Nice post: “Architecture in Context – Part 1″, By Charlie Alfred and Gene Hughson

Architecture in Context – Part 1 | Form Follows Function.

It’s really important to remind folks about context, this is a great take at it. The multidimensional aspect could easily be overlooked. Namely, the environment, time continuum, these bring about constraints that help to frame the context, and usually stakeholders don’t have any control over these other dimensions. When some of this is missing, endeavours may become disconnected from reality.

In my opinion, this isn’t stated often enough, instead a lot of debate tend to centre around definitions and the latest-fashion.

Handy shortcut to keep WiFi running on OS Yosemite: restart the DNS resolver

A long time ago, while I was studying, I had a PC running Microsoft Windows 2 (yes indeed, Windows version 2). It came with a program called Write, which I was using to type my homework and eventually my graduation assignment. This thing was unstable, it crashed so often that I learned to press CTRL+S at the end of every line of text that I typed on it, to be sure that I didn’t lose my work. The habit never left me. It wasn’t until about 4 or 5 years ago, long after I had already switched to Mac and didn’t need to worry about CTRL+S, that I finally lost the habit of instinctively hitting that key combination every few minutes.

I have an annoying issue with my Mac, it just randomly loses network connection, sometimes it won’t connect at all for  a few minutes. After a couple of updates that promised to have fixed the issue, it’s still there. I made this shortcut, very short bash scripts that I placed in my .bash_profile startup script.

$ alias down-discoveryd='sudo launchctl unload -w /System/Library/LaunchDaemons/'
$ alias up-discoveryd='sudo launchctl load -w /System/Library/LaunchDaemons/'
$ alias restart-network='down-discoveryd && sleep 3 && up-discoveryd'

One line would have been enough, but I wanted it a little pretty, so I made three. I added a small delay, for good measure, though I think it could also be omitted. The only command I need to run is the last one, restart-network, I get prompted for the admin password, and the service is restarted. If the network is still not restored, I run it again, and again. After 2 or 3 attempts, I get my network connection back and I can continue working.

I find myself using this shortcut very frequently. It has become my new CTRL+S. Unfortunately.

Cloud and Mobile, an incredible if not unprecedented opportunity for comeback kids

It cannot have escaped many software company executives that Mobile and Cloud represent possibly the best opportunity to reinvent a flagging business proposition. Surveys and studies by many household name analysts such as McKinsey, Deloitte and others, show that . My post comes from another angle, a simple observation at a micro level that can be scaled up to a bigger picture.

Actually, I believe that Mobile without Cloud, or vice versa, would not have any significant impact. So, I contend that whenever Cloud is mentioned, Mobile is an implied companion. And the other way around as well. When Internet Of Thins (IoT) finally dawn, Ubiquity would become a more appropriate concept and could encompass Mobile.

I was recently reminded of one pervasive reality with software, dependencies are the cause of a lot of troubles, if not most. I was trying to install a new version of Archi, a software tool I am used to running but hadn’t needed for a while. When it failed to run, I thought I could quickly just rebuild it. I fired up Eclipse and started going through the process of building Archi. I quickly stopped, realising the trap I was slowly getting myself dragged into. What the industry term as legacy is largely due to such dependencies, in many situations, an insurmountable task of rewriting and rewiring code that is large, complex, hard to understand, better left alone as long as it is working. In the case of Archi, I am not suggesting that any rewrite would be necessary, just the dependencies that I would have to deal with before I could achieve my goal, get it up and running.

As a quick comparison, I take the recently famous move by Microsoft, who have turned to open source in a serious way.

rebuilding a complete software stackFull Stack: open source stack vs. Microsoft’s

In the diagram, I name an arbitrary number of levels, or layers, just for this discussion’s sake.

  • Level 0: this is usually provided by hardware vendors, who make the hardware an then bundle it with software.
  • Level 1: this is the Operating System level, in the comparison, Microsoft provides this element, this is Windows for example.
  • Level 2: fundamental building block elements, usually provided by the OS vendor. This is one area where Microsoft open sourced .NET Runtime Engine for example.
  • Level 3: combines with Level 2 and make it easy to expose system capabilities to users. Level 2 and Level 3 tend to be closely integrated, often case, 3rd party vendors provide Level3 elements.
  • Level 4: this is the part that the user will eventually experience.

In this discussion, I’ve intentionally left out Apple, as they are known to control the end-to-end user experience in most cases. Albeit, Apple do subcontract for parts and components, embed 3rd party software and open source software, but they control the packaging process. It is not an interesting study for this post, I focus on Microsoft stack vs. open source stack.

I’ve simplified the reality in this diagram quite a bit. But there usually are multiple layers between Level 2 and Level 3. This is where most of the dependency troubles lie. For a developer, this could be a tool chain for example. But it could also be libraries, utilities and other 3rd party software elements. This is where trouble with multiple Windows DLL versions typically occur. Such dependency issues are not confined to Windows, I’ve seen it with many open source Linux software too. The issue happens when for example you are dealing with a Level 3 component and it complains about some Level 2 element that you were not aware of or didn’t expect to be dealing with. That’s the can of worms.

