Thursday, December 26, 2013

Full stack web development

A Post by Laurence Gellert@http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/




What is a Full Stack developer?


Is it reasonable to expect mere morals to have mastery over every facet of the development stack? Probably not, but Facebook can ask for it. I was told at OSCON by a Facebook employee that they only hire ‘Full Stack’ developers.  Well, what does that mean?
To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.
Good developers who are familiar with the entire stack know how to make life easier for those around them. This is why I’m so against silos in the work place. Sure, politics and communication challenges get in the way in large organizations. I think the point Facebook is going for with their hiring policy is, if smart people use their heads and their hearts, a better product gets built in less time.

layers of the full stack:

  1. Server, Network, and Hosting Environment.
    1. This involves understanding what can break and why, taking no resource for granted.
    2. Appropriate use of the file system, cloud storage, network resources, and an understanding of data redundancy and availability is necessary.
    3. How does the application scale given the hardware constraints?
    4. What about multi-threading and race conditions? Guess what, you won’t see those on your development machine, but they can and do happen in the real world.
    5. Full stack developers can work side by side with DevOps. The system should provide useful error messages and logging capabilities. DevOps will see the messages before you will, so make them count.
  2. Data Modeling
    1. If the data model is flawed, the business logic and higher layers start to need strange (ugly) code to compensate for corner cases the data model doesn’t cover.
    2. Full stack developers know how to create a reasonably normalized relational model, complete with foreign keys, indexes, views, lookup tables, etc.
    3. Full stack developers are familiar with the concept of non-relational data stores and understand where they shine over relational data stores.
  3. Business Logic
    1. The heart of the value the application provides.
    2. Solid object oriented skills are needed here.
    3. Frameworks might be needed here as well.
  4. API layer / Action Layer / MVC
    1. How the outside world operates against the business logic and data model.
    2. Frameworks at this level should be used heavily.
    3. Full stack developers have the ability to write clear, consistent, simple to use interfaces. The heights to which some APIs are convoluted repel me.
  5. User Interface
    1. Full stack developers: a) understand how to create a readable layout, or b) acknowledge they need help from artists and graphic designers. Either way, implementing a good visual design is key.
    2. Can include mastery of HTML5 / CSS.
    3. JavaScript is the up and coming language of the future and lots of exciting work is being done in the JavaScript world (node, backbone, knockout…)
  6. User Experience
    1. Full stack developers appreciate that users just want things to work.
    2. A good system doesn’t give its users carpal tunnel syndrome or sore eyes. A full stack developer can step back and look at a process that needs 8 clicks and 3 steps, and get it down to one click.
    3. Full stack developers write useful error messages. If something breaks, be apologetic about it. Sometimes programmers inadvertently write error messages that can make people feel stupid.
  7. Understanding what the customer and the business need.
    1. Now we are blurring into the line of architect, but that is too much of a hands off role.
    2. Full stack developers have a grasp of what is going on in the field when the customer uses the software. They also have a grasp of the business.

Other Pieces of the Puzzle:
  1. Ability to write quality unit tests. By the way, even JavaScript can have unit tests these days.
  2. Understanding of repeatable automated processes for building the application, testing it, documenting it, and deploying it at scale.
  3. An awareness of security concerns is important, as each layer presents its own possible vulnerabilities.

Closing Thoughts:
It is very bad practice to tightly couple code to a specific implementation (library, OS, hardware, etc). Just because a full stack developer understands the entire spectrum doesn’t mean they have license to take shortcuts. Well, actually they do if it is a build and throw away prototype.
Technology start-ups need full stack developers for their versatility!  However, as an organization matures, it needs more and more focused skills.
I’m not sure you can call yourself a full stack developer until you have worked in multiple languages, platforms, and even industries in your professional career. Full stack goes beyond a ‘senior engineer’, as it is along the same lines as a polyglot programmer but with a higher view of all the connecting pieces. Note that on my list, only items 3-5 involve writing code.
THIS ENTRY WAS POSTED IN WORK. BOOKMARK THE PERMALINK.


Original Post: http://act2.me/full-stack-web-development/


Full stack web development


Over the next few months, I plan to write a series of posts about full-stack web development. This first post is a rough, but sufficiently accurate guide to how web applications have evolved over the last 15 or so years – and I’ll end with the set of technologies I plan to write-about over the next few  months.
In the good old days, we had simple web pages (with animated gifs!). Apple, that paragon of beautiful design, had a website that looked like this:
apple_1473503a
Things were simple back then – often, the developer would administer the web server (often his only machine), and he would write HTML pages and place it in a folder (/www) on his server machine. These HTML pages would then be served when a browser requested the page…
1
But there was a problem – you could only get static content. What if you wanted your visitors to see how many other people had visited this web-site (remember those spinning visitor count images?!). Or what if you wanted people to fill out a form with their name and email address? That was when you turned to CGI and Perl scripts – simple code that often was run by the web server itself, and that could interface with the file-system or databases.
2
But organizing code in CGI/Perl scripts was rough. CGI didn’t scale well (a new process for each request), was often insecure (accessed the file system / environment variables), and it didnt provide any structured way of building dynamic applications. Things got confusing for a few years (till about 2005) – there was Java Server Pages (JSP), Microsoft’s ASP and then there was PHP! I like to think of the reference architecture at this time as being IIS & ASP.NET – you could build scalable, secure applications, and development was quite easy with Visual Studio.
3
Things got interesting though once we had AJAX (2005) – till now, web servers mostly sent back an entire page or document. AJAX allowed for JavaScript code on the client side to request for a fragment of a page – and then dynamically (i.e – without going back to the server) refresh a part of the page (by updating the document in the browser – called DOM, or document object model).
What was sent back was still HTML, but the code on the browser could stick in this HTML fragment inline to the current page. This meant that web apps could be more responsive (I believe that this was when we really had a web-app, instead of a web-page). Google’s GMail and Google Maps were the killer demos for AJAX, and suddenly, everyone was using AJAX to refresh a portion of the page.
4
For a couple of years, things were all about AJAX, using the existing technologies on the server. And then, in about 2007, there was a new kid on the block – Ruby on Rails, from 37signals. The “5 minute blog” demo for Ruby on Rails took the developer world by storm, and suddenly everyone was talking about Rails! What made Rails different was that there was a prescribed way to lay out your web application – using a development pattern that had been commonly used in desktop applications, but that had been forgotten in the move to web apps. This was Model (data) – View (templates) – Controller (business logic). Rails was opinionated – “this is the way to do it”, had lots of plugins and made building web apps sane once again.
5
Between 2007 and 2010, there were 3 developments that prompted another change:
The first was the rise of smart phones and mobile apps. Now, as was often the case, many applications had a web version and a mobile phone app for it. However, the server was sending back HTML pages – not something the mobile phone app could consume. So, you needed structured data from the server, not HTML.
The second development was the rise of jQuery – a JavaScript library that became really popular and made it easy to build very dynamic, beautiful web applications – and that made AJAX easy!
The third development was the release of nodejs – for the first time, you could have high performance JavaScript on the server, thus potentially ending the nightmare of having “client side developers” who knew HTML/JavaScript and “server side developers” who knew .NET/C#/Ruby.
6
This was a good architecture – but we could re-use the learnings on the client side to simplify the spaghetti of jQuery code that was happening on the client side. What was needed was an “opinionated” way to assemble HTML pages on the client from data that was fetched from the server – similar in spirit to Rails. So, in the last 2 years, we’ve had  number of frameworks that simplify the client side development – BackboneEmberDerby and Meteor – and my favorite one, AngularJS.
7
So, this is where we are today – and my reference architecture is mongodb for the database server,node/express as the web/application server, AngularJS on the client side (along with Bootstrap for styling). I find that this architecture allows me to build web services really quickly that can have a client interface build fast using AngularJS, and then one can start development of mobile apps against the service using PhoneGap or native mobile development tools.
8
Over the next several weeks, I’ll have posts on each of these: MongoDB, Node/ExpressJS, JSON and REST interfaces, AngularJS, Testing with Karma & mocha and Bootstrap for styling pages.