First post!
For the company blog that is.
With my luck, my byline will be truncated in the wrong place by search engines, and searches for my name would turn up “charged multiple times [dot dot dot]” instead of “charged multiple times with method_missing abuse”.
Hi guys,
Love your stuff, really. Engaging visual, audio, and tactile senses1 (typing code, writing notes) at the same time is an excellent way of picking up new skills.
If it is not too much to ask, for longer screencasts could you put a simple Table of Contents within the first few seconds of the video? Something like
1. Has-many associations - 01:59
2. Polymorphic associations - 04:03Sometimes when I’m trying to recall the exact implementation details of something I go back to your videos, and I have to skip about to find it. It would be easier to drag the slider to the time value given by a handy TOC.
I think this is probably something relatively straightforward to do (compared to the huge amounts of work you are already putting in!) and will greatly increase value for your consumers.
Thanks. You guys rock.
Best,
Tim.
UPDATE: PeepCode has some screencasts with Quicktime chapter tracks , and will be including chapter tracks with other screencasts in the future.
1 Just a thought when it comes to engaging senses and learning/coding. I think it would be hilarious to have a device that literally emits a bad smell anytime you’re writing bad code. That may be difficult to identify, but stuff like using deprecated functions, having too much logic in views, etc can all be detected programmatically. Just imagine, you could walk past someone’s desk and be like “Ugh! That’s some nasty code you’re writing today”.
Working off the trunk of an open source project may seem scary because of all the uncertainties, but my experiences with Django and Rails tell me that this isn’t a matter of choice.
Well actually it is. If you want your project to be maintainable in the future, you have to keep up with the trunk of your framework. If not, then go ahead and pick a version to fix your project on. There you go, who said there aren’t any choices?
Quick aside: I don’t recall the latest Django trunk having an exciting “Gen-X PR-type” name1, so let’s call it “Django Axe2” (because Django is named after a guitarist, etcetc).
Of course I don’t mean that you update whenever Edge/Axe do. But you should do so frequently – once every week or two. While I haven’t been hit with this problem (because my projects actively keep up with Axe/Edge), I can tell from the changesets in both trunks that updating even 100 revisions can sometimes be very tedious.
This is because both frameworks are highly moving targets, with huge swaths of changes coming between versions. Axe recently had the entire Unicode branch merged, and Rails, well a look at the conversation thread here will give an idea of the magnitude of difference between stable and Edge.
What’s more, Django and Rails aren’t standalone projects – they are an entire ecosystem of common apps and plug-ins. And you can bet the most popular ones are going to move to follow Axe/Edge, so those components of your apps are going to be legacy as well.
Okay you say, but the reverse is true as well – what if you are relying on a plug-in that hasn’t upgraded? Well the responsible thing to do in that case is to get that upgrade done yourself, and contribute back. Chances of this happening are not that high unless you’re using something obscure, since most plug-ins for Django and Rails get a lot of love from users of their frameworks.
The consequences of not keeping up with a moving open source target are a lack of flexibility if you’re lucky, and extreme inefficiency if you aren’t:
While these projects have many instances of successful deployments, they are not without bugs. If one of these bugs suddenly surfaces in your project, you’re going to have to manually patch your version of the framework’s code. This may be fine the first, second, or third time. But keep going at it and the framework code you’re running on becomes a mess of custom backports.
And as time goes on, it becomes harder and harder to make such selective changes, since bugfix X relies on changeset Y, which depends on changeset Z, and so on. You will find yourself climbing up the dependency ladder each time you’re making a change. Soon you realize that the time you saved by not keeping up to date is far less than the time you’re expending to keep your Goldbergian series of patches intact.
Say you have to roll-out a version of your Django site supporting other languages. If your Django code is close enough to the Unicode branch, you’ll have a much less painful time upgrading and fixing any issues that come about. Or your manager/client reads all the hype about OpenID, and you suddenly find yourself needing the OpenID plug-in that relies on Revision X. If you’re a thousand revisions behind, have fun upgrading. Or ignore the plug-in, roll your own, and pat yourself on the back. Neither way is as optimal as keeping up in the first place.
I understand that others may have been burned before by projects which had broken stuff in trunk that went unfixed for a long time. The conventional wisdom is to go with a stable release version.
But despite their disclaimers, Django and Rails generally take very good care of their trunks. I don’t think there is too much to worry about here. Plus you can always rollback a changeset or two if breakage occurs – I’m not saying you need every revision the moment it shows up on svn.
It may be a very tired analogy, but think of the time you spend every week or so updating your project to work on the latest framework code as stashing part of your salary away monthly. It gives you security, flexibility, and reduces your project risk.
1 Django doesn’t have a book with a skateboarder on the cover either.
2 Let’s see if lil ol’ me can start a meme.
I use Python with the Django framework at work, and I enjoy working with them. Django really simplifies development, and has some excellent sites built using it: have a look at Naples News Online and Lawrence.com
So when it came to putting this blog up, the first thought that came to my mind was “Ok, I’ll spend a couple hours putting up something basic with Django, and I can then add to it as I go along.”
Yep, trust my first instinct to be the most lazy time-saving one.
Then I realized that this option was just too easy. Having built an entire CMS with Django recently, I would learn nothing new by doing a simple blog with it.
So I decided this was an excellent chance to learn Ruby and RoR. I’d be killing two birds with one stone: diversifying my knowledge portfolio within the area of web development, and sating my intellectual curiosity as to why Rails has exploded over the past year or so.
Seemed simple enough. Checked out the Pickaxe book from my company library, and got the seminal Rails book too. Went through the tutorial, and subsequently put together a bare-bones blog app (sans a decent template and styling) in around half an hour.
Yes, that’s not a typo. Neither am I exaggerating. Rails is simply that fast. Bear in mind we’re talking bare minimum here—all my app was at that point was a simple wrapper around a BlogEntry model with Title, Body, and CreatedAt fields. But I could perform basic CRUD on it and have the results immediately reflected live. A minimalist blog I suppose. Django would be slightly slower, because it eschews the script/generate “magic” of Rails1.
Alright, there’s enough praise and hyperbole about Rails out there. No point adding my voice to the choir.
Anyway, from that base I planned to slowly bake in basic features like comments, tags, etc.
That’s when Captain Obvious paid me a visit saying, “You do realize that what you’re doing is a classic example of NIH syndrome.” I then realized that I could learn about Rails faster by using one of the blog platforms out there built on Rails and contributing back to it, instead of reinventing the wheel as I originally planned.
In the end I went with Typo. Not because I find it hilarious to have a blog that is “Typo Powered2”. And I did this despite the fact that their Trac page was down (and is still down) due to spam issues. Despite the fact its developers go by the rather dubious name of Leetsoft3. Despite the fact that Steve Yegge crucified Typo for its lack of documentation and difficulty of installation. I did find it easy to set up though, thanks to an excellent tutorial I found.
I initially chose Typo because it seemed to be the blog of choice for people playing around with Rails. I’ve stayed with it because its been a blast to use so far, despite the occasional bug I run into (which I could help with or at least look up if their Trac was up!) Lacks the polish of Wordpress et al, but makes up for it with some very nice glitz.
Thus for now, this blog is Typo Powered. It took me a long time to settle on an option—I went from self-built Django to self-built Rails to Typo, but I’m glad I took my time making a decision.
1 I’ll cover ideological differences between Django and Rails in the future when I’m more familiar with the latter.
2 I do find it hilarious, but that’s definitely not the basis of my decision-making.
3 OMGWTFBBQpewpew j00 lam3rz, everyone knowz its spelled as “l33t”!!!111one
