Developing Upwards

For the first time in a long time I wanted to write a brand new little app, from scratch, just for fun. I was feeling the Joy of Coding coming back after a long hiatus. So, yay for me? Yay for me. The idea for a single-case app for the kinds of repeating chores of the day has been knocking around in my head, so I whipped out npx create-react-app and tinkered on my laptop while watching TV. In about an hour and a half I made Cheqee , the Simple app for the things you do every day. I was thrilled to be reminded of how quickly an entirely new application can be built from scratch and published as a PWA (Progressive Web App) and "installed" on any phone and used like any app by anyone around the world, so here's the things I accomplished in just a couple hours total and in this post all the pieces that went into making that happen so effortlessly: Wrote a brand new app that does a simple job, built quickly but easy to expand and improve Incorporated persistent da...

I had an adventure over the last couple days with ES6! There was a pattern I'd already used in a few of my React projects to make ES6 classes a little nicer. ES6 did a lot to make working with  this  mechanics nicer, but there was a still a gap that bit me: the sugar provided by ES6 classes don't extend to keeping method bound to instances of the class. Maybe you, like me, would expect this to work: class Counter { constructor () { this . count = 0 } onClick () { this . count += 1 } } counter = new Counter () document . querySelector ( '#add-button' ). onclick = counter . onClick But, like non-class methods on any regular Javascript object,  onClick  will loose its binding to the  Counter  instance. There are a few existing solutions to this, but I wanted one that didn't change the syntax of defining a method on these classes. Enter AutoBind, via my new NPM module  es6-class-auto-bind : import Aut...

I’m really excited about ReactJS. I’ve let my tentative excitement grow for a while now, with a few experiments and tutorials and lots of reading. There is a strong habit of Shiny New Thing syndrome in the web world, and I’m as guilty of it as anyone else, so a lot of effort was made to avoid jumping on the bandwagon too soon. After building my first simple but complete application with ReactJS (and Flux) I’m absolutely convinced it is the best option for me to build web interfaces going forward. To share my excitement and to preserve my thinking, in case I come back in a couple years wondering how I got started with ReactJS, I’m going to outline all the reasons I’m so excited about ReactJS. ReactJS is Fast in Every Way That Matters Saying a software library is “fast” is often a red flag for not having a holistic view of the trade offs. Faster than what? Fast by what measurements and under which conditions? I can say that ReactJS is fast because I’m not saying one vague thing, but sayi...

Hashtrack.js 0.2 includes a number of bug fixes and enhancements, and I'd like to start doing official releases that really show off what the tool is capable of. I've been using this for a few years in projects both personal and professional, and I always merge improvements back into it. Hopefully, I can start making an effort to polish it up better, because in this day and age we all are finding ourselves in need of stateful web applications, and we need to handle this gracefully. Take a look at the github repo for hashtrack if you like the sample code below, or take a look at the very sparse but informative docs . hashtrack.onhashvarchange("background", function (value) { $('body').css('background', value); }, true); ----- <a href="#?background=green">Make the background green</a>

Something I read today in a Javascript forum gave me pause to think about broader attitudes in developer tools and libraries. I love jQuery, but if this is all you want to do, jQuery is overkill.  Javascript libraries are great if you want to do a lot of things, or one really complicated thing, but if you're just doing something small and simple, just write the javascript code. arandomgeek I respectfully disagree. Of course, people say this about a lot of other libraries and I defend against this stance in, more or less, all of these cases. I have heard it about Python and things in the standard library, about jQuery, about Django and Twisted, and about any language that isn't C. The common thread here is someone feeling that, as they are not using every or many parts of a tool, they should not use it for the one or two things it could be useful for. These people suffer from the Fear of Overkill. I can summarize the argument against this very simply. It would ...

