First, have a goal. I initially wanted to make AOL “punters” (apps that kicked other users offline) and malware. I found them interesting. Do you want to program games? websites? Facebook Apps? Apps for OS X?

Once you have the goal, do research on how those apps are made, particularly on the language used, APIs/libraries used, and so on.

When starting, you will be learning a lot of concepts that you will see no use for. If-then statements, variables, etc. You might understand the basic idea of what a variable is, but might wonder – why would I ever use this instead of putting the value in directly? At this stage, it’s important that you remain persistant and just go through the examples/exercises in your book (or those provided by your tutor). I noticed that most people will struggle through the first set of concepts, and then lose interest and quit after seeing that they aren’t doing anything interesting. One day, you’ll be doing something and everything will fall into place. An A-Ha moment.

You’re learning a bunch of stuff that doesn’t really connect with each other. How does printing “Hello World” to the screen eventually become a 3D game? How do I go from a console app to a window app? How does knowing what a variable or constant is translate to a web development project?

It’s a plateau — and I want to stress that this applies to almost anything, not just programming. You begin by learning a lot of stuff, very slowly making progress, and over time you begin to see that you kinda “know” what’s happening behind the scenes of the apps you’re using. After that, learning because easier and quicker. Getting to that level requires persistance.

My Turning Point – Stop Asking “What Should I Code?”

When I first began coding, I had the mentality that I had to “learn how to program” before “making app X” – This is logical but the way I structured in my head was important in impeding my progress. I divided learning how to program and making app X into two separate goals. It was a problem because it migrated me away from the goal of “making app X.” I began asking the wrong question – what should I code to learn how to program?

Instead, I should have been asking – what should I learn next, to reach my goal of making app X? I broke down app X into individual tasks, and then began learning how to do each one. For example, let’s say my goal is to program a game.

If I ask “what should I code to learn how to program?” I will spend a lot of time learning things I might not need anytime soon (or ever), I will get nowhere near reaching my goal, and will become unmotivated and quit before getting there. Instead, I would break down the game into individual tasks (this requires research) and work on learning each one.

Let’s see, I need to figure out how to make a window/draw things on screen. That becomes my new short term goal. I dig deeper and learn that I need to learn the Windows API. I learn that the Windows API is how one draws to the screen. But the Windows API is another thing I need to learn, so that becomes the immediate short term goal. Digging deeper, I realize that the Windows API is just a bunch of functions with some conventions that I need to memorize.

Now my goal is somewhat clearer. I begin reading about the Windows API, making different small apps to make sure I understand what I’m reading. Eventually I am able to draw a window and controls. Great. I still don’t have a game. What’s next? I need to draw graphics. I dig into how it’s done and learn that the Windows API provides a set of functions graphics. I’m familiar with the Win API and so I just begin learning the graphics lib. I make a few dozen apps drawing basic circles, loading bitmap images, etc. Now my goal of making a game is starting to take shape in my head. I can mentally structure how the game will be, minus a few concepts I might not have learned yet.

Persistence.

I’ve been using Firefox since the first public beta, and the one thing always on my wish list was fixing the sluggishness and unbelievable memory consumption (2 GB of RAM?) that results from keeping Firefox open for too long. This is still on my wish list today (almost 2010), and I know it’s unlikely to be fixed. In fact, I’ve realized that – Zen Moment – the ‘patch’ must come from within.

The Mozilla team claim it is a feature and not a bug. Firefox stores pages you’ve been to so that you can go back to them instantly upon hitting the “Back” button. This means that FF’s memory needs grow as you browse the net, and leaving a page doesn’t necessarily mean the page’s memory has been deallocated. It makes sense, but in practice it results in Firefox becoming unresponsive. You can go into about:config and edit hundreds of settings, but I’ve never had any success with any of them in any version of Firefox on any OS. Ever.

I probably don’t use Firefox like the majority of users, and certainly not like the developers intended. For one, I don’t close it. In fact, I’ve never voluntarily closed Firefox in my life (I don’t shut down). I purposely crash it and then re-open it so that it asks me to load up all my previously open tabs. This clears out some memory and restores responsiveness making Firefox useable again.

Why don’t I just close it? Because I usually have a minimum of 50 tabs open across several FF instances, and some of those tabs are actually those “Oops, this is embarrassing…” windows that let you choose what tabs to re-open when you re-run a crashed Firefox. That means some of the tabs hold the potential to open up dozens or even hundreds of more tabs.

I feel relieved when Firefox is unable to restore my tabs. Life starts anew.

I keep tabs open that I intend to go through (never!), and I keep different sets of windows/tabs open depending on what I’m doing. i.e., cooking tabs in one window, work tabs in another, research tabs in another, etc. But this isn’t restricted to Firefox. On my Linux desktop I have 2 displays and 8 virtual desktops, making that 16 workspaces, and they’re usually always full. Since I have the RAM/power to run this setup, it’s smooth… except for Firefox and most other browsers (not Chrome).

On this desktop I worked around the Firefox memory problem by creating multiple profiles and using different profiles for different tasks (one for work, one for multimedia, etc). This also allowed me to crash one without affecting the others. It’s a temporary and crude solution until Firefox natively supports multiple processes like Chrome (see Electrolysis.)

But while there are some workarounds, fixing the technical issue isn’t going to increase productivity much. Having more sites open will probably make things worse. The habit of putting things off for later is inherently the problem. Having many sites/apps open is normal only amongst abnormal people. There’s nothing ‘wrong’ with it, but I don’t feel it’s very efficient, even if it may seem so at the time.

I’m generally disorganized and severely ADD-ed, and so this issue doesn’t only exist digitally. My desk is just as messy as Firefox. I have pieces of paper, napkins and anything else I jotted down notes on. I have unopened snail mail, opened but unchecked mail, and mail that has been checked and separated into 2 piles, those that require a reply and those that are to be trashed. There’s books I’m reading (multiple), and always unsorted pages of ideas/diagrams/blueprints of things I’ll probably never get to.

I’m obviously spreading my attention span thin. Going back to Firefox, if there’s an important piece of news on a page buried beneath other sites, I subconsciously still have “must read that article” somewhere deep in my head. It probably doesn’t result in any noticeable effect on its own, but when multiplied by 100x, the decline in calmness becomes significant enough to kill productivity. It produces a weak feeling of anxiety or overwhelmingness.

To make life easier, I created this vim mapping that will expand <? to <?php and <?? to <?php echo. You may change the abbreviation as you see fit. Simply place this in your .vimrc

inoremap <??    <?php echo  ?><Left><Left><Left>
inoremap <?     <?php  ?><Left><Left><Left>

Re-open vim or type use :source ~/.vimrc to reload the config. Now just type <? or <?? in insert mode.

Copy Files Securely Between Two Machines

I used to always forget the syntax for this, until I realized that the syntax is exactly like the standard cp command. In fact, you can copy files like you normally would using scp, on your local machine. The following are equivalent:

$ cp file file.orig
$ scp file file.orig

Where they differ is, scp lets you copy files over a network, through SSH. Here’s an example:

$ scp contents.txt silver@ssh.domain.com:/tmp

This will copy local file contents.txt to /tmp on the remote machine ssh.domain.com, as user silver. Here are some more examples:

$ scp draft.pdf ssh.domain.com:

(copy draft.pdf to my home dir on remote machine. username is implied to be the same locally and remotely.)

$ scp swine.jpg rex@ssh.domain.com

(read: This will copy swine.jpg to local machine as a file named rex@ssh.domain.com. To make it go remote, append a : to the address, like above)

scp supports, among other things, compression (-C) and recursive copying of directories (-r).

$ scp -rC code/ ssh.domain.com:/archive/code_02032009

Trying to copy to a directory you don’t have permission to (/usr etc) will fail.

Don’t Get Lost Jumping To and Fro Between Directories

You can use cd - to jump to the previous (NOT parent) dir. For example:

kiwi@localhost: ~ $ cd /usr/local/share
kiwi@localhost: /usr/local/share $ cd -
/home/kiwi
kiwi@localhost: ~ $ cd -
/usr/local/share
kiwi@localhost: /usr/local/share $

Another way is using pushd/popd – A Last In First Out (LIFO) stack of dirs.

kiwi@localhost: ~ $ pushd /usr/local/share/
/usr/local/share ~

pushd is like cd but keeps note of the current dir before cd’ing into a new one. The stack of dirs is listed every time you invoke pushd (the “/usr/local/share ~” output you see above.)

kiwi@localhost: /usr/local/share $ pushd /
/ /usr/local/share ~

Stack is ordered left to right, latest push first. If we pop the first dir off:

kiwi@localhost: / $ popd
/usr/local/share /tmp ~
kiwi@localhost: /usr/local/share $

We’re back in the share dir. We can keep popping until there’s nothing left (throws an error):

kiwi@localhost: /usr/local/share $ popd
/tmp ~
kiwi@localhost: /tmp $ pushd /lib
/lib /tmp ~
kiwi@localhost: /lib $ popd
/tmp ~
kiwi@localhost: /tmp $ popd
~
kiwi@localhost: ~ $ popd
bash: popd: directory stack empty

Working with Long Lines

No need for more Bash shortcut cheat sheets, but here are some useful ones to help you work with long lines.

You can jump to the start & end of a line using CTRL+a & CTRL+e respectively. Example (* is the cursor):

kiwi@localhost: ~ $ echo al the ducks are swimming in the w*

and you want to fix the first word. You can hop to the beginning of the line with CTRL+a:

kiwi@localhost: ~ $ *echo al the ducks are swimming in the w

and now you can jump to the end of the misspelled word “al” using CTRL+Right twice to correct it:

kiwi@localhost: ~ $ echo all*the ducks are swimming in the w

Now ctrl+e to jump to the end of line:

kiwi@localhost: ~ $ echo all the ducks are swimming in the w*

Instead of backspacing every character, use ALT+Backspace to backspace entire words. You can also delete all or part of a line using CTRL+u combo. It deletes everything before the cursor. Likewise, CTRL+k wipes out everything after the cursor. I’ve developed a habit of using CTRL+e CTRL+k to delete lines.

Bash has a lot of ALT commands that let you move and manipulate words. ALT+l and ALT+u will make a word in front of the cursor lowercase or uppercase, for example. A neat one I don’t think I ever used is ALT+\ It pulls everything after the cursor left to the first non-whitespace character. Here’s an example, * is the cursor:

BEFORE:

$ my     spacebar is    *sticky

AFTER (ALT+\):

$ my     spacebar issticky

Avoid Retyping Commands & Arguments

ESC + . is very useful. Escape followed by a period will output the argument you sent to your last Bash command. Command calls themselves are outputted if they were invoked without any arguments (popd, ls, etc).

Example, unzipping a file and moving the archive to /tmp:

$ unzip archive-with-a-long-ambiguous-name-03092009-5960-1.2.5.zip
$ mv archive-with-a-long-ambiguous-name-03092009-5960-1.2.5.zip /tmp

In the mv command, the archive name was outputted by pressing ESC+. (full command being mv (ESC+.) /tmp) There was no need to type the long archive name twice.

The argument is taken from your bash history. You can keep invoking ESC+. to cycle back through all your recent command arguments. (history -c to clear)

Try not to forget this; You’ll naturally find plenty of uses for it.

Another way to avoid re-typing commands is CTRL+R. It will initiate a search of your command history. Begin typing, and watch Bash try to complete your command from previous ones you entered.

Command Getting Too Big? Send it to your Editor

Sometimes you begin writing what you think will be a simple command, only to realize that it has grown too complex for the command line, and you wish you were in your text editor.

First make sure your default editor is set. This is either in $EDITOR (export EDITOR=/usr/local/bin/vim) or elsewhere depending on the distro.

Use “fc” to open the last executed command in your editor:

ls -paul --sort=size
... ls output ...
fc

Now the ls line will be open in your editor. But what if you hadn’t executed the command yet? No problem. You’re sending off an email, but quickly realize that the command line isn’t ideal for everything:

echo -e "Dear Santa, \n\n\tIt has become evident that your fat ass is contributing to Global Warming, primarily due to the large quantity of coal you distribute annually. We hereby

No matter where you are on the line, hit CTRL+x, CTRL+e to invoke your editor, which now contains what you were typing on the cmd line.

I always find myself wanting to finish a command in vim, but unwilling to type the first few lines over, especially when I’m trying to write a for loop or any ugly multiline Bash code.

IMPORTANT: Whatever you type in your editor is executed automatically after you quit the editor.

Multiple Commands on a Single Line

There are a number of ways to piece together commands (||, pipes, etc), depending on your need, but sometimes, you just commands executed consecutively. You can use ; or &&.

semicolon (;) vs AND (&&): The semicolon will run through each command consecutively, whereas && is a little smarter, and will not continue if a command does not end successfully (return 0 – you can check the return value of the last app ran with echo $?).

&& is generally safer. i.e., ./configure && make (&& sudo make install)

AND

$ cp bogus && echo "** copied"
cp: missing destination file operand after `bogus'
Try `cp --help' for more information.

SEMICOLON;

cp bogus; echo "** copied... or did I? tun tun tunnn!"
cp: missing destination file operand after `bogus'
Try `cp --help' for more information.
** copied... or did I? tun tun tunnn!

Convert between DOS and UNIX ASCII files

Sometimes you get a text file that has weird ^M characters in it. These are due to a difference in how Unix and Windows systems end lines. You can convert between these formats using unix2dos or todos and dos2unix or fromdos.

$ mkdir /tmp/rcfl
$ cd /tmp/rcfl
$ echo -e "Justa Lonely\nASCII File" > out
$ file out
out: ASCII text
$ todos out
$ file out
out: ASCII text, with CRLF line terminators
$ vim out # notice [dos] flag in status bar, quit :q!
$ fromdos out
$ file out
out: ASCII text

Background Processes

Have a little more control over your apps.

Stop Right Thurr
When a program is running in the foreground, you no longer have access to the command line. An example is ‘tail -f’ or ‘ruby script/server’

You can have a running process pause for a sec with CTRL+z.
Do your dirty work and then bring the app back to the foreground with fg.
To list the processes you have paused, use jobs

$ tail -f useful.log
00:00:50 User did something that was log-worthy
00:00:56 User did something that was log-worthy
00:00:57 User did something that was log-worthy

# (press CTRL+z)
[1]+  Stopped                 tail -f useful.log

$ echo "look ma, I can type"
look ma, I can type

$ fg
tail -f useful.log

# (press CTRL+z)
[1]+  Stopped                 tail -f useful.log

$ tail -f blah.tmp

# (press CTRL+z)
[2]+  Stopped                 tail -f blah.tmp

$ jobs
[1]-  Stopped                 tail -f useful.log
[2]+  Stopped                 tail -f blah.tmp
$ fg 1
(process [2] continues)

In the Background

You can have a process start in the background by appending to it a &.
and bring this to the foreground using fg [#].
As before, jobs will list background processes, but with status Running instead of Stopped.

Programs running in the background will still output to stdout, which means they’ll make the shell ugly. So if you plan on using them, think about redirecting the output.

Bash Redirection

Some things are mentioned on nearly every ‘bash tips’ page — like redirecting output. Here are the basics. We’re concerned with 2 I/O streams: STDOUT and STDERR. STDOUT has a value of 1, and it is the screen. If a program writes to stdout, that text is shown in the console. Errors are sent through a different stream, stderr, which has a value of 2. Value 0 is stdin, used for user input. The technical details aren’t important. Just remember that 1 is screen and 2 is error.

There’s a number of ways to redirect output:

$ echo "asdfasdf" 1> /tmp/asdf.txt # overwrite existing file
$ echo "asdfasdf" > /tmp/asdf.txt # (same, 1 is default, optional)
$
$ echo "32452345" >> /tmp/asdf.txt # append to end of existing file*
$ echo "wash the dishes" > /dev/null # just ignore output
$ echo "wash the dishes" 2> /dev/null # just ignore errors
$
$ more 1> /dev/null # error still shown
$ more 2> /dev/null # nothing shown
$ more &> /dev/null # nothing shown
$
$ more 2>| /dev/null # silence errors
$ more >| /tmp/more.txt # save output to file
$
$ more 1> /tmp/more.txt 2>&1 # redirect stdout to file and redirect stderr to stdout (same file)
$ more 2> /tmp/more.txt 1>&2 # have stdout follow stderr to file

To redirect output to a file & screen, use tee

$ echo "dont forget the milk" | tee /tmp/toforget.txt

More a more extensive guide on redirection, see Bash IO Redirection or some of the External Links below.

Art of teh Alias

I use a lot of aliases. Here are a few:

# I use these a lot. Can also have aptupdate, aptremove etc...
alias aptinstall='sudo apt-get install'
alias aptsearch='apt-cache search'
alias suvim='sudo vim'

# Aliasing command names. To use original commands, you'd need to specify absolute path.
alias a2restart='sudo apache2ctl restart'
alias gem='sudo gem'
alias checkinstall='sudo checkinstall'

# I used these to workaround the infamous FF memory leak (ugly)
# alias swapoff='sudo swapoff'
# alias swapon='sudo swapon'

# Going places. This + ssh keypair
alias macbookshell='ssh 192.168.1.17'
alias workshell='ssh meh@ssh.domain.com'

# Pretty output. (--group-directories-first might not work on your system).
alias lsf='ls -hAlF --group-directories-first --color=always --time-style=+" %m/%d/%y %I:%M %p "'

# List only directories
alias lsd='ls -d */'

# I'm a measly human!
alias free="free -m"

# 'gimme x' is equivalent to 'sudo chown me.me x'
# alias gimme="ME6=`whoami` && sudo \"chown $ME6.$ME6\""

# Usage: nullminate bloated-file.log
alias nullminate="cat /dev/null > "

# Search contents of an entire dir. Usage: scan "PESKY_VARIABLE ?=" project-123/
alias scan="grep -Rin --color"

These should go in a ~/.bash_aliases file and invoked from within your user conf (.bashrc?)

External links (related):

• Working more productively with bash 2.x/3.x
• Getting Started with BASH
• Bash Tips & Tricks
• 10 Tips for Writing Efficient Bash Scripts
• Best Tips & Trips for Bash
• Bash Shell Shortcuts
• Bashish
• Writing Robust Shell Scripts

“AOL System Msg: Your screen name (mrEman) is now signed into AOL(R) Instant Messenger (TM) in 2 locations. Click here for more information.”

To use, paste code in file, save file as blockaolsystemmsg.pl in ~/.purple/plugins/ and then open (or re-open) Pidgin and go to Tools -> Plugins (or press CTRL+U), and enable “Block AOLSystemMsg.” That should be it!

If you’re having any trouble, try going to Help -> Debug to open up Pidgin’s debug console.

#!/usr/bin/perl
# BlockAOLSystemMsg plugin tested on Pidgin 2.5.5. Put in ~/.purple/plugins/ and enable
use Purple;
our $target = 'AOL System Msg'; # case-insensitive
our $plugin_name = 'Block AOLSystemMsg'; 

%PLUGIN_INFO = (
  perl_api_version => 2,
  name => $plugin_name,
  version => "0.1",
  summary => "Blocks the screen name 'AOL System Msg'",
  description => "Ignore annoying 'your SN has signed on at 2 locations' AIM message",
  author => "Isam ",
  url => "http://biodegradablegeek.com",
  load => "plugin_load",
  unload => "plugin_unload"
);

sub loginfo { Purple::Debug::info($plugin_name, " @_\n"); }
sub minimize {
  my $r = lc($_[0]);
  $r =~ s/ //g;
  return $r;
}

sub plugin_init { return %PLUGIN_INFO; }

sub plugin_load {
  my $plugin = shift;
  $target = minimize($target);
  loginfo("Sight set on '$target'");
  Purple::Signal::connect(Purple::Conversations::get_handle(),
                          'receiving-im-msg', $plugin, \&callback, '');
}

sub plugin_unload {
  my $plugin = shift;
  loginfo('Block AOLSystemMsg Unloaded.');
}

sub callback {
  my ($acc, $sender, $msg, $flags) = @_;
  if (minimize($sender) eq $target) {
    loginfo("(BLOCKED) <$sender> $msg");
    return 1
  };
}

update: Fixed the botched code. Thanks.

They are not in any specific order.

Glass or Plexiglas

Anything Expo markers can write on may be used as a board surface. This means a piece of glass, or acrylic glass (Plexiglas), placed over a bright white surface it (i.e., a wall or table). Glass actually works pretty well in terms of eligibility and clean up, but it’s heavy, has sharp edges and cannot be drilled into (easily). It’s also not cheap.

Plexiglas works well, but I heard some dry erase Expo markers have problems coming off. Research this before trying Plexiglas. Never use Acetone to clean Plexiglas (or any plastic).

Plexiglas might be a hassle to cut. Sawing at a high speed, be it power or manual, might cause the edge to melt and stick back together between each cut. It’s usually cut underwater ( don’t try putting a power saw in your bathtub).

What I did was use a regular hack saw, and had my friend shoot the area I was sawing with a water gun to cool it between each cut. A water gun.

Both glass and plexiglass have the advantage of letting you make overlays (assuming they are translucent). You can put anything behind this board, as opposed to having an all white surface. Some examples I’ve seen are adding templates like a blank calendar or checklist behind the glass.

If you put some work into it, this can be a nice, cheap setup.

Chalkboard or Chalkpaper

Chalkboards are cheaper than whiteboards, and even cheaper if you go the DIY route and make one using chalk paper. Chalk paper is basically a rough surface you can buy in rolls, which can be written on using standard chalk. Which means.. hopscotch in the office!

Chalkboards have great contrast, and chalk is dirt cheap compared to dry/wet erase markers (unless you steal those from your local college). The problem, and it’s a big one, is chalk dust. Chalk dust in a small room or office make this route unacceptable for most people. There is “anti-dust” / dust-free chalk, but dust can still be a problem if you don’t have good ventilation.

Paper Whiteboard, or Just Paper

Paper. Big paper. There exists huge books of pages that you hang up on the wall, meant to act as a huge Post-It book. I’ve seen these sold at Michael’s. An alternative is to just hang up a big sketch book, but that might get expensive. Paper has plenty of advantages…

You can write on a page using a pen, pencil, markers, crayons, blood etc. It’s flexible and mobile; You can detach papers for storage or to just generally move around, tear in two, etc. Clean up is as easy as curling up a huge piece of paper and shooting a basket.

The cons? Erasing is a nuisance (and only possible if you use a pencil or erasable pen), and the entire thing is meant to be disposable, making this a a recurring expense. This might mean you will end up squeezing as much content on each page as you can to save money.

I’ve seen “paper whiteboards” at IKEA – but with a short stand, designed for children. You get far less cool points hanging up paper than you would having a real (looking) whiteboard in your house.

DIY Digital / Touch Whiteboard

Expensive from scratch, but you might be able to use what you have around the house to hack up a nice digital whiteboard; One great example is the Wiimote Whiteboard:

If you can find tileboard, I suggest using that instead. It’s cheap and it works well. You can probably cover an entire wall for $20. These alternative methods are OK, and in some cases might even be great, but they’re no match for a ‘real’ whiteboard, or one made of tileboard.

* Post-It Wall pic by RainBowCookee

More details and the vim config itself here

I recommend turning backups on if you have them off. I personally hate having the ~ files all over my OS, so I keep them along with the .swp files in 1 backup dir in ~/.vim/

The programming language skeleton stuff will detect what files you are editing and change options in vim by inheriting the specified files which I put in ~/.vim/skeletons and ~/.vim/inherit.

The skeletons are automatically inserted in new files that vim is aware of. For example, in my own config, I have ~/.vim/inherit/c which has all the usual includes and int main() code. When I make a new C file (“gvim hello.c”), the new file begins with the skeleton code already present. Neat huh?

The inherit files can be used to set specific options for each language. This can mean different bindings, whitespace options, themes, etc depending on what language you’re working with, automatically.

See the vim page

What options have helped you the most?

Jekyll tackles all the nuisances involved in creating static pages (I used to add just enough PHP to make a layout). It works by running your prototype through some parsers and outputs plain static HTML/XML (RSS feeds) etc. It’s perfect for lightweight sites that would be impractical on Wordpress, like a few static pages of information, landing pages, portfolio/resume pages, and parked domains.

Git takes care of keeping your development (local) and production (remote) environments synced. Git might be a little confusing if you’re learning it with the mindset that it works like Subversion.

I’ll update this post when the guide is done. For now, the following will assume you’re familiar with Jekyll (or at least have an empty file in the prototype directory) and git. This Bash script simplifies creating the remote git repository:

** please read through the code and make sure you know what this does, and what you’re doing. As of now, this is bias towards my own Apache/vhost setup. It’s trivial to edit for your specific needs. You’re using this at your own risk.

(direct link – repogen.sh)

#!/bin/sh
# 
# 04/01/2009 | http://biodegradablegeek.com | GPL 
# 
# You should be in site (NOT public) root (be in same dir as public/ log/ etc)
# proto/ is created and will house the jekyll prototype
# public/ will be the generated static site
# the public/ folder will be REMOVED and regenerated on every push
# 
 
if [ -z "$1" ]; then
  echo "Usage: ./repogen.sh domain.comn"
  exit
fi
 
# optional. will make it easier to copy/paste cmd to clone repo 
SSHURL="ssh.domain.com"
URL="$1"
 
echo "** creating tmp repo"
mkdir proto
cd proto
git init 
touch INITIAL
git add INITIAL
git commit -a -m "Initial Commit"
 
echo "** creating bare repo"
cd ..
git clone --bare proto proto.git
mv proto proto.old
git clone proto.git
rm -rf proto.old
 
echo "** generating hook"
HOOK=proto.git/hooks/post-update
 
mv $HOOK /tmp
echo '#!/bin/sh' >> $HOOK
echo '# To enable this hook, make this file executable by "chmod +x post-update".' >> $HOOK
echo '#exec git-update-server-info' >> $HOOK
echo '' >> $HOOK
echo '' >> $HOOK
echo 'URL='"$URL" >> $HOOK
echo 'PROTO="/home/$USER/www/$URL/proto"' >> $HOOK
echo 'PUBLIC="/home/$USER/www/$URL/public"' >> $HOOK
echo  '' >> $HOOK
echo 'export GIT_DIR="$PROTO/.git"' >> $HOOK
echo 'pushd $PROTO > /dev/null' >> $HOOK
echo 'git pull' >> $HOOK
echo 'popd > /dev/null' >> $HOOK
echo '' >> $HOOK
echo "echo -----------------------------" >> $HOOK
echo "echo '** Pushing changes to '$URL" >> $HOOK
echo "echo '** Moving current public to /tmp'" >> $HOOK
echo 'mv "$PUBLIC" "/tmp/'$URL'public-`date '+%m%d%Y'`"' >> $HOOK
echo 'echo "** Generating new public"' >> $HOOK
echo 'jekyll "$PROTO" "$PUBLIC"' >> $HOOK
 
echo "** enabling hook"
chmod a+x $HOOK 
 
echo "** clone repo on local machina. example:"
echo "git clone ssh://$USER@$SSHURL/~$USER/www/$SSHURL/proto.git"

Usage

Your site structure might be different. repogen.sh is made by pasting the above code in a new file, and then chmod a+x to make it executable. This should be done on the remote server.

cd www/domain.com/
 
ls
public/ private/ log/ cgi-bin/
 
./repogen.sh domain.com

Now on your local machine, clone the new repo, move your files in, and push:

git clone ssh://[username]@ssh.domain.com/~[username]/www/domain.com/proto.git
cd proto/
cat "hello, world" > index.htm
git add index.htm
git commit -a -m 'first local commit'
git push

After you push your changes, the post-update hook will delete the public/ directory (the root of the site). This dir and its contents are automatically generated and will get wiped out on EVERY push. Keep this in mind. All your changes and content should reside in proto/.

The proto/ repo will pull in the new changes, and then Jekyll will be invoked to generate the updated site in public/ from the prototype.

Should you need to edit it, the post-update hook is in the bare git repo (proto.git/hooks/)

Thanks to the authors in the posts below for sharing ideas. I first read this git method on dmiessler’s site.

Resources:
dmiessler.com – using git to maintain static pages
toroid.org – using git to manage a web site
Jekyll @ GitHub
git info
more git info

For programming, and the way I use my desktop (gnome+compiz), having multiple screens is much more productive than one big screen because I hate minimizing and dragging windows. If I’m coding in rails for example, I can have my editor maximized in one screen, and a reference window or a `tail -f file.log` maximized in the other screen. With a big monitor I would need to manually resize each window or depend on my window managers cascade feature, which requires some manual resizing as well.

For coding or writing, a killer setup would be having two or three widescreen displays setup vertically side-by-side. I noticed I only look at 3/4th of the screen real estate when I’m coding, and when I hack or write, I generally prefer having one long narrow window (off topic, but I always exceed 80 chars per line). Widescreen wasn’t made for coding anyway.

When it comes to (photo) editing, whether you’re using 1 or 2 monitors, widescreen is a must. Many people complain that Gimp doesn’t support MDI (Multiple Document Interface: Having multiple windows in a container, like Photoshop or AOL), but I noticed that Photoshop on Mac doesn’t have MDI either, and I finally began Learning to Love the Gimp Interface. I can edit a picture full screen in one monitor, while I have my entire toolset open on another screen. I can also do all my editing in one screen and have tutorials or references on another display.

Taskbars on each screen are also separated, so that apps open in one desktop don’t show up on the taskbar of another desktop (tweakable). This simplifies the taskbar and makes it quicker to find what you have minimized. No more 256 pixel thick taskbars.

I used to think having a split/gap between screens was annoying, but it naturally segregates the workspace. I can banish windows I don’t care about to ‘the other’ screen and focus without distractions on my main desktop. It’s sorta like the ADHD plugin for compiz. I can also switch my attention to make which ever monitor I want to be my “main display.” This brings us to another huge advantage a multi-monitor setup has over a huge single display.

You can physically move each screen around independently, which is great when you’re working in teams (i.e., you wanna demo something) or you just have people over. Just last night I had a basketball game on my 2nd display tilted so my bro can watch (neither of us have cable) while I did my thing in ‘my own’ desktop.

With Devilspie, you can probably configure yourself a pretty nice setup for a big monitor, but if you don’t plan on doing much hacking, dual screens are naturally more productive in OS X and Linux. I noticed Windows XP has problems with dual screen, i.e., the taskbar doesn’t go across both monitors, and the cursor moves off screen and “breaks” into other desktops while you’re in a game. Very annoying, but Vista or Windows 7 might not exhibit these problems, and there are workarounds in XP.

A huge benefit is the massive amount of information you learn and get accustomed to in a short period of time. There’s no way to download O’reilly PDFs into your brain just yet, but grokking source code written by those much more experienced than you is one of the fastest ways to see and practice everything you’re been learning in theory (books, sites, classes).

It’s certainly overwhelming to jump head first into a huge app trying to understand every line. I think it’s common for people to open up some code, read it for a few minutes and then never touch it again because they don’t understand it. This was the case with me when I began programming. Here are some ways i used to justify putting off the need to read third party code.

Their code style didn’t suit my taste, i.e., they add the opening curly bracket under the function definition, and I would find myself changing their brackets and formatting more than I spent time actually looking at the logic.

I told myself I would learn much more by re-inventing the wheel, or have more control over my app if I built it from scratch. This is only partial true, but the cons outweight the pros. Reinventing the wheel means diviating from writing program logic and having to learn something that might not even remotely be related to the project I intended to start or finish. Here’s an example that used to be common.

I would happily hack away and then realize that I need a string library (I <3 C). At this point I could have downloaded one, and continued hacking at my app. But instead I would start a new project aimed at writing an efficient string library. Before I knew it, I’m hours into my string lib and totally abandoned my main project. I usually  anyway. The funny thing is that sometimes I’ll just give up and use a third party lib, but most of the time I just ended up scrapping both projects. What a waste of time.

Everyone has their own way of learning other people’s code. I found that what works best for me is to download an app and just browse the source indifferently. It’s not good, it’s not bad, it’s not ugly or inefficient or godly. I just try to get a basic idea of where everything is, what plugins are being used, etc. Layout stuff is in this general area, settings here, plugins are all in there, etc. This step is probably useless and I only do it as a guilt-free way to avoid working for 10 minutes. Or, maybe it does help.

Then I begin by setting up the environment. Put in my DB settings, make sure I have all the requirements installed, etc. Logs are your best lead at this point. I usually open up a fullscreen console and tail -f the log file(s), then watch them like a hawk every time you shift a pixel in the code. It’s not as tedious as it sounds.

Another thing that helps is knowing the language/framework the code is written in. You should know at least how to read the language – though if you’re dedicated, I’m sure you can muddle through with a crash course/reference sheet. By knowing the lang/framework, you can find or create some functions to help you debug and examine objects (even just raise object.inspect is great) in detail. You can also examine other aspects of the code. One thing I do early on is rake routes > ROUTES. This saves all the routes to a file which I can glance at if necessary. And rake routes takes forever on my ancient machine.

After this, the code is compiled/started and I’m ready when I can interact with it live. Now I begin actually reading the code. If I have a specific update I want to make, be it adding a new feature, fixing a bug, or seeing how something works, I work backwards from the live app tracing everything going on around the component I’d like to edit/update.

This is not easy, not quick, and very error prone when you’re making updates. Things breaking == You learning, and all you need to do is be persistent. It’s like reading a calculus book. Nothing will make sense until you turn over the page and see how the problems and answers are laid out, and begin doing them on your own. It’s a great feeling when 2-3 days later you realize that you have a pretty good view of the app’s design (unless it’s something like the Kernel).

No matter how cryptic the code looks, don’t be turned off. Is there some sort of force that will completely stop you from understanding what the logic says? Can other people look at this code and instantly tell you what it’s doing? (well, they can form a great guess if they have the experience). It’s time consuming but the concepts apply to other things in life. You can understand how to change your oil without knowing how the engine works, or how to make simple CSS/HTML changes to a layout to change the background or font size without knowing every single CSS tag and technique.

define:persistent: Refusing to give up, especially when faced with opposition or difficulty; continuing firmly or steadily

Most of my favorite quotes are about it. It’s unfortunate my memory isn’t very persistent.

Do you have any special techniques/advice for learning to read third party code?