Super Simple Versioning of Third Party Scripts
My attention span decreases every day too… **tl;dr** – Scroll to bottom of page for a neat code example…
Working on a large eCommerce web site gives me the “privilege” of working with other companies that integrate with us via JavaScript files placed in our code. Privilege is a euphemism here, it’s usually a pain. Some are good yes, but many of these companies write crappy JavaScript. Coming from me, that’s a harsh statement, I love JavaScript but I’m not as good at it as I’d like to be.
One of these companies has a couple files on their servers that are slow loading for our users at times. Since we sell to most anybody worldwide our users can come from all over the world. These files are slow to load sometimes because our partner doesn’t have a very robust server network. We were told that they could not be downloaded from them and served through our domain because they change too often. We were skeptical so I thought it would be interesting to see how often they actually change.
I posted a question on Twitter asking for a program that could be scheduled at a configured interval to download a file via http and version it. I’d like to see how the file changes over time. It seemed to me like something was probably out there and that I shouldn’t write something myself, this is why I asked before I started coding like a mad-man. I got some good responses and cron was the most common response, but I’m running Windows because that the best OS for our company and the work we do.
The smart and talented Brian Hogan (follow him, seriously, do it!) suggested wget, which I already had on my machine at work. In my limited experience with wget, I realized I could schedule a task to run a batch file to issue the wget command. Simple enough, right? Now, when it comes to versioning… we use git for all of our source control so why not just set up a local git repo? Brian’s suggestion and my love of git made this task super simple.
The code is (generically) as follows:
(you have to run ‘git init’ and commit your first version, but from then on…)
The moral of this story blog post is that there’s probably already a good way to do something that I just haven’t figured out yet. It’s super common, but can be tough to consider at times. This is why we pair when coding, ask for advice on code design and generally shouldn’t work in a “silo”. Just some food for thought!
If you have more questions on this hit me up on Twitter @ChrisMissal.