Category Archives: Development

Attention Web Designers

Please stop doing the following.

Creating external links without a default target=_blank. You might be against it for whatever religious reason, but this doesn’t change the fact that people expect this behavior. I’m looking at you, Reddit.

Unnecessarily modifying the URL as you scroll through a page or highlight text. This makes me have to hit the back button 20 times.

Loading your title tags up with SEO garbage instead of my location on your page. This doesn’t help your SEO, and it makes tabbed browsing frustrating.

Infinite scrolling. Unless you can save the user’s position after they return to the page from clicking something, don’t do this. The user will have to scroll all the way from the top, wasting the user’s time and wasting your bandwidth even more.

Creating floating divs that pop up when you hover over text. I’m trying to read here.

Designing a website to be mobile-first without appropriately scaling up. This is just as bad as making a non-responsive website.

Needlessly using custom scrollbar solutions. These tend to break a lot and suddenly snap me back to the top of the page, or stop scrolling altogether. They also don’t scroll the way the user expects.

Using Hashbangs for AJAX crawling. That is so 2010. There are better ways to do this now.

Making black and white, animated on hover, circular cutouts for your About Us photos. Good lord, this is overplayed.

Outsourcing your blog to Tumblr. This is tacky. And what’s the point? Are you trying to anger the Google Gods? Or has Rails backed you into a corner with bad WordPress knockoffs?

Using slow CDNs. It sorta defeats the purpose.

Requiring users to use an app or sign in with Facebook. I leave every time, no exceptions.

Populating the meta keywords. No search engine since the 90s uses these. All you’re doing is giving the competition a glance into your marketing strategy.

Skeumorphism. No more cloth and wood backgrounds.

Java and Flash. The world really needs to move on now.

Wi-Fi Thermostats are Awesome

There comes a time when a man is unsupervised for 2 weeks, and random household projects take place. Gutter cleaning, hedge trimming, pump re-piping, mysterious projects involving an angle grinder, and on top of all this, the start of what will become numerous home automation experiments.

Anyway, I made the purchase of a Wi-Fi thermostat. It is a Filtrete 3M-50, and it rocks. The same thermostat is also labeled as a Radio Thermostat CT50 and other models. I found mine as an open box model on eBay, figuring some poor guy bought it and couldn’t figure out the wiring. Judging by the few missing wire labels but otherwise perfect condition, I figured right.

Hardware installation was surprisingly easy. Thermostat wiring is somewhat standardized, although my Trane unit threw a curveball at me as far as the “C” wire, which happens to be the most important wire to get a modern thermostat working. On a Trane, it turns out this wire is labeled “B”, and it took some research to figure this out (even Nest’s website couldn’t determine my setup). Anyway, I put the 6 or so wires in their place, fired it up, and it has worked ever since.

The Wi-Fi setup is slightly weird, and maybe it doesn’t look as sexy as a Nest, but it works well, doesn’t need a battery, has a touchscreen, a scheduler, and an app to adjust temperature and scheduling settings. But the thing that sold me on it… get this, it has a well-documented JSON-based REST API. *drools uncontrollably*

Why did I buy this passé, beige, how-you-say… uninspired box when I could have bought a Nest? I guess this would be why…

1) Nest had no open API. The only info I could find was reverse-engineered. It looked nice though.
2) Nest requires the cloud. As far as I could tell, you can’t address it on your network directly.
3) I wasn’t sold on the automatic scheduling. It has to see you for that to work, and my thermostat is in a room with no real traffic.
4) Their website suggested it was incompatible with my wiring. This turned out to be untrue.
5) There are a lot of scary Amazon reviews out there. Either you love it, or it destroys your life (and freezes your pipes). Not much in-between.
6) It uses a lithium ion battery. I don’t know about you, but I don’t want to replace the batteries on a thermostat every 3 years.
7) There was apparently a (forced) software update bug that bricked a lot of people’s thermostats in the middle of winter.
8) I don’t care what the hardware interface looks like… if it’s doing its job I shouldn’t have to look at it or touch it.

