To Any Place Worth Going

One of the best parts of Unix systems is that fundamentally they are built as development platforms.  The most common text command interface for Unix is call Bash (the Bourne Again Shell)and it is a full blown script-able interface allowing direct interaction with command line programs and giving the user the ability to string together these programs into really powerful applications.  Because of the power of this interface, developers have over many years improved the ability to use it directly as well.  Things like <tab> completion are well known, but how about reverse command searches, built-in text editor mode, and shortcuts galore.  I have been trying to use more and more of this “built-in” bash functionality and so below are some of my favorite shortcuts and functionality.

Shortcuts:

Ctrl + A Go to the beginning of the line you are currently typing on
Ctrl + E Go to the end of the line you are currently typing on
Ctrl + L Clears the Screen, similar to the clear command
Ctrl + U Clears the line before the cursor position. If you are at the end of the line, clears the entire line.  Especially useful when you know you’ve mis-typed a password and want to start again.
Ctrl + K Cut the line after the cursor, inverse of the Ctrl + U
Ctrl + Y Pastes the content from a previous Ctrl + K or Ctrl + U cut.
Ctrl + H Same as backspace
Ctrl + R Search through previously used commands
Ctrl + C Sends SIGINT to whatever you are running (effectively terminating the program.)
Ctrl + D Exit the current shell
Ctrl + Z Puts whatever you are running into a suspended background process. fg restores it.
Ctrl + W Delete the word before the cursor
Ctrl + T Swap the last two characters before the cursor
Alt + T Swap the last two words before the cursor
Alt + F Move cursor forward one word on the current line
Alt + B Move cursor backward one word on the current line
Tab Auto-complete files and folder names (f there is a multiple option match hitting Tab twice will list all possible values.)
Alt + . Paste the previous commands final argument (great for running different commands on the same file path.)

To see a complete list of all bound bash shortcuts you can type

bind -P |less

but you may need to look-up some bash hex character values to understand all of them.  What is more you can actually set bound shortcuts to almost anything you can think of, including actual applications, for example:

$ bind -x ‘”\C-e”‘:firefox.

will launch the Firefox web browser from the command line when you hit Ctrl + e.

Another one of my favorite commands is fc (fix command.) If you simply type

fc

FC will copy your most recent bash history into your preferred editor (vi by default on most systems) and allow you to edit it within the editor.  If you save and exit the editor it will automatically copy it the contents into the bash session and hit enter.  Additionally if you are interested in editing some other history item you can type

fc -l

to get a full history with numbers beside them.  Then type

fc <num>

where<num> is the history number you want to edit.  In a former life my bash terminal and fc was all I needed for most SQL testing.

A Person Wrapped up in Himself

Package building under RPM hasn’t actually changed a whole lot in the last decade.  While I have notes scattered around the website on building and maintaining package repositories; the one part that has changed significantly is the use of git for version control.  Thankfully tagging, archiving, and building packages is pretty simple under git basically consisting of the following three steps:

  • git tag -a 1.1 -m “Version 1.1”
  • git archive –prefix=projectname-1.1/ 1.1 |bzip2 > ~/Temp/projectname-1.1.tar.bz2
  • rpmbuild -tb ~/Temp/projectname-1.1.tar.bz2

The -a option will create a “true” package tag although it will not be signed with a digital key.  Of course the rpmbuild command depends on correctly formatted spec file in the base of your project directory.  Make sure the spec file version and changelog have the same version number as your tag.  FYI for scripting purposes it is good to remember that changelog dates use the following date command format:

date +’%a %b %d %Y’

The reason I mention scripting is because I am working at extending my automated build script for software packages I manage.  Way back in my days at DPS I had developed a bash configuration that would allow me to download, package, and build a piece of software directly from the CVS repository.

When I moved to Cobb Engineering I also changes version control software and started using SVN.  Extending my previous script to supportboth CVS and SVN wasn’t too hard.  Now I have a number of personal projects at home as well as software examples I keep for my students at ITT-Tech; all of which is stored/managed in Git.  The new software package script is almost done but I would really like to be able to update a spec file, changelog, tag, package, and build with one command.

The most useful part of my build script is that is doesn’t require me to spend any time remembering how to use it.  By default is has both auto-complete as well as logical default behaviors.  I just run buildpackage and it will list the available projects that I have ready to build.  If I run buildpackage project it will present me with a list of versions that have already been tagged.  One of these days I will post it publicly but I seriously doubt there is much interest in the broader community as almost everyone who develops at this level seems to already have their own custom build  scripts.

