Install MySQL on Mac OS X 10.7+

The no fuss, no muss guide to installing the latest stable version of MySQL DB locally on your Mac running OS X 10.7 or later.  (Hat tip to Trey Piepmeier for his excellent tutorial, upon which I improved a few things.)

  1. I’m assuming you’ve already installed Homebrew.
  2. If you haven’t already done so, run a quick brew update in terminal. This ensures you have the latest brew library of packages before you install anything.
  3. OK? Good. Now you need to tell brew to install MySQL by entering this command:
    brew install mysql
  4. Enter the following two commands, one after the other (the second one starts up your new, local MySQL server and creates an initial database):
    unset TMPDIR
    mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp
  5. The output from that last command should instruct you to enter three more.  Do it!:
    mkdir -p ~/Library/LaunchAgents
    cp $(brew --prefix mysql)/homebrew.mxcl.mysql.plist ~/Library/LaunchAgents/
    launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist


    The three commands above do the following, respectively: create a LaunchAgents folder for you if you don’t already have one, copy the mysql.plist file into that launch folder, and then loads that file into a system file so that Mac OS X starts MySQL for you each time you restart your machine.  Perfect!

  6. One final (optional) step is to run the included MySQL root/user config script. It’ll step you through various default username/password/etc options that you might want to configure now that you’ve got MySQL up and running on your machine. To run this automated post-MySQL-install wizard, enter:
    $(brew --prefix mysql)/bin/mysql_secure_installation

Looking to install PostgreSQL instead?

Install Homebrew on Mac OS X 10.7+

How to Install Homebrew on Mac OS X (10.7 or later)

This one’s super-quick and easy!  If you want to easily install other tools and add-ons in the future, you need Homebrew.

  1. Open a new shell and run the following:
    ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
  2. Once Homebrew has finished its installation, make sure to run the following:
    brew update

    Running Brew’s update command instructs it to fetch the latest install recipes from the remote repository. Remember: Before you use Brew to install something, you definitely want to run this command. Every single time! That way, you’ll always ensure you’re installing only the latest, stable packages.

That’s it!  You’re done.

Change OS X’s Archive Utility Preferences

So you’re sick of the lame, default settings that OS X’s Archive Utility comes with and you want to change ‘em? Yeah—I did too. So, here’s three ways to change that little tool’s settings to whatever your heart desires once and for all! (…or temporarily if you’d like; I don’t much mind either way to be honest with you.)

Unless you’re as fast as Superman and can open Archive Utility’s preferences pane during the roughly 0.0006 few seconds that it’s displayed on the screen during its unarchiving process, it seems the only way to change the default preferences are as follows:

  1. Launch Archive Utility manually and change the preferences as you would in any other app:
    Open up Terminal and type: open -a Archive Utility
  2. If you’re the type that doesn’t want anything to do with opening Terminal (not that there’s anything wrong with that) or one that prefers clicking the mouse a few more times, just for sport:
    Click on OS X’s Finder (usually in the lower-left of your dock), then go to the very top OS X menu bar and select “Go” and then “Go to Folder…” Then, just enter the following—/System/Library/CoreServices—and smack the enter key on your keyboard (or gingerly click the “Go” button with your mouse—again, totally up to you. I prefer smacking smacking the enter-key, myself.)
    At this point, you need only find the Archive Utility App within the Finder window and give her the ol’ double-click to launch.
  3. Now, if you wanna get all fancy-like and add a new icon to OS X’s System Preferences app, enabling all users to set their own Archive Utility preferences, do the following.
    • Open up Terminal and enter this beautiful one-liner:
      open /System/Library/CoreServices/Archive Utility.app/Contents/Resources/
    • In the Finder window that opens as a result, locate and double-click on the Archives.prefPane file.
    • If you’re asked to enter your Admin password, DO IT IMMEDIATELY WITHOUT HESITATION. This isn’t a drill and your life could depend on it. Of course, that’s simply false. But the truth is that at this point, OS X wants to add a dedicated preference icon for Archive Utility to its System Preferences App and wants you to confirm this action by entering your password. Honest!

Enjoy the following panel that you now have access to and configure the settings until you’re blue in the face!

OS X's Archive Utility Preference Panel (as seen after being added to the System Preferences App)

Hat Tippity Tip / Source

This “how to” article was adopted from one I originally read on TAUW right here, which itself was apparently adopted from an even earlier article, currently located on Macworld.com right here. Enjoy!

Setting up PostgreSQL on Mac OS X

What’s that? You’re making a Rails app, planning on eventually pushing it to Heroku, and you’re still running SQLite locally on your machine? Like a chump!? Come on now!

