Scott Radcliff

Do Nothing

I often think about doing something cool and talk myself out of it. Lately it's been some sort of screencast site where I teach some programming thing. Nothing big. Just small things. Maybe once a week. I would need a library of videos built up before. That's where I get derailed. All this thinking and planning. And then. I do nothing. Over and over again. I do nothing.

Adventures In Java Script

Today I started to take JavaScript back. I started taking a bunch of jQuery code and convert it to plain old JavaScript. I discovered a few things.

1) There are functions in the JavaScript API that I don’t remember before I started using jQuery. querySelector is pure awesomeness.

2) Client side code is fun again. I am not programming in a language anymore, but into a language. (if that doesn’t make sense to you, drop everything and read Code Complete). My thoughts and overall design are at a much higher level, and I am having a lot of fun discovering that the language already supports a lot of what I want to do.

Two links that have been huge helps to me are

MDN Web API Interfaces

MDN JavaScript Reference

Has Jquery Served Its Purpose

I used to be a jQuery hater. I’m sure that stuff is on the Internet somewhere. But when jQuery hit the scene, I was convinced that it didn’t really serve a purpose. I could already write JavaScript. What did I need a library for? Then I started to see some usefulness in the library. Animations were kinda cool. And the Ajax stuff was really cool.

I started to convert. I started to see how this tool could actually help me. But it was a pretty long road. One that I fought pretty hard. But in the end. jQuery won me over.

Those days were a little different. Writing the same code for different browsers was very common. There was a lot you had to remember. Lots of little quirks and bugs in browsers. I’m not so sure that’s the case anymore. Browsers have gotten pretty standard.

jQuery as a Crutch

jQuery is a crutch now. It’s such a default in a web developer’s tool belt that they don’t ask if they need it. Until they start to ask if they need it.

What gets me is the API changes in jQuery. There are a lot of them. Functions get renamed all the time and old functions get deprecated and finally removed.

An Example

There used to be this real handy function for attaching an event to an element and have that event watch for new elements and automatically attach the event handler to those also. It was called live and it was one of my favorite features of jQuery.

If you look at that function now, you will see that it has changed twice. I’m not even sure if they functionality has changed, but the name has changed.

As of jQuery 1.7, the .live() method is deprecated. Use .on() to attach event handlers. Users of older versions of jQuery should use .delegate() in preference to .live().

So here we are. I can’t use live. I need to use on, unless I use an older version. Then I should use delegate.

This is just one example that frustrates me. I hit these deprecations all over the place.

I understand deprecations are common, but this is extreme.

Another example.

To access an element’s attributes, you could use attr. This still kinda works on some things. More often than not, I need to use prop in Firefox or it just fails silently. I don’t know why. They seem like they do the same thing.

Here is the same code in JavaScript: getAttribute. Why am I using an abstraction that seems to change? I can’t answer that. I don’t know.

I think it’s time to go back to vanilla JavaScript. Well, except for Ajax. That doesn’t seem to change much and is super helpful. But then again, the cool kids tell me there are libraries just for Ajax now.

Google Spotlight Stories Is Amazing

Every once in a while something comes along on mobile and I am just absolutely blown away. It's just one of those uses of tech that you start to wonder what's possible and where it could possibly end up.

Seriously. Stop what you are doing and go get Google Spotlight Stories. It's amazing!

The app puts you right in the center of a movie and physically move around to see what is happening.

The first thing I did was download the movie Help. It's a pretty large file and takes a while. But once you watch it, you'll know why.

It's a completely immersive watching experience. I was literally spinning in my chair trying to look at everything.

The coolest part is you will hear or see things happening behind you and try to turn around to see what is happening.

This app is seriously cool.

Saving The Web

I just read a superb article on Medium. That's quite ironic after you read the piece.

In it, Hossein Derakhshan talks about the web we lost. Which seems to pop up every couple of months. I have to admit I'm intrigued every time I see one of these. They all make great points. We did lose something when we all got social.

Hossein is right. I used to start my day in an RSS reader checking up on what was happening. I now start on Twitter or Facebook. I'm kinda ashamed about that. I do love the open web and wonder if we are on the cusp of some sort of, err I don't know, revolution. One where those that are capable give those that are incapable the ability to host stuff on the internet free from censorship or any sort of silo.

I don't know what this might look like. Certainly not web rings. Please. Do not start web rings again.

I imagine some sort of RSS or JSON would be involved and give people a way to share information without limitations.

Certainly something to think about if you are technical enough to run servers and build software to empower people.

Web Versus Native

Somewhere along the way, we lost our way. We went from using the web at what it’s ideal for, linking documents together, to trying to make it do something it’s not good at. Making desktop-like applications. Or maybe we could call them native-type applications, since what we are really doing is trying to mimic mobile devices.

I think I know what this stems from. I think it’s just a fact that mobile is taking over at an rapid pace. You either have to get on board or get out of the way. Clearly no one wants to get out of the way, making software is fun.

But what if, like me, you don’t really have much, if any, experience making installable software? It’s not like web development. It’s a completely different animal. What do you do if you can’t get on board because you don’t want to make native software?


You bring it to where you are comfortable. The web.

Seems like a good idea. Use JavaScript to make smooth animations instead of page loads. The user will never know. They will think it’s like an iPhone app. But they will know. They will know they are on a website. They will know because, more than likely, they use the web everyday. And they know it’s not an iPhone app. And they are okay with that. They know pages load, links to go other pages, and they expect URLs to work.

What we’ve done is make it convenient for us. Sure we tell the customer/user that we have done this for them. Look at how fast the transitions are! They don’t care. Look at how only part of the page gets updated! They don’t care. Look at how the URL changes but the page doesn’t. Again. They don’t care.

If an effort to side step making a truly delightful web experience on the web. And a delightful native experience on a device. We have introduced a level of complexity that we think makes it awesome, when in reality, it causes more issues than it solves. Some may argue there wasn’t a problem to begin with.

How do fix this?

Let’s call it SRP. Use the web for the web and use native for native. Understand that native apps are generally faster. They are closer to the metal. Web apps will always have a browser between the user and the computer.

Working With Git Stash

Have you ever been working on something and you’re not quite in a good spot to commit? You know, a good commit. The kind with meaningful commit messages that describe what you’re committing and why.

You don’t really want to commit because you have some garbage changes that you would like to go back and fix, but you haven’t gotten around to it. You’re still developing.

Then something comes up and you need to jump on another branch and fix something really quick. Call it a hot fix.

Now you’re stuck. You might just grumble a little bit, add what you have, and commit with a vague and often unhelpful commit message. I’ve done this a lot. Too often.

This is what git stash was designed for. With stash you take everything you have, store it somewhere so it doesn’t mess you’re working tree, and come back to it later.

Here’s how it works.

Just running git stash without any arguments saves the changes and applies a WIP message. For example, if you were working on a dev branch, change a couple of files, and then you needed to jump back on master and typed git stash. It would stash the changes for you. Running git stash list would show your lone stash with a WIP message.

    stash@{0}: WIP on dev: 3bff306 Initial message

The initial message text is my last commit message. This is where the branch was reverted to after saving my changes.

Once you’re done doing what you needed to do and jump back on your dev branch, you can simply run git stash apply and have your changes reapplied to the dev branch. It’s worth noting that apply leaves the stashed changes in your stash list. That may not be what you expect. If you want to apply your changes and remove the changes from the stash list, run git stash pop. This will apply that last change and remove those changes from the stash list.

Now you should see something like this

    On branch dev
    Changes not staged for commit:
    (use “git add <file>…” to update what will be committed)
    (use “git checkout — <file>…” to discard changes in working directory)

        modified:   sample.txt
        modified:   sample2.txt

    no changes added to commit (use “git add” and/or “git commit -a”)
    Dropped refs/stash@{0}          (4974d43e224dd25ab4c75c0b1e583e0748d7d200)

That’s great and all, but maybe you want to leave yourself a message. Maybe it’s going to be a while before you come back. For that case you can use git stash save with a message.

If you run git stash save “Another emergency needs my attention”, you should see something like this.

    Saved working directory and index state On dev: Another emergency needs my attention
    HEAD is now at 3bff306 Initial message

And git stash list should show something like this.

    stash@{0}: On dev: Another emergency needs my attention

This has been a huge help for those situations where I need to jump to another branch when I’m in the middle of something. Hopefully, it will help you too.

How To Run Sinatra And Compile Sass Files At The Same Time

I love me some Sinatra. More often than not, I reach for Sinatra when starting a new app. It’s not that I don’t like Rails. I just prefer the control and simplicity of Sinatra.

Naturally when using something like Sinatra, you lose certain things like the auto reloading of files and niceties like compiling Sass for you.

There are tools for these. Shotgun allows Sinatra apps to be reloaded when files change. You do still have to manually refresh the browser, but you no longer need to restart the server.

And of course, Sass comes with a CLI for compiling sass files into css files. It’s pretty straight forward. Pass it some sass files and some css files, and it will compile them for you. I generally pass it entire directories. Something like this

sass —watch sass:css

That will grab all my sass files, compile them, and place them in the css directory.

I also need my server running. Shotgun handles this. This particular Sinatra app isn’t modularized yet, so I just pass it the entry point. For me that’s almost always app.rb

shotgun app.rb

You can probably see my issue already. I need two terminal instances for this. Or I can combine them.

Here is where you might want to grab the && operator, but that would be a mistake. The && operator will wait for the first task to complete and since both tasks watch, the second task will never fire because the first won’t complete until you kill it.

What you need here is the & operator. This will run a task in the background. When your terminal reaches this operator, it will detach that tasks from stdin and allow other tasks to be run simultaneously.

Now you have something like this

shotgun app.rb & sass —watch sass:css

You can run that in one terminal tab and see both processes at the same time.

To make it even nicer, you can throw it in a Rakefile so it’s easy to remember.

task default: "start"

