Monday, October 19, 2015

The Lure of the Dead Project

Dead projects can be a constant lure. When you put down a body of code work and call it either defunct or completed, its hard to avoid the feeling there is something more to do. Whether its work you’ve decided was complete, but later come back to in your mind with ideas of new features and improvements, or work you’ve walked away from intentionally or through neglect and feel a guilt to return to that you cannot shake, old projects have a way of pulling your attention back to them. This constant pull can be terrible for concentration and painful for motivation on new work when you feel this desire to sink your time into something you’ve already gotten away from. Maybe you stopped working on that project because there were simply more interesting things to do with your time, or it was moving in a direction that wasn’t as interesting for you. Maybe you just have too many projects going at once and needed to do the responsible thing as an adult and recognize when you and too much on your plate.

There are many reasons you might walk away from a project, and some times its healthy and helpful to identify that reason and be really clear with yourself when a project is truly finished, or just finished for you. It can be helpful to put an explicit “DONE” label on something, even if there are definitions by which it isn’t done, because you need to make yourself stick to those decisions about moving on to other projects.

I’ve tried to do better at this.

I’ve begun a series of posts where I do public post-mortem on my own projects, even if they are ones I hadn’t previously publicized. The goal here is two gold. First, I think its useful inside my own mind to really put together my thoughts at the end of a project and even long after and document what I learned from and through the project. But, secondly, that public announcement of not working on a project might be more valuable than the public declaration you make when you begin a project. I proclaim “I’m done with this. if you see me picking this up again, question my motives and question what I’m neglected to pick this back up."

Some times it just as simple as deleting a project from your machine, even if you keep a back up or a Github page for it. Make it harder to return to. If you really want to close that chapter in your life, maybe take the repository down if it isn’t maintained or if it never had other users anyway. In the most strict response to the urge to return you might find yourself deleting all traces of a project you once held dear.

A lot of these projects are done to scratch some personal itch, so get invested in an existing solution that scratches that same itch, even if it doesn’t quite get it. learn to appreciate tools for being just good enough. Get invested enough that you would be seriously determining to your workflow if you tried to leave that solution for your own half baked versions.

Fight the lure of the dead project, because you let it die for a reason.

Monday, October 12, 2015

The Practice of "Vanilla JS"

I try to keep my skills up and its hard to do when the thing you try to have skills in is always changing. The web landscape is always in flux, at a seemingly ever-increasing pace. Javascript represents only one area of the web, and as a language within a much greater ecosystem even that microcosm can keep you busy with the evolution of the language itself (ES6), constantly rolling out new in-browser APIs (like the new Web Cryptography API), and learning to sling this language both inside browsers and on backends (Node.js).

One of the best tools I have to keep these skills sharp is the practice of what you call “Vanilla Javascript”. I try hard to find lots of small opportunities to practice Javascript without the abstractions of all the myriad of libraries and frameworks that might obscure it even in the course of a single day’s work. I find two simple strategies help me poke through the cushion these tools provide to make sure I don’t forget what’s under the hood.

  • On a new project, especially a smaller one, I’ll build what I can using no JS libraries until the need really presents itself. Its wonderful how many tasks you’d turn to jQuery in the past for are just fine to approach using nothing but standard APIs today.
  • At any time, I try to have one toy project i might come back to when I have some time to kill, which I keep a “plain only” rule on. These are just private throwaway projects, but useful to give me a sandbox to avoid the pressures that usual projects bring to the table with a necessity of a toolchain’s safety net.

The effort is small, but the impact of keeping yourself reminded of the language and APIs underneath jQuery, Angular, React, or whatever other JS toolset you prefer is undoubtedly valuable. 

The next time you’ve got a new task JS to complete, give yourself a quick challenge in accomplishing it without a library. But, find a balance, and don’t force yourself to do what you really should use a library for. Just give yourself that chance, now and then, to discover some new Vanilla JS you may have not known before or to revive some understand which had gotten rusty.

Sunday, October 11, 2015

