Dominic Burford - Professional Profile

This article[^ gives a good summary of the stages a professional software developer takes throughout their career. From junior developer right the way trough to senior developer.

What qualities should a senior developer have though? Here are my own qualities that I would expect to see in a senior developer.

At least five years working in the industry. Some people say three years is sufficient, some say at least ten. I think it depends on how much variety they have had within that time that is important. Experience from working from a variety of projects using different tools and technologies is the key.
This segues nicely into my second point. A senior developer should have a broad range of skills covering areas such as design, requirements and coding. They should be able to apply good business sense to a project. Rather than just using the latest shiny technology, they should be able to pragmatically apply the most appropriate tools and technologies to the project to ensure it meets the customer's expectations.
They should possess good design skills. They should have familiarity with design patterns and the SOLID principles.
An appreciation of the different lifecycles, and their key strengths and weaknesses. For example, when and why would you use Agile? What is Test-Driven Design and why would you use it?

In summary, a senior developer should have a wide range of knowledge, covering all aspects of the software lifecycle, coupled with a deep understanding of their current tooling. They should be sufficiently experienced that they could mentor a graduate / junior developer.

There are no hard and fast rules, so this list (or indeed any list) of qualities and attributes expected in a senior developer will always be completely subjective, but hopefully this list gives a good starting point.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] gives a very pragmatic means of implementing the CQRS pattern in a typical ASP.NET MVC application.

I came across CQRS[^] late last year when a colleague pointed me in the direction of DDD, event-sourcing and CQRS. It's great to see an article that makes it simple to implement in practically any project. I suspect part of its lack of widespread adoption is that it's simply viewed as an enterprise pattern that isn't applicable for use in the everyday application.

Maybe now we will begin to see CQRS being implemented more widely.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Over the years I have worked for four software companies (and am currently employed at one as I write this), as well as non software companies including the public sector, a publishng house and for the UK's largest IT outsourcer.

Although there are probably many differences between the individual companies, one thing that has struck me is the level to which software is granted the status of a core competency at a software company.

At a software company, software is king. It is the core domain of the business, and therefore there is far more innovation and R&D relating to software within these companies. They tend to have better processes, early adoption of new and emerging technologies, and dare I say it, better developers. I appreciate that there are great software developers everywhere, but the best ones seem to be drawn to software companies. If your passion is for developing software, then it makes perfect sense that you want to work for a company that specialises in that domain.

This is the key difference between working for a software company, and a non software cmpany. At a software company, the software is king. Everywhere else, software development is a support function. It enables internal business processes and automates manual tasks that are likely to be error prone. But there is a huge diffefence between developing software that supports the business, and developing software that IS the business.

Even if you work for a well known high street brand, software is still a support function to the key competency of the business.

I have always preferred working for software companies and wouldn't want to work anywhere else.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

A friend of mine was due to visit me over the weekend, but was somewhat delayed due to a problem with work. Despite this being a Saturday and he was not working authorized overtime, he was running late due to having to sort out a problem with the web site where he works (who shall remain nameless). The web site had been hacked and needless to say the issue needed resolving quickly. The problem was, no one was actually tasked with having responsibility for the web site. My friend who was sorting out the problem has no official jurisdiction over the web site whatsoever. He was only asked to investigate the issue as it was widely known that he had an interest in web sites outside of work. But officially, he has no responsibility for the web site.

My friend’s manager was unable to help due to his lack of technical expertise. He is a general purpose manager who delegates the workload to his team, but he doesn’t actually have any technical expertise himself.

The IT Director was unable to help for the same reason. Although he does have some technical expertise, he wasn’t sufficiently skilled enough with the specific technologies to be of any help in resolving the matter.

So the responsibility of resolving the issue fell on my friend. On a Saturday when he had other plans.

IT weren’t even fully aware of the web site, as it was brought into the business without them being consulted. Apparently the Marketing department wanted a web site, and went out and secured one. IT weren’t consulted, and so refused to accept any responsibility for its maintenance. They therefore assumed that the web site had not been commissioned.

What a sorry mess all round.

I’m sure I don’t need to spell out the huge errors that this situation highlights.

• No one had responsibility for the web site and therefore there was no single point of contact to go to when it became hacked.
• There was no one skilled enough within the business to resolve the issue when it occurred.
• There was no escalation procedure in place.
• Consulting the various departments and getting their buy-in before introducing a new application into the business is paramount. If you need IT to support the system, then they need to be fully consulted before hand.

If you’re going to have a web site, or indeed, any corporate / enterprise software application, you need to ensure that there is sufficient skills to maintain it when it inevitably causes problems. It is nothing short of incompetence to do otherwise.

Needless to say, my friend will be raising this issue first thing Monday morning, with solid assurances that the matter will be fully discussed with action points so that it doesn’t happen again.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] is the perfect follow up to a previous blog I wrote entitled Bankrupt Development[^] where I call into question the ethics of our profession.

Quote:
We, software engineers, have superpowers most people don’t remotely understand. The trust society places in us is growing so rapidly that the only thing that looks even remotely similar is the trust placed in doctors. Except, most people have a pretty good idea of the trust they’re placing in their doctor, while they have almost no idea that every time they install an app, enter some personal data, or share a private thought in a private electronic conversation, they’re trusting a set of software engineers who have very little in the form of ethical guidelines.

As with any profession, conducting yourself in an ethical manner is of paramount importance. Software is becoming more and more ubiquitous. We are increasingly becoming more dependant upon software for every part of our lives. From cash-points, to our cars, washing machines, smart phones, apps, the internet to name just a few. Software permeates every part of our existence. Yet very few understand what we do. But like good scientists, it is our duty to break down the barrier between our profession and the public and to be as transparent as possible, to take care to explain what we do as clearly as possible, and to ensure that we act in the interests of the public at all times. We are accountable for our actions and need to ensure that we take responsibility for those actions.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Any article[^] that claims to describe the skills needed by a developer is naturally going to be out of date fairly quickly. Nonetheless this article does a pretty good job. My only criticism is that Node.js is missing. This is inexcusable. If I had to list just one skill that EVERY web developer needed to learn it would have to be Node.js. I’m not sure how the Go programming language can get a mention but not Node.js.

I’d also like to have seen a mention of Progressive Enhancement (PE). For those that haven’t heard of it, PE is a design strategy aimed at making web applications more inclusive by ensuring that the applications can work from the least enabled (in terms of browser versions and features) and upwards. With the current ubiquity of Javascript frameworks, PE is more relevant than ever before.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I've been using Visual Studio Code[^] for nearly a fortnight now and have to say that it's pretty damn good. I've been using it for web development as well as Node.js develolpment. In both cases, it works extremely well.

Up until installing Visual Studio Code, I've been using the Sublime code editor (which incidentally is very good) for my Node.js development. But I wanted a tool that had good support for Javascript, and Node.js in particular. And to that extent I am very impressed. Visual Studio Code has great Node.js support and even allows for debugging your applications.

I've also been using Visual Studio Code for my web development. It may not have all the features of it's big brother - Visual Studio - but it contains more than enough features to keep this software developer happy.

All in all, I'm very impressed with Visual Studio Code. It's very compact and has a nice, clean UI that is very simple yet powerful. If you are serious about software development but want something a little less cluttered, then check it out.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software developers solve problems by creating software solutions. That’s our job and that’s what we’re paid for. However, just because we’re asked to create a piece of software doesn’t mean we should immediately go ahead and implement it. There may be other ways of solving the problem that don’t necessitate creating a software solution. The problem may be solved by a change to the underlying business process or by utilizing another software application for example.

I was recently asked to investigate a problem that a customer had reported with one of our products. Their request was very reasonable and I started looking at ways of solving it. The proposed solution was to provide a patch to the product which would solve their problem. All this was perfectly reasonable.

Upon further investigation and asking a few more directed questions to the support team, I ascertained that the problem was specific to only this particular customer, as no one else used the product in the same way. Further to this, to create a patch would take time. A software developer would need to fix the code. A tester would need to test it to ensure it worked without adversely affecting the rest of the product. We would then need to create the patch and distribute it to them. During all this time other work would not be getting looked at. It could therefore take several days to get the patch to the customer during which time other work would have to be put on hold.

My proposal was to simply fix the affected data directly by executing a few SQL queries on their database. It was quickly agreed that this was the more effective solution and the support team were very quickly on the case. By the end of play that same day the data was fixed and the customer was happy, and so were we as it saved us a lot of effort. All in all a very successful outcome.

So before you write a single line of code, it’s always worth considering alternative solutions, particularly if the alternative has a quicker and cheaper yet equally effective outcome.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Really interesting article[^] where Stephen Hawking speculates that human intelligence will be overtaken by artificial intelligence over the next century. This is not the first time that such conjectures have been made, by either Stephen Hawking or other scientists / thought leader including Elon Musk and Bill Gates.

Quote:
Computers will overtake humans with AI at some within the next 100 years. When that happens, we need to make sure the computers have goals aligned with ours

Whilst easy to dismiss as science fiction hyperbole, the danger is that intelligence is based upon connections which increase at an exponential rate. The human brain is wired to connect synapses, and electrical current passes between these to create thought. A single synapse is connected to many other synapses, which in turn are connected to other synapses, which in turn…..you get the idea. You don’t need many synapses to very quickly grow a vast amount of connections (an exponential number). Artificial Intelligence is based upon exactly the same architecture, only instead of cellular connections there are digital ones. The point is that intelligence can grow very quickly given limited input, and exponentially increase thereafter.

The irony is that our own intelligence may turn out to be our biggest downfall.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

In a recent blog entry[^] by Andy Hunt, one of the original authors of the Agile Manifesto, he openly criticizes the current state of Agile adoption. He makes the argument that far too often, Agile is adopted in a prescriptive and inflexible way. The whole point of Agile, as indicated by its eponymous name, it that it should be “agile”. Many proponents instead have taken the Agile Manifesto as a prescriptive set of doctrines to be slavishly followed. Agile however was never intended to be a process, but instead a set of best practices that could be implemented to align with the needs of the business.

Just like a design pattern is a general solution that is intended to be implemented in a way that fits the needs of the application, so Agile is a set of best practices that are intended to be implemented to meet the needs of the business.

The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In other words, software grows and changes based on real-world feedback and actual evidence, until it reaches a state in which it actually works. Hunt advocates the use of the Dreyfus Skill Model within this framework, as a way of on-ramping less-experienced developers while allowing their veteran counterparts more flexibility.

Quote:
“Whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors,” Hunt concluded. “There is no ‘us’ versus ‘them.’ There is only us.”

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Further to my previous blog post[^] on learning Node.JS, I want to recommend another book on Node.JS. In my previous blog post I had purchased a book called The Node Beginner[^] which is an excellent introduction to anyone wishing to learn Node.JS.

I have since bough the follow up book called The Node Craftsmean Book[^] by the same author Manuel Kiessling[^]. This book is every bit as good as his first book. It picks up where the first book left off by going through some more advanced aspects of Node.JS such as callbacks, asynchronous execution, event emitters and working with MySql and MongoDB. You then use these techniques to build a fully working Node.JS application.

The writing style is simple and easy to understand and by the end you have a fully working application.

I highly recommend both of these books to anyone who either wants to learn Node.JS from scratch or for those with some knowledge who want to dive a little deeper.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Well, my new laptop has arrived and I've been setting up my development environment. With so many free tools around these days it's easier to geek out than ever before.

So far I've installed Visual Studio Code, Visual Studio Community Edition, Reach.js and Node.js. I intend to install SQL Server Express and / or MySQL.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] makes a good point. Great programmers write code that can be easily debugged. One of the first things I always add to my own applications is error and diagnostic logging. I do this as part of the underlying architecture, not as something I add later on (when it is obviously much more difficult to do so).

Whilst no software developer wants or expects their application to throw an exception, when inevitably it does, they will need the tools to track down and fix the problem. Without adequate logging this is almost impossible to achieve. It is a long and painful process of trial and error. It is a false economy to deliver an application more quickly without logging, as you’ll simply absorb all that time during the lifetime of the application thereafter.

Logging is not just a nice-to-have luxury, it is an underpinning part of the architecture.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

In the article In Praise Of The Average Developer[^] Jacob Kaplan-Moss asserts why the myth of the 10X programmer is so destructive.

As developers we all admire those who are on the bleeding edge, those who work tirelessly to stay on the crest of the technological wave and are constantly trying to break into new territory. Those developers who are writing articles about a new technology before we've had a chance to even download it. As developers we are excited by new technologies.

The harsh truth is that the vast majority of us are not like this though. As with any distribution, the majority of us will sit on the top of the bell curve somewhere. And there is absolutely nothing wrong with that.

The rock star developers may be awesome at coming up with fantastic new solutions and implementing new architectures using the latest bleeding edge tools. They may not be so good at fixing bugs and the other mundane tasks that are fundamental to the work of a software developer.

If the industry was filled with these creative geniuses then who would fix the bugs? The harsh reality is that the industry contains far more average developers than rock star developers. Not everyone is able or even motivated to work extra hours researching new technologies. But that's absolutely fine. Whilst the average developer may not set the world alight, they play a vital role nonetheless.

Whilst the industry needs rock star developers to keep pushing the boundaries and seeking out new solutions, it also needs the reliable, hard working average developers too.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

The annual Future of Open Source survey confirms what we all suspected: Open source has won[^]

With the mighty Microsoft now fully embracing open-source with many of its developer tools, open-source is now hard to ignore, even for the enterprise.

Quote:
The survey reports that 78 percent of its respondents are now running their businesses with open source software, and two-thirds are building software for their customers that’s based on open source software. More significant, the percentage of respondents actually participating in open source projects has increased from 50 percent to 64 percent, and 88 percent say they expect to contribute to projects within the next three years.

Open source is now no longer viewed as hobbyist projects developed in the spare time the closet geek, but is now viewed with (almost) complete parity with its shrink wrapped cousin. There is still some way to go, but this is certainly very encouraging progress.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software development is full of best practices. Indeed entire books have been written on the subject of best practices covering every aspect of software development, from design to coding to methodology to name a few.

I thought I'd throw my own weight into the arena and list a few. These are in no particular order.

Agile methodologies are huge these days. There is an entire industry now dedicated to helping companies adopt agile practices.
Automated testing is something almost universally agreed upon as a laudable goal.
Test driven development may fall more on the controversial side, but there is no shortage of developers out there that think of this as a best practice (certainly when used strategically rather than in a purist manner).
Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit.
There was the original, so-called, Gang of Four list of object oriented design patterns, but the list of patterns has grown beyond the ones suggested by this group of authors to include many more. All taken together, using these patterns strategically is considered to be a best practice.
Code reviews are widely considered to be indispensable ways of promoting code quality.
Pair programming takes code reviews to the next level and has development performed in a constant state of review.
One click, automated builds are considered an important goal for most organizations, in stark contrast to the practice of having someone labor for half a day to get the software into a deployable state.

I could list many more, and may do just that in a future post. But I think those make a good start.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

In a recent discussion with a colleague we were talking about the analogies between the civil engineer and the software engineer. In order for the software industry to be given equality with the civil engineering industry, then it should adopt the same underlying principles.

Rigorous requirements
Rigorous design
Repeatable processes
Entry qualifications and external assessment

These are very worthy criteria to aim for, and I would definitely advocate their use. However, there are certain key differences with software engineering.

Software engineers are expected to be able to fit new features onto existing solutions. Imagine if a civil engineer was asked to amend their bridge so that it could accommodate trains as well as cars after it was completed? The civil engineer would quite rightly say that this was impossible or at least so financially costly as to be unworkable. The software engineer however is expected to do exactly this with the solutions they build.

I would definitely like to see more engineering disciplines filter through into software engineering. Particularly entry level qualifications and external assessment. To become a civil engineer and build a bridge you require certain minimum qualifications that have been verified by the industry. In software almost anyone can enter the industry with little or no qualifications and go on to build critical software applications.

There are certainly things we can learn from civil engineering, but there are also key differences between the two industries that we shouldn't forget.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] makes for some very interesting reading.

Quote:
Web developers should learn .Net, Java and C# to improve their employability but will not make as much as other IT roles in the UK despite high demand, according to new research.

To me this seemed a rather strange statement as these are the key skills that many web developers would have anyway. I suspect they may be confusing web designer with web developer.

Quote:
Similarly, customers of all industries are demanding more intuitive applications to interact with businesses. Thanks to this trend HTML 5, Java Script and CSS were the top three front-end skills in demand so far this year.

It's fair to say that web developers are expected to be full stack developers who are comfortable working on the back-end business processing code as well as creating interactive and intuitive UIs.

At the end of the day you should love what you do and do what you love. Money can't buy you happiness.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I recently came across this article[^] that demonstrates a high precision Pi calculator written as a Windows batch file.

As someone who got started in programming by writing Windows batch files longer ago than I care to remember, this is certainly impressive.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Whilst working a lot recently with various Javascript frameworks ((React.JS and Node.JS) I came across this fantastic unit testing framework called Jasmine.[^]

Quote:
Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests

If you're developing any sort of application that uses Javascript then you need to check this framework out. It's very easy to use and can be used in a TDD style approach.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

The following article[^] outlines the ways in which enterprises are failing to fully grasp the importance of open source software.

In a nut shell.

Quote:
Enterprises continue to fumble open source, largely because they misunderstand its value

Just as there is more than one way to swing the proverbial cat, so there is more than one way to increasing the bottom line. Selling software is certainly one way, but it isn't the only way.

Open source is a great way to advertise your skills, products and services. It can lead to higher quality software by allowing other developers to sweep through the code and find and fix defects. Apart from the development side there is testing, documentation etc that can also be harnessed by the open source community. The key word is community. To fully embrace open source and to maximise the benefit you get from it, you need to build a community around what you do. You need look no further than the mighty Microsoft and its recent strategy of opening up its development code bases (C# compiler, MSBuild, ASP.NET) for proof that the strategy can be an extremely successful one.

Giving something away may just be the best way to increase your bottom line.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software craftsmanship is more than simply having pride in one's work. It's a two-way street. A craftsman approach also helps increase the respect of the business for their IT professionals, who bring high-level expertise and a sense of purpose that will advance the business. In software, developing a deep obsession with the customer's needs is part of being a craftsman approach. After all, obsession with customer satisfaction is what helps business succeed at the highest level.

A few years ago, these values were enunciated in the Manifesto for Software Craftsmanship[^] (with more than 16,200 signatories so far), citing the following values:

Quote:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships

The manifesto has a very similar vibe to the Agile Manifesto[^], and that's no accident. Agile principles are an important part of software craftsmanship, which also advocates a higher-order role for developers:

Quote:
Although software craftsmanship is not a methodology, it strongly recommends the adoption of certain technical practices and disciplines, mostly the ones defined by Extreme Programming. With a great synergy with Agile and Lean principles, software craftsmanship promises to take our industry to the next level. Professionalism, technical excellence, and customer satisfaction are the main focus of software craftsmanship. One of its main focuses is changing the perceptions that software developers are like workers on a production line and that software projects can be run as if running a factory.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I have long been an ardent advocate of open-source software, and happily contribute to it when I can. I posted my Subversion to Bugtracker.NET application on my Github[^] page for example.

This article[^] nicely summarises why open-source software is becoming more than just a hobbyist past-time but increasingly becoming part of the enterprise software landscape.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

To say that Javascript frameworks have been in a state of constant change over the last few years wouldn't take a genius. Every developer involved with web development picked up and used JQuery to a smaller or larger extent. This remained the de facto Javascript framework for several years and everything ticked along very nicely thank you. But recently we have had Knockout, Backbone, Amber / Ember and Angular to name just a few, each one the flavour of the month in quick succession. I have often felt that I was spending more time attempting to learn the strengths and weaknesses of each Javascript framework than I ever did actually writing any code in them.

Too many of the other frameworks which I looked at seemed to take a "my way or the highway” approach, requiring you to rewrite everything from scratch. You had to follow that framework's ideology and force you to subscribe to its own idiosyncrasies. If you needed to follow a slightly different path to achieve something this usually involved a lot of pain.

Angular’s “directives embedded in HTML” approach, in particular gave me cause for concern. From what I've read on various forums, the two way data binding that is one if Angular's big selling points seems to cause as many problems as it solves, especially when applications scale up.

Angular certainly has a lot of developers using it. How many of them still like it now is another question. Backwards compatibility does not seem to be one of its core strengths. I’ve seen the up-and-coming Angular.js 2.0 described as a "course change", a description that should send a shudder through any developer that's relying on it. How many of those developers are going to take kindly to rewriting their entire code base from scratch. I think many of them may just look elsewhere instead.

I believe Angular.JS is heading for a demise that’s going to be even more rapid that was its original rise.

Enter ReactJS
For my money, Facebook's React.JS[^] Javascript library is set to dominate the web programming world. Even if it doesn't get as many developers as Angular or Ember, the latter two libraries are rapidly assimilating many of React's best ideas, so React will win out one way or another.

React's best features:
1. Encourages component-based design based on composition. Practically mandates it, in fact.
2. Implements a one-way, top-down data flow.
3. Has a super fast diffing engine that minimises updates to the DOM (always a performance pain).

With React.JS on the client and Node.JS on the server, the future of web development and Javascript in particular looks very bright indeed.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

As always I like learning new technologies. To this end I've been spending time learning Node.JS[^]

Quote:
Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Within the content of the Node.JS language HTTP is a first class citizen which gives you access the the HTTP request and response streams.

I bought myself a copy of the The Node Beginner Book[^] which is a tutorial that takes you step-by-step through building a simple application. For anyone who is interested in learning Node.JS I highly recommend this book. It's very easy to follow and understand.

I'm hoping to upload an example Node.JS project to my Github[^] account at some point in the near future so watch this space for more details.

It really is a fantastic platform to use. If you enjoy getting under the bonnet (or hood) of the web then you'l love Node.JS. As long as you have a good grasp of Javascript then you shouldn't have any problems learning Node.JS.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Dominic Burford - Professional Profile

Summary

Reputation

Privileges