Tech Blog

More Than Meets the Eye

It’s the time of year to make predictions about web development trends in 2015.  It’s also the time of year to reflect on how wrong we were in last year’s predictions, or in some cases, how the “prediction” was actually just declaring what’s already happening.  If you follow the train of  predictions down the track, you have already heard about Flat Design, Retina/High-Res Screens, and Parallax.  What you may not be paying attention to though is something called Augmented Reality. From Wikipedia: Augmented reality (AR) is a live direct or indirect view of a physical, real-world environment whose elements are augmented (or supplemented) by computer-generated sensory input such as sound, video, graphics or GPS data. In short, your mobile device can add to your experience.  Think about moving through a museum and virtually interacting with the collection in ways the physical world won’t allow.  Think of travelling with an infinitely-informed tour guide, ready to show you secret drives or the path to a great diner.  It’s what your phone already does, but integrated into your daily experience. There are already some apps that provide augmented reality, but we’re going to see more and more context-aware web applications as well.  Mobile browsers support location services, access to the camera, even support for motion detection- everything that a native app has access to.  That means mobile websites will soon wade into the waters of augmented reality. A couple reasons I believe that web apps will eventually be better than their native brethren are 1) there are a lot of web designers and programmers all over the globe who have a vested interest in building great...

1 is Greater Than 1.5

Back in the late 1990s, when internet still got piped into peoples’ houses by way of a modem, web developers cared deeply about the download size of their websites.  After all, there was only so much patience you could expect of a user on a 128 Baud connection.  But broadband solved all those problems, right? In a way, broadband solved a lot of problems, but it also moved the needle on acceptable user experience.  I remember waiting patiently for 10 or 20 seconds for a page to download on the phone modem, and that was ok.  These days if I have to wait 5 seconds I’m a little irritated.  So users expect fast, but are we giving it to them?  Not really. Internet speeds have risen dramatically since then and it’s pretty routine to stream video at home.  The pipes are much bigger, so all that worry about file size doesn’t make business sense.  But it does: there’s a confounding variable in the mix, and it’s called the iPhone.  Before the iPhone, internet connectivity on a phone was a sort of novelty act, but now it’s standard.  Remember, it was only 2007 that the iPhone appeared, and now the entire web industry supports mobile web.  We have terms like “responsive design” and “mobile first” to help lead the way.  But it hasn’t been a painless ride, and we’re far from done. It goes without saying that a mobile phone doesn’t always have the best connection.  And under the hood is another insidious little problem: cellular networks have a lot of latency.  What that means is for every image, every JavaScript or...

Dust Bunnies and Your Search Ranking

There are a lot of “tricks” to boost your search ranking, but the best bet has always been to say something worthwhile, and say it well.  The first half of that is often summarized as “content is king,” however the other half -say it well- often gets glossed over, as if punctuation and grammar are the vehicles of the web.  In truth, code is the mechanism for delivering content, and Google has started indexing fully rendered pages– including CSS and JavaScript.  That means a lot of things, but the important take-away is that clean code matters. “Clean code?” you say?  Yes, because the web has always been a messy place.  In an ideal world, all web browsers would expose the same functionality, would adopt new features at the same rate, and users would upgrade their browsers eagerly.  Web programmers are either laughing or crying at that last sentence because we remember the “browser wars” of the late 1990s.  In short, browser makers were adding new features faster than any standard specification could be written, so it was routine to see “Best Viewed In Internet Explorer 6” on a web page, all other comers be damned. As an outgrowth of that mess in “the good old days,” usability across other browsers was a secondary concern.  Thankfully that hasn’t lasted.  Nowadays users demand a high quality user experience, regardless of browser, device, screen resolution, or language.  To address those concerns, web programmers have gladly jumped on the various bandwagons, including AJAX, responsive design, HTML5, CSS3, etc.  The quality, sophistication, and usability of web sites (and now “web applications”) has improved drastically, but...

Are You Using the ‘Phant?

