Flattening an array is a standard question in interviews, especially for modern languages like python and ruby. I just thought trying to flatten a hash would be much more interesting.

Here is my attempt at converting something like

{“a”=>1, “b”=>{“c”=>3}, “b2″=>{“c2″=>{“d2″=>2, “d3″=>8, “b2″=>9}}}

into

{“a”=>1, [“b2”, “c2”]=>9, [“b2”, “c2”, “d2”]=>2, [“b2”, “c2”, “d3”]=>8, [“b”, “c”]=>3}

require 'enumerator'
class Hash
 def flat_each(prefix=[], &block)
      each do |key, value|
           if value.is_a?(Hash)
                 value.flat_each(prefix + [key], &block)
           else
                 yield prefix + [key], value
           end
     end
end

main_hash = Hash.new
given = {"a"  => 1,"b"  => { "c" => 3 },"b2" => {"c2" => {"d2" => 2,"d3"  => 8,"b2"  => 9}}}
given.to_enum(:flat_each).collect { |k,v| main_hash.merge!({ (k.size == 1) ?  k.first : k.uniq  => v}) }
puts main_hash

Algorithm adapted from Ruby Forum.
Not sure this is what you would call flattening a hash, but this is the best I could rustle up in half an hour.

Taken from Floating point accuracy problems.

Floating-point numbers cannot precisely represent all real numbers, and that floating-point operations cannot precisely represent true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers.

For example, the non-representability of 0.1 and 0.01 (in binary) means that the result of attempting to square 0.1 is neither 0.01 nor the representable number closest to it. In 24-bit (single precision) representation, 0.1 (decimal) was given previously as:
e = −4
s = 110011001100110011001101, which is 0.100000001490116119384765625 exactly.

Squaring this number gives 0.010000000298023226097399174250313080847263336181640625 exactly.

Squaring it with single-precision floating-point hardware (with rounding) gives 0.010000000707805156707763671875 exactly. But the representable number closest to 0.01 is 0.009999999776482582092285156250 exactly.

I recently got given an iPad to play with and considering this was my first time ever using this latest of toys, I was pretty keen on it’s functionality.

I got the device, and managed to configure it and set as many apps on it as I wanted to my hearts content thanks to the wifi at work. But when I got home, the attraction of the device plummeted. This was not due to any fault of the device itself but due to the rather lamentable condition of internet connectivity.

Due to the fact that the area that I inhabit has pair gains setup over its phone lines, I cannot get ADSL connectivity and hence must rely on mobile broadband. This is all well and good but the problem arises when the setup of the mobile broadband refuses to allow shared internet connections through my MacBook over the airport. Hence the decreased interest in my iPad when I got it home.

I tried many things in order to share the connection to my iPad. I tried to share the screen, looked for apps to connect directly to a laptop; I tried a lot of things. In the end, Andrew Humphrey suggested I try to share it over ethernet through a router. I still had a Netgear router lying around from the heady days when I had ADSL and hence decided to use it. Alas, even that let me down.

Daniel Hall made the observation that Netgear routers do not allow static routes and hence I just needed a dumb router, which he was kind enough to lend me the next day.

Hence, as the situation lies, I have a mobile broadband dongle connected to a laptop, sharing the connection over Ethernet to a dmb router which then shares it over wireless to which my iPad connects.

It seems a very round about way of getting wifi to my iPad, but it was the only way. And now that I have wifi, the iPad seems so much more interesting. Let’s see, how long this lasts.

Noticed yesterday that playing Wagner (specifically the Die Walkure suite) consumes the battery of my Apple Macbook much more rapidly than playing Beethoven (specifically the 6th).

Both these mp3’s are the same bit rate, same compression, and nothing changed on the laptop between playing the two suites. I played the suites for the same length of time twice and did not even move the laptop thinking that perhaps the temperature might be a factor.

Next step is to run different suites of both composers and see if the effect can be reproduced.

The process of software development is long and hard. It goes through a lot of stages. Development is usually done on your laptop/desktop and once you are done, it is hopefully moved to a production like machine where your changes are tested. If passed, it then is passed onto production. All these different environments are configured differently and possibly access and enable different areas of the application being deployed. All this is usually managed by configurations.

The scenario mentioned here gives rise to the possibility of two different types of configurations and that is going to be my rant for today.

There is application configuration and there is environment configuration. If you have to turn features on or off in your application in production, or release something that you want a subset of your users to see for some testing purposes or for whatever reason, you want flexibility, then that setting is an application configuration.

Any change in environment, whether machines, URL’s, databases etc when you move software from one system to another in the development lifecycle requires environment configurations.

Usually, the way to go about them is to put the configuration in a YAML file. For example

ThisReallyIsSomethingIHate: 1
ThisIsSomethingMeLikey: &AliasForIt
    Name: Gandalf
    Default: #98AFC7
    Update: #FFFFFF

This works fine for environmental configurations which rarely change and which do not need to be altered every so often. But for application changes, where toggling of features on and off, before and after deployment is a common thing, we need something that works, in my opinion similar to a JMX console. An admin console, which tells us the health of the feature/application, and allows us to toggle the features on and off.

This involves moving the application configuration from a flat file into a persistent storage, perhaps a database. This ensures that Operations do not have to worry editing files but actually have a console to do it in, something that is easier to start and manage. This would also help out QA during testing, because now they do not have to write automation tests to edit configuration files but a simple selenium step will accomplish that for them.

I do not know whether this is the right way of separating application and environment configuration, but I do know that we need to separate them.