I recently contributed an article entitled A Facade for Tooling with NPM Scripts to the Bocoup blog. Package.json script aliases let your project take advantage of npm-based tooling without the need for globally-installed packages, and can provide a common interface for handling package or application build tasks independent from the technology underlying those tasks.
Package scripts expose important tasks in a consistent, discoverable way. Lowering the barrier to entry means faster ramp-up for new employees, easier contributor onboarding, and less delay if you revisit a codebase after leaving it for a long period of time. There’s no downside to adding package scripts—at worst they just alias through to other tools—and there’s a lot to be gained! (read more)
This technique’s been a big help to myself and my team, and I hope you’ll give the article a read and let me know your thoughts.
I had the pleasure of speaking in New York this month at EmpireJS, and the video of my talk has been uploaded I discuss why side projects are important to our learning & growth as developers, and offer some ways that we can integrate this type of exploration into our work so that our “side” projects needn’t be so peripheral to the rest of our jobs. It’s a topic I care about deeply, and I’m thrilled to have had the opportunity to share it with such a great audience—thank you to everybody at EmpireJS for the warm reception you gave me!
Slides from the talk are here. Press “s” to pop up the speaker notes view, if you’re interested in additional context!
→ See the talk description on the WordCamp Providence website!
I delivered a talk this morning at WordCamp Boston 2012 on how to find ways to fit web development tools into your workflow—you can find the slides online at http://talks.kadamwhite.com/wcbos12/.
The genesis of this talk was a conversation in which some friends expressed frustration at hearing about not being able to use “cool” front-end technologies with WordPress. It is true that WordPress and its LAMP stack are “old fashioned” compared to, say, a CouchApp, but for example you can make Node.js work for you by running your build process with something like Grunt.js even if you don’t incorporate Node into any part of your public-facing web stack. The best tools are flexible, and I use stylesheet pre-processors (with demos in LESS) to show how you can slot a tool into several different aspects of your workflow.
Tools that help us make website are invaluable for keeping up our speed and productivity as developers, and playing with the “latest and greatest” helps us stay excited about what we do and engaged with the community at large. We’ve gotten good at making advanced sites for our clients—we deserve to have some cool toys ourselves now and again.
For all who attended, I hope you found the talk useful! I have added two pages of links to unit testing and style guide resources at the end of the talk for those who wanted some further reading. For additional resources for workflow and developer tools—far, far more resources than you could shake a stick at—check out Aaron Jorbin’s slides from “Developing an Automated Workflow,” also presented today at WordCamp Boston 2012.
The msys shell that comes with a Windows install of Git has curl, which is an awesome little utility, but sometimes you want access to wget. The MinGW project on SourceForge has a build of wget ported to work with MinGW/MSys: download this archive, create a folder called
/bin in your home directory, and extract
wget.exe to that
/bin folder. Since
~/bin should be in your MSys PATH (at least it was for me), this should let you run
wget from any directory when using Git Bash.
Credit to trasana.org’s page on creating a build environment for pointing me in the right direction