I got into an ironic conversation the other day over the usefulness of having multiple languages in the world.
I am of the opinion that languages are redundant and they only exist for being the most usable mechanism we have invented for communication so far.
As I tweaked some last bits of code and added a few comments here and there, I realized I was getting excited. This project I had been working on for the last few days was almost done. I was happy about the code I had written and started prepping for a code review. My co-workers had been asking how it’s going and wanted to give me feedback, so I pushed and deployed my changes to a staging server.
What immediately followed was a humbling experience. “What is this?”, “Why did we decide to do it this way?”, “Won’t this interfere with the rest of the product?”, “How about if we do X instead?”, “Arnor, what the hell have you been building?”
By now, it’s no secret that making mobile products has a unique set of design challenges. All companies and individuals making mobile products struggle with this. Finding the right balance between power and ease of use on a 3″ – 4″ screen is hard.
It really all boils down to the natural rule of features:
More features => harder to understand, more useful.
Fewer features => easier to understand, less useful.
So if you just add more features, without applying careful thinking about the whole experience and especially the experience for new users, you’ll inevitably make a complicated product.
I was reminded once again today how impenetrable the wall of things to do in life is. We had just hit yet another big milestone at work and as soon as we hit it, I started thinking about the next steps. And after that the next steps.
Just in the time it took for us to reach this milestone, a list of things to fix and improve before the next milestone was building up. And that list is long enough to take 10 times the time that the original milestone took.
We grow up thinking that next year will be better, or this year you will manage to finish X
Running a business, or working at one, is about fires. Everything is either falling behind, failing, has always been broken or is unusable. The only tool we have is a limited fire extinguisher to dim down the biggest most obvious fire each time.
I wasn’t surprised that parseInt was slow, since I think it parses the number as a string, but the left shift being faster than Math.floor() was a bit more puzzling to me.
So I decided to make a JSPerf test to compare those three methods.
Read on for the full results
LinkedIn is perhaps not known for their development efforts in the open source community. But to my surprise, they have released an open source data store, dubbed “Sensei DB” which I find really interesting. (They may in fact have released it a while ago, but I just recently have discovered it) It’s built for high [...]
I got into a conversation at work today about whether or not Node.js might become as popular and as ubiquitous as Ruby on Rails has become, or if it’s just a fad.
At first I was like “It’s going to become the most used framework evar!” But then I thought about it a bit more and realized that this might not be the case.
I have this horrible habit, where when I have an idea, I usually start by ordering a domain.
And when I’m brainstorming, I might come up with around 30 ideas for domain names of a particular idea, which I narrow down to about 3-5. But horribly, I can’t decide which one is the best (some people tell me it’s because I’m a “libra”), so I end up buying all of them.
I’ve been hooked on Node.js for the last 2-3 months. I’ve been doing some small projects for fun in Express, and at first I used the SASS complier that ships with Express by default.
That framework is pretty limited and TJ Holowaychuk pointed me towards Stylus, a much better sass complier for Node.js.
I tweeted something about Stylus a couple of days ago which resulted in a fellow countryman, named Jokull Solberg (www.solberg.is), showing me a responsive grid framework he made in Stylus.
We use git as our versioning tool at work and I’ve gradually been learning a few tricks on how to speed up my development time and time spent managing my repo.
When jumping between branches, continuing your work from where you stopped last time, etc., you very often open the same files as you were editing in a previous commit. This may not be a problem if you use something like Command-T for vim or rely on the file browsing in TextMate, but often it might just be quicker to open all the files from a particular ref in git or opening all files from your branch’s diff from master/dev or something.
I’ve been dealing with some unfortunate scroll performance issues at work lately, and to aid me in that task I’ve been using a handy CSS stress test bookmarklet made by Andy Edinborough. It works by iterating through all your classes and measuring the performance improvement you get from dropping them – thus helping you find out which classes are making your page scroll speed slow. It’s handy but the use case too constrained for my needs.
I wanted to be able to simply run a test anywhere on the page just for a single run, and I didn’t really care about the classes, since I was manually disabling styles and moving things around, unbinding event etc to find out where the biggest performance improvements could be had.
Felix Geisendörfer, one of the node.js contributers has released what can only be dubbed as the ultimate guide to writing node.js applications. He’s launched a site called nodeguide.com which has a beginner’s guide, a guide for how to convince your boss you should be using node (kind of funny, but sadly there are people who need this) and a style guide for standardization of indentation, naming, etc which should be taken with a grain of salt.
A couple of months ago, Facebook started rolling out it’s Timeline feature. For those who don’t know, it’s a new form of a Facebook profile, which displays a user’s profile in a very different way, based on their entire life’s history. It’s a very dramatic thing and is a very impressive endeavor.
I signed up the very minute it was announced and have had it as my default profile, though it hasn’t been viewable by anybody but me for some time, it’s dust has now settled a bit and I’ve been trying to digest it and form an opinion.
The Timeline is so interesting in so many ways. In one regard it’s got a very inconsistent UI compared to the rest of Facebook and it introduces a lot of UI concepts and ideas that have not been known to websites in general before but on the other hand it’s also a very pretty beast.
Read on if you’re interested in diving (probably way too) deep into the Timeline