There is beauty in the thoughts expressed in code; the search for the perfect idioms. A logical poetry.
There is beauty in the product: that which our code has created.
There is beauty in the usability of our code – its API: its language of interaction.
Think, for a moment, about your own code. We write so much of it. Where is the beauty within your career’s corpus?
Dollar-cost averaging (DCA) is a popular investing technique whereby you incrementally purchase more shares of the funds in your portfolio: in small amounts on a monthly or quarterly basis. The main idea is to not invest all of your money at once: avoiding big dips in the market right after your purchase. If you only invest a little at a time, you’ll buy more shares when the market is down and fewer shares when the market is up. Sounds like a no-brainer, right? Well, DCA really only makes sense in a few cases.
This post was featured in Node Weekly #43.
When you have a large JS codebase that uses the AMD module pattern, like we do at Bēhance, it becomes tedious to perform certain tasks within your editor. This hurts productivity and adds up to wasted developer time in the long term. Here are some of the problems and possible/existing solutions.
Personally, I’d prefer to have no configuration and no code. Ideally, tooling should help me avoid having to write that boilerplate. In this post, I’ll talk about the feasibility of automating front-end build processes and auto-generating Grunt tasks. The ideas are used in an experimental tool called YA that explores solving this problem.
I’m writing tests for a node.js tool that I’m working on and hit a snag in trying to mock (i.e., simulate) a dynamic npm install of a module within a subdirectory. I tried a bunch of ideas and ended up with a simple, perhaps not ideal, but effective solution.
Programmers, both new and experienced, have a hard time getting away from technical interviews: the “large-company” style of interview where you’re asked to work through an ambiguously-stated programming question with an interviewer who already knows a wide-range of solutions to the problem. There are pros and cons to this interview style; I personally don’t like it at all. However, preparing for technical interviews can teach you a a lot about yourself. I’d like to share my own findings, in case it helps a programmer with similar problems.
We use the internet every day to surf the web and send emails but it’s not obvious what’s going on behind the scenes. I’m teaching an online class aimed at demystifying the internet.
Feel free to register and/or share (http://bit.ly/1bPseUY) with anyone you know that might be interested. Thanks in advance and I hope to see you there!
Eureka! That’s the feeling I had when I finally saw how
Object.create could help me in achieving the inheritance-oriented behavior I was after. I’d been reading lots about prototypal inheritance in JS and understood bits and pieces, but it finally started to click recently. Here are some thoughts and (intentionally simplified) explanations that will hopefully help you toward that eureka moment.
When I started architecting the initial JS apps for YouNow, I sought to build structures that could be used both by our Backbone.js applications and one-off scripts/projects. These structures grew quite quickly over time; they became monolithic. In this article, I’ll examine the motivations, pros, and cons of a backend api service layer and suggest/brainstorm alternative implementations.
There is a clear behavioral difference between software developers and software engineers, though the terms are often, incorrectly interchanged. Through my own experience and observations, I hope to not only shed some light on the difference, but encourage developers (my target reader) to strive to become engineers. If you find this post helpful, feel free to tweet at me: @mrjoelkemp.