more than you can afford to lose

I honestly don’t know why some links seem more appropriate in a blog; as compared to my freakishly huge bookmark list.

  • Getting Started with NoSQL – I tell my students that much of the support development they do in the future will be on MySQL and much of the new development they do themselves will be with NoSQL.  Good into to CouchDB, my current favorite.
  • Fedora Packing Guidelines for cpanspec – I started writing a script like cpanspec almost 8 years ago, but never finished because the complexity of figuring out CPAN dependencies was taking too much time away from actual development.  This thing is an absolute MUST for Perl developers using RPM based systems.
  • Renaming a Git repository stored in gitolite – You know a technology is a game changer when it not only solves problems you have but solves problems you didn’t even realize were problems.  Git is like that and gitolite is how I manage my git repositories.  After having to do a Google search on this… twice, I figure I better save the link.
  • Moving files from one git repository to another while preserving history – Title says it all.  The only thing to add is that this post includes a link to Linus’ “greatest git merge ever” post, which was not only a cool post (if you a total nut-job computer geek) but started a pretty amazing thread about “cool” git merges.
  • Using git archive – I use something like  git archive –prefix=proname-1.1/ 1.1 |bzip2 > proname-1.1.tar.bz2 to create my deployment packages on Linux. This is a nice document listing examples and use cases for git archive.  This only works if 1.1 is a branch or has been tagged via something like git tag -a 1.1 -m ‘Message about tag.’
  • Telling Linux to ignore a bad part of memory – Is memtest freaking out about some bad memory?  How about simply telling the Linux kernel not to use that chuck?  This modifies the grub options so the Linux kernel knows which part of memory not to use before it actually loads itself up.

not merely necessary to life

After we have fastcgi working for Catalyst, we then need a proxy http service to actually to the page response work.  There are a number of solutions available to handle this but recently I have been messing with nginx.  nginx is a fastcgi compatible web server designed specifically for speed and quickness. While nowhere near as feature complete as Apache, it provides enough functionality to host some very large, vary busy web service companies.

In the interest of total disclosure, a fairly significant portion of the information I am provided I gleaned off an outstanding tutorial by Richard Wallman.  Basically you need to create a new server instance config file for your new nginx application proxy.  Open a text editor as root and create a new file /etc/nginx/config.d/mynewserver.conf and add following:

server {
server_name  app.mysite.org;
# Let’s have a server alias as well

access_log  /var/log/nginx/mysite.access.log;
root   /usr/share/nginx/html;

# Serve static content statically
expires +30d;
location /static {
add_header Cache-control public;
root /usr/share/nginx/html/root/;
}

# We pass the rest to our FastCGI application server
location /  {
# We also set some headers to prevent proxies
add_header Pragma “no-cache”;
add_header Cache-control “no-cache, must-revalidate, private, no-store”;
expires -1s;

# Where our FastCGI app server is listening
fastcgi_pass   127.0.0.1:8100;

include /etc/nginx/fastcgi_params;
fastcgi_param   SCRIPT_NAME     /;
fastcgi_param   PATH_INFO       $fastcgi_script_name;
}
}

If the line with fastcgi_pass is the same as the fastcgi ip address then you should be in good shape.  The other thing to notice about the configuration above tis the location /static this forwards requests for static content directly through nginx without using cgi.  This creates less overhead and faster responses for things like images, css, and javascript.

More later, my kids are in the middle of a mean rendition of chop sticks.

Fear Lying Upon a Pallet

Almost all of of my recent work has been using NoSQL solutions, my favorite of which is Couchdb.  Easily the best feature of Couch is the RESTful JSON API that it uses to provide data.  Because you get your DB queries back to you directly as JavaScript objects, you don’t have to worry about application servers or middle tier systems for N-Tier development.  This is HUGE and make the whole web development (and given that most mobile applications are actually web apps) must cleaner, faster, and more functional for the end user.

Couch does have a couple weaknesses.  The one that has been giving me the most headaches is the lack of documentation for their parameters that the server can handle as part of the JSON View (map/reduce) phase. So here are a number that I have found useful over the last few months.  I will update this list as I find more.

  • key=abc The most commonly passed option to a given couchdb view.  This provides a way to select a single unique (well, I guess probably unique) key for a given view.  That said, view keys DON’T HAVE TO BE UNIQUE in couchdb.  Meaning, that if more than one result returns with abc this will also return those multiple results.
  • keys=[abc,123,ACC] A JSON encoded list of keys to use in a given map/reduce function.  Basically the same as above but without the need to call multiple network queries.
  • startkey=abc Used with endkey=abC to provide reange selection for a given view.  startkey will accept (as valid input) anything that would be valid in a standard couchdb view key, even JSON objects.  So think startkey=[a,]&endkey=[a,{}] to get a range of all keys=[a,somethingElse].
  • endkey=abC Counterpart of startkey, see the above reference.  One thing to note, it is generally better to specify another object and the end of a range if you want to inclusively select a range.  So {} is a better end range value than ZZZZZZZZ is.
  • limit=100 Select on the first N number of results.  This parameter is particularly useful for paginated return results (like “showing 1-100 of 399.)  Reduces network bandwidth for a given request.  Because map/reduce functions are cached upon request, the response time for the server isn’t any faster, but there is less data to download.
  • skip=100 Work with the above parameter limit to return a group result set.  For example you can limit the return result to 100 documents starting from 101 going through 200 (think email counts in gmail) with the ?limit=100&skip=100.
  • descending=true Reverses the return result order.  Will also work with limit, skip, startkey, etc…
  • group=true The default result for a given map/reduce function (which has been re-reduced) is a total, i.e. a single number.  In my case this is seldom the result I am actually looking for so this command provides the bridge between the full re-reduce and what I is most commonly sought, the groups result.  Your final results when this option have been passed it to return the reduced functions grouped by the map keys.  Instead of a single row with {key:null, value:9999} you will get multiple rows with the key being the name of the map key i.e [{key:”bob”,value:”444″},{key:”tom”,value:555}].  If you created design documents and view them inside of Futon, group=true is the default.  Which can be a little confusing when you actually try and make a JSON request and find you get a different result.
  • group_level=2 An alternative to the above parameter is the group_level option which will actual group the resulting reduce by the number of levels specified IF you key is an array matching at least that many arguments.  While the example above is for two levels the number can be as many array places as your key has.  This become particularly helpful when working with years and dates.  For a detailed example checkout this post.  That said, group=true is the functional equivalent of group_level=exact.
  • reduce=false Turn OFF the reduce function on a given map/reduce query.  This is the default if not reduce is defined but you can override it on views that DO have a reduce function if you only want the results of the map.
  • include_docs=true For map queries (that do not have a corresponding view) this option will include the original document in the final result set.  This means the structure of your JSON rows object will be {_id, key, value, doc} instead of the normal {_id, key, value}.  This will save you an additional JSON request if you are using the map query as a lookup for a particular database query.

that the ripest might fall

Git is simply amazing when it comes to branching and merging.  I probably have half a dozen branches, each with a unique feature I am working on.  Git makes combining and working with branches so easy that it simply seems natural to store test-functionality on different branches, across multiple repositories, and between different developers.

…and HOLY CRAP is it fast!

That said I hit a problem today that I had to hunt down the answer to, so I am posting it here for easy reference in the future.  The basic issue is that whenever you create a new branch that is then pushed to someone else as a remote branch, git automatically (as would be logical) associates those branches together because they share the same name.  This makes future pushes easy and allows other users to continually get updates when you have commits you want to make available.

The problem occurs when you try to PULL from that new remote branch (because the users or repository has made some of their own changes.)  Git does NOT automatically associate pulls with the remote branch of the same name, even though this associates pushes.  So how do you fix this?  The error message says to modify your config file and look at the git-pull man page, but that could quickly cause insanity based solely on the extent of the complexity of the command set for git.  I probably spent an hour looking through documentation.

The answer was, like you didn’t know where this was going, Google.  Ultimately you can the problem with a fairly simple command that WILL AUTOMATICALLY update your config.

git branch --set-upstream yourBranchName origin/yourBranchName

And that is it! Hopefully that saves someone the time that I lost.

Another fix I ran across comes from an initial pull from a remote repository that is empty. Because the original repository (empty) shares no files in common with my local repository (that I have added files to.) Git gets upset. The error generated looks something like this:

No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as ‘master’.
fatal: The remote end hung up unexpectedly