desc 'Run the server and watch sass files'
task :start do
  system "shotgun app.rb & sass —watch sass:css"

Because we have defined a default task, we can run this one of two ways.


    rake start

One less thing you need to think about.

Doing Your Best Work

I’ve been thinking a lot about doing my best work. I ask myself questions like If I didn’t get paid, would I still do what I do everyday and What would it feel like to be immensely proud of what I’ve done

This really has nothing to do with employers, clients, or friends. Most of the time, what they hire/ask me to work on is important to them. But not necessarily the most important thing to me.

Recently, I was asked what the most important thing is to me regarding work. Without hesitation I stated that building software that changed someone’s life. Something that didn’t used to exist, but now does, serves a real purpose, and allows a person to do something that they couldn’t do before was the most important thing.

You can take everything else away. Money, pool tables, cool offices, work when I want, or anything else. Once you reach a certain point, none of those perks matter. And this is what money driven people don’t get. Not everyone cares about being rich. Some people just want to leave a legacy, a body of work that meant something. You can’t buy that.

So, I thought to myself. What are some good examples of this. This is by no means a complete list, but here are some examples of people changing lives through software.


Infiniteach was founded to change the way we approach autism education. We believe that every child with autism should have unlimited access to proven strategies that can increase their independence and help foster meaningful relationships.

Prana Diabetes

Prana Diabetes helps address the growth of diabetes in India.

Totus Power

Totes Power is using portable power from electric car batteries to provide battery packs for schools in developing countries.

Charity Water

Charity water gets clean, drinkable water to countries that don’t have it.

Kno Clothing

Kno Clothing is more than threads on your back. It’s about ending homelessness. Every time you make a purchase, we donate an article of clothing to those in need and fund organizations who help restore the lives of people experiencing homelessness in local communities.


Catchafire matches those with skills to non-profits or other organizations that need help but are light on funds.

The world needs more of these.

The Case For Isomorphic Javascript

If you know me at all. Even if you haven’t seen me rant on Twitter, you should know that I have this constant struggle with JavaScript. Not in the language itself, but more of an issue with what we, as developers, are doing with it.

Granted, JavaScript is just a programming language. As such, you can do programmery things with it.

My argument has always been Is this the right task for JavaScript?. One could say C++ is a great language, but you would be crazy to try and build a complete web application with it. That’s just not what it’s good at. It’s better at close to the metal stuff. Super fast code. And because of that, it’s more difficult to work with than a higher level scripting language.

Here is the part where I declare why JavaScript was invented so I can make the case that we are using it wrong. But while researching I learned something I didn’t expect.

First, JavaScript was invented for nonprofessional programmers. That sounds harsh, and I imagine this makes a lot of JavaScript developers angry. It could be reworded as “JavaScript was invented to target non-java and non-c++ developers.” It was invented to give more developers access to a programming environment that they could work in and possible build more awesome stuff.

I didn’t expect that.

I expected to learn that JavaScript was developed just for web page scripting. That doesn’t appear to be true. I stand corrected.

Here’s the real kicker. Server side JavaScript was actually introduced in 1994 in a Netscape product called Datacraft.

Those involved in the early days of JavaScript were already planning for it to run on the server. They were planning on using JavaScript as a complete programming environment. Client and server.

The Extracted API Fallacy

The idea of extracting client side code from server side code sounds perfect. Take all of your JavaScript front end stuff and have one app for it. It will handle displaying data, state changes, fancy interactions, and package management. Then take all of your server side logic, create an API, and feed that to your client side app.


We now have a client side app for rich interactions, and we have an API that can feed anything; iOS, Web, Android, etc… What’s not to like?

This is great in theory, but in practice it starts to fall apart a bit. The first sign is that you still need a front end web server. Well, if you have any sort of progressive modern app you’ll need a web server. At a minimum, you will need a way to compile and serve all of your assets.

You’ll also need a lot of libraries and packages. And of course, if you use cool stuff like requiring modules as needed, you need a build process. That’s more dependencies.

All of this before you get to the server side.

The additional complexity is not worth it. This is why so many companies go heavy client side and then go back to the server side. I think if they would have went all in, they would have had a different experience. But that is hard for larger code bases. They definitely felt the pain.

We should be moving to easier, not more difficult.

Decreasing Complexity with an Isomorphic Approach

I still remember the first time I used Rails. I knew it was a game changer and it was how I wanted to build applications. I haven’t seen that with JavaScript yet. Actually, it’s been the opposite. Instead of thinking This is awesome! I want to build all applications like this., I think OMG this is awful! Why is this so complex?

Netscape had the right idea in ’94. If you are developing JavaScript apps, develop JavaScript apps. I think about the client side applications I have worked on. It would have been easier to add a node server and a data store than it was to maintain two completely different applications.

I’ve been researching and playing around with isomorphic application development. I really think this is the next logical step for the web.

I’d like to report back with more data once I have a few of these under my belt, but I really encourage you to take a look at isomorphic development. Especially if you’ve felt the extracted API pain.