1. How to upgrade nodejs on your no.de smartmachine

    So you have a brand new Joyent no.de smartmachine, with a really old version of nodejs? Here’s how to upgrade it to a newer version of nodejs.

    Upgrade packages

    Ensure that you have the latest compiler, etc.

    pkgin update
    pkgin upgrade
    

    Build nodejs

    Refer to https://github.com/joyent/node/wiki/Installation for the details. Here’s how I compiled it on my smartmachine:

    ssh node@yourmachine.no.de
    git clone --depth 1 git://github.com/joyent/node.git
    cd node
    

    Select a version - v0.6.7 was the latest at the time of writing:

    VERSION=v0.6.7
    git checkout $VERSION
    

    Compile and install to ~/local/…

    ./configure --prefix=~/local/$VERSION
    make
    make install
    

    Change the nodejs symlink

    Your smartmachine has a symlink that points to the current node installation. This is the version that is used when you ssh in. Derived from: http://wiki.joyent.com/display/node/Setting+the+Node.js+Version

    cd ~/local
    mv --no-target-directory nodejs nodejs-old
    ln -s $VERSION nodejs
    hash -r
    

    Change the node service symlink

    Run this command as root.

    ssh root@yourmachine.no.de
    cd /opt/nodejs
    VERSION=v0.6.7    # Yes, substitute this with your version again
    ln -s ~node/local/$VERSION $VERSION
    

    Version check

    ssh node@yourmachine.no.de
    node -v
    npm -v
    

    Revert if something blew up

    cd ~/local
    mv --no-target-directory nodejs-old nodejs
    

    Otherwise!

    You’re done

  2. Apple just doesn’t get sync. Sync is hard to get right - especially in the user interface department. Dropbox gets sync because it’s able to simplify away the interface. Magic.

    Apple just doesn’t get sync. Sync is hard to get right - especially in the user interface department. Dropbox gets sync because it’s able to simplify away the interface. Magic.

  3. A tasty finish (or a start!)

    After reading the essay titled ‘Just say “No” to the Pet Project’ in The Developer’s code, I’ve decided it’s now or never! I just have to constrain my pet project, and launch! Otherwise it’ll never see the light of any smiling faces. So there you go - I will bring you TastyFinish.com early 2012.

    Here’s an extract from The Developer’s code by Ka Wai Cheung. Highly recommended.

    Every one of us has a pet project archive. Software we started and saw part of the way through, but never quite finished. Code that began strong but came to a screeching halt because more pressing issues came up. Other work got in the way, or, we simply lost interest.

    Pet projects fail when there are no time constraints and nothing’s on the line if we don’t succeed. When a launch date is “one of these days” we likely won’t be finishing it anytime soon. Some of us seem to spend years mulling over that next great idea instead of first deciding on a specific amount of time to build it. 

  4. Proprietary Legacy doublespeak

    You know you’ve been had when a vendor starts telling you to stop using proprietary software, and use their open software instead.

    You know you’ve been had when they call your existing working living breathing system a legacy so they can sell you their unproven flash in the pan technology. Not withstanding the fact that you did adopt their previous flash in the pan technology that is now your legacy.

    So I knew it was time to throw up when I received an invitation to a webinar from Redhat touting “Now, using Java EE can be even simpler than using proprietary legacy frameworks such as Spring Framework, and take much less time.

    Can’t they see that no one cares about the old open Java vs proprietary software talk anymore. The whole reason for the widespread adoption of Spring was that it just worked. Let me repeat that - it just worked. It’s a product made to serve you the developer. Not a standard made to serve the vendors. All the previous multi-vendor ivory tower J2EE standards were not products. They weren’t usable. You couldn’t read the standards and use them. You had to use a bad product that didn’t care about solving your problems, but about adhering to a straw man standard. Unlike Springframework or even Grails which are usable products, borne out of the need to solve real problems for real developers.

    I bet they were just trolling.

  5. The Myth of the Genius Programmer - Quite possibly my all time favourite talk about collaborative software development.

    Fact: Nearly all widely used software is developed by teams.

    Fact: Most programmers have fantasies of developing something innovative and new all by themselves.

    *Boom*

    Let go of your ego, and become a small fish in your pond and learn how to be a great developer by watching this talk.

  6. JS1k, 1k Javascript demo contest →

    You can learn so much about Javascript by just viewing the source of these demos

  7. Man vs Ocean

    I just watched Bear Grylls of Man vs Wild launch off a remote Hawaiian island on a handmade bamboo raft straight into a couple of tiger sharks. Wow! This episode was much more real for me than any other. I’ve been stranded while windsurfing for hours at a time with my energy sapped away by the elements and so I know how tough it is to just be out there with the winds, the waves and the creatures all conspiring against you. I completely expected Bear to give up and call in the helicopter after a few hours. Instead he drank the spinal fluid of fish he caught with Hibiscus twine, smeared his face with coconut oil he had prepared earlier by climbing a coconut tree, and stared down the tiger sharks who tried to bump him off his rickety raft, and finally attracted a sailboat by reflecting the sun off his knife. I think I’ve just found my next hero after Steve Irvin. Respect.

  8. Riiiiight!

    Riiiiight!

  9. Hello new world

    I’m getting a lot of satisfaction from my work these days. It’s a great feeling coding in the zone.

  10. Functional + NoSQL == *HOT*

    Dave Thomas was in town stirring up all the geeks with his talk titled “Why Real Developers Embrace Functional Programming and NoSQL Data”. I had a great time meeting some old friends, and hearing Dave cut through the crowd with the sharp tongue that he has.

    His central message was to never stop learning.

     
    We’ve become a monoculture of object oriented programmers living in a world of relational databases. Remember the horrors of EJB’s persistence layer? Well, even Rails’ ActiveRecord is just a slicker version of the same nonsense. The object-relational impedance mismatch was never breached. Same old layers of icing on the same old shit.
     
    And he doesn’t like frameworks very much either. Layer upon layer upon… you get the idea :-)
     
    If you’re still maintaining the status quo of Relational databases and Object Oriented languages, Dave would like to remind you that you’ve turned into a row farmer :-)
     
    So what do we do? He argued that we should look at the shinier side of functional programming which has famously had lower KLOCs, and the now blinding presence of all the NoSQL databases which are more flexible and perhaps better suited to your problem domain.
     
    I swear I never want to write another many-to-many join table with composite keys. Sign me up :-)
     

  11. Software art is engineering?

    Dr. Ivar Jacobson the god father of software components has lofty goals. He admitted being embarrassed by them last year, but now he’s quite proud and loud about them. He was in Melbourne today talking about his latest meta-methodology SEMAT (Software Engineering Method and Theory).

    I’m one of those ‘computer programming is an art, so don’t sully it with engineering’ kind of guy. So I attended Dr. Ivar Jacobson’s talk with trepidation.
     
    Ivar noted that software engineering today is like the fashion industry. There are waves of process fashions that wash through the industry every 5 or so years. There was structured programming before I even started programming - then it faded. Object Oriented Design was really big while I was at university - then it faded. XP was strong during my early career - now it’s gone. UML, CMMI, RUP - aaargh! And now everyone’s disillusioned or frantically becoming a scrum master.
     
    The situation reminded me of something Dr. Karl Kruzentiski once said on TripleJ - if there is more than one explanation for something, it’s likely that they are all wrong!
     
    The reality is that software development is differs from industry to industry - and you need to pick a methodology that works best for you. There really can’t be a theory of everything because it’s the wrong question to ask. Enterprise development is very different to game development. Game development is very different to embedded systems development. Ivar really didn’t address this dichotomy at all, so I was a bit disappointed there. This blog post talks about more deficiencies of SEMAT: http://catenary.wordpress.com/2009/11/29/against-semat/
     
    Ivar wants to bring together the Industry, Academics, Methodologists, and Developers. They rarely see eye to eye on software engineering processes.
    • Academics don’t understand the needs of industry. They have no practical experience within industry, so they pick a processes such as XP or Scrum to teach without a real need to use them themselves. Or they claim they are too proud to teach any methodology!
    • Industry is wrapped up in many processes because they have a real need for them to deliver useful software. However, they aren’t able to scientifically compare and choose processes - thus there are fads.
    • Developers want to become experts in their domain, but find themselves lost every time they change jobs and have to re-learn a new process
    • Methodologists have been prolific in creating fads, but have been unable to compare their methodologies in scientific terms.


    To help them see eye to eye, Ivar has called to action some of the big names of the software engineering world who have created processes such as RUP, CMMI, Scrum, XP and many others.

    With them, he has extracted a small kernel of practices that are common to all processes. The idea is to be able to categorise and compare processes better, and hopefully put them through their paces in a more engineering way. Perhaps even compare them using metrics.
     
    These practices are essentials that every software development organisation does. Nothing is optional. They might do them in different ways using different methodologies - even if the methodologies don’t themselves describe them. For example, Customer Representatives must ‘Understand the need’ and ‘Ensure stakeholder satisfaction’. These sound like universal truths - and they are. Every process has something to say about them.
     
    Ivar said that all methodologies can be described in terms of his kernel practices. And he has apparently started a company that sells 23 glossy cards with the practices printed on them.

    Now until I get my hands on a full list of the 23 practices he has explained, I’m going to stay sceptical. I’m not going to say that software development is an art any more, but merely that it’s complicated :-)

  12. Oh Data! Where are you?

    Here’s an interesting idea for distributed computing when you have large amounts of data spread across numerous machines - move your code around (as ruby/scala/what-have-you continuations) instead of moving your data around. 

    It’s a research language called swarm:

    http://blog.locut.us/main/2008/10/6/swarm-a-true-distributed-programming-lang…

    http://code.google.com/p/swarm-dpl/

    It’s kinda like when you’re in a library (the physical kind with heavy books, dusty shelfs and smelly aisles), and you pause reading a book to walk to the reference section to look up a word before walking back and continuing your book.

    The coolest part is that most continuations can be contained in a single network packet - so there shouldn’t be much network traffic bouncing around if you’ve partitioned your data vis-à-vis your problem domain.

  13. Shuffling energy

    I got up this morning and rearranged some energy to affect the world. That’s what I do for a living according to Ron Burk -

  14. Ever wondered how mechanical computers worked?

    I remember playing with gears as a kid and discovering some of their mathematical properties. But I never went as far as using cams to compute trignometric functions!

    Watch these videos to learn how they used plain old gears and shafts to compute the trajectory of a projectile, and many other computations that the navy required.

    Part 1 -

    Part 2 -

  15. Stuff someone learned working at Microsoft

    I found this an interesting read. Mostly because it resonates with my own experience -
    http://www.sriramkrishnan.com/blog/2009/12/stuff-ive-learned-at-microsoft.html

Vignelli theme by Robbie Manson