Yeah, I got a framework for that …

trepenationDo you remember when they loudly pronounced “vinyl was dead”? Be it records, testing or development framework, whenever something new comes along, there follows an army of doom-merchants. Either for the kick, or for profit, pronouncing something is dead is a easy way to get peoples’ attention. After all, what is better than something that’s past being kicked into touch, by something new. Maybe working out first if something new is better, or in fact, an over-hyped pile of crap. If you have worked in tech for 10 years, you will know what I mean when I say I literally wince in pain, when I hear someone’s warbling on about the latest framework product, that just blows away the competition. Even if the product wouldn’t even exist, if it wasn’t for it’s OAP predecessor (i.e. the language it was coded in).

I am reminded of time a professional colleague told me that as part of his learning of php, he built a user-friendly content management system from scratch and website templates for a client. It took him less than a month, and of course, he knows it inside and out.  I, on the other hand, chose the WordPress framework – and although implementation is quick, I still spend month of two configuring, adding plugins, refactoring plugins, etc.. Both are ways to get the job done effectively, but the smokescreen of frameworks is that they save time. They don’t. It’s two ways to do the same task. But the former provides you with something truly relevant, with no dead weight. Anyone who thinks otherwise is kidding themselves. I love WordPress, but fully aware that I also need to understand php even more than the products built on it.

Having said that, having been through the first painful few projects, I can now quickly build a customised CMS and templates very quickly using WP. I guess the point here is when you sell up to a framework, it really only shows value if you use it on future projects, not just a one-off.  One of the early mistakes I made was in the first flurry of excitement, I quickly bloated the code, as requirements necessitated plugins, some custom, some from the bewildering array of free and commercial plugins.  And many don’t manage to stay the distance, and languish through under-development, ultimately becoming incompatible with subsequent WP versions.

With development frameworks take your pick to learn, with enough fashionably named JavaScript frameworks to keep you busy in bluffing your way in IT for the rest of your life. But be wary – your career is on a knife-edge if you base it on products alone. And there is always a risk of spending too much time learning, and working with one framework. Nothing last forever, but a programming language is highly likely to outlive any product that is based on it. So feel pick Rails, Grails, Zend2, CakePHP, dotNET(?), Joomla (frameworks large and small) … not to mention the array of plugins and module they all have to extend the functionality.  But be conscious you are skipping across the surface of the tech, and what provides quicker routes, often come with more risk. If you are looking for a framework to use for your project, ask yourself why you are, before deciding.

At application level, I am wondering if there is any real valid excuse for using a framework. They don’t save time and they certainly don’t seem to save money in long-term. And there will always be compromise, sometimes at cost of client requirements. Start-ups can have valid excuse to use frameworks to accelerate initial development forward, but if you are looking something robust and future-proof, maybe you are better off with a “primitive” approach … a programming language takes a lot longer to die, than a framework.

Are we there yet?

You Are My Bot

Since when did programming language become a fashionable label? I mean, its all code and approach; no magic wands.

With all the meetups and new course the development world is buzzing with activity. But something strangely familiar and stagnant about it already. Meetups preaching largely to the converted, numerous testing and development courses that attempt to each sell themselves as THE course, older school who don’t want to move forward themselves but latch onto modern thinking as a sales and money-generating tool. The early-birds, which save you little except committing to something you may not even be able to make. Oh yes, mix with the higher echelons of technology and define your future. Though you are not defining yours, you are defining theirs. And you think the web 2.0 mentality has gone – “how can I make you make me money?”. Whether Google+ or a well-meaning group set up for enthusiasts of a particular area of technology – ultimately the individual will pay the price for a small section of people’s success, because the entire model of professional networking is wrong.

You Are My BotFinally, I am moving jaffamonkey away from simply a contractor company, and starting a “hub” of my own focused on my two areas of Quality Assurance and WordPress. Though I have to be cautious about labels such as “fashion-free” and “no Nathan Barleys”, as it is easy to slip into an ironic kudos area. But this is very much what I want from it. Take a look at Shoreditch, home to the beautiful people of technology, where Google has set up a base. There is nothing special here – people with ideas are everywhere, but because of the vacuous recent movements in technology (putting it in the realms for those who wish to affiliate rather than integrate), there are many very weak ventures of little use to anyone except those who benefit from short-term gains. Sounding familiar? Are newer generations simply getting trapped in same patterns as those they purport to rebel against? Of course they are.

