Author: Bobby Rockers

whatever it takes to give away

I have been using Git for basically all my personal projects lately and have found it to be exceedingly powerful.  While the entire system is worth using simply for the content level tracking; the flexability of a fully distributed version control platform lends itself to thinking about software development entirely differently.  That said, it takes a little configuring to get it working (the way I like) on all my development systems.  Below is a random mash of links, config files, settings, and tips that I have had to re-reference while using git.

  • gitolite – Hosting (and managing) your own git central server..  Done forget to ‘git push’ you changes when done.
  • git Repos with gitolite – The gitolite people are not particularly… cuddly.  This is an easier how-to for gitolite.
  • git crash course – git for svn users.
  • git cheat sheet – Huge list of misc. git commands, configuration information, usage, cloning, etc..
  • git push origin master – The command I most often forget when push back from a cloned repository.

Here is my default ~/.gitignore file:

# Desktop Linux #
#################
.*
!.gitignore
*~
.directory

# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so

# Packages #
############
# it’s better to unpack these files and commit the raw source
# git has its own built in compression methods
*.7z
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip

# Logs and databases #
######################
*.log

# OS generated files #
######################
.DS_Store*
ehthumbs.db
Icon?
Thumbs.db

My primary git configuration settings look like this.  The most useful parts are the alias (that not coincidentally look similar to SVN) and the colorized output.

color.ui=auto
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
alias.st=status
alias.ci=commit
alias.br=branch
alias.co=commit
alias.df=diff
alias.dc=diff –cached
alias.lg=log -p
alias.lol=log –graph –decorate –pretty=oneline –abbrev-commit
alias.lola=log –graph –decorate –pretty=oneline –abbrev-commit –all
alias.ls=ls-files

Of course core.excludesfile, user.name, and user.email have to be set but they are depend on which system I am running on.

Proud of the ones I’ve got

Got a few really handy debug/development features inside of Catalyst that I have been using lately.

  1. RenderView‘s dump_info parameter.  Basically when using the default view close handler in Catalyst (i.e. Catalyst::Action::RenderView) you can add ?dump_info=1 to the end of any URL in your application server to get the exception dump.  While this will need to be turned off in any live environment, it is crazy helpful during development or when hunting down a bug in your code.
  2. StackTrace  is Catalyst plug-in (i.e. Catalyst::Plugin::StackTrace) that gives better detailed information to the server during the request process.  You add it to the primary project module library under lib/MyProjectName.pm INSIDE the use Catalyst parameter.
  3. If you are using Template Toolkit for your Catalyst template layouts you can include the following hook as well.  [% USE Dumper(Indent=1) -%]  will allow you to Data::Dumper variables to the browser window for debugging purposes.  After specifying the use statement you can simply [% Dumper.dump(variablename) %] out anything you want to see.  Again, bad for production, but really really good for development.
  4. Finally, one of my favorites; if you run DBIC_TRACE=1 script/myapp_server.pl -r for your development server (instead of the standard script/myapp_server.pl) you get automatic refreshes AND full DBIC traces of your error messages.  Think detailed messages with full function states when your server crashes.  The best part is that you simply don’t use the DBIC_TRAC option on production to remove the functionality when you are live.

as necessary as food to the body

As anyone who has ever meet her will attests, I married WAY WAY out of my league, something I am constantly amazed and grateful for.  Today I am especially grateful for her cooking, specifically my most recent addiction, hummus.  So as a quick post (and to help me find it next time I need it) I thought I would post her receipe.  The following is Heather’s Lemon and Spice hummus.  It is unquestionably the best hummus I have ever had, as can be proven by the fact that it actually gets me to eat large quantities of vegetables in the consumption of it.  Just blend everything listed below.

  • 15oz can of chickpeas
  • 4 Tbsp lemon juice
  • 1/4 cup extra virgin olive oil
  • 2 cloves garlic chopped (or 2 tsp if you buy it pre-chopped)
  • 1/2 tsp sea salt (we really only eat sea salt anymore but the flavor quality REALLY matters in this recipe)
  • 1 tsp cumin
  • 1/2 tsp cayenne pepper
  • parsley to taste

the parents of security

