Cutting Through The JavaScript Toolchain Thicket with Angular CLI

If there is a developer hell, one of the circles will involve the JavaScript toolchain. The JavaScript ecosystem is awash in tools, choices, and configuration options. Combine that with spurious documentation and constant change and you have a jungle of pain awaiting any brave soul who dares build a modern JS application.

Much has been done to ease JavaScript toolchain fatigue. There are templates and starter packs for most of the popular JS stacks. If you’re using Angular 2, the Angular team has created a tool called Angular CLI. It encapsulates all the best practices into one handy command line tool. Angular CLI shortcuts most of the Angular 2 setup. Just run a few commands and you have a working application. In addition to the build tools, you also get a set of scaffolding tools. If you’re familiar with the Ruby on Rails scaffolding tools, Angular CLI will feel right at home. In the interest of trying new things, I decided to kick the tires on Angular CLI and see if it lives up to the hype. I took my demo Angular 2/TypeScript/Webpack application (repo here) and ported it over to Angular CLI.

Installing Angular CLI

npm install -g angular-cli

Install the Angular CLI tool using NPM. Make sure to run the npm install as an administrator. Easy peasy.

Scaffolding an Application

npm install -g angular-cli
ng new <my app name>
cd <my app name>
ng serve

These commands will spin up a basic app structure for you to use. This app structure has a lot of goodies included. Testing, linting, hot module loading, and a decent starter app all come with the basic template. CLI abstracts away the webpack setup, so you don’t have to figure that out. It even includes a basic demo server for you to serve your application from. The only thing that the angular cli doesn’t include is a style library. I’d love to see Angular Material or Bootstrap included with the CLI, but I’ll live.

Here’s what comes out of the box with a new Angular CLI Project:

I was curious about how up to date the basic setup is, so I ran “npm outdated”. NPM packages change often. It looks like most of the packages are close to their most recent version, but the CLI used Angular 2.3 instead of Angular 2.4.

Generators

Boilerplate code sucks and Angular 2 has a bunch of it. There are lots of small files that need be built when you add a new component. Angular CLI has generators to help with that. I tried out a few of the generators. I found the component generator to be particularly useful. It builds out the template, code, and spec files. It also adds the component to its root module. This is a great time saver. The route generator was far less useful, however, as it didn’t do anything. It looks like they’re going to add it back in later.

Styles

The default template doesn’t include any style libraries, so I pulled in Angular Material (currently in beta).

To install:

npm install --save @angular/material

Then you need to pull it into your app module:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';
import { AppComponent } from './app.component';
import { CharacterBuilderComponent } from './character-builder/character-builder.component';
import { EncounterComponent } from './encounter/encounter.component';
import { NavMenuComponent } from './nav-menu/nav-menu.component';
import { StatsComponent } from './stats/stats.component';
import { HomeComponent } from './home/home.component';
import { MaterialModule } from '@angular/material';
@NgModule({
declarations: [
AppComponent,
CharacterBuilderComponent,
EncounterComponent,
NavMenuComponent,
StatsComponent,
HomeComponent
],
imports: [
BrowserModule,
FormsModule,
HttpModule,
MaterialModule.forRoot()
],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }

Finally, add a theme file to your site.css. There are several pre-built themes, but you can make your own if you want.

@import '~@angular/material/core/theming/prebuilt/deeppurple-amber.css';

After importing the styles I ported all of my demo code over into the angular cli project. This process was surprisingly easy. Unfortunately, the Material styles are not as robust as the Bootstrap styles. I’m sure I made a mistake somewhere, but I wasn’t really going for maximum style, so I let it go. I’m looking forward to Material UI being ready for primetime, but I don’t think it’s quite there yet.

Final Verdict

I wouldn’t use Angular CLI in production (yet), but I think it’s a fantastic tool for playing with and learning Angular 2. It takes the most painful part of setting up an Angular 2 project and makes it a breeze. You can get up and going faster than building an environment from scratch. I’m going to keep an eye on this project and see how it develops. If you build Angular 2 apps, I recommend you do the same.

Here’s the final result:

https://github.com/DustinEwers/typescript-demos/tree/master/ts-demo-node/ninjas-quest

Building Tech Radars for Fun and Profit

The technology landscape is exploding. New technologies, platforms, and tools are being creating at an ever-increasing rate. VR, AR, and wearables give us new app stores to target and new experiences to create. Conversational UI (Alexa, Bots, Cortana API) is a totally new way to interact with users, and another dozen different platforms you can target. Even the web space is exploding. It feels like there’s a new JavaScript framework roughly every ten minutes.

All of the new stuff is amazing, but also exhausting. There’s so many new things out there. Finding your focus is hard.

confused kitty

Keeping track of all this new stuff is tough, but we have tools to help us. One of those tools is tech radar. A technology radar is a collection of new technologies and how important they are to you or your organization. You enumerate new technologies and assign them a value somewhere between “run away screaming” and “let’s use this for EVERYTHING”.

The tech radar was created by Thoughtworks. They publish their radar a couple of times a year. It’s a great snapshot of what technologies they are using in their organization. I recommend you check it out.

Thoughtworks Tech Radar

While the Thoughtworks tech radar is great, it’s more fun (and useful) to do it yourself. Neil Ford has a fantastic talk about building your own tech radar. Check it out here:

In his talk, Neil mentions two tech radars. One for your company and one for yourself. After viewing this talk, I was hooked by the idea and decided to give it a try. I’ve worked on both styles of tech radar and learned a few things along the way. 

Organizational Tech Radars

An organizational tech radar is a picture of the technologies used in your company along with recommendations for new things you should keep an eye on. Your team sorts technologies into one of four categories.

Adopt – Use when appropriate. This is a default best practice.
Trial – Use on non-critical projects. Good, but not 100% there yet.
Assess – Keep an eye on this. Use it for POCs and Demos.
Hold – Avoid using this on new projects.

To conduct a tech radar, get representatives of the different teams in your organization together and have them discuss some of the new technologies they are using or interested in using. Assign each technology to the proper category and record the highlights of each conversation.

Shoot for fewer than 30 people per discussion session. Try to get a diverse slice of your organization’s tech users. If your organization has teams outside of generic enterprise app dev, make sure they get a seat at the table. (examples: designers, SharePoint Devs, Salesforce Devs, DBAs, DevOps, mobile devs, etc… )

I’m involved in two different organizational tech radars. One as the primary organizer and another as an observer. It’s been an educational and useful experience. I’ve gained insight into some of the dynamics behind how technology is used in these two organizations.

One of the major benefits of doing a tech radar is that you deepen your understanding of how technology is used in your organization. You also gain insight into what different people are thinking. It can highlight blind spots in your own thinking and surface interesting technologies to check out. Another benefit is that it can make your organization more proactive about technology adoption. By knowing what’s available, you can begin to plan earlier. You also gain consensus about which technologies to adopt. It’s a lot easier than trying to campaign for new technologies on your own.

It’s not all rainbows and puppy dogs though. I ran into several challenges while coordinating my organization’s tech radar. First, I had to make a special effort to represent all the developer communities in my organization. We have a lot of practices and not all of them came to the discussion meetings. Next time, I may hold special meetings for each group.

The second hurdle I ran into was that everyone was very focused on things to adopt now, as opposed to future technologies. This issue was relatively easy to solve. We created a new category for “obvious best practices” and focused more on the “trial” and “assess” categories. Don’t be afraid to make tech radar your own. You don’t have to copy Thoughtworks verbatim. I found that making a category for things that aren’t new, but part of your default tech stack, cleared up the “adopt” list and kept the radar future forward. It also provides you with a handy list of architectural recommendations for new projects.

The final challenge was dealing with all the conversations. It was easy to go off on tangents or get caught up in how you feel about a particular technology. It’s tough to keep on track. One way we addressed the issue was by splitting up the meetings into small chunks. It’s easier to schedule and no one gets burned out from a 4 hour meeting from hell.

Overall, I found this exercise highly beneficial. I learned a lot and picked up a few technologies for my tech radar.

Personal Tech Radars

If you’re like me, you have “the list”. Sometimes referred to as “the guilt list”, because I never finish it. It’s the pile of technologies you intend to research. If that sounds vague, that’s because it is. “to research” doesn’t really give you  a finishing point. I built a personal tech radar to help clear up that ambiguity.

For me, a personal tech radar is a much less formal affair than the organization radar. It’s also, by necessity, a smaller one. I changed the definition of the categories. Instead of focusing on adoption, my categories focused on how much effort I want to put into learning the technology. Here are my categories and a few examples for each one.

Adopt
Agitate for use and learn deeply. This is for your core skills.
Examples: .NET Core, Angular 2, TypeScript, Azure

Trial
Seek functional knowledge on. Build a demo apps or POCs.
Examples: Python, Spark, R, Progressive Web Apps

Assess
Keep an eye on it, but don’t worry about getting deep knowledge.
Examples: Hololens, Unity, Xamarin, Chatbots

Hold
Avoid using when possible. Don’t waste a lot of time learning new things about this tech.
Examples: Old ASP.NET, Angular 1

I only had one challenge with my personal tech radar. I’m interested in everything, so I had a lot of trouble keeping my categories small enough to be doable. I consider this a feature, not a bug. Doing this exercise forced me to take a holistic view about what I’m interested in and edit accordingly. I also did some journaling about where I wanted to go in my career, which helped clarify my thinking. For example, I realized that learning data analysis is a better use of my energy than learning native mobile development. I’m still keeping an eye on mobile, but it’s not a top priority for me. Overall, it narrowed my scope and helped me focus.

Conclusion

If you want to better deal with the ever-growing deluge of new technologies, consider doing a tech radar. Both the organizational and personal flavors offer insights that you can use in your daily developer practice. It’s a great way to end the year.

PS – For some reason, I think of this song every time I bring up Tech Radar.

 

Great Reads for Innovators

As technologists, we are the vanguard of innovation. We’re at the forefront of technological innovation. Even if you’re slagging COBOL in the basement of some bank, you’re still dragging your organization into the future. Ever wonder how that process actually happens? What can you do to be more creative?

I’m fascinated by this topic, so I put together a talk about it.  (abstract / slides) It distills what I’ve learned from reading dozens of books on innovation and the history of technology. To save you some time, I put together a list of my favorite innovation related reads. If you’re curious about this topic, these books are a good place to start.

Books for Innovators

Sapiens

Sapiens is a highly entertaining, unorthodox view of human history. Not only is it informative, it challenges basic assumptions about ideas that most people don’t realize they’re making. It’s a great description of early human history and how we got to the modern age. It’ll really open up your mind.

Geography of Genius

Innovation is not evenly distributed. There are certain times and places throughout history that have “golden ages” of innovation. Geography of Genius explores a few of these places and tries to find what ties them all together. This book is very interesting and you’ll learn about some places that you don’t see much of in the classroom.

Evolution of Everything

Unlike what the history books tell us, innovation is more bottom up than top down. Matt Ridley does a fantastic job describing how in Evolution of Everything. He covers a several major innovations including religion, money, and government. This book challenges many deeply held beliefs and illustrates how innovation is an evolutionary process.

Smarter Better Faster

This book offers a more tactical look at creativity. It’s also a great guide to improving other aspects of mental performance. Charles Duhigg does a fantastic job mixing science with fascinating stories.

Deep Work

Creativity requires concentration. A commodity in short supply in the modern age. In Deep Work, Cal Newport makes a compelling argument for making “deep work” (focused work) one of your primary priorities. I changed several of my habits after reading this one.

Competing Against Luck

While I enjoyed the Lean Startup, I felt like it treated innovation more like a roulette wheel than a process you can influence. “Just pivot until you make it big or run out of money.” In Competing Against Luck, Clayton Christensen describes a fantastic intellectual power tool for building new products. The “Jobs to Be Done” theory of innovation. If you want to build a product, I highly recommend this one.

The Righteous Mind

One of the most important things you can do to become more innovative is empathize with and learn from people whom you disagree with. We live in a society that’s increasingly polarized, but this book the antidote. In the Righteous Mind, Jonathan Haidt explains the moral foundations for different political outlooks and makes a strong case for civility in political discourse.  This is a must read if you have trouble dealing with people who don’t share your beliefs.

Bonus Materials:

Here are a few non-book resources to check out:

Protopia (Kevin Kelly)

Kevin Kelly’s concept of protopia (as opposed to utopia or dystopia) is really enlightening.

In How to Fail at Almost Everything and Still Win Big, cartoonist and business author Scott Adams describes his “success formula”. Each area you master roughly doubles your odds of great success. This is a great case for diversifying yourself. You can either get his book or read this article:

Dilbert Creator Scott Adams Reveals The Simple Formula That Will Double Your Odds Of Success

If you’re looking to diversify yourself, here are two excellent resources:

Personal MBA

The Personal MBA is a reading list that’s meant to give you the business skills taught by an MBA program. I’ve read many books on this list and have not been disappointed. It’s also got great selections on personal finance and psychology.

The Great Courses (Amazon)

The Great Courses are a series of college level lectures that you can listen to in your car. Personally, I’m a big fan of their history selection. They also have courses on psychology, philosophy, and business.

Why Innovation Thrives in Cities

Innovation is partly a network effect. This article describes why cities with a higher population density have higher per capita rates of innovation.

Everything is a Remix is a video series about cultural innovation by Kirby Ferguson. I have yet to find a better description of how culture is generated by remixing other cultural elements.

This is a TED talk on how Google X (Google’s own skunkworks company) takes risks and creates a culture that fosters psychological safety.

Conclusion

This list of resources will open your mind and help you become a better innovator. If you think I missed something, feel free to drop it in the comments.

 

Lazy Loading Modules With Angular 2 And Webpack

I’m sure this is obvious to some people, but this issue threw me for a loop.

When building applications in Angular 2, it’s best practice to divide up your application into feature modules. This keeps your code simple and easy to work with. You can lazy load these child modules to improve initial load times and keep people from downloading code for areas they don’t have access to.

The Angular 2 website has excellent tutorials on how to set this up, but if you’re using Webpack, those instructions (link) don’t quite work.

Here’s the code from the Angular 2 website.

export const routes: Routes = [
  { path: '', redirectTo: 'contact', pathMatch: 'full'},
  { path: 'crisis', loadChildren: 'app/crisis/crisis.module#CrisisModule' },
  { path: 'heroes', loadChildren: 'app/hero/hero.module#HeroModule' }
];

You could assume that this code isn’t specific to using system.js as your module loader, but you’d be wrong. Webpack, by default, chokes on these lazy loaded modules. I spent more time than I’m willing to admit trying to figure out the arcane errors before I realized that the Webpack was the problem. Fortunately, this problem is easy to fix.

Like everything else in Webpack, there’s a loader for that. In this case, you want the Angular 2 Router Loader (more info here). Be attentive to the instructions, because the module strings work different than they do with system.js. For example, the Webpack loader supports relative paths. (The Angular 2 docs say otherwise) Once you setup the loader, lazy loading in Webpack works like a champ.

How to Turn Off TypeScript Automatic Compilation in Visual Studio

TypeScript is a first class citizen in the Visual Studio universe. By default, Visual Studio will compile your typescript files whenever you save them. This is great for many types of TypeScript projects, unless you’re using a tool like Webpack or Gulp. These tools handle TypeScript compilation by themselves. You don’t want Visual Studio to waste your time generating spurious files. Fortunately, it’s easy to disable automatic TypeScript compilation. Just add a “TypeScriptCompileBlocked” element to your project’s xproj file and give it a value of “True”. This will prevent Visual Studio from making those pesky extra files.

Set the TypeScriptCompiledBlocked to True in the Xproj file

Disabling automatic TypeScript Compilation

Taming the JavaScript Dragon with TypeScript

 

The year was 1995. “Gangsters Paradise” topped the music charts. Pixar released Toy Story, the first wholly computer generated film. And, in just 10 days, Brendan Eich created a language for adding dynamic content to web pages. From these humble beginnings, JavaScript has become one of the most popular programming languages in the world. Outgrowing its initial purpose by several orders of magnitude. You can now use JavaScript to build nearly anything, from web pages to robots. JavaScript is the Swiss army knife of programming languages and one of the best tech career investments you can make. Not bad for a language someone threw together in a few weeks.

Unfortunately, it’s not all puppy dogs and rainbows. JavaScript is a landmine ridden kludge of a language. It uses a class system that most programmers are unfamiliar with (prototypical class), is loosely typed, encourages the use of global variables, and has lots of weird quirks like the “this” keyword. Despite all this, JavaScript has two things going for it. First, JavaScript runs on every web browser, which means it’s available on every computer. It’s the only scripting language that can run on any browser. Second, smart people have created patterns that expose the “good parts” of JavaScript and overcome the bad parts. The current popularity of JavaScript today is made possible by a community of highly skilled developers that have figured out how to make the most of an imperfect language.

Even with smart design patterns, JavaScript’s failures are magnified on larger projects. It’s simply not built for 100+ kloc applications.

Additionally, the lack of static typing means it’s hard to implement the static code analysis that’s common in tools for enterprise languages like C# and Java. This means that you also miss out on refactoring tools, which you would want on a large code base. I’m sure there’s a contingent of Notepad lovers who think tooling is for sissies, but most of us have better things to do than spend six hours staring at a screen looking for a typo an IDE could of dropped a squiggly line under in two seconds. It’s a craft, not a religion.

Dependency management in JavaScript can also be a chore. The lack of a proper module system makes it tough to break apart functionality. Node.js does a great job of getting around this limitation with it’s module pattern and NPM, but it should be baked into the language.

Fortunately, we have some options. ECMAScript6 (ES6), the new version of JavaScript, has recently been ratified. This new standard addresses many of the issues with building large JavaScript applications. Unfortunately, most browsers don’t support ES6 yet. Why let little things like browser support stop you? There are lots of tools that allow you to use ES6 features today. These tools will take your code and transpile it down into plain JavaScript that can run on any browser. Among these tools, my favorite is TypeScript.

What’s TypeScript?

TypeScript is a language developed by Microsoft. The goal of TypeScript is to add features to JavaScript that make it usable on large projects. TypeScript is a superset of JavaScript. This means that valid JavaScript is also valid TypeScript. All you have to do is rename your *.js files to *.ts files and they’ll usually work. Also, the compiled output of TypeScript is readable, which makes debugging much easier. If you’re used to C# and you hate how loose JavaScript is, Typescript will help fix that. If you’re primarily a JavaScript developer, Typescript gives you additional powers without having to learn a totally new language.

TypeScript has two primary features:

Optional Static Typing

The namesake feature of TypeScript is the addition of an optional static typing system. While this doesn’t sound like much, it gives you access to much better tooling. Modern IDE’s, like Visual Studio, rely on static typing to provide robust code analysis and intellisense. JavaScript has some of these features, but lacks the level of code analysis available to C# and VB.

New JavaScript (ES6 / ES7) features

The TypeScript team is committed to implementing new JavaScript features in TypeScript. While they don’t have the level of support dedicated ES6 transpilers like Babel have, TypeScript is close behind. Much like HTML5, ES6 was created with large scale modern web applications in mind. The most important features in ES6 are classes and modules. TypeScript implements both of them.

What about the competition?

While TypeScript is a great language, it does have competitors. In fact, there are over 250 different languages that compile to JavaScript. There are two major categories of compile to JavaScript technologies.

Replace JavaScript with another language

This category includes languages like CoffeeScript and Dart. Their general philosophy is that JavaScript is broken and we need a new language to fix it. I don’t buy that argument. JavaScript is not broken because it doesn’t behave like your pet language. TypeScript has two advantages over these types of languages.

The first is that you don’t need to learn a totally new language to use TypeScript. You’re just adding features to existing JavaScript. If you don’t like the way TypeScript does something, just do it the vanilla JavaScript way. You can go as far down the rabbit hole as you like. Your existing JavaScript knowledge remains useful.

Second, languages like this are leaky abstractions. Because you’re compiling down into JavaScript, you’re going to have to debug in JavaScript. You still need to have strong JavaScript knowledge. TypeScript adds to your JavaScript skills instead of replacing them.

Implement ES6 features today

This category includes transpilers like Babel and Traceur. These options support more new features than TypeScript, but TypeScript still has static typing. Also, TypeScript is also built into Visual Studio, which makes it easier to use (for ASP.NET developers) than ES6 transpilers. TypeScript is going to give you a better tooling experience than ES6 transpilers.

How to get started?

The easiest way to get started with TypeScript is to use the TypeScript Playground. It’s an interactive tool that walks you through the features of TypeScript. You can play with the TypeScript code and see how it compiles into JavaScript. It’s a good way to quickly get a feel for the language.

Visual Studio and Visual Studio Code both support TypeScript out of the box. You can also use NPM to install a TypeScript compiler for use in your Node.js or Cordova projects. TypeScript is also supported (via extensions) by many text editors, including Atom and Sublime Text. Regardless of what your preferred tools are, TypeScript is likely a viable option.

Additional Resources:

The TypeScript Handbook
Kangax ES6 Compatibility Table

How to Future Proof Your Web Application

What do traditional archers and old Linux hackers have in common?
Terrible looking websites.

I’ve recently started getting into traditional archery. Like any other geek, the first place I looked for information was the Internet. In my quest to suck less at hitting targets, I scoured the Internet for resources. I found lots of content, especially video content, but most of the websites were so outdated it made them hard to read. Not only were they unusable on my phone, but many sites didn’t even look good on my computer. While there are lots of videos on YouTube, I could only find one well designed site. (http://www.archery360.com/)

The thing about traditional archery is that it’s been around for thousands of years. It’s about the most evergreen content you can find. A well written archery site should be able to last indefinitely.

This got me thinking about how to build a future proof (or at least future resistant) web application. The benefits of future proof apps are obvious, but even if you don’t plan for longevity, your app is probably going to be running longer than you expect. I’ve seen many instances of businesses running ancient apps that no one thought would last that long. Think about the trillions of lines of COBOL happily chugging away in server rooms across the world.

Additionally, most people have better things to do than redesign their sites every year. Not everyone needs to keep up with the latest web design trend. This is especially true for people who are producing evergreen content, as opposed to news sites and blogs.

How do we make our web apps future proof?

Make things easy to change

Great software is software that can be efficiently maintained. Pay attention to proper design principles. Separate your concerns, don’t get too clever, and keep things simple whenever possible. Program to interfaces to isolate dependencies. There’s a reason why we call these concepts “best practices”. Additionally, use a robust suite of automated tests. Automated tests will save your ass when trying to make changes. Software that can be properly maintained lasts longer and is easier to deal with. It’s also less expensive. Realize that most of the stuff you write isn’t going to be scrapped in the next few years. The web is a mature platform and most applications are going to be around for a while.

Pick technologies with a future

Thinking about using that sexy new JavaScript framework for your mission critical business application? You may want to reconsider. Picking the right stack means balancing a lot of different factors. Here’s a few things to think about:

The Lindy Effect

https://en.wikipedia.org/wiki/Lindy_effect

The Lindy Effect predicts the lifetime of nonperishable media, like books or JavaScript frameworks. It states that the longer something has been in use, the longer it will likely remain in use. For example, the Bible will likely remain in print far longer than the book at the top of the New York Times best seller list. This makes sense. For something to stay in print for a long time, it probably offers significant value. This effect applies to software too. Ruby on Rails, ASP.NET, and PHP have been around for a while. They are mature platforms and don’t appear to be going anywhere any time soon. Meanwhile, there’s a hot new JavaScript framework every week. It’s hard to tell which one of these frameworks is going to emerge from the pack. (… though we all know Angular.js already won)

Is there new stuff being written in the technology?

While the Lindy Effect is useful, relying on it alone will steer you wrong. COBOL and FORTRAN have been around since forever, but there’s no way in hell anyone should be writing new code in them. Think about what other people are doing with your chosen stack today. Are people writing anything new in it or is the technology on it’s way out?

Who’s backing the community?

Another predictor of longevity is who’s backing the technology in question. ASP.NET has Microsoft behind it. Ruby on Rails and PHP both have large communities of users. Angular.js has Google (and to a lesser degree, Microsoft) behind it. You don’t need a large corporate backer to be viable, but if you see lots of people and companies get behind a technology, the likelihood of it being around in ten years is high.

Design for the future

People access the web from all sorts of devices. From computers to phones to Internet enabled refrigerators. One thing we know about the future is that the number of device form factors is not going down. When I was looking for archery sites, the most common problem was the text was too small. This was because most of the sites were designed with one viewport in mind.

There are two things we can do to make our designs future proof.

Keep it simple.

This is Google’s homepage in the year 2000

How to Future Proof Your Web Application

How dated does it look? Can you still use it?

While Google isn’t the most beautiful site, it’s simplicity gives it long term appeal. When building something to last, stick with a simple design. You don’t need to go as spartan as Google, but keep the content to chrome ratio firmly in the content side.

Use responsive design

With frameworks like Bootstrap and Foundation, it’s easier than ever to make your site responsive. Responsive design should be the default for everything you build on the web. You never know what kind of device someone is going to visit your page with, but with a little bit of effort, you can make your web application work on most of them.

Conclusion

Future proofing should be an important design consideration. By making good choices in the beginning, you can ensure your web app will live a long life.

Now if you’ll excuse me, I have a traditional archery website to build…

How to: Ionic in Visual Studio

Mobile devices are taking over the world. If you are a web developer, you need to be prepared for a world where people spend the majority of their computing time on mobile devices. This doesn’t mean “the web is dead”, just that you need to be able to write code that works on mobile devices. The primary way to do this is by writing responsive web sites. However, sometimes you want to be on your user’s home screen. For that, you need to build an app. While learning the native platforms is a possibility, there’s a significant learning curve. Fortunately, there are hybrid applications.

What’s a hybrid application?

A hybrid application is a mobile app (it sells in the app store) that runs within an internal web browser. Hybrid apps use standard web technologies like HTML, CSS, and JavaScript. For the average user, hybrid apps are indistinguishable from standard native apps. There are two main advantages. First, you can use one code base for all three platforms. Second, you use existing web skills to build that code base.

My Path to Hybrid Development

I spend most of my time developing ASP.NET applications, but I’ve been experimenting with mobile technologies for the past year. I’ve built native apps in Android and Windows Mobile. I’ve played around with Swift. I tried to use Xamarin Forms (and hit the paywall at File -> New). The one technology that’s been on my list that I haven’t gotten around to until recently, is hybrid.

A big part of why hybrid technologies got kicked to the back of my list is because of the ongoing debate between hybrid and native. Hybrid apps got off to a lousy start. They were slow and clunky compared to their native counterparts. Turns out DOM manipulation is slow, especially on a phone with 128mb of ram and a single core processor.

In recent years, a combination of improving web browsers and Moore’s law have fixed this issue. Unless you are building a video game, hybrid apps are fast enough.

Another barrier for hybrid technologies is that each native environment has it’s own design language. Each of the native environments has a standard list of controls and design guidelines that help you fall into the pit of success. You don’t have to work hard to make something that looks professional.

When building my Windows and Android apps, I went from zero knowledge to a simple, but decent looking app in a few days. I used the standard controls with some minor color tweaks and had something that looked like it belonged.

Most hybrid environments, like Apache Cordova, don’t have this built in design. You start with a blank canvas. This gives you lots of room to shoot yourself in the foot.

In the web world, we solved this problem with front-end frameworks. You can use Bootstrap, Foundation, or a host of other frameworks to give your app a default design you can override later. This has made it a lot easier for developers to build professional looking web applications.

Fortunately, people who build hybrid applications caught on and built their own frameworks. While there’s quite a few of these, the one I’m going to cover here is Ionic.

What is Ionic?

Ionic is a hybrid application framework that uses Angular.js to build cross platform hybrid apps. It sits on top of Apache Cordova and provides a standard set of controls for building hybrid applications. Think of Ionic as Bootstrap (+5) for hybrid applications. It gives you starting point and way of doing things that speed up development.

Why Ionic?

There are lots of advantages to using Ionic, but ultimately, I care about building great applications as fast as possible. Before learning about Ionic, I had recently downloaded an app. I was impressed with it’s design and functionality. When I first heard about Ionic, I noticed that they had a showcase of apps built using the platform. In that showcase, I saw the app I recently downloaded. At that point I was convinced. If an independent developer can build an award winning application that rates 4+ stars in both app stores, the technology that created it is worth a look.

Another reason that I’ve decided to try hybrid development is that Microsoft is embracing hybrid. Cordova tools for Visual Studio is now built into Visual Studio 2015. Microsoft is also building their own set of emulators to aid in hybrid development. This means that people that are using Microsoft technologies can use familiar tools to build mobile applications.

Overall, I think this is a big win for ASP.NET Developers.

How to get started?

Install Node.js

There are two paths to using Ionic with Visual Studio, but both of them start with some basic setup. Like many front end frameworks, Ionic uses the Node Package Manager (npm) to run commands. NPM is basically NuGet for Node.js. You can find Node.js here.

Install NPM Packages

Once Node.js is installed, fire up a command shell (in admin mode) and enter the following command:

npm install -g cordova ionic

This command installs both Apache Cordova and Ionic.

Now that you have the basic tools setup, there are two ways to use Ionic with Visual Studio. The first option is to use Visual Studio. In this case, we’re going to use Visual Studio 2015.

Visual Studio 2015

To develop with Ionic on Visual Studio 2015, do the following:

Install Tools for Apache Cordova

These come with the default installer. They’re listed under “Cross Platform Mobile Development”. If you need to add the tools in after the fact, you can just run the installer again.

Use the Ionic Template

The makers of Ionic have published some handy templates for you to use in Visual Studio. In the new project screen, go to Online and search for “Ionic”. You should then see the Ionic Tabs template. This template will set you up with a basic Ionic App to check out.

Ionic Template

Run Your App

To run your app, select either select an emulator and hit “Run”. The easiest emulator to use is the Ripple Emulator, which brings up your Ionic app in your web browser.

Ionic in Ripple

Visual Studio Code

Another way to get off the ground with Ionic is to use Visual Studio Code. If you haven’t checked out Code yet, you really need to. It’s a lightweight code editor that’s fast and optimized for ASP.NET and Node.js development. If you want to use Code to do your Ionic development, do the following:

Install Visual Studio Code

Download code here and follow the installation instructions for your platform.

To add the “code” command to your command line on a Mac:

Start up Terminal

Type cd ~/ to go to your home folder

Type touch .bash_profile to create a bash profile file.

Edit .bash_profile with your favorite editor (You can just type open -e .bash_profile to open it in TextEdit.)

Add the line code () { VSCODE_CWD="$PWD" open -n -b "com.microsoft.VSCode" --args $* ;}

Type . .bash_profile to reload .bash_profile and update any functions you add.

Create an Ionic Project

Open up a command window and browse to the folder where you want your project.

To start an Ionic project type ionic start appname template.
For “appname”, substitute your app name. For “template”, Ionic comes with three basic templates. Try the “tabs” template for now. (Additional Info on starting an Ionic App)
This command builds your Ionic app using your chosen template.

To Edit Your Ionic Project

To open up VS Code, you can use the UI, or you can just type code . in your ionic project folder.

To Run Your Ionic Project

Type the command ionic serve
This will open up your Ionic project in a web browser. You can also use emulators to run your Ionic app. (Instructions here)

Additional Resources

Ionic Framework
Visual Studio Code
Node.js
Ionic Showcase

How To Get The Most Out Of Criticism

Have you ever built something you’re proud of, only to have it torn to shreds when you show it your audience? Get burned in a code review? Rejected after a job interview? I know I have. Today, I’m going to write about some strategies to deal with it.

If someone is able to show me that what I think or do is not right, I will happily change, for I seek the truth, by which no one was ever truly harmed. It is the person who continues in his self-deception and ignorance who is harmed.
― Marcus Aurelius, Meditations

One of the most underestimated soft skills of the modern software developer is the ability to take criticism well. This is an industry where things change so quickly that there’s no way to be perfect. There is always someone who knows more than you and even if they don’t know more than you, you can certainly learn from them.

Besides being bad at taking criticism, most developers are not good at giving good criticism. Anyone can slag another person’s creative output, but how often can someone say something that helps the person they’re critiquing? Being able to deliver a useful critique is almost as valuable as taking one. Software development is a complex craft and being able to help others is essential.

On Dealing With Criticism

One particularly powerful sting-elimination strategy is to consider the source of an insult. If I respect the source, if I value his opinions, then his critical remarks shouldn’t upset me.
– William Irving, A Guide to the Good Life: The Ancient Art of Stoic Joy

I’m going to define criticism broadly. To me, criticism includes any comments you receive on your creative work. It includes well meaning advice, sharp attacks, and trolling. It also includes situations when you don’t get picked for the job, get passed over to speak at a conference, or lose a contest. Call it criticism from life. Regardless of the source and intent of the criticism, the following tips apply.

Don’t take it personally.

Even if someone meant to harm you, you choose how you respond to criticism. You can choose not to interpret it as insult. At the end of the day, all criticism is information. Treat it like any other data stream. Some data is higher in quality, some data is lower in quality, but it’s all just data.

The reality is the people who sling insults are not doing it because of you, they’re doing it because of their own issues. You can’t control them, but you can control you.

Mine for actionable feedback.

When someone criticizes your work, even if they were trying to hurt you, look for things you can improve on. For example, let’s say your users throw some scathing criticism your way in a product review. While it’s easy to get angry or frustrated, try to figure out the root cause of their pain and use it to improve the product. If you get rejected for a job, try to think of where you went wrong and fix those things in future interviews. Remember, failure is temporary. Learning is everything.

Sometimes, you are going to get comments that have no useful information. Trolls excel at leaving useless criticism. If you can’t find actionable advice, then disregard the comment. Remember, people being mean is their fault, not yours.

Consider the source.

Like in the quotation above, it’s important to consider who is criticizing you. Do you respect them? Are they considered experts this particular area? Do they adhere to the same philosophy as you? Use these considerations to weigh comments. Do you think that Peter Thiel, Elon Musk, Ray Kurzweil and others like them care one shred about what luddites think about them? I doubt it.

On Giving Good Criticism

Giving good criticism is almost as important as being able to take criticism. Being able to deliver useful feedback to your peers helps them grow. Being able to do it in a way that doesn’t make them hate you is good too. Here are a few tips to help you with that.

Be mindful of other people’s egos.

While it’s easy to say that you should make all criticism into dispassionate feedback, actually doing it is hard. I still have a ways to go myself. Because of this, you should make it as easy as possible for the person you are critiquing to turn what you say into useful feedback. An important way to do this is by being mindful of their ego.

Software development is a tough craft. People invest their time and energy to get good at it and a well timed insult and can trigger all kinds of pain. If you want to see how fragile people’s egos are, Google “imposter syndrome”.

To help preserve ego, start with compliments. For example, I attended a session last year that had some content issues. When asked how it went, I started off with the good things about the session. I complemented the presenter on their topic selection and presentation style, which were both excellent. Then I made a point about how they tried to do too much for their time slot. This gave the person something they could use without hurting their feelings.

Remember that negative feedback has more weight than positive feedback. Start off on a positive note and try to achieve at least a 2:1 ratio of positive to negative comments. (if possible)

Focus on giving actionable advice.

Telling someone “that sucks” does nothing useful for either party. You don’t get a better product/employee/code and the person being criticized doesn’t learn anything. Additionally, you’ve angered the person you are critiquing, which benefits no one. Instead, focus on making things better. Try saying “This would be better if…” or “These X things would improve your product because of Y reasons”. Using direct, but non personal phrases focuses the attention to where it needs to be. Remember, there are no bad people, just bad ideas.

Conclusion

The key lesson for this post is to always look for value in criticism. When someone criticizes you, focus on extracting useful information from the experience. Use it to fuel your abilities to the next level. When critiquing others, try to focus on making it easy for them to find value in your comments. Help them get to the next level. Remember, criticism is just data. You choose how to use it.

Image:
Roman Emperor and Stoic, Marcus Aurelius
Photograph by Jean-Pol GRANDMONT

What We Need More of is Hubris: A Review of Zero to One

What We Need More of is Hubris: A Review of Zero to One

We wanted flying cars, instead we got 140 characters.

– Peter Thiel

According to Peter Thiel, an amazing future lies ahead. All we have to do is build it. Unfortunately, cultural shifts have steered us away from audacious, grandiose, and truly innovative projects. We need to stop focusing on making slight improvements to existing technology (going from 1 to 1+n) and start making new things (going from 0 to 1). In short, we need more of the hubris that America has had in past decades.

Zero to One: Notes on Startups, or How to Build the Future is an excellent book by the self proclaimed contrarian and billionaire Peter Thiel. It’s about building startups and thinking big. Zero to One will inspire you and make you think. It’s one of the few business books that can’t be re-written in five pages.

Contrarian Truth

Zero to One starts off with a big question:

What important truth do very few people agree on?

This is a tough question to answer well. Most people come up with something widely believed, like the healthcare system is broken, or an opinion, like how chocolate ice cream is better than vanilla. The key is to find something that is both true and unpopular.

For example, think about the housing crisis. Right before the crisis, the important truth was “the housing bubble is about to pop”. Most people thought the good times were going to last, but some people saw the impending crunch. They used that knowledge to make a lot of money, while the rest of the country lost their shirts.

Finding these contrarian truths gives you an insight into the future. An insight that can you can use to build a business or make an investment. Think of how many truths we take for granted today that were science fiction a few decades ago.

  • We can prevent most infectious disease.
  • It is possible for humans to land on the moon.
  • We will have enough food to feed everyone on the planet.
  • The Internet will connect the world with each other

These things were once considered impossible, but now are obvious.

Here’s a few contrarian truths that I think about on a regular basis:

  • The world is a becoming a much better place for all humanity, despite what the news tells you.
  • Deference to authority is not a good tool for solving social problems.
  • The first human to live past 150 years old is probably alive today.
  • Most people won’t drive cars in 20 years.

So when looking for business opportunities, you should ask yourself: What valuable business is nobody building?

Zero to One vs. The Lean Startup

a startup is the largest group of people you can convince of a plan to build a different future.

– Peter Thiel

Since the .com bubble popped, the startup community has moved towards the Lean Startup model.

The Lean Startup model goes as follows:

  1. Target an existing market with competitors or take something that already exists and apply it in a new context. ie. rip, pivot, and jam
  2. Build a small version of your product. (a Minimum Viable Product)
  3. Release that product and gauge it’s traction
  4. Evaluate the tests and either:
    a. Make small incremental changes to improve the product
    b. Pivot into a new product
  5. Release the new version and test again
    … repeat 4-5 until out of money or you have a killer business.

The beauty of this approach is that it’s a scientific way to build a business. No one knows exactly what’s going to work, so you run as many tests as you can to get to a market.

Thiel doesn’t agree with this method. He advocates something a little different. His philosophy is that startups should make big plans and carve out their own monopoly. They can do this in one of two ways.

  1. Make a 10x improvement over an existing product. (Google did this with search)
  2. Make a totally new product segment.

In my experience, I have noticed that most big companies fall into the category of 10x improvements. Even companies that are credited with creating new markets, like Apple, are usually just improving existing technology. MP3 players, smartphones, tablets, and smart watches all existed before Apple took them to the next level. When I think of companies that made something new, I think about Pirates of Silicon Valley

He also mentions that head to head competition always results in a drop in profits. Look at any commodity market and you will notice that profit margins are razor thin. To avoid this, you need to stay so far ahead of the competition that you can charge enough to make a healthy profit. This profit can then be used to build moonshots or attract the best employees by giving them a world class working environment. Google is a great example of this. Thier monopoly status allows them to treat their employees like royalty while trying to tackle large problems.

To build a monopoly, Thiel advocates starting small and dominating a niche market. Be the big fish in the small pond. I think the bootstrapping community has this down on the small scale. They advocate niching down your product so that it serves your target audience perfectly. The primary difference with Zero to One is that once you master that small scale niche, you then expand your reach. Facebook is a great example of this. It started off with just one college and spread like a zombie plague from school to school. I remember the day when Facebook arrived at my school. Nearly everyone on campus was signed up within a week. It was insane.

Honestly, I think Thiel overstates his contrarian-ness here. While his criticisms of the lean model are legitimate, his alternative is very similar. Start small and blow up. I like how he focuses on sales, which is a dirty word to most developers. The importance of selling is often understated in the Valley. Even the best product will fail is no one’s heard of it.

Fail to plan or plan to fail

Shallow men believe in luck, believe in circumstances… Strong men believe in cause and effect
– Ralph Waldo Emerson

Indefinite attitudes about the future explain what’s most dysfunctional in our world today. Process trumps substance
– Peter Thiel

One of the major themes of Zero to One is the importance of making plans. One of the biggest problems with our society right now is this indefinite attitude towards the future. America used to be a country of big ideas. Even normal people felt they could come up with something big and pitch it to the public. Today, people who think big are often attacked. Ambitious initiatives, like seasteading and life extension, are regularly attacked by lovers of the status quo. If people like Tim Ferriss or Peter Thiel are indicative, having detractors is evidence that you are doing something right. People who change the world are going to make some enemies.

Conclusion

The most contrarian thing of all is not to oppose the crowd but to think for yourself.
– Peter Thiel

The best part of Zero to One is that it will make you think. Unlike many business books, which can be summarized in a page or two, Zero to One is packed full of interesting and useful information. It’s one of my favorite business books and I think that it’s a good book for developers who want to build something great.