When things move into a fashion zone, they automatically become part of something that is ultimately disposable. The fashion-ability determines its duration. Little consideration is made of the technology or approaches, and rarely shared. What underpins software is code, and code has evolved slowly in comparison with everything else and with good reason. It ultimately has to work, and lessons learnt over the decades have evolved to the point we are now. But now, people carry their programming language(s) like some kind of fashion badge. When it’s irrelevant. Instead of nodding towards vacuous networking, pro-actively mix with other people. You can always find an audience who will agree with anything you say. But finding a vibrant audience with questions, opinions and disagreements is far more valuable. The new “hub” will be open soon, and focus on enabling and connecting people. Not all ideas may succeed. but they can all help with our education in an atmosphere of mutual support and communication. Watch the blog …

Smarter architecture with DSL

The soup is SOA with DSL Maybe it’s time to write new language. As a programmer working at a company, you must find yourself writing same chunks of code time and time again. Sure, you build up your own libraries to reuse. And if you are going to do that, why not create a class/function to use that call that code. And you don’t need to just use one programming language. This mentality is not so prevalent in web development. A lightweight, but relevant example is virtually every website will have HTML and Javascript – Javascript is sometimes more appropriate for a given website feature, or simply only possible with it.

What we are doing by accident or by design, is writing our own languages – the fact they are based on 1 or more other programming languages is irrelevant. It feels like its time to re-address how we look at programming languages, as selling up to particular technologies is a dangerous game to play, in the long-term.

It is always a good idea to write a DSL. There is no better way of becoming a domain expert than implementing a custom language for that specific domain.
http://blog.nofail.de/2010/02/writing-your-own-dsl-with-ruby/

Although there have been many benefits of Domain-Specific Languages (DSLs) reported from both academia and industry, implementation of DSLs continue to face challenges with respect to frequent evolution of both syntax and semantics. Some languages are more geared for DLS than others (Ruby is a good example). Techniques for implementing DSLs also lack interoperable capabilities among base languages and limited tool support. Such challenges result in increasing DSL development cost and constrain DSL adoption opportunities. It’s early days – but there is no reason that companies can’t start developing a strategy for DSL projects. No room for individual project politics here – you need cohesion.

Have I been harsh on Ruby on Rails?  Perhaps – as the underlying ethos of RoR does make a lot of sense.  The phrase that always makes me wince is “I can do more with less code”.  That is not necessarily a bad thing – unfortunately the phrase also has an association with lazy development (developers). Ongoing programming library development, new helper objects, are all part of the programming evolution. But it can be done badly. You can’t have developers who only understand their programming environment from component perspective, and issue diagnosis will involve lower level understanding.

Software that used to be an entire system, has become a component, and that seems perfectly logical. A CMS (Content Management System) is one of them – a common set of features that becomes a feature itself. If your company developed software on SOA principles, you would be surprised by how much work can be save in the long-term. There are many commonly used features in application development, and none more so than on web applications. It is far easier to present requirements in form of components, and the more advanced and flexible these components are, the easier it would be to implement them in code closely to requirements. Clients are generally asked to think too granular these days – I mean, does the client really need to have an opinion on password length? There are a lot of standards on the web, and it is advisable to follow those standards.

To effectively share and reuse of your DSL, it is necessary to provide a consistent programming environment with clear set of limitations and rules. This is called the Application Programming Interface (API).  An API is an essential part of Service-Oriented architecture, as well as any other software architecture, because it can be used as independent logical layer. Below is very simple representation of SOA, which has been largely misunderstood (or more correctly, underestimated).

The key to SOA is the business logic layer (i.e. potential shared services). And this is where DSL comes in, or should do. DSL transforms programming logic, into architectural logic. Computers are only going to be as dumb as we make them.