Hillel Wayne interviewed people who have worked professionally both as a software and a traditional engineer (from a diverse set of engineering disciplines) to determine if “software engineers” are really engineers … and, yes we are.
He also analyzes myths from and about software engineering and tries to find out if there’s actually something that makes software engineering unique among the other engineering disciplines.
If you use Python‘s Bottle micro-framework there’ll be a time where you’ll want to add custom plugins. To get a better feeling on what code gets executed when, I created a minimal Bottle app with a test plugin that logs what code gets executed. I uesed it to test both global and route-specific plugins.
When Python loads the module you’ll see that the plugins’
methods will be called immediately when they are installed on the app or applied to the route. This happens in the order they appear in the code. Then the app is started.
The first time a route is called Bottle executes the plugins’
methods. This happens in “reversed order” of installation (which makes sense for a nested callback chain). This means first the route-specific plugins get applied then the global ones. Their result is cached, i.e. only the inner/wrapped function is executed from here on out.
Then for every request the
method’s inner function is executed. This happens in the “original” order again.
Below you can see the code and example logs for two requests. You can also clone the Gist and do your own experiments.
Let’s say you read settings from a YAML file and have some sort of settings object. Then you check if certain options are set with custom values or you have to set default/fall-back values on them. If you are dealing with Boolean options you have to be careful … as I had to find out myself.
Initially you would probably do something like the following to set a default value on a Boolean option:
settings[:some_option] ||= true # set default value if nothing set
Do you see the problem? What happens if the option was deliberately set to
? You would overwrite it because both cases
(i.e. nothing set) and
would evaluate to
in the context of the
operator and you would in both cases assign the right hand value (and overriding an explicit user choice in one case) … *ouch*.
So the correct solution is something like the following:
settings[:some_option] = true if settings[:some_option].nil?
# thanks to http://blog.phusion.nl/2011/08/14/rendering-rails-3-1-assets-to-string/
# you may need to change the owner of the tmp/cache/* directories to the web servers user
# e.g. for Debian systems: `chown -R www-data:www-data tmp/cache/*`