Cloudbacon A flowy thought place

DynaTech Double O Nine

Poodcasts! That’s right. A quick run down of what we are meandering about can be found at the Soundcloud page. Also a chance to subscribe to the feed and likely a plethora of other awesome bits.

If for some reason this is the first DynaTech podcast, the TLDR is as follows: It is your’s truly and another Dynamo-mate just riffing on the week’s technology news. Sometimes there is a smattering of Microsoft cuddles, other times we only care about the money that’s flowing around the Valley, and we even dip our toes into gaming here and there.

With the untimely demise of Google Reader, RSS is a shit show so getting your technology news in that manner is worst at best. Simply point your favorite podcaster over our way and bemuse your dinner guests with all your tech knowledged, sponged up from one podcast.

*Dynamo, DynaTech, Cloudbacon, or your’s truly are not liable for guests who leave your dinner due to conversation centered around tech news.

Remote in Twenty Sixteen

Excerpt from: ‘Remote Work. Right Now.’

It seems that the slow transition to larger remote workforces in the technology space has finally begun. The many benefits of working remotely combined with the pitfalls of modern offices and the current robustness of remote-enabling technology have finally culminated in this perfect moment. The time is finally right for remote work, right now.It seems that the slow transition to larger remote workforces in the technology space has finally begun. The many benefits of working remotely combined with the pitfalls of modern offices and the current robustness of remote-enabling technology have finally culminated in this perfect moment. The time is finally right for remote work, right now.

Source

Couldn’t agree more with Ray about this paragraph. While in late 2014 and 2013 we spent a good amount of time constricting the remote salesforce and upping the housing prices in large, tech supported cities, let’s spend 2016 spreading our wings. If perhaps Ray’s writing rings true, make sure to share the article through your favorite medium

Twenty Fifteen Retrospective

This year, this year of 2015(is that right?)… Fuck it. There was going to be a retrospective just like last year and poof! Nothing. What happend is the web became inundated with these type of posts. It all happened after Christmas, and wow was it a crying shame. Everyone, and by everyone, I truly mean everyone on the web decided that they, right now, would write some kind of retrospective.

It seemed like it was a go-to response to some Verge article. A right of passage into the world of 2016, or just perhaps a way to blow off steam that had accrued throughout 2015. Whatever, likely no one will care if this turns into a not-spective. Which actually just happened because the rest of this chutzpa will be a response to a fine friend.

Late last year a coworker produced a post outlining the specifics behind his standup desk setup. Afterwards, he asked me nicely to do the same so he could compare. Well, that day has come. As follows…

I have been standing now, in some fashion for the past five years of work. Most of it has been on shody, thrown together abarations that sit on normal desks. Only recently, within the last three years, have I invested in a proper standing desk for my home office. This includes:

  1. Set of standing legs from multitable
  2. 1 simple top from Ikea
  3. 1 freedom monitor arm from ergotech
  4. 1 Asus 25 inch monitor
  5. 1 Calddigit thunderbolt station
  6. 1 CST Laser guided trackball
  7. 1 Custom Ergodox with deep space alphas and granite mods
  8. 1 Power Cube
  9. 1 12South ParcSlope

All of this can be seen in the photo below.

So what are the goods and the bads of this setup? For starters there will be a new Ergotech arm and Monitor in 2016. Not because I crave the desktop space and can’t work off from a single screen. It is just much more convenient to have a todo list, doc viewer, chat, and terminal all open in the same ‘space.’

Some other ‘goods’ are that you only ever need to plug power and a thunderbolt cable(soon to be 2) into your computer to get access to all required peripherals. This allows plugging in and getting work done a breeze. Or if required, unplugging very quickly and heading out the door for some coworking. Being mobile and actually taking time to move is what tends to keep the creative juices flowing. Having an “assigned” seat in a workspace never really did it for me and this is apparent in how I have set up my home office.

And now for the not so greats: My office at the moment is a little sparce. It could use a lamp and some overhead lighting and especially a confy-ish chair. However, these are luxuries that I fight to find relevant in a space that should should ooze productivity while kicking the user out at the end of the day. After all, this is a place where work should get done. Perhpas a little moonlighting, and a couple hours of open source work at max. It shouldn’t feel like a place I want to escape to at night. Because after all, this is the environment where I go to work and that very concept is hard to keep in line when you work at home.

In terms of the this blog. I have every intention to get my ideas down more frequently this year over lasts. Last year, when it came to writing was most definitely the worst and that should change. So with high hopes, and perhaps a pretty sweet desk setup, here is to 2016!

IMG_0972.jpeg

Derailing Tech Interviews For The Better

One of the most feared activities on this planet is the tech interview. Not so much the first, get to know you interview but, the third interview. The one where the interviewer asks a question about recursion… or ML. No, I am not currently looking for a new job, I have just had the pleasure of derailing a technical interview recently. In addition, this topic always seams to be top of mind. Plus a constant topic talked about in any software engineering circle.

The hard part of it all is pinpointing what makes these interviews so terrifying. Perhaps it is the need to sit there and let the interviewer barate the interviewee with questions that they feel are relavant. We all know these, they may include Towers of Hanoi, cycle detection, something about man hole covers, and my all time favorite: some overweight campers need to get over a rope bridge in 17 minutes. The answer to the above is 12. The campers, in their packing extravaganze happen to have brought a rope. This allows them to pull the required flashlight back across the bridge without having to walk it back.

And… why do these suck? It’s simple: we don’t use Haskell or ML in the real world (not many of us). We also, as web programmers(apparently not even kernel programmers) rarely use recursion. And if we did, Babel or some other transpiler would deconstruct it for us(t’s faster that way). Yet, it is a constant that we will be inundated with these questions during the interview process.

Frankly the above blow but, here are a few that can turn the tide of any interview.

  1. Research the companies open source work. Look for good documentation, well written commit messages and inquire about documentation. Doubly so where it is lacking (no documentation is complete). In some ways, these developer soft skills are more inportant than recursion.
  2. Inquire about how they communicate. Do they use asynchronous tools that add to documentation or do they prefer to do things through video chat? If the latter is true then how or when do they document their face to face time? Have they upgraded their Slack account so history is completely searchable?
  3. Are they partially remote (“remote by design”) or remote first? If the position is remote or augmented the answers here are key. It shows how they value remote employees and if they know how to work remotely themselves.

These questions are aimed at getting the interviewer away from tooting about their ML knowledge. They require a good bit of company research by the interviewee but, this should be a given. Knowing the people who are grilling you on the other end of Skype is the first step in winning. And winning is the only outcome that makes sense when being subjugated by someone else’s ML knowledge.

Hubot Sightings With Monit

Slack and bots go together like peanut butter and chinese food. They are quite, literally over running the joint. So with an already loud and notification filled app like Slack, what’s one more? Hubot is a somewhat older, coffee script powered happiness engine from the folks at GitHub. Getting one of these guys up and running isn’t really the topic here but, this guide is super easy to follow.

Now that there is a bot up and running, we can’t just check out of the server and have it continue to run. That’s where Monit comes in. Monit is a dead-simple, text based uptime monitoring system. It can search out, at an interval and make sure a specific program is still running. If the PID, or whatever is missing, Monit will use the designated start process to start things back up.

Ok, so how can we stitch Monit and Hubot together? Matt Garrison, a couple years ago put together a gist for just this occasion. A couple of things to make this thing work:

  1. Make sure on the restart and start services to use a user and group that is available to your server.
  2. Name the bot properly
  3. Make sure to use the correct path to the bot
  4. And finally/lastly, call the hubot bin from node_modules, it’s cleaner.

Happy annoying your fellow Slack mates with kittens and Archer quotes. Also, if for some reason Matt removes the above link, here is my forked gist

Update for Oct 11, 2015

Since writing this, we have moved on from Monit to God. God, may require Ruby but, overall it has been a much more stable choice over Monit. Monit seemed to generate new instances of the Slackbot And never cleanup the old pids. This left the users confused when they interacted with the bot because any command would be multiplied by the amount of instances currently running. Not good when you are trying to not spam your team’s Slack channel.

God has been exceptionally reliable and always seems to reap the previous PID before creating another instance.