What is a Full Stack developer?

What is a Full Stack developer?

Is it reasonable to expect mere mortals 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.

A.     This involves understanding what can break and why, taking no resource for granted.

B.     Appropriate use of the file system, cloud storage, network resources, and an understanding of data redundancy and availability is necessary.

C.     How does the application scale given the hardware constraints?

D.    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.

E.     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

A.     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.

B.     Full stack developers know how to create a reasonably normalized relational model, complete with foreign keys, indexes, views, lookup tables, etc.

C.     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

A.     The heart of the value the application provides.

B.     Solid object oriented skills are needed here.

C.     Frameworks might be needed here as well.

4.      API layer / Action Layer / MVC

A.     How the outside world operates against the business logic and data model.

B.     Frameworks at this level should be used heavily.

C.     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

A.     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.

B.     Can include mastery of HTML5 / CSS.

C.     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

A.     Full stack developers appreciate that users just want things to work.

B.     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.

C.     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.

A.     Now we are blurring into the line of architect, but that is too much of a hands off role.

B.     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.

Your Maven build is slow. Speed it up!

Article by Andres Almiray

We often dream that things will run faster (perhaps you’re serving a jail sentence), or happen sooner than they do so they’re not as annoying. It’s particularly painful, when you have little or no control over the thing you’re waiting for. Time seems to stop and every second feels like an eternity. Multiply that by 10 add 5, divide by 2 and square it. You now have a measure of how annoying this can feel. An example of such an annoyance might be the build time of your project. Perhaps you use Maven as your a build tool of choice? Then you most probably know this feeling.

Well, the good thing is that you’re reading this post! In this, I’ll try to explain some of the most common reasons as to why Maven build is taking longer than it should and figure out how it can be improved. So, if you’re one of those people who counts the seconds in a slow Maven build, keep reading, this should help you. Or at least will it will line up your thoughts to help figure out how to improve it.

Here are some the solutions to the common reasons why your Maven build is slow.

1. Parallel builds

By default, Maven does not utilize the full power of your hardware. It builds all modules sequentially rather than in parallel. However, often your project setup does not require it to be sequential. Often you can command Maven to analyze your project including the dependency graph and build the project in parallel where possible. You can either specify the exact number of threads to use for building your project or use a portable version of the parameter and specify the number of thread in terms of CPUs available on the machine.

mvn -T 4 install -- will use 4 threads
mvn -T 1C install -- will use 1 thread per available CPU core

While it might happen that your project is not easy to build in parallel it’s worth trying, the speedup can be substantial. Using one thread per CPU core is a good default. Your development machine probably has spare computing power and speeding up the build is always useful.

2. Running tests in parallel

An aspect of build which probably has the biggest impact on your build speed are the tests. The most common practice is to disable the tests when you’re just interested in building your artifacts, but we cannot recommend such a non-conventional engineering practice.

If you really do intend to skip your test goals (Are you sure? Are you sure you’re sure?) during your Maven build, then the most common property that the majority plugins respect is: -DskipTests=true

However, you can achieve faster build times without damaging your feedback loop that much. The answer is running tests in parallel. The parallelization technique that we just discussed works on the module level. If you’re using an established plugin for running tests, let’s say, Surefire, you can also configure it for parallel execution within the module.

Running tests in parallel might lead to unwanted side-effects, especially if they are tangled together and expect to be executed in a certain order. However, that’s another story altogether and you should totally try it to see if it works for you and by how much it speeds up your build. You can always figure out the failures later.

3. Build necessary modules only

Let’s have a bet. I bet fifty RebelLabs dollars that when you build your project, the chances are you’re using the default command:

mvn clean install

Did I win? Thought so! While cleaning Maven is removing all the generated artifacts, all temporary files, except hopefully the configuration and the files checked in into the version control. It then generates fresh copies of those files again. It’s great for when you hit a weird caching issue or some obscure bug that you have but nobody else is able to reproduce. However, it will take extra precious seconds and CPU cycles to do what is essentially a needless job of recreating already existing files.

Instead what you most typically want to do is to build your project incrementally. Say you have a multi-module project with common core modules that rarely change and a web-interface that you’re currently working on. After changing the web-interface module try running a command like the following:

mvn install -pl $moduleName -am

First of all, we removed the implicit call to the clean phase. The project rarely requires cleaning, so we won’t want to do it all the time. Let’s take a look at the descriptions of the other options in the Maven command we just used:

• -pl – makes Maven build only specified modules and not the whole project.
• -am – makes Maven figure out what modules out target depends on and build them too.

The result of using these options together is the perfect combination of the flexibility and speed. We know what module we’re usually working on and if we have changed any dependencies, they will be renewed as well.

At the same time a large chunk of your project build will be skipped either because it’s still fresh and doesn’t require rebuilding or because it’s not a part of the target module and won’t play a role.

4. Limit internet access

You’ll like this one. If you sometimes feel like Maven is downloading the internet, know that you’re not alone! This is one of the most common complaints of any build system, npm, gradle, sbt. You name it, you’ll be surprised at how many libraries and transitive dependencies known to humanity will need to be downloaded at an arbitrary, and usually most inopportune time.

However, there’s a simple option you can enable that will make Maven work offline. You’ve probably guessed correctly, it’s the infamous offline key.

Append your mvn command with this option and Maven won’t be tempted to check for a new snapshot of your favorite dependency making you wait for the network to respond.

If you don’t want to take it offline, but have a shady network connection, you can try setting:

-DdependencyLocationsEnabled=false to your MAVEN_OPTS variables. This addition will mean Maven will retain fewer outgoing connections throughout the build and maybe shave a few seconds off your build as well.

5. Speeding up Java startup

The last bit that I want to share with you today doesn’t come from my experience, but some research. Maven is a Java program, so it will of course run on the JVM. This in turn can be tuned for a much faster startup.

To make the JVM start a bit faster (safe in the knowledge we’re not dealing with a long-running application server process that has to be optimized for a faster execution later on), we can recommend the following two options for your Maven process:

-XX:+TieredCompilation -XX:TieredStopAtLevel=1

We just made your JVM perform the basic just-in-time compilation of the code only. It won’t try to gather a more precise profile and better optimize the execution of the code. The benefit of that is that the JIT doesn’t need that much information and the optimized code actually has a chance to kick in during a since build.

Note, that this advice is purely theoretical, I’d be happy if you could try it and mention whether your project build benefits from it.

Conclusion

In this post we’ve looked at several common reasons why a Maven build might be slow and could be annoying you each and every time it’s run.

In a nutshell, I think the default command for your build should be something along the lines of the following snippet:

MAVEN_OPTS= -XX:+TieredCompilation -XX:TieredStopAtLevel=1 mvn install -pl $moduleName -am —offline

It will deny Maven its annoying right to download the internet, build only the necessary modules and their dependencies, while fine-tuning the JVM into faster shorter running programs, and won’t relentlessly clean the whole project again and again. You’re welcome.

I bet you’ve been waiting for me to say this next bit, so wait no longer! If you have an opportunity, consider trying out another build tool. For example Gradle is said to be more intelligent with greater “optimizations” as built-in defaults. The Virtual JUG recently hosted a great session of Gradle with Andres Almiray where these points were discussed, check it out!

PS. There might be a way to skip the build phase of your Java project completely. Check outJRebel, a revolutionary tool which reloads your code changes instantly without building your project at all!. It will make your development cycle faster by skipping your build, redeploy and restart stages. Your development experience will become more enjoyable and you will be a happier and more productive developer.