First, here is a good tutorial for using Screen:  http://www.linuxjournal.com/article/6340

Screen is great for keeping long running processes running.  This is especially useful if you are ssh'ed into a server.  But, I know people who live in Screen even locally.  Not sure what the benefit is of that.  But, to each his own.

Some Screen Commands

Whenever you see something like "ctrl+a, c", that means "ctrl+a" then press "c".

From the command line:

• screen => Starts screen
• screen -R => (Note that this is run from the command line, not from within screen.)  Re-attach all open screen windows.  This will re-attach you to the sweet processes running in screen.
• screen -ls => Lists the currently running screen sessions.

From within a Screen session:

• ctrl+a, c =>  starts a new screen shell (or window)
  
• ctrl+a, p => go to previous window
• ctrl+a, n => go to next window
• ctrl+<number> => Each of your Screen windows are given a number.  You can navigate to one with this key binding.
  
• ctrl+a, " =>  list all the active screen windows.  use "j" and "k" to navigate up and down the list.  hit enter to choose a window.  may be able to use the up or down arrow.
• ctrl+a, shift+a => rename the screen window.  This is key.  I rename all my active Screen windows to something descriptive, such as "Mongrel Log" for the log file I am tailing.
  
• ctrl+a, k => kill the current window.  This will kill any processes in that window.
  
• ctrl+a, \ => kill all the windows
• ctrl+a, d => detach screen.  This will remove you from screen.  But, all the screen windows you had active (which are running sweet processes) will still be running.

Fix the delete key issue

On my mac, the "delete" key does not delete when in screen.  You need to do this to fix it. On the system from which the screen command will be run, add the following line to the ~/.bashrc file.

alias screen='TERM=screen screen'

Make sure to restart the user's shell session.

.screenrc file

Create one of these in your ~ directory.  Anyone have a really sweet one?  Please share.

I don't have a lot of Screen customizations.  But, the one I must have is this one.  See the image below.

Here is what you need in order to get that:

hardstatus alwayslastline "%{= wk}%H | %-w%{+u r}%n %t%{= wk}%+w%{= wk}"

http://startuplessonslearned.blogspot.com/2008/09/what-does-startup-cto-actually-do.html

So, what is a CTO supposed to be doing all day?  I think Eric Ries, in the above post, sums it up pretty well.

The CTO's primary job is to make sure the company's technology strategy serves its business strategy.

So concise.  So correct.  The key phrase in that statement is "serves its business strategy".  Technology often forgets why it exists.  Why does technology exist?  It exists to serve some function.  If you work for a company, that function is for business.  And, if you are really lucky, that business is transforming the world, and culture (Google, Apple, Twitter, etc.).

He goes on to identify 5 (+1) key skills for a CTO.

• Platform selection and technical design
• Seeing the big picture (in graphic detail)
• Provide options
• Find the 80/20
• Grow technical leaders
• Own the development methodology

Provide options

Some technologists have a tendency just to "decide for you" and give you the "best" option, but that's dangerous. You can't have an honest dialog if one party knows all the answers.

"Some"?  I would say "most" technologists.  Usually, when a technologist says, "That's impossible."  What they really mean to say is "I don't want to do that because I don't know the technology you are talking about, and I kind of think you are an idiot, and by the way, I have this piece of code that I wrote 20 years ago that we should use, and basically, I don't care about the business, I care about Perl."  

Too many technologists only think about technology.  What good is technology if it is not meeting a business need?  Provide options.  Be a collaborator.  Collaboration is the key to honest dialog.  Collaboration builds trust.  So, get out of your cave and start collaborating.  

Find the 80/20

Once I understood what the objective of their feature was for customers, I could sometimes see a way to get 80% of the benefit for 20% of the cost.

Now, we are talking!  Everyone, all up and down the food chain, needs this skill!  

This is of ultimate importance for the CTO.  Why?  Because technology is friggin' expensive.  Because a technology project is never 100% done.  Because technology is never as easy as you think it is.

The key to "getting done" is getting ~80% done.  Then, decide if doing the rest is part of the technical and business strategy.  If the CTO (or an leader for that matter) cannot grasp the 80/20 concept, costs will rise while project timelines increase.  A losing proposition indeed.

Grow technical leaders

By delegating and training, we create a corps of leaders who could step in to provide CTO-like services on demand. And by working together, we created a team whose whole was greater than the sum of its parts.

In other words, the CTO needs to mentor.  To me, this is a no-brainer.  For anyone in leadership, one of their main day to day activities should be to mentor.  ABM (Always be mentoring).  But, I am constantly amazed at how little mentoring is done.  I have found that when I mentor someone, it is always a growing experience for me.  I think I get more out of it than the mentee.  Why?  Teaching something is the best way to learn something.  Plus, you can't BS someone you work with everyday.

Out.

http://gitready.com/

Quick snippets of Git tips and tutorials.

Sprinkle is a software provisioning tool you can use to build remote servers with, after the base operating system has been installed.

http://github.com/crafterm/sprinkle/tree/master

I am going to have to try this out!  It looks really promising.

I have used a number of Cap scripts to do something similar.  But, this solution looks more elegant.

A Ruby based Continuation Integration server.  I have not had a chance to try it yet.  But, this could be an interesting project.

http://integrityapp.com/

If you have not watched it already, go watch the Apple battery video here:

http://www.apple.com/macbookpro/

Prior to watching this video and understanding the reasons for an enclosed battery, it was difficult to understand Apple's decision.  Now, I am going to wait for the new enclosed battery to make its way to the 15" MacBook Pro before purchasing one.  It all just makes sense.

I think this is a great example of how we can get used to something, and think that it is the "correct" way.  But, in reality, the thing you got used to (and thought was the "correct" way) was created because of faulty design, laziness, or the lack of innovation.  

I see this phenomenon a lot in programming.  Some examples might be:

• Premature optimization
• Valuing computer processor time more than developer time
• Writing unreadable clever code because it is "faster"
• Stored procedures and triggers
• Not using an ORM