An abundance paradox: so many opportunities to innovate, yet so little demonstration of it

In his number titled Rat Race, Bob Marley once sang the following lines,

In the abundance of water,
The fool is thirsty.

I think it could apply to the world we live in at the moment.

Many observers wrote that the world is producing unprecedented amount of media at an unprecedented rate. All that information is mostly freely available. Yet it has hardly been more difficult to make proper use of such manna. Technology is evolving at such a pace that the barrier to innovation is lowering by the day. Capabilities that would sound like science-fiction just a few years back, are now becoming available at near commodity levels.

It has never been easier and cheaper to publish digital media. At the same time, long established media publishers seem to be relinquishing publishing control to new players such as Facebook, Medium or Google. I won’t even start on horrible terms such as post-truth and similar misnomers, you get the impression they’re on about some World Wrestling Entertainment show, or maybe soap operas. Quality seems to be missing when it should’ve been easier to publish truthful and newsworthy items.

It used to be very difficult and time consuming to design and build even modest web solutions, nowadays the task can be accomplished at a fraction of the cost and comparatively no time at all. And yet, many businesses are struggling to digitise their processes, take many months if not years to deploy decent solutions. We might not be learning fast enough, have our eyes on the wrong priorities, struggling to streamline our messages and get them across, falling too quickly to fads, finding it difficult to separate wheat from chaff. The reasons are varied and multiple, but it is clear that technological prowess isn’t proportionally resulting in unquestionable progress in a lot of cases.

All this, to me, point to an increasing inability to innovate and deliver value when it should have been relatively easier and cheaper to do so. Why is this happening? How come we can’t seem to do better, despite getting access to ever better and cheaper tools and learning?

I just read an article about a new uncertainty that’s going to hit businesses that ship user-facing software solutions built on the Java platform. Many who invested in building IP around user solutions, will likely face large bills or tedious legal procedures. This will come as a shock surprise to many, who never considered the scenario.

Fluff, stuff and veneer

Products can be categorised in three broad sets, based on the proportion of fluff, stuff, and veneer in their structure. This can be seen in the picture below.

distribution of fluff, stuff, and stuff

What really makes a difference is stuff, that is the true substance. Fluff is often added to help with margin. Veneer makes it easy to sell, may also help with the margin. Users are more naturally looking for (a.) type of products, but this is often not the case. Companies that offer (a.) type of products usually have more affinity with value, have more empathy, and can learn to adjust to changing times. Companies offering (b.) products also have decent chances to respond when the environment changes. However, those only dishing out (c.) products will suffer most in times of change. The latter group builds on thin air and is promptly exposed, they may be adept to fad.

What about infrastructure?

If infrastructure is at the core of what a company sells, then it may well be stuff. Even then, there is value in working out how much fluff and veneer it may contain. In other cases, if infrastructure is determined to be a key part of the differentiator, then it should still be considered as stuff. When that is also not the case, then infrastructure may well be part of fluff and should be given a lot of scrutiny. A key consideration is thus, how do you determine what is fluff, stuff or veneer? In which part are you spending most of your resources, stuff, fluff, or veneer? How do these spending proportions look like? In which one have you become very good at? These are important questions to ask.

What’s fluff for one company may be stuff or veneer for another. Other combinations apply equally. Infrastructure for one business may be veneer for another. It is quite likely that the proportions would differ significantly, even for companies serving a given market. Attempts to apply generally accepted recipes should focus around formulas and the careful gathering of input, but definitely not pre-cooked outputs that might be off in a different context.

Nimbleness

If a business strongly relies on information technology, an increasingly common case nowadays, it ought to carefully consider applying the sharing economy principles. Essentially, the path to nimbleness is paved with pay-as-you-go operating models, requiring less and less ownership of the infrastructure. The less infrastructure you own and operate, the less liability you incur, the more agile your business becomes.