Most folks have heard about “The Cloud,” and how it can make your business amazing.  But have you heard about The ‘Phant?  The Cloud has a lot of hype to live up to: speeding up business processes, making data secure, and lowering costs, but The ‘Phant is a guaranteed solution: it never loses data.* Of course, storing all of your data in an elephant is a joke, but it does make you wonder about The Cloud: is there a hidden joke there too?  Maybe joke is too strong a word, because there are some wonderful success stories.  But those success stories came with a price tag: planning and strategy. I was watching TV a while back and heard the slogan, “To the cloud!” in a commercial.  The implication was that in the new business wonderland called The Cloud, technical problems disappear.  In truth, technical problems never ever go away, they just get moved around.  When you “move to the cloud,” are you moving problems out of your life, or into it? The Cloud is a new enough term that no one can really define it universally.  As an IT professional, I have a technical understanding of cloud-based computing that is basically meaningless to a CFO or marketing exec, while a network administrator might have an understanding that is worthless to me.  So rather than define what the cloud is, or what it can do for you, define your problems and your goals.  Then ask, “Is the cloud good at X?  Better than my current solution?” By identifying your problems first, you might identify a solution that is cheaper and faster than something a...

#ATO Wrap-Up

I attended the All Things Open conference in Raleigh this last week.  I was impressed by the size of the conference, as well as the quality of the presentations.  As we know, content is king, and I saw some great content. For me, the most memorable spot was by Scott Hanselman.  He is a great speaker, and very knowledgeable.  He talked a bit about JavaScript and its role in the future of application development.  He covered a lot of history, even the un-flattering parts, and talked about what the future looks like.  Not only at Microsoft, where he works, but in the JavaScript world in general.  It was a vision that is far enough out to be inspiring, but grounded enough to be useful. The other stand-out presentation was Pamela Vickers on company culture.  We in the tech industry are in the midst of a grand experiment in “getting it right.”  Why is “culture” on so many job posts, and what does it mean anyway?  Do you motivate people to be productive, or do you give them inspiration and get out of their way?  She talked a bit about women in tech, which was a prevailing theme at the conference, and of course the ubiquitous ping-pong table in job postings.  I know I didn’t choose my workplace based on the presence of a game table, but a quick search seems to indicate that “ping pong” is an important thing in the minds of some tech recruiters.  It’s a great thought-starter. Like I mentioned, the topic of women in the tech workforce was a theme of the conference, and several panels and presentations...

Node.js and REST


Warning: file_get_contents(https://bitbucket.org/danielclouse/why-rest/raw/5139a934576196a20b34d522340ce7490c36a4d5/sailsAPI/api/controllers/FooController.js?at=master): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/public/wp-content/plugins/wp-git-embed/wp-git-embed.php on line 99
This is the second in a multipart series about REST APIs. Learning to REST Why REST Node.js and REST Even Microsoft Takes a REST (coming soon!) Getting REST with Angular (coming soon!) CORS and REST Across Domains In the last blog post I front end that consumes a simple REST API endpoint and utilizes http verbs in an idiomatic way.  In this post we will build a simple back end using Node.js and some tools.  Remember, the objective isn’t to to become a master at Node.js, but to understand what makes a REST API powerful and flexible. Preparation For the sake of brevity, I’ll be using the Sails.js framework since it does a lot of the work for me, and lowers the bar (considerably) for prototyping a REST API. First you’ll need to install Node.js.  They have great instructions on their website and support most operating systems.  Node comes pre-packaged with the Node Package Manager, or NPM for short, which is an indispensable tool for managing dependencies in whatever software you write. Next, you’ll need to install Sails.js.  To do this you’ll use NPM with the command: npm install sails -g If you’re on a Mac or Linux system, you might need administrator privileges to do this, so the command is: sudo npm install sails -g Next up, tell Sails to create a new application.  For this demonstration, we can call it “sailsAPI”: sails new sailsAPI Sails created a folder and a Node application for us.  Navigate into that folder, then tell Sails we want to create the scaffolding for a new model and controller called “foo”: cd sailsAPI sails generate api...

Why REST


Warning: file_get_contents(https://bitbucket.org/danielclouse/why-rest/raw/5139a934576196a20b34d522340ce7490c36a4d5/sailsAPI/assets/js/main.js?at=master?at=master): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/public/wp-content/plugins/wp-git-embed/wp-git-embed.php on line 99

Warning: file_get_contents(https://bitbucket.org/danielclouse/why-rest/raw/5139a934576196a20b34d522340ce7490c36a4d5/sailsAPI/assets/js/main.js?at=master?at=master): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/public/wp-content/plugins/wp-git-embed/wp-git-embed.php on line 99

Warning: file_get_contents(https://bitbucket.org/danielclouse/why-rest/raw/5139a934576196a20b34d522340ce7490c36a4d5/sailsAPI/assets/js/main.js?at=master?at=master): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/public/wp-content/plugins/wp-git-embed/wp-git-embed.php on line 99
This is the second in a multipart series about REST APIs. Learning to REST Why REST Node.js and REST (coming soon!) Even Microsoft Takes a REST (coming soon!) Getting REST with Angular (coming soon!) CORS and REST Across Domains In the first blog post I talked a little about REST conventions and hinted at some implications for how REST APIs can and should be used.  In this post I’ll talk about why. Learn It, Love It, Live It Most REST APIs “speak” JavaScript, or more specifically JSON (JavaScript Object Notation), so let’s get something out of the way: even if you don’t particularly like JavaScript, it’s good to learn The Good Parts.  Back-end programmers, I’m talking to you.  Writing good front end logic is hard because users are unpredictable.  Don’t make writing the front end harder by imposing a complicated API pattern.  REST APIs are supposed to make it slightly less complicated by providing a uniform and pattern-driven way to read and write data from the front end.  That makes a front-end engineer’s life a bit easier.  On the other hand, a poorly designed or implemented REST API can make for more work. Even if you never ever do front-end work, and never touch the browser, remember that somebody else does.  A little bit of time and consideration on your part can make someone else’s life much much easier. Lifting Sails There’s a really elegant little framework for Node.js which makes REST patterns painfully obvious, and it’s called Sails.js.  If you’re not familiar with Node, I recommend taking 15 minutes to download and install it.  There’s a lot of cool stuff going on...

Tech Work is Still Human Work

Back in the 2000s the web was a wild new place; a place with new rules, or no rules at all.  It was a place where brave entrepreneurs could make millions, or even billions, just on the strength of their ideas, tech chops, and resolve. That’s how the story goes anyway.  It’s not all true, it’s not all good, and it certainly isn’t all pretty.  There are still a few hold-overs from those heady days that on the surface seem innocuous, but really hold us back. In short… Words Matter I started working as a programmer and web developer in 1999, and over the years I’ve seen job descriptions and job titles change.  In the very early days, companies didn’t know what to ask for; job searches were a blind grab for tech talent.  But as the industry matured, those roles have become better defined, better understood, and the whole software development life cycle (SDLC) has gone from arcane magic to well-worn path.  Now we can expect a “Senior Web UI Programmer” to have a certain set of skills and a certain longevity. Job descriptions and job titles are an area where the tech industry needs to take a moment to reflect.  If you’re job hunting, or if you are a company looking to recruit, try to remember that the dotcom bubble burst, and with it went all of the “new economy” daydreams, like calling yourself, “Chief Cookie Monster” on a resume.  So a job title of “Rockstar Coder” or “JavaScript Ninja” is a dead giveaway that reflection hasn’t happened. If your company is really competent, and you can reliably...

The Dog Food They Didn’t Eat

The other day a friend of mine was saying that she had clicked the “unsubscribe” button on the bottom of some email she had gotten, and then the emails kept coming.  I don’t recall if the unsubscribe process actually broke, but it was clear that it didn’t work. My politically incorrect response was that she should find their contact email and sign them up for their own newsletter.  Then do the same with the admin email, and every email she could find on their site.  Make them try to unsubscribe, and be forced to deal with the problem. One of the hardest and most important lesson you learn as a programmer is to eat your own dog food.  Basically, use the things you make.  There are a number of reasons this is a good practice, but the short answer is that if you don’t use your own stuff, you’ll never know the poor experience you’re putting your users through. How do you handle frustrating web...

Learning to REST

Learning to REST Why REST Node.js and REST (coming soon!) Even Microsoft Takes a REST (coming soon!) Getting REST with Angular (coming soon!) CORS and REST Across Domains The word “REST” has become something of a buzzword in software developer circles lately.  It’s an architectural style (REpresentational State Transfer), that allows programming languages and development platforms to pass data back and forth over the web without complex protocols or a lot of overhead.  The simplicity and lightweight nature of REST  make it a great tool for a lot of web projects.  But old habits die hard. I work in a .Net programming shop, and I’ve noticed a pattern.  Actually, I’ve wandered the web in search of good code to learn from, and I’ve seen the pattern there too: programmers treat REST like it’s a new form of MVC (ASP.Net Model-View-Controller framework), or just another server-side implementation of AJAX (Asynchronous JavaScript And XML).  Or worse yet, they treat it like a new flavor of WCF (Windows Communication Foundation).  It’s related to all of those things, but it isn’t those things. The pattern I see too much of comes from the MVC side of things.  In MVC you name your actions as part of the URL, and you rely primarily on HTTP’s GET and POST verbs.  So you’d GET someurl/user/dan and the framework would dish up some HTML that represents the “dan” user.  To update data to the framework you might have a method called “save” you could invoke by POSTing to someurl/user/dan/save.  In this scenario, any “action” that must be performed on the “dan” user would be specified as a method of the “user” controller....

Who We Work With

When I started my job as a software developer at my current employer, I noticed a few things.  First, everyone was smart and competent.  Second, they were nice, pleasant to work with, and got things done when they said they would. Third, almost everyone was a man. These Young Men are Actually the Good Old Boys The realization that I work in a male dominated field wasn’t a surprise.  I’m a classical and folk musician, and those are heavily male dominated as well.  But at least there’s an open conversation happening there, with notable in-roads by women into the elite orchestras.  If I consider the last 4 jobs that I’ve had in IT, I’ve never worked with a female developer. In the tech field, recruiting is an ongoing puzzle.  The short list of qualifications for a software engineer is that they’re smart and get things done.  Yet, as hard as it is to find people who fit that description, I think it falls short.  “Diverse” needs to be added to the equation, not bolted on at the end of the search. The problem is deeper though, since companies are recruiting college grads at the end of a very long pipeline- one that is slanted towards men and away from women.  Colleges (well, some colleges at least) are acknowledging the gender bias, and changing their programs and measures.  If you’ve ever worked at a college, you know that’s a really slow process.  And more to the point, an institution making changes isn’t the same as a teacher changing his stance on women in the sciences and applying it to the...

I Hate Programming

I’m a professional programmer, developer, coder, computer nerd; so I don’t actually hate writing code.  But coding is the last thing I want to do to solve a problem.  Here is why: 1) Coding is expensive.  You’re asking someone to invent something for you.  It takes a lot of skill, research, and time to get the super-technical solution right.  Sometimes it’s the right thing to do, and you can make some amazing magic happen.  But without some serious planning, you can burn a lot of expensive time and energy when another (existing) solution would work as well. 2) There are a lot of great solutions that do 90-100% of what you want.  I use WordPress for my personal blog.  I’ve implemented the same solution for a good number of friends and private clients over the years.  It’s a good solution with good plugins.  I’ve implemented Sitecore as a solution, a number of the “nuke” platforms…  I *can* write a custom solution for each new situation, or I can be smart and re-use some of the great tools that already exist. 3) Sometimes the problem isn’t the computer.  Every business is unique, but every business is the same too.  That goes for people and the things they want to do as well.  What might come across as a shortcoming in the technology might actually be a shortcoming in your understanding.  Work to understand first.  If good tools and well-understood processes don’t help you, then invent something...

Know Your Tools

As a programmer and developer, I spend a lot of time thinking about tools.  Some tools are things like compilers, coding IDEs, or inspectors.  But other tools include things like a pen and paper for notes, stackoverflow for answers to questions, or samples of other people’s code for inspiration.  I’m currently renovating a house, and the process is remarkably similar, with the same sorts of tool-based musings.  A friend gave me some masonry tools that had been out in her garage, and my dad gave me a book he used a lot when he built the houses I grew up in.  Good tools come in all shapes and sorts. I had a conversation with a coworker recently where we were designing the moving parts of a REST API.  We got to talking about one approach versus the other.  His approach was to formalize everything so that our tools could work with the program in a very tightly-bound manner and in theory save us time.  My approach was to use the strength of the framework underneath to provide what we needed and leave things fairly simple so the syntax would be expressive.   The downside of his approach in that case was that we would have to change the output type, in essence change the product to fit the tools.  The upshot of mine is that we would have to write a bit more code by hand, but it would be easier to understand the whole picture be reading the code.  Our two approaches were at philosophical odds: rely on the intelligence of the human beings or rely on the intelligence...

Going Native

This is the third in a series of articles about writing mobile apps; the first and second using WinJS, and this time iOS using Xamarin.  In this article I’m going to talk about where I came from as a developer making some of these decisions, the philosophy of being a programmer in the weird-weird world of mobile devices, and what I want. First things first I grew up on the web.  I’m a little old to say that, but the truth is that I wasn’t really interested in programming until the web came around.  In 1995 JavaScript sucked, and couldn’t do very much.  But that was ok because the web didn’t really do much either.  So as the platform got bigger and stronger, so did my programming skills.  My heart has stayed there. And frankly, that’s a pretty good place to be.  There’s a lot of invention, learning, energy, community, and opportunity as a web programmer.  There are more “traditional” programming roles (desktop, ERP, network), with older more staid languages and platforms, but I’ve never clicked with those.  I was on a big project writing a medical records system in WPF a couple years ago: it was interesting stuff, some great tools, and then when the project was over I was thrilled to be back on the web for the next project.  And I don’t think I’m alone: look at github and bitbucket and you’ll see a lot of web-oriented stuff. So with that information, I’m going to talk about phones, tablets, and the war of the mobile platforms. Today there are three major contenders (arguably two, but I’ll get...

Fat Guy in a Little Coat: Angular.js and WinJS

This is the second in a series of articles about the experience of writing an app for the Windows 8 App Store.  In the first I talked a bit about some of the good and bad of developing with WinJS, and hopefully showed some pointers if you want to go down that route.  In this article I’m going to cover Angular.js, and how to successfully manage its relationship with WinJS. Control(ler) Freak Anyone following the explosion of JavaScript development frameworks will be familiar with the newest breed: MVC frameworks.  MVC (Model-View-Controller) frameworks seem to be hot stuff these days, with heavy-hitters like Knockout.js (sorry for the pun), Knockback, Backbone, Spine, Ember, Maria… it goes on and on.  There’s even a JavaScript MVC framework called “JavaScriptMVC” just so it’s perfectly clear what it does.  Angular is part of that family, but it has rapidly become one of my favorite tools for developing front-end interactivity. For the uninitiated, the Model-View-Controller pattern separates different kinds of programming code into different locations.  For instance, the code that tells the computer how things will look (often called “markup” or the “view”) will be in one place, the code that calls the shots, reacts to user clicks, etc will be somewhere else.  It’s called the controller for obvious reasons.  The “model” part of the design is the stuff that gets moved around by the controller and shown by the view.  Think of a model as your arms or legs, and the view like your clothes.  Your brain is the controller: it calls the shots, moves your arms and legs, and if everything goes right, the...

Lost in Translation: WinJS, Web Apps, and Jquery

WinJS is a New Country With the Same Language. I recently wrote a Windows 8.1 tablet app for my company, Parse3.  I learned a lot about the framework, async programming, and even (at my jaded old age) JavaScript.  This is the first in a multi-part series about my learning experiences with WinJS and its strengths and weaknesses. In the latest release of Windows, MS released WinJS- a development framework that is meant to draw web developers back into the “native app” fold.  It allows programmers to write desktop or tablet apps in plain-old HTML and JavaScript.  This seems like a win-win for everyone.  See, in order for the whole Windows App Store model to work, MS needs a lot of programmers churning out apps for its ecosystem.  A lot of those programmers are out on the web, where the technology is new and exciting, the visibility great, and the community mature.  So WinJS is an attempt to get some of that energy back into the MS desktop development arena, with the flip side that it lets web developers target the desktop/tablet with their core skills. In Theory. Jquery doesn’t work.  Let that sink in a bit. Jquery is one of the most popular and widely-used javascript frameworks on the web.  Most any web developer worth his or her salt will know Jquery like a trusted friend.  It’s like a carpenter’s hammer: not right for every problem, but oh-so-right when the problem is a nail.  Let’s face it, in web development there are a lot of nails to pound.  So not supporting jquery out of the box presents a road block,...

In Which I Geek Out

Have you ever watched builders, and said to yourself, “Those guys are using TAPE MEASURES.  Hell yes, this is awesome.” Yeah?  Because that’s basically what my last couple days have been like.  Except the builders in question are software people.  And shit, every builder knows how to use a tape measure. Most people I know sort of glaze-over whenever you start talking about building software.  I think that sort of behavior is a bad habit.  A habit that’s completely understandable.  Because bad software builders want you to think that there’s magic.  There’s mystique.  Smoke.  Mirrors. Indescribable powers at work. Nope.  It’s just 2x4s, nails, and close measuring. If your house isn’t level, you don’t blame the homeowner.  If the doctor’s office caves in on itself, it wasn’t because the new tenants were stupid.  If the vet’s office burns to the ground in an electrical fire, it’s less likely that the volunteers didn’t know what they were doing than it was that the builders didn’t know their craft. I’ve worked in software, on an off, for most of my adult life.  But I’ve been swinging a hammer since I was around 4 or 5.  There are certain things that just are. And one of them is quality.  Not the Robert Persig sort of Quality, but the stuff you touch and trust.  Like the floor isn’t going to fall out from under you.  You don’t think about it.  Not the “I hope my car makes it to 200 Thousand miles” but the sort that says, “I’ve been walking on these legs since I was born, and I’ll walk on them till...

Letters to Doug, Part III

This is the third in a series of letters between me and an old friend/coworker on learning how to develop websites.  Doug is a graphic designer in Michigan and is trying to convert his Photoshop kung fu into web ninjitsu.  You can read the previous letters here and here. Doug writes: Hi Dan, Good news. I sorted out my font issue finally. Sorta. I never actually managed to figure out the Typekit problem. In fairness, I probably should have reached out on the Headway support forums. What I ended up with was that after doing some more digging, I found exactly the type of font I needed in Google web fonts which made the whole thing streamline. Now my problem is trying to get my image slider working/looking the way I want. I may have to find a better plug-in. So my question now is this: if I wanted to get serious about being able to do this, what’s my education path? I think a goal would be to take a design from a Photoshop PSD to finished WordPress site, with enough ability to tweak code as needed to make things work. What little I know, tells me I would minimally need to learn CSS3, HTML5, and PHP. What do you think? And how is jQuery used? Thanks, Doug I’ve really given this some thought.  I don’t want to come across as too much of an ass, as one can sound that way when one is teaching. But assery be damned, this is how I think of it. I’m glad you got the font thing ironed out, and don’t...