Brian Parsons

From The Psychology of Computer Programming by Gerald M. Weinberg, this is a great list to have posted in any dev shop.

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4. Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9. Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people—be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

I needed to find an IP address amidst a bunch of random text. I googled and didn't find anything that worked for me the way I needed, so I made my own with awk. I thought I'd put it up here in case someone else could use it:

awk '{match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/); ip = substr($0,RSTART,RLENGTH); print ip}'

So you can pipe anything through this and it will grab the IP (V4) address(es).

Example:

$ ifconfig | awk '{match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/); ip = substr($0,RSTART,RLENGTH); print ip}'

Rackspace has put out a nice infographic highlighting what IT decision makers are looking for as well as what they are concerned about when it comes to cloud.

Rackspace® — Rogue IT, Cloud Lock-In Dominate Cloud Concerns [INFOGRAPHIC]

Cloud Computing is not just a paradigm shift for infrastructure. IT operations, accounting and even staffing structure need to be updated to effectively harness the benefits.

In a previous article I illustrated deploying a multi-terrabyte RAID array in the cloud. That takes just a few minutes these days but it used to take most organizations over a month to provision that much storage through their IT channel. Moving to cloud will allow organizations to reduce and potentially eliminate IT staffing around procurement.

From an accounting standpoint, most IT departments are structured and budgeted around a list of services that they provide: server provisioning, incident management, resource monitoring, web support, database support, and infrastructure. These services to the business typically get rolled up into infrastructure OPEX. Actual integration support is often missed in terms of process, time planning, and accounting.

While some roles can be eliminated, there are new roles that need to be filled. As it gets easier to deploy into the cloud, it is important to put process and authority checks in place to avoid cost overruns and "server creep". Easy deployment allows IT operations to put more focus into integration support. This has given rise to the "DevOps" movement:

In computing, "DevOps" is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT Operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization's goal of rapidly producing software products and services.
~ Wikipedia

Operating successfully in this new environment means adding integration support roles that focus on the interoperability between the infrastructure and applications, both during development and ongoing support. IT staffing needs to shift from hardware support to overall platform management and analysis, taking a consultative approach in building environments in which the organization's products can thrive. This requires gaining understanding and supporting the ecosystem of the business, which for some may require a different skill set than what they have currently.

Adopting a model of having dedicated integration support staff and infrastructure support staff will bring transparency to the true operating costs of the product or application. This increased visibility will allow for better planning for IT decision makers.

While I haven't *knock on wood* had any EBS failures in Amazon's cloud myself, I have heard the horror stories and that makes me uneasy. Another issue with disks in cloud that I do run into a lot is latency. The disk io in many cases is slower to begin with, and random bouts of latency tend to crop up.

I have addressed both of these problems by deploying RAID 10 on my Amazon EC2 instances. It sounds techie but you don't have to be a rocket scientist to do this. If you are managing an EC2 instance you can do it and I have published a script that will get you there in a few steps.

First you need to have the ec2-api-tools installed and working on a machine. This can be a server but you can also do this on your workstation. For Arch Linux users, there is a package in the AUR.

The key to getting those tools working is setting up your environment variables. I use a little script called awsenv.sh like this:

#!/bin/bash

export AWS_USER_ID="0349-01234-09134"
export AWS_ACCESS_KEY_ID="BLAHDEBLAHBLAHBLAH"
export AWS_SECRET_ACCESS_KEY="somecharsthatmeansnothing"
export EC2_PRIVATE_KEY="/path/to/EC2-key.pem"
export EC2_CERT="/path/to/EC2-cert.pem"

Call it with: $ source awsenv.sh

Now you're ready to grab my script from: https://github.com/bparsons/buildec2raid

Once you have the api tools working, using the script is really easy:

Example:

$ ./buildec2raid.sh -s 1024 -z us-east-1a -i i-9i8u7y7y

This example would create a 1TB (terrabyte) array in the us-east-1a availability zone and attach it to instance i-918u7y7y.

The script does the basic RAID math for you. It uses 8 disks but you can change the DISKS variable near the top of the script if you prefer another topology. I really suggest that you use RAID 10. That way you can pull a slow EBS volume out of your array and then replace it without much hassle.

Once the volumes are created and attached to the instance, you log into the instance and initialize the array:

$ mdadm --create -l10 -n8 /dev/md0 /dev/xvdh*

That starts the array up. Then all you have to do is format it. Here is an XFS example:

$ sudo mkfs.xfs -l internal,lazy-count=1,size=128m -d agcount=2 /dev/md0

If you are new to software RAID you will find it helpful to check out the Linux RAID Wiki

Dont forget to add the mountpoint to your /etc/fstab file and create the /etc/mdadm.conf file:

# mdadm --examine --scan > /etc/mdadm.conf