You’ve got to install Postgres locally! The good news is it that it’s super easy.

Major Hat Tip: Dan Manges is crazy-smart, the CTO of Braintree, and happens to be my mentor while at Code Academy. He saved me about three hours of chin-scratching, by teaching me everything below today (in about 15 minutes). Thanks man!
(Probably worth noting that any errors below are courtesy of yours truly—not Dan :)

  1. First things first: You’ll need Homebrew.
    • Open terminal and type: 
      brew -v

      This will return the current version of brew (if you have it installed).

      • If you do have it installed, update it with the following command:
        brew update

        That was pretty simple.

      • If you got an error when you ran brew -v, then you need to install Homebrew. Type the following into Terminal
        /usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"

        More info about installing Homebrew here.

    • With brew installed, you’re golden. Time to install PostgreSQL!
  2. Install PostgreSQL with the following command in Terminal
    brew install postgresql
  3. Start the PostgreSQL server and create a database:
    initdb /usr/local/var/postgres
    • Optional You’ll need to have PostgreSQL running locally in order for your app (running in development mode, of course) to read and write to your Postgres database(s). If you want to have PostgreSQL start automatically each time you start your computer, enter the following three lines into Terminal one-by-one:
      mkdir -p ~/Library/LaunchAgents
      cp /usr/local/Cellar/postgresql/9.1.3/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
      launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
  4. Done and done. PostgreSQL is up and running and now all you need to do is tweak a few setting in your Rails App’s database.yml file (in the config folder).
    • In your database.yml file, you’ll see a few environments and their respective configs beneath. Most likely you’ll see three environments: development:test:, and production:.
    • For now, we’ll just change the development: environment. If you haven’t changed anything, you’ll see the following as the default config for development::
      • development:
        # adapter: sqlite3
        # database: db/development.sqlite3
        # pool: 5
        # timeout: 5000
      • In order for your app to use your PostgreSQL server, you’ll want to change the above to this:
        development:
        # adapter: postgresql
        # database: name_of_your_app_development
        # encoding: utf8
        # template: template0
        # host: localhost
      • Super-awesome Protip: You’ll want to replace name_of_your_app with the name of your app.
  5. Hold on there partner, don’t forget to tweak your gemfile!
    Make sure the you’ve got the pg gem in your gemfile:

    gem 'pg'
    • Don’t Forget: You don’t want this gem 'pg' line only within your group :development, :test do block. So, either make sure you add :production to that block, or just add the gem 'pg' line outside of any such block like I did—like a pro.
  6. Finally, you’ll want to create a new database: 
    rake db:create

    and you’ll probably want to run the following command to delete your tables, recreate them, and seed them with any data you may have in your seeds.db file with the following command: 

    rake db:reset
Trying to install PostgreSQL on your Linux machine instead?

My buddy—Eric MacAdie—offers these helpful instructions for setting up a Postgres server for Rails on a Linux machine instead of OS X.

Rails’ default HTTP methods for button_to and link_to helpers

Here’s a tip when using Rails’ button_to and link_to URL helpers!

Never ever forget these two things:
1. button_to uses the :POST method by default

2. link_to uses the :GET method by default

Believe me: Memorizing these two simple Rails defaults will save you routing headaches down the road.

Example — Specifying the :GET method: Let’s say that you’d like to provide your user with a “Cancel” button on a form that redirects her back to the previous page after it’s clicked. (Because you’re nice, you’ll also throw up a warning modal…): 

button_to "Cancel / Delete", :back, confirm: "Are you sure you'd like to cancel and delete this post?", disable_with: "Deleting..."

Guess what? That’s not right! When clicked, that button will either throw a routing error or unintentionally make a post request to one of your routes. Instead, you need to specify that you’d like the button to use the :GET method, instead of its default :POST method. (refer to rule 1 above.)

Here’s the correct code for such a button: 

button_to "Cancel / Delete", :back, method: :get, confirm: "Are you sure you'd like to cancel and delete this post?", disable_with: "Deleting..."

See how we specify the method in there with “method: :get“?

Example — Specifying the :POST method: Want a text link that ends up sending sending a :POST to one of your routes? Simple, just remember to pass the correct method:

link_to "Click here to submit post.", posts_url, method: :post

If you wanted a button to perform the same action, you wouldn’t need to specify the method, as the default method is already :POST

button_to "Submit Post", posts_url, disable_with: "Submitting Post..."
Example — Specifying the :DELETE method: Just as you need to pass in the proper HTTP method into your button_to and link_to helpers if you’d like to use them for the opposite of their default method, so too must you specify the :DELETE method when you’d like to use that instead: 

button_to "Cancel / Delete", :back, confirm: "Are you sure you'd like to cancel and delete this post?", disable_with: "Deleting..."

