When hiring or speaking about our colleagues, we should strive to avoid calling someone “junior.” We should, instead, call them “less experienced.”
When you join large projects and fix bugs or build features, you typically rely on senior (in terms of time at the company) engineers to say “don’t forget to test feature X (that you probably didn’t know existed).”
Being new, you have limited knowledge of the entire architecture. Our tools should help fill this gap in knowledge. Our tools should help us traverse and understand large application architectures: the primary reason why I built and continue to work on the Sublime Dependents plugin.
I recently implemented a new feature that allows you to better understand which features or pages would break with a change to a module by showing you which app entry points depend on that module. In this post, I’ll talk about some of the tools and performance considerations that went into building this feature.
I’ve been spending quite a bit of time working on Sublime Dependents: a free, Sublime Text 3 plugin that helps you navigate front-end codebases. The plugin was built for large, production codebases (originally built for use at Bēhance). As such, performance is a priority. In this post, I’ll talk about some performance optimizations (in the context of the plugin but applicable to other node-based, static-analysis tools); expanding on my original post on the tool.
I was in London in October speaking at the FullStack conference. I gave a talk on using static analysis to give build tools like Grunt, Gulp, and Broccoli the ability to figure out how to generate their own configuration files based on what we’re doing/using as we build front-end applications.
You can find the recording here: https://skillsmatter.com/skillscasts/5776-using-static-analysis-to-give-build-tools-a-brain
You may need to register for SkillsMatter to view the video. It’s free to create an account.
This talk was a more focused version of the talk that I gave in St. Louis earlier this year. Thanks to the SkillsMatter team and NearForm for putting on a great event with an impressive lineup.
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.