Interesting thoughts: Frameworks are fundamentally broken

I just read this blog post, Frameworks are fundamentally broken. Many of the points highlighted resonated with me. Then I realised that I blogged about an aspect of the problem that can occur with frameworks. It was a few years back, in fact in 2010 as I just verified. I kept my post at a high level, taking the discussion above Rails and other particular paradigms but focusing on the cognitive load aspect alone.

Tim’s article calls for reflexion. My own take on the issue was triggered as I spotted a rant on Rails (of Ruby on Rails). My post is Code frameworks and ghettos, where creativity gets a lock-in

Never mind Oracle’s business as usual, Java EE has run its course anyway

Oracle might not even have to lift a hand, nature will kill Java EE for them. By nature, I mean the numerous thriving communities that keep at improving the developer experience. Developer experience is all that matters now, and Java EE has nothing to offer there.

Java EE was born out of a playbook for big vendors, in a day and age when vendor push was the norm. Java EE was never about developers, it was always about vendors. Once alternative playbooks focusing on developer experience started to thrive, that’s when Java EE started its slow and steady descent into irrelevance. And there is no stopping that trend. Everybody knows this. Oracle is simply acknowledging this fact then trying to figure out how it can remain relevant in the longer run.

Companies large and small have all come to realise that what used to be called enterprise software needs to be rethought and retooled. The most promising programming models favour an approach that gets rid of large initiatives and management units, in favour of ever smaller and more nimble concepts. These are totally antagonistic to what Java EE stands for. Furthermore, the enterprise push model has had its time and the world has moved on from that. Every large vendor is having to rewrite its business model and rethink its technology.

Java EE has perhaps joined the ranks of mainframe technology, it will survive for a long time in one form or another, but will no longer be exciting. Effectively, Java EE is out of date, its future lies in the past (if that makes sense). It has run its course and has fared well. It’s time to leave it alone and move on.

A selected quote from the article:

Oracle’s silence about Java EE has brought developer community distrust to a fever pitch.

Source: How Oracle’s business as usual is threatening to kill Java | Ars Technica

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

Qubes OS Project, a secure desktop computing platform

Given that the majority of security annoyances stem from antiquated design considerations, considering the progress made in computing, affordable computing power, this is probably how Operating Systems should now be built and delivered.

Qubes is a security-oriented, open-source operating system for personal computers.

Source: Qubes OS Project

Martin Fowler’s article is barely a year old, folks have exceeded my expectations

When I first I saw a blog post by Martin Fowler’s on the micro-services, I immediately thought that the developer community was going to go crazy about the concept. I wasn’t disappointed. But thankfully, many people caught on the mania before it got totally out of hand. Martin, in his latest blog post, is among those calling for some sanity. Read Martin’s blog post here: Monolith First, by Fowler

Martin Fowler is a brilliant technologist. Needless to say. This post is going to be a recap of some of my tweets on the subject of micro-services (or “microservices” as I see commonly being written). I would have quoted a bunch of other people instead, had I seen many. But that wasn’t the case, so I’ve got to quote myself then.

The first article I read about micro-services was on InfoQ.

Some time later, I saw a blog post by Martin Fowler’s article on the same subject. Then I immediately thought, as is typically the case, that the developer community was going to go crazy about the concept. I had the following reaction.

Naturally I value the thoughts and the content of the article. But I was merely concerned that many would jump straight in and make a total mess of a rather valuable insight. The topic gained popularity quite quickly, faster than I had expected though I couldn’t say I was surprised either. Reputed analysts picked up on this.

Time going by didn’t assuage my concerns, rather, I was only getting more and more confirmations. I thought that perhaps nobody is going to adjust perceptions and expectations until disaster stories would abound. I tweeted my thought on that.

Soon enough, people started posting thoughts on what was going on.

And, to keep this relatively short, here we are, somewhat full circle, with Martin Fowler inviting for some sanity. Martin opens his latest blog post

As I hear stories about teams using a microservices architecture, I’ve noticed a common pattern.

Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

Read Martin’s blog post here: Monolith First, by Fowler

An open source port scanner that is helping some bad guys

An open source port scanning tool, masscan, is being used to repeatedly attack my web sites. There are certainly lots of such tools widely available that even criminals with no skills can get their hands on and randomly try to break sites. IT security is a never ending quest that is best left to dedicated professionals.

Port scanning is one of those annoying activities that the bad guys may use while attempting to try and find back doors on systems. The principle is simple, find out what ports a system has left open, if you recognise any, try a dictionary like attack on these ports. All it takes is a simple bot.

Last few months, I have noticed multiple port scan attacks at my web sites from a user agent “masscan/1.0”. I dug a little and found this to be coming from an open source tool, the project on Github:

robertdavidgraham/masscan

So, it seems that some people have found this tool, and are now randomly targeting web sites with it. To what aim, I can’t tell for sure. It is certainly reprehensible to be poking at someone’s doors without their consent, everybody knows this.

I’ve also noticed lots of attempts to run PHP scripts, they seem to be looking for PhpMyAdmin. Fortunately I don’t run anything with PHP. If I did, I would harden it significantly and have it permanently monitored for possible attacks.

Most of the attacks on my web sites originate from, in this order: China, Ukraine, Russia, Poland, Romania, and occasionally, the US.

You don’t need anything sophisticated to detect these kind of attacks, your web server log is an obvious place. Putting a firewall in place is a no-brainer, just block everything except normal web site http and https traffics. You can invest also more in tools, then the question is if you’re not better off just hosting at a well known provider.

This is just one instance, and there are infinitely many, where even the dumbest criminals are getting their hands on tools to try and break into systems. Cloud hosting are getting cheaper all the time, soon it will cost nothing to host some program that can wander about the Internet unfettered. Proportionally, it is getting exponentially easier to attack web sites, while at the same time, it is getting an order of magnitude higher to keep sites secure.

I do see a shimmering light, container technologies provide for a perfect throwable computing experience. Just start a container, keep it stateless, carry out some tasks, when done, throw it away. Just like that. This may reduce the exposure in some cases, it won’t be sustainable for providing an on-going long-running service.

IT security is a never ending quest that is best left to dedicated professionals. I am just casually checking these web sites that I run. At the moment, I haven’t deployed any sensitive data on these sites yet. When I do, I will make sure they are super hardened and manned properly, likely a SaaS provider rather than spending my time dealing with this.

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

A lot of people don’t know the background or origin of the programming language that they are using. Fair enough. If frustrations become frequent however, it might be best to go back and find out the initial motivation of the programming language creators.

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 context
programming 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

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.