Developing Upwards

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 y

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

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

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 "Hi