Posts

A few weeks ago, two of our officemates (this guy and this guy ) did a Level Up Lunch on visual notetaking and the Bullet Journal technique.

I like to think I am someone who seriously get things done, but I have to admit I was struck by the simplicity and clarity of the system and the possibility that even while I am great at getting things done with Taskpaper , I do recognize that I still pile things into and roll things forward into future weeks arbitrarily, often just removing the problem I had with days getting overloaded with other systems, to future weeks with Taskpaper. I really liked the idea of the Monthly versus Daily calendaring, as well as the Event logging that seemed inherent in bullet journaling. And, well… it’s always good to shake things up, so I decided to take the plunge. I’m on the cusp of the 45 day mark, so I felt I should share my findings so far.

And make glorious and interesting mistakes. Some great advice from the ever-wise Neil Gaiman.

Cool kinetic typography from Nanna Påskesen

via the Farnam Street Weekly newsletter

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.