iPhone GUI PSD

iphone_gui.jpg

Over the past few months we’ve had to create a few iPhone mock ups for presentations. The problem we’ve encountered is the lack of resources to help us design something efficiently. Up until now we’ve used a nice PSD from 320480.com but we still found ourselves having to build out additional assets or heavily modifying bitmap based buttons and widgets.

Since we know we’ll be doing more of this, we created our own Photoshop file that has a fairly comprehensive library of assets – all fully editable.

(via fscklog.com)

Open-Source-Plattform für Social Networks: Elgg v1.0 startet

Open-Source-Plattform für Social Networks: Elgg v1.0 startet: „Elgg ist eine Open-Source-Social-Network-Plattform, die Blogging, Networking, Messaging, Communitys, RSS-Feeds und Filesharing miteinander verbindet. Die webbasierte Anwendung wurde auf der Grundlage von LAMP (Linux, Apache, MySQL, PHP) entwickelt.

Ein wesentlicher Bestandteil von Elgg sind die ‚Views‘. Damit werden die einzelnen Seiten für unterschiedliche Anwendungsfelder aufbereitet. Neben Standard-HTML sind beispielsweise Views für mobiles Internet, iPhone oder als eingebettetes Widget möglich.

Das Konzept von Elgg beinhaltet die Erweiterung der Plattform über Plugins. Damit diese Möglichkeit einfach und schnell umsetzbar wird, wurde das Framework von Elgg so geschrieben, dass viele Komponenten eines Plugins schon enthalten sind, wie beispielsweise ein Benachrichtigungssystem, Import/Export-Filter, Sprachanpassung und eine API.

Die Möglichkeit zum Datentransport zwischen unterschiedlichen Social Networks wurde in der nahen Vergangenheit immer wieder gefordert und von einigen Netzwerken auch schon angegangen. Elgg präsentiert in diesem Bereich mit der openData Definition (ODD) schon zum Start ein fertiges Konzept, mit dem die Nutzer in der Lage sein sollen, ihre persönlichen Daten von einem Netzwerk in ein anderes zu kopieren.

Die Social-Network-Plattform Elgg verfügt über einen hohen Funktionsumfang und ist als webbasierte Anwendung crossplattformfähig. Das vom Start weg enthaltene Konzept zur Data Portability macht Elgg zukunftssicher und hält eventuell vorhandene Einstiegshürden niedrig. Die vereinfachte Möglichkeit zur Entwicklung von Plugins sorgt zudem für eine zusätzliche Anpassungsfähigkeit der mit Elgg entwickelten Social Networks.

Heute (18.08) startet Elgg nun die finale Version 1.0. Einen ersten Eindruck kann man sich mit einer Testseite von Elgg verschaffen.“

(Via t3n.yeebase.com – Open Source, Web & TYPO3.)

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example: „

YUI 3.0 Preview Release 1 was made available on Wednesday, and with it we provided a look at how the next major iteration of YUI is taking shape. Among the elements we shipped with the preview is a new example from Dav Glass, the Draggable Portal, which exercises a broad cross section of the preview’s contents.

The Portal Example in the YUI 3.0 preview release.

The Draggable Portal is a common design pattern in which content modules on the page can be repositioned, minimized, removed, and re-added to the page. The state of the modules persists in the background, so a reload of the page or a return to the page calls up the modules in their most recently positioned state. You see variations of this design pattern on many personlizable portals like My Yahoo, NetVibes, and iGoogle.

In this article, we’ll take a look under the hood of this example to get a richer sense of YUI’s 3.x codeline and the idioms and patterns it establishes. We’re just pulling out some specific code snippets to examine here, but you can review the full code source for this exampleand for 66 others — on the YUI 3 website.

(more…)

(Via Yahoo! User Interface Blog.)

The Only Thing We Have To Fear Is Premature Standardization

The Only Thing We Have To Fear Is Premature Standardization: „The web is made of open standards. This was a significant factor in the web’s displacement of proprietary application platforms. Openness is hugely attractive, so much so that the web dominates over competitors with better technologies. The difficult tradeoff that comes with a standards-based approach is that it is difficult to innovate. As a result, the basic technologies of the browser have been stalled for a decade. What innovation we’ve enjoyed, such as the Ajax revolution, has come by mining all of the latent, accidental potential of the existing standards. That potential has been used up.

If we are to go forward, we must repair the standards. This is something that must be done with great care. A revision to a standard is an act of violence, just like any surgical procedure. It should only be undertaken when the likely benefit far exceeds the cost and the pain and the risk. The web is particularly troublesome because it did not anticipate the management of software updates, which is why IE5, an ancient browser, still has more users than Safari and Opera combined. Changes to the standard can put developers in a very difficult position because the benefits to users of some browsers become the seeds of failure for the users of others. Developers must manage this gulf, and it is not easy. Developers are not well served by new standards that make their jobs even harder.

I think it is instructive to look at two approaches to managing innovation within a standards based system, one that I view as a success, and the other not so much. JavaScript was a promising but half-baked language that was irresponsibly rushed to market and then irresponsibly cast into a standard. That standard is called ECMAScript to avoid a trademark dispute. That standard was last revised in 1999.

It is clear that the language needs to be updated, but TC39 (the committee that is responsible for drafting a new standard) could not reach consensus on how to do it, so it split into two groups, each producing its own proposal. This was a good thing in that competition is a healthy thing, and I believe that competition inspired improvements to both proposals. This was also a bad thing because no standards organization can adopt two proposal for the same standard. Without consensus, both proposals must fail.

On one side there was the proposal called ES4. It was unfortunate that it adopted that name because it strongly suggested that it was destined to be the Fourth Edition of ECMAScript, a fate that was not certain. The project was very open to new ideas and features, adopting a porkbarrel attitude that was almost Congressional in its expansiveness. Lots of good ideas were included without an adequate analysis of the language as a whole system. As a result, many overlapping features were adopted which would have significantly increased to complexity of the language.

ES4 was so large and so innovative that there were doubts about whether it could be successfully specified and implemented. More worrisome, there was no experience with the language itself. Would the interaction of features cause unintended problems as we saw in ES1 and ES3? The schedule for ES4 required that the standard be put in place and adopted by the browser makers before that question could be answered. This is a problem because once a bug is inserted into a standard, it can be extremely difficult to remove it. All of the features, considered individually, were attractive. But taken as a whole, the language was a mess.

On the other side was a proposal called ES3.1. Its name indicated a less ambitious proposal, being a smaller increment over the current Third Edition. This project was intended to repair as many of the problems with the language as possible while minimizing the pain of disruption. New syntax was considered only when it was already implemented and proven in at least three of the four major browsers. Feature selection tended to favor necessary improvements over desirable improvements.

ES3.1 was more minimal in approach. The set of feature interactions was much smaller and much easier to reason about. ES3.1 is likely to complete its specification and will be the candidate for the Fourth Edition.

ES4 had a large head start (by as much as seven years by some estimates), but was unable to meet its deadlines. Ultimately, the project fell apart when some of the key members left.

Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1. The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that ‘design by committee’ is a pejorative. Standards bodies should not be in the business of design. They should stick to careful specification, which is important and difficult work.

I see similar stories in HTML5. The early work of WHATWG in documenting the undocumented behavior of HTML was brilliant. It went off the rails when people started to just make new stuff up. There is way too much controversy in HTML5. I would like to see a complete reset with a stronger set of design rules. Things can be much worse than the way things currently are. Having smart people with good intentions is necessary but not sufficient for making good standards.

(Via Yahoo! User Interface Blog.)

YUI 3.0 Preview Release 1

YUI 3.0 Preview Release 1: „

YUI 3.0 Preview 1 website.The YUI team is pleased to announce the public availability of YUI 3.0 Preview Release 1, an early look at what we’re working on for the next generation of the YUI Library. Documentation for YUI 3.0 is on the YUI website; the download is available on the YUI project area on SourceForge; you can find us with questions or comments on the YUI 3.x discussion forum. Keep in mind that this is an early preview, not a production-quality (or even a beta) release. This release is not suitable for production use, but it will give you an idea of what we’re working on, and it should provide a good framework for conversation about the future of the library.

Five Goals for YUI 3:

We’ve talked to thousands of YUI users over the past 30 months, and based on that feedback we’ve set five design goals for the next generation of the library. What you’ve told us is that YUI 3.0 should be:

  • lighter (less K-weight on the wire and on the page for most uses)
  • faster (fewer http requests, less code to write and compile, more efficient code)
  • more consistent (common naming, event signatures, and widget APIs throughout the library)
  • more powerful (do more with less implementation code)
  • more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

With this early release, we’ve made progress toward most of these objectives — and we believe we have the right architecture in place to meet all five as we move to GA over the next few quarters.

What’s New in YUI 3.0?

When you start to write code using YUI 3.0, you’ll notice some changes in structure and style. Here’s a taste:

Snippet: What it does:
YUI().use('node', function(Y) {
    Y.get('#demo').addClass('enabled');
});
Creates a YUI instance with the node module (and any dependencies) and adds the class ‚enabled‘ to the element with the id of ‚demo‘.
YUI().use('dd-drag', function(Y) {
        var dd = new Y.DD.Drag({
        node: '#demo'
    });
});
Creates an instance of YUI with basic drag functionality (a subset of the dd module), and makes the element with the id of ‚demo‘ draggable.
Y.all('.demo').addClass('enabled');
Adds the class ‚enabled‘ to the all elements with the className ‚demo‘.
Y.all('.demo').set('title', 'Ready!').removeClass('disabled');
Sets the title attribute of all elements with the className ‚demo‘ and removes the class ‚disabled‘ from each.
Y.get('#demo').plug(Y.Plugin.Drag, {
    handles: 'h2'
});
Adds the Drag plugin to the element with the id ‚demo‘, and enables all of its h2 children drag as handles.
Y.on('click', function(e) {
    e.preventDefault();
    e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');
Attaches a DOM event listener to all anchor elements that are children of the element with the id ‚demo‘. The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor.

What’s different here?

  • Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
  • Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
  • Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
  • Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
  • Custom Events++: Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
  • Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get('#main ul li').addClass('foo');), it makes it easier to normalize differences in browser behavior (Y.Node.get('#promo').setStyle('opacity', .5);).
  • Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.

And that’s just the beginning. Dive into the examples to learn more and to see the preview release in action, including some hidden gems like full A-Grade cross-domain requests. Our resident metahacker Dav Glass created a nice multi-component example, the draggable portal, that will give you some sense of what’s included in today’s preview.

Is YUI 3.0 Backward Compatible with YUI 2.x?

No. YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

We know that ease-of-migration will be a critical factor for all YUI users. We’re taking two important steps to facilitate the transition as it arrives:

  • Limited compatibility layer: YUI 3.0 will ship with a limited compatibility layer for the current YUI Core (Yahoo Global Object, Dom Collection, and Event Utility). This will allow you to run many of your YUI 2.x-based implementations on top of YUI 3.0. We’re not shipping the compatibility layer with today’s preview, but you’ll see it appear in a future preview or beta release prior to GA.
  • Full parallel compatibility: YUI 3.0 can be run in parallel to YUI 2.x with no side effects for either version. If you choose to make the transition in stages, you can run the full 2.x stack and 3.x stack together as needed.

Even with these provisions in place, we know that an API change (along with new concepts and idioms) has a real cost for everyone involved. We’re convinced that this change is both necessary and worth the effort, and obviously we’re going to work hard to make the value proposition compelling.

What’s Next?

YUI 3.0 is a work in progress. The common widget framework for 3.0 is not included in this preview and we’re continuing to work on refinements to the core — including optimizations to the package structure to minimize base K-weight. We anticipate the next two releases coming up as follows:

  • October 2008 — PR2: Widget Framework, sample widgets, additional utilities.
  • December 2008 — Beta 1: Final mix of module structures, API completion, full complement of utilities.

We have some great stuff to share as we move further along in this process. We’ve never been more excited about YUI and its future — and we think YUI 3.0 will have a big role to play in that future.

(Via Yahoo! User Interface Blog.)

Ad-Server OpenX 2.6 mit API und schnelleren AdTags

OpenX hat mit der Version 2.6 seines gleichnamigen freien Ad-Servers veröffentlicht, die wesentliche neue Funktionen mitbringt, darunter ein API und schnellere Ad-Tags. OpenX hieß einst phpAdsNews, später dann OpenAds und heute OpenX.
Dank des neuen API in OpenX 2.6 soll es deutlich einfacher sein, OpenX in bestehende Systeme zu integrieren und beispielsweise an CRM-Software anzubinden. Zudem können Entwickler so eigene Applikationen schreiben um neue Kampagnen anzulegen, Statistikdaten empfangen oder eine größere Zahl an Werbemitteln hochladen.

Neu ist auch das Dashboard, das auf Wünsche aus der OpenX-Community zurückgeht. Es fasst die wichtigsten Statistiken zu den genutzten Ad-Servern zusammen und kann um Widgets erweitert werden, die Daten zu laufenden Kampagnen zeigen.

Ein neues Ad-Tag verspricht eine schnellere Auslieferung der Werbung, denn der Browser muss damit künftig nur noch eine Anfrage an den Ad-Server senden, auch wenn mehr als ein Werbemittel angezeigt werden muss. Es sind vor allem diese via JavaScript abgewickelten Aufrufe, die Webseiten langsam erscheinen lassen, da das Rendern der Seite dadurch in manchen Browsern behindert wird. Das Laden der eigentlichen Banner ist eher unproblematisch.

OpenX ist Open Source und steht unter der GPLv2. Die Version 2.6 kann ab sofort unter openx.org/download heruntergeladen werden. Laut OpenX wird die Software auf mehr als 100.000 Websites eingesetzt und monatlich mehr als 250 Milliarden Werbemittel über OpenX-Server ausgeliefert. Das Unternehmen selbst bietet auch eine gehostete Version des Ad-Servers an. (via Golem.de)

Using GnuPG with PHP

Using GnuPG with PHP: „

GnuPG is open-source software that makes it possible to encrypt your email and other messages so that they can only be read by the intended recipient (not unlike Jim Phelps and his briefing book). Unlike cleartext messages, which are unprotected and can be read by anyone who intercepts them, GnuPG-encrypted messages are ‘locked’ through cryptographic techniques and may be viewed only by a person with the correct ‘key’; everyone else will merely see gibberish. In today’s day and age, when hacking and phishing is common, such encryption plays an important role in protecting sensitive data like user names, passwords or credit-card information.

(Via Zend Developer Zone.)

Non-blocking JavaScript Downloads

Non-blocking JavaScript Downloads:

External JavaScript files block downloads and hurt your page performance, but there is an easy way to work around this problem: use dynamic scripts tags and load scripts in parallel, improving the page loading speed and the user experience.

The problem: scripts block downloads

Let’s first take a look at what the problem is with the script downloads. The thing is that before fully downloading and parsing a script, the browser can’t tell what’s in it. It may contain document.write() calls which modify the DOM tree or it may even contain location.href and send the user to a whole new page. If that happens, any components downloaded from the previous page may never be needed. In order to avoid potentially useless downloads, browsers first download, parse and execute each script before moving on with the queue of other components waiting to be downloaded. As a result, any script on your page blocks the download process and that has a negative impact on your page loading speed.

Here’s how the timeline looks like when downloading a slow JavaScript file (exaggerated to take 1 second). The script download (the third row in the image) blocks the two-by-two parallel downloads of the images that follow after the script:

Timeline - Blocking behavior of JavaScript files

Here’s the example to test yourself.

Problem 2: number of downloads per hostname

Another thing to note in the timeline above is how the images following the script are downloaded two-by-two. This is because of the restriction of how many components can be downloaded in parallel. In IE <= 7 and Firefox 2, it’s two components at a time (following the HTTP 1.1 specs), but both IE8 and FF3 increase the default to 6.

You can work around this limitation by using multiple domains to host your components, because the restriction is two components per hostname. For more information of this topic check the article ‘Maximizing Parallel Downloads in the Carpool Lane’ by Tenni Theurer.

The important thing to note is that JavaScripts block downloads across all hostnames. In fact, in the example timeline above, the script is hosted on a different domain than the images, but it still blocks them.

Scripts at the bottom to improve user experience

As Yahoo!’s Performance rules advise, you should put the scripts at the bottom of the page, towards the closing </body> tag. This doesn’t really make the page load faster (the script still has to load), but helps with the progressive rendering of the page. The user perception is that the page is faster when they can see a visual feedback that there is progress.

Non-blocking scripts

It turns out that there is an easy solution to the download blocking problem: include scripts dynamically via DOM methods. How do you do that? Simply create a new <script> element and append it to the <head>:

var js = document.createElement('script');
js.src = 'myscript.js';
var head = document.getElementsByTagName('head')[0];
head.appendChild(js);

Here’s the same test from above, modified to use the script node technique. Note that the third row in the image takes just as long to download, but the other resources on the page are loading simultaneously:

Non-blocking JavaScript timeline

Test example

As you can see the script file no longer blocks the downloads and the browser starts fetching the other components in parallel. And the overall response time is cut in half.

Dependencies

A problem with including scripts dynamically would be satisfying the dependencies. Imagine you’re downloading 3 scripts and three.js requires a function from one.js. How do you make sure this works?

Well, the simplest thing is to have only one file, this way not only avoiding the problem, but also improving performance by minimizing the number of HTTP requests (performance rule #1).

If you do need several files though, you can attach a listener to the script’s onload event (this will work in Firefox) and the onreadystatechange event (this will work in IE). Here’s a blog post that shows you how to do this. To be fully cross-browser compliant, you can do something else instead: just include a variable at the bottom of every script, as to signal ‘I’m ready’. This variable may very well be an array with elements for every script already included.

Using YUI Get utility

The YUI Get Utility makes it easy for you to use script includes. For example if you want to load 3 files, one.js, two.js and three.js, you can simply do:

var urls = ['one.js', 'two.js', 'three.js'];
YAHOO.util.Get.script(urls);

YUI Get also helps you with satisfying dependencies, by loading the scripts in order and also by letting you pass an onSuccess callback function which is executed when the last script is done loading. Similarly, you can pass an onFailure function to handle cases where scripts fail to load.

var myHandler = {
    onSuccess: function(){
        alert(':))');
    },
    onFailure: function(){
        alert(':((');
    }
};

var urls = ['1.js', '2.js', '3.js'];
YAHOO.util.Get.script(urls, myHandler);

Again, note that YUI Get will request the scripts in sequence, one after the other. This way you don’t download all the scripts in parallel, but still, the good part is that the scripts are not blocking the rest of the images and the other components on the page. Here’s a good example and tutorial on using YUI Get to load scripts.

YUI Get can also include stylesheets dynamically through the method
YAHOO.util.Get.css() [example].

Which brings us to the next question:

And what about stylesheets?

Stylesheets don’t block downloads in IE, but they do in Firefox. Applying the same technique of dynamic inserts solves the problem. You can create dynamic link tags like this:

var h = document.getElementsByTagName('head')[0];
var link = document.createElement('link');
link.href = 'mycss.css';
link.type = 'text/css';
link.rel = 'stylesheet';
h.appendChild(link);

This will improve the loading time in Firefox significantly, while not affecting the loading time in IE.

Another positive side effect of the dynamic stylesheets (in FF) is that it helps with the progressive rendering. Usually both browsers will wait and show blank screen until the very last piece of stylesheet information is downloaded, and only then they’ll start rendering. This behavior saves them the potential work of re-rendering when new stylesheet rules come down the wire. With dynamic <link>s this is not happening in Firefox, it will render without waiting for all the styles and then re-render once they arrive. IE will behave as usual and wait.

But before you go ahead and implement dynamic <link> tags, consider the violation of the rule of separation of concerns: your page formatting (CSS) will be dependent on behavior (JS). In addition, this problem is going to be addressed in future Firefox versions.

Other ways?

There are other ways to achieve the non-blocking scripts behavior, but they all have their drawbacks.

Method Drawback
Using defer attribute of the script tag IE-only, unreliable even there
Using document.write() to write a script tag
  1. Non-blocking behavior is in IE-only
  2. document.write is not a recommended coding practice
XMLHttpRequest to get the source then execute with eval().
  1. eval() is evil’
  2. same-domain policy restriction
XHR request to get the source, create a new script tag and set its content
  1. more complex
  2. same-domain policy
Load script in an iframe
  1. complex
  2. iframe overhead
  3. same-domain policy

Future

Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.

Summary

  • Scripts block downloads in FF and IE browsers and this makes your pages load slower.
  • An easy solution is to use dynamic <script> tags and prevent blocking.
  • YUI Get Utility makes it easier to do script and style includes and manage dependencies.
  • You can use dynamic <link> tags too, but consider the separation of concerns first.

(Via Yahoo! User Interface Blog.)

Conditional Comments for HTML Email

Conditional Comments for HTML Email: „

Take a look at this:

<!--[if gte mso 9]>

<![endif]-->

Chances are the general syntax will be instantly familiar — it’s a conditional comment, useful for feeding specific content only to Windows versions of Internet Explorer. But did you know they work for Office applications too?

Neither did I … until recently.

We’ve just overhauled the HTML templates for our email newsletters … a painful process to be sure — if you think that web browsers are harsh task-masters, you should try coding to suit email clients! A recent article, How to Code HTML Email Newsletters, spells out just how convoluted it can be, and how arcane are the techniques you have to resort to, to produce a decent layout in the most popular email clients. And the issue has been further complicated by the fact that one of the most popular Windows clients — Outlook — no longer uses Internet Explorer for HTML rendering, it uses Word!

And it was while perusing the franken-code that passes for ‘Save as Web Page’ output from a Word document, that I first saw these little nuggets — exactly what we needed to hide bits of content from Outlook that were just too mangled to leave.

So there you go. If you’re publishing HTML email and struggling with Outlook’s rendering, here’s an extra little tool for the kit. The syntax even implies that it can be used for granular targetting of Office versions all the way back; but I haven’t tested this, so any information is gratefully received :)

(Via SitePoint Blogs.)

Working With History in Bash

Working With History in Bash: „

Yesterday we talked about favorite bash features (on the ##textmate IRC channel). I figured it was worth posting mine to this blog, they mostly revolve around history, hence the title.

Setup

My shell history collects a lot of complex command invocations which take time to figure out. To ensure that I have access to them at a later time, I have the following 3 lines in my bash init:

export HISTCONTROL=erasedups
export HISTSIZE=10000
shopt -s histappend

The first one will remove duplicates from the history (when a new item is added). For example if you switch between running make and ./a.out in a shell, you may later find that the last 100 or so history items is a mix of these two commands. Not very useful.

The second one increase the history size. With duplicates erased, the history already holds a lot more actual information, but I still like to increase the default size of only 1,000 items.

The third line ensures that when you exit a shell, the history from that session is appended to ~/.bash_history. Without this, you might very well lose the history of entire sessions (rather weird that this is not enabled by default).

History Searching

Now that I have my history preserved nicely in ~/.bash_history there are a few ways to search it.

Using Grep

The most crude is grep. You can do:

history|grep iptables

For me (on this particular Linux server) I get:

4599  iptables -N http-block
4600  iptables -A http-block -s 58.60.43.196 -j DROP
4601  iptables -A INPUT -p tcp --dport 80 -j http-block
4602  iptables -L http-block
4603  iptables-save -c
4604  history|grep iptables

I do this often enough to have an alias for history (which is just h).

From the output I can either copy/paste the stuff I want, or repeat a given history event. You’ll notice that each history event has a number, you can repeat e.g. event number 4603 simply by running:

!4603

I will write a bit more about referencing history events in History Expansion.

Prefix Searching

Similar to how you can press arrow up for the previous history event, there is a function you can invoke for the previous history event with the same prefix as what is to the left of the insertion point.

This function is called history-search-backward and by default does not have a key equivalent. So to actually reach this function, I have the following in ~/.inputrc (or /etc/inputrc when I control the full system):

'\ep': history-search-backward

This places the function on P (escape P). So if I want to repeat the iptables-save -c history event we found in previous section, all I do is type ipt and hit P. If it finds a later event with the same prefix, hit P again to go further back.

This functionality is offered by the readline library, so if you setup this key, you have access to prefix searching in all commands which use this library.

Incremental Search

It is possible to press ⌃R to do an incremental (interactive) search of the history.

Personally I am not a big fan of this feature, so I will leave it at that :)

Update: The reason I dislike ⌃R is both because the interactive stuff just seems to get in the way (when P is what I need 99% of the time) and because it fails in cases where I ‘switch shell’, for example I may do: ssh mm press return, then instantly type: fP and again hit return (to execute free -m on the server called mm). I enter this before the connection to the server has been fully established, and here ⌃R would have been taken by the local shell, but it is the shell history at the server I want to search.

History Expansion

History Expansion was what we did above when we ran !4603. It is a DSL for referencing history events and optionally run transformations on these.

Anyone interested in this should run man bash and search for History Expansion, but just to give you a feel for what it is, I will reference a subset of the manual and provide a few examples.

Event Designators

First, an event designator starts with ! and then the event we want to reference. This can be:

«n»      Reference event number «n».
-«n»     Go «n» events back.
!        Last line (this is the default).
#        Current line.
«text»   Last event starting with «text».
?«text»  Last event containing «text».

So if we want to re-run our iptables-save -c we can do: !ipt.

What’s more useful though is to use history references as part of larger commands.

For example take this example:

% which ruby
/usr/bin/ruby
% ls -l $(!!)
lrwxr-xr-x  1 root  wheel  76 30 Oct  2007 /usr/bin/ruby -> ../../System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby

Or something like:

% make some_target
(no errors)
% path/to/target some arguments
(no errors)
% !-2 && !-1

Word Designators

In the previous section we referenced entire history events. It is possible to reference just a subset of a history event by appending a : to the event designator and then the word of interest, the two most useful are:

«n»      Reference the «n»’th word.
$        Reference the last word.

So for example we can do:

% mkdir -p /path/to/our/www-files
(no errors)
% chown www:www !$
(no errors)

Here we reference last word of last line. We can also reference stuff on the same line, e.g.:

% cp /path/to/important/file !#:1_backup

To reference the last word of last line one can also press _ which will immediately insert that word.

Modifiers

To make history substitution even more useful (and harder to remember), one can also add a modifier to the event designator.

The most useful modifiers are in my experience :h and :t, these are head and tail respectively or better know as dirname and basename.

An example could be:

% ls -l /path/to/some/file
(listing of file)
% cd !$:h
(change directory to that of file)

Brace Expansion

Somewhat related to the backup example where we reference the first argument as !#:1 and append _backup to this, another approach is bracket expansion.

Anywhere on a command line, one can write {a,b,c} which will expand to the 3 words a, b, and c. If we include a prefix/suffix, that will be part of each of the expanded words. We can also leave the word in the braces empty, and have it expand to just the prefix/suffix, so for example we can do:

% cp /path/to/important/file{,_backup}

This is functionally equivalent to:

% cp /path/to/important/file !#:1_backup

But lack of hardcoded word number is IMO an improvement.

(Via TextMate Blog.)