Tuesday, December 4, 2012

The Web Developers Mistake

If like me you do web development there is probably one mistake you often make over and over again in terms of UX.

We assume that our experience using our app under development will mirror the end users and there are a few reasons why that is probably not true.

First is our workstation. Like many developers I am using a modern computer with a lot of memory. In my case it is a macbook air with 8GB of ram and a 23" external monitor. But our users may have very different hardware. And by different I mean older. For those users who are not power users it would not be crazy to think that they are using a 5-6 year old computer with a 17" monitor. And for many uses such a computer is of course a practical machine. However if your website or app does not work well on it then they will go use something else.

Second is the network. When I do web development I am using a server that is either on my laptop or maybe on the linux box sitting next to it. In both cases these machines are very lightly loaded as I am the only one hitting this server. But more importantly it is local. It is connected over a 100mbs Ethernet wire.

Our end users may be in a very different ballgame. If, for example, you host your application in Amazon's East Coast Data center (as many sites are) your user may well be half way around the world from the server. In addition depending on what country they are in their network connection speed may be congested. As such it would not be crazy for a network round trip for your local development server to take 1-2ms while for the production server to take 300ms or more. So the time to connect to the server would be as much as 300x slower!

Of course there are ways to help this. Combine scripts and images and using a CDN will help a lot.

However the most important way to combat these problems is just to keep them in mind as you build your applications.

Why are backups so hard?

Like everyone else I need  a backup solution and I have been putting this off to long. Here is the thing I want this to be as simple as possible. I have my laptop with stuff on it and I have a file server with free space. So it should be simple right? Choose what to back up (and what not too) and have it make a compressed copy of everything to backup onto the file server. Ideally compress it at the same time.

I looked at Apple's Time Machine and it wants either a directly attached drive or their backup server. No Joy there :( I don't want to buy their thingy and Don't want to buy a hard drive just for this.

I looked at a bunch of other things online all of which seem really complex and cost money, both of which I want to avoid if I can.

My final Solution... Tar and a shell script

I mounted the backup volume on my mac and created a script to tar everything up and copy it over my net.  I will add it to the chrontab later to backup every night after I go to bed.

Sunday, October 14, 2012

Dealing with time intervals

Sometimes in a configuration file you want to express something should happen periodically or after a delay. The problem is that Erlang like most languages wants to see an integer number of milliseconds, while I want to write something that will make sense. If I see 5400000  in a config file I have no idea what that means. On the other hand if I see {90, minute} then it is very clear that  this is a time value.

Here is a brief function that will let you specify time as seconds, minutes, hours or days.

Thursday, October 11, 2012

Meta Web Services

I have been building applications and services on the web for almost 20 years. Really it has been that long I put up my first very simple web app with Perl 5 and mSQL (MySQL wasn't out yet) in about 1994. And what I find is that I seem to still be writing the same code now as I was then.

Ok I switched from Perl to PHP to Erlang and have upgraded architectures in there a few times but I am still writing CRUD code by hand after almost 20 years. At one point I actually built a generator to build PHP from templates which was nice but really why am I doing this?

What I really want is a generator script. Let me write a set of rules in to describe the service in a config file of some form, then have the computer build the code.

Now the question is what do I want in this package....

  • Written in Erlang
  • Use Yaws or Cowboy
  • Support Mnesia, MySQL, PostgreSQL and Riak
  • Support Web Sockets
  • REST
  • Authentication via OAuth or local 
  • Integration with Web services (Facebook, Twitter, Dropbox etc)
  • Allow Custom Extensions
  • Should Focus on providing web services not pages (JSON over HTML)
  • Easy to read setup files
Well there you have it. I want to be able to describe my service in a DSL check that into github and have my server pull it out, build what I want and push it live. 

Monday, September 10, 2012

CoffeeScript keeps crashing on me

I am a big fan of CoffeeScript, I think it is the syntax that Javascript should have. The problem I have is this, the compiler keeps crashing on me. I generally set it up with the "--watch" command so that it will keep track of my files and recompile as I go, which is nice. Except when it crashes and I spend 5 minutes wondering why my new code is not showing up.

I had originally thought to write an erlang app to fix this, but then I realized that I need something much simpler, a shell script will do:

(yea I suck as shell scripts) But it does the job. It runs the compiler and if it should exit well then bash will just restart it without bothering me.

When in doubt have the computer do the boring and repetitive stuff!

Sunday, September 9, 2012

Mixed in with all the other programming stuff I am doing I am going to be teaching my Step Daughter to code. So we will be working threw "How to Design Programs" which should be fun  so expect to see some scheme here intermixed with the CoffeeScript, Erlang and whatever else runs across my desk. Look for it under tag "scheme"

Thursday, September 6, 2012

A Mock Sync For Backbone.js

If you want to do unit tests on a backbone.js application it would be really nice if you could replace the default sync with one that will not make an AJAX call but will return prebuilt data so you can test the application.

This is very easy to do. What you need to do is to replace the default Backbone.Sync object with one that will pull prebuilt data. This is what I have been using so far. It just takes an existing table of mock data and when a request comes in uses the URI as a key to retrieve the data and resets the data for the collection.

Obviously this only works for reading data, for Update, Delete etc things get a little more complex but there is no reason to not be able to expand this approach.