Eclipse Che looks promising, the cheese’s moved around

A very quick look at Eclipse Che shows a promising concept. I thought let’s have a look. When I’m serious about a technology I take the time to read the documentation before diving in. In this case I wanted to follow the typical journey that most folks take, just dive in, never bother with documentation, upon the first hurdle start complaining like a bewitched mad dog with an exaggerated sense of entitlement – ok, minus the last bit of attitude.

I installed Eclipse Che, easy peasy. Then I fired it up. Oops! I can’t connect to it. The first time ever I couldn’t just use an Eclipse release after installing it. It was time to look under the bonnet. So I did. I saw it’s deployed on Docker… What!? Why!? Ahem, ok, move on. I stopped it, also stopped Docker Machine. Then I manually started Docker Machine, readied the environment, then started Che again. This time I tried http://localhost:8080 and I got in. Cool. Everything looks familiar, except it’s all now in one web browser window.

Time to look back and reflect on what I’ve learned here. The fact I couldn’t connect the first time might have to do with RTFM that I didn’t. Anyway, not a big deal, it took me a couple of minutes.

Nothing much to it, just an IDE inside a web browser. It’s the same old thing, in a new cloak. The most obvious/visible differences I spotted can be depicted in a simple diagram, BEFORE and AFTER.

before_reinvention_classic_eclipse_ide

With Eclipse Che,

after_reinvention_eclipse_che

I’m oversimplifying, but highlighting the most visible changes. It seems that when we get to modernising our software stack, adding Docker and JavaScript are passage-obligé. So, somehow people think that deploying a Java app on Docker is a better architectural choice than only targeting the JVM? In my case, since I’m using a Mac, which runs OSX, hence requires an extra VM (VirtualBox in my case) in order to run Docker containers, I actually end up with a more complicated stack for just an IDE. I don’t know where this is going. Now trying the IDE.

eclise_che_ide_in_action

 

I haven’t gone further than this. The concept of Developer WorkStation Server can be interesting for pair programming. The Server option is perhaps more appealing. I just wonder why this couldn’t be just a Java App and why Docker was actually necessary.

A brave, new post open source world, or Fly-by Software License pollution

I just read an interesting article with the title We’re in a brave, new post open source world. The article goes into the evolution of Open Source movement and the numerous licensing policies. On particularly notable phrase I saw read as follows:

…if you use someone else’s code revision from Stack Overflow, you would have to add a comment in your code that attributes the code to them.

What this means is that, if a developer uses a snippet of code taken from StackOverflow, and fail to add such an attribution, then technically the project might be in breach of StackOverflow license. I am curious how many organisations actually check this.

The whole article is a good read.

Original Article: We’re in a brave, new post open source world — Medium

Open source is a development methodology; free software is a social movement. by Richard Stallman

I just read a nice essay by Richard Stallman with the title Why Open Source Misses the Point of Free Software – GNU Project – Free Software Foundation. A chosen quote from this essay poses perfectly the problem

Open source is a development methodology; free software is a social movement.

Most people probably aren’t even aware of this difference. I never understood why and how the term open source came to be applied to hardware, government and many other areas when in fact even the English language doesn’t see any notion of source in such contexts.

The article I refer to is concerned about correct definitions, I want to look at some  of the misunderstandings.

There is an angle to this discussion, a lot of people and organisations look to Open Source Software (OSS) in search for cheap (but not cheerful) opportunities to solve their problems.  You can’t blame them for it, but this can raise several issues. I will ignore any moral aspects for now, and focus on a few practical implications.

  • Some individuals or organisations release their work as Open Source with the explicit intention to invite others to contribute to it. This is often an acknowledgement that one’s work can be bettered and perfected if others would gain access and be allowed to contribute.
  • By releasing a work as open source, there is no implicit or explicit guarantee of quality or defect. It just means use it at your own risks, your contribution would be appreciated if only in terms of signalling any defects found, or improvements that you might have been able to add to it.
  • FOSS doesn’t  opposed nor condone gainful use. Statistically however, there exist far fewer people and organisations able to contribute than those who actually use OSS. This is well understood and accepted by most. However, it is astonishing to see some people throwing a tantrum and launching on diatribes when they get frustrated by some open source software. This is just plain crazy behaviour, they not only miss the point and are showing preposterous entitlement that deserves to be frowned at.
  • Increasingly, many organisations are using OSS as a mean for attracting and retaining talent. This is an instance that stretches the notions of free and open in an interesting way, a subtle form of free promotion and marketing.

Article: Why Open Source Misses the Point of Free Software – GNU Project – Free Software Foundation

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.

 

Macaw is just what I wanted

I get inspired when I can visually tinker with experience design. This is the reason that Macaw.co got my attenion and I adopted it almost immediately. I finally found a product that allows me to do that, from Macaw.co, a recently launched rapid web UI prototyping tool. It’s got its warts, being brand new, but I like it and I expect it to do well.

I get inspired when I can visually tinker with experience design. This is the reason that Macaw.co got my attenion and I adopted it almost immediately.

Macaw user interface
blank canvas in Macaw

I hailed Twitter Bootstrap when it was launched. It helped me and many others  with UI prototype work. Some seemed to prefer deploying Bootstrap default experience with little change. I don’t like that much. I would often customise the look & feel to make it a bit proprietary. Over time I came to realise that I didn’t particularly enjoy tweaking and tuning the myriad features exposed through the LESS assets. There is nothing wrong or limited with Bootstrap per se. Web browser development tools are also a good help for quickly trying out UI ideas. There are many online sites such as codepen that help you experiment with snippets and small features. These are all fine but, I just wasn’t getting inspired by any of it. What these tools lacked – that would get me excited – was the ability to just draw my idea of an entire page as I envision it, tinker only with the drawing, and then immediately get the code behind without resorting to any extra artifices. There is an emerging bunch of tools that allow you do that in a cost effective manner.

I discovered that my way of tinkering with web design worked better if I could do it visually. As I examine visual elements I get more ideas and I can iterate quicker. Going back and forth to the LESS source files and tuning design was too slow to entice me. I am not a designer by education so I make lots and lots of tweaking before I like something. As a kid I used to love drawing things. I would typically start by drawing a line or some randomly curved shape, then as I added to that some kind of shape would start to emerge and I would finalise my drawing that way. If I ended up drawing a horse or a house that was usually not even in my mind when I started. That was my way of playing with pen and pencil. It seems that is also how I can enjoy doing UI work.

For a long time I relied on Omnigraffle, not really a web design tool, and Pixelmator, also not a real UI web design tool. I’ve used Adobe FireWorks on and off for years. FireWorks is a nice tool but it never got me excited much. It seemed that I couldn’t find any product out there that I would want to stick to. That changed recently.

There’s a new product that allows you to visually design what you want, then get a baseline html and css code that embodies that. It’s called Macaw. I saw a brief video announcing its features and immediately decided to buy a license when it shipped. I got a copy at the beginning of this month, started using it, and it felt right away that this was how I always wanted to work with web design.

Aside from the immediate feedback, one benefit I particularly appreciate with Macaw is that the authoring assistants are intuitive and help you just the right way. As a non-negligeable bonus it generates a minimal base code that can be directly fed into an application design. Here are two radically different design I made with it.

macaw - design prototyping example
macaw – design prototyping example
Web UI Prototyping with Macaw
Web UI Prototyping with Macaw

I create these artefacts just like I would in Omnigraffle, however the whole experience of manipulating the elements fits perfectly with the job: desiging a web front-end. Once done, the code that Macaw generates is clean and minimal, it does link to jQuery though. So, I could just take the code I get from this and embed it in the application code. This approach is more to the point, and more efficient than say using a free html template downloaded from the web.

macaw generated css
macaw generated css
macaw generated source files
macaw generated source files

Before Macaw I tried several products of which many are online solutions. I won’t list them since this isn’t really a posting on product comparison. While lots of nice experiences are available I was often disappointed with the code that got generated. The problem I expect to solve with these tools is to get started with a clean slate and be able to repurpose code with minimal effort. This means that I didn’t want any dependencies in the code and that seemed almost impossible to achieve. For this reason I couldn’t settle for anything in particular and kept on to a traditional model where the UI design assets were fairly remote from the code produced to implement it. I don’t need to do that anymore, I can rely on Macaw to visually tinker with prototype designs.

Of course when it comes to serious web crafting like making animations or complex interactions Macaw wouldn’t fit the bill. Webflow for example seems to be another nice one, particularly suited to animation rich UIs. The produced code embeds relatively proprietary JavaScript code. And the business model seemed to be favourable to repeat uses or even hosted solutions. For my particular needs I saw these as compromises I didn’t really want. And honestly I would just hire a professional designer if the experience is complex or that it needs to be very sophisticated. I am an IS&T architect who believe in all-round craftsmanship. I want to deliver the whole solution. If it needs to look spiffy and flashy then I call out to professional designers.

Having used the product for a little while now, I am convinced that Macaw is the tool that I was missing so far. I can now deliver complete end-to-end experiences to clients with the tools that I am comfortable with.

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.

Recent Ruby on Rails SQL injection vulnerability: lack of developer awareness, type safety

The much publicised Ruby on Rails SQL Injection vulnerability is also down to a lack of developer awareness of secure coding practices.A type safe programming language would have protected against this vulnerability too. An id is typically an auto-incremented database field, a number. So, any attempt to pass a spurious SQL string in such function would have been rejected by the type safe code. Ruby isn’t type safe.

The recently publicised Ruby on Rails SQL injection vulnerability is really down to a single issue: many developers are not aware of hardening their code. The article linked at the bottom of this post showcases both issues.

Lack of awareness of Rails secret token file

This file, as its name implies, is where the token used to further protect user sessions is configured. Inquisitive people would spot such a file quickly and ensure they won’t expose it where it shouldn’t be. Apparently many are blissfully ignorant of this file and they just push everything to Github.

The First rule of SQL injection 101

If you examine how SQL injection is achieved, it’s just a very basic mistake that has been known forever: unchecked input parameters.This points to where SQL injection could occur

A security aware developer, writing this single line of code would wonder what could happen if the input parameter were to be manipulated, and whether that were even possible. And that is the second awareness awareness that would have caught the issue.

A type safe programming language would have protected against this vulnerability too. An id is typically an auto-incremented database field, a number. So, any attempt to pass a spurious SQL string in such function would have been rejected by the type safe code. Ruby isn’t type safe.

Here is the blog that apparently uncovered this recent vulnerability: let me github that for you.

Why Microsoft Typescript is a breath of fresh air in web application front-end development

Typescript is an elegant solution to a really annoying issue: Javascript code sprawling into a massive spaghetti. If you are a programmer who writes web applications, don’t wait to learn about scaling JavaScript the hard way, start with Typescript and you won’t regret it.

Anders Hejlsberg is one of the most astute thinker alive in the programming language world today. So when he comes up with something I take a careful look at it. Typescript is his latest creation, I watched his presentation video and I really liked what I saw.

Unless you’ve been involved in web application development at scale, you won’t realise what Typescript brings to the picture. It is a very elegant solution to a really common problem: Typescript helps in writing large Javascript code without ending up with a monster spaghetti that even the authors hate to look at.

Naysayers will snarl, isn’t this yet another Microsoft embrace and extend effort? Who needs a new JavaScript like language?

Microsoft lovers would rave.

But, any fanboim set aside, this is a tremendous effort and it is coming from a truly “new Microsoft” that some are still too blind to see. This is a nice case of “embrace and extend” that should be applauded. The team that made it took care of the following essential things:

  • keep the learning curve low and smooth: Typescript is actually just JavaScript, if you think about it, so no new language to learn
  • make it fit within developer’s work flow: the developer can keep his beloved tools and still get the benefits of a less error-prone (thus less bug) development
  • keep it future proof: Typescript team appears to have adopted the open standard that governs JavaScript itself (EcmaScript if you don’t know), so as the standard matures Typescript would have already been there or can easily adjust with changes to the specifications
  • make it open for the wider community: the language and its tooling is all available under a well liked Apache open source License, anyone can use it and extend it, no fear of vendor lock-in here

If you are a programmer who writes web applications, don’t wait to learn about scaling JavaScript the hard way, I highly recommend  Typescript to you. If you already know all the horrors of large JavaScript code, check this out anyway and you will learn something that might even make you want to switch. I definitely plan to integrate this in my tool-chest and the solutions that I am building.

LMAX Disruptor: Mechanical sympathy, a quality of great C/C++ programmers, rediscovered in Java world?

We learn this all the time, testing is a fundamental part of crafting great software – yet it seems to often be relegated for all sorts of reasons. This oldish article by Martin Fowler on LMAX Disruptor shines a light on the value of performance testing, and mechanical sympathy as a crucial skill for crafting great software solutions.

Two interesting take aways from Martin Fowler’s article on LMAX are: the importance of performance testing, and mechanical sympathy.

Testing is actually one of the most efficient ways of learning modern software systems, so if nothing else it’s going to bring that edge to people. Mechanical sympathy, on the other hand, is one of the enduring qualities of great C/C++ programmers, I’d say that in that case the expression covers a combined affinity with the C++ language standard, the vendor compiler idiosyncrasies, and the particular OS being targeted.  I could infer this back in the 1990s as I read books by folks like Herb Sutter, Stan Lippmann, or Scott Meyers. At the time I had a good understanding of the x86 architecture and could see how mechanical sympathy played out – though, I didn’t know the expression until I read Martin Fowler’s blog.

I’ve been focusing on actor based programming models last year or so, I think the LMAX Disruptor is definitely a very interesting and exciting concept.

Google Go is good to go now. Where are all the libraries to go with it?

It seems that Google Go would suit scaling issues that are mainly due to application execution (CPU) bottlenecks, so not disk or network performance bottlenecks which are actually more common. Targeting those who’d have to otherwise program in C means that Google expects a niche market for this language. Companies like Facebook and Twitter may have good use cases, but those don’t look to be the best of friends with Google nowadays. Would traditional enterprise development groups rush to adopt Google Go? I doubt it.

I read an article on ReadWriteWeb, commenting on Google’s announcement that their Go language reached 1.0. I took a quick look, as I did when it was first publicly announced. As then and now, it looks interesting but I personally can’t see it fit in any of the initiatives I am involved in at the moment.

One thing that is constant, and actually infuriating with these new programming language announcements is the way they are presented. Many would showcase a Hello World, Fibonacci, writing a Blog Web site, or writing a To Do List application. I don’t know about you but I’ve rarely come across a real-world problem involving any of these examples. I think it as a form of escapism.

Another problem with any new programming language is that people have to go through a stage of “brainwashing” before they become really productive. That may be luxury for a lot of people at the moment. And lastly, even if a language is great you would be swimming upstream unless you could count on a large amount of libraries to tap into. In that department, the recent wave of JVM based languages are doing well. Even Microsoft, who normally have a massive install base, understood this and is working very hard to bridge its languages with the open source communities out there. I am not yet seeing how Go will help developers get the most out of existing libraries. This also makes me think that it is not targeted at the larger developer community.

It seems that Google Go would suit scaling issues that are mainly due to application execution (CPU) bottlenecks, so not disk or network performance bottlenecks which are actually more common. Targeting those who’d have to otherwise program in C means that Google expects a niche market for this language. Companies like Facebook and Twitter may have good use cases, but those don’t look to be the best of friends with Google nowadays. Would traditional enterprise development groups rush to adopt Google Go? I doubt it.

I am curious how the reactions would be like over next few months.