Developing on Staxmanade

Thoughts on Working Remotely from Home

(Comments)

This post may seem a bit longer than my usual posts. It's one I've slowly been extending over the last couple years while working remotely. Many of the points may be obvious ones, but if you're considering a work-from-home (remotely) type of position that you consider some of these topics.

Background

My previous job afforded me the opportunity to work from home a couple days out of the week. While putting my wife through school, those days were great. I would start work extra early so I could leave early and watch our little girl while my wife headed off to class. The early start was great because these quiet mornings were often the most productive part of my day. The lack of distractions such as email, meetings, and instant message chats along with the quiet focus time all contributed to this increased productivity.

While I quite enjoyed this time, was often productive, and it helped my family I still preferred to go into the office over working from home.

So why did I still prefer going to the office over working from home?

I did not feel as connected to the group, which left me feeling as thought I was always playing catchup. All of those water-cooler discussions and inpromptu office meetings where I (or anyone else remote) wasn't pulled into more often not left me feeling like I was not able to keep on top of what was going on.

This experience and the feeling it left me with is what concerned me about the new job I was about to take.

Worried to take a remote / work from home job.

Given my limited work from home experience, I was concerned about working remotely 100% of the time. However, the new opportunity to work for a consulting firm I admired, and the thought of being able to constantly try new technologies, and business domains was really appealing.

I have now worked remotely for Vertigo for over 3 years and I'd like to share a list of Pros/Cons that I've gathered through my experience working from home full time.

Con's to working from home

Now, while Con's do not outweigh the Pro's for me, there is quite a bit of grey area here, so let's review some con's.

  • Less human/social interaction on a daily basis. As an introvert, and a software developer, this is generally not too bad. This was a bigger concern for me originally and is much less of an issue now that I've tried it out. I make sure to take some time to have great Skype video calls with fellow remote coworkers and I also try to offset this by participating in local user groups or and other social occasions. However, the best medicine for this is a simple trip to the park with my little girls. I will say that I've had a day or two where I jumped at the opportunity to take a trip to Costco or other errand just so I could get out of the house...
  • Shipping Hardware.
    • This one is a bit of a pain. Working for a consulting firm means there are many of different projects that require varying hardware configurations. From Xboxes, test phones, tablets, computers, and even TVs. I semi-regularly run to FedEx and send something to H.Q. or the Apple Store or Best Buy to pick up some hardware based on the needs of a project.
  • It can be a little too easy to sit at the personal computer in the evening and reach over to my work computer to reply to a late work-related email, or hammer on some code. So you need to be careful about the work/family balance when it's so easy to work from home. This takes a bit of discipline.
  • Sitting in the office chair when the amazingly yummy aromas of some fresh home cooking - distracting me from being productive as the smell is driving my stomach to scream at me to go downstairs for some food!
  • Communication
    • Being remote, you have to become an over-communicator. An email here and there is fine, but combine that with chat/I.M., phone calls, video chat calls (preferred), and more emails. However, you have to work a little harder to be noticed, especially if you have to compete with people who are all working in the same office.
  • It often takes a little more discipline to take breaks.
  • Time Zones
    • Time Zones are a hassle from many different angles, even when you work at an office; however, working remotely often means your employer has hired you because you are not near them. This increases the chance that you are several or more timezones away from your company's headquarters. Which can mean the usual things like meal planning, start/stop times, etc require a bit more planning and accommodation.

Pro's to working from home

  • Home office temperature!
    • Like most indoor jobs, AC and Heat are good amenities to have, but in big buildings people cannot often control the temperature. It's either too cold or too hot as big buildings have a mind of their own (their airflow and ventilation kinks). However, working from home, you're the master of your indoor weather. If you get hot, take off some clothes or turn on the AC. If you're too cold, put on some clothes or crank up the heat.
  • Commute
    • I often joke with my fellow Californian commute ridden co-workers when they complain about traffic that day that I narrowly avoided a 3 (lego) car pile-up on my way to the office.
    • I live where it's cold in the winter and not having to scrape the ice off of the windshield of my car in the morning due to the icy dew is a HUGE benefit.
    • Plus there's the, well not commuting part. While I enjoyed using the commute to zone out to my favorite podcasts, I still find time to keep up with my podcast when doing things like laundry, dishes, etc.
  • More family time overall. Since my coffee, water, bathroom breaks all lead to opportunities where I can say hello to the family.
  • SWEATPANTS! My wife recently introduced me to sweatpants. OMG they are comfortable, try wearing those at the stuffy-formal-office...
  • Quiet place to focus. It's easy to isolate yourself from the outside world if you need some quiet time to focus and be productive. Shut off the I.M., put phone on do not disturb, close email and get some serious work done.
  • We have all the usual necessities at home,
    • Tools (for that time you need a screwdriver)
    • Easy access to hygiene related products/tools. Ever need to take a shower in the middle of the day? Change of clothes (spilled coffee....)? Or brush your teeth?
  • Invest in your office.
    • When you invest in your home office, you're investing in yourself. Get a good chair, desk, keyboard, mouse, etc.
  • Lunch at home. My wife is a great cook. I'm spoiled to nearly always have a great set of leftovers in the fridge. Keeping me from eating out all the time. Not having to worry about someone eating my leftover chicken-wings (ya, that really happened - not even funny - You know who you are!)
  • My wife just brought me the most amazing homemade burrito. I didn't even care I was on a video call with my team. nom...nom...nom...
  • One of my favorite perks, is not even a perk that any company could offer (or even replace). I take the opportunity to for 10-minute break in the afternoon, where I walk up the street to meet my daughter at the bus stop. This is so much more important in my life than practically any company can offer (like free lunches, ping-pong table, etc...).
  • Scheduling an at-home call is easy. It's rarely a problem to have a fix-it man come by, or cable-guy, or if a package needs to be signed for, working from home makes this easy.
  • David's Additions: I shared a draft of this post to a good friend and coworker and he gave me some other tips, I hadn't thought of, which I totally agree.
    • You struggle on problems and your kid walks in the room and puts your life in perspective.
    • I can listen to my music turned way up!

What about distractions?

I get this a lot, when I tell others I work from home. "I don't know how you don't get distracted with other things to do at home." This may be a very individual thing. While, there can be distractions at home, I've always been a focused individual and I would say it's often easier to be distracted at the office with office chit-chat, meetings, going out to lunch, etc.

Not-so socially appropriate

  • When you're at the office, possibly in a long meeting, what do you do if you have some gas? Working remotely, there's no stress, or stomach pain... Mute your conference call, relax and nobody is the wiser. (Except this one time, I did such a thing not realizing my wife was within an earshot. Yea, a bit embarrassing but we had a laugh over it.)

One of the Simplest Things You can do to Improve Email Communication

(Comments)

TL;DR

Respond to emails with got it. Or some context-related reply, for example: thanks or will respond with further detail later...

More Context

We all know that communication is important, and often where things go awry.

I sometimes wonder if I'm alone in this thinking, but don't think I am. When I send an important email, I like to know that the person on the other end received it. It may be an email that will take the other person time to respond with the detail necessary, but it's awfully unproductive to send an email, and wait a day or two before finding out that the communication was never received.

Simply replying with got it or got it, will respond with more detail later... is a great way to notify me that you've received the email (and may take some time to respond).

I don't necessarily care that my email takes priority, but at least knowing that the other end has seen it is 1/2 the battle.

Updating git branches.

(Comments)

How to update a git branch OTHER than the one you're currently on.

git branch -f {branch-to-change} {commit-to-change-to}

I recently setup a C.I. server to automatically generate builds of an iOS application and upload to TestFlight. I don't want each and every push to master to trigger a new TestFlight build, so I configured my C.I. server to watch the release branch.

I was starting to dislike the switch branch dance to trigger a new build.

What I used to do:

# When I was on the master branch
git checkout release
git merge master
git push

When things start to hurt, look for a better alternative. And with Git, there is almost always a more efficient way.

After digging a bit, I found the answer.

git branch -f {branch-to-change} {commit-to-change-to}

So to trigger a new build from master I can just:

git branch -f release master
git push origin release

Or wrap that in a Gulp task gulp tf. And with CommandAllThings I can now type rake tf, or grunt tf or gulp tf and they all trigger a new build to come out of TestFlight.

Or if you wanted to skip moving your local branch, you could just update the remote branch directly.

git push origin local_branch:remote_branch

So my workflow would look more like

git push origin master:release

Happy Automation!

Introducing CommandAllThings

(Comments)

I'd like to introduce a simple little tool/(set of scripts) I threw together last weekend called CommandAllThings.

Some background

Do you use any command line build tools like GulpJS, GruntJS, Rake, etc?

I leverage these tools in many projects, both at work and on my own projects. I recently noticed that the muscle memory I've developed was slowing me down as I switch between projects and inadvertently use the wrong tool in the wrong project.

When working on one project all day and typing rake test throughout the day, then switching to another project not using rake I found myself still typing rake test even though I needed to type gulp test, or grunt build. This really messes with my flow. All I wanted to do was test or build the current project.

So I created CommandAllThings.

What is it?

In short, it's a very simple abstraction on top of your usual task runners like GulpJS, GruntJS, rake, etc that allows you to accidentally type the wrong tool and still accomplish the desired task with the right tool.

By using aliases in either PowerShell or Bash we can route, rake, gulp, grunt, etc to CommandAllThings which will inspect the current directory, determine the correct tool and execute your task(s) with the correct tool.

This is great. Now when I type in the wrong command rake test in a gulp project, I don't get slapped in the face with an error saying "cannot find a rakefile." Instead I continue on my way like I knew what I was doing.

example screenshot of commandAllThings

Does it only work on Windows or on the Mac?

At the moment it works on both.

  • For Windows I have an implementation in Powershell.
  • For the Mac you can alias to a Bash script.

Download at GitHub!

Check it out!

What's next?

I'd like to look at adding other tools to the list. You can check out the project for other task runners I know about. And if you have any thoughts on how to detect the other types, drop me a note in the issues (or consider sending over a pull request).

I'd also love to get some feedback on how to best or more easily get this into peoples's development environment. For now it's pretty manual and since it's all about your profile, a bit personal, so probably a good thing that it's not automatically installed.

Happy Commanding!

How to compile plain *.js (JavaScript) files with the TypeScript Compiler

(Comments)

Challenge

Let's say you've been tasked with researching what porting your existing JavaScript solution to TypeScript may look like or maybe you're curious what this process would be like before you propose it to a lead or project manager.

The first hurdle you may stumble upon is - the tsc (TypeScript compiler) requires all of your files end with a .ts file extension. This can make quickly prototyping a port challenging. To get an idea of what a port to TypeScript will look like you don't want to deal with first renaming all of your files to .ts. Especially since there are probably files you want to not rename to TypeScript (like jQuery or AngularJS etc.

And since:

TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

it seems reasonable that you could acquire the benefits of the TypeScript compiler for even your existing JavaScript codebase.

Challenge Accepted.

The TypeScript compiler is open source, so let's take a dive into the compiler to see if this is something we can work around...

What are the steps we need to accomplish to make the compiler accept plain .js files?

  1. Get It
  2. Copy it
  3. Hack it
  4. Use it

Get it

Before we can get too far, let's first install the compiler onto our system.

I'll use npm to install typescript

npm install -g typescript

Note the -g here tells npm to install typescript globally. This adds the TypeScript compiler to your PATH so you can get right at tsc'ing your TypeScript code.

Copy it

We probably don't want to modify the globally installed version of tsc so we'll create a copy on our system to play around with. But, before we can do that we need to find where it is.

If on Windows or Mac

where tsc

NOTE: if you're using the PowerShell console on windows be sure to type out where.exe tsc because where is aliased to Where-Object in PowerShell which won't help us out in this case.

Once you've found the path to your version of tsc

Mine was in

  • C:\Users\jason\AppData\Roaming\npm\tsc
  • C:\Users\jason\AppData\Roaming\npm\tsc.cmd

Look at the contents of the tsc.cmd for Windows and tsc for non Windows machines. You'll notice that they are essentially executing node.exe passing in an argument to another tsc file in the node_modules path.

Take the two tsc and tsc.cmd files, copy them into a working folder MyJSCompiler and rename them. I named mine jsc and he shall be my squishy. Then take the contents of the node_modules/typescript/* folder (and path structure) and copy them to your working directory.

When you're done you should have a directory that looks something like this


--MyJSCompiler
  |   jsc                 <-- notice the re-named file from tsc -> jsc
  |   jsc.cmd             <-- notice the re-named file from tsc.cmd -> jsc.cmd
  |   
  ----node_modules
      ----.bin
      |       tsc
      |       tsc.cmd
      |       
      ----typescript
          |   .npmignore
          |   CopyrightNotice.txt
          |   LICENSE.txt
          |   package.json
          |   README.txt
          |   ThirdPartyNoticeText.txt
          |   
          ----bin
              |   lib.d.ts
              |   tsc
              |   tsc.js
              |   typescript.js
              |   
              ----resources
                  |   diagnosticMessages.generated.json
                  |   
                  ----(*.json files excluded for brevity)

Now you should be able to call your local version of jsc at the command line.

Hack it

Since we have a local version we can hack on now, let's find out what needs to change. Thanks to Ryan for already giving us a clue here.

Open up the node_modules/typescript/bin/tsc.js file (in our working directory from the previous step) and apply the below diff/changes.

     function isTSFile(fname) {
-        return isFileOfExtension(fname, ".ts");
+        return isFileOfExtension(fname, ".ts") || isFileOfExtension(fname, ".js");
     }

We've now implemented a small tweak to the TypeScript compiler that allows us to compile plain JavaScript files.

Use it

I won't be going into how to use the tsc compiler in this post, but you can now call the compiler passing along your *.js files and begin learning what changes you will need to make to your existing codebase to satisfy the compiler.

Be sure to use the --out FILE or --outDir DIRECTORY options because if you don't the compiler will take the input javascript file and overwrite it with it's compiled version.

!!WARNING!! I'll say that again, to use it, be sure to use the --out FILE or --outDir DIRECTORY options because if you don't the compiler will take the input javascript file and overwrite the original with it's compiled version.

With source control, this can potentially be a fun experiment to see what TypeScript's version looks compared to your own, but I'll leave that up to you to play with.

Best of luck on your port to TypeScript.

Migrating from BlogSpot to Octopress - Part 9 - What's left?

(Comments)



This article is Part 9 of 9 in a series about Migrating from BlogSpot to Octopress.

Now that I've migrated to Octopress, I'm in the process of finding my new blogging flow.

I'm currently editing markdown post drafts in a DropBox folder. I have been leveraging some of the following tools to write MarkDown.

My worry is that some of these don't have the best spell-check support - so here's hoping I double-check my work along the way :P.

Migrating from BlogSpot to Octopress - Part 8 - Redirect Atom/RSS in FeedBurner

(Comments)



This article is Part 8 of 9 in a series about Migrating from BlogSpot to Octopress.

This one is quick and easy.

I noticed that my original RSS feed staxmanade.blogspot.com/feeds/posts/default was 302 redirecting to http://feeds.feedburner.com/DevelopingOnStaxmande.

So I went to feedburner.com where I was already logged in (due to being auth'd with google/blogger) and from their I selected my feed and chose Edit Feed Details where I could put in my new RSS feed to http://staxmanade.com/atom.xml.

After doing this, I noticed 3 of my previously posted blogs show-up-again, but I can live with that.

Now you've hopefully migrated your blog's RSS subscribers automatically without loosing any.

Migrating from BlogSpot to Octopress - Part 7 - Setup a Custom Domain

(Comments)



This article is Part 7 of 9 in a series about Migrating from BlogSpot to Octopress.

To host your blog for free by GitHub, you are not required to buy a custom domain so this is an optional step, but one I took.

The reason I have a complete post on this topic is primarily to say that I was able to accomplish this while not even at my desk.

While out waiting for my daughter to complete practice, I sat on my iPhone and was able to not only buy the domain name staxmanade.com but I also configured the CNAME on GitHub. By the time I got home from my daughters practice, I could hit my blog through the new domain staxmanade.com. Exciting!

You can use this post for a quick and simple walk through.

Migrating from BlogSpot to Octopress - Part 6 - 301 Redirect Old Posts to New Location

(Comments)



This article is Part 6 of 9 in a series about Migrating from BlogSpot to Octopress.

So far we have mostly delt with getting the old blog content into our new Octopress blog. In this post I'll talk about how I setup automatic redirection from the old blog to the new blog.

Sorry, this post gets a little long, mostly because there is lots evolved, and I took some time to explain it along the way.

So, I'm not an SEO expert or even novice, and I hope the steps I took below actually gave me my end goal. I think they did, but let's not get ahead of ourselves. If you have any feedback, please drop me a line in the comments or in a github issue for this blog.

Reasons for redirection:

  • I'd like people to arrive at my new site even if they followed a link to the old BlogSpot location and get all the benefits of the new site (new theme, broken links fixed, etc)
  • The whole reason I did this was to 'migrate' not, start fresh.

I probably won't ever delete my staxmanade.blogspot.com blog due to outside blogs, articles and sites that have linked to posts I've made in the past, but at least they will end up at my new blog.

Goals for the redirection.

  • Users who click on a link to the old blog should redirect successfully to the new site.
  • I would love it if Google and other search engines could follow a 301 Moved Permanently redirection with the hopes that my old blog's search rankings would carry over to my new blog.

    DISCLAIMER: Given the steps in the post, I'm not 100% confident that this goal was accomplished, but I think it may have worked (maybe, possibly, ???)

Now, while I'm not 100% confident my search rankings carried over, I'm fairly confident that Google found out about my new blog because after just 2 days of the below steps being implemented, Google had already indexed the new site.

What's involved for redirection?

  1. Tell BlogSpot to redirect each post at staxmanade.blogspot.com to the new location.
  2. Handle that redirection on the Octopress side.

There are a number of posts out there that describe how to accomplish this with WordPress or other blogs that can host a dynamic server side component. However with Octopress or other statically generated sites we don't have as easy a time. I belive this has more to do with the lack of programmability on the BlogSpot side (or my lack of knowledge of how far you can go with it on their side) than the static-ness of our Octopress blog.

Let's get into why this wasn't as straight forward.

If you look at how to redirect from a BlogSpot blog to say WordPress you'll see that they are basically passing the FULL original url EX:http://staxmanade.blogspot.com/2013/12/format-your-net-exceptions-to-see.html to a server-side component, where it can dynamically translate that into the correct 301 redirect response needed for each page.

The problem we have is the BlogSpot template tags are limited. They don't provide a relative blog url parameter which would have made it easy. Instead they provide only the full URL <$BlogItemURL$> which we can't use on our static site.

The direction I took was to use the <$BlogItemNumber$> which is like a really long id value, leverage the Jekyll alias generator and end up doing two redirects.

  1. from staxmanade.blogspot.com/SomeBlogUrl -> staxmanade.github.io/blog/<$BlogItemNumber$>
  2. then from staxmanade.github.io/blog/<$BlogItemNumber$> -> staxmanade.github.io/blog/finalBlogUrl

On the Octopress side we are going to leverage the alias plugin. Once that's installed, we need to update all of our blog posts to add in the 'alias' that will point to th e/blog/{really_long_id}. My scripting hammer isPowerShell*(sorry if you're reading this on a mac - hey, maybe [Pash](https://github.com/Pash-Project/Pash) can help you if you're not on Windows)* and I wrote the below script to help in the task. Even if you don't knowPowerShell`, take a moment to read the comments in the code to get an idea of what it is doing.

In summary, the above code is:

  1. Parsing the blogger xml
  2. Extracting the post url (slug) and BlogSpot blog id
  3. Matching each post with a post in our Octopress _posts that we recently exported
  4. And injecting an alias: /blog/{id} into the header YAML

Look in your blogger xml for a sample ID, it looks like

<id>tag:blogger.com,1999:blog-4726251688144615011.post-7515836382847059837</id>

What we care about is the BigNumber after the "...post-". This is the id used in the above script to generate our new /blog/<BitNumber> alias url.

If you completed the above and run rake generate and rake preview, test out that your redirections are correct.

After I completed this and on my blog, staxmanade.com/blog/7515836382847059837 should redirect me to an actual post.

Once you're happy with your Octopress's blogger redirections, SHIP IT. Publish them to your blog and test them out on gihub rake gen_deploy.

Now that we have our static site redirecting the special /blog/{id} url's, we can go back to BlogSpot and update our template to redirect to our static site.

I used the below template (note search/replace your domain etc) before dropping this into your site.

Update Blogger template to redirect.

  1. Go back to your BlogSpot admin page and select the Template tab.
  2. On the lower right you may have to select (forgetting the exact text - but something like) Revert to classic template
  3. Modify the below template for your own site.

This will change all pages/posts on your old BlogSpot site (even your home page). You can now go test it out - see that it hopefully transitions you from your blogger site -> to the new static redirect - and then to your final post location. It happens so fast I sometimes don't see the middle/transition page.

Note: I had to run through this a few times before I got it right so be careful doing this (especially if you have a popular blog as it may interrupt users at the current time). I'm not that cool, so my blog could handle some downtime :P

Migrating from BlogSpot to Octopress - Part 5 - Fix Links

(Comments)



This article is Part 5 of 9 in a series about Migrating from BlogSpot to Octopress.

Once you've ported your content into Octopress there were several steps I used to fixup links. The two types of links I cared about at this stage were:

  1. Cross-Post links (where I referenced one of my other posts)
  2. Broken links.

Cross post links

I used a text editor and some command line magic to search for http://staxmanade.blogspot.com/ and replace it with /blog/ so that my cross-referencing posts could link to a relative version of the blog instead of the full blogspot domain.

Depending on how you configure your permalinks you may need to do some more link manipulation. I had to search .html at the end of my cross-referencign posts and be sure to delete it since my old reference would look like

http://staxmanade.blogspot.com/2013/12/format-your-net-exceptions-to-see.html

but now should link to

/blog/2013/12/format-your-net-exceptions-to-see

If you're on Windows and not interested in figuring out a PowerShell or other command to quickly search and replace, a friend of mine Tim Greenfield has a great utility GUI tool for easy search and replace.

I don't recall exactly what I did, I think I either used sed or a python command on my Mac for the initial search/replace. I'll let you figure out the rest of how to get that task done.

Once you're done fixing up cross-post links, we want to make sure we didn't mess anything up, and while we're at it, fix any old or out-dated links.

One great feature of Octopress is that we can run the site locally and use a spider tool to search for broken links. Run rake generate and rake preview locally to browse your site.

I used the Integrity link checker on my Mac to search the http://localhost:4000 site locally. There are lots of these tools out there, so feel free to use what you feel happy with.

This was a great exercise. Not only debugging any oopsies from the above cross-post fixup step, but allowed me to find any external links to blogs/images/etc that were out of date. I wasn't able to fix up all of my external links, but that's the way of the web unfortunately. I haven't done it yet, but have consider going back and linking the out-dated links to a version out on the Way Back Machine.