Shepherd Book's Commonplace

A Wholly Immersive Dev Environment

2013-07-08T00:00:00-04:00

A Wholly Immersive Dev Environment

8 July 2013 – Jared Koumentis

Since I’ve dove deeper and deeper into the Dev side of the DevOps equation, I’ve found myself intensely interested in how people like to work and their ways to be most productive. I’ve seen some really interesting setups and have adopted a few myself. We’ve all heard about having a large ultra-hi-res screen and having a second screen in a portrait layout for having longer form documentation or code displayed. Ergonomic desks, chairs, and mechanical keyboards. No two development environments are quite the same.

Wait. I’m not describing what you thought when I said “Dev Environment”? Perhaps you thought this was a post debating the pros and cons of different IDEs or text editors. I suppose this is more of a hardware focused thought process I’m on.

We’re in the middle of some remarkable happenings in technology. The things that have caught my attention aren’t traditionally aimed at developers. We see some amazing things happening with Virtual Reality and Human-Computer Interface technology. Typically, such things are aimed at gaming and immersive 3D worlds. Oculus VR, Omni, Leap Motion. These devices offer unique interaction experiences.

As you read what follows, remember that the technology to do this currently exists. It just needs to be brought together.

Here’s a future dev environment I envision…

You sit down and put on your headset. As you open your eyes, you are automatically recognized (by your iris, of course) and given access to the systems you need to do your work. The headset is lightweight and wireless, connected to a small and incredibly powerful little “mini-cloud” piece of hardware sitting next to you. That, of course, connects to a large virtualization environment, allowing you access to any resources you require.

You tell your virtual operator to load up your programming and staging environments. You’re asked if you’d like to listen to some music and you choose some to thrust you into the zone. I front of you, you see all manner of feedback. Your code sits just off to the side. Up and to the other side, you see a running environment. It shows information about the running staging and test environments, as well as an interface to interact with your program. Just behind that, floating just out of the way, are all manner of graphs and data about your program and server’s performance.

You reach out and grab the code, pulling it forward. You open your hand and, with the flick of your fingers, have it fill your vision. You see, built into the headset are sensors that can detect even the most minute movements in your hands. You begin to think about the problem you face and how you might overcome it. Your headset detects a slight rise in your stress level and adjusts the music accordingly. You ask your operator to provide a thirty minute flow state enhancement, to help you bring everything into your working memory and manipulate it within your mind. Monitoring your brainwaves, it begins to apply a very slight current to your forehead. You feel a slight tingle across your skin as your mind begins to work at it’s most efficient. The thirty minutes pass in what feels like a tenth of the time. As you feel yourself come out of your flow state, your operator asks if you’d like some tea. That sounds nice. You slip off your headset and walk to the kitchen, where a warm cup of tea awaits you. You remove the cup from the machine and look at the ingredients on the display. Earl Grey, Milk, Sugar, Lavender, Choline Citrate, Pramiracetam, and a touch of Ginseng. Your operator knows what you like and knows what your body needs, so it prepared the perfect cup for you.

As you walk back to your workstation and place you headset back on, everything reappears before your eyes. You ask your operator to get in touch with your coding partner. It’s time to do some code review of what came out of your flow state. You hear their voice and look over to see them standing beside you. You ask your operator to fire up the loading program. You and your partner find yourself standing in a pristine room, ready for testing. The code appears before you both and you begin breaking down and refactoring what you find. As you modify the code, you watch as the environment updates and approves your changes. All your tests pass and your operator asks if you’d like the changes deployed to production. You tell it to go ahead and a diagram representing your production environment appears. You watch as the changes propagate through the system and are confirmed.

“Deployed…” flashes in front of you and fades into the distance.

You and your partner decide that now is the perfect time to go ahead and work on architecting your next project.

“Operator… blank slate please.”

As the pristine environment materializes before you and your fellow dev, you reach out and begin…

- ShepBook

Diversity - More than meets the eye.

2012-12-24T00:00:00-05:00

Diversity – More than meets the eye.

24 Dec 2012 – Jared Koumentis

Diversity

A lot has been written about about diversity. It’s certainly an important topic. Many people focus on the gender or racial aspects of diversity, and many people have written about those parts of the conversation. I’m going to focus on something deeper than what you typically here about. Instead, I’m going to talk about the type of diversity that you can’t determine with a checkbox on an opt-in part of your job application.

Something I’ve observed in a number of companies is a lack of “thought diversity”. This is seen particularly strongly in a number of Silicon Valley startups. The culture of the “brogrammer” is a clear example of this. Now, it’s not to say all startups are like this. Perhaps, let me explain more of what I mean…

I was recently watching a video clip of “The Lost Interview” with Steve Jobs. He mentioned how a great team is like a rock tumbler. You take ordinary and seemingly plain rocks, apply friction, and you get something beautiful out of it. He states how a great team is much the same. A great team has clashes… fights even.

Companies that embrace this friction do amazing things. Companies that avoid this friction don’t necessarily die… They do, however, slowly fade into oblivion. Some of the greatest companies that we’ve ever known have been lead by leaders who embrace friction. Because of it, better people, better products, and better companies come out of it.

In many startups, there is significant weight given to “culture”. Everyone loves to talk about how you must protect the culture of your company. However, not many people talk about what you should be protecting it from. The undertone is that, if you let in people from “outside” your company’s culture, they will ruin it. But what does this really say?

For many startups, to “protect your culture” means to seek out and hire only those who share your same style of thinking. There is a problem with this. If you have people who all think the same way, you’ll probably eliminate a great deal of friction.

I’ve personally watched this happen in a number of businesses. They try to hire only those who think like their current group. They avoid friction. The problem I’ve seen, and it seems to inevitably happen, is akin to the “Bus to Abilene”. I never knew what to call the “Bus to Abilene” until I read “Quiet”. Susan Cane explains it well.

“The ‘Bus to Abilene’ anecdote reveals our tendency to follow those who initiate action—any action.”

With everyone thinking the same, you end up with a group management that moves on ideas without fully considering the counter arguments. Unfortunately, due to the homogeneous nature of such groups (again, caused by the sacred guarding of “the culture”), you have a sort of cascading effect. “Well, the other people think it’s a good idea, so I guess I should think it’s a good idea too…”

I won’t say that you shouldn’t consider your culture of your business. I agree that it’s important. I’d only caution that you not guard against the wrong thing. Embrace friction. Find people who disagree with your views and work with them. Listen to the people who disagree with you and try to understand the “why”.

Remember… while diamonds are formed from ugly blobs of carbon that are placed under heat and pressure, they only sparkle and shine after being ground and beat against another diamond. Startups naturally have plenty of “heat and pressure”. Make sure your culture doesn’t exclude the friction.

- ShepBook

ZFS and DTrace running on Ubuntu Linux

2012-06-01T00:00:00-04:00

ZFS and DTrace running on Ubuntu Linux

1 Jun 2012 – Jared Koumentis

ZFS and DTrace

These two technologies are the main thing I hear when I ask people “Why do you stay with a solaris-like operating system, instead of moving to Linux?” Hell, these two technologies were the reason why the company I work for spent several months building their own solaris-like distro based on the Illumos kernel.

Of course, I have my own opinions on these technologies. ZFS is certainly handy. Compared to other filesystem or filesystem management software, it does make things easy. For DTrace, I have an issue with the steep learning curve. The ability to instrument in real time with lowered probe effect is pretty cool though. Personally, I do not think that these two technologies are worth staying with or moving to a solaris-like OS. Primarily, this opinion comes down to community. You could pile all the communities together (Illumos, OpenIndiana, SmartOS, OmniOS) and you still wouldn’t approach the same level of community found in any of the major Linux distros. Need a distro designed to remove pain from the administration of your computers? Ubuntu. Need extensive documentation on everything you can imagine? Arch Linux. Need a great desktop distribution? Linux Mint. I could go on and on. Simply put, the community behind Linux is many times greater than that behind the solaris-like distros.

So, I had heard about ZFS and DTrace running on Linux. People have been working on them for years. Basically, since the time the technologies came out on Solaris. So, I decided to follow up on these ports and see what could be done. Luckily, I had great success in getting both to run on an Ubuntu server of mine. If you would like to do so as well, just follow the steps below.

Firstly, ZFS

1) Install an Ubuntu server. (I recommend trying it out on a VM first.)

2) Attach 2 drives to use for testing ZFS. (Again, I was using a VM, so this was as simple as “attaching” two more virtual hard drives.)

3) Partition the new drives. I used cfdisk on my two newly attached drives. If you aren’t sure of which /dev/sdx device the new drives attached as, just “cat /proc/partitions” and you should find it.

4) Do a “sudo apt-get update && sudo apt-get upgrade” to make sure your system is up to date.

5) Install the needed prerequisites with “sudo apt-get install python-software-properties bison flex build-essential libelf-dev zlib1g-dev libc6-dev-i386 libdwarf-dev binutils-dev”

6) Add the zfs-native apt repo with “sudo add-apt-repository ppa:zfs-native/stable”

7) Update apt with the new sources from the zfs repo with “sudo apt-get update”.

8) Install ubuntu-zfs with “sudo apt-get install ubuntu-zfs”

9) Create your new zpool with “sudo zpool create zfs-blog raidz /dev/sdb1 /dev/sdc1”. Here, “zpool create” is given the name for the pool “zfs-blog” and told to use “raidz” (which will mirror, in this example) and then told to use the two disks we attached and partitioned earlier “/dev/sdb1 /dev/sdc1”.

10) Check out your new zpool with “sudo zpool status”

11) Check out your zfs-blog dataset with “sudo zfs list”

12) See that it is listed with “df -h”

13) Enjoy ZFS running on your Ubuntu server.

Then, DTrace

1) Install git with “sudo apt-get install git”

2) Either make a git directory and move into it for you to keep your git stuff together or move to the directory you already use.

3) Clone my fork of the dtrace4linux repo with “git clone git://github.com/ShepBook/dtrace-for-linux.git”

4) Move into the dtrace-for-linux directory with “cd dtrace-for-linux”

5) Run “sudo make all” to build dtrace-for-linux.

6) If you would like to install dtrace into /usr/sbin/dtrace (The solaris-style location for this tool) then do “sudo make install”

7) To load the DTrace kernel module, do “sudo make load”

8) Enjoy DTrace running on your Ubuntu server.

Some side notes

I used Ubuntu 12.04 LTS for this setup. I ran it in Virtualbox for Linux. I forked the “dtrace4linux” repo to make this easier and to be able to base my instructions on a set point in its development. I have been able to play around with ZFS and it seems fully functional. I am not well versed in DTrace, so I can’t really tell you how well it is or is not working. I was able to run some one liners just fine, however, I’m sure there are differences between the probes on Linux and the probes on a solaris-like system. If you were well versed in DTrace on solaris-like systems, then I expect that you will be able to work with and/or figure out how to make DTrace work on Linux just as well.

Hopefully, with the ability to run ZFS and DTrace on Ubuntu Linux, the people who have been holding back from moving to Linux from a solaris-like operating system can be convinced to join the wonderful community surrounding Linux. I, for one, welcome the solaris converts with open arms.

- ShepBook

Further Reading and Sources:
Thanks for Darik on Slashdot for recommending these links:
ZFS on Linux Homepage
ZFS on Linux Launchpad
ZFS Introduction

A Theory of Productive Spaces

2012-05-13T00:00:00-04:00

A Theory of Productive Spaces

13 May 2012 – Jared Koumentis

I’ve been thinking about what an optimized collaborative space would look like. I know that many businesses are certainly concerned with this. Think about it. Who wouldn’t want to increase the productivity of everyone in their company?

I suppose that the place to start is to consider what it takes to do awesome work. Since most of my experience is in the technology field, that is what I’ll be focusing on here. However, I would suspect that many of the theories here could be applied to other fields just as well.

Think back to the time when you’ve done your best work.

Of course, different kinds of work are better suited to certain kinds of spaces. There is a difference between creative and implementative work. When it comes to seeding creativity and innovation, solitude trumps collaborative environments. How so? Remember the concept of mirroring in psychology? People in a group tend to mirror the person that is percieved as “dominant”. This can often lead to a sort of “common denominator” of an idea coming forth from such groups. Typically, this idea will originate and is fueled by the most extroverted person in the group. While this is fine for deciding where a group will go for lunch, it’s terrible if you actually want to hear of innovative, off-the-wall ideas. Once an idea has spouted and taken root, then there is significant benefit to be found in polishing the rough edges in a collaborative environment. This can certainly help with determining implementation. The difference is that the idea didn’t come from the group. Ultimately, it comes down to this. If you want new, fresh, unique ideas… seek solitude. If you want to refine and test an idea… seek collaboration.

Think back to the time when you’ve done your best work.

When I think of the times I’ve been most productive in working with other people, it’s always been on a small scale. Two or three people working together seems to be the sweet spot. When you have more people than that working together, you end up with either two to three people doing most of the work and the rest watching, or you end up with the larger group breaking up into smaller groups of two to three and tackling the problem. This is why meetings are so terribly inefficient. So, ultimately, do you really need more than two or three people in one “group work space”, working on a single problem? Is mandating a “group brainstorming session” on a problem really going to help? You see this happen naturally in group chat rooms, like campfire. A few people will be discussing something and it gets taken to another room or instant message, where the two or three people can continue communicating. You’ve seen this if you’ve ever walked in on a few people staring at a whiteboard covered with writing and they’re just sitting there, thinking.

Think back to the time when you’ve done your best work.

You hear a lot about open floor plans these days, from those that love them to those that hate them. A bit of a confession is in order. I used to be one of the people that was absolutely in love with the concept of an open floor space. Even now, I still think they can be leveraged well. However, there is something missing from open floor spaces. It has nothing to do with furniture or layout. Instead, it has everything to do with culture. I think that the quintessential open floor plan has been wildly popular for many years… in libraries. Think about it. Almost every single library I’ve been to revolves around a giant, open space. What’s the difference between a library and the “typical” open floor plan office? Library culture. If you start cracking up and having a loud conversation in the middle of library, you are certainly going to get stern looks. If you keep it up, the librarian is probably going to kick you out. It’s a group space that is focused on solitude. I know that sounds like an oxymoron. “Group space focused on solitude.” Sure, you can work together, but keep it quiet. This lets people really get heads down and work on something without feeling antisocial. This sort of open floor space has worked for many, many years. It can work for your open floor plan too.

Think back to the time when you’ve done your best work.

“But what about our culture of enjoying the company of the people we work with?”, you may ask. I never said that you couldn’t. Might I propose the 40/60 theory? What’s this 40/60 theory? It’s actually pretty simple. 60% of your office space is dedicated to being a sort of library space. Quiet, group solitude space. The other 40% is dedicated to spaces where people can relax, talk, drink beer, or whatever else they want to do together. One key to this is that the 40% space does not include things like the lunch/break room, conference rooms, or other similar spaces. The 40% space should have lots of places to sit. Comfy chairs, couches, and cafe tables come to mind for me. Whiteboards everywhere; all over the walls and a few standalone ones on casters. This would be where you keep your games too. Perhaps a nice big projector for watching fun stuff together. The 40% space is where people can go and just relax. You could also do work there. Perhaps you’re in the mindset of craving interaction but still want to hack on something. This is where you go. Having a 40/60 space would allow people to match their environment to their mindset at the moment.

Think back to the time when you’ve done your best work.

Mindset. I guess a lot comes down to your mindset. Now, I’m not saying you need to find some way to alter your mindset in order to do great work. I would never expect someone to do so though. Neither should you or your business expect that. I know that, for me, the times I’ve done my best work is when I’ve been able to match my environment to my mindset. Not the other way around. (I honestly don’t know if matching mindset to environment is even possible. If it is, it must be hard.) By giving people a choice of environments to work at, in the office, you give them the ability to match their environment to their mindset. I cannot stress this enough. This is important! Though, honestly, sometimes a 40/60 space still isn’t enough. When a 40/60 space just won’t cut it, turn to the rest of the world. Perhaps working in the office just isn’t jiving with someone today. Find out what’s up and, if possible, fix it and make the office that much better. If it isn’t something you can fix, but that person feels they could do better work somewhere else… LET THEM! If someone knows they could do work better from some other place, that’s awesome and let them run with it. “The place you are free to leave is the place you are free to be.” Personally, if I know I could do better work somewhere else, but I’m not allowed to do my work there, I feel depressed and trapped. This is bad and is heavily against doing great work. Even allowing your employees to work from home “as long as they let ‘some-manager’ know”, isn’t enough. Give your people complete freedom to work where they know they will be able to do their best work and you can expect great things.

Think back to the time when you’ve done your best work.

“But… if everyone isn’t in the office, how will we know work is getting done? How will we work together?”, you might ask. Well, as far as work getting done, that should be rather simple. Is work getting done? If yes, great! If no, try talking to the person who isn’t getting their work done. The thought that being able to physically see someone somehow ensures that work is getting done is absolute rubbish. All you can tell from looking at someone is if they are staring at their screen. Woop-de-fuckin’-do. Your standard for “gets shit done” should involve actually looking at the output of what they do. As for working together, remember the whole massively diminishing returns related to group size? Well, there’s a simple solution to this issue. Firstly, give people a way to communicate asynchronously. Then, trust that your people will do whatever needs to be done in order to do awesome work. I don’t think this is terribly revolutionary, but it seems like people miss this all the time. Let’s say a couple of people are chatting about something. They decide that it would be cool to attack this issue with a whiteboard but, they are both working remotely today. One is at a cafe and the other at home. If you think, at all, that “Well, I guess they can’t collaborate together.”, then you’re a moron. However, there is hope. Since you’ve empowered your people to do whatever they need to do to accomplish awesome work, they might just agree to both come by the office and hack it out in the 40% space tomorrow! That’s like… revolutionary!… or something. I don’t know. Maybe it’s just me, but I think it’s fucking common sense. Let people do whatever is necessary to do awesome work. Get out of their way and trust them to get it done.

Think back to the time when you’ve done your best work.

What if you want to design a physical space to really leverage what I’ve mentioned? Maybe you have the chance to build out a new office space, from scratch, however you’d like. What can you do to help encourage a “collective solitude” type of space. I propose using physical barriers to build small nooks where people can work, yet still feel connected to the primary space. Kind of like a maze. No, not a cubicle farm. (Those can die in a fire.) Instead of crappy cubicle walls or office spaces, how about we borrow another concept from the library. Bookshelves. Go to ikea, buy a bunch of those bookshelves that look like some kind of grid. Fill them with all the books you can. If you don’t have enough books to fill all the space, then they have those little cubble-hole looking box things that fit in the grid. I’m certain that the grid bookshelves are less expensive than cubicle walls or a real wall. I’m also sure that surrounding everyone with awesome books will benefit everybody. Such a setup, using bookshelves to separate spaces into areas where three to four people can sit down and work, will permit people to work without the distraction of people walking around the room. It will also help to dampen noises. Did I mention how great it would be to be surrounded by awesome books? Seriously. Do this.

Think back to the time when you’ve done your best work.

Recap… Give people options in their work spaces. One size does not fit all. Let people match their work environment to their current mindset. Let people work in groups naturally. Don’t force it. Let people do whatever is necessary to do kickass work and then trust them to do so. Make your office into the sort of varied, flexible, awesome space where people actually want to be. Ultimately, it comes down to one simple thing.

Think back to the time when you’ve done your best work.

- ShepBook

Your Text Editor Makes a Difference

2012-04-22T00:00:00-04:00

Your Text Editor Makes a Difference

22 Apr 2012 – Jared Koumentis

“Hello… My name is Jared and I’m a recovering Modal Text Editor addict.”

I’ve used a fair number of text editors in my time, as I’m sure most technologists have. I started with Nano, as that was what Arch Linux examples suggested. As my workload requirements increased, it became clear that Nano wasn’t going to cut it. To top it off, most of the systems I was working on did not include Nano. Hell, they didn’t even include Vim. So, there I was, faced with Vi. I figured Vi/Vim were more common on these older Unix systems I was administrating, so I might as well learn it.

Diving into Vim, I taught myself through various cheatsheets and tutorials I found online. I found it quite nice and it certainly helped my productivity. However, I still found myself longing for some kind of visual control options. I found my way to Gvim, of course. Gvim sated my desiire for some kind of visual control and there I stayed for quite a while. I still had to use Vi/Vim while on remote systems, of course. However, for working on my local files, I enjoyed the options available to me with Gvim.

More recently, I’ve found myself working with code a lot while teaching myself Python and Ruby. Going from working with the occasional config file to working on multiple files for a code project shined some seriously bright light on the rough edges of my current editors. Even with Gvim and all it’s advantages, I still found myself having to pay some attention to the editor. So, my search continued to find something that suited my new requirements. This led me to Gedit.

I had heard of Gedit before, of course. I just had never given it much use. Basically, it is the Gnome equivalent to Kwrite. I had used both on occasion and found myself going back to them. Tabs for my files and easier management were significant advantages I found. Gedit definitely made my life easier. (Isn’t that what software is supposed to do?) So, I customized my Gedit with a nice dark theme (similar to the one found for TextMate) and got to hacking on my code. Life was good.

Now, as I wrote code more often, I began to think about some of the repetition issues. Mind you, Gedit does have an awesome snippets plugin (like many text editors) and I made significant use of it. However, there was some friction I noticed that I wished my editor could help me out with. For example, when I type in a left parenthesis, I want the matching right parenthesis to appear as well. The same goes for most of the oft used punctuation of code. Gedit did provide some indentation help, however, there was friction there too. It didn’t autoindent when I typed out a block of code, like a for loop or something. I didn’t think much of it, when I first started to learn programming. I would just tab things myself and move on. However, this little, tiny friction point eventually becomes noticeably painful, kind of like getting a blister while hiking.

So off I went, yet again, in search of a new editor. I knew I needed something that was more specifically targetted at writing code. Gvim and Gedit did alright, but they were, first and formost, simple, plain text editors. I looked at some development environments. While their features seemed to solve many of the pain points I experienced with the simple text editors, they introduced a massive amount of bloat that I knew I simply wouldn’t be able to accept.

Now, anyone who’s written much of any Ruby code has probably heard about TextMate. Sounds pretty cool. Problem.. it is only for OSX. I certainly prefer running Linux Mint for my OS and intend on keeping it that way. So, TextMate is out. There are certainly many “tweaks” for Gedit, but it still didn’t achieve the level of polish I hear about from those who use TextMate.

Eventually my search lead me to Sublime Text 2. When I first read about it, I wrote it off. “There’s no way it can be that good. Besides, I really don’t want to pay for a text editor. It certainly can’t be worth the $59.” So, back to Gedit for me, I thought. (I’ll just ignore the pain.)

So, I’m hacking away in Gedit on the Rails Tutorial I found. I come to chapter 3, I believe it was, and I notice this guy keeps pushing for Sublime Text. He keeps suggesting it, subtly but surely. I figure, if this guy is so good with Rails to have written an awesome tutorial, he probably knows what he’s suggesting with Sublime Text. I guess it’s worth checking out. I go download it and fire it up.

At first glance, I find it’s interface to be simple, clean, and yet still beautiful. The default color scheme is a sane, dark theme. Code colors and highlights are simple and clear. “Hmmm…”, I think. “Let’s give this a try.” I start working my way through the tutorial again. That’s when my jaw drops.

Remember those parenthesis (or other paired punctuation)? Suddenly, they are created in pairs and my cursor placed between them! I start typing out my functions and it indents perfectly. It recognizes my statements and indents appropriately. I then decide to pause my study of the Tutorial and learn more about this Sublime Text 2.

I start looking through the documentation, which is pretty dense. I decide, instead, to go find some reviews or suggested usage tips on the Intarwebs. Each thing I discover just adds more to the awesomeness I already know. Here, let me share a few things I love.

Simple Beauty

I know “beauty is in the eye of the beholder” and I’m sure there are plenty of people who prefer light color schemes instead of the dark ones I prefer. Luckily, Sublime Text 2 has that too.

Really Fucking Fast

Seriously. Opens practically instantly. I created a symlink (like “sudo ln -s /home/shepbook/Sublime\ Text\ 2/sublime_text /usr/bin/subl”) and I can start it with my ALT+F2 run command option in Gnome, just by typing in “subl” (of course, one could do this from your terminal as well). Even better, I can open a folder in the same way, like “subl /path/to/folder” and Sublime Text opens it in the left side bar. Great for managing a large project. Oh, and did I mention that even this is really fast… like measured in milliseconds fast.

Magical “GoTo Anything” search

Press CTRL+P and you get this handly little drop down box. Start typing and you can search for any file in your project. It searches for both filenames and complete paths. Then, once you find the file, you can type “@” and it give you a list of all the methods in the file. Need to jump to a line in that file? Some Vim awesomeness has carried over (since it was originally inspired by Vim)… just CTRL+P and then type “:” followed by the line number.

Sublime Package Control

There’s a thing called “Package Control” for Sublime Text and it makes installing plugins and extensions a piece of cake. CTRL+SHIFT+P drops down the “Command Palette”. Type out what you want to do, say “install package” and press enter. It will then pop out a list of packages you can install, which you can text search through, of course.

Git Control

There’s a Git plugin, which you can install with the Package Control. This puppy lets you do all your favorite Git commands from within Sublime Text.

Many More Plugins

There are lots more plugins, which warrent your looking through them. There’s a linter, code completion, word highlights. If you use SFTP a lot, there is a plugin (though, not free) for managing that flawlessly.

Simple Configuration

There are no crazy menus or configuration tools you have to nagivate through, in order to customize Sublime Text 2. Instead, everything is easily configured in simple text files. While some may not consider this “easier”, it is simpler. Coming from an Arch Linux background, this style of configuration management is very, very much welcome.

Give It a Try. You Won’t Regret It.

Hopefully, this article has shown you some things that could make your life better, as well. I know there will be many people who simply don’t want to use Sublime Text, for many different reasons. Top of the list seems to be 1) not open source 2) $59 license fee.

I understand not liking it’s closed source binary ways. This part also put me off. However, I’m not RMS. If something genuinely makes my life and work better, I’ll give it a try. If you have political or ethical issues with this, I really can’t help you there. The advantages I get out of Sublime Text 2 outweigh the disadvantage of it being closed source.

The license fee also seems to put a lot of people off. I was one of those people too, at first… until I gave it a try. Sublime Text 2 offers a free evaluation period, without time or funtionatility limits on the program. The only difference between the unregistered or registered version is that when you save a file on the unregistered version, it will occasionally (rarely, even) pop up a little box and say something to the effect of “please buy a license if you like it”. Honestly, my productivity is significantly improved by Sublime Text 2. I can easily justify paying the $59 license fee. The way I see it, if it saves me even one hour of collective time over the next year, it will have paid for itself, many times over. For me, my time is the most valuable thing I have. If I can spend less time working and do more in that time, then I can spend more time doing other things that matter more to me.

Besides all the time I save by using it, it simply makes coding better. A friend asked me to explain what made Sublime Text 2 so much better or what about it makes me more productive. If the benefits above don’t seem to justify it for you, just give it a try. You’ll be glad you did.

- ShepBook

Comment and Discuss at Hacker News

(I am not in any way associated with Sublime Text nor have I recieved any compensation from them.)

The Laws of Business Success

2012-04-16T00:00:00-04:00

The Laws of Business Success

16 Apr 2012 – Jared Koumentis

I came upon Horstman’s Laws. Certainly worth a read.

I was feeling artsy. This is what came out of it.

I think the Laws apply to more than just management though. I believe they apply to all aspects of business success or even, perhaps, all of life. I’ve added a few things not in Horstman’s Laws but I feel they also apply.

So, what do you think? I hope you enjoyed.

- ShepBook

Quarter Century in the Making

2012-03-25T00:00:00-04:00

Quarter Century in the Making

25 Mar 2012 – Jared Koumentis

Today, as of 7:12pm, I’m officially a quarter of a century old.

That makes me feel… old.

I estimate that about one-third of my useful life is gone, never to be seen again. While it’s true that I may indeed live to be older than 75, I don’t expect to be terribly productive at that age.

All of this is rather depressing, to be honest. So, I’m going to try to focus on some positive things that have happened since the last time I visited this square on my calendar.

Good things that occurred during my 24th year of life:

I married the love of my life.
I switched from focusing on nursing to pursuing my passion of computer systems administration (and, coming soon, programming).
I attended my first tech conference. (Surge 2011)
I’ve met some amazing people, whom I consider mentors.
I’ve learned a great deal about businesses and startups.

All these things are pretty cool, however, looking forward I see some things I need to improve upon.

For example, I’ve come to the realization that being a systems administrator (or “site reliability engineer”, if you prefer the “fancy” title) simply isn’t going to be enough. This is my reason for studying programming. My future depends on being more than just a systems administrator. On the other hand, being just a developer wouldn’t cut it either. The lines between systems operations and software development become fuzzier each day. I believe that sysadmins and devs have to make a choice. This choice separates the merely mediocre from the exceptional. What is this choice? Simple.

Specialization or Generalization

You must choose to specialize or generalize. If you’re a sysadmin, to specialize would mean to delve deeper into the systems you work with and integrate new ones as you find them useful. If you’re a developer, to specialize would mean compiling an ever larger understanding of the languages you work with each day. As new languages appear, you’ll integrate them into your arsenal.

However, to specialize is to destroy your future. While the above examples of specialization may at first glance appear to be broad in spectrum (learning and integrating new systems or languages), their scope is self-limiting. You can only be so broad of a sysadmin or developer.

To generalize is to thrive.

You can choose to specialize and become the best developer or sysadmin you can. However, such a choice will never approach exceptional. The master generalist, what I call a “Full Stack Technologist” (FST), is the future. The FST is a proficient software engineer. The FST is an exceptional systems administrator. I consider the optimal balance between software engineering and systems administration for an FST to be ~40/60. This doesn’t mean the FST is half-assing it in either category. It means that the FST is has a deeper understanding of systems than programming. FSTs are capable of writing production level code, however, their greatest strengths are in debugging. FSTs don’t specialize in programming, so they may never deliver code so beautiful that it brings tears to your eyes, however, given the choice of having either a “Beautiful Code Programmer” or a “Full Stack Technologist” design and write a piece of software for me, I would choose the FST every time. Every. Single. Time. No exceptions.

Why? A Full Stack Technologist is the ultimate generalist. The FST sees and understands all. From the high-level code to the bare metal and everything in between. When things go wrong, this is the person you want at the helm. Better yet, when you prefer things to go right from the start, this is the person you need at the helm.

Do these Full Stack Technologists exist? Yes, though I know of very few. Am I a Full Stack Technologist? Not yet. However, this is my goal. Do I expect to be a Full Stack Technologist by this time next year? Hell no. I do, however, expect myself to have made significant progress toward this goal by this time next year. I have some personal goals that I intend on reaching, and in order to give myself the best chance of achieving them, I don’t intend on talking much about them. While I can’t top every item on my list from this year (you can only marry the love of your life once), I do intend on expanding upon that list and having plenty more to show off next year.

Feel free to join me in this pursuit. Otherwise, stay tuned.

- ShepBook

(P.S. If you want to be a Full Stack Technologist, please, for your own sake, stop calling yourself a “DevOp”. It will only hold you back and you sound rather moronic… “Hi! I’m a DevOp!”)

State of the (Automation) Union

2012-03-21T00:00:00-04:00

State of the (Automation) Union

21 Mar 2012 – Jared Koumentis

This past Tuesday (March 12th), I went to the DevOpsDC meetup. The topic was automation. They had someone from CFEngine and Canonical come in to present their automation toolsets. The organizers represented Chef and Puppet. The idea was a kind of “automation tool thunderdome”. While it wasn’t quite that exciting, I did learn a good bit. Here are my perceptions of the “contenders”.

CFEngine

There were a couple of CFEngine guys there. The one that did the presentation seemed like the seasoned sysadmin type. He told us about how CFEngine evolved, embracing theories and philosophies along the way to growing up. He offered a high level overview of how CFEngine works. This is where the presentation started to falter though. The attendees started to latch on to points of insecurity. Unfortunately, this threw the presenter off kilter to the point where he couldn’t even properly finish his presentation. I’m sure the attendees had legitimate concerns about security, but that would be something to bring up after the presentation, not during. It did seem to revolve around IP authentication which, if true, is horribly foolish. Unfortunately, the presentation degraded into pointlessness after miscommunication and an overwhelming sense of “tear the ‘expert’ down” destroyed it.

Unfortunately for CFEngine, that wasn’t so much what gave me a bad taste about it. What did it for me is when the talk, fairly early on, shifted from “technology and applied theories” to “Look at our big clients”. Whenever a product presentation starts resting on the laurels of its large clientele, instead of the power and superiority of its offering, I tend to tune out and discount it. Perhaps this is just a bias of mine. Sure, some really big banks and organizations use it extensively. That doesn’t mean I want to use it in my infrastructure. To its credit though, CFEngine is really fucking fast. It is written in C, requires no dependencies, and outshines all others I’ve seen, in speed. Unfortunately, speed isn’t everything and there were some security flaws brought up. Personally, I’ve moved on.

Juju

The guy from Canonical definitely had a west coast air about him. A sort of laid back, cocky, cool guy vibe. Totally fits in with my vision of Canonical. He was a developer on the Juju project, so he generally knew his project stuff well. The downside is that he was overwhelmingly a developer. Juju, and consequentially his presentation, is aimed at Ubuntu. Sorry, not just aimed at… but solely for Ubuntu. Of course, this immediately put off the ole’ salty dogs of the Unixes past. Personally, I’ve got no problem with Ubuntu and, if given the choice of which OS is going on my server, it’s my go to distro. However, I know this made the presentation, from a really early point, completely unpalatable to a few attendees.

About the technology side of things. Juju is a completely different take on the whole idea of automation. Really, it’s not about automation. It’s about orchestration. Not really system orchestration though, but service orchestration. Unfortunately, right now, it’s in its early stages. By early, I mean alpha-beta. Would I want it handling my production architecture? Hell no! Would I toy with it in a cluster of virtual machines? Sure, could be fun. Right now, Juju just needs to grow up. Maybe it will have something to show off in a few years. Currently, don’t waste your time.

Puppet

Puppet didn’t really receive a fair shake. Honestly, I didn’t really learn much about it and so, in the interest of fairness, I will not be passing a judgement on it. I know lots of people love it. I know plenty hate it. The overwhelming tone of the presentation did make me feel like it was painful, both the presentation and the use of puppet. Ultimately, I felt like the presenter was actually making a great case for…

Chef

Chef was the final presentation of the night. The presentation had a welcome depth to it, while still maintaining an “overview” feeling to it. My own personal experience with automation has been with Chef, so much of the presentation felt familiar to me.

Chef has the good theory parts of CFEngine with some of the hackiness of Puppet, and a giant bucket of polish. While it is still new and growing, as the presenter pointed out, so much is available for you to do with Chef. The whole of the Ruby language is at your disposal.

Conclusions

As the presentations ended and the meetup came to a close, we were given a proverb that I hold as a tenant of the DevOps movement. “Use what works for you. If the tool fits the job well, you like using it, and it makes your life easier, then use it.” Really, this is all it comes down to, at the end of the night.

My opinion, I’m rolling with Chef any time I need automation. That’s not to say I don’t recognize the others. It’s just what I prefer. Some things are worth pointing out though, about the others. Chef is where it is today, by standing on the shoulders of giants. CFEngine pushed the paradigms that we now see in both Chef and Puppet. Puppet surely influenced Chef, if with nothing but Ruby. Juju is playing it’s own game right now, and it will be interesting to see where it goes. I do believe that, if you couple Juju with something like the “platform as a service” (PaaS), then you will go far. It just isn’t meant for getting into the nitty gritty of a system. It’s much more high level and, really, it just wouldn’t be the right tool for that job.

So, recap…

CFEngine seems great if you have complete and perfect control of your network, you need many more servers (orders of magnitude more) than the average business, and you therefore need the shear speed of well-compiled C.

Juju has too much growing up to do for me to take seriously, right now. It does, however, seem really good at standing up a local wikimedia install on your laptop. Then again, so are my shell scripts.

Puppet seems great if you already know a lot of Puppet stuff or have the willpower to do the hacky work required.

Chef is the go to standard (or should be) of most sysadmins I meet everyday. It has struck a good balance of power and simplicity. If you’re starting out, start here.

- ShepBook

The Art of the Critique

2012-03-18T00:00:00-04:00

The Art of the Critique

18 Mar 2012 – Jared Koumentis

I’ve been working to publish my first “official” article. It’s “official” in that it is meant for my company’s blog of sorts. Having my article edited by someone else was an interesting experience. It’s the first time I’ve had this done. One thing I noticed was a difference in editing styles.

The person who did most of the editing primarily just went about correcting all my little typos and such. That was awesome. Occasionally I would be asked what I meant about something and would be asked for clarification. This was quite awesome as well.

Then there were the people who didn’t do so much editing as they did critiquing. Mind you, I’m cool with critiquing, even if I don’t agree with the critic’s opinion. One thing I noticed was how different critique could feel, even when the critique carried the same underlying message.

When you critique someone’s work, you have options. One way to do it is to say how you disagree with a point and then share what you believe or think to be the correct point. This goes something like, “No, I don’t agree. In fact, I think this is wrong.” and then state your opinion that goes against the original point. While this may fulfill the critic’s desire to critique the work and share a dissenting opinion or point, it doesn’t actually help the writer of the original piece. The writer probably spent a fair bit of time writing out whatever you’ve just critiqued. If you just dissent and never help the writer understand why you are dissenting, how is that helpful? Obviously, you are attempting to share your thoughts with the writer and the whole objective of editing is to create a better end product. So, how was your critique supposed to help the writer produce a better piece?

Another way to critique and dispute a point is to provide the writer with some new information or understanding that he may not have had before. Let’s say you’re critiquing an article and you bring up a point you disagree with, to the writer. Perhaps it goes something like this, “I don’t agree with this particular part here… Let me explain why…” and then share with the writer your reasons for considering it wrong. Yes, this takes more time and effort than simply saying, “I don’t agree. Here’s my opinion instead.” however, the outcome is far more positive.

In my experience, the first editor, doing all the corrections and requests for clarification was simply awesome. There wasn’t much of any input on the content matter, but that’s ok. I didn’t expect that person to do so. The second and third editors are where I noticed the biggest difference in effectiveness. The second editor simple left me frustrated and perhaps even a bit intimidated. I didn’t know what to think or do after discussing about the article. I literally hit a mental block. Then, I talked with the third editor who explained things completely differently. Even though the third editor agreed with the second editor, the way the point was approached was completely different. The fact that there was a detailed and significant explaination for the “why” of the dissenting opinion made the critique successful. When I was finished discussing the article with the third editor, I felt great. My mental block had cleared, I understood “why”, and I even learned a good bit. That evening, after talking with the third editor, I did a massive rewrite of my article. I trimmed out unessential bits and completely rewrote the controversial portion. In fact, with what I learned from the discussion with the third editor, I changed my stance significantly. The third editor’s critique genuinely opened my mind to a different way of thinking.

In the end, this is simply one example from my one experience about editorial critique. Take it or leave it. I do think it outlines some good points, particularly for those who edit the articles of an introvert (like myself). Primarily, if you disagree with a point, don’t just say you disagree and state your opinion. Give a good reason why you disagree. Explain it in detail. Chances are, the person who wrote the article came to the opinion they did after significant thought and hard work. They are going to want a good reason why you disagree with their writing. Give it to them. They still may not agree with your critique, but I guarantee you that they will have more respect for you. In the end, building the best piece possible is the whole point of the editorial process. Keep this in mind and you too can give good, helpful critique.

- ShepBook

A New Home

2012-03-14T00:00:00-04:00

A New Home

13 Mar 2012 – Jared Koumentis

Finally, a blog! I hope to amuse and enlighten you with my writings. No guarantees though. Feel free to keep an eye on things. Improvements will happen on the fly. I test on prod. :P

- ShepBook