Giving it a REST

I don’t remember deciding that I was a fan of REST APIs, but I found myself in that position for a lot of years. I was really only getting to the point as a developer that I was even thinking about APIs around the time when REST was already on the scene, and especially was getting more popular among the Python community and among the Web developer communities, the two places I drew most of my social influence from in the are of programming.

SOAP was not a disaster that I had really much experience in, save for a couple very brief encounters. One of my first small programming contracts was actually wrapping a SOAP service into a RESTful endpoint. The main business model of my client was reselling another service because developers would prefer to use this improved API that much more that the small premium would be worth it. I was young and impressionable and looking back, I don’t know if the SOAP API I had to work with directly for this job was actually as bad as it was made out to be or if it was me picking up the tone of the job. And, I think, interacting with SOAP services probably is different in different languages, and maybe doing it in Python from scratch and entirely by hand was definitely more painful than some more strict languages with heavier SOAP tooling in their ecosystems.

So these ideas I’ve held for so long about how great REST is and how awful SOAP was are not ideas I can really trace back to experience or education. They’re things that I largely picked up socially. SOAP was always the poster child for the wider idea of RPC (Remote Procedure Call) APIs, but the negative tone was definitely equally applied to any similar system (which was almost always XML based, of course).

A tale I’ve heard about an experiment involving social pressure and monkeys goes like this. The scientists had a cage with a bunch of monkeys and they had a ladder in the center that let them to some treat up at the top. Immediately the monkeys tried to get there, but when they would try someone would spray them with a hose and get them off the ladder and repeat this until none of the monkeys would even try. When all of the monkeys had learned this lesson, they removed one monkey and replaced him with a new monkey, who didn’t know about the ladder and tried to get the treat. The hose was used again, and all the monkeys were punished. The monkeys were replaced like this, one by one, until they learned to self police and stop any new monkey from trying to climb the ladder. The hose wasn’t even needed. Eventually, none of the monkeys in the cage had ever even seen the hose, but they all knew what to do when someone climbed the ladder.

Some times I feel like we’re all the monkeys and RPC is that treat at the top of the ladder. And maybe, in this scenario, SOAP is the actually ladder? The point is, I feel like we all avoid this thing we don’t really understand and we do so based on the experience of others we’ve gleaned from, about something we don’t actually understand beyond the surface fear of.

At this point I feel like I don’t know what I missed or left behind, and I’m not just abandoning REST (nor could I, as it is inescapable in the current landscape) but I want to recognize that learning more about alternatives is something I’d like to do. I know SOAP enough to know I don’t want to get to know it better, but I also feel like tooling is a missing piece here. I want to understand, with the right tooling in place, how much less might I care about the protocol being used and what else might I value in that protocol?

Sunday, October 04, 2015

Chrome and Session Restore

The Chrome Development team is talking about how much faster Chrome is at loading your tabs when you restore from a previous session. This is a totally welcome improvement, especially compared to Firefox's long superior handling of session restore by on-demand loading tabs only when you switch to them. Chrome, by contrast, has already penalized you for every extra tab you had to restore by loading them all at once and immediately.

But, something is missing from these announcements about improving the speed. On the forthy-fifth release of the Chrome browser, I would have expected and been happier with finally improving the plain experience of restoring a previous session in the first place.

Chrome doesn't even prompt you to restore your tabs or even tell you there is a session that could be restored, if you don't explicitly go looking for it.

Hidden behind the main menu button that many users don't even recognize and know is a menu, and then within the "History and Recent Tabs" you actually get the option to restore a previous session. Many users I've asked (anecdote, I know) don't even know this feature exists, and have just been assuming Chrome forgets all their tabs on close or crash.

When you do know about and use the feature, it leaves a dead empty window because it opens the previous session in a second window, and if you have pinned tabs it creates duplicates of them every time. This has felt less like weird behavior and more like buggy software for years now.

So, they make opening that old session faster? That's great, but maybe making it actually work first would be a better priority.
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive