Wes Gorgichuk

Wes has an extensive background in JavaScript, Node, PHP, MySQL and Actionscript development. He enjoys learning new technologies and has unwittingly received the, unofficial, title of DevOps at gskinner for managing the internal server infrastructure in addition to his programming duties. When he's not learning new technologies he can be found hitting the trails on his mountain bike or travelling the world and eating at some of the best restaurants there are.

I’m Lazy

Yes, I’m very lazy and proud of it. Most programmers out there will understand that. We’re among the laziest people you’ll ever meet. We’ll work hard and create a vast array of tools and scripts to aid us in tasks that we consider boring or repetitive, all so we don’t need to do extra work. Many of the repos at gskinner have a utils folder that’s full of scripts that serve one specific purpose. That’s a good thing. In daily programming, there are always repetitive tasks that crop up. Some are easy, some are just boring and time-consuming. Here are a few tips to help you also be lazy and save those precious seconds during your day.

When Should you Create Tools?

  • Is there a group of tasks that’s repetitive? Ex: everyday are you running the same X commands? Make a script to wrap them.
  • Is there a boring, but labor-intensive task that comes up every few weeks or months? Make a script for that. A good way to know when you should create a script for these tasks is, are you always having to remember those nit-picky details about how to do it? Or are there weird edge cases you know will be forgotten? A quick script will help isolate those dependencies for next time.
  • Is it a task that’s large and time-consuming? Examples could be data extraction or converting a folder full of files. Make a script for that. Sometimes if you know that one task will take you a few days (or more) to complete. Then, by all means, spend a few hours or even a day or 2 making that script that will save you time in the long run.
  • A “tool” doesn’t need to be a script. It could be a small, throwaway, RegExp expression. I don’t know how many times the “List” feature on https://regexr.com/ has saved me from hours of tedious data conversion tasks.

Focus on Functionality 

These tools don’t need to be perfect. They don’t need to be used by other projects or other people. Sure, if you make something that’s useful, then, by all means, consider making it more portable. But don’t waste time upfront with that extra work. It’s very tempting to over-architect your tool, but it may only be a script that’s only ever used in your project, or potentiality only runs once or twice. Your initial focus should be making it functional and don’t worry so much about error handling. Don’t worry about making the UI or cli interface perfect. Don’t worry about making the code clean. Do what’s fast, do what’s gonna get you to that point of running the script, so you can move past your boring task. You can always tweak or polish your script in the future. Or someone on your team will.

Organization 

Sometimes a tool turns into something more. Something that requires you to start adding command-line arguments or even UI. If you are in a JavaScript project, chances are you already have a package.json file.  And it’s super easy to add scripts to it. More on that here: https://docs.npmjs.com/cli/run-script. This helps centralize your tools, and makes them easy to discover, run, and self-document. For other projects just having a utils/ folder can be fine. Just remember to name your script something useful. runMe.sh is not useful. download-strings.sh gives some context to what will happen when you run this file. Don’t forget to add some docs. Use your repo’s README and add a one-liner to say what your script does, and any potential arguments or gotchas for running.

Stay Lazy!

Keeping it Grounded: Why We Avoid the Cloud (Sometimes)

The Cloud

Don’t get me wrong, the “Cloud” is great. Being able to utilize existing apps and not having to worry about updates or security is a huge time saver. But when it gets down to it, “In the cloud” is a buzz term. When translated to laymen speech it means “Storing your data and running your applications on an offsite server, somewhere”. It’s that “somewhere” that is a legal gray area for us, and for certain clients. For example; let’s say we’re working on a project for Microsoft, but are storing documents and files on Google servers. The two companies can (and do) collaborate, but what if they don’t on this project? And we’re storing sensitive Microsoft information with Google? It could cause legal issues if a dispute ever came up. This is the primary reason why we choose to self-host the vast majority of our infrastructure. The services we self-host include a Git server, bug tracker, wiki, file syncing server, and a custom built timetracker. Having a local server host all these services allows us to be extremely agile in development and with our workflows.

Continue reading →

Automation in Your Daily Workflow

Automation saves you time, your company money, and your employee’s sanity. At gskinner, we have a long history of building workflow tools to aid with anything from creating a simple button in Flash, to managing the build process for entire web apps or JavaScript libraries like CreateJS. Automation doesn’t need to be complicated. Some of my own tools only have a few lines of code, but those few lines can take hours off any project. For large scale projects spending hours or even days building an automation tool can have the same impact as a small tool. I generally start with a small scope (no more then a few hours) and see if what I’m building is a) Useful and b) Useable. If it doesn’t meet both of those criteria then I can re-evaluate my approach without burning too much time.

Continue reading →

DiggTop AIR Application Updated

This week, our first public AIR application, DiggTop, surpassed the 10, 000 download mark, thank-you to all who have downloaded it!

We initially announced DiggTop back in April, Flex + Apollo + Digg API = DiggTop!, for the then brand new Digg API. We had hoped to have many new versions and features out by now, but due to our internal work load, free products like DiggTop suffer (an all too common story). But fear not! We have not forgotten about this project and still have great new features planned for (hopefully) the near future. We will also be updating it to match any future builds of AIR. So stay tuned, as our little AIR application will keep wasting your time well into the future.

**Note: Digg has recently updated their api, so any current builds of DiggTop will not work anymore. We apologize for any inconvenience this has caused. This build resolves that issue, and adds a new images section to match the Digg.com site.

Alpha Video Article Released

Macromedia has released the second of a series of articles from us Flash developers at gskinner. This article entitled “True Alpha Video in Flash 8” gives you the knowledge and skills to create your first alpha video, and how to use that video in Flash. I learned a lot about the new Flash 8 video in researching this article, and I really hope you take away some good knowledge about creating and using alpha video from reading this. You can read my article here. While researching this article we had tons of fun filming Guirellmo the hamster for the goofy demo below. Guirellmo’s whole purpose was to eat, and run across the screen (easier said then done). Just click to drop food in his feeding area and watch him do his thing.

Continue reading →