It is with an extremely heavy heart that I bid farewell to my employer of the past 4+ years, Netbiscuits. I started, fresh off the plane from `murica, as a fresh-faced 40-something-year-old, learning new proprietary code bases, new technologies, and new names, faces and cultures (though, stupidly, not the new national language…).
After a couple of company make-overs and re-focusings, I leave having worked on several challenging and at-times fascinating products, and most recently having led a small team to try to reinvent a solid product, Netbiscuits Device Detection, in order to make it easier for companies and developers to build the perfect user experience for every user, on any device.
I will certainly miss the staff more than anything. A fantastic group of human beings. I wish them all, and the company, the best of luck, and will continue to help them in any way I possibly can.
Yet it is with an equally exhilarated heart that I announce my new position, as the Director of Internet Technologies, with AdvantiPro. As daunting as that title sounds, the position, created newly for me, will surely live up to it.
With a collection of media products, ranging from print to online to design, and with a newly-rebranded flagship website, The Find-It Guide, having just launched, I will have more than my fair share of work to dive straight into once I get settled into the office!
And I cannot wait to meet all of the new team there, learn from their experiences, share some of mine, and find new and exciting ways of making what they have already done even better, however and wherever I can.
So, I find myself feeling both excited and sad. But that’s the way change feels: longing for the old, and excitement for the new.
Now I plan to enjoy my last day at Netbiscuits, then enjoy the weekend, and one in-between-jobs week, before embarking on my new adventure. Wish me luck. :-)
A good friend of mine, AlexanderKhost, and a group of his friends are running a Kickstarter campaign to provide NYC kids with an open, free and creative playground environment, aptly called play:ground.
I had an entire world around me like play:ground as a child, and I know that it had a lot to do with my enthusiasm for creating and willingness to explore new possibilities and options. Let’s try to give more kids that opportunity!
Thanks for any help you can offer Alex, his friends, and the kids that will benefit from play:ground. In the end, we all benefit from more creative, open-minded children becoming more creative, open-minded adults…
I had an issue the other day where I needed my Gruntfile.js to “know” what environment I was deploying to so it could use choose the correct parameter values.
Specifically, my Critical CSS Task needed to know whether it should use my Local, Dev, or Prod server to determine what CSS is critical.
Starting with the second block of code above, because that’s how the code actually flows:
grunt --env=dev
This is how you tell Grunt to get off its lazy butt and get to work. This can happen via command line, or, in the case of this project, via command line locally, but via DeployBot for Dev and Prod.
Typically you would start Grunt by simply typing grunt and hitting Enter. You might also be familiar with something like grunt svgmin which will start Grunt, but only run the svgmin Task. But in our case we’re adding this --env=dev at the end…
What’s happening here is we are essentially passing a variable called env and setting a value to that variable, and in the above case that value is dev.
The first line creates a new Grunt config variable, called environment, and sets, as the value of that variable, a SIAF.
The SIAF checks to see if any command line options were passed along with the grunt command, specifically if there was one called env (grunt.option('env')).
If the env option was passed, it’s value is set as a local variable (also called env); if not, it’s value is set as local (thus giving us a default, so I don’t have to pass the option when working locally!).
The function then checks a couple possible values of the env variable, specifically prod and dev, setting the appropriate value for the domain variable, and again, defaulting to local.
And finally returns the value of domain, thus setting the value of the Grunt config variable environment.
Putting it into Play
Finally, we make use of the env variable by sending it to the Critical CSS Task:
This is pretty standard Critical CSS stuff here, except for the url parameter value, which is set using grunt.config('environment').
This grabs whatever value we set in that environmentconfig variable and passes it to the Critical CSS Task.
All the Options
So, for my three environments, I use one of these Grunt commands to get the correct Critical CSS for my site:
Local: grunt
Dev: grunt --env=dev
Prod: grunt --env=prod
Again, local is the default, so no options need to be passed there, making local development, where I manually start Grunt, the easiest. And Dev and Prod are both DeployBot-driven, so I just paste that command into the configuration page and save it.
Summation
This kind of dynamic variable passing could be really useful for all kinds of situations, including testing new methods or trying any different parameter values really easily, without having to keep editing and saving your Gruntfile.js.
The other day a co-worker shared the link for okayNav, and I have to agree: although dependent on jQuery, it certainly is one of the “okayest responsive navigation” menus I have seen…
react-native-nw-react-calculator let’s you use one code source to create apps that work as an iOS app, Android app, desktop app, and in a browser. Wow.
And finally, whether you like AMP or not, you have to like Google’s proposed HTTP header, save-data, which developers can look for to send “lighter”, and thus faster, experiences to users that have activated the Save Data feature…
Great (albeit simple, which is actually part of what makes it great!) example of sort-order progressive enhancement from JeremyKeith, starting with select elements and enhancing with nifty drag-and-drop functionality, while still using the update process from the non-drag-and-drop version…
The future of loading CSS by JakeArchibald demonstrates a progressive approach to page rendering, allowing for improved perceived page load speeds, and pretty ideally designed for modular design & development…
Then here is an interesting follow-up from Jake. As Jake says, not practical, and probably shouldn’t even be done, but it’s always interesting to push envelopes and see how various options affect things.
Service Worker Precache is a module for generating a service worker that precaches resources. The module is designed for use with gulp or grunt build scripts, though it also provides a command-line interface. The module’s API provides methods for creating a service worker and saving the resulting code to a file.
Boy did this site performance article send me down a rabbit hole… Into Ilya’s presentation, into my repo, onto my dev server, and finally this site makes fair use of rel-prefetch. :-) My Analytics, at least for now, says that preconnect, prefetch, and prerender don’t make much sense for me, but it is something I will keep an eye on!