HN user

andregawron

11 karma
Posts2
Comments5
View on HN

TL;DR: if possible, create a develop environment which is as close as the live environment

I think developing servers are only good for people writing libraries or frameworks to get started. I might understand that people want to choose a small and easy to set up webserver to get going when starting developing a website.

But, in my opinion, as soon as you're getting serious, there's nothing better than developing on a system which as close as possible to your live environment (hardware is hard to mimic, so are websites running in the cloud) including same webserver and software configurations.

Of course this means that you either:

a) have any influence on software installed or b) know what is installed and how it is configured on the live system

I encountered several bugs which happen to be only on staging / live server, but which I did not encounter in my development environment. Why? Different OS. At this point, I'm trying to recreate my live-systems in virtual machines as close as possible. This is not perfect hardware-wise, and software still might behave differently, but it's damn close.

Another plus: I'm on a rolling release distribution and software packages are updating fast. This can be problematic when developing websites and applications. All my server-software is in the VM. I can choose when and what to update, problem solved. It also keeps my desktop clean, no stuff installed for developing purposes.

There's nothing worse than developing on a windows* machine and deploying on a unix-based os.

* nothing against windows developers. Point is: different OSs behave differently.

I might have considered throw and catch as I wrote the library, but right now, I cannot think of any good reason why I haven't used it. Will check that again. Thanks for the suggestion.

Inspired by Lisp's condition system I wrote a ruby library which comes pretty close to Lisp's error handling. It also implements "restarts" ... a little bit messy though since, as you said, low-level execption are used to get it working. In one point the condition system bootstraps itself which is quite interesting to think about.

https://github.com/melkon/conditions

An example ("parse_log_file" and "log_analyzer show restarts"): https://github.com/melkon/conditions/blob/master/example/exa...

In the beginning I thought it can only be ported to Ruby because I used some Ruby-specific features. The exception solution (which I implemented later) should work in a lot of different languages though.

Another thing is, if you understood the condition system, you can use it for a lot of different things besides error handling. You can build protocols on top of that, event handling etc. Freedom is yours.

Hyper, Super ... I'm talking about mod4 (on most keyboards the win-key right to L-CTRL). The overlay is normally activated by pressing mod4. With the stated option ticked, triggering the overlay with mod4 doesn't work anymore (when I remember correctly) - but every other shortcut using mod4 + anykey works again.

To get to the overlay using a shortcut, I set it to mod4 + a.

You can actually make the Super-Key usable again. Goto Region and Language -> Keyboard Layout Options and tick "Hyper is mapped to Win-keys" [1]. After that, you can use the super key again for shortcuts. I moved the activity window to Super-A but actually never use it.

[1] Image: http://www.andre-gawron.de/wp-content/uploads/2011/05/key.pn...

[2] Full blog entry: http://www.andre-gawron.de/383/amsterdam-peek-gnome-3-a-new-...