Roughly, the notion of sharing economy that has taken hold in recent years, sees people increasingly ditching ownership of fluff in favour of sharing or renting. Stop owning things that may be fluff or veneer, share those instead. When applied to the context of business computing, sharing amounts to embracing cloud native solutions whereby infrastructure is put to maximum use over its allocation time.

An obvious and immediate defensive reaction I often hear is, how about vendor lock-in? That’s possibly one of the most overused red-herring these days. People are too inclined to worry, afraid of getting stuck, preferring to freeze and starve instead. That’s like worrying about your hair style while standing in the pouring rain. What’s the point in that? I don’t have enough space to discuss lock-in in this post, I’ll just say that it’s a non-issue for most businesses that find themselves on a burning platform. Even in plain sailing conditions, choice is inevitable. Whatever choice a business makes will obviously imply some kind of lock-in. Being afraid of it doesn’t change things, choosing the right kind of lock-in does. No lock-in often means going for the lowest common denominator, that should be vetted against the cost of operating such setup.

When people and companies succumb to fad, that they mostly go with the flow, there is an absence of steering. And that’s one possible reason that so few innovations are emerging out of the abundance of the opportunities created by technological progress. Likewise, the overabundance of information is creating a discernment crisis, all look the same to newcomers, experienced folks may have lapses of vigilance, deafening noise cancelling out sound judgment. Sure, we learn by experimenting, by failing as they put it. Fail fast is the motto in hip startup technology circles. But, exactly how fast should that be? At what point does it become a case of fail fast rather that an instance of quitting, abandoning? How do companies determine that it is time to fail? Some will try to copy recipes they’ve heard worked elsewhere, only to fall into a me-too trap, no realising the benefits sought after.

Leadership drive: From ‘despises Open Source’ To ‘inspired by Open Source’, Microsoft’s journey

With a change of mind at the top leadership level, Microsoft showed that even a very large company is able to turn around and adopt a customer focused approach to running a business. By announcing Nano Server, essentially a micro-kernel architecture, Microsoft is truly joining the large scale technology players in a fundamental way.

A video on Microsoft’s Channel9 gives a great illustration of the way Microsoft is morphing its business to become a true champion of open source. I took some time to pick some of the important bits and go over them.

I remember the time when Microsoft was actually the darling of developers, the open source equivalent of the day as I entered this profession. I was a young student, eager to learn but couldn’t afford to buy any of the really cool stuff. Microsoft technology was the main thing I could lie my hands on, Linux wasn’t anywhere yet, I had learned Unix, TCP/IP, networking, and I loved all of that. Microsoft had the technical talent and a good vision, but they baked everything into Windows, both desktop and server, when they could have evolved Ms-DOS properly as a headless kernel that would get windowing and other things stacked upon it. They never did, until now. The biggest fundamental enabler was probably just a change in the leadership mindset.

The video presents Nano Server, described as a Cloud Optimized Windows Server for Developers. On a single diagram, Microsoft shows how they’ve evolved Windows Servers.

Microsoft Windows Server Journey
Microsoft Windows Server Journey

Considering this diagram from left to right, it is clear that Microsoft became increasingly aware of the need to strip out the GUI from unattended services for an improved experience. That’s refreshing, but to me, it has always been mind-boggling that they didn’t do this many years ago.

Things could have been different

In fact, back in mid-90’s, when I had completed my deep dives into Windows NT systems architecture and technology, I was a bit disappointed to see that everything was tied up to the GUI. Back then, I wanted a Unix-like architecture, an architecture that was available even before I knew anything about computers. I wanted the ability to pipe one command’s output into the input of another command. Software that requires a human present and clicking on buttons should only be present on the desktop, not on the server. With Microsoft, there was always some windows popping up and buttons to be clicked. I couldn’t see a benefit to the user (systems administrators), in the way Microsoft had built its server solutions. It wasn’t a surprise that Linux continued to spread, scale and adapt to Cloud work loads and scenarios, while Windows was mainly confined to corporate and SMB environments. I use the term confined to contrast the growth in departmental IT with Internet companies, the latter having mushroomed tremendously over last decade. So, where the serious growth is, Microsoft technology was being relegated.

Times change

When deploying server solutions mainly covered collaboration services and some departmental applications needs, people managed a few number of servers. The task could be overseen and manned by a few people, although in practice IT departments became larger and larger. Adding more memory and storage capacity was the most common way of scaling deployments. Although, still rather inconvenient, software came in CD-ROMS and someone had to physically go and sit a console to install and manage applications. This is still the case for lots of companies. In these scenari, physical sever hardware are managed a bit like buildings, they have well known names, locations and functions, administrators care discriminately for the servers. The jargon term associated to this is server as pet. With the best effort, Data Centre resource utilisation remained low (the typical figure is 15% utilisation) compared to the available was high and large.

Increasingly however, companies grew aware of the gain in operations and scalability when adopting cloud scaling techniques. Such scaling techniques, popularised by large Internet companies such as Google, Facebook, Netflix, and many others, mandate that servers are commodities that are expected to crash and can be easily replaced. It doesn’t matter what a server is called, workloads can be distributed and deployed anywhere, and relocated on any available servers. Failing servers are simply replaced, and mostly without any downtime. The jargon term associated to this approach is server as cattle, implying they exist in large numbers, are anonymous and disposable. In this new world, Microsoft would have always struggled for relevance because, until recently with Azure and newer offerings, their technology just wouldn’t fit.

the voice of the customer
the voice of the customer

So, Microsoft now really needed to rethink their server offerings, with a focus on the customer. This is customer-first, driven by user demands, a technology pull, instead of the classical model which was a technology-first, I build it and they will come, a push model, in which the customer needs come after many other considerations. In this reimagined architecture, the GUI is no longer baked into everything, instead it’s an optional element. You can bet that Microsoft had heard these same complaints from legions of open source and Linux advocates many times over.

Additionally, managing servers required to either sit in front of the machines, or firing up remote desktop sessions so that you could happily go on clicking all day. This is something that Microsoft appear to be addressing now, although in the demos I did see some authentication windows popping up. But, to be fair, this was about an early preview, I don’t think they even have a logo yet. So I would expect that when Nano Server eventually ships, authentication would no longer require popup windows. 😉

the new server application model
the new server model, the GUI is no longer baked in, it can be skipped.

The rise of containers

Over last couple of years, the surge in container technologies really helped to bring home the message that the days of bloated servers were numbered. This is the time when servers-as-cattle takes hold, where it’s more about workload balancing and distribution rather than servers dedicated to application tiers. Microsoft got the message too.

microsoft nano server solution
microsoft nano server solution

I have long held the view that Microsoft only needed to rebuild a few key components in order to come up with a decent headless version of their technology. I often joked that only common controls needed rewriting, but I had no doubt that it was more to do with a political decision. Looking at the next slide, I wasn’t too far off.

reverse forwarders
Reverse forwarders, a technical term to mean that these are now decent headless components

Now, with Nano Server, Microsoft joins the Linux and Unix container movement in a proper way. You see that Microsoft takes container technologies very seriously, they’ve embedded it into their Azure portfolio, Microsoft support for Docker container technologies.

Although this is a laudable effort, that should bear fruits in time, I still see that there is a long way to go before users, all types of users, become truly centre for technology vendors. For example, Desktop systems must still be architected properly to save hours of nonsense. There is no reason why a micro-kernel like Nano Server wouldn’t be the foundation for desktop systems too. Mind you, even with multi-core machines with tons of memory and storage, you still get totally unresponsive desktops when one application hogs up everything. This shouldn’t be allowed to ever happen, user should always be able to preempt his/her system and get immediate feedback. That’s how computing experience for people should be. It’s not there yet, it’s not likely to happen soon, but there is good progress, partially forced by the success coming from free and open source advocacy.

If you want to get a feel for how radical Microsoft has changed their philosophy, and you are a technical minded person, this video is the best I’ve seen so far. You will see that the stuff is new and being built as they spoke, but listen carefully to everything being said, watch the demos, you will recognise many things that come straight from the free open source and other popular technology practices: continuous integration, continuous delivery, pets vs. cattle, open source, etc. I didn’t hear them say if Nano Server would be developed in the open too, but that would have been interesting. Nano Server, cloud optimised Windows server for developers.

Remove unnecessary layers from the stack to simplify a Java solution

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. 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.

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.

 

Trying to oppose Open Web to Native App Technologies is so misguided that it beggars belief

Open web is not in opposition of native apps. There is just one single entity called Web, and it is open by definition. There are numerous forms of applications that make use of Internet technologies, a subset of such Internet-based technologies serve the web. You get nowhere trying to oppose those two things.

People who ought to know better spend valuable energy dissing native app technologies. I’ve ignored the fracas for a long time, finally I thought I’d pen a couple of simple thoughts. I got motivated to do this upon seeing Roy Fielding’s tweets. I also read @daringfireball’s recent blog post explaining in his usually articulate way how he sees Apple in the whole picture. Here, I just want to look at a couple of definitions, pure and simple.

To claim that open web technologies would be the only safe bet is akin to saying that all you would ever need is a hammer. Good luck with that if you never come across any nails.

I think both are very good and very useful in their own right, one isn’t going to push the other into irrelevance anytime soon because they serve different use cases. The signs actually are that web addressing model, by way of URIs, might get challenged soon once Internet connected devices start to proliferate (as they’ve been hyped to do for some time now). So, I actually think that a safer bet would be Internet Technologies, Web could increasingly be pushed into a niche. But ok, I actually didn’t intend to get in the fray.

Incidentally, I only see claims that native platform apps would be some kind of conspiracy to lock users down, but apparently open web would be the gentlemen benevolent dictator’s choice. I am skeptical in the face of such claims, because Mother Teresa wasn’t a web advocate for example. I remember that Apple, who triggered what-you-know, initially only wanted people to write HTML apps for the iPhone when it launched. It was only when they got pressured by developers that they finally released native SDKs. That’s such a terrible showing for a would-be mal-intended user-locker.

There is no such thing as an open web versus anything else. There is just the web and then there is an ever growing generation of native platform apps that also take advantage of Internet technologies. That’s it. Trying to oppose those two things is just rubbish. Plainly put. If something is a web technology and actually adheres to the web definition, it can only be open. A close web technology would be an oxymoron, the definition doesn’t hold. If something is built using Internet technology, it may borrow web technology for some purposes, but it is not part of the web per se.

In the instances where web technology is best fit, it will continue to be that way and get better. Conversely, in the  cases where native platform apps work best, those will continue to get better and may use the Internet. There is a finite number of web technologies bound by the standards and specifications implemented. But, there is an infinite number of native app technologies since the implementers can write anything they like and get it translated to machine code following any protocol they may devise.

The Web doesn’t equate to the Internet. There are open and closed Internet Technologies, but there isn’t such a thing for the Web. The Internet contains the Web, not the other way around.

In the outset, there is a platform battle going on where parties are vying for depleted user attention. In such battles, every party attracting people to their platform is self serving and can make as much morale (or whatever you call it) claim as any other. The only exception are those set to gain nothing in getting their platform adopted. There aren’t any of those around.

My observation of the ongoing discussions so far is simple. Some individuals grew increasingly insecure of having missed the boat on native platform apps. Whatever the reason, including own choices. Some other individuals, a different group, burned their fingers trying to follow some hypes, learned from that and turned to native platform apps. The two groups started having a go at each other. That got all the rousing started, everyone lost their cool and indulged in mud slinging. But there is no point to all of this.

If you are building software intended to solve a category of problems, then the most important technology selection criteria you should consider is ‘fit for purpose’. Next to that, if the problem is user bound, then you want to find the most user friendly way of achieving your aim. If you do this correctly, you will invariably pick what serves best the most valuable use cases of your intended audience. Sometimes this will work well with web technologies, sometimes it won’t, and other times you will mix and match as appropriate.

I don’t see web technologies being opposed to native app platforms, at all. Whatever developers find more attractive and profitable will eventually prevail, and use case is the only metric that truly matters. It is understandable that any vendor should vie for relevance. That’s what’s at stake, and that is important to everyone. It’s only once people and organisation would face up to this cold fact and start talking genuinely that they begin to make some progress.

 

Marrying Technology with Liberal Arts, Part II

People whose mental memory is sharpened by one kind of activity, tend to do poorly when facing an opposing kind of activity, and vice versa. Liberal Artists are not expected to brag about efficiency and effectiveness, or even economical. Conversely, Technologists will not be taken seriously if they start dwelling on aesthetics. Even if it were aspirational for one side to claim value attributes of the other, they are likely to face an uncertain journey of reconversion, adaptation, reinvention. At an individual level this is hard at best, at an organisational level such aspirational journey could quickly become daunting, you have legions of people and habits to convert into totally alien habits.

In a earlier post, I started exploring this notion of marrying technology and liberal arts. If you follow information technology closely, you certainly know who got famous for making such a claim. Even if you do, I invite you to bear with me for a moment, join me in a journey of interpreting and understanding what could lie behind such an idea. It’s a fascinating subject.

This is not about defining anything new, let alone appropriating someone else’s thoughts This is just an exploration of the notion, to get an idea of the motivations, challenges and opportunities that such a view would generate.

In the last post, I mentioned that there were challenges and pitfalls when attempting to marry technology with liberal arts. Let’s have a look at some of these challenges and pitfalls.

Let’s imagine that the journey involves two sides, two movements, starting at opposing ends and moving towards each other, converging towards an imaginary centre point.  On one side of this journey are The Technologists, thereafter Technologists. On the other side are the Liberal Artists, thereafter called Liberal Artists. The imaginary point of convergence is thus User Needs and Wants, that’s what both sides are striving for. Herein lies an important first chasm:

  • The products generated by Liberal Artists want to occupy our minds and souls, capture our imagination, give us comfort and feeling of security, entertain our fancies, give us food for thoughts. Of essence here are issues such as aesthetics, forms, feelings, comfort, feeling secure or insecure, want, etc. Liberal Artists want to make us feel and want things, trigger our imagination, provoke our thoughts. Liberal Artists might not necessarily concern themselves with practicality – this is not to suggest that they would never do because clearly whole legions of them do, but just that it might be a lower priority concern.
  • The products generated by Technologists want to help us carry out some essential activities. The premise here is that something needs to be done, something that is perhaps essential, something that is unavoidable. The technologist has done her/his job if such an activity could be carried out with the tools created and the techniques devised, considerations such as aesthetics and friendliness might come at a at later stadium, if at all.

By virtue of them starting at different places, Technologists and Liberal Artists have different contexts, different set of values, different views of the world, not necessarily completely alien to one another but definitely having their minds occupied in completely different ways. They face different sorts of challenges. Because we are shaped by our environments, we can grow to become utterly different people. Technologists and Liberal Artists often grow to become very different  people.

Liberal Artists have their own activities,  attributes and aspirations. In no particular order, nor  an exhaustive list by any stretch of the imagination:

  • Crafting is the primary activity, the outcome could be more personal, intimate, often some form of impersonation or expression of the liberal artist.
  • To be loved, to be adopted and to entertain the patrons.
  • To be perceived to have good aesthetics, aesthetic in this sense could come in the form of something that is pretty, beautiful. Alternatively, this could be something very ugly, repulsive, contrary to accepted beliefs and wisdom. The aesthetics may manifest itself in the look, the feel, and the smell.
  • To provide feel good, feeling different if not somewhat superior, or otherwise convey distress, pain, anger, or other high emotions, especially when dawned in artistic expressions

Technologists also have their activities, attributes, and aspirations. Again not in any particular order, certainly not exhaustive either:

  • To be perceived to be effective and efficient.
  • Productivity is an important driver, this is more about Taylorism, automation, continuously seeking to make things faster and cheaper.
  • To be making durable products, to be providing effective services
  • To get a job done in an economical way.
  • Attributes such as fast, powerful, high performing, are the typical claims that are made.

It is not necessary to go any deeper before one starts to see some of the challenges that all sides/parties face: the  areas of strength for one side automatically represent the perceived or real weakness points of the other side. This is trivial. People whose muscle memory is sharpened by one kind of activity, tend to do poorly when facing an opposing kind of activity, and vice versa.

Liberal Artists are not expected to know much about efficiency and effectiveness, or the economical. Conversely, Technologists might not be taken seriously if they start dwelling on aesthetics. Even if it were aspirational for one side to claim value attributes of the other, they are likely to face an uncertain journey of reconversion, adaptation, reinvention. At an individual level this is hard at best, at an organisational level such aspirational journey could quickly become daunting, you have legions of people and habits to convert into totally alien habits.

Liberal Artists and Technologists are sometimes competing for the same resources and spaces, most of the time they are not. In fact, the two sides address complimentary wants and needs, they are frequently found to be collaborating but not competing. For a wide variety of their activities, Technologists and Liberal Artists rely on each other, one could be found making tools that the other would put to use.

If Technologists and Liberal Artists are collaborating to address user needs, aren’t they already somehow “married” then? Aren’t they solving different but complimentary problems? Does it make sense to talk about bringing them closer together?

Tails, privacy for anyone anywhere. Makes sense to me

I often felt that visualisation has the potential for a more secure computing than we have seen so far. Project Tails is a good move in that direction, and is in effect a great virtualised secure solution. I am encouraged to see this happening.

I wrote before in this blog that I felt security and privacy were underserved by current technology offerings. This project lays out a vision that is very close to how I imagined it, and it looks promising.

Project Tails Logo

Django CMS is the simplest and most elegant Web CMS I’ve seen lately

Recently I have deep-dive compared a lot of web content management (CMS) products. I’ve found that Django CMS is the simplest and most elegant way of authoring semantic HTML content on the web.

Recently I have evaluated a lot of web content management solutions, all of them open source, almost exclusively on Unix like systems, I haven’t seen anything as simple and elegant as Django CMS. I took it for a spin, it’s polished, really designed to solve fast turn-around web publishing needs. It does that brilliantly, no question about that. I particularly like the way they make all the authoring tools and widgets disappear when not in use, so that you are always looking at your content exactly as it will appear when  published.

There is one thing, in a lot of cases, to truly appreciate any piece of work, one must have a practical understanding of the challenges involved in making it. This is also true for software. Content management, web content management isn’t a sexy topic. However, without such systems it would be tedious to maintain an online  presence, difficult to consume a lot of the content produced daily by legions of people.

I was just going to use one of the web CMS products I’ve known for a long time, to power one of my web sites. In the process, I realised that I have not done any proper re-evaluation of the products available for a while. I wanted to try that first before settling on something. I thought perhaps I should go open minded about it, include a broad selection of products. As time is precious, I decided to focus on Unix/Linux based solutions for now, because that is also my target deployment platform.

For my purpose I went back to implementing a few other web CMS products, namely: Zotonic (Erlang based), Liferay Portal (JCR), Magnolia (JCR), dotCMS (JCR), several static publishing systems such as Pelican (Python), Jekyll and Octopress (Ruby), and of course WordPress (PHP, which powers this blog). Django CMS best all these in terms of simplicity and its focus on making semantic HTML content authoring a bliss. To be fair, it’s hard to compare these products I just mentioned since each actually aim to cover a breadth of needs that might be going well beyond web CMS (portal for example). But I had narrowed my scope down to the authoring and publishing processes only, web CMS functionality alone, that makes it possible to come up with a fairly reasonable comparison.

I am not yet done evaluating web content management systems, I still have on my to-do list Prismic.io (an innovative Content Repository As A Service) and a couple of .NET based web CMS.

More to come on this topic sometime later. I probably have enough material to publish a small document on this subject. We’ll see if/when I get to that. But for now, I definitely maintain that Django CMS is the most polished solution for folks looking for a simple and attractive web CMS software.

