Yesterday I was fortunate enough to attend the Summerside 'instance' of the Global Day of Coderetreat (my first ever) and already I can't wait for the next one.
The day is very difficult to describe without sounding like a cultist, to be honest :) There's something very awesome about being able to slowly, precisely and correctly write code without having any pressure to just 'get it done'.
For those that aren't familiar with the process, ours went something like this: partner up, write some code for 45 minutes then delete it. Add a constraint and repeat. While the goal seems to be "implement Conway's Game of Life", the actual goal, in a way, is to never quite get there :)
For our particular retreat, we started with basically just trying to implement GoL correctly. This means using TDD properly, and slowly implementing the code bit by bit. My first round I got to do it in Java, which is always fun.
After deleting the code, we added the constraint of 'no conditionals'. This time my 'pair' wrote in PHP and surprisingly enough got to the exact some point in the code as the first round (which I found humourous).
After lunch, we added 'use no primitives' (and 'no PHP' :) ). This time my partner and I decided to use Ruby, which was fantastic as I am an absolute beginner, and my team mate was definitely not an expert. We got to spend some time learning RSpec (for testing Ruby code) and we spent a lot of time simply discussing what the constraint meant. It was definitely a difficult thing to wrap our heads around, but this was the point where I suddenly realised that some of our constraints are not necessarily possible with all of the languages that we choose to use. This was definitely a pivotal moment for me. To be honest, it had been brought to my attention at the end of the first constraint, but this time it was me making the realisation by myself :)
Delete. Break. Try again. This time using JS and 'only return self'. Delete. Break. Back to Java and 'no more than 4 lines per method, ping pong coding' (and maybe something else). By this time, for sure, I was completely beat. My brain stopped working around 2:30PM and so to be honest it's quite possible that the constraints I listed may be out of order, wrong, or incomplete. Also, by the end of the day (and quite naturally) we were getting less and less code done, but there was more and more conversation around how we would do the code.
While these constraints may seem random or simply designed to annoy, each session ended with some really good discussion as to how these constraints actually make our code more testable, easier to develop (with some practice!) and ultimately better.
Lately I have been reflecting on my time at university. "Youth is wasted on the young", they say, and I believe, sometimes, that "university is wasted on the uneducated". The more I have been able to think about what I learned there, it seems, the more it is that I'm relearning all of these lessons again.
And that's a good thing.
I've also been reminded that I need to extend my knowledge of languages again!
Thanks especially to the City of Summerside for giving us the venue (and gigabit internet to boot!) and all of the organisers (especially Steven Baker and Derek Campbell).
I can't wait for the next one!
Sunday, December 15, 2013
Wednesday, September 18, 2013
Please... No More Rock Stars!
Let me cut to the chase: I'm so sick and tired of seeing people advertising for software developers and using nouns to describe these future employees as something they are not.
As a possible candidate for this position, here's why I don't match what you're hiring...
I'm not a rock star. I don't have any recording deals, and I don't have groupies. More importantly, I don't turn around and leave you in the lurch at crunch time because I would rather do something shady at the hotel when I'm meant to be wowing the fans.
I'm not a ninja. For one I have very little martial arts training. More importantly, I don't come in in the middle of the night and drastically upset things so that when you come back the next morning you wonder "what the hell just happened?!?"
Finally, I'm not Chunk Norris (yes, I just saw this advertised!) I don't think I have to actually say anything about this but I'll tell you what... well, I'm not Chuck Norris.
I get it's all about advertising and marketing and all that crap but as far as I'm concerned, you're trying to impress the wrong people! Software engineers aren't about showmanship. We're not about trying to seem hip and happening and all that. We're about getting it done and doing it well.
I also get that there are some instances when you need what may be defined as a rock star. However, if you're not planning on paying that person a heap of money to always be on the road at conferences, selling your brand subconsciously, then I think you're doing it wrong. Alternatively, maybe, a rock star is someone you're hiring because you're hiring that person... in which case, you're not really going to advertise for them!
As far as I'm concerned, there aren't many people that look at an advertised position and think to themselves "you know what? I am a rock star!". As far as I'm concerned, the people that look at your ad and get their ego stroked that way are exactly the kinds of people you shouldn't want to hire.
Stop please. For my sake. Stop stroking the wrong peoples' egos and stop making yourself look like you're more about marketing than you are about development.
Please?
As a possible candidate for this position, here's why I don't match what you're hiring...
I'm not a rock star. I don't have any recording deals, and I don't have groupies. More importantly, I don't turn around and leave you in the lurch at crunch time because I would rather do something shady at the hotel when I'm meant to be wowing the fans.
I'm not a ninja. For one I have very little martial arts training. More importantly, I don't come in in the middle of the night and drastically upset things so that when you come back the next morning you wonder "what the hell just happened?!?"
Finally, I'm not Chunk Norris (yes, I just saw this advertised!) I don't think I have to actually say anything about this but I'll tell you what... well, I'm not Chuck Norris.
I get it's all about advertising and marketing and all that crap but as far as I'm concerned, you're trying to impress the wrong people! Software engineers aren't about showmanship. We're not about trying to seem hip and happening and all that. We're about getting it done and doing it well.
I also get that there are some instances when you need what may be defined as a rock star. However, if you're not planning on paying that person a heap of money to always be on the road at conferences, selling your brand subconsciously, then I think you're doing it wrong. Alternatively, maybe, a rock star is someone you're hiring because you're hiring that person... in which case, you're not really going to advertise for them!
As far as I'm concerned, there aren't many people that look at an advertised position and think to themselves "you know what? I am a rock star!". As far as I'm concerned, the people that look at your ad and get their ego stroked that way are exactly the kinds of people you shouldn't want to hire.
Stop please. For my sake. Stop stroking the wrong peoples' egos and stop making yourself look like you're more about marketing than you are about development.
Please?
Tuesday, August 20, 2013
Roaming in the US... Now that's the way to do it!
We just got back from a 4 day trip in Boston. Because a lot of the time my wife and I were going to be in separate parts of the city, we really needed to be able to contact each other. Suffice to say, we were dreading the roaming charges!
Having spoken to our current cell provider, we were looking at $1.50 / minute for voice, 60c / message for text and $5.00 / MB for data. A $50 package would have given us 50 minutes, 50 messages and 25MB of data, before going back to charges that were approximately half of the 'non package' prices.
Only 50 messages? The worst thing about that is that it's incoming and outgoing, so really it's only 25 messages in a way. This was still going to be expensive!
We started to think about prepaid SIMs, but trying to organise that was going to be a hassle. That is until I found Roam Mobility.
There is one prerequisite for using Roam and it's the same prerequisite for using other pre-paid SIMs... your phone needs to be unlocked as far as the network is concerned. This is fine for us as we had Nexus 4's that only cost us $50 to begin with :)
So here's the deal: with Roam, you can buy a SIM card for $20 (I bought mine at the local Telus store). Once activated, that card gives you a phone number based in the US (note that it also only works in the US). So long as you use it at least once a year, you can keep that SIM. Once it's activated, you buy a 1, 3, 7, 14 or 30 day plan.
We opted for the 7 day 'Talk + Text + Data' plan and here's what we got:
- Unlimited talk within the US as well as to Canada
- Unlimited text within the US as well as to Canada
- A total of 700MB of data usage (for every day's worth of plan, you get 100MB of data)
How much? $27.95!
So for less than the $50 roaming package from our own provider, we got unlimited talk and text and all the data we needed / wanted. They even tell you how to set your phone up as a mobile hotspot for your laptop!
The coverage was no problem and it was probably the most simple process I have ever used for anything related to telecommunication.
So that's my tip: if you're roaming to the US, get an unlocked phone and jump onto Roam... I can't wait to travel that way again, just so that I can use it again :)
Having spoken to our current cell provider, we were looking at $1.50 / minute for voice, 60c / message for text and $5.00 / MB for data. A $50 package would have given us 50 minutes, 50 messages and 25MB of data, before going back to charges that were approximately half of the 'non package' prices.
Only 50 messages? The worst thing about that is that it's incoming and outgoing, so really it's only 25 messages in a way. This was still going to be expensive!
We started to think about prepaid SIMs, but trying to organise that was going to be a hassle. That is until I found Roam Mobility.
There is one prerequisite for using Roam and it's the same prerequisite for using other pre-paid SIMs... your phone needs to be unlocked as far as the network is concerned. This is fine for us as we had Nexus 4's that only cost us $50 to begin with :)
So here's the deal: with Roam, you can buy a SIM card for $20 (I bought mine at the local Telus store). Once activated, that card gives you a phone number based in the US (note that it also only works in the US). So long as you use it at least once a year, you can keep that SIM. Once it's activated, you buy a 1, 3, 7, 14 or 30 day plan.
We opted for the 7 day 'Talk + Text + Data' plan and here's what we got:
- Unlimited talk within the US as well as to Canada
- Unlimited text within the US as well as to Canada
- A total of 700MB of data usage (for every day's worth of plan, you get 100MB of data)
How much? $27.95!
So for less than the $50 roaming package from our own provider, we got unlimited talk and text and all the data we needed / wanted. They even tell you how to set your phone up as a mobile hotspot for your laptop!
The coverage was no problem and it was probably the most simple process I have ever used for anything related to telecommunication.
So that's my tip: if you're roaming to the US, get an unlocked phone and jump onto Roam... I can't wait to travel that way again, just so that I can use it again :)
Thursday, August 8, 2013
Not Going to NEPHP? Try Pandacodium Instead!
You may or may not have noticed that I'm heading to Boston next weekend for the Northeast PHP conference. You also may or may not have realised there was a little sarcasm in that last sentence.
But what are you going to do? Where are you going to be? What if I told you that you could attend a hackathon instead?
Well?
Pandacodium is an online, world-wide hackathon that's going to run for 48 hours starting on Friday, August 16th at 7PM.
I don't know if the theme changes every year, but either way, this one is going to be focussed on developing real-time web applications.
Although I've never been to a hackathon, and I'm probably going to miss the one in Charlottetown in a few weeks, it's something that I'm itching to do... and now you all can! Please, let me live through your adventures :)
Seriously: I urge everyone that can to take this opportunity to flex your coding muscle, stretch your comfort zone, meet new people and more importantly have a heap of fun! Head over to http://pandacodium.ca right now and sign up. If I weren't going to Boston, I'd be doing this.
Let me know if you're going to go in it... I want to hear all of the gory details!
But what are you going to do? Where are you going to be? What if I told you that you could attend a hackathon instead?
Well?
Pandacodium is an online, world-wide hackathon that's going to run for 48 hours starting on Friday, August 16th at 7PM.
I don't know if the theme changes every year, but either way, this one is going to be focussed on developing real-time web applications.
Although I've never been to a hackathon, and I'm probably going to miss the one in Charlottetown in a few weeks, it's something that I'm itching to do... and now you all can! Please, let me live through your adventures :)
Seriously: I urge everyone that can to take this opportunity to flex your coding muscle, stretch your comfort zone, meet new people and more importantly have a heap of fun! Head over to http://pandacodium.ca right now and sign up. If I weren't going to Boston, I'd be doing this.
Let me know if you're going to go in it... I want to hear all of the gory details!
Monday, July 29, 2013
NEPHP 2013: Don't Be STUPID, Grasp SOLID
This may be getting boring, but too bad... there are so many talks to see at Northeast PHP this year!
Anthony Ferrara is giving a talk this year titled 'Don't be STUPID, Grasp SOLID' (see http://northeastphp.org/talks/view/33/Don-t-Be-STUPID-Grasp-SOLID and https://joind.in/talk/view/8907).
This is another one of those talks that I think I need to concretely square away some issues I've been having with my code lately. When I first started writing code, I always had small, compact functions. However, somewhere between here and there I lost my way.
I started cramming random meaning into particular function parameters, for example. Depending on the combination of 46 different parameters, the function would do one of 2,500 things... just because it seemed right to use the same function name. This may be because of PHP's lack of function overloading, or it may not. Either way, I realise now how stupid it all was.
Elsewhere, my code started pulling in random static classes, using singletons from static function calls and the like... this is all bad news when you start realising the benefits of unit testing, for example, but in reality, and in my older age, I've realised it's just bad news no matter what.
So like I say: I've started to come back around to smaller functions and classes and already it's made a huge impact on the way I work. I can honestly say that changing that particular approach to my coding has probably saved me more time and given me more safety than any other 'tweak' I've done to my 'style' in the last 5 years. And now that I have a taste for it, I'm looking for more!
Other than the actual topic, I've heard some awesome things about Anthony himself, so it'll be great just to see him talk anyway.
Hopefully you will too!
Anthony Ferrara is giving a talk this year titled 'Don't be STUPID, Grasp SOLID' (see http://northeastphp.org/talks/view/33/Don-t-Be-STUPID-Grasp-SOLID and https://joind.in/talk/view/8907).
This is another one of those talks that I think I need to concretely square away some issues I've been having with my code lately. When I first started writing code, I always had small, compact functions. However, somewhere between here and there I lost my way.
I started cramming random meaning into particular function parameters, for example. Depending on the combination of 46 different parameters, the function would do one of 2,500 things... just because it seemed right to use the same function name. This may be because of PHP's lack of function overloading, or it may not. Either way, I realise now how stupid it all was.
Elsewhere, my code started pulling in random static classes, using singletons from static function calls and the like... this is all bad news when you start realising the benefits of unit testing, for example, but in reality, and in my older age, I've realised it's just bad news no matter what.
So like I say: I've started to come back around to smaller functions and classes and already it's made a huge impact on the way I work. I can honestly say that changing that particular approach to my coding has probably saved me more time and given me more safety than any other 'tweak' I've done to my 'style' in the last 5 years. And now that I have a taste for it, I'm looking for more!
Other than the actual topic, I've heard some awesome things about Anthony himself, so it'll be great just to see him talk anyway.
Hopefully you will too!
Saturday, July 27, 2013
NEPHP 2013: You Can UX Too: Avoiding the Programmer's User Interface
Just another talk I want to see in Boston this year at Northeast PHP 2013...
This talk is on a track that I must admit, I know pretty much nothing about. And to be honest, until recently I've tried to avoid it. But no longer! User Experience (UX) is definitely something I need to be on top of and conferences, talks and workshops are a perfect way to get on the way.
With this in mind, I'm looking forward to the talk 'You Can UX Too: Avoiding the Programmer's User Interface', to be given by Eryn O'Neil. If you want details, check out either http://northeastphp.org/talks/view/187/You-Can-UX-Too-Avoiding-the-Programmer-s-User-Interface or http://joind.in/talk/view/8931.
The reason this is going to be on the top of my 'UX exposure list' is specifically because it speaks directly to me. I am a programmer, no doubt about it, and this talk is addressing the simple (and dare I say obvious?) fact that UX is a problem for programmers. I'm really looking forward to getting an idea of how to take off my coding hat and stick on my UX hat easily, and hopefully more often.
For what it's worth, I'm not saying that I don't want to see any of the other UX talks. On the contrary, this whole realm of software is completely foreign to me and I really need to correct that.
And dare I give kudos to the conference itself for making sure to include this UX track? It's going to be fantastic to have such a wide audience at the one place... I'm looking forward to getting to talk to these 'UX-aware' attendees and finally being able to get an idea of how it all works.
Thursday, July 25, 2013
NEPHP 2013: Agile in the Workplace
So another talk I'm looking forward to seeing this year at Northeast PHP is 'Agile in the Workplace', to be given by Michael Stowe (more details at http://northeastphp.org/talks/view/57/Agile-in-the-Workplace and https://joind.in/talk/view/8914).
To understand why I'm going to find this talk interesting, you have to know that I tend to be one of those people that learns way more through practical examples than I ever do through theory.
The concepts intrigue me, however all the reading in the world is not going to make it all fall together without real life exposure. Unfortunately that would mean finding and working with a group that practices agile correctly... which is not really an option for me. So instead, I'll take the second best thing: I'm going to listen to someone talking about it, and no doubt listen to stories about practical examples.
I'm looking forward to hearing the good and the bad about the process, and ways that I can avoid following those bad practices. For what it's worth, the reason I highlighted the word 'correctly' above is because from what I understand, 'agile' can very easily be a word that gets thrown around by groups, without actually being agile. Every story I've heard about these groups tends to imply that there is a very painful lesson to be learned about the difference between being agile and thinking you're being agile.
Hopefully, too, there may be a way to correctly ease a team into an agile workflow, which I believe would help everyone by being an evolution as opposed to a revolution.
Either way, I say 'viva la agile'. Or something like that... My French is not so good.
To understand why I'm going to find this talk interesting, you have to know that I tend to be one of those people that learns way more through practical examples than I ever do through theory.
The concepts intrigue me, however all the reading in the world is not going to make it all fall together without real life exposure. Unfortunately that would mean finding and working with a group that practices agile correctly... which is not really an option for me. So instead, I'll take the second best thing: I'm going to listen to someone talking about it, and no doubt listen to stories about practical examples.
I'm looking forward to hearing the good and the bad about the process, and ways that I can avoid following those bad practices. For what it's worth, the reason I highlighted the word 'correctly' above is because from what I understand, 'agile' can very easily be a word that gets thrown around by groups, without actually being agile. Every story I've heard about these groups tends to imply that there is a very painful lesson to be learned about the difference between being agile and thinking you're being agile.
Hopefully, too, there may be a way to correctly ease a team into an agile workflow, which I believe would help everyone by being an evolution as opposed to a revolution.
Either way, I say 'viva la agile'. Or something like that... My French is not so good.
Tuesday, July 23, 2013
Could Second Item Auctions be Used for Ticket Sales?
Every time a big concert, game, show or whatnot goes on sale, we invariably read people complaining about scalpers taking all of the tickets and then jacking up the prices.
Firstly, let me try and summarise my take on both sides of the argument. The anti-scalper argument is that because scalpers are buying as many tickets as possible, and because their business revolves around the fact that they can get these tickets, it means that the scalpers are going to always try and be first to buy, and have a financial incentive to do so. That is to say, the fans have less of a chance to buy the tickets.
The pro-scalper argument is that basically it's the free market, baby! When scalpers can buy and sell tickets for a profit, then that indicates that the original ticket price was 'wrong', in that the sellers were leaving money on the table so to speak.
So with that being my understanding of the problem, I ask: what would happen if tickets were sold off in the form of a second item auction? A second item auction is when you are auctioning more than one identical item, and basically the winners are those people that bid the most... with the 'twist' being that all winners only pay the lowest winning bid.
For what it's worth, I always thought this was called a Dutch auction, but that link to Wikipedia actually says that a second item auction can be confused with a Dutch auction, so I don't feel so bad...
So off the bat, this sounds like a horrible idea: in theory the scalpers are cut out of the process, as those people that are willing to spend big will do that directly with the seller. The fans are probably screwed out of the process too, though, as they are likely going to be outbid.
Over time, though, I wonder if the prices would fall, as there is going to be a group of people that are bidding higher than they would like, just to make sure they get to go to the show? In my head, at least, I think that as this goes on for a little bit and scalpers are essentially squeezed out of the market, these people will find that they can slowly lower their bids and still get tickets.
Either way, it would definitely remove a lot of the incentive for the scalpers, and would even remove the argument for the existence of them: the whole 'the price is not what the market is willing to bear'.
And who knows? Maybe the other fans will be happier, just knowing that there isn't someone there, buying tickets from under them simply to make money. Or not...
Firstly, let me try and summarise my take on both sides of the argument. The anti-scalper argument is that because scalpers are buying as many tickets as possible, and because their business revolves around the fact that they can get these tickets, it means that the scalpers are going to always try and be first to buy, and have a financial incentive to do so. That is to say, the fans have less of a chance to buy the tickets.
The pro-scalper argument is that basically it's the free market, baby! When scalpers can buy and sell tickets for a profit, then that indicates that the original ticket price was 'wrong', in that the sellers were leaving money on the table so to speak.
So with that being my understanding of the problem, I ask: what would happen if tickets were sold off in the form of a second item auction? A second item auction is when you are auctioning more than one identical item, and basically the winners are those people that bid the most... with the 'twist' being that all winners only pay the lowest winning bid.
For what it's worth, I always thought this was called a Dutch auction, but that link to Wikipedia actually says that a second item auction can be confused with a Dutch auction, so I don't feel so bad...
So off the bat, this sounds like a horrible idea: in theory the scalpers are cut out of the process, as those people that are willing to spend big will do that directly with the seller. The fans are probably screwed out of the process too, though, as they are likely going to be outbid.
Over time, though, I wonder if the prices would fall, as there is going to be a group of people that are bidding higher than they would like, just to make sure they get to go to the show? In my head, at least, I think that as this goes on for a little bit and scalpers are essentially squeezed out of the market, these people will find that they can slowly lower their bids and still get tickets.
Either way, it would definitely remove a lot of the incentive for the scalpers, and would even remove the argument for the existence of them: the whole 'the price is not what the market is willing to bear'.
And who knows? Maybe the other fans will be happier, just knowing that there isn't someone there, buying tickets from under them simply to make money. Or not...
Monday, July 22, 2013
NEPHP 2013 Talks: How To Get There
Just another post, keeping hungry for the Northeast PHP conference this coming August in Boston...
What I could only assume is due to the alignment of a number of stars, I see that Larry Ullman is giving a talk titled 'How To Get There' (more details at http://northeastphp.org/talks/view/148/How-To-Get-There and https://joind.in/talk/view/8911).
Lately I have been feeling more and more like I'm not at my peak. I should be better, bigger and more valuable than I am. This is hopefully going to be one of those talks that slaps me in the face and gets me to wake up and push through.
The funny thing about these motivational talks, I find, is the fact that simply by me acknowledging that I want to see this talk pushes me further. Which is awesome.
Even still, I really can't way to see Larry talk. Along with his other talks 'Ajax: You Can Do It Too' and 'Teaching PHP & Web Development' I foresee a day when Larry may have his own track at NEPHP and to be honest, I'd probably end up seeing all of it!
What I could only assume is due to the alignment of a number of stars, I see that Larry Ullman is giving a talk titled 'How To Get There' (more details at http://northeastphp.org/talks/view/148/How-To-Get-There and https://joind.in/talk/view/8911).
Lately I have been feeling more and more like I'm not at my peak. I should be better, bigger and more valuable than I am. This is hopefully going to be one of those talks that slaps me in the face and gets me to wake up and push through.
The funny thing about these motivational talks, I find, is the fact that simply by me acknowledging that I want to see this talk pushes me further. Which is awesome.
Even still, I really can't way to see Larry talk. Along with his other talks 'Ajax: You Can Do It Too' and 'Teaching PHP & Web Development' I foresee a day when Larry may have his own track at NEPHP and to be honest, I'd probably end up seeing all of it!
Thursday, July 18, 2013
NEPHP 2013 Talks: Package Management in PHP
The Northeast PHP Conference is coming up, and to keep myself motivated and on the edge of my seat, I figured I might write about some of the talks and workshops I'm looking forward to...
One of the talks that I'm really excited to see at NEPHP is titled "Package Management in PHP: Better Late than Never!" (you can see it at http://northeastphp.org/talks/view/21/Package-Management-in-PHP-Better-Late-than-Never and https://joind.in/talk/view/8903).
To be honest, I don't think I have to say much on this at all. As far as I'm concerned, if you don't understand the premise then that's a great sign that you have something interesting to look into. If you do understand it and don't care, then I believe that you're on the wrong path.
The description itself explains the crux of the issue: a lot of current (and some not so current) languages already have similar tools for managing the packages that you use in your code, and it's great to see some advancements in this field for PHP.
Don't get me wrong: PEAR was a pretty good start, but it seems as though every attempt at improving that process seemed to fail, until now with Composer and Packagist.
A simple command line tool that lets you easily dictate the required versions of libraries and then takes care of grabbing them (and their dependencies!), storing them in your project and even managing upgrades? Count me in!
While on the one hand we have Composer, that manages these packages, it has to get them from somewhere, and while it can get them from practically anywhere, we look to the other hand and we find Packagist. Packagist is quickly becoming the 'go to' place for these libraries. It's almost like the new PEAR site, or Perl's CPAN. So put these two together and suddenly we have an easy way to find packages, and then an easy way to manage them in our own projects.
It's becoming more and more obvious that we will be using more and more of these focussed packages for single purposes as time goes by, and keeping track of all of that will be a nightmare without something like this. If you're not at least trying to use these packages, then let's face it: you're probably wasting time re-inventing the wheel.
As I mentioned earlier, Composer really is picking up steam and I'm loving the fact that frameworks such as Symfony 2 (and it's little brother Silex) are using it as the go to system for managing their own packages.
I hope I sound as excited as I actually am for this stuff: it's an awesome development for successful code reuse that's spreading across entirely separate projects and all of a sudden PHP developers are OK with reaching outside of their own source tree to find something that works well and works now.
Hat's off to the Composer and Packagist teams, and I can't wait to see Sequoia McDowell's talk at Northeast PHP this year.
Hopefully I'll see you there too!
One of the talks that I'm really excited to see at NEPHP is titled "Package Management in PHP: Better Late than Never!" (you can see it at http://northeastphp.org/talks/view/21/Package-Management-in-PHP-Better-Late-than-Never and https://joind.in/talk/view/8903).
To be honest, I don't think I have to say much on this at all. As far as I'm concerned, if you don't understand the premise then that's a great sign that you have something interesting to look into. If you do understand it and don't care, then I believe that you're on the wrong path.
The description itself explains the crux of the issue: a lot of current (and some not so current) languages already have similar tools for managing the packages that you use in your code, and it's great to see some advancements in this field for PHP.
Don't get me wrong: PEAR was a pretty good start, but it seems as though every attempt at improving that process seemed to fail, until now with Composer and Packagist.
A simple command line tool that lets you easily dictate the required versions of libraries and then takes care of grabbing them (and their dependencies!), storing them in your project and even managing upgrades? Count me in!
While on the one hand we have Composer, that manages these packages, it has to get them from somewhere, and while it can get them from practically anywhere, we look to the other hand and we find Packagist. Packagist is quickly becoming the 'go to' place for these libraries. It's almost like the new PEAR site, or Perl's CPAN. So put these two together and suddenly we have an easy way to find packages, and then an easy way to manage them in our own projects.
It's becoming more and more obvious that we will be using more and more of these focussed packages for single purposes as time goes by, and keeping track of all of that will be a nightmare without something like this. If you're not at least trying to use these packages, then let's face it: you're probably wasting time re-inventing the wheel.
As I mentioned earlier, Composer really is picking up steam and I'm loving the fact that frameworks such as Symfony 2 (and it's little brother Silex) are using it as the go to system for managing their own packages.
I hope I sound as excited as I actually am for this stuff: it's an awesome development for successful code reuse that's spreading across entirely separate projects and all of a sudden PHP developers are OK with reaching outside of their own source tree to find something that works well and works now.
Hat's off to the Composer and Packagist teams, and I can't wait to see Sequoia McDowell's talk at Northeast PHP this year.
Hopefully I'll see you there too!
Wednesday, July 3, 2013
My Take on the Marshmallow Experiment
I just finished reading an article that apparently explains "What Marshmallows Tell Us About Silicon Valley". It's a take on the classic Stanford Marshmallow Experiment.
On and off, I have considered what I would have done if I were in that situation... and what would I do if I were in that situation now?
I honestly believe that it doesn't matter when it took place, I am 99% certain that if the 'marshmallows' offered were basically of equal value to me, I would eat the first one then and there.
Apparently that implies that I have little patience and not much self-control. While that is true to an extent (I mean, everyone can point to moments in their lives when that is true), I don't believe that is the reason for me eating the marshmallows straight away.
For me, it's a lot simpler: firstly, I don't really care that much for 'more candy' and as far as I can remember, I never have. For me, a second marshmallow in 15 minutes time just seems like a stupid thing to wait for... but then that may be what the experiment proves. Secondly, however, is something that I think more defines why I would not wait.
I was raised to believe that expecting a 'host' to have to do more work for me is unacceptable (where in this case, the host was the experimenter). As far as I'm concerned, a host provides their guests with a venue to facilitate a good time. Although they probably will have food, drink, music or whatever, I've never been to someone's home and then complained after leaving "man, they could have at least offered me a coffee!"
When I was a boy and my friends would come over, my parents made sure that they all knew to "make yourself at home". That means to feel comfortable and if you want something to eat or drink and it's not been offered, that doesn't mean that you have to go without. As my parents would say "you're a big boy... use your legs!".
On a tangent now, but I don't want to give the impression that our home was "that place" where everyone just raised themselves. Quite the opposite, actually. "Make yourself at home" meant "you're part of the family", not "treat this place as the place you live in". Therefore, conversely, if you didn't want to be part of our extended family, that was fine... just don't expect us to offer you the same courtesies. That meant some interesting interactions between my friends and my parents at times... but at least everyone knew where everyone stood!
Anyway, back to the marshmallows. If I am a guest somewhere and I am offered something, with the option of more later, then for me it would just be rude to expect my host to then have to go out of their way to organise the extra stuff. If it was already prepared and they actually wanted me to have it, they would have offered it to begin with. Anything other than that and they were obviously just being nice and I would obviously not want to put them out. If I wanted another marshmallow, surely I should get one myself at a time and place that's more convenient to everyone.
So, long story short: as far as I'm concerned, the reason I would take the marshmallow today has only a little to do with impulse control, and mainly all to do with the fact that I would consider it rude to have the host have to get me something else later on. Instead, stop worrying about me, sit down and have one yourself!
Oh yeah, and you could at least offer me a coffee :)
Monday, June 24, 2013
Northeast PHP Conference 2013
This is me, telling anyone who cares that the Northeast PHP Conference is set to run again this year from August 16-18.
This year is a little different, though, in that as well as the two days of talks, there's also a day of workshops. The line up for speakers is looking awesome and as a way of testing my typing fingers, I'll probably start writing about which talks I'm most interested in... just to keep myself excited :)
The thing I love about this conference is that it has a focus on inclusion: the talks are ranging from beginners to advanced, and there is an entire track dedicated to User Experience, which I think is sorely lacking in our industry.
If anyone else is going to be in Boston for the conference let me know, as I think it'll be an awesome opportunity to catch up or meet for the first time!
This year is a little different, though, in that as well as the two days of talks, there's also a day of workshops. The line up for speakers is looking awesome and as a way of testing my typing fingers, I'll probably start writing about which talks I'm most interested in... just to keep myself excited :)
The thing I love about this conference is that it has a focus on inclusion: the talks are ranging from beginners to advanced, and there is an entire track dedicated to User Experience, which I think is sorely lacking in our industry.
If anyone else is going to be in Boston for the conference let me know, as I think it'll be an awesome opportunity to catch up or meet for the first time!
Monday, June 10, 2013
Backing up from Plesk to S3
Recently I went looking for a solution for backing up from a Plesk server to S3: what I settled on was surprisingly simple.
I started with a simple list of criteria, but as I went looking for a solution, and as I continued to find no good ones, my list got longer. I have a tendency to be quite OK with the bare bones if I'm going to be using an existing system, but if I have to build it myself, I'm normally happy to add more features.
I started with basically "I want to be able to backup files and databases", but the solution I ended up with also gave me the following features:
- backup multiple domains
- along with files and databases, backup the actual domain configuration and mail if required
- rotate backups automatically
- define the frequency of backups and the number of backups to keep before rotating
- open source
- a simple interface right in Plesk
So what did I do?
I don't know, really, if this is a super smart way to do it, or just a cop-out, but basically I realised that hey, the Plesk backup manager already let's us do all of the above... except for the S3 part. All that I ended up doing was installing s3cmd from http://s3tools.org and setting it up to do the syncing to S3, looking at the location on the server that Plesk puts it backups.
So basically, users (or I) define backup rules for each domain as needed (via the Plesk UI) and then s3cmd runs with the sync option once a day.
With s3cmd located in my /root/cli-tools directory, and assuming s3://example.com is the name of the bucket I will use, the actual cron tab entry I use is as simple as:
cd /var/lib/psa/dumps; /root/cli-tools/s3/s3cmd -c /root/cli-tools/s3/s3cfg --delete-removed -H --no-progress sync domains s3://example.com/backups
UPDATE: as per a comment by Rutger below, you may actually want to use:
cd /var/lib/psa/dumps; /root/cli-tools/s3/s3cmd -c /root/cli-tools/s3/s3cfg --delete-removed -H --no-progress sync clients s3://example.com/backups
instead of, or possibly in association with, the above line.
When I commission a new Plesk server, I just copy the s3cmd directory over, create a new bucket and I'm done.
The only downsides I see, really, are that if I wanted to just have a single rule for all of the domains, I couldn't. Also, I'm assuming that all of the backups have been run when the cron job runs once a day. Not that that matters too much, as I could just bump the cron job up to hourly if I liked and I wouldn't see much difference.
I think the biggest negative to this approach is that I'm pushing backups explicitly even if what has been backed up actually hasn't changed. That is to say, if Plesk does a backup everyday, then I push a new backup every day... even if nothing has changed since the last backup.
Anyway, I hope this helps someone as for me it was completely obvious once I realised it, but it took me an embarrassingly long time to get to it.
I started with a simple list of criteria, but as I went looking for a solution, and as I continued to find no good ones, my list got longer. I have a tendency to be quite OK with the bare bones if I'm going to be using an existing system, but if I have to build it myself, I'm normally happy to add more features.
I started with basically "I want to be able to backup files and databases", but the solution I ended up with also gave me the following features:
- backup multiple domains
- along with files and databases, backup the actual domain configuration and mail if required
- rotate backups automatically
- define the frequency of backups and the number of backups to keep before rotating
- open source
- a simple interface right in Plesk
So what did I do?
I don't know, really, if this is a super smart way to do it, or just a cop-out, but basically I realised that hey, the Plesk backup manager already let's us do all of the above... except for the S3 part. All that I ended up doing was installing s3cmd from http://s3tools.org and setting it up to do the syncing to S3, looking at the location on the server that Plesk puts it backups.
So basically, users (or I) define backup rules for each domain as needed (via the Plesk UI) and then s3cmd runs with the sync option once a day.
With s3cmd located in my /root/cli-tools directory, and assuming s3://example.com is the name of the bucket I will use, the actual cron tab entry I use is as simple as:
cd /var/lib/psa/dumps; /root/cli-tools/s3/s3cmd -c /root/cli-tools/s3/s3cfg --delete-removed -H --no-progress sync domains s3://example.com/backups
UPDATE: as per a comment by Rutger below, you may actually want to use:
cd /var/lib/psa/dumps; /root/cli-tools/s3/s3cmd -c /root/cli-tools/s3/s3cfg --delete-removed -H --no-progress sync clients s3://example.com/backups
instead of, or possibly in association with, the above line.
When I commission a new Plesk server, I just copy the s3cmd directory over, create a new bucket and I'm done.
The only downsides I see, really, are that if I wanted to just have a single rule for all of the domains, I couldn't. Also, I'm assuming that all of the backups have been run when the cron job runs once a day. Not that that matters too much, as I could just bump the cron job up to hourly if I liked and I wouldn't see much difference.
I think the biggest negative to this approach is that I'm pushing backups explicitly even if what has been backed up actually hasn't changed. That is to say, if Plesk does a backup everyday, then I push a new backup every day... even if nothing has changed since the last backup.
Anyway, I hope this helps someone as for me it was completely obvious once I realised it, but it took me an embarrassingly long time to get to it.
Sunday, June 9, 2013
On having nothing to hide...
Obviously, there's a lot of discussion right now about what information should be considered private, and whether or not people really have nothing to hide. I believe that people have a lot of information that they want to keep private: even when they say they don't.
When I meet people that say they have nothing to hide, I 'play' one (or more) of three cards.
The first thing I will do is ask them how often they masturbate. I know it's a fairly taboo question, but that's the point. It's not illegal, it doesn't hurt anyone, but not many people want to answer the question and I will push them a bit before I change tack. A lot of people think that this is a stupid question because it doesn't make a difference and that it's meaningless. Apparently that makes it somehow mean that they still have nothing to hide, but anyway.
Sometimes I choose to play the "we don't know the future" aspect. One of my cousins is gay. That is not illegal where we live, but there are places where it is and let's face it, there are no doubt people even in our community that would prefer for it to be illegal. In the future, what if it became illegal? All of a sudden, all of that knowledge of what I didn't need to hide becomes a problem.
Let me reiterate that: right now, my cousin has nothing to hide, and I have nothing to hide in knowing that they're gay. In the future, if it became illegal, there's a ton of information that suddenly we may wish to have been kept secret. Unfortunately, that stuff that we didn't have any reason to hide suddenly becomes something we may wish we were able to.
Finally, depending on who I'm talking to, sometimes I will play the family card. If the person I'm talking to has a child (especially a daughter) I like to ask them how they would feel if in the future that child was dating a good government employee that had access to all sorts of information. Then I begin to wonder, what would happen if they went through a messy break-up? I wonder, what if that ex turns out to be a little jealous and maybe a bit of a stalker? Would you support, then, there being a heap of information on your child, being easily accessible to this ex?
I guess a lot of my arguments come down to this: you don't know the future. In this, you have no idea what you do at the moment that may be considered dodgy behaviour in the future.
Even if you think that that's not a problem, there's a very good chance that right now, you do stuff that you don't want people to know and as far as I'm concerned, the very fact that you haven't considered that means that you haven't spent nearly enough time thinking about it. And to be honest, that frightens me just as much.
When I meet people that say they have nothing to hide, I 'play' one (or more) of three cards.
The first thing I will do is ask them how often they masturbate. I know it's a fairly taboo question, but that's the point. It's not illegal, it doesn't hurt anyone, but not many people want to answer the question and I will push them a bit before I change tack. A lot of people think that this is a stupid question because it doesn't make a difference and that it's meaningless. Apparently that makes it somehow mean that they still have nothing to hide, but anyway.
Sometimes I choose to play the "we don't know the future" aspect. One of my cousins is gay. That is not illegal where we live, but there are places where it is and let's face it, there are no doubt people even in our community that would prefer for it to be illegal. In the future, what if it became illegal? All of a sudden, all of that knowledge of what I didn't need to hide becomes a problem.
Let me reiterate that: right now, my cousin has nothing to hide, and I have nothing to hide in knowing that they're gay. In the future, if it became illegal, there's a ton of information that suddenly we may wish to have been kept secret. Unfortunately, that stuff that we didn't have any reason to hide suddenly becomes something we may wish we were able to.
Finally, depending on who I'm talking to, sometimes I will play the family card. If the person I'm talking to has a child (especially a daughter) I like to ask them how they would feel if in the future that child was dating a good government employee that had access to all sorts of information. Then I begin to wonder, what would happen if they went through a messy break-up? I wonder, what if that ex turns out to be a little jealous and maybe a bit of a stalker? Would you support, then, there being a heap of information on your child, being easily accessible to this ex?
I guess a lot of my arguments come down to this: you don't know the future. In this, you have no idea what you do at the moment that may be considered dodgy behaviour in the future.
Even if you think that that's not a problem, there's a very good chance that right now, you do stuff that you don't want people to know and as far as I'm concerned, the very fact that you haven't considered that means that you haven't spent nearly enough time thinking about it. And to be honest, that frightens me just as much.
Wednesday, February 13, 2013
A Friendly Reminder About Something I'd Already Paid For
A few weeks ago I purchased a product online called Texture Packer Pro. The purchase went completely smoothly and without a hitch.
Imagine my surprise, then, when I received an email about my purchase the other day. To be honest, I was a little concerned.
Opening the email was a pleasant surprise. Simply put, the email was a timely reminder about the fact that I should expect a certain payee on my credit card statement, telling me how much it was for, who the payee was and, especially, what the purchase was for.
Such a simple little thing, at the right moment, and there will no longer even be a second of doubt when I look at my statement. I loved it, and intend to do a similar thing as soon as I start selling online, too.
And for what it's worth, if you're looking for a tool to resize and place images into a texture map (and let's face it, who isn't looking for one?) I can totally recommend it!
Imagine my surprise, then, when I received an email about my purchase the other day. To be honest, I was a little concerned.
Opening the email was a pleasant surprise. Simply put, the email was a timely reminder about the fact that I should expect a certain payee on my credit card statement, telling me how much it was for, who the payee was and, especially, what the purchase was for.
Such a simple little thing, at the right moment, and there will no longer even be a second of doubt when I look at my statement. I loved it, and intend to do a similar thing as soon as I start selling online, too.
And for what it's worth, if you're looking for a tool to resize and place images into a texture map (and let's face it, who isn't looking for one?) I can totally recommend it!
Tuesday, January 29, 2013
How FLOSS Software Became More Easily Accepted at Work
This was a long time ago now, but it was at a time when things were really starting to get big in the place where open source / free software and the Internet collided. It was also the time that we were looking to replace our in-house built, desktop based, bug tracking system.
It wasn't great, but it did the job. Even so, I started looking at a web-based bug tracking system that just happened to be licensed under the GPL.
I understood the requirements that were on us. I knew what it meant for us to use and change the code, and I knew what our obligations were for doing so.
Even still, a few people had concerns and I wasn't able to persuade them that we were OK. I suggested that we run the license past our (very technical) legal guy: if he knew what we intended to do, he would also know what was expected of us. My theory was, if he approves the license for our use case, then who really could argue differently?
The use of the GPLed software was approved and we went on our way. If the story ended there, it wouldn't be much of a story, though.
As time went on, we found ourselves gravitating to software licensed under GPL. But why? Quite simply, we knew two things: (a) legal had approved it; and more importantly (b) because the GPL itself is copyrighted, the very fact that legal had already approved that license meant that we didn't have to worry about fine print anymore!
All of a sudden, we didn't have to wonder "does this randomly drawn license for this particular software package allow us to do what we want?" and we didn't need to get 're-approved' to use the GPL (assuming we stayed within the parameters that we were given to begin with).
It was a weight off of our shoulders: almost overnight, we were confident that our understanding of the license requirements was correct, as we knew exactly what that license represented. We no longer had to try and understand hundreds of lines of legal terminology... we'd already done that once!
As time went on, we got a better understanding of a few more licenses (especially LGPL and MIT) and with that, we were able to make better and faster decisions about the libraries of code that we were looking at using.
It all really came down to the simple fact that because the licenses we were looking at were themselves copyrighted, any project that claimed to be using that license was not going to have some strange 'twist' to the license.
Yes, there were the odd times that the project tried to add a rider to the license, but even then, we were no worse off as legal would have had to look at it anyway.
To cut a long story short, these licenses made our lives easier because we all knew what we were able to do without ever really having to specifically analyse the license, simply because we knew that it couldn't have been modified from what we already understood.
And that made us happy.
It wasn't great, but it did the job. Even so, I started looking at a web-based bug tracking system that just happened to be licensed under the GPL.
I understood the requirements that were on us. I knew what it meant for us to use and change the code, and I knew what our obligations were for doing so.
Even still, a few people had concerns and I wasn't able to persuade them that we were OK. I suggested that we run the license past our (very technical) legal guy: if he knew what we intended to do, he would also know what was expected of us. My theory was, if he approves the license for our use case, then who really could argue differently?
The use of the GPLed software was approved and we went on our way. If the story ended there, it wouldn't be much of a story, though.
As time went on, we found ourselves gravitating to software licensed under GPL. But why? Quite simply, we knew two things: (a) legal had approved it; and more importantly (b) because the GPL itself is copyrighted, the very fact that legal had already approved that license meant that we didn't have to worry about fine print anymore!
All of a sudden, we didn't have to wonder "does this randomly drawn license for this particular software package allow us to do what we want?" and we didn't need to get 're-approved' to use the GPL (assuming we stayed within the parameters that we were given to begin with).
It was a weight off of our shoulders: almost overnight, we were confident that our understanding of the license requirements was correct, as we knew exactly what that license represented. We no longer had to try and understand hundreds of lines of legal terminology... we'd already done that once!
As time went on, we got a better understanding of a few more licenses (especially LGPL and MIT) and with that, we were able to make better and faster decisions about the libraries of code that we were looking at using.
It all really came down to the simple fact that because the licenses we were looking at were themselves copyrighted, any project that claimed to be using that license was not going to have some strange 'twist' to the license.
Yes, there were the odd times that the project tried to add a rider to the license, but even then, we were no worse off as legal would have had to look at it anyway.
To cut a long story short, these licenses made our lives easier because we all knew what we were able to do without ever really having to specifically analyse the license, simply because we knew that it couldn't have been modified from what we already understood.
And that made us happy.
Friday, January 11, 2013
Where's Lad Vampire and Muguito When You Need Them?
Another week, another call from "Windows IT Support" trying to get me to download some malware. I do my best to keep them on the line for a few minutes at least, but all it does is upset me, which leads to me calling them names and then fuming for a bit :)
Artists Against 419 is an awesome site that maintains a database of fake bank sites. Along with actively reaching out to the hosting companies etc., trying to get them to take the sites offline, they also used to have an application called Lad Vampire that was (I believe) replaced by another application called Muguito. These applications participated in what were called "virtual sit-ins". Basically they continually downloaded images and so on from the websites, helping to diminish the available bandwidth to the site and therefore making it less likely that a victim will actually be able to use it.
Some people may call it a DDoS, and to be perfectly honest, I might too. It didn't stop me running it though.
After my last call with "random IT support company" I wondered: at some point in the process of them 'helping' you, there must be something downloaded from somewhere. I'm not talking about the remote access software, but the malware that is intended to run in the background.
So where is the list of the servers that are hosting these files and where's the tool to continually download them? Unfortunately I'll never have the self control to get far enough into one of those calls to find out, but I tell you right now: if there's one use of my fibre-op connection I could get behind, it's downloading that malware as often and as quickly as possible.
For what it's worth, I know that random three letter acronym agencies are trying to deal with these companies, but in the meantime, surely there's something else we can collectively do?
Artists Against 419 is an awesome site that maintains a database of fake bank sites. Along with actively reaching out to the hosting companies etc., trying to get them to take the sites offline, they also used to have an application called Lad Vampire that was (I believe) replaced by another application called Muguito. These applications participated in what were called "virtual sit-ins". Basically they continually downloaded images and so on from the websites, helping to diminish the available bandwidth to the site and therefore making it less likely that a victim will actually be able to use it.
Some people may call it a DDoS, and to be perfectly honest, I might too. It didn't stop me running it though.
After my last call with "random IT support company" I wondered: at some point in the process of them 'helping' you, there must be something downloaded from somewhere. I'm not talking about the remote access software, but the malware that is intended to run in the background.
So where is the list of the servers that are hosting these files and where's the tool to continually download them? Unfortunately I'll never have the self control to get far enough into one of those calls to find out, but I tell you right now: if there's one use of my fibre-op connection I could get behind, it's downloading that malware as often and as quickly as possible.
For what it's worth, I know that random three letter acronym agencies are trying to deal with these companies, but in the meantime, surely there's something else we can collectively do?
Subscribe to:
Posts (Atom)