tail -f findings.out

There are a number of ways you can go about the process of converting image files into PDFs, most simply by opening a given image and printing it. You can select “Print to file” instead of a printer device, PDF format is the default for this type of output. But say you have a folder full of images and you want to make one big PDF of them. Here’s how you can do that:

This loops through all the .jpg images in the directory and converts them to a PDF file of the same name. Once that is done they are all combined into FINAL_NAME.pdf by pdftk, a handy PDF utility. The temp dir business is there to make the temp PDF file removal easier.

Problem

You have a file already tracked in your git repository, but you don’t want future modifications to it to be tracked.

A perfect example of this is the DB config file for Rails projects (config/database.yml). You’ll probably want to track this to keep the production and staging configuration stored and consistent. But it’s quite likely that individual development configurations will be different. Having a commit for each developer adding their own local configuration and thereby polluting it for others when they push is just silly.

Solution

The fun details

I had initially thought that git-ignore was the thing to use for this. That was wrong: git-ignore’s purpose is to allow ignoring of untracked files. In the case of the Rails DB conf example above, the file is already tracked. It has the instance information that needs to be shared and now we want to add local development details. Since it’s tracked, any modifications are going to be picked up by git-status. When you do a commit including changes to tracked files listed in .gitignore, the changes do indeed get pushed, which isn’t what we want.

When looking around for solutions to this, I saw “git rm –cached FILENAME” suggested as a way to stop tracking currently tracked files. And it does this, but it also deletes the file in the commit, which isn’t what we want either.

git update-index allows you to alter your staging area more manually than usual. With it you can perform a wide range of operations not otherwise possible through standard commands. Continuing with the Rails DB conf example, here’s what the workflow would look like:

1. config/database.yml with permanent instance info is added, committed, and pushed
2. Application code is pulled down by new developer
3. Local modifications made to database.yml for new developer’s local DB setup
4. git update-index –assume-unchanged config/database.yml

Thereafter, the changes to conf/database.yml won’t appear in status or get committed. You can continue making and committing other changes, going about business as usual. But any changes to config/database.yml won’t ever appear.

In case you decide you do want to start tracking changes on a file previously ignored, just run:

Thereafter changes to FILENAME will appear in git-status.

Gotcha

The annoying part about this solution is that it has to be run against every new checkout of the repo with the files whose modifications should not be tracked. The command sets a particular bit per checkout, and it’s not passed on to new checkouts.

Just as I was finishing up some fact checking for this write-up, I came across Jesper Rønn-Jensen’s post on this exact topic. If only it had come up in my initial searches! Here’s hoping the next searcher has better luck.

No, in fact ASCII art isn’t dead, it’s all the rage. Now that that’s established, check out these handy programs for generating your own ASCII art messages:

Figure 1. boxes provides boundless entertainment.

Figure 2. figlet and its inherent awesomeness.

Spice up those bland Bash scripts with entertaining comment formats!

But seriously, these utilities can make for more interesting banners, alert messages, and so on:

• boxes: Creates ASCII art boxes around entered text
• figlet: Creates large ASCII art versions of entered characters

Just because it’s the command line doesn’t mean it has to be boring!

Navigation menus on websites most often consist of a list of links. When looking through a menu, it’s not unreasonable for a visitor to have their mouse cursor over some of the menu item links for a few moments as they read through the options. Using an unadorned anchor tag in this situation has a troublesome side effect:

The title attribute of the anchor tag will appear as a tooltip, potentially obscuring menu items and minimally being a useless distraction. But removing titles from navigation links isn’t a good option, since this attribute is helpful for SEO and accessibility purposes.

When discussing this problem with friend Google, I ran across many examples of how to change the display of anchor tooltips, as well as how to hide them altogether. But what I wanted was removal of the title attribute on navigation links only when the mouse cursor hovered over them, adding it back when the cursor left. The solution I settled on consisted of jQuery’s handy hover function and some basic JavaScript. hover() allows you to specify a function to call when the cursor hovers onto an object and another to call when the cursor hovers off. Perfect! Here’s a simple example:

You can verify the functionality by inspecting one of the MenuItem links with Firebug and watching the title attribute as you move the cursor on and off the same link.

After the page is finished loading, when a cursor hovers onto any links within the div of id “main-menu” the title attribute is stored and set to an empty string (so no tooltip). When the cursor leaves, the title attribute is set back to its original value. Simple but effective!

I’ve found that I often create several views that are variations on an initial one, providing a slightly different convenient slice of the data as the need arises. But when a view is created the syntax actually stored can be quite different than what you put in. The parser reorganizes and rewrites to make everything explicit. While better for performance in running the view, this has the unfortunate side effect of transmuting a once readable statement into a forest of parentheses and backticks that can and does induce tears.

First an example view that I created using the handy world database:

This is a view of the 10 cites with the lowest population in the Central Luzon region of Asia. Now let’s see what actually got stored. To get a view’s create statement you can use the MySQL Query Browser and right click the view name shown in the right under Schemata, selecting “Copy SQL to Clipboard”. Or you can run a query like:

Here’s the result for the view above:

I added the line breaks for a modicum of readablilty, the statement is stored without them. I sure don’t want to edit that version in making a variant! This example isn’t actually too bad, but for real world complicated views, it really is quite difficult to read views exported in this way. I often try to store the original create view query just to avoid this pain. But sometimes I only have the stored syntax.

I’ve created a Bash function to make this whole process less painful:

Now to get a cleaned up view you can call this function followed by the database and view names:

To get the create statements for multiple views you can use a loop. For example:

If you need some more flexibility than this I implemented it in Python after an initial fit of rage caused by trying to get various levels of nested strings properly escaped in Bash. That ended up being overly long and unnecessary, and a cooler head prevailed. But the script is here on GitHub if you want it. It creates the same file although without using sed and with some error handling.