With 8, Java is distancing itself from the ‘new Cobol’

Java 8 has introduced a lot of welcome improvements, justifying that I take back my earlier statement that it was ‘the new Cobol’, but I see there is room for improvement.

It is time to amend a post I made a while back, where I supported the idea that Java was the new Cobol. At that time I had given up any hope to see a decent modernisation of the language in a foreseeable future. That future is here and Java has been modernised.

If you look at Oracle’s site, a few points stick out:

  1. Lambda Expressions: this improves some of the building blocks considerably.
  2. Nashorn and Javascript: this is a nod to the success of NodeJS

To me, those two points justify a new blog post to adjust my earlier statement. I still see opportunities for improvement in the syntax itself, take the following example (from the same Oracle article linked above):

Set artists =
        albums.stream()
            .filter(album -> album.getTracks().size() < 8)
            .map(album -> album.getArtist())
            .collect(toSet());

Wouldn’t this read better in the following way?

Set artists =
        albums ->
            stream
                filter tracks.size < 8 
                map artist Set

Notice a lot of the unnecessary characters removed, because the compiler would be able to infer them. This isn't far off from the language's current standard, yet it could have dramatically improved the code readability. I know, there's a huge legacy to cater for and language design requires serious work. This type of simplification wasn't out of reach, it is what you typically see in the attractive programming languages like Haskell, OCaml and others.

So, Java 8 has introduced a lot of welcome improvements, justifying that I take back my earlier statement that it was 'the new Cobol', but I see there is room for improvement.

The very employable leave their mark well beyond their own office

Tim Bray is leaving Google. He is letting it be known in a marvellous example of humility and thoughtfulness of the scientist penning a dissertation. This is a good way to leave a company.

As a follow-up to my posting on people who rant as they quit a job, I stumbled upon a perfect example of how to do it right. And this is the case for Tim Bray’s post on his leaving Google.

If the name doesn’t ring a bell, check out Wikipedia (Note: do read Wikipedia disclaimers, I only know Tim through his great work that large swathes of the IT industry depend upon daily).

The unemployable typically go out with a bang

Leaving an employment with a bang might be a way to let some steam off, but it also might be limiting a person’s chance of landing the next employment role. Before you post a rant, sleep on it and see if you would still do it the next day.

Every now and then someone departs a job at a well known company then blog about all they’ve seen as evil at now former company.  It usually triggers a flurry of commentary. This is just what happened with a former Apple employee blog posting. This is rarely a wise thing to do, but hey, move fast and break things doesn’t mean there would be no consequences.

While such essays might amuse the gallery, gain the author some form of  ephemeral fame, they may also have an influence on such person’s employability. For example, whenever I hired someone, I often took what they said about their former employers to be a template of what they would eventually say about me and my company. In most cases I don’t hire a person that slags their former company off, it’s rarely a good sign.

People might have, legitimate or not, reasons to rant about former employment. In many cases, it says more about the person than the job they’ve just left. Obviously I don’t know if there’s any legitimate reason for this person to have ranted the way he did. I am just commenting on the act, as a cautionary tale for the would-be hipsters that might be tempted to copy-cat at each opportunity.

After all, if/when some reprehensible activity should be going on at a company, whistleblowers might help bring to light such misdemeanours. That could be ultimately beneficial to the society. But, in all likelihood, for every whistleblowing action there’s probably  dozen of frustrated over-reacting actions.

I wouldn’t go out with a bang if I have hope to land another job somewhere else in the future. There are other ways too. It could be much more productive, while still in employment and actually not fearing of getting fired, to internally vent any frustration one might have. It’s also good to check if the reasons for your frustrations are shared by many or not. If nothing helps then leaving with the good memories is often a better attitude. After all, while at an employment one enjoys some of it and are hoping to help build something up.

If I have a few words for the up and coming professionals: Look for reasons to celebrate something, consider any crap to be the part of unavoidable combustible fuel for moving forward.