I spent my Sunday afternoon familiarizing myself with a tool who's Getting Started page has been sitting in my Evernote tickle file for a couple weeks. This is one of those many projects that fall under the ever widening category of "Stuff I Wanted To Do, But Am Glad Someone Else Did It So I Can Just Use It And Get On To The Next Thing." If you use virtual machines as part of your development process, or want to, and especially if you already use the excellent VirtualBoxVirtualBox , then Vagrant  is certainly worth looking at. The Setup (for Vagrant 0.2) Now, the docs might need some updating and they seem to assume you're already a Ruby user, so they're missing a few dependancies that such a person would just happen to alread have. This is what I did, as an Ubuntu user who didn't even have Ruby installed. I'm also adding Virtualbox's Karmic repository to provide VBox 3.1, which Vagrant requires. sudo apt-get install rubygems libxslt-dev openssl-...

I got acquainted with developing against the Google Wave Preview last week, and I'll be doing more of it this week. There are still many gaps in the documentation and in the public understanding of what exactly is going on in a lot of cases. This post is halfway between an introduction to Wave development and a story of my personal hurdles in my first experiments working with it. One of the first things you'll find in the Wave documentation is a diagram I have reproduced here.  This diagram is wrong. You're going to notice something when you look at this diagram and play around with Wave itself, the web client. You're going to realize you have no idea what the difference between a Wave and a Wavelet is. You don't seem to be able to even see the term "Wavelet" appear  anywhere  in the application! What's more, everything the API docs describe a Wavelet as is what the UI seems to call a Wave. This was really confusing to me and I know I'm not the ...

I've been meaning to this for months, and I just kept putting it off. So many other things going on, so I didn't think I had the time. I decided to take a look this morning, finally, and put in the energy required to try this cool looking stuff out. Took me ten minutes. If you don't care about writing a Jetpack extension, but you have Jetpack installed , you might want to try out what I wrote. "Twitter, Who Am I?" is the name and making your currently-logged-in user at twitter.com obvious is the game. You'll get a nice label above all the pages, so you don't accidentally follow Ashton Kutcher with your business account. The tutorial is fantastic, so I'm not going to try and rewrite or replace it, but I do want to make some comments about the process of getting into this. Firstly, the tutorial on the website is the same as that in the about page, but crippled. Same text, no interactive features. The tutorial built into Jetpack lets you edit and try out...

The infamous Zune 30GB failures were traced to a leapyear issue, and apparently they use some code we can see in the Freescale codebase. Take a look at the following sample of code, which determines the year from the day number (counting from January 1, 1980). I don't know about you, but the infinite loop is immediately obvious.  On a leapyear, the main loop continues when days = 366  and the incrementing is never reached, because days > 366  fails. Am I naive to think that even a casual code review would have caught this in a moment? year = ORIGINYEAR; /* = 1980 */ while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } } else { days -= 365; year += 1; } } UPDATE: Fixed formatting issues. It looked fine when I posted it, honest!

We learn to recognize a bad bit of code quickly as our code-fu grows. Arbitrary side-effects smell badly and crazy one-liners frustrate us. It becomes easier to identify what lines of a codebase you might want to clean up to improve the overall quality of the work. There is a line between codebaess with bad code in them and bad codebases. When do we learn to recognize this and what are the signs that the problem is far reaching, not localized? A bad codebase is an expensive codebase. It is difficult to work with and difficult to collaborate with others on. Identifying what makes a codebase bad is key to knowing when, where, and why to improve it. Improving the overall code quality reduces the overall code cost. I'm thinking about software in economic terms these days, and I'm hoping we can turn the recession to our favor by pushing the mantra Bad Code is Expensive Code . Costs of code come from three actions. Adding features costs, fixing bugs costs, and understanding costs. Ad...

The development sub-blogosphere is abuzz with responses and responses to responses on the debate over splitting up developers into two camps . The core idea is that 20% of us care about software development and 80% of us just do our job and go home. We all like to think we're in the 20% and we probably are, because the 80% doesn't care enough to recognize the distinction. They might recognize those few geeks at the office who don't seem to have a life, of course. Is the debate centering around who is what group and what it means or that we are grouping so bluntly in the first place? Well, we are a binary loving people, after all. For the 20% This Means... We love to self comment. We're a relatively small slice of the populace spending an unusual amount of time talking about ourselves and this whole deal just exposes that. Who reads about the split between the developers that care and the developers that just pay the bills? Not the bill payers. Even if this all centers ...