Updates from February, 2008 Toggle Comment Threads | Keyboard Shortcuts

  • steve918 10:50 am on February 15, 2008 Permalink | Reply  

    Distributed Versioning – The new wheel 

    With all of the great distributed versioning tools out there it’s a wonder everyone is still using traditional client-server versioning systems like SVN or CVS. Especially when you consider how trivial distributed systems are to setup for small projects. Unless your hosting your SVN project with some one like Sourceforge, LaunchPad or Google Code, it is much easier with a system that doesn’t require you to setup a central repository. I know… “If it ain’t broke don’t fix it.”, but sometimes you don’t realize how broke something is until you’ve used something that’s… less broke.

    I’ve spent some time looking at several open-source distributed SCMs and the most prominent one’s from my point of view are the following:

    Each of the above SCMs are production ready distributed systems and have notable projects under their belts, but each one has properties that suit certain projects better than others, so I recommend doing some reasearch on your own because what works for me may not meet your needs.

    I typically work in a unix like environment from the command line, but I also collaborate with people who do not, therefore I tend to shy away from solutions that don’t function well on all platforms. For me this eliminated Darcs and Git from the start. Although both of the aforementioned SCM systems are feature rich and technically strong, their windows support is pretty dismal compared to the other competitors on the list.

    So for me the most appealing options are Bazaar (bzr) and Mercurial (hg). Both of these projects have strikingly similar offerings. The both have clients/plugins for Eclipse, Windows Explorer (Tortise__), and Trac. Both systems are written in Python and have a dependency on the Python libraries, but it is relatively easy to find binary installers for Python, Bazaar and Mercurial so if Python isn’t your thing, (Hard to imagine) it doesn’t really matter. Bazaar is used heavily by the company behind Ubuntu (Canonical) who is also responsible for Launchpad. Mercurial is used by several big-name projects such as Mozilla and OpenJDK. I’ve used both Bazaar and Mercurial for some small projects and for me Mercurial really stood out.

    For anyone looking for a distributed SVN replacement, I definitely recommend giving Mercurial a shot. Since they’ve updated their logo there’s no reason not to! Seriously though, Mercurial was an extremely painless transition for me. The user interface was extremely familiar and intuitive, has clients available for just about everything and was extremely painless to install and use. The fact that it just felt familiar coming from SVN to me and it is noticeably faster for most tasks than Bazaar put it at the top of my list.

  • steve918 11:54 pm on February 14, 2008 Permalink | Reply  

    Miami Here I come 

    I’ll be in Miami along with Kevin Fox, also from Vidoop, toward the end of the month for a couple of different events that should be a lot of fun. I’ll be catching BarCamp on the 28th followed by
    FOWA – Future of Web Apps. I can’t wait to geek out at all the events and see Miami.

  • steve918 1:15 pm on February 3, 2008 Permalink | Reply
    Tags: , Php, , , Rails, Ruby, Zend Framework   

    Framework Envy 

    I’m typically a PHP guy. I wrote my first web page using PHP3 and have created some pretty robust websites since then and for the most part it’s been a pleasure to work with. I also have a bit of experience using Zend Framework which among other things has a really strong MVC implementation, but I can’t help but feel a bit left behind when I look at features of some other modern frameworks. I’ve been playing around with Django for a few days and a few things have occurred to me.

    Validation logic should be part of the model

    Take a look at this bit of code from Django.

    # in visitor/models.py
    class Visitor(models.Model):
        name = models.CharField(maxlength=30)
        email = models.EmailField(maxlength=200,blank=true)
        website = models.URLField()
        donated = models.DecimalField(max_digits=5, decimal_places=2, blank=true)

    In the Zend_Validator is much more complex, typically happens in the controller and has no direct relationship with the data model your validating for.

    $nameValidator = new Zend_Validate_StringLength(1,30);
    $emailValidator = new Zend_Validate();
    $emailValidator->addValidator(new Zend_Validate_StringLength(0, 200))
                   ->addValidator(new Zend_Validate_EmailAddress());
    // Zend doesn't have a URL validation class, so we would have to
    // create a custom validator that extends Zend_Validate
    $website = new Custom_Validator();
    // This only validates that the number is a floating point number,
    // in reality we would probably have to write another custom validator
    // to validate monetary values.
    $donated = new Zend_Validate_Float();

    The nice thing about Django is the actual database tables are created from the model. So when you declare a name field with the maxlength of 30, your validation rules knows your fields max length because it’s based from the same one line of code the database field was created from! I’m not sure I believe building database tables from your model code is the only way to do things, but I am sure complex validation logic for models belongs in their implementation, not in the controller.

    Template inheritance rocks.

    This is sadly something I had never seen before. Instead of having half a dozen include statements in each of your views you can just have on that says that it extends your base template. The nice thing about this is the child view/template can override what ever portions of the base template it wants, or it can just go with what the parent has. Django’s documentation has a really good example of template inheritance in action.

    An auto generated admin interface is more valuable than gold.

    Before playing with Django I watched a few screen casts to get a feel for what it was all about. Then Django seemed like a one trick pony to me and the one trick seemed a bit lame. I mean, auto generated administration interface… who cares. Since then I’ve learned Django certainly has more than one trick up it’s sleeve and their main act is really beautiful in person. It is honestly as robust (or more so) as any administration interface I’ve built in the past. I expected something clunky and extremely _not_ user friendly. I really expected it to generate an admin interface that made it somewhat more convenient for programmers, but wouldn’t work for the average Joe. Well, when they say it’s “production ready” that’s exactly what they mean. The number of hours this saves (that can be spent developing fun stuff) is extremely valuable.

    Admin scripts

    I know this will sound a bit lazy, but I don’t like having to manually create half a dozen empty folders every time I set up a new project, controller etc. Rails and Django both do a good job of generating framework skeletons for you so you can plug away without missing a beat.

    Shell to poke at objects

    This is really a language feature and not a framework feature, but you can do some really sexy stuff inside the Django shell like insert a new visitor:

    >>> p = Visitor(name="Steven", website="http://steven.bitsetters.com")
    >>> p.save()

    Or select the last five blog posts

    >>> recent = BlogPosts.all()[:5]

    This makes it possible to stay in Python land forever if you wish. No bouncing around between SQL and Python.

    Built-in development servers make getting started fun

    There is nothing like spending half an hour setting up Apache and mod_* before writing your first line of code. Django and Rails bundle a lightweight web server who’s sole purpose is to make development easy and convenient. Unfortunately you won’t be seeing a bundled PHP based web server with your favorite PHP framework anytime soon. Try writing one and see how far you get without things like thread support. PHP is really more of a template language itself than a general purpose programming language. Projects like PHP-GTK make me giggle. Single threaded GUI applications are awsome! </sarcasm>

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc