- Visit at least one new country(I meant to make it somewhere else last year, instead I ended up in Australia again.)
- Renew Certified Scrum Practitioner certificate. Not really sure how much I value it, but it's cheap to renew and I'd like to try their shiny new test so I can have an opinion on it.
- Deal with my wrist related issues better. Got a few solutions for this, my current favorite is getting junior devs to write code while I sit with them and teach/dictate, this is great for my hands and also seems to work well for getting people up to speed quickly.
- More speaking and on more varied topics. I enjoy speaking so I shall do more of it and I need te break out of always doing tech focussed topics as what I do has become so much broader than that in the last couple of years.
- Read more books. I have a few target areas here: Finishing off the main business books that I still have to read, progressing my broader knowledge( particularly more science related reading this year I think), a decent amount of tech reading, more good fiction and less trashy fiction.
- Write More and regularly. My girlfriend has set out to do 500 words a day, I hope to match her totals but probably won't achieve the same regularity she will. Hopefully get up to at least five days a week though. Writing is something I'd like to develop into being more of a small regular habit than something I work at in bursts.
- Get down to less than 50 Films to go on the IMDB top 250. I've got 93 to go now and watched just under 50 last year so I basically have two years left before I've finished watching the majority of the films that are really good in the generally watched realm. It does miss a bunch of really good films that have only achieved smaller audiences, but in general it feels like an enriching experience and makes me appreciate all film a lot more. In the same way as you have te read quite a bit of classic literature before it all starts coming together and being enjoyable.
- Learn Clojure, I've always liked lisp and clojure is threatening to actually be moderately successful in the wider world.
- Automate more things. Both small tasks in my day to day life and business related stuff, there are things I do too often and haven't got around to automating. I want to find at least 6 tasks that I do regularly that I can make more automated. This could mean anything from automating basic new site setup to getting a better system for handling my expenses.
- Get some traction for at least one of the startups I'm involved in. Got few things in the pipeline and a couple of projects that are succeeding on the marketing front so long as the product arrives when it's looking like it should.
Technology and Cocktails
Breccan McLeod-Lundy's personal blog.
Wednesday, January 4, 2012
Goals for 2012
A short collection of my goals for 2012 - publicity helps with these things.
Tuesday, January 3, 2012
Some of My Achievements and Failures in 2011
Achievements
Failures
- Railscamp. Organising Railscamp took up quite a bit of time at the beginning of this year but it was worth it. Even better is that there are now lots of people in NZ wanting to help organise future ones. Including the one in Canterbury next month.
- Speaking. I spoke at various events covering everything from clouds and python to rails and node.js. It's been interesting making it to such different and I'm looking forward to further broadening what I attend and speak at in the coming year.
- Broadened my end to end business skills. By happenstance I took a couple of decently-sized projects right through from business development to final delivery. It's a lot of work but a really interesting experience to be able to manage client expectations through the entire process rather than building up a more piecemeal client relationship. Not a particularly scalable approach, but I enjoyed doing it and think I learned a lot about some of the areas of project leadership that I hadn't touched so much previously.
- Read some books that have been on my list for a while. 71 books in total with some great reads like Poor Economics and Bargaining for Advantage as well as some of the more serious books that took a long time to get through like Godel, Escher, Bach, and the Decline and Fall of the Roman Empire. My rato of non-fiction to fiction was a lot higher this year, mostly as I did a few big dives into topics that have plenty of easy to read books in them like negotiation practices or the broader coding styles books.
- Helped out and collected equity in various different startups. Involved myself in a number of various startups that are now in various states. In the end I came away with interests in four of them of which two are showing some level of growth. There was much learning to be had from this involvement and if any of them actually succeed it'll pay off well as well. Regardless, I'm happy for the experience and look forward to applying it to some other upcoming projects.
- Completed the stanford AI Class online course in the advanced track. Didn't put as much time into this as it deserved but I completed it and it reminded me how cool a lot of the more hardcore CS stuff is.
- Decent load of writing for Nanowrimo. Nanowrimo went pretty well this year as I started using dragon dictate to avoid the dangers of typing 50000 words in a month again. Not sure what I'll do with what I've written but will definitely spend the time to tidy it up.
- Improvisation - Ended up doing an improvisation course towards the end of the year and it turned out to be one of the highlights. I'll blog on it specifically sometime soon.
- Watched lots of really good films. I watched over 40 films from the IMDB top 250 films list as well as spending a lot of time at film festivals. I'm really enjoying watching good films, especially when the list forces me to watch things I otherwise might not. Many of the old films on the list are marvelous and there are some genres I hadn't watched that turned out to be excellent when viewing the best of them. Of particular surprise to me was how much I enjoyed most of the westerns on the list.
- Switched to dvorak. Switching to dvorak took slightly longer than I thought it would but it's going to pay off over time.
Failures
- Blogging. I didn't blog as much as I said I would. I hope to do better this year.
- RSI. I haven't dealt with the pain in my wrist as well as I should have, doing a slightly better job of things now though.
- Startups that didn't fly. Some of the startups I was involved in didn't go as well as they should have. To some degree this is expected with startups, but I'd still like them to be more sucessful. I'm starting to lean towards being more process oriented with them from the get go. The biggest issue I've seen cropping up in the ones that fail is expectation management and people thinking the path to product should be much shorter than it actually turns out to be. I either need to get better at holding these ones together or at identifying that issues are present and stopping investing time sooner.
- Failed to Travel anywhere new. I made it to Aussie a couple of times at least, but that's not very exciting.
Monday, November 7, 2011
Going From Zero to Revenue During Startup Weekend
This last weekend was filled with the first Startup Weekend Wellington. Well, it was for some competitors, for me it was a few hours getting a minimum viable product up and running, and then wandering around chatting to interesting people. I decided I liked sleeping.
With the site "done" early in the weekend I went back to talking to people and watching the money flow in. We managed to get a little over $200 in the bank by the end of the 52 hours and were, as far as I know, the only team to have any revenue inside of the weekend.
Unfortunately, by the time judging rolled around another lawerly type had opined that the space dream question wasn't enough for NZ law. So when a Judge asked, "Where is this legal?" our answer had become something like "We may need to move to Antigua".
Getting something from nothing to revenue in a couple of days was an entertaining experience and really drove home how little you need to do to get people to give you their credit card details. It was also a slightly addictive feeling as I got a little burst of pleasure whenever I got an email from someone with a new sale and their dreams about space. This is probably why dashboards are so good at motivating sales types.
The event itself was well run and gathered lots of great energy. The only issue being that there were other great events happening around the city at the same time. There were some particularly impressive showings coming out of the more serious teams such as winner's usnap.us, who put together a comparatively polished photo sharing app, and Auti who created a toy for autistic children that I really hope succeeds.
I started the weekend at a bit of a low ebb on energy after a busy week so I decided to join whatever team popped up with the easiest idea to implement. This ended up being "Space Lotto" an idea whose time had clearly come as it collected the most sticker votes in the initial round of sticker voting to pick ideas.
Our initial concern was legal issues. The first lawyer we spoke to said we would probably just need one of those simple sweepstakes questions so we added a requirement that entrants tell us why they wanted to go to space. This lead to one of the highlights of the weekend for me - receiving the following dream:
"Human expansion into space is both an aspirational goal that will inspire and enable innovation, and a necessary step in our evolution as a species. My dream is that we conquer the currently insurmountable distances in the same way we conquered those of the oceans. That this quest unifies the human race in common endeavour, beyond nation state, race and religious distinctions."For the site to run the competition I went with the lightweight "embed a paypal(not mine) taking Wufoo form into a basic Blogger template" approach. This took less than an hour with the majority of the time being doing a little fiddling with the layout. The same approach would have worked well for a number of other teams to get to revenue in the weekend, I somewhat regret not just wandering around and setting it up for some of them.
With the site "done" early in the weekend I went back to talking to people and watching the money flow in. We managed to get a little over $200 in the bank by the end of the 52 hours and were, as far as I know, the only team to have any revenue inside of the weekend.
Unfortunately, by the time judging rolled around another lawerly type had opined that the space dream question wasn't enough for NZ law. So when a Judge asked, "Where is this legal?" our answer had become something like "We may need to move to Antigua".
Getting something from nothing to revenue in a couple of days was an entertaining experience and really drove home how little you need to do to get people to give you their credit card details. It was also a slightly addictive feeling as I got a little burst of pleasure whenever I got an email from someone with a new sale and their dreams about space. This is probably why dashboards are so good at motivating sales types.
The event itself was well run and gathered lots of great energy. The only issue being that there were other great events happening around the city at the same time. There were some particularly impressive showings coming out of the more serious teams such as winner's usnap.us, who put together a comparatively polished photo sharing app, and Auti who created a toy for autistic children that I really hope succeeds.
Sunday, August 28, 2011
A Rubyist visits Kiwi Pycon
It's an interesting experience going to a python conference for me, particularly when I was speaking at it as well. I have done some Python, but I'm mainly a Ruby person, which made there being something of a competition going on between the two, at least in the minds of some of the practitioners, all the more entertaining.
It feels very reminiscent of the Emacs VS Vim debate, the languages are so similar that it's really a bit ridiculous the comments that get flung back and forth on occasion. It seems to be the Pythonistas declaiming Ruby though, as I don't notice Rubyists really commenting on python. Apparently the Python people still think ruby is all monkey-patching and crazed metaprogramming, something that I think Ruby has managed to outgrow over the last few years as more people realise it's a bad idea.
Coming out of Kiwi Pycon I think the best thing to do would be for the languages to steal more ideas from each other, they're so similar in capabilities that things seem to transition back and forth very nicely. The web programming talks at Pycon seemed to be lagging about a year and a half behind Ruby in terms of what the new cool thing is, while the more sciencey areas are still where Python is dominant.
Audrey Roy's talk really reminded me of how strong Ruby has become in terms of deployment tools, from capistrano to Chef and Puppet we have some really powerful and well built tools. Unfortunately they're not making their way into Python land as well as they should due to a certain amount of resistance to the language. I hope more python people will try them out though, as they really are very good and it's not the kind of tool where it really matters what language it's in.
I got to hang out with Mark Ramm, who is currently tasked with restoring Sourceforge to its former glory, for a few hours on Friday night and he was a fascinating guy. It sounds like there has been some really good development happening over there in the last few years in terms of building up to being a toolset that really empowers open source. Mark also gave some of the best talks of the conference including an excellent session where he powered on despite the departure of his laptop from the realms of the living.
My talk on the clouds went pretty well. It was a lot higher level than the other talks that had happened so far with only a couple of slides of code. The other morning talks had seemed to follow an "All Code. All The Time" policy and I was a little worried that I'd missed the level of the event, but then there were a bunch more higher level talks later on. I got a decent amount of positive feedback and one guy who came up, looked slightly disappointed, and said, "I thought there would be more python". On balance, I'm pretty happy with that.
I ended up busting out my recently purchased remote for my presentation and also lent it out a couple of times as there wasn't one supplied, which was probably a slight oversight as I think that the speakers using it were able to give much better talks. After borrowing it, Eric Light said it was his first time speaking like this and then proceeded to give a very slick talk on all the ways he managed to screw up contracting out a web development job.
Overall, it was a well run conference and attracted an impressive number of people for a language specific event in NZ and the organisers have my congratulations. I really enjoyed the chance to hear a lot about all the cool but slightly different things that are happening over in python land and I didn't feel like I was hearing mostly things I already knew like I have with some of the more broad conferences I've attended recently. I would have liked slightly more coffee vouchers.
It feels very reminiscent of the Emacs VS Vim debate, the languages are so similar that it's really a bit ridiculous the comments that get flung back and forth on occasion. It seems to be the Pythonistas declaiming Ruby though, as I don't notice Rubyists really commenting on python. Apparently the Python people still think ruby is all monkey-patching and crazed metaprogramming, something that I think Ruby has managed to outgrow over the last few years as more people realise it's a bad idea.
Coming out of Kiwi Pycon I think the best thing to do would be for the languages to steal more ideas from each other, they're so similar in capabilities that things seem to transition back and forth very nicely. The web programming talks at Pycon seemed to be lagging about a year and a half behind Ruby in terms of what the new cool thing is, while the more sciencey areas are still where Python is dominant.
Audrey Roy's talk really reminded me of how strong Ruby has become in terms of deployment tools, from capistrano to Chef and Puppet we have some really powerful and well built tools. Unfortunately they're not making their way into Python land as well as they should due to a certain amount of resistance to the language. I hope more python people will try them out though, as they really are very good and it's not the kind of tool where it really matters what language it's in.
I got to hang out with Mark Ramm, who is currently tasked with restoring Sourceforge to its former glory, for a few hours on Friday night and he was a fascinating guy. It sounds like there has been some really good development happening over there in the last few years in terms of building up to being a toolset that really empowers open source. Mark also gave some of the best talks of the conference including an excellent session where he powered on despite the departure of his laptop from the realms of the living.
My talk on the clouds went pretty well. It was a lot higher level than the other talks that had happened so far with only a couple of slides of code. The other morning talks had seemed to follow an "All Code. All The Time" policy and I was a little worried that I'd missed the level of the event, but then there were a bunch more higher level talks later on. I got a decent amount of positive feedback and one guy who came up, looked slightly disappointed, and said, "I thought there would be more python". On balance, I'm pretty happy with that.
I ended up busting out my recently purchased remote for my presentation and also lent it out a couple of times as there wasn't one supplied, which was probably a slight oversight as I think that the speakers using it were able to give much better talks. After borrowing it, Eric Light said it was his first time speaking like this and then proceeded to give a very slick talk on all the ways he managed to screw up contracting out a web development job.
Overall, it was a well run conference and attracted an impressive number of people for a language specific event in NZ and the organisers have my congratulations. I really enjoyed the chance to hear a lot about all the cool but slightly different things that are happening over in python land and I didn't feel like I was hearing mostly things I already knew like I have with some of the more broad conferences I've attended recently. I would have liked slightly more coffee vouchers.
Sunday, August 7, 2011
Website Launch Checklist
Launch day is one of the scariest and most stressful times in web development. Getting everyone on the same page in terms of what's going to happen and when it's going to happen goes a long way in making the entire process smoother.
Things are less likely to go wrong and people are less likely to start throwing recriminations around if the processes for deployment and dealing with issues are well documented.
The following is a list I've been building up in my notes of some of the things that should be done in preparation for launching a new site or major revamp.
Client/Product Owner
Server Setup
Things are less likely to go wrong and people are less likely to start throwing recriminations around if the processes for deployment and dealing with issues are well documented.
The following is a list I've been building up in my notes of some of the things that should be done in preparation for launching a new site or major revamp.
Client/Product Owner
- Site and content has been signed off by appropriate people.
- Any potential downtime and exact release times have been confirmed and communicated to everyone involved. Involved means everything from developers to people in marketing who organised that snazzy TV promo.
- Everyone knows who's in charge of what and where notifications need to go for any immediate problems. This process is organised with designated communication points so that the deployment team don't get flooded with notifications if things go wrong.
Look and Feel
- Images have appropriate Alt Text for both accessibility and SEO.
- Pages have sensible Titles.
- Pages have Appropriate Meta Tags.
- Favicon is in place.
- Friendly error pages, particular 404 and 500 error pages.
- Contact Us page has appropriate details.
- Copyright info is in place.
- Someone has gone through checking for spelling and grammar errors etc.
- At least some manual testing has occurred to catch any outstanding issues, e.g., weird edge cases or black text on a black background.
Server Setup
- Backups are running at appropriate intervals and the steps that are needed to recover using them are documented.
- Transfer DNS at an appropriate time. Make sure something is in place to handle delays in propagation.
- The "www." subdomain is redirecting appropriately, or the reverse if you prefer www. domains
- Monitoring service is checking site uptime (Pingdom or similar).
- Something is capturing application errors and reporting them (A service like Airbrake or something better than the default system logging).
- Deployment process is automated, fast and takes one click or command. You need to be rolling out quickly and any fixes need to be able to go out fast and reliably as well.
- Set up resource monitoring (Munin or similar).
- Make sure the site comes back up after power cuts/crashes.
- Penetration testing if necessary. Level of security testing should be agreed well before launch as it will affect release schedules.
Dev Tasks
- Analytics are in place.
- Larger sites have a sitemap.xml for bots to read.
- Automated tests are in place. The level of automated testing being used should have been decided early in the project.
- Testing has occurred across browsers that are being supported. Browser support decisions should have been made at the beginning of the project.
- Devs know what the expected release load will be and they have resources in place to handle it.
- The site should be load tested for the expected load. At the very least, it should be checked with reasonable load for any performance anomalies.
- Set up a robots.txt
- Run a website performance tool such as Yslow over the site.
Other Tasks
- Put a catch-all email address on the domain.
- Wrap-Up and review meeting with the team.
- Write a case study and/or take some pictures to add the site to your profile.
- Party
Did I miss anything? Leave a comment and tell me about it.
Monday, May 23, 2011
Reading The Four Steps to the Epiphany
Steve Blank's the four steps to the epiphany
has established itself pretty solidly on the must-read list for entrepreneurs. It's also one of the hardest books in the space to read. Where other authors have spent their time creating pithy lists and easy to apply snippets of information, Steve has written a book that is dense and not particularly suited to skimming.
As a book there are all sorts of problems with it: it's self-published in a somewhat inconvenient format, the proof reading is poor, the writing hasn't had a fine tooth applied to it and organisation is such that while sections may be possible to read on their own you'll often miss something that Steve had defined separately in another section. However, the book is full of really good information backed up by a huge amount of experience and good reasoning. That's why so many start-up people who have read the book recommend it so highly, it talks about the things they do or have done in a practical fashion that's easy to compare to your own endeavors if you can grasp the ideas.
It's a book that gets easier to read the more time you've spent around start-ups as you start to recognize the occurrences presented in it more easily. But that isn't when it's best to be reading it, you'll get the most benefit by reading it as soon as you possibly can so that you can better recognize the situations it applies to in your company when you hit those problems the first time. Entirely too many people premise their opinion of the book with "I wish I'd read this before my first startup" and entirely too many people say something along the lines of "The first time I picked this book up I put it back down again".
One of the central and most valuable themes of the book is the idea of market type. Are you in a new, re-segmented or existing market? Many of the sections of the book are broken down into shorter pieces dealing with each market type for that topic. For example, Steve suggests you should enter an existing market with with a direct assault of marketing while a new market requires a much slower grass roots process of convincing people they need the solution at all.
The breakdown of market types is great and covers a wide variety of differences in how you should work in different markets. Unfortunately, it also encourages a mistake when reading the book, which is to skip the sections of the book that don't relate to the particular products you're involved in. The book hasn't been written to allow for that though, these small sections remain closely intertwined. When the book examines business development for the first time it defines it in a section regarding existing markets, but it then assumes it for the other markets when it talks abou them.
There are two sets of ideas to focus on in the book: the iterative customer focussed portion of the customer development model and the collection of smaller topics that appear throughout the book when there's some particular thing that Steve points out.
The basic customer development model relies on: iteration, metrics and feedback. Throughout the book the models of finding customers and then improving your relationships with them come back to this pattern. Talking to people, recording their responses in a way that aligns with what you business needs to achieve and then updating how you're talking to them and what you're talking to them about until you feel comfortable at that stage. In the early stages of the startup talking means finding out if they like your ideas and respond positively, in later stages it means generating sales at appropriate cost.
If all you get out of the book is taking an iterative approach to each stage and measuring it then you've easily got your money's worth. But there's a lot more in there, everything from pre-tested strategies for dealing with various types of enterprise sales to working out if you're CEO is still the right fit when you go from startup to business. Indeed, the last chapter covers the rocky time that comes when you find yourself growing past the size that the entrepreneur can control everything and how that can be managed.
If the thought of reading the whole thing is still too daunting then perhaps the best choice is to only read chapters as you start approaching the stage that they talk about in the company. You'd be better off reading it all at once, but you'll get a lot of value out of reading the relevant bits as well. In addition, Steve suggests that a good mental task is to think about what your competitors are or could be doing, so if they're at a different stage read up on what they're likely to be facing as well.
This book isn't an easy read, but it is a valuable one. No matter how hard a book is to read, if it can make the difference between learning some of this stuff by reading versus learning it by having a startup fail then reading is the much more pleasant option. This book is definitely in that category.
As a book there are all sorts of problems with it: it's self-published in a somewhat inconvenient format, the proof reading is poor, the writing hasn't had a fine tooth applied to it and organisation is such that while sections may be possible to read on their own you'll often miss something that Steve had defined separately in another section. However, the book is full of really good information backed up by a huge amount of experience and good reasoning. That's why so many start-up people who have read the book recommend it so highly, it talks about the things they do or have done in a practical fashion that's easy to compare to your own endeavors if you can grasp the ideas.
It's a book that gets easier to read the more time you've spent around start-ups as you start to recognize the occurrences presented in it more easily. But that isn't when it's best to be reading it, you'll get the most benefit by reading it as soon as you possibly can so that you can better recognize the situations it applies to in your company when you hit those problems the first time. Entirely too many people premise their opinion of the book with "I wish I'd read this before my first startup" and entirely too many people say something along the lines of "The first time I picked this book up I put it back down again".
One of the central and most valuable themes of the book is the idea of market type. Are you in a new, re-segmented or existing market? Many of the sections of the book are broken down into shorter pieces dealing with each market type for that topic. For example, Steve suggests you should enter an existing market with with a direct assault of marketing while a new market requires a much slower grass roots process of convincing people they need the solution at all.
The breakdown of market types is great and covers a wide variety of differences in how you should work in different markets. Unfortunately, it also encourages a mistake when reading the book, which is to skip the sections of the book that don't relate to the particular products you're involved in. The book hasn't been written to allow for that though, these small sections remain closely intertwined. When the book examines business development for the first time it defines it in a section regarding existing markets, but it then assumes it for the other markets when it talks abou them.
There are two sets of ideas to focus on in the book: the iterative customer focussed portion of the customer development model and the collection of smaller topics that appear throughout the book when there's some particular thing that Steve points out.
The basic customer development model relies on: iteration, metrics and feedback. Throughout the book the models of finding customers and then improving your relationships with them come back to this pattern. Talking to people, recording their responses in a way that aligns with what you business needs to achieve and then updating how you're talking to them and what you're talking to them about until you feel comfortable at that stage. In the early stages of the startup talking means finding out if they like your ideas and respond positively, in later stages it means generating sales at appropriate cost.
If all you get out of the book is taking an iterative approach to each stage and measuring it then you've easily got your money's worth. But there's a lot more in there, everything from pre-tested strategies for dealing with various types of enterprise sales to working out if you're CEO is still the right fit when you go from startup to business. Indeed, the last chapter covers the rocky time that comes when you find yourself growing past the size that the entrepreneur can control everything and how that can be managed.
If the thought of reading the whole thing is still too daunting then perhaps the best choice is to only read chapters as you start approaching the stage that they talk about in the company. You'd be better off reading it all at once, but you'll get a lot of value out of reading the relevant bits as well. In addition, Steve suggests that a good mental task is to think about what your competitors are or could be doing, so if they're at a different stage read up on what they're likely to be facing as well.
This book isn't an easy read, but it is a valuable one. No matter how hard a book is to read, if it can make the difference between learning some of this stuff by reading versus learning it by having a startup fail then reading is the much more pleasant option. This book is definitely in that category.
Friday, May 6, 2011
Code School's Rails Best Practices Review
The guys at Envy Labs have created a really great new set of learning materials over at Code School.
I've been teaching some people Rails recently and sitting them down in front of Rails for Zombies really worked for them. The idea of mixing short screencasts with convenient practical exercises has been a great way of teaching and the web based format is really quite slick.
I wanted to try out some of their stuff myself so I went and bought their Rails Best Practices course. Honestly, the course was a little bit too easy for me, but it was something I wished had existed a couple of years ago when I was just picking up little Rails idioms here and there.
Inside of this, the format of very dense screen-casts with quick practical excercises meant that the familiar stuff didn't really get in the way and bore me like a slower intro would have. Overall the full run through took less than two hours effort, while I know newer devs would probably find themselves skipping back and forth between the exercises and the videos.
While I knew most of it there were a few small things that for some reason I wasn't familiar with. The .presence method for example is a little thing that is easy to miss but has quickly made its way into my everyday coding after having seen it. The usage of delegate is something that I hadn't really been familiar with beforehand but now really like. A couple of other things were also new to me but don't seem so helpful, Memoizable and Nested Layouts come more under this heading.
The only drawback of the whole thing is the price really. If you're already confident that you've been reading widely on ruby then it might not be quite as worthwhile. But, I wish something like this had existed a few years ago when I was just starting to get deeper into rails. It would have saved me a lot of time. They're also giving away a free Peepcode screencast when you finish now which it a little nicer. There's no shortage of decent Peepcode videos that are worth purchasing after all.
The thing I'm most excited about is what they're going to do with this platform in the future. It really is a great system and something that I intend to get anyone I come across wanting to learn something to sit down in front of. I'm particularly looking forward to some frontend devs I know sitting down in front of their upcoming Jquery course.
I've been teaching some people Rails recently and sitting them down in front of Rails for Zombies really worked for them. The idea of mixing short screencasts with convenient practical exercises has been a great way of teaching and the web based format is really quite slick.
I wanted to try out some of their stuff myself so I went and bought their Rails Best Practices course. Honestly, the course was a little bit too easy for me, but it was something I wished had existed a couple of years ago when I was just picking up little Rails idioms here and there.
Inside of this, the format of very dense screen-casts with quick practical excercises meant that the familiar stuff didn't really get in the way and bore me like a slower intro would have. Overall the full run through took less than two hours effort, while I know newer devs would probably find themselves skipping back and forth between the exercises and the videos.
While I knew most of it there were a few small things that for some reason I wasn't familiar with. The .presence method for example is a little thing that is easy to miss but has quickly made its way into my everyday coding after having seen it. The usage of delegate is something that I hadn't really been familiar with beforehand but now really like. A couple of other things were also new to me but don't seem so helpful, Memoizable and Nested Layouts come more under this heading.
The only drawback of the whole thing is the price really. If you're already confident that you've been reading widely on ruby then it might not be quite as worthwhile. But, I wish something like this had existed a few years ago when I was just starting to get deeper into rails. It would have saved me a lot of time. They're also giving away a free Peepcode screencast when you finish now which it a little nicer. There's no shortage of decent Peepcode videos that are worth purchasing after all.
The thing I'm most excited about is what they're going to do with this platform in the future. It really is a great system and something that I intend to get anyone I come across wanting to learn something to sit down in front of. I'm particularly looking forward to some frontend devs I know sitting down in front of their upcoming Jquery course.
Subscribe to:
Posts (Atom)