I’m not a Nest Labs hater or anything though. I like their Nest Protect product, even though it has a few problems of its own, and I may end up purchasing one or two of them. Heck, does anyone else make a Wi-Fi smoke detector?

So, I managed to write an extremely basic class in PHP that allows me to get and set the temperature, and I’ll be releasing it on GitHub soon as part of a big project I’m working on. A project which is getting closer and closer to release. 🙂

#OneSpark #EdSpark #YearOfAwesome #lolhashtags

So, since I’m not busy enough these days I decided to help out my friend Courtney with a project of hers she wanted to enter into OneSpark. If you’re not familiar with OneSpark, it’s a crowdfunding festival in Jacksonville that helps get innovation and investors in the same place, to help local projects get funded. That’s the idea at least, but in practice it’s more like an idea some rich bohemians came up with to get people to remember that downtown Jacksonville exists, while simultaneously not really managing to get anybody’s projects off the ground.

Alas, I promised myself this would not turn into a rant. 🙂

The idea we entered is a nifty one. It is an ABA Therapy App (in fact, that’s the name) that allows behavior analysts and therapists to work more efficiently with autistic children. Right now it supports manding, assorted flashcards, and analytics, but we want to do all sorts of useful things with the app. The prototype is currently written in jQuery Mobile, but it may be rewritten natively for the final version. All in all it is a pretty exciting project and we got a lot of great feedback. We also got some wonderful funding and met some great allies in our cause.

screenshot-numbers

This was all born out of a pact we all made called the “Year of Awesome.” I know that sounds like some kind of Honda used car sales event, but really all it is, is the promise that we’re going to have our twenties go out with a bang instead of a whimper. You know, get the ball rolling on stuff that should have been rolling years ago, like starting a business and building cool ideas. So this was a way to do just that, and I think we succeeded. Maybe we didn’t win prizes or anything, but we built something, attracted the investors we needed, and got a nice booth at EdSpark. And hey, we got more funding than most. Now there are some next steps to take care of, and you’ll soon be seeing some exciting new mobile projects from me.

The Year of Awesome is go.

Moon Boogie

My latest game involves driving a jumping pink jalopy around on the moon, whilst shooting heart-shaped bullets at aliens. Believe it or not, no LSD was involved in the making of this app.

Moon Patrol is one of my all-time favorite games (I even have the standup arcade game), so it was only a matter of time before I wrote my own version. It follows the same formula, but I changed a few things here and there. I actually wrote a Moon Patrol clone about a decade ago, but the source code got lost in a drive crash… this one is better anyway, haha.

screen568x568

Get Moon Boogie for Android
Get Moon Boogie for iOS

You’ll notice the iOS version costs 99 cents, while the Android version is free. The reason for this is the Android version is way easier to port than the iOS version, and I don’t have to pay $99 a year for a developer license like I do with Apple. Also, what I’ve noticed is Android users expect everything to be free (like Windows and Linux software), while iOS users are fine with paying a buck or two (like MacOS software). So, lots of reasons.

The holes were the hardest thing to implement. The game is extremely difficult, even for me, the guy who made the game. I spent probably 3 days trying to track down a weird Android bug, but I spent even longer cursing at Xcode over a file path bug. One final note: Disco Nick is hidden in the game, as usual.

Enjoy.

Fantasy Healthcare

I have an announcement to make: I placed 3rd in the Robert Wood Johnson foundation’s Games to Generate Data Challenge. I have been secretly working on this project for most of the year, and now that it’s over, I can talk about what I’ve been building.

Fantasy Healthcare is a game that allows friends (in the Wisconsin area for this version) to create their own healthcare provider dream team and pit it against other friends and players online. The provider data and provider names are 100% real, but the doctor/department names have been changed to protect the innocent. The idea is that players will better familiarize themselves with providers in the area, while also learning which providers perform best in certain areas.

The interesting part of all this is how it all got started. At my public sector job, I joined up with a group that was looking to enter the Games to Generate Data Challenge as a team, but alas, government red tape (and lawyers) prevented this from happening. However, since I was a contractor, I was able to take an idea of my own into the challenge and see how far it would get. It ended up being a good enough idea to place in the Top 5, so from there I developed the game on my own.

Fantasy Healthcare is written in HTML5, Canvas, CSS3, Javascript, jQuery, jQuery Mobile, PHP, and MySQL. The back end stuff runs on a Linux server. The Canvas stuff is also cross-compiled to native iOS and Android platforms for the efficiency and fast performance you expect from a game. I did it all myself, so considering I competed with some large teams and some big industry players, I guess I did pretty well for 3rd place.

So besides winning some nice prizes, I also got a trip to Boston to attend Games for Health, and a trip to the Health 2.0 Conference in San Jose to see the winner announcements. First off, Ben Sawyer’s Games for Health project in Boston was a wonderful experience, and I wish I were able to go again. There are really some amazing interactive ideas out there ready to transform the industry. As far as Health 2.0, I also had a great time hanging out in the Valley, drinking local brews and eating some In-N-Out Burger. The 1st and 2nd Place winners were totally deserving of their prizes, each having some fun-looking and interesting games, and I sincerely wish them all the best with their endeavors.

While I was in San Jose I got caught up in the government shutdown, but that’s a story for another time.

The Robert Wood Johnson Foundation and Health 2.0 are doing some wonderful things right now to provoke and promote bleeding edge ideas in the healthcare industry, so be sure to visit their challenge site.

What’s next for Fantasy Healthcare? I’d like to publish the apps and expand it to more cities. This will take some time I don’t have at the moment, though. In the meantime, it is available here for anyone to play with.

The New Way to do Event Bubbling

All Javascript developers should be familiar with event bubbling. For those of you who don’t know, event bubbling is when DOM events move up the chain from bottom to top. In other words, if you click on a <li>, the <body> will get clicked first, then the <ul>, then the <li>. In IE, of course, it does the exact opposite (“event capturing”), but with the advent of jQuery, this is pretty much a moot point.

So why is it important to know? Well, imagine you’ve attached a click event to an <li>. It may not be a problem now, but if your <ul> ends up with thousands of <li>s, you’ve got thousands of bindings in the DOM, which is going to be a performance killer among other things. Instead, simply attach the click event to the <ul>, then inside the event, figure out what <li> got clicked on and react accordingly.

By the way, this is an interview question for every Javascript-related job ever. Know what it is and why it’s important.

I was going to post a simple example on how to do this, but apparently this is entirely the point of jQuery’s new “on” method. I use “on” all the time, and you should too, and if you are still using “delegate” or the dreaded “live” to bind events dynamically, you should start using “on” instead. So anyway, here is how to use “on” to efficiently bubble events:

$('ul').on('click','li', function(evt){
alert("cream cheese");
});

What this code is doing is binding to the <ul>, but only firing the callback if a child <li> node was targeted. I’ve always used $(document).on as a force of habit, but really you should be using the parent of the object you want to bind to. Folks, it doesn’t get any simpler than this. Sure wish I understood this months ago….

Project Workflow for Lone Developers

I’m not ashamed to admit I’m a designer-developer hybrid. I worked as a graphic and web designer for several years. I did back end development professionally for 4 years. I’ve done UX development professionally for 3 years. I love design and I love coding, and I love doing both at the same time. So it’s not uncommon for me to build entire web applications by myself. This practice gets a bad rap because developers are typically awful designers, and vice-versa, but for me it comes naturally.

