Matt Mazur

One quick productivity hack is to add command line aliases to your Terminal in Mac OS X.

For example, I prefer typing c instead of clear to clear the terminal and I usually add all sorts of shortcuts for cd’ing into directories that I use often.

Here’s how to do it:

1) Navigate to your home directory:

cd ~

2) Open up .bash_profile using vi:

vi .bash_profile

3) Add an alias (press i):

alias c="clear"

4) Save the file (press Escape, type :wq, and hit Enter)

5) Restart Terminal

If you followed this example, you should now be able to just type c and Enter in Terminal to get the same affect as typing clear.

For more information, this post gives some additional examples of aliases you can add.

By default, when you open up a new Terminal window in Mac OS X the command prompt displays a relatively long name:

I prefer to shorten this to a simple dollar sign ($) in order to free up space.

To change your default command line prompt, follow these instructions:

1) Navigate to your home directory:

cd ~

2) Create a file called .bash_profile

vi .bash_profile

3) Add the following line (press i)

export PS1="$ "

4) Save the file (press Escape, type :wq and hit Enter)

5) Restart Terminal

You should now see something like this:

There are other ways you can configure the command prompt (for example, showing the current time), but I prefer to keep it simple.

I’m just getting around to setting up my new Macbook Pro and figured I’d document my experiences in case it helps anyone else.

In order to write tutorials I need to take screenshots and by default Mac’s save screenshots to the Desktop, which I don’t like because  the Desktop tends to get cluttered very quickly.

Instead, I prefer to keep them in a separate folder reserved only for screenshots.

To change the default screenshot location, follow these instructions:

1) Create a folder called Screenshots in your Pictures folder (or wherever):

2) Open up Terminal and enter the following (one line):

defaults write com.apple.screencapture location /Users/yourlogin/Pictures/Screenshots

(Replacing yourlogin with your login name.)

3) Restart your computer for the changes to take effect

After you restart, new screenshots will be automatically saved to the Screenshots folder instead of the Desktop:

Hat tip to Macworld for the original instructions.

I bought a new Macbook Pro on Apple.com last Saturday evening (14 Jan 11) and it arrived via Fedex yesterday afternoon (Thursday, 19 Jan 11).

Using the FedEx shipment history and a confirmation email I received immediately after placing the order, we can put together a pretty accurate timeline of where the Macbook was and when:

The Macbook went from Shanghai to Anchorage to Newark to Franklin to Needham to my doorstep in less than 90 hours–not bad Fedex.

Hey everyone, I just changed my Twitter name from @leandesigns to @mhmazur. If you were following @leandesigns, it should have automatically updated for you.

I originally set up the @leandesigns account after I renamed jMockups to Lean Designs, but never really found the right balance between using it for marketing and using it for personal use. I’m not much of a Twitterer (?), but saying Hi to friends from a company’s Twitter account seemed awkward. I probably should have used it more to engage with folks looking for a web design tool, but that always seemed too spammy (which is probably wrong).

Anyway, I think I’ll use it more now that it’s just a personal account. Feel free to say hi @mhmazur.

Received an en email today from Cody K on my use of Webrick in production for Lean Domain Search:

Hey Matt,

Lean Domain Search is really neat – thanks for making it available.

Just wanted to let you know that it’s a really bad idea to run Ruby web apps with Webrick in production – you should be using something like nginx and either Unicorn or Passenger. Those are battle-hardened and production-ready, whereas Webrick’s sole purpose is for development environments, and, as such, is not heavily tested (if at all) for security issues and whatnot.

Just a friendly heads up. :) Thanks again.

Heroku’s Rails 3 docs are also pretty clear on this and I remember reading it during my initial upgrade, but never got around to actually doing it.

Thin is a recommended app server over Webrick (the default for rails).

Switching to Thin is pretty easy:

1. Add gem 'thin' to your Gemfile:

I added it to the production group because I want to keep using Webrick in development for now.

2. Make sure that you run bundle install to update your Gemfile otherwise you’ll receive a warning like this when you push to Heroku:

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
You have added to the Gemfile:
* thin

3. Add a Procfile to your root directory to instruct Heroku to use Thin instead of Webrick:

4. Commit and push your updated app to Heroku.

If all went well, you should see something like this in your logs:

2012-01-18T12:44:33+00:00 app[web.1]: >> Using rack adapter
2012-01-18T12:44:33+00:00 app[web.1]: >> Thin web server (v1.3.1 codename Triple Espresso)
2012-01-18T12:44:33+00:00 app[web.1]: >> Listening on 0.0.0.0:38951, CTRL+C to stop
2012-01-18T12:44:33+00:00 app[web.1]: >> Maximum connections set to 1024
2012-01-18T12:44:34+00:00 heroku[web.1]: State changed from starting to up

Too easy.

One thing confused me though: How did Cody know that I was using Webrick? I emailed him and asked.

His response:

I mistakenly typed some bogus characters in at the end of my address bar while I was on your site…something like this: http://www.leandomainsearch.com/search?q=up^jf

Sure enough, Webrick fails loudly when the URL includes a caret:

Touché.

Big Huge Thesaurus by John Watson provides an excellent thesaurus API that can be quickly integrated into any app.

The first step is to sign up for an API key which takes less than a minute. The API is free up to 10,000 requests per day and cheap if you need more than that.

After you fill out the required information the site will generate an API key for you which you can use to access the API.

Here’s a simplified example of how I’m using it with in Lean Domain Search via jQuery:

$.ajax({
  url : "http://words.bighugelabs.com/api/2/youapikey/" + word + "/json?callback=?",
  dataType : 'json',
  complete : function(jqXHR, textStatus) {
    if (textStatus == 'parsererror') {
      // Did not find any synonyms
    }
  },
  success : function(data) {
    // Found synonyms
    alert(data);
  }
});

(View Gist)

Here’s an example of the returned JSON data for the word “open”:

Note that the results are broken up by part of speech (noun, adjective, etc) and are further broken up into groups (“ant” for antonyms, “rel” for related terms, “sim” for similar terms, “syn” for synonyms).

All in all it took about two hours to integrate the Big Huge Thesaurus API into Lean Domain Search and only because I added some extra functionality (sorting and filtering the synonym list, tracking what % of the searches are discovered via the synonym list, etc).

Here’s what Lean Domain Search looks like now — note the synonym list in the right column:

Click here to check out the results for “open”.

Yesterday I launched Lean Domain Search, a new domain search engine, on HackerNews.

You can read the discussion here: Review my Startup – Lean Domain Search – The fastest way to find a domain name.

It started with Domain Pigeon

Lean Domain Search is a follow up to Domain Pigeon, my first Rails project which I launched (also on HackerNews) a little less than three years ago.

Lean Domain Search is what Domain Pigeon was supposed to be: you type in a search phrase and the app pairs it with other words to generate domain names and instantly shows you which are available. I even kept a notebook in my car and when I saw a company name that started or ending with something that would also work for a domain name, I’d jot it down. One problem though: I didn’t know how to do it.

It’s not hard to programatically check whether a domain name is available, but doing it in bulk and doing it fast is. When I started trying to implement bulk search for Domain Pigeon, I couldn’t figure out a way to do it well. I decided to pivot slightly and simply listed available web 2.0-style domain names instead.

Domain Pigeon did well, but I made a bunch of mistakes which eventually led to its downfall. I remember thinking foolishly “Man, making money with web apps is easy.” Domain Pigeon was never supposed to take off. It was a something I undertook to learn web development; it wasn’t supposed to be what I became known for. Yet I’d go to Philly on Rails meetups and I’d be the “Domain Pigeon guy”. And so I started working on other projects, one of which eventually became Preceden. I kept working on Domain Pigeon on the side, but as I became more and more involved in Preceden’s development, I let Domain Pigeon slide and eventually just said screw it and shut it down.

Looking back, my two big takeaways from Domain Pigeon where:

1) It’s hard to make money with web apps. If you are lucky enough or talented enough to find something that people like and will pay for, double down.

2) If you do decide to work on new projects, don’t abandon your existing ones. If you don’t have the discipline to maintain existing projects while building new ones, then don’t build new ones until you do.

Lean Domain Search aka Domain Pigeon 2.0

I launched Preceden and eventually Lean Designs, but I still had the domain name itch. I really wanted to build that original search tool and continued brainstorming ways to do it. About five months ago I decided to take a break from Preceden and Lean Designs development and go for it (without abandoning either — see #2 above).

Lean Domain Search is the result. It’s better that what I originally envisioned: it generates and checks the availability of 1,000 domain names in about 2 to 3 seconds (go check it out!).

The HackerNews launch

The launch on HackerNews went well, but it was not without issues (launch day never is).

The biggest problem was the accuracy of the results. I estimated beforehand that about 1 in 1000 available results would be actually be registered due to some quirks with the way they were being checked. That turned out to be a tad bit optimistic: it was more like 1 in 20. As an extreme example, the results for “cloud” returned 10 results, none of which were actually available. This was understandably frustrating to anyone who searched for “cloud”, found domain names that he or she got excited enough to register, and then found out it was actually registered.

As a temporary solution, I added a “Double-check availability” button that let folks confirm an available domain name was indeed available before going off to register it. This worked great on my local computer, but there was a bug in production that caused it to say that every result was registered. I didn’t notice this until a few hours later by which time 800 people had double-checked the availability of a domain name and Lean Domain Search said the equivalent of “Oh, actually it’s registered. My bad.”

There was a hectic hour of hacking after that where I troubleshot and fixed the double-check feature, but it still felt sloppy. Everyone searching for “cloud” still got those same 10 incorrect results. Eventually it clicked: why not track the double-check results and stop showing ones that come back registered?

After another few hours of hacking, I had a decent solution in place: if you double-checked the result of an available domain name and it came back as registered, Lean Domain Search would remember that and it would no longer be shown in the available search results for you or anyone else. This way the results become more and more accurate as more people use it. 1 in 1000 might never be possible, but the false positive rate should eventually be closer to 1 in 100 than 1 in 20 (and thanks to Mixpanel, I can actually track that over time).

This morning I spent a few hours cleaning up the code and making other improvements. For example, when you click a domain name it will now automatically double check the result so you don’t have to.

I also found a typo today in the Namecheap affiliate link that caused my affiliate code to be dropped so I didn’t get credit for who knows how many domain name registrations yesterday. Fun!

But it was still a good day. All in all folks used Lean Domain Search to make about 14,000 searches yesterday thanks to it sitting on the HackerNews front page for almost 20 hours. Launch day traffic is always inflated though (don’t be fooled!); the trick is getting it back up to that point over the next few months.

The mentions on Twitter about Lean Domain Search were very positive too — thank you to everyone who Tweeted about it.

Here’s a screenshot from today:

On a final note, I should be blogging a lot more in the future. If you’re not subscribed to the RSS feed, you should.

Hey ya’ll,

This blog is going on hiatus for a few months while I take care of some other commitments.

I’ll still be available by email if you need to reach me.

All the best,

Matt / matthew.h.mazur@gmail.com

(The following is a cross-post from the Lean Designs blog)

It gives me great pleasure to announce that you can now create hybrid width layouts using Lean Designs, letting you create professional looking websites in a fraction of the time compared to doing it by hand.

To understand the significance of this new feature and how to use it, we need to go over a bit of terminology:

Three types of layouts

Fixed Width

In a fixed width layout, the site is given a fixed, constant width which is then displayed (usually centered) in the browser. With this type of layout, you cannot use any of the excess space in the browser except for specifying the page’s background style (white in the example below).

Example:

Until today, fixed width layouts were the only type of design you could create with Lean Designs.

100% Width / Fluid Width / Liquid Width

In a 100% width/fluid width/liquid width layout, the width of the site is based on the width of the browser. Because the position of the the elements are based on the width of the page, they’ll appear differently to visitors depending on the width of their browser.

Example:

Fluid widths are not currently supported by Lean Designs.

Hybrid Width

Hybrid width layouts, as the name implies, takes pieces of both the fixed width and the 100% width layouts. With this type of layout the outer elements can have 100% widths, but their contents are held in a fixed width, centered container.

Example:

With today’s release, you can now create this type of design using Lean Designs. Note that the term hybrid width is not a standard web design term, but we needed a way to differentiate this type of layout from the fixed width and 100% width layouts.

Creating Hybrid Width Designs in Lean Designs

Creating hybrid width designs in Lean Designs is a piece of cake:

1. Add a DIV element to your designs

2. Position it against the left side of the canvas

3. Stretch it so that it spans the entire width of the canvas

When you export it, Lean Designs will recognize that you want this element to have a 100% width and generate the appropriate HTML/CSS.

For example, let’s add an H1 element, assign it an id of logo, assign the red element an id of header, and export it. This is what it will look like in the browser:

And here’s the HTML/CSS that Lean Designs generates:

Pretty cool huh?

OneHub Example

Lest you think this is only for creating simple, ugly sites, check out the following example of OneHub’s homepage re-created using Lean Designs in about 10 minutes:

In the editor:

Exported to HTML/CSS: (click here to view site)

Hope you like it. If you don’t have an account, you can sign up for free and create your own design in minutes.

As always, drop us a note if you run into any bugs or have ideas for improvement.

matt / matt@leandesigns.com