It can be fixed with the following command:

git push origin master

Then all remaining pushes should be fine as now you have a shared reference to use for future pushes.

Geniuses remove it

I am starting to believe that in the Poettering household, simplicity was considered a cancer that must be tortured and destroyed with extreme vigor.  Systemd is quickly becoming thoroughly ubiquitous in Linux systems everywhere.  While Systemd tries to do everything for everybody (it is supposed to eventually replace sysvinit, chkconfig, automount, logging, cron, and a whole host of other things) ultimately the primary intent of Systemd is to speed up the boot process.  It does this job exceedingly well.  This concern about boot time is a direct response to the speed of which other Unix based OSes boot and reference material even explicitly points to Apple as a reference.

That said, sysvinit did have one thing going for it… IT WAS SIMPLE.  Heck, just getting a list of available services is a pain in the ass now and generally requires looking up documentation just to remember how to do it.  Simple actions in systemd are annoyingly complex with a cheat sheet that looks like it was written by a Perl regular expression programmer on acid.  I will be the first to admit that systemd-analyze plot is pretty awesome and, considering that systemd was designed by the same guy who created PulseAudio, we should probably be thankful that it isn’t even MORE complex.  But still, something just seems wrong about using an all-for-everything program on an OS that was designed to be simple and efficient.

to create a space for them

OK, first I have a new favorite quote:

Concentrated power is not rendered harmless by the good intentions of those who create it.
–Milton Friedman

And second… Well, this was a topic I had not expected to be posting about again but the last couple weeks I have found myself spending more and more time building RPM packages for Fedora.  Thankfully the development stack (and documentation) for Fedora is noticeably better than it was for Redhat 9.  So, in my usual fashon, I am listing some of the more useful information I have RECENTLY come across for building RPM packages on Fedora 16.

  • Recommended Method for adding Users & Groups — A Fedora wiki page that discusses the best way to add new users to a system during the rpm install process.  There is no recommendation for REMOVING users during uninstall.  Additionally, rpmlint will scream about un-registered users if you don’t provide reference users for rpmlint.  This bugzilla report discusses how to best alleviate that problem.
  • Packaging Tricks — A stupidly useful Fedora wiki article discussing common issues/fixes for doing package builds.  Some of them are simply look-up problems (like knowing group package groups are available.)   Some of the information is much more advanced package configuration tips (like converting badly encoded files to UTF-8.)  All are really helpful.
  • Frequently Made Mistakes — In the same vein as the Packaging Tricks but specifically focused on problematic RPM methodology.  One correction on this page.  The correct location for checking SPEC files from other Fedora packages is not correctly listed (Fedora doesn’t use CVS anymore.)  The correct location is in their git repository.
  • Creating Sub-packages — Is a very early stage draft document on the Fedora Documentation website that discusses how to best create multiple sub-packages from a given SPEC file.  I had been needing good documentation on this process and this seems to be the start of it.
  • RPM Groups — Raw list of valid RPM package groups.
  • How to Make RPM Packages — Exactly what the name implies.  Probably the best starting point for Fedora Linux software packagers.
  • rpm –showrc — This command will list all the current Macros defined for the rpm build environment.  It even includes your custom local setup.  It is a great place to grep for path information and to verify directory locations for installation.  It has probably been around forever but I honestly didn’t know about it until a couple days ago.
  • rpmdev-setuptree is one of several tools available in the rpmdevtools package (yum install rpmdevtools.)   Running this command will setup a local build directory in THAT USERS home directory (as you should NEVER build packages as root using the system wide build directory.) Additionally it will create a stock .rpmmacros config file.  You will still want to define your own %packager and %vendor macros.
  • Package Guidelines – The definitive guide from Redhat on creating Fedora/Redhat rpm files for distribution.
  • RPM Dev Tools – Web listing of some of the new automated packing tools for RPM based distributions.  Things like creating your default build environment and spec file format checker.
  • CPAN2RPM – A tool for building rpm files from the Comprehensive Perl Archiving Network.  While tools like cpanplus work well for package installation, I prefer the flexibility and consistency of rpm packages and this is a nice way to be able to use rpm files for CPAN modules.
  • cpanspec – Another tool for building spec files (and therefore rpm packages) from cpan repository information.  Generally I use cpan2rpm to create a basic package and then modify the spec file to work anyway, so this might be a better option.

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.

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.