By moving important elements to open source, Microsoft would normally have had to do a lot of work in Level 2 and Level 3, to bring up their open source proposition to the same level where Unix/Linux is at. But, with Cloud and Mobile, this work is not necessary. A wide variety of platforms and legacy systems can be skipped. This is also perhaps the best opportunity for Microsoft to actually ditch support for a lot of systems that won’t need to be directly exposed to the user.

Cloud providers and infrastructure providers offer solutions that combine Level 0 and Level 1. Lots of players have emerged in recent years, providing up to Level 3 either by themselves or by procuring Level 0 and Level 1 from others. Large players like Amazon, Microsoft, and Google provide up to Level 3. In some instances, they offer solutions all the way up to the end user level. Examples abound, I don’t want to extend this discussion too much.

Ditching Level 3 elements and rewiring your Level 2 elements for Mobile and Cloud, that is where the opportunity mainly lies. The necessity of revising and rewiring systems should be a profitable source of business for those who can can into it.

Unfortunately, companies that cannot figure out exactly what is going on in their business at its core, will struggle to even see the opportunity. The situation is akin to old Hollywood blockbusters movies such as Die Hard for example, where it was important to cut the right cable. The comeback opportunity is about separating out what should be dropped from what should be kept, then streamlining the business for Mobile and Cloud. Newcomers who never even built such Level 2 and Level 3 elements, have the freedom to move swiftly along with the market.

Programming language, one man’s cornucopia is another one’s air horn

Whenever I read a rant about a programming language, I try to see if the author actually knew the background of that programming language. In the vast majority of cases, people don’t know the origin of the language they are programming in. One can argue that this may not be necessary, but to me, it often would save time and frustration. To illustrate the topic, I made a little diagram.

programming language design in contextprogramming language design in context

The situation is this, unless your needs fit more closely to the range of light red and green in the diagram, you are bound to be disappointed with the language that you are dealing with. If you find that many of your concerns are in the brown colour, you really ought to carefully look at what you can trade-off before going further. If the important concerns of your challenge fit more in the blue shapes, you might be better off considering an alternative language altogether.

This is just a quick summary of some simple but often overlooked aspects of programming language selection.


Remove unnecessary layers from the stack to simplify a Java solution

An item in my news feed this morning triggered the writing of this post. It read shadow-pgsql: PostgreSQL without JDBC. It’s a Clojure project on GitHub. Indeed, “without JDBC”. That’s it. This is particularly pertinent in the Java software world, where a flurry of popular initiatives are driving down the adoption of once revered vendor solutions. Some of the arguments I make here apply as well to other software and programming environments, not just Java.

As you start writing a Java application, destined to be deployed as part of an Internet enabled solution, it is important to carefully consider the requirements before selecting technology to build your solution with. Everyday, a new tool pops up promising to make it easier and faster to start writing software. People lose sight of the fact that getting started isn’t the hard part, keeping running and growing, adapting to change, all at a reasonable cost, are by far the hardest part with software. And to boot, once something is deployed into production it instantly becomes a legacy that needs to be looked after. So, don’t be lured by get started in 10 minutes marketing lines.

I would argue that, not knowing the expected characteristics of your target solution environment, is a strong indication to choose as little technology as possible. There are lots of options nowadays, so you would expect that people always made proper trade-off analysis before settling on any particular stack. A case in point is database access. If you are not forced to target an AppServer then don’t use one. If you have access to a component with native support for your chosen database platform, it might be better to just skip all the ORMs and JDBC tools and use native database access libraries. This would simplify the implementation, reduce the deployment requirements and complexity.

It used to be that, if you set out to write a server side Java program, certain things were a given. It was going to be deployed on an AppServer. The AppServers promoted the concept of container where your application is shielded from its environment. The container took charge of manageability issues such as security, authentication, database access, etc. To use such facilities, you wrote your code against standard interfaces and libraries such as Servlets, JDBC, or Java beans. If the company could afford to, it would opt for an expensive product from a large vendor, for example IBM WebSphere or BEA WebLogic (nowadays Oracle). And if the organisation were more cost-conscious, a bit of risk taker or an early adopter for example, it would choose a free open source solution, Apache Tomcat, jBoss, etc. There were always valid reasons for deploying AppServers, they were proven, tested and hardened, properly managed and supported in the enterprise. Such enterprise attributes were perhaps not the most attractive for pushing out new business solutions or tactical marketing services. That was then, the Java AppServer world.

As the demand for Internet scale solutions started to rise, the AppServer model showed cracks that many innovative companies didn’t hesitate to tackle. These companies set aside AppServers, went back to the drawing board and rebuilt many elements and layers. The technology stack had to be reinvented.

