Category Archives: Development

Cache Rules Everything Around Me

By Chris Bartek

Are you getting a “merge conflict marker encountered” error when compiling a Node app? I ran into this issue for the first time recently, which was confusing as I had definitely fixed all previous merge conflicts, and could verify this by searching the codebase for “<<<<“, “>>>>“, “====” etc. and there were none to be found.

How is it encountering something that doesn’t exist, you ask? Beats me as to why, but when ghosts end up in the code I usually suspect the cache first.

So after trying several methods to clear out the issue, the one that seemed to work best was the following:

rm -Rf node_modules/.cache
(then yarn, then yarn start)

App booted up perfectly. Hope this helps somebody out there. I usually don’t come across caching issues in React apps but they sure are weird when they happen.

Leave a reply

Attention Web Designers

By Chris Bartek

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.

Leave a reply

Wi-Fi Thermostats are Awesome

By Chris Bartek

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. 🙂

Leave a reply

#OneSpark #EdSpark #YearOfAwesome #lolhashtags

By Chris Bartek

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.

Leave a reply

Moon Boogie

By Chris Bartek

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.

Leave a reply

Fantasy Healthcare

By Chris Bartek

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.

Leave a reply

The New Way to do Event Bubbling

By Chris Bartek

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….

Leave a reply

Project Workflow for Lone Developers

By Chris Bartek

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.
Leave a reply

Behold, and Impart My Learned Wisdom Unto Others

By Chris Bartek

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.

Leave a reply

Every year, it goes something like this…

By Chris Bartek

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.

Leave a reply