Strangely, one of the earliest things I learned in unix computing was crontab -e. In fact, it would not be an exaggeration to say, the reason I learned to
use vim in the first place, was so I could fire off automated jobs in cron
while I slept (Don’t ask. Mine was a complex childhood. :-) ).
I’ve never been a fan of Apple’s launchd replacement on the OSX operating
system.
Perhaps I was just expecting a lot, lot more from a book that purports to teach Hackers Design and subtitled Reverse Engineering Beauty but, at best, I’d only be able to give DfH an “ok” rating.
While I was hoping for something that would both illuminate and then directly show how to apply Design learnings from a hacking perspective or even the many, many rues of thumb and underpinnings that define Design, I found the book more a theoretical tour through the underpinnings which often meandered and went off course (I still don’t know why SEO was discussed at length) and was a bit disappointing. A number of any elementary books on visual and information Design could have taken its place and the “for Hackers” in its title seemed marketing hype rather than applicable reality. It did, however, have an excellent section on Typography which I found personally very useful.
I have to admit I was a bit sceptical going into this book. It seemed to promise a lot with a simple premise and one, frankly, that made solutions to a lot of my product problems way simpler.
So, I was reading with a bit of scepticism and pleasantly surprised.
And yet still, despite the fact I think it does sort of approach storymapping from a very ideal direction, and doesn’t get into the weeds of what happens on complex projects or how to untangle a bigger and more problematic project, it does make a clear and compelling case for storymapping helping with the What of needs to be delivered often where quite often the problem is developers using Agile techniques and getting lost in the trees and quagmired in the How of implementing something.
I have to admit I really, really wanted to like this book.
While at least one of our company offices has invested a lot in getting across Clojure as being the next big thing for some of the technical projects we could be running and it does seem interesting enough on its surface (particularly with interesting datastore developments like Datamic) and purports to solve some interesting problems that are difficult to do so in other languages, I have to admit the primary draw of the book for me was the fact the writer had a style similar to that of Why the lucky stuff whose book on Ruby sucked me back into programming and enjoying building digital products again.
Subtitled Building a Business When There Are No Easy Answers, I have to admit I really kind of liked this book. While I don’t agree with everything that Horowitz did in his career at Opsware (and its always easy to Monday morning quarterback someone else’s decisions), the thing I did like about this was its honesty and solid advice on what to do when there are, well… no easy answers.
I really like the Padrino web framework. Its simplicity and layer of just enough above Sinatra appeals to me over the burgeoning complexity of Rails of late.
As my applications have become more complex though, the lack of documentation and good examples have become an increasing issue. I’m intending to write a few blog posts on common, yet more complex things, you need to do in Padrino to use it as a Rails replacement. Hopefully it can increase uptake and help other people with issues to solve some common gaps.
Simple works.
Sometime around early 2012 I switched over to using Things for OSX from the spartan essentials of Taskpaper. I have to admit, at the time I was angry with Taskpaper. It was still using the SimpleText service (Taskpaper now uses the uber-reliable Dropbox) for synchronizing with my iPhone and it had done what I felt was the inexcusable: It had lost tasks I had to complete in a sync conflict and even after I recovered the file, I didn’t know what they were (partly my stupidity for not having it source controlled in git).
Everyone I know that deals with large amounts of data has been looking closer at Hadoop as it’s matured. Especially with tools like Hive, old datawarehouse hands are taking a serious look at it as a better type of long time data archive and storage. You probably should too.
While most of the time for the types of real work you’d be doing, it makes more sense to spin up Amazon’s EC2, Elastic Map Reduce or another flavour of virtualized Hadoop instance in the cloud for the clustering and crunching benefits, it’s very good to have a local install for development and testing.
[Updated: 2013-01-08 - A lot of people asked for Postgres instructions]
After my faithful Macbook Air went down hard in Tonga, I was really surprised at the number of outdated posts, misinformation and general number of questions (even on Stack Overflow), on how to install a Rails dev environment from scratch on a new OSX 10.8 Mountain Lion machine.
This HOWTO runs from zero to getting you to what I consider a naked dev
environment where you’re good enough to start and source control a
project and issue a rails new command. It starts from a totally fresh
install of Mountain Lion with all system updates.
Some quiet holiday time has finally given me the chance to polish up the code I wrote earlier this year and finally release my blog engine.
Kobayashi is finally out in the world in at least a first release form with a few tests, a basic theme and working code.
I wrote more extensively about why I’d write a blog engine here .
Kobayashi’s built to handle large blogs and still be damn fast and cache and act as if the entire site was static so (hopefully) hold up under high loads with highly optimized caching using memcache and etag http caching. The whole thing runs on heroku with a simple push.