I’ve been designing since age 6 and programming since age 11, and never quite knew how I could merge those talents. Since kindergarten, everyone always told me I would grow up to be an artist, but I wanted to be a programmer. Once the time came when I needed to choose a major, I chickened out at the last minute and chose multimedia (I hated math and still do). Back in 2001, CD-ROMs and VB were king, and Director and Flash were still in their heyday. That was how you built interactive applications. But slowly, web and mobile took over this space, and bridged the gap between design and development. I was lucky to be caught in the middle of that merge.

Throughout the years, I’ve typically been unmanaged throughout the web development process, since the stuff I do is usually highly experimental. Because of this, I’ve developed and refined my own process for development that seems to work great for me. Your mileage may vary, but I’ve found this workflow to be the winning combination, especially for projects where I’m going it solo.

Lone Developer Workflow

  1. “Liveframing”, what I call wireframing with HTML. Create a preliminary GUI with no design, just basic structure. I prefer this to wireframing in most cases… honestly, I’ve never been a fan of wireframing tools, and I avoid them whenever possible. It depends on the project though.
  2. Mockup. Based on your liveframe, use Photoshop to design what the final website will look like. You want to throw a bone to the client to keep them busy awhile, but you also want to put a vision in your head of what you’re working towards.
  3. Database schema. This is the third thing I usually do, for two reasons. One, after building the GUI I have a pretty good idea of what data I’m collecting and how it will be used, and second, I want to do this before starting on the back end. I usually use Excel or pen and paper to draft a schema, and then build the actual tables as I need them. The schema will always change from start to finish, but usually I nail it with 90% accuracy. And usually, I end up needing fewer tables than I had originally schemed.
  4. Back end development. Once I have a barebones liveframe and a schema, I’m ready to start back end development. Of course I start in the planning stages, figuring out which pages do what, how the API will work, .htaccess considerations, etc. and generally decide how communications will be coded. Communication formats will also be decided in this stage (XML vs JSON, data structure, REST considerations, etc.). Then, I start coding, and hook the liveframe up to the code as I go for testing purposes.
  5. UX development. I start elaborating on the liveframe by adding the necessary Javascript and jQuery.
  6. Test, test, test. As I move through my prototype on the front and back, I add or modify decisions for both sides. The pieces slowly come together. The client should be engaged during this time to verify the project is functioning under the proper requirements.
  7. Once the project is 90% solid, then I start slicing the front end. The liveframe’s header, footer, and CSS will be replaced with the new design, and if you did it right, it should pop right in.
  8. Beta and QA testing. This is probably something you don’t want to do yourself. Find friends willing to test it out.

Behold, and Impart My Learned Wisdom Unto Others

Bartek’s Law of Coworking
Nothing says the digital era like piling people into a downtown office building with tons of talent and zero ideas.

Bartek’s Law of Private Sector Employment
Make the boss love you. Make management respect you. Make HR fear you.

Bartek’s Law of Project Management
“Man, it’s really hard to find developers. Let’s add more esoteric technologies to the stack and hopefully that’ll make hiring easier.”

Bartek’s Law of User Experience
“The client called. They’re worried that by simplifying the design, you’re confusing the user.”

Bartek’s Law of Software Engineering
The only career path where more money gets you fewer of the opposite sex.

Bartek’s Law of Google Image Search
No matter what the search term, you will always end up with furries in the results. Once you see the first one, you’ve reached the end of relevance.

Bartek’s Law of Design
Apple sets all trends, because that’s what your boss and clients want. If that means ushering in the return of early ’90s hypercolor, then so be it.

Bartek’s Law of Web Design
Take any random picture, blow it up and add 1000% gaussian blur. Add some aquamarine and coral buttons. Congratulations, you made a website.

Bartek’s Law of IT Jobs
Everbank has had those jobs posted for 4 years now. Ignore those, they have no clue who they want to hire.

Bartek’s Law of Front End Job Hunting
The search term you’re looking for is not “frontend”; it’s not “front-end” either. The standard search term is “ninja“.

Bartek’s Law of Modern Web Development
Yo dawg, I heard you like having to learn 5 languages. So we put languages on top of those languages.

Bartek’s Law of IT Careers
You can live where there are awesome jobs. You can live where life is relaxed and easy. But you can’t live in both at the same time.

Bartek’s Law of Search
If you’re searching the web and can’t figure out why Google is giving you unusually awful results… you’re accidentally using Bing again.

Bartek’s Law of Photoshop
“Client: My 11 year-old nephew knows Photoshop. I’ll have him design the website to save money.”

Bartek’s Law of Art School
Congratulations, you graduated. Hang that piece of paper on the wall and commence to starving.

Every year, it goes something like this…

CEO: I just read in Forbes that…

2013: …all websites should be written in Scala. Let’s rewrite our Java to Scala, by next week.
2012: …relational databases are dead. Let’s migrate 30 years of data to MongoDB, they’ll be around forever.
2011: …all websites should use responsive design. Make it pop.
2010: …all websites use Ruby now. Let’s hire Rails experts; there should be tons of them, and willing to work cheap.
2009: …millennials only buy through social media. Let’s make a Tweeter, whatever that is.
2008: …SEO is the future. Let’s buy tons of backlinks, spam up blogs, and set up microsites. No way this plan will fail.
2007: …all websites should be web 2.0. Let’s market ours as web 3.0!!
2006: …all websites should use Flex. Let’s rewrite our entire website in Flex, but don’t use any Flash.
2005: …all websites should have a blog. What, you mean we have to pay someone to write articles for it?
2004: …all websites need an RSS feed. Content? What’s that?
2003: …IE won the browser wars, and no other browser will ever compete. Let’s only write for IE now.
2002: …ASP.NET is going to revolutionize the industry. This is how all web applications should be developed.
2001: …we need a Flash landing page to sell customers on our branding. Make it so.
2000: …e-commerce is the future. Let’s sell pet food online and advertise at the Super Bowl, this is going to be HUGE.

Let’s Talk about Pre-Processors Like it’s 2010

Reading some of my past entries, you’d think I hate pre-processors or something. Well, that’s not quite right. Setting aside the obvious (PHP, etc.), I want to have a quick discussion on the pre-processors that have been popular over the last few years, and my take on them.

SASS & LESS
Great ideas, but pretty much the same thing. They don’t offer any real benefit over old-school CSS for small projects, but they’re certainly useful for the larger ones. But you know what’s better? Stylus. Stylus seems to take the whole idea a step further with the whitespace syntax.

CoffeeScript
Mixed feelings. I used it on a project recently, and while I love how easy it makes OOP and the syntax is lovely compared to the mess that is Javascript, it seemed to have a few frustrating quirks, and whitespace syntax is not always your friend. But then again, it beats getting lost in the “});});” forest. Debugging can quickly become frustrating as well.

HAML
I won’t lie, I can’t stand HAML. I want to like it, but the fact is HTML, like XML, is incredibly well suited for, well, markup. Here is an example of the number one reason HAML drives me nuts:

HTML
<span class="test">this</span> <strong>is <a href="test/" target="_blank">a</a></strong> <em>test</em>

HAML
%span.test this
%strong
  is
  %a{:href => "test/", :target => "_blank"} a
%em test

…so what happened here? Well, I traded a simple, common line of text for a mess of carriage returns, indents, hashrockets, and… colons? why?… and at the same time made it more difficult to read. I saved 20 characters, but at the expense of readability, and I made my brain hurt. HTML. Isn’t. A. Programming. Language. The verbosity of XML serves its purpose, like it or not. Although like everyone else these days I use JSON over XML most of the time, when you are dealing with lots of inline data, it makes more sense to use XML instead. Repetition and verbosity != not readable. This just doesn’t seem like the solution to any kind of problem HTML might have had. A better solution? Stick with HTML, and for templating, use mustache.js (the only Javascript-based templating engine that doesn’t suck, in my opinion).

Oh, and if I ever said anything mean about Node.js, I take it back. Without that, none of this would be possible. 🙂