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 #
# Compiled source #
# Packages #
# it’s better to unpack these files and commit the raw source
# git has its own built in compression methods
# Logs and databases #
# OS generated files #
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.
alias.lol=log –graph –decorate –pretty=oneline –abbrev-commit
alias.lola=log –graph –decorate –pretty=oneline –abbrev-commit –all
Of course core.excludesfile, user.name, and user.email have to be set but they are depend on which system I am running on.
Got a few really handy debug/development features inside of Catalyst that I have been using lately.
- 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.
- 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.
- 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.
- 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 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
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:
The export path will depend on the install location of ksshaskpass. Try typing:
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
- — 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 will remove the individual entry for a. 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.
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.
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.
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.
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 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:
- Programming: CC2, SICP, the Camel, Design Patterns, Refactoring, K&R, the Dragon Book, The Little Schemer, F&FSE, and if your are really brave the “Art of Computer Programming.”
- Management & Startups: Peopleware Zero to One, The Lean Startup, The Innovators Dilemma, Rework, and MMM.
- Networking: Computer Networking, Computer Networks, Unix Network Programming, and Hacking.
- Hacking: The Basics of Hacking and Penetration Testing, The Art of Intrusion, and Hacking (again.)
- Hacker Culture: The Hacker Crackdown, The Hacker Handbook, the updated Jargon File, Open Sources, Underground, Revolution in the Valley, Dealers of Lightning, Cathedral and the Bazaar, and Stealing the Network.
- Design: The Design of Everyday things,
- Others: If you have any specific technology interests (say Cisco switches or MS SQL Server) find the appropriate user forums for those groups and ask their users which books are MUST reads. One good technology book is better than 10 mediocre books.
- 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…