About the Author:

Front-End Development Explained for Non-Developers (part 1)

January 29th, 2020

Front-end development is defined, by Wikipedia, as the “practice of producing HTML, CSS and JavaScript for a website or web application so that a user can see and interact with them directly.” Most people can make sense of basic HTML, CSS, and JavaScript (and that used to be enough). But in the last 5-10 years, front-end development has evolved and splintered into a miscellany of frameworks, libraries, build-tools, command line tools, and new languages.

This plethora of technologies makes it challenging for developers and next to impossible for lay people to follow this field. This post will attempt to explain the landscape of front-end development technologies (as of mid-2015) for a non-developer audience.

Part 1 will cover Libraries and Frameworks. Part 2 will cover build tools, command line tools, and new languages. Part 3 will provide 3 pieces of recommended reading.

Libraries

There’s an organization in Denver, Colorado called the Denver Tool Library. For a subscription fee, they let members borrow some of their 2000 different tools. People can come in to chisel wood, test circuits, or maybe take a tool out to use in their garden. The library offers specific tools with specific functionality that can be used as many times as members need.

Programming libraries work very much in the same way as a physical tool library. Libraries like jQuery, Handlebars, Underscore or Backbone give developers specific functions, methods, and objects they can use to achieve a particular task in their code. With one command or <script> tag, developers can bring a library in and have immediate access to its tools.

The library that has had the largest impact on web development in the last 10 years is jQuery. Among other things, jQuery simplifies creating JavaScript across browsers.

Handlebars is a “semantic web template system”. Template systems make it easy for developers to put dynamic content into a static page a user sees. {{ Curly Brackets }} (aka sideways mustaches) are put into the HTML for dynamic content. Handlebars swaps out values between the curly brackets with content from the program. An example of this in action:

This HTML table…

<tbody>

{{#users}}

<tr>

<td>{{fullName person}}</td>

<td>{{jobTitle}}</td>

<td><a href="https://twitter.com/{{twitter}}">@{{twitter}}</a></td>

</tr>

{{/users}}

</tbody>

…will become this table with the help of Handlebars. The brackets get filled in with dynamic content:

Underscore takes a different spin on the tool library metaphor. Underscore used to call itself ‘a utility-belt library’ for JavaScript. Underscore gives developers shorter, faster ways of doing common tasks like looping over an array or object (which are collections of data in JavaScript). Normal JavaScript provides a way of doing this but a library like Underscore (or Lodash) provides a shorter/simpler way of doing so.

Backbone is a library that makes it easier to better organize applications. Backbone is usually used with Underscore and jQuery, and sometimes with Handlebars to form a complete application framework. An application framework usually handles a lot of the common tasks in web development like handling HTTP requests, routing, organizing business logic, and views the clients will interact with. We’ll go over frameworks in the next section in more detail.

React is the hot library of 2015. React came out of Facebook’s struggle to get the Like Button count to work well. When people would push it, it was hard to get the like count right. React offers a new (and faster way) to create data-driven interactive user interfaces. It is actually used in production for hundreds of millions of users (Instagram/Facebook) so even though it’s new, it has been thoroughly ‘battle tested’.

Photo, Phone, Android, Instagram, User, Smartphone

React in action

The Frameworks

A framework is typically something that provides a structure or way of organizing something. A web application framework, like Ember or Angular, saves developers from having to set up common web development structures/tasks on their own.

Think of a framework like a prefab home. Prefab homes come with the most of the ground plan laid out. The electrical wiring, framing, drywall, and plumbing are generally installed and ready to go. The homeowner then customizes the home’s interior suit their tastes (colors, textures, floors, appliances). The homeowner still could tear down the walls and rework the structure but generally they will go with the defaults.

This metaphor has its limitations but think of a web framework as providing a starting structure and set of defaults within which the developer can make an application.

Angular has become, by far, the most popular JavaScript framework in use (as of 2015). Angular handles tasks like connecting to a database, allowing the user to interact with information on the page, and handling the URL routing (in the address bar). Angular makes it simple to create what are called Single Page Applications (SPAs). If you’ve used Google Maps or Gmail, you’re used to a using a page that updates without refreshing the entire page. It does this by using a technology called Ajax.

Ember is another JavaScript framework that gives developers a scaffolding and structure to develop applications. Ember has a number of ‘opinions’ (conventions) that are meant to increase developer productivity. In theory, this should make it easier for developers to join an Ember project than an Angular project. The tradeoff of this is that some feel restricted by it’s enforced structure.

Bootstrap and Foundation are front-end frameworks that focus on the look and feel of a site. Both can be utilized to easily develop good looking sites that work well across different screen sizes. Each gives you pre-defined CSS and HTML components. A Bootstrap component would be a something like this piece of HTML:

<ul class="nav nav-pills"> 
<li role="presentation" class="active"><a href="#">Home</a></li> 
<li role="presentation"><a href="#">Profile</a></li> 
<li role="presentation"><a href="#">Messages</a></li> 
</ul>

This allows a developer to quickly get a navigation menu that looks like this:

By using Bootstrap/Foundation, developers can avoid having to reinvent the wheel when they need something common like a navigation menu, progress bar, or drop-down menu.

Bootstrap is now used on nearly 10% of internet sites. You can see a variety of sites that use Bootstrap at their showcase site.

Google Trends Proxy on Framework Popularity

Summary

This post gave a high level explanation on libraries and frameworks. Hopefully, you have a better sense of how each work now. Part 2 of this blog series will explore and explain how build tools, command line tools, and new languages work in front-end development.

About the Author:

Why You Need Test Coverage, But Shouldn’t Trust It

November 22nd, 2017

I’ve never heard someone say that unit tests—or any kind of tests—are useless. Practically everyone agrees that testing our software is a good idea. There are objections about the amount of time it takes to set up the testing environment and create tests, but let’s assume you’ve gotten past all of that and are actually writing tests. How do we know that we’ve tested everything we need to? Tests can’t help if there are parts of your code that aren’t tested. That brings us to the topic of this article: test coverage.

What Is It?

There are tools out there—probably for every programming language, but we’ll focus on JavaScript—that run alongside your tests and track which code is executed during the tests. Don’t ask me how it’s done; it’s all magic as far as I’m concerned, but it works, even on code that is compiled/transformed as long as there are source maps available. Most of these tools are able to give you statistics on which lines, statements, and code branches have been executed, so you can know what parts of your project could use more testing.

So how do you get started with integrating test coverage tools into your testing? In some cases, such as with the Jest unit testing framework or with scaffolding tools such as Vue CLI, it’s built right in so you don’t have to do anything extra to enable code coverage, at least for your unit tests. Apart from that, you can use popular test coverage tools like Istanbul, Blanket.js, or JSCover. There are also tools that go beyond plain test coverage such as Sealights, which tracks coverage statistics over time and offers other enterprise-level features. However, it has a cost, so choose one of the free and open-source projects if you’re not looking for anything super advanced. To learn how to install the tools, you’ll have to check out each individual project’s site for their instructions.

The Problem With Test Coverage

While using test coverage tools can be considered by many to be essential, there’s something you’ll need to be aware of. Just because a test coverage tool tells you that something is covered, that’s not the end of the story. Coverage simply informs you what code was executed, not whether you are adequately testing to make sure the code produced the correct outcome.

Here are a few situations where coverage can be misleading:

if (a || b) {
  foo()
} else {
  bar()
}

In this example, if you test with a being true and b being false, and do another test where they are both false, then your results will come back saying that you’ve covered 100% of this code. But you haven’t tested the case where b is true and a is false. This may or may not be important depending on your code, but it’s important to test numerous cases to ensure there are no unexpected side effects.

Here’s another example:

eventEmitter.subscribe('event', () => foo('event'))
// ... more code ...
eventEmitter.trigger('event')

If this code is run by any of your tests, then your coverage tool will report that everything is covered, but if you don’t test to ensure that the execution of that event listener had the correct effects, then it isn’t fully tested.

Conclusion

Should you still use test coverage tools since they don’t give you perfectly accurate information? Yes! They may tell you something is tested when it technically isn’t, but if they say some code isn’t covered, then it certainly isn’t covered, and you’ll know to create tests that cover that code. This is quite useful even if sometimes they can give you a false confidence in your testing. In other words, if you aren’t checking your test coverage, it is likely in your best interest to do so.

About the Author:

What’s Driving the Need to Learn JavaScript?

March 28th, 2017

The 2017 DevelopIntelligence Developer Learning Survey Report uncovered a number of insights and trends on how, what, and why software developers want to learn and be trained on in 2017. One of the major discoveries that stands out from the report is the enormous demand for training on JavaScript. 55% of survey respondents say they want more training JavaScript and 27% want training on ES6, the newest version of JavaScript. Our survey also uncovered a strong training demand for JavaScript frameworks, libraries, and related tooling–e.g., 42% desired Angular 2 training and 38% of developers reported a desire to learn React (a Facebook-driven UI library). What accounts for this robust training demand? Why is everyone either on or jumping on the JS train?

It’s worth considering a bit of history on the language. Brendan Eich invented JavaScript in 10 days around May 6-15 in 1995. The language, originally called Mocha, started as a simple client-side scripting language. It allowed developers to create simple interactivity in the browser. This was when the web was used by tens of millions of people vs. the billions who use it now. This web was originally invented to share simple documents over the wire. Consider what ESPN looked like in 1999:

And here’s what ESPN looks like in 2017:

We ask a lot more of the web than we used to. It needs to be able to do animations, video, social interactivity, eCommerce, and a multitude of other things that we do in our browser in 2017. JavaScript (and JavaScript developers) had to evolve a lot to keep up with this. Here’s a couple of the major milestones of that evolution:

Ajax – 2004

Ajax stands for asynchronous JavaScript and XML. Ajax allows developers to fetch data from a server without doing complete page refreshes. Ajax made things like Gmail and Kayak.com possible. It allowed browsers to feel much more like a desktop application instead of jumping from page to page. They could stay on the same screen but receive new data from a data source somewhere. This allowed for a much smoother and more interactive user experience.

Source: By DanielSHaischt, via Wikimedia Commons

Get JavaScript Training for Teams

jQuery – 2006

jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML. jQuery made it much simpler for web developers to build applications that worked equally well on all browsers. This was the era when Internet Explorer had annoying quirks that other browsers didn’t. jQuery also made web development easier, in general, as it would give developers shorter/simpler ways of doing common tasks. They could get the same thing done with much less and much more readable code.

Here’s how to do relatively simple aJax request in jQuery:

$.getJSON('/my/url', function(data) { 

});

Here’s how you would have to write it in JavaScript

var request = new XMLHttpRequest(); 
request.open('GET', '/my/url', true); 

request.onload = function() { 
if (request.status >= 200 && request.status < 400) { 
// Success! 
var data = JSON.parse(request.responseText); 
} else { 
// We reached our target server, but it returned an error 

} 
}; 

request.onerror = function() { 
// There was a connection error of some sort 
}; 

request.send();

The source of this code is a site called you might not need jQuery. They are arguing that jQuery is being overused. This might be true but it’s worth considering how many lines of code developers can save.

MVC Frameworks (Backbone, Angular, etc.) – ~2009-2013

Web applications continued to get larger and more complex. jQuery works well for simple applications but quickly turns into spaghetti code as an app grows. The tooling needed to evolve to accommodate this.

This is where the MVC (Model-View-Controller) frameworks like Backbone and Angular came out of. MVC was an existing popular way to organize code projects (in other languages) and adhere to what’s known as the separation of concerns. One area of the code would contain the templates that users would see, one would contain the logic of what functions would be called when users did different actions, and another part would contain the data that ultimately drove the app. This worked and worked really well for a variety of web applications.

This short video shows the power of Angular 1. It allows for accomplishing many common tasks with ease:

While Angular shines in simple smaller apps, it struggles to perform well and be maintainable as it grows. This created the need for a better paradigm.

Component Frameworks (React, Vue) – 2013-Now

Facebook released the React.JS UI library in 2013. Facebook was struggling to make existing frameworks/libraries support their complex app so they rolled out their own. React (and similar libraries) break a web application down into components. Every little widget or separate area of an app/page is a component and, thus, developed independently. React handles the task of keeping the data in sync with the user interface (e.g the like button has the correct number of likes).

Component-driven development greatly simplifies the application development and makes it easier to avoid common types of bugs that plagued the MVC frameworks.

Here’s a great clip, from 2013, that explains the React paradigm from a high-level:

No wonder developers want to learn more JavaScript!

As you can see, JavaScript has come a long way. There are variety of powerful tools to build simple and complex applications. But the tools keep changing and evolving, forcing developers to constantly be learning new things. Developers need regular training in multiple formats to keep up with this landscape.

DevelopIntelligence javascript offers expert-led, hands-on courses on all of the latest JavaScript libraries and frameworks. Our Developer Survey Report goes even more in depth on the front-end training landscape and you can download it here.[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

About the Author:

How To Deliver Real ROI With Development Budgets

March 2nd, 2017

We asked Nik Kinley, Director & Head of Talent Strategy, YSC, to provide some feedback on the real ROI of development within an organization’s budget. Below are his thoughts.

Once a year, every year, year, firms face the same challenge: Choosing priorities and creating budgets for developing employees. There is some core, basic training that needs to be done. There is coaching, executive education and other activities for leaders. And there is often a sum set aside for identifying and developing potential future leaders. (more…)

About the Author:

Free resources for building hackathon apps quickly

March 10th, 2016

GoCode is a hackathon/app competition put on by the State of Colorado. The challenge this year is for teams to build an app that helps “businesses build a competitive strategy” while also using a Colorado open dataset. Rather than limiting the dev time to the traditional all-nighter weekend, teams have many months to build their apps/businesses.

We (DevelopIntelligence) are one of the sponsors GoCode (our 3rd year of sponsorship and GoCode’s 3rd year of existing) and teaching a half-day class to the top teams on the mentor weekend.

Our speciality lies in the technology training and learning space. In addition to our mentoring day, we want to provide some resources GoCode participants or other hackathon participants could use to build their apps.

(more…)

About the Author:

Tech and Training Reads – December 2015

December 9th, 2015
Training Reads

Coding is boring, unless…

The software industry has a turnover problem. This causes problems for teams, projects, and companies. Check out one startup’s approach for retaining their developer talent through constant learning and growth.

Why Virtual Classes Can Be Better Than Real Ones

Massive online open courses (aka MOOCs) get a lot of flak for their low completion and retention rates. But these courses become more popular and refined each year. Instructor of one of the largest MOOCs, Engineering Professor Barbara Oakley, makes a compelling argument for MOOC’s pedagogical advantages. It comes down to using video in the right way.

How Gamification Reshapes Corporate Training

Gamification is the use of game-design elements in non-game contexts. Think badges, rewards, and leaderboards. These and other game elements are helping auditing firm Deloitte increase its corporate training engagement.

Tech Reads

What is a coder’s worst nightmare?

Hundreds of programmers give their perspectives and stories on the things that haunt developers. The answers cover impossible bugs, organizational politics, trying to understand other people’s code, documentation dilemmas, and many other scenarios.

Why is it so hard to find a good front end developer?

Front end developers are the unicorns of the programming world. The field requires raw engineering chops paired with design intuition. This piece describes why it’s so hard to find talent in this field.

Must See JavaScript Dev Tools That Put Other Dev Tools to Shame

A front-end engineer details the best developer tools for 2016. Worth skimming through and forwarding to your developers.

About the Author:

Instructor Spotlight: Dave Wade-Stein

November 16th, 2015

Dave Wade-Stein is one of the newest instructors at DevelopIntelligence. Dave has experience with a wide variety of software language (including Assembly, Perl, PHP, Java, Tcl, Ada, Eiffel, C++, Bash, and Fortran) and will primarily teach classes on Python, Linux, Unix/Linux, Chef and Puppet. He’s been programming since the late 1970s and teaching in some capacity since the early 1990s. He has a Master’s in Computer Science and a PhD in Cognitive Psychology. He’s worked for universities, startups, large  companies, the US Navy, and now DevelopIntelligence.  

IMG_0735 (1)

Hi Dave. Tell us about your background in technology.  How did it all start?

I had my first programming job at 13 in 1977 (or 1978). I had a personal computer called an Ohio Scientific (OSI) Challenger 2P (which included 4K of RAM, and for $150 I upgraded it to 8K of RAM), and after writing some games in BASIC, one of which unintentionally hung the system, the OSI rep put me in touch with a guy named Pete who was building some card key entry systems. Now they’re pretty ubiquitous but, at the time, it was pretty revolutionary to have a credit card like thing that could get you into a building or parking lot. I remember having no idea what to charge for programming, but it ended up being pretty good money for a 13-year-old.

(more…)

About the Author:

6 Ideas for Retaining the Training

November 13th, 2015

How much did you remember from your high school Spanish or French class?

If you’re like most people (including me) probably very little.   We all know that there’s a difference between hearing something in a classroom and being able to apply it in context later.  And just like your forced two years of High School language classes didn’t help you actually learn the language, most software development (aka programming) classes have this same problem.

Current research suggests that workers retain only around 10% of what they’ve learned in most classes. To put that in tangible terms, that means over a 3-day class (24 hours), you’ll only retain about 2.5 hours worth of the information. If we are talking about an Introduction to Javascript or Python course, that means you’ll basically remember how to do looping and functions. While those building blocks are valuable, they are definitely not enough to write even a basic production application on your own once the class is done.

There must be a better way to help people retain more knowledge during a class…RIGHT?

Here are a few tips and tricks for increasing retention that we’ve learned in 20 years of teaching people how to write software.

(more…)

About the Author:

Front-End Development Explained for Non-Developers (part 3)

September 3rd, 2015

This last post in the series of 3 will curate 5 interesting resources on front-end development you should check out if you’d like to know more on the field.

The JavaScript World Domination

This post details the history of Javascript from something that would animate web pages to becoming the dominant programming language.  It alludes to where Javascript might be going and talks about many unexpected use cases of the language.  It does a good job at staying high level and is approachable for non-technical audience.

(more…)

About the Author:

Front-End Development Explained for Non-Developers (part 2)

September 3rd, 2015

This blog series is explaining common front-end development technologies for a non-technical audience. Part 1 of this series explored front-end libraries and frameworks. This post will explain/explore build tools, command line tools, and new languages.

Build Tools

When developers create applications, there are numerous tasks involved. These tasks include setting up their codebase, downloading libraries, or preparing their application for production deployment. These tasks can be done manually using the command line, a package manager (like NPM), or manually creation/coding. But running these tasks manually can become repetitive and disorganized. Developers hate repetition (that’s what computers are for) so they create tools to handle this anytime they can. The tools, in this case, are called task runners or build automation tools.

Grunt and Gulp are the most commonly used build automation tools. Grunt got an earlier start but Gulp has quickly become more popular. Think of build tools as “programming to setup for programming”. A common task in Grunt/Gulp would be to ‘lint’ the code upon saving. Linting code is the process of checking it for proper syntax/styling. This is one way to reduce bugs and make code more readable. Grunt/Gulp are commonly used to run such tasks as minification, concatenation, clean up file locations, and compile one type of file to another.

An easy way to imagine Gulp is to picture it as a sort of old-school pneumatic tube

system. Gulp is a way to pipe files from one location to another. The difference is that Gulp uses one or many plugins in the middle to make changes to the file before delivering it to it’s destination.

Broccoli is similar and newer than Grunt/Gulp. It does tasks differently and offers a more concise syntax and increased performance. Broccoli’s is supposed to be especially helpful when projects grow in size/complexity. Grunt and Gulp files can quickly become difficult to wrangle and Broccoli’s tree/folder based tasks supposedly shine here.

Yeoman has a set of ‘generators’ that allow for quickly setting up / scaffolding a project. Rather than taking the time to create folders for your HTML, JavaScript, and CSS, Yeoman will do this for you. You can then tweak the setup to your liking/needs.

Command Line Tools

In 2015, most development projects require a lot of external libraries (you know what a library is now, right?). To use jQuery, for example, the developer needs to go to jQuery’s site, download the source code, put it in the right folder, and include the <script> tag in their code to bring jQuery in. This quickly gets tedious as a project needs many libraries. Furthermore, it becomes difficult to keep track of which version is needed where.

An example of how libraries are included into a project

Command line tools like Bower and the Node Package Manager (npm) allow for libraries to be installed using the command line. A simple command like bower install jquery will go fetch the jQuery source code and put it into the bower_components folder, stored locally. Now the index.html file will look something like this:

<script src="bower_components/jquery/dist/jquery.js"></script>

<script src="bower_components/underscore/underscore.js"></script>

<script src="bower_components/bootstrap/dist/js/bootstrap.js"></script>

<script src="bower_components/angular/angular.js"></script>

<script src="bower_components/angular-route/angular-route.js"></script>

<script src="bower_components/angular-resource/angular-resource.js"></script>

NPM can do everything that bower can and more. There 70000+ npm modules to the Bower’s 10000+ packages. Npm needs Node.js to run and many projects don’t use node. Npm also installs many more dependencies (think Libraries that depend on Libraries) when you install something with npm. Bower will, supposedly, install fewer dependencies and therefore take up less space than npm modules.

It’s a bit trickier to think of metaphors for command line tools. But, imagine, you’re a dentist working on someone’s teeth. You merely have to open your hand and say the tool you need and an assistant puts in it in your hand for you. This is what Bower and Npm are to a developer. In a command or two they have quick access to the tools they need.

Languages

JavaScript and CSS are default languages that are used in webpages. However, they each have their own drawbacks in terms of syntax, whitespace, and aesthetics. For this reason, developers invented new languages and ‘preprocessors’ that they develop in. They then take these new languages, like CoffeeScript or Less, and compile/convert them into JavaScript, HTML, or CSS. The newer languages are easier to develop in but must ultimately become what the browser can read.

CoffeeScript

CoffeeScript is a programming language that ‘transcompiles’ (converts) to JavaScript. CoffeeScript is a cleaner prettier version of JavaScript. It has a ‘leaner syntax’ that makes it easier to read. Here’s a quick example from the CoffeeScript site:

Looping over an Array example in JavaScript (a common task):

cubes = (function() { 
var i, len, results; 
results = []; 
for (i = 0, len = list.length; i < len; i++) { 
num = list[i]; 
results.push(math.cube(num)); 
} 
return results; 
})();

The Equivalent in CoffeeScript:

cubes = (math.cube num for num in list)

This is one small example of how using something like CoffeeScript makes developers’ jobs easier.

Typescript

Typescript is another new language that converts to JavaScript. One of the biggest potential drawbacks of JavaScript is its ‘weak typing’. Weak typing basically comes down to not being able to tell when a piece of data is a string (text) vs. a number. Typescript has stronger typing (hence ‘Type’ in the name).

Typescript also offers some advanced (futuristic) JavaScript functionality that isn’t supported by most browsers yet. Typescript offers features (e.g. modules, classes, mixins) that will come with the next version of JavaScript, ES6. Typescript will convert back to normal JavaScript and work in today’s browsers. Typescript offers JavaScript’s future, today.

Less, Sass, and Compass

Less, Sass, and Compass are all languages that can be compiled to CSS. They are to CSS what CoffeeScript/Typescript are to JavaScript. Less, Sass, and Compass improve the process of writing CSS.

For example, say a developer is going to use the same color across their application. Instead of writing out the hex color code (e.g. #000080) multiple times, they can declare it once as a variable then use that variable across the application. When that Less, Sass, or Compass is compiled later, that hex code will put in across the CSS.

Think of Less, Sass, and Compass as using programming in CSS. They give you functions, variables, and logic to make stylesheets easier to write, maintain, and understand. Here’s a quick example in Sass from this excellent post:

$container-width: 100% - 20px;

This is assigning a value to the variable of “container-width”. Containers are common HTML objects. This variable will be assigned however many pixels is currently 100% (width) minus 20 pixels. This spares the designer/developer from having to go figure out what the current proper width is and subtract 20px and put that value in. When something changes in the styles, the changes will propagate dynamically across the stylesheet (vs. having to go do all the math again). This small example shows how something like Sass makes writing styling much easier.

Summary

This post covered build tools, command line tools, and new languages. Most of these tools didn’t exist 5 years ago and none existed 10 years ago. It’s easy to get lost in their cryptic names and acronyms. Simply remember that they all exist to make developing and maintaining applications easier. In 5-10 years, you’ll have a new set of technologies to learn up about! They will have the same purpose as well.

The final post in this series will curate some introductory level writing on front-end development. These 5 posts were selected to be generally approachable to a non-technical person. They will allow you to appreciate how far this field has come and how exciting it is now.