Over last ten years I would say, people started writing leaner Java applications for the Internet services. Mostly doing away with AppServers. This allowed the deployment of more nimble solutions, reduced infrastructure costs, increase the agility of organisations. Phasing out the established AppServers came at a cost however, one now needed to provision for all the things that the AppServers were good at: deployment, instrumentation, security, etc. As it happens, we ended up reinventing the world (not the wheel as the saying would have it, but well a certain well known world). What used to be an expensive and heavy vendor solution stack, morphed into a myriad of mostly free and open source elements, hacked together parts and parcels, to be composed into lean and agile application stacks. This new reinvented technology stack typically has a trendy name, Netflix OSS is one that sells rather well. That’s how things go in the technology world, in leaps and bounds, lots of marketing and hype, but within the noise lie hidden some true value.

Arguably, there are a lot of new java based solutions being implemented and deployed with stacks of unnecessary layers. That is a shame, because there is an unprecedented amount and variety of options for implementing and deploying good solutions in Java, or targeting the JVM. Understanding the characteristics of the envisioned solutions is one aspect that keeps driving Java and JVM based languages and technologies. AppServers are not necessary for deploying scalable Java solutions. JDBC and ORMs are not necessary for building high performance and reliable Java programs. The fact that a lot of people keep doing this, is no good justification for adopting the practice. The move towards smaller and leaner specialised applications is a good one because it breaks down and compartmentalise complexity. The complexity that is removed from the application stack, is diluted and migrated over to the network of interlinked applications. Not all problems would automagically vanish, but some classes of problems would disappear or be significantly reduced. That is the same principle that should motivate into challenging and removing as many layers as is reasonable from individual application stacks. I resist the temptation of mentioning any specific buzzword here, there are plenty of good examples.

When writing new software, it is natural to simply follow the beaten paths. People pick up what they are already used to, or what they are told to use, and then get going. There may or may not be proper directions for choosing the technology, but there is invariably a safe bet option that will be chosen. This isn’t wrong per se. What is though, is when no alternatives were ever considered when there was a chance to do so. Keeping your options open would aways prove more profitable than just going with the flow. One characteristic of lagging incumbents is that they often just went with the flow, chose solutions deemed trusted and trustworthy without regard for their own reality, usually not challenging enough the technology stack.


DYI: Improve your home Wi-Fi performance and reliability.

If, like me, you eventually got annoyed by how choppy and frankly slow your home Wi-Fi can become, then this post may be for you.

Does your Wi-Fi feels much slower than you expect it to be? Is it typically slow at the times when your neighbours are also at home, just after work for example, on weekends? Does it perform better when most of your neighbours are asleep? In the affirmative in some of these questions, you may be experiencing Wi-Fi channel overcrowding.

If channel overcrowding is the issue, here is a simple way to solve it:

  1. Identify a channel that is less busy or not at all
  2. Configure your router to use this free channel
  3. Restart it. Et voila.

Here is how a crowded channel looks like

wi-fi network channels


In the picture, you see a lot of coloured areas between 1-8 (numbers at the bottom of the picture), these are wi-fi channel numbers. If your router’s name shows in this area you are likely to have a poor reception. The solution is to move to a quieter channel. In the picture, you see that channels above 108 are totally free. Look at your wi-fi router documentation, look for the word “channel” and find out you to change it. If your router is not able to use the desired channel, it may be because it’s too old for example. If you find that all the channels in your area are too busy then you are out of luck, as far as this tip is concerned.


In my example, I am using a Mac and and I found a program in Apple Store called WiFi Explorer. The picture in this post is a screenshot from this app. If you are using a PC, I am sure there would be an equivalent available somewhere – be safe though, free software from an obscure or unchecked source may be malware. If this kind of tool isn’t something for you, then the good old trial & error method might be a way to do it. Just set your Wi-Fi router to another channel, restart it, check how it performs. Repeat the process until you stumble into a channel that works for you.



In residential areas, most of your neighbours also have wi-fi at home. More often than not, you may just drowning out each other’s wi-fi network with unwanted noise. Think of it this way, try to have a cozy conversation with someone in the middle of a busy shopping street and the two of you are 15 meters apart. What’s more, people have different voices that can be heard, the situation is different with wi-fi routers.

People get wi-fi at home either by directly obtaining it from their cable internet provider, or by buying wi-fi routers and installing that themselves on top of their wired Internet connection. It’s easy to do. The hope is that it’s going to be super fast as your provider relentlessly has been touting. At some point, a reality slowly start to sink in, your Internet connection is nowhere near as fast as you were told. Then follows annoyance, frustration, a little bit of guilty denial and ultimately resignation to accept the status quo – so-called Stockholm Syndrome.

A common cause of sluggish and fluctuating wi-fi network performance is the overcrowding of the allotted channels. Since most neighbours are likely to get wi-fi from the same providers, they all get the same routers with the exact same default settings. This means that the routers will be constantly interfering, causing noise that slows down and sometimes interrupt your network.


Although I am talking about possible Wi-fi interference here, it is by far not the only reason behind sluggish or unreliable home network. Another culprit may be typically deception from cable providers. It is well documented that residential Internet connection providers frequently throttle their users bandwidth, it’s easy to find out. And naturally, when lots of people are on the Internet, for example following an event, networks could become slower for everybody for a certain amount of time. It’s all more complicated than we often make of it. This is just a tip that may help if you are lucky to be meeting the conditions that I mentioned.