Topic: Web Development

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.

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 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 came upon this blog post by Seth Hoenig titled “Open letter to sites with annoying interfaces” yesterday. In the article he talkes about how some web sites and/or apps hide user interface actions until a later state. The post is a little bit funny and there might be a little bit of truth to it, but mostly it’s inaccurate.

The examples he covers are gmail’s edit-contact page and the button used to edit a project’s description on github. I’d like to talk a little bit about those and then give another perspective on hiding UI elements.

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.

Usually when designers are designing both print and website layouts, banner ads and other user interfaces, they need to have some text copy to work with. Most of the time, the client or the company they are working for doesn’t have text copy prepared, so designers usually place so called “Lorem Ipsum” content into their designs.

Lorem Ipsum has been used for many decades as placeholder content in print layout designs. It’s based on latin, but is actually just gibberish and doesn’t have any meaning. It’s purpose is to divert the reader’s attention away from the text itself and onto the layout and the design. That seems very logical.

My mom had a birthday gathering the other day (happy 52 mom). It was pretty uneventful as you would expect, but as sometimes happens these days, a conversation about Facebook got started.

Most techies you meet would say that they hate listening to normal people talk about anything technical – especially the older generation. I usually find these kinds of conversations rather enjoyable, especially if I can withdraw and not have to be a part of it and just listen. Because then you kind of get a sense for how normal people see things and what problems they run to, etc.

Closures are functions that you define “on the fly” that have access to the same variables (the same scope) as they get defined in. You can store them as variables, pass them around between other functions, and generally get treated like a normal variable.

In general they are very powerful. Read on for a deeper explanation of how they are useful and creative way in which they can be used.