Simple as pie to understand; Easy to forget and waste an hour scratching your head. Do yourself a favor and commit this to memory!

So you wanna use Git, huh?

Over the past few weeks, I’ve been working on an app with three other people. The four us divided up the necessary work that needed to be done, chose parts to work on that we found interesting, and then got to work.

How do multiple people add to, modify, and delete the project’s codebase (and other files)—all while keeping track of everything along the way?

As soon as we asked this question, the answer was simple: use Git!

Git is a Revision Control System

Using Git, multiple people can easily work on the same project, at the same time, and keep track of all changes. In addition to providing a detailed history of who did what and when, Git empowers collaborators to revert back to a previous version of a project’s codebase (or a previous version of, say, a single file), should broken code or otherwise undesirable changes occur at some point.

Start Using Git in Your Own Rails Project

  1. After creating your project, cd into your project’s working directory via terminal and initialize Git with the following command:
    git init
  2. Git is now good to go and is ready to keep track of the files in that directory. Make changes to some code, return to terminal, and type the following:
    git add .

    Notice the . (period) at the end? That tells Git to add all of the new and modified files to it’s index. In other words, Git is now tracking every file in that directory and will know when changes are made to existing files or when new files are added.

    • Note: If you ever delete a file from your project, you should type the following command in terminal:
      git add -A .

      It’s similar to the previous command, but passing in the -A option will tell Git to “add” the files that you removed from your project. (You can think of this as Git keeping track of the fact that you just deleted a file.)

  3. So far, Git has been initialized and is also tracking all of the files in your project (including any changes you’ve made so far). But, you’ve yet to commit these changes. These commits are the snapshots of your project that Git will keep a history of, enabling you to rollback or revert to at some point in the future should you so desire.
    To commit your changes—and thus make your first/initial commit for this project—type the following command in terminal: 

    git commit -m 'initial commit'

    This commits your changes. Note the -m option that we’ve passed in as well as the 'initial commit' message following it. As you might guess, the -m stands for “message” and the text in single (or double) quotes following it contains a message that will be saved along with the commit. (You should always pass in a descriptive note that will let you [and/or other developers reading it later on] to quickly decipher what changes you made for that particular commit.

Part Two: Coming Soon

This post covers the basics of using Git for your personal projects. In the next post, I’ll detail how using the above-listed commands—as well as a few other commands—will enable you to use Git for a single project with multiple collaborators as I described in the opening paragraph.

Code Academy Has Begun!

Remember that one time when I moved to Chicago to start Code Academy? Oh wait, that just happened!

Back Story

After graduating from college, I wisely decided to pursue my interests in technology and got a job working at Mahalo in Santa Monica, CA. (Many fun stories on this experience, of course. I’ll save them for future posts—including, “Greg’s guide to getting a job at a startup”. Good times.) After Mahalo was slapped by Google (note to self: avoid building a business entirely reliant on another company for both traffic and revenue) I parted ways and joined the team at Border Stylo.

I absolutely fell in love with startups. I soon realized that I wanted to become more technical myself so that I could start actualizing my own ideas and start a company of my own. Enter Code Academy.

Why Code Academy?

Of course, there are many nice, free, online and interactive “teach yourself how to program” resources these days that enable an aspiring developer to teach herself various languages at her own pace, on her own time (not to mention all of the free and paid video courses that have been available for years).

But, I was looking for something that met the following criteria:

  1. I wanted to do this full-time and completely immerse myself without any distractions;
  2. I wanted an environment where I could work alongside others that were equally as dedicated and passionate about becoming developers;
  3. And, I wanted an adventure—I wanted to travel and live somewhere new for a while.

Code Academy offered my all of these things and more so I jumped on the opportunity, applied for a spot, was accepted (duh), and made it happen. In talking with some of the then-current (now former) students before and while I applying, I was left without any doubt: this was the program for me and would be awesome.

The Focus

The focus over the next 12 weeks (the duration of Code Academy) will be Ruby on Rails, and a healthy dose of HTML, CSS, and Javascript to be dangerous. In talking with folks, it’s clear that many are looking to land a gig at a startup or dev shop once things are done, others are focusing on an existing idea for a web app that they came into the program with already and will pour everything they learn into that one idea, while many others are somewhere in between.

Code Academy offered a design class this quarter and so we’ll also be working closely with them throughout on the various projects we create throughout, hackathons, demo-day projects, etc.

The Beginning

Things have only just begun and so there’s not too much to share yet. But count on the fact that I’ll be posting regular updates on my progress, funny anecdotes, and everything in between in the coming weeks and months while I’m in Chicago.