Cross posted on Medium
One of our NodeJS apps, written in TypeScript, started to chew up memory in production. The first solution was to toss some more memory at it of course, but that’s only gonna work for so long.
One of my reports is relatively new to leading a team of engineers. They are beyond competent and are really excelling, but as time marches on the impact and scope of their product has grown considerably. As more things need to be done, they are starting to feel the burn of requests piling up. He asked me “How do you manage all the incoming requests?” and honestly I didn’t have an answer on the spot. I spent the past few weeks thinking about it and came up with the list below.
Communicating clearly is a learned skilled in my opinion. I say this because I am still learning it and failing most days! I’ve been challenging myself to speak more clearly regarding task quantificiation - i.e. how complex is an ask.
Whatever your reason for migration from Flow to Typescript, it’s not easy - especially for a mature codebase with active contributors. Speaking from experience, this will cause headaches for you and your team. Personally I took 2 different approaches, the latter being successful (mostly). My first approach was to have Flow and Typescript coexist in a 1,000 file project, but this really doesn’t work for two big reasons
Three things so similar it’s hard to keep them apart. Been thinking how I’m not as familiar with
bind as I should be, so diving in and realized I should extend it to
Upgrading to Webpack 4 can be accomplished with a few steps. Some of these steps are more difficult and harder to understand than others. Below are some of the solutions I’ve used to migrate Webpack configs in the past.
With some configurability, Docker is a great choice to test chef recipes in a cookbook. While there are a few small gotchas, I’ve marked my journey below. I configured this to work successfully on a set of existing cookbooks I inherited and the production instance they run on. Most of the following info involves spinning up a new cookbook and a boilerplate recipe, but the content I pulled directly from my solutions. Feel free to reach out to me on twitter about questions, corrections, or comments.
Since the current application I help build runs about >1200 (and growing) Jasmine unit-tests, I figured migrating to Jest would be a pretty painless process. Snapshot testing was (and very much still is) a missing part of testing stack and was the catalyst for this migration. While creating simple snapshots was super easy and I’m excited to snapshot everything more, what I uncovered about our Jasmine setup was the more interesting issue.
My team’s unofficial team motto is “let reuse drive” - meaning let the need for abstraction come as needed. This motto isn’t a law, especially when architecting a whole system, but a principle when developing business logic and front end components. Below is an example of an abstracted component.
There’s not a lot of documentation for using Mocha, Chai, and Sinon to test prototyping. I spent a good chunk of time debugging the function and trying to code around the issue, but I eventually came to the same conclusion that I needed to test it as is. Creating a prototype to use inside of the function was necessary for how the rest of the application and since I had put off writing unit tests for this block of code, I had to use the tools I had already invested in – Mocha, Chai, and Sinon ( for stubbing ). I looked at a few other tools similar to SinonJS like JackJS but a lack of documentation and current bugs in the code made that un-useable (as of Sept, 01, 2015).
Adding a meta box to your WordPress admin for use in a BackboneJS application is very simple. With a single call you can create the UI for the meta box. ``` <?php //define namespace namespace Test\Test;