Tech Blog

The Interesting Problems

As a programmer I hate writing boilerplate code.  You know- the “stuff” you have to get setup before you actually start solving the problem you set out to solve.  There are a lot of code generators out that these days to address the boilerplate issue, but even then there are a lot of well-solved problems that we programmers have to solve over and over again. I wrote some time ago about the problem of inventing all of your own in-house technology, and the take-away is that there are a lot of well-solved problems.  Don’t write your own CMS system unless it offers something new and unique.  Don’t invent a new programming or data standard.  And please, for the love of all that is holy, don’t invent a new programming language. But let me flip that over and talk about what sorts of problems are worth solving.  If you work for a business, most of your problems are shared with other businesses, but a few are unique to just you.  A lot of the time, that uniqueness comes down to what you know, how you know it, and how you can show it to your customers. With that said, I think there are two really interesting and compelling problems in modern software development.  They are both related to what you know and how you communicate it. Problem #1: Big Data The problem is that no one can really define “big data.” Job descriptions for data positions are all over the board, there’s not a lot of guided coursework or certifications, and what is out there right now won’t make any sense in a...

TypeScript and the Future of JavaScript

I’m not bashful about my enthusiasm for JavaScript (can enthusiasm be bashful?).  But as many others have pointed out, JavaScript kinda sucks.  And even though ES6 (the next version of JavaScript) has features to help resolve a lot of the pain, developers can’t really use ES6 on public websites for another three to six years.  Remember, up until very recently, web developers were expected to make websites compatible with Internet Explorer 6 (Hello 2001!). ES6 is the future, and it’s here right now, but we can’t use it yet.  So what can we do as JavaScript developers to make our lives better? There are two answers emerging.  One is to write in ES6 and run it through a compiler that “transforms” it into ES5, the current version of JavaScript.  The other is to write in different language entirely, such as Dart or CoffeeScript (get the pun?), which can be compiled into ES5.  Either way, you can write run-anywhere code, but work in a language with fewer pitfalls. But not so fast!  Remember, learning a language takes time, and mastering it takes even more time.  And writing in a language that writes a language ( Dart-> JavaScript)?  That means you need to know both languages, despite any claims to the contrary. I have a pet peeve with code that writes code.  Unless it’s a commercial product, or a popular open source tool, I avoid it because it’s just too easy to write buggy code, which in turn generates more buggy code.  I write all my bugs by hand, thank you very much. Kidding aside, I recommend getting good at JavaScript before learning a language that writes...

Why Tech Projects Fail

Tech projects are hard.  If you work in the tech industry, or have worked on a tech project in some capacity, you already know this.  They are hard to get right, hard to get done, and hard to even get started.  68% of tech projects fail in some way.  Only 2% of companies regularly achieve software project success. Now that all that gloom-and-doom is out of the way, let’s take a look at why they fail, and how you can minimize your risks. Our People Matter Companies are made of people.  Even programmers are people, albeit strange ones at times.  And people are all different.  Put the right ones in key positions; play to their strengths, their ambitions, even to their egos.  But the wrong person in the wrong role can disrupt everyone else. Look in the Mirror Once you know your people, know yourself.  Take an honest moment of reflection.  The biggest marker of an organization’s software success is its business analysis capabilities.  Do you and your team have the chops?  It’s ok to say no.  That’s why there are consultants; you can “rent” their insight and competence to help you through a project.  Remember, paying for success is much cheaper than paying for failure. We Didn’t Define the Problem Technology is only valuable if it does something better than the old way.  Rewriting a 17-step manual process from MS-DOS so it’s a 17-step manual process on an Ipad isn’t solving the problem.  Now it’s a problem that employees can experience on the go! Some problems show themselves pretty plainly; things that cost money (and shouldn’t) or upset employees, things...

Angular 2 in Developer Preview

It was announced today that Angular version 2 has moved out of “Alpha” release phase and into Developer Preview.  For geeks like me, this is big news. Here at work, Angular.js has become a favorite tool.  I totally geek out about model binding, Bootstrap UI, and declarative HTML.  But I’ve been hesitant to start any new projects in Angular.js v 1.x because version 2 is so close. Angular 2 is going to solve a lot of problems for Angular developers: it will be easier to write directives/components, there will be a “right” way to write services, and even the markup attributes help clean things up.  The reason all this matters is that developers can write cleaner, more bug-free code, faster and with less hassle.  Considering the gift that was Angular 1.x, that’s saying something. My favorite things I’ve seen so far, in no particular order: ES6 (The newest version of JavaScript) support, out of the box. Tight integration with TypeScript to simplify writing compilable code. Differentiation in the markup: Square brackets [] signify expressions or properties. Parenthesis () signify event listeners. The pound/number/hash symbol is used as a reference- particularly handy for iteration. Asterisk can be used for flow-control directives like “for.”  Combined with the # sign, it would look like: *for=”#name in names” Scope isolation! Transclusion is being retired. Shadow DOM and performance improvements. Data-binding can be once, one-way, or two way; this can contribute to performance and clarity of code. Of course it’s not all clear sailing.  There are still a lot of questions, clarifications, and complaints.   The Angular team is taking a big leap with this new...

The Big Day

Today is the big day.  Not daylight savings, or tax day, or even my birthday (send presents, because you just missed it).  No, today is the day Google is making their big algorithm change to favor “mobile friendly” websites. If you’ve been paying attention, you might be ready and it’s an exciting step forward.  If this is news to you, don’t panic.  We’re here to help. What it Means “Mobile friendly” is a pretty broad term, but Google are focusing on usability.  From their post last November: A page is eligible for the “mobile-friendly” label if it meets the following criteria as detected by Googlebot: Avoids software that is not common on mobile devices, like Flash Uses text that is readable without zooming Sizes content to the screen so users don’t have to scroll horizontally or zoom Places links far enough apart so that the correct one can be easily tapped A follow up in February says: Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices. Reading between the lines, it means that your traffic will be impacted one way or the other. Who Needs to Change Google has released a mobile-friendly test tool to help you analyze your home page.  It only analyzes one page at a time, so it can’t analyze  your entire site in one pass.  What it’s good for is getting...

Non-Violent User Experience

I recently had solar panels installed on my roof.  I could write a lot about the experience and what I learned, but one thing in particular stuck out: the folks who built the computer that controls my solar array have a totally different understanding of user interactions than I do. In my work life, I am in a world of web browsers and mobile devices: there are clicks and swipes, navigations and refreshes, logins and authorizations.  If you think about it, there’s a lot of imaginary stuff going on in the world of web and app development.  We expect that the user is going to interact with subtle and controlled gestures, and the computer or smart phone will respond with a something that “feels” like a real world reaction.  Try rotating your phone while browsing, or even just scrolling on it: the page moves as if there’s inertia.  Someone did a lot of math to get that imaginary inertia to appear natural. So imagine my surprise when I learned that the way to wake up the computer on my solar array is to hit it.  The conversation with the installation tech went something like this: “If the screen is blank, just hit it.” “You mean, like a button or something?” “No, there’s a symbol down there that shows you what to do.”  He pointed at an icon of a fist with an arrow pointed toward a box. I examined the icon, pushed it with my finger tip, and he interrupted, “No, like this,” and punched the screen with his fist.  It lit up merrily and provided a read-out of system...

WordPress Roles

Today we’re going to look at how to use roles in WordPress to help facilitate content-generation, and how roles can help you develop a smarter publication workflow.  This post will focus on how roles relate to content-generation, and the different access levels an editorial team might need. The Built-Ins WordPress comes with built-in roles.  You can think of them as “access levels” to different functionality.  The goal is to allow different people to access different functionality in the control panel without giving them access to core settings on the site.  Users can be added in one of two ways: by signing up, or by being added by the administrator.  Roles can only be assigned by an administrator. If your site allows people to sign up, they generally get signed up as Subscribers:  this is the most limited role.  Public users who “sign up” to your site are assigned this role.  For instance, if you require a login to comment on a page or post, the user can join your site as a subscriber.  Basically, subscribers get to add or delete their own comments, edit their own profile, and very little else.  While the subscriber’s role is very limited, it can be extended significantly with plugins to create social networks, content aggregation… the sky’s the limit.  In fact, the core of WordPress is designed to be simple and low-frill so that plugins can be added to suit your needs without having to override a lot of cruft. The other path to creating users- through administrator action- goes as follows: the administrator adds users through the “Users” link in the control panel. At the bottom of the...

Apples, Oranges, and Web Developer Tools

I came across an article titled “PHP vs. Node.js: An epic battle for developer mindshare” and articles like that bug me.  I like that they are talking about developer mindshare, because mindshare can really impact the quality of tools and end results from a given platform.  But posts like “this tool is better than that” don’t help developers choose the right tools for the right job, or help clients understand the big picture.  So I thought I’d share my take on the topic. PHP came out in the mid-1990s, as did the JavaScript language, upon which Node.js is built.  Node is only a few years old, but it’s still fundamentally JavaScript on the server.  Both tools are about 20 years old, but have radically different histories- in part because they were built to solve different problems.  20 years is a very long time in computing, and the problems PHP and JavaScript were built to solve have changed, a lot. The Mainframe is Dead Back in the bad old days of computing, computers were so expensive that it made sense to have one really big computer with many “dumb” terminals.  The big computer, the mainframe, did almost all the work.  When personal computers and the internet started becoming widespread, it shook that model to the core, and PHP was part of that vanguard.  Suddenly users were sitting at powerful workstations instead of dumb terminals, and the role of the mainframe became one of dishing out content (called HTML) instead of the entire application.  The web browser was the application, and PHP was a great tool to deliver content to it. Of course a whole host of...

Methodology Showdown, Part II: Waterfall

In this installment of the methodology showdown, we’re going to tackle the Waterfall methodology.  Last week we talked about Agile, and where it can shine.  This week we’ll talk about where Waterfall is the right choice, and how you can use it to achieve success. Waterfall is an older methodology, but it’s hung around for good reason: it’s a really solid path to success. Waterfall takes its name from the nature of the methodology itself: each stage happens in sequence, flowing into the next phase.   Where it Works Waterfall works in well-defined projects, or in projects where there are many stakeholders.  Waterfall has a reputation for being documentation-heavy, but that can be a good thing.  Think of the space shuttle: many teams from many companies agreed on the specifications and performance of each part in a giant machine.  The end result was individually crafted parts to create a more complicated whole. The documentation phase of the process is really two parts: discovery and planning.  Get the stakeholders together and figure out what they want and need in writing.  Then take information, make a plan, and present it in writing.  Both the requirements document and the plan get signed and approved by all the stakeholders.  It’s those two documents that serve as the yardstick for success. Who it Works For (And Who it Doesn’t) You’ll see Waterfall used a lot in larger companies and especially government contracts.  It’s partially an issue of company culture, but there also a degree of permanence to the Waterfall methodology that fits the needs of slower-moving business units. For instance, point-of-sale systems or inventory control software; they need to meet...

Methodology Showdown, Part I: Agile

When it comes to tech projects, you’re likely to hear about the work being divided into phases, or stages. Known as software development methodologies, or systems development methodologies, these frameworks allow developers and project managers to parse out everything from requirements and design, to testing and maintenance. In this new series, Method to the Madness, we’ll look at different software development methodologies, how to choose one that’s right for you, and how to increase your chances of success. Today, we’ll look at Agile. The Agile methodology began a few years ago when a group of software developers wrote The Agile Manifesto. In short, the intent was to empower people to do produce good work. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. In practice, this involves short development cycles with working software at the end of each one. You won’t see an exhaustive discovery phase, an iron-clad contract for expected features, or a lot of documentation. The reason? Every cycle, usually called a “sprint” or “iteration,” contains all the ingredients of a long-term or more traditional project development process, just in miniature. It looks like this: Where it Works Agile software development works well when you don’t have a set-in-stone outcome, but have a really strong sense of direction....

Programmer Automation = Customer Happiness

We recently posted about using Jira as a project tracking and management tool- from the viewpoint of a programmer.  One of the big things a system like Jira does is provide a centralized view of what’s going on.  But there’s a lot more power under the hood than just good-looking screens. We’re going to look at some of the automation that can be put in place to reduce software development pain.  That’s pain in dollars, hours, and bleary eyes at the end of a long day.  Or even at the end of a long development cycle.  Tired people can make mistakes, but computers don’t get tired, so let’s harness them to take as much load of the software team as possible. The Basics First, developers need to be using a first-class source code control system.  I personally won’t work for a company that doesn’t, and you shouldn’t work with one either.  It’s the foundation for almost all software development automation.  It’s too big a topic to go into any depth here, but ask your tech partner about it.  They should be experts at the fundamentals. For us at GeekHive, Jira is linked into our source code control system.  You can see what changes have been committed, how often, and by whom.  You can drill down into the gritty details.  That might seem unnecessary at first, but remember this: when a programmer commits changes to the system, they are also committing notes on the change.  Those notes are important information and should be visible to anyone on the team.   Clicking the “1 commit” link opens a screen with those...

The Tinker’s Dilemma

I have a developing friendship with a gentleman who used to be an HP exec.  To say the least, he doesn’t waste words.  His philosophies on human interaction have given me a lot of food for thought. Know Thyself Like many programmers, entrepreneurs, artists, and creatives, I’m a natural tinkerer.  I like to get under the hood and see how things work, change it up a little, and maybe get a better result.  Sometimes the outcome is something really special.  Or maybe it’s a deeper understanding of how stuff works.  But a lot of the time it is just lost time, or maybe a broken thing. Yes, sometimes I can’t get it put back together again. Are you a tinkerer?  If so, know there’s a cost involved.  Learning and exploring are powerful and compelling experiences, but sometimes if you need to solve a problem, tinkering is the most expensive path.  That’s money and time; the former is in short supply and the latter can never be refunded. Well-Solved Problems “If someone else has found a solution to your problem, buy it.”  That was a comment in a conversation this last weekend with my new friend.  That’s a message we all understand on some level, but he led with it.  And then he stopped talking. Buy-in doesn’t necessarily mean spending money.  Sometimes it’s a matter of changing your point of view.  I’m a big proponent of Open Source software.  It’s free in the financial sense, but truly buying into the Open Source ecosystem takes a mental, emotional, and cultural shift.  That’s hard for one person to do, so getting an organization...

Enter the Emoji

I was having an instant messenger conversation with a couple of my developer coworkers the other day.  One of them asked if I recognized a chunk of code from a project I’d worked on a while back.  He pasted the block of code into the messenger window and clicked send.  What I got was a flurry of smiley cartoon faces, flapping birds, and envelopes disgorging their contents onto the screen.  In other words, Emoji.  Welcome to the new web. For us mere mortals, emoji are basically smiley faces; they are small animated images we can use in text messages and email to add emotions.  The humble semicolon and close-parentheses become a winking face.  😉  Slightly more complicated symbols get transformed into hearts or dancers.  Think emoticons++.  On the surface it seems cute and trite.  But to many users, emoji have become much more than decorations: they add emotions and context to an otherwise flat text message. Apple recently announced they have expanded their emoji collection to be more racially diverse.  Not only does that make sense, given that smart phone use is exploding in developing countries, but it also shows that the practice of adding context-invoking pictures to a message is becoming mainstream practice. Furthermore, what differentiates emoji from emoticons is that emoji are actually part of the character set on a computer.   I’ll say that again, they are part of the machine. I joked with my coworkers that I was going to invent a programming language that was all emoji and emoticons.  They yelled at me.  I kept at it long enough until they laughed.  But the truth is the way we...

Software Project Success 101

So you or your company have this technology project, and it’s really cool and it’s going to be a great success.  All you need to do is get started. The scariest phase of any big job is starting.  That’s the time when you know the least, have the most work left to do, and have the least direction and momentum.  But it’s also the time where creativity and initiative can make a huge (and exciting) impact on the final product.  So how do you get started in a way that minimizes the scary and maximizes the exciting? The short answer is “start with the big stuff.” What Problem are You Solving? It might be something simple like getting the word out about your company in a creative or impactful way, or it might be sophisticated delivery of media to mobile devices.  Know what you’re trying to do, and do that one thing well.  If there are other opportunities that come up during the project, write them down and tackle them next time.  It’s better to do one thing really well than several things poorly. Who are You Solving it For? Know the people who are going to use your technology.  And I mean actually talk to them.  You are one of them?  Great, go talk to a bunch more of them.  Draw pictures, listen, ask for honest feedback, and take it back to the drawing board until people are looking forward to using it.  Even the simple stuff can be compelling, if it means something to people. Who is Your Technology Partner? Find a partner who not only has the...

Node or Not

Front-end web technologies are maturing at a break-neck pace.  It’s hard to keep up, to manage versions and dependencies, and stay abreast of the latest best-practices.  Heck, it’s hard just getting stuff to work correctly without having to go off-roading through someone else’s github repository.  But luckily, there’s a back-end framework that manages all that front-end stuff effortlessly. The other day I mocked up an administrative web dashboard using the rdash framework.  It was quick and easy- I slapped some dummy charts on it, filled in some Lorem Ipsum and showed it off.  It took only a few minutes to get all the frameworks in place; Angular.js, D3.js, Bootstrap, and a whole host of others to glue it together. Then the cool part started.  As I was showing the mockup to a coworker, I made a change to the code- and the web page automatically refreshed with the changes in place.  I had served up the web app using gulp.js, which watched the local file system for changes, rebuilt the entire app, and sent a message to the browser to refresh itself.  My coworker exclaimed that it must save a lot of time, not having to save, build, and then refresh for every change.  Yes it does. All made possible by node.js. If you’ve paid any attention to the web and software development world in the last couple years, you’ve heard about node.js.  You’ve probably even seen the blog posts about what it’s good for and what it’s bad for (video).  The whole conversation has become stale, so let’s ask a better question: should you use node? If you’re a developer, Absolutely.  But maybe not...

The Smartest Man in the Room

I’m a big fan of the BBC show Sherlock, in part because of writing and acting, but largely because the whole thing is driven by his singular genius and the friction he creates between himself and every other character.  In the tech world, we work with a lot of very smart, yet oh-so-prickly people.  It seems to come with the territory. But I was reading a post a few weeks ago titled, “Why I’m Kind Of Tired Of The ‘Smartest Man In The Room’” and it got me thinking.  Sometimes I fancy myself the smartest person on the team, but experience has demonstrated that “smart” and “successful” aren’t the same thing, and even if it were true (it rarely is), I’m not the sort of save-the-day genius portrayed in Sherlock. The truth is, no one is that smart. One of the big take-aways of reading that article was that most of the protagonists are really smart, and really awful to work with.  They’re jerks.  And somehow it’s okay to be a jerk if you’re really smart.  But in the real world, it’s never okay to be a jerk. I know that New Year Eve is a week behind us, and Thankgiving is soooo last year, but I’m thankful that my software development team is nice as well as smart.  That makes a difference not just in our personal interactions, but our interactions with our clients, and even our success rate.  Moreover, we cherish good process rather than save-the-day fixes. Watch an episode of Sherlock and you’ll see everything going down hill all episode, things in peril, and all the interpersonal...

Whiz-Bang

One summer during college I worked with my dad in the maintenance department of an auto parts factory.  One of the old-timers in the department was a guy my dad called “Whizbang.”  It was a moniker that was equal parts admiration and ribbing, because no matter what the challenge, Whizbang knew the answer and strode in to fix the problem.  And sometimes the failures were spectacular and hilarious. Keeping things running- metal stamping machines, lathes, cutters, and the like- wasn’t a science so much as an art.  Some of the machines pre-dated me, but still had the manuals tucked into cabinets on the side.  The guys from the maintenance department rarely used the manuals though.  They preferred experience and the habits won from working it out on the fly.  It also turned out that the manuals were routinely wrong.  Users didn’t use the machines as the manual implied, the controls shown weren’t the same as those on the actual machine, wiring diagrams were outmoded, previous repairs had change the configuration…  It certainly wasn’t “by the book,” but in the auto parts got made and the team of maintenance workers all knew how to keep things running because underneath it all, the fundamentals of every machine were the same. In the factory it was clear why we called it “Production.”  The most important thing was to produce- to maintain up-time, to operate safely and legally, to get rid of as many bottle-necks and breakdowns as possible.  It was important that your coworkers could support your work.  It was not important that fixes were perfect, or even very pretty. Now I’m a...

Not Your Father’s JavaScript

Last week I sat down to a meal with some friends and the topic turned to what I do for a living.  And because I love Node.js, Angular.js, Socket.io, and a whole bunch more, I talked about how JavaScript has really taken center stage in web development.  Yeah, I’m that guy at parties- I talk about code. One of the friends at the table is a CEO, who is also incredibly technically astute. After rising to EVP at a major tech company, he left and launched several successful start-ups.  He’s also been around the block enough to know where JavaScript came from, so when he commented that, “It’s completely unstructured,” I really got to thinking.  Lack of  structure carries a cost- money, time, frustration, performance.  And his statement is true, but only if you write unstructured JavaScript code. The sad part is that most JavaScript written in the last 20 years is unstructured, and that is a terrible legacy to inherit.  But it’s not the only legacy.  JavaScript has some really good parts, is capable of wonderful syntax and functionality, and runs on every computer out there.  That is a legacy worth investing in.  And it’s one that a lot of the modern front-end frameworks invest in by providing structure and tools to streamline development. Modern web apps are shifting the weight of handling user interaction back onto the browser.  User interfaces are more sophisticated, interactions more mature, and user expectations are high.  The code that powers that stuff? JavaScript.  But it’s more than that: powerful business logic is being implemented in the browser too.  The server no longer renders full pages...