When developing in Unix, on any software project of marginal size, the remote toolkit of choice is always ssh.  Besides being stupidly secure it is also crazy fast and is supported on almost every platform in existence.  The only problem that slowly starts to develop is directly related to how often it is used… password management.  Thankfully ssh has support for key sharing requiring you to only enter you passphrase during the initial login on a given machine.  On KDE there is even a tool for getting your passphrase requested when initially logging in. That said, installing it DOES NOT set it up so here are some basic instructions for getting it working on any current version of Suse.  It even has support for kwallet to store the password (but if you do so remember to has a wallet password AT LEAST as strong as your passphrase or the whole point is mute from a security standpoint.

Start by installing ksshaskpass:

zypper install ksshaskpass

Now, create a file called ssh-add.sh and put it into your .kde4/Autostart directory. It should contain the following:

#!/bin/sh 
export SSH_ASKPASS=/usr/lib64/ssh/ksshaskpass
/usr/bin/ssh-add

The export path will depend on the install location of ksshaskpass. Try typing:

which ksshaskpass

and see what the result is. Make it executable by only your local users. While not really required it is a simply thing that can be done to help make the whole install a little more secure.

chmod 700 ./ssh-add.sh

And if it’s a bad script…

JavaScript has a couple features that I wasn’t aware of until I saw a recent video on Node.js.

  • — splice – A function to pull out a single element from an array.  So [1,2,3,4,5].splice(1,1); will return 2.  Additionally the array will afterwords look like [1,3,4,5].
  • — indexOf – Need to find out what a specific index number for a given value is (basically a reverse index look-up) something like [8,7,6,5,4].indexOf(7); will return a 1.  I actually thought indexOf was a function of the HTML DOM for some reason.
  • — delete – Built in function to delete a specific index of an array.  Something like a=[5,6,7,8]; delete a[0] will remove the individual entry for a[0].  Now depending on environment delete will shorten the array for that element, some environments will simply turn that array element to null effectively blanking out that one entry.

All I must do is find it

The essence of success is that it is never necessary to think of a new idea oneself. It is far better to wait until somebody else does it, and then to copy him in every detail, except his mistakes.
–Aubrey Menen

Two quick things things I wanted to post.  I have used rsync for along time for file backups but generally speaking rysnc is a spectacular tool for efficiently coping files.  Not only does it only transfer the changes between a two files but, it also has a bunch of other useful features.  One I need just recently, a copy command with a progress bar.  So check this out:

rsync -v –progress

Yup, that is it. Simple, clean, efficient, and usable from any scripting interface.

The second thing I wanted to link was an article posted on the Linux Blog related to removing new lines characters from text files.  The post mentions how to due this using tools like tr, awk, perl, sed, and C.  Again, very handy for scripting on Unix systems.

Too remote nor too familiar

Discovered a freakishly use Linux application today that I am already installing on some of my virtual machines.  It is called scponly and functionally what it does is give a user account scp/sftp access to a folder location, under a given user credintials, without actual shell access.  Additionally you can manage the log-in account the same way you do every other account (ala adduser, passwd, chmod, etc.)

Here is a specific example.  Pretend you want to setup sftp access to your apache server (because we all know ftp is terribly insecure.)  Assuming your web root is located at /var/www (example for fedora) you would do the following:

  • Install scponly (yum install scponly)
  • Copy the shell into your allow system shells (which scponly >> /etc/shells)
  • Create a new user (useradd -s /usr/bin/scponly -d /var/www -M sftpUserLogInName)
  • Set user password for scp/sftp sessions (passwd sftpUserLogInName)

Now you can log in remotely using standard ssh to make sure you file transfer is secure.  Directory listing even work under sftp.  Most “quality” ftp clients support sftp (check out fireftp if you use Firefox) so client support is easily available regardless of platform.  The best part, when you want to change permissions or modify the account password you do it with the standard Linux user manager suite, just like every other user on your system.

Lux et Veritas

From the earliest days of software technology, the term hacker has been used to describe someone who was particularly proficient with technology.  While the term “hacker” has come to mean something malicious to those with only a cursory understanding of geek culture, it is still held as a term of high regard among those who know otherwise.  Lately I have gotten the question from students in my IT/IS classes concerning how best to become a “hacker”.  While the question they are asking is not precisely the information they want to know, I have decided to answer the question correctly.

While this may seem like a silly exercise, it actually has a long and storied tradition inside of hacker communities.  There are a number of well known “guides” that have circulated the halls of old Usenet and dusty Jargon files from many years back with contributions from such luminaries as Bruce Parens, Eric S. Raymond, and Larry Wall.  Basically I am going to offer a stupidly basic outline of what I would like to have learned, in the order I would like to have learned it in, to have developed my skill-set (or lack thereof) in the quickest fashion possible.

*One caveat is that I have changed this list 8 times in the last 3 weeks (which is why it has taken so long to post) and added another step just minutes before posting again.  My point is that I will probably continue making updates for a while and I would encourage anyone comments or suggestions on how it can be improved.

  • Step 1: Start by visiting/read these websites, netcasts, mailing lists, IRC forums, & newsgroups.. everyday!  ArsTechnica,  Phrack, SecList, Schneier on Security, OWASP, ITSecurity, cDc, Toms Hardware, HackerNew, and the LiquidMatrix Blog.  Listen to every episode of Security Now!  For extra credit read everything you can handle from the SANS Reading Room.  If you don’t understand what you are reading, Google it!
  • Step 2: The best resources you can possibly have as an IT Professional are OTHER IT Professionals.  This means you need to be part of your local community by networking with other professionals.  Nationally there is ACM, AITP, and IEEE. MORE importantly are your local groups & chapters.  In the Oklahoma City area we have OKC JavaScript Developers Group, OKC LugNuts, Okcruby, DC405, Oklahoma Game Developers, OK InfraGuard, ISSAOKC, and OKCJug, just to name a few.  Join a couple groups and start attending monthly meetings.
  • Step 3: Build your own computer.  Check out the ArsTechnica System Guide to make sure you have compatible hardware that will actually be cost effective and then purchase the parts at PriceWatch (be sure to check the vendor ratings before you buy.)  Yes, you could actually buy a system “kit” from someplace like NewEgg but the value of this exercise is in learning the hows and whys of each component.
  • Step 4: Install a Unix style OS on your newly built system… and/or every other system you can get your hands on.  I recommend either Fedora or Ubuntu to start with as they are the easiest to begin using but in reality any *nix style will work (i.e. FreeBSD, Linux mint, OpenSuse, OpenSolaris, etc.)  No hacker I know lives in Windows (well… unless they are gaming.)  Linux OSes provide access to a system on a level you simply will NEVER get on Windows.  This is partly because of the power of the Unix system model and partly because hackers develop for hackers on Linux/Unix.  After you install your new OS, use it, everyday, as your primary OS.
  • Step 5: Make your own website… from scratch.  Go get a $6.00/month HostMonster account, decide on a domain name, learn FTP, setup an email account, and start making a website!  It is a cheep way to get some direct experience doing many of the most common web task.  Finally, got get a copy of the Lama, Pythonista, or Rails Tutorial and go through the ENTIRE tutorial thus creating your first dynamic website content.
  • Step 6: Continue building your library.  Nobody can know everything there is to know about technology.  Having quick access to information that you have (at the very least) read before is a HUGE help.  Additionally, going through the programming and hacking literature will give you the best hands-on experience necessary to take the next steps.  You should own/have read as many of these as possible:
  • Step 7: Pick a transformative technology and learn how to use it. “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln.   In many ways this is the basic activity that all IS/IT employees do on a daily basis.  Technology solutions have a tendency to be very darwinian.  Therefore, you should start by picking tools that have stood the test of time.  Very few technology resources have lasted longer than 4 or 5 years.  Tools like
  • Step 8: Find an Open Source project that interests you, pick a problem, and fix it.  Meaningful contributions to Open Source projects now rank as more valuable than experience with a fortune 500 company and by volunteering yourself to something used by hundreds or thousands of people, you increase your credibility as a contributor to the community.  Often contributors get their names listed in the software itself (imagine being able to show a prospective employer you name in the Firefox contributors tab.)  It doesn’t have to be software development either, many projects need volunteers to answer forum questions, update documentation, translate it to other languages, or simply test and report bugs.
  • Step 9: …and then teach.  No amount of experience will develop your skills, help you network, or let you enjoy technology more than passing on the things you have learned.  Write articles or blog posts, offer to teach a computer class at your local library, or do mentoring to grade school kids.  Sometimes this step can even turn itself into a decent part-time job.
  • Step 10: Download the Linux From Scratch book and build your very own custom operating system from source code.  You will learn more about how operating systems work than 99.9% of IT professionals do.  Doing your own OS build will change the way you see systems and how to protect them.  The results of a LFS build is not the system itself (you will probably go back to using Fedora shortly after finishing) but that you will NEVER go back to be just a technology user…

KDE vs. Gnome

Great post originally from http://www.illusionary.com/GNOMEvKDE.html but as the site is no longer up I am re-posting it with full credit to its original author.  This “summary” was a surprisingly accurate feel for the overall development process of the two major Linux  Desktop interfaces.   Specifically this was the overall feeling during the KDE 2.x – 3.5 & Gnome 0.0 – wheneverubuntueffectivelytookovertheproject.x time frame.  While these generalizations no longer hold true, they sure make for some entertaining reading to those of us who remember the those days.

KDE

A big room somewhere in Europe with lots of chrome and glass and a great big whiteboard in the front with lots of tiny, neat writing on it. There are about 50 desks, each with headphones and pristine workstations, also with a lot of chrome and glass. The faint sound of classical music permeates the room, accompanying the clicky-click of 50 programmers typing or quietly talking in one of the appropriately assigned meeting areas. (Which of course consist of elegant contemporary white pine coffee tables surrounded by contemporary white pine and fine leather meeting chairs.) Coffee, tea, mineral water and fruit juices are available in the break area.

At the end of the day, *everyone* checks in their code and the project leader does a “make” just to make sure it all compiles cleanly, but it’s mostly only done from tradition anymore since it always compiles cleanly and works flawlessly. When all milestones have been met, and everything has been QA’d, (usually within a day or two of the roadmap that was written up 18 months previous) a new KDE release is packaged up and released to the mirror sites with the appropriate 24-hour delay for distribution before being announced.

KDE developers are generally between the ages of 16 and 25, like art made of lines and squares and the colors white and black. When/if they finally stop taking government subsidies and get around to getting “real jobs,” most of their salary will be taken in taxes so the socialist government can subsidize the care and feeding of the next generation of KDE developers, just like it did for them. A high percentage of KDE developers, during their mandatory 5 years of government military service, crack from their years of cultural dullness and flee Europe to become terrorists for the sheer joy to be found in killing random strangers for no discernible reason.

GNOME

An abandoned warehouse in San Francisco, kitted up as for a rave, electronica playing at 15db louder than “my ears are bleeding and I’m developing an aneurism” volumes and the windows all painted over black so that the strobe and spotlights and lasers can be seen better. Computers, mainly made of whatever stuff has been exchanged for crack or scavenged from dumpsters behind dot-bombs, are scattered around on whatever furniture is available, which also consists of whatever stuff has been exchanged for crack or scavenged from dumpsters behind dot-bombs. There’s no break area, but you may be able to bum a beer (or more likely something harder) off of one of the developers hanging around, and they will probably be too jacked up on X, coke, acid, heroin, ether or all of the above to notice that you’ve taken anything.

Development strategies are generally determined by whatever light show happens to be going on at the moment, when one of the developers will leap up and scream “I WANT IT TO LOOK JUST LIKE THAT” and then straight-arm his laptop against the wall in an hallucinogenic frenzy before vomiting copiously, passing out and falling face-down in the middle of the dance floor. There’s no whiteboard, so developers diagram things out in the puddles of spilt beer, urine and vomit on the floor.

At the end of the day – whenever that is since an equal number of programmers will be passed out at any given time – or really whenever someone happens to think of it (which is rarely), someone might type “make” on some machine somewhere, with mixed results. Generally nothing happens, so he/she shrugs his/her shoulders and wanders off to look for someone who might have more pink/black-striped pills. Once in a great while, generally in the unpleasant time between the come-down from the last thing they took and before whatever it was they took just now comes on fully, someone will tar up a bunch of random files and post it on a website someplace it as the next GNOME release, usually with a reference to some kind of monkey.

GNOME developers rarely live past 25 and prefer “alternative” art – generally stuff made of feces that’s “too edgy” for most people to “understand” or “like.” Core GNOME developers are heavy Ketamine users. The bodies of GNOME developers can often be found in dumpsters or floating face-down in any sufficiently large body of water.

Copyright 2002, Derek Glidden.