24 Hours with Chromebook: Is it for you?

I just received the Samsung Chromebook and have been putting it through its paces.  Here’s a quick writeup of my initial thoughts:

Why a Chromebook?

90% of my work is done in the following applications:

  • Google (Drive, Mail, Calendar)
  • Evernote
  • Harvest
  • Asana

(10% of my work on a monthly basis is done using desktop applications such as Keynote).

As a consultant, I am rarely at one desk all day, often moving between coffee shops, coworking spaces and client offices. I don’t have a car, so a lightweight laptop is extremely important to me if I’m carrying it all day. My MacBook Pro feels like such dead weight.

Cost — I initially considered the MacBook Air, but I couldn’t justify the price tag. And realizing that I do most of my work online, it didn’t seem to make sense.

Product Review

The Samsung Chromebook is $248 for the Wi-Fi version and weights 2.4 pounds (lighter than the MacBook Air)

Now that I’ve been using the Chromebook for a couple days, I am very happy with my decision to purchase it.

Offline capabilities are great for Google Drive and Email. I may end up switching from Evernote to using Google Drive more for note taking because of this.

It is so light! I just love how portable this device is.

The battery is awesome. I haven’t had the chance to let it fully drain, but I’m getting at least 6 hours (probably more), without charging.

Yes, you can download PDFs and files. You’ll end up having to view them in Google Drive, but that’s fine by me.

It’s fast! If I’d purchased a traditional desktop computer for $250 bucks you better believe it would feel sluggish. Not the Chromebook! It’s super speedy.

Onto the things that are a little funky:

Why didn’t anyone bother to mention they got rid of the CAPS LOCK? If you never use the caps lock, this may not matter to you, but I taught myself to capitalize using this key (weird, I know). I’m begrudgingly using the shift key, and I’ll obviously be forced to adapt, but I am not thrilled about this.

Why is the ALT key on the left side of the space bar so freaking huge? What the heck is that about? I keep accidentally pressing it.

Other than these keyboard complaints, I really have nothing bad to say about the keyboard. It appears full sized and is pretty easy to adjust to.

My final gripe is that I have to jump through an extra hurdle to print and I can only use 1Password with read-only access. These aren’t dealbreakers, but not being able to write to 1Password is pretty annoying.

Final thoughts

It does take adjusting to doing everything in a browser. But that takes about a day to figure out — and then you’re up and running. For $250 I definitely think it’s a great value. Is it missing some features? Sure. But for day to day web workers, I think it’s a really awesome alternative to your regular laptop.

About these ads

Deploying your Rails 3 app to Heroku

Heroku is my favorite service to deploy my Rails apps on. It can be a simple joy to use, or it can be a complete nightmare. It’s not difficult to deploy to Heroku, but there are a few things you must keep in mind:

1. Make sure your Rails app is located in a top level directory of your git repository. If you try to create an app anywhere else, it will fail to deploy to Heroku.

2. Heroku will not work with SQLite. You need to install Postgres if you’re working with Heroku. If you’d like to continue using SQLite in development, that has to be specified in the Gemfile. Ideally, you Gemfile should look like this:

gem 'heroku'

group :development, :test do
    gem ‘sqlite3′

group :production do
    gem ‘pg’

3. Once you’ve updated your Gemfile, run bundle install.

4. If this is a new repository, you’ll need to initialize it in the terminal with git init.

5. After your repository has been initialized, git add . and  git commit -m "Your message" .

6. Now we’re ready to push to Heroku! You’ll want to create your Heroku repo on the Cedar Stack. This is Heroku’s default runtime stack and works with Ruby, Rails, Python (and many more) languages. Run the command heroku create --stack cedar to create your repo.

7. Finally, run git push heroku master to push your code to heroku. You’ll notice that if you’ve been successful, Heroku gives you the URL in the terminal to visit your app.

If you already have a database in development, remember that isn’t going to be uploaded. You’ll need to run heroku heroku run rake db:migrate to setup your database on Heroku.

That’s Heroku in a nutshell. If and when  you do encounter problems updating Heroku, run heroku logs to help identify where the problem may lie. Whenever I’ve failed to deploy successfully to Heroku it’s because something is already broken in the app, that I didn’t catch in my development environment.

Good luck and please post other questions and Heroku advice in the comments!

Using Pry in your Rails application

One of the biggest challenges newbies to programming face is learning how to ask the right questions to fix problems and overcome challenges. Programming is just full of bugs and without knowing the tools that can help you overcome those challenges, bug fixing can seems like a miserable, infuriating slog.

My favorite debugging tool when working on Rails apps is Pry. It has, in a word, REVOLUTIONIZED my ability to deal with problems in the code and drill down to figure out where pain points lie. If you’re not using Pry in your Rails app, here’s how to get started:

Add Pry to your Gemfile and specify that you’ll be using it for development:

Run  bundle install

Next, move into config/environments/development.rb file within your rails app and at the bottom of the file tell your app you want to use Pry in development:

Awesome! Now that we’ve got Pry installed in our Rails app, let’s put it to work. In my example, I want to investigate why a piece of code is breaking. Based on the output I see in localhost, I know that there is something wrong with my code around user.username = auth.info.nickname in my app/models/users.rb file. Username is throwing a NoMethodError, so I’m going to place binding.pry on the line above where my code is breaking. This will spring pry into action so I can investigate that line further when I relaunch my server.

Restarting the Rails server, recreate the action that causes your program to break. In doing so, you’ll notice a couple things: 1) The site will hang 2) The console shows you that Pry is at work and you can now dig down into the broken lines of code to see what might be wrong:

Within the terminal we’re now in Pry, so just like IRB, we can begin digging into what problems lie.

In my case, I had forgotten to add Username to my User table, hence the NoMethodError. As you can see in the example above, I have since fixed it.

I’m only scratching the surface of why Pry can do. There’s a lot more information their site, along with a great introductory video that will help get you started.

Trick out your Terminal with ASCII art

Terminals are basic, kinda ugly and wonderfully utilitarian. If you’ve ever thought about “tricking out” your terminal, there’s only so much you can do from the terminal application preferences pane. Changing the background and you can go all black window on green text, “super1337haxor living in the Matrix” style, but that’s as exciting as it gets.

Taking a few more steps, you can transform your terminal into a snazzy window, with awesome colors and welcoming ASCII art. This tutorial is aimed at Mac users that have Homebrew installed. If you’re on Linux, I assume you’re smart enough to figure it out.

Here’s how to go from dull to dazzling in your terminal window:

1. Let’s play around a bit. In the terminal, type:
brew install fortune

Once this has installed, in the terminal, type:

Keep running it and see all the awesome fortunes that you’ll get!

2. Next we’re going to install this awesome program for the terminal called lolcat. This will effectively make anything you type into a beautiful range of colors.

From the terminal, run this command:
brew install lolcat

Once lolcat has installed, try running
fortune | lolcat


Pretty cool, huh!

Let’s take it a step further — ASCII ART!!

Sidenote: This stuff is amazing. ASCII art has been around since the dawn of the computer age (or 1966, according to Wikipedia, when Bell Labs’  Kenneth Knowlton created the first known ASCII art). Originally used to print out images with characters before printers had the ability to print actual graphics, ASCII art has gone the way of the punch card and is largely relegated to the computer graphics graveyard.

Aside from ASCII art being totally rad, it is mad OG and using it in your terminal as I am about to demonstrate gives you about 1000 internet points. So there.

We’re going to be making ASCII art appear in your terminal every time you open up a new window. This is super simple. In fact, the hardest part is going to be deciding what ASCII art to choose. So let’s get started.

First, pick out the ASCII image you like. There are tons of resources online. My favorite is http://www.chris.com/ascii/

There is a plethora of amazing ASCII art. Case in point:

That’s right, people. Cher.

You’ll want to use your mouse to select the art you like. Copy it and move to the next step.

Next, open up your terminal move to you home directory. Type:

ls -a

You’ll notice a bunch of files appear, including a lot of files that are preceded by a dot(.) These are hidden files. Notice you have a file called “.bash_profile” (on Mac). If you’re on Linux (and probably Windows)  it’s “.bashrc”. You need to open up that file in your text editor. I’m using Textmate:

mate .bash_profile

Once you’re in .bash_profile, click on the empty space at the bottom of the page and type in this command exactly as written:

read -r -d '' VAR <<'EOF'

Paste in your ASCII art below this command. Don’t move it around! Even if it looks weird, just keep it as is.

On the line above below your ASCII art, write:

echo "$VAR" | lolcat

Save your file and then open up a terminal window. You should see your ASCII art in color! If it looks a little wonky, head back into .bash_profile and make minor edits to the ASCII.

Share your art in the comments!

Teach yourself Ruby on Rails

So you want to learn Rails? Well you’re in luck. There are a ton of resources online to help you do just that.

At App Academy we stared by reading the monolithic tome of OMGRAILSLEARNEVERYTHING, otherwise known as Michael Hartl’s Ruby on Rails Tutorial. Hartl’s tutorial is free, completely exhaustive and will definitely have you up and running with a beautiful Rails app. If you’re new to programming, Hartl will take you on a deep dive of Test Driven Development, Rails and putting your application on the web. It’s awesome, but it’s also extremely in depth and probably more than an absolute beginner can grok.

Here’s my advice: start with a  simple app that you can build in an hour. That both gives you the satisfaction of actually doing something and seeing it work AND help you understand the Rails MVC framework.

Try that a couple times and then spend a week or two with Hartl.

Here’s how to get up and running with Rails, from n00b to novice (that’s right, novice. Becoming anything more than that is going to take months of experience).

I’ve structured my advice around increasing order of time and difficulty. You can knock out the first three tutorials in a day. The last two will be more of a time (and brain) commitment:

1. Get down the basics of Ruby. Code School has an awesome and interactive free Ruby tutorial. Go ahead and play with it to learn the basics.

2. Build a URL shortener with Rails. This was a great tutorial and very easy to follow. It goes through the very basics of Rails and will have you up and running with your own URL shortener in about an hour. Warning: It does have a couple typos, so please check out my code on GitHub to see a working version.

3. JumpStartLab has some solid tutorials for learning more about Ruby and/or Rails. I highly recommend checking out the One Day Rails project. You’ll be building a blogger clone.

4. [OPTIONAL] Now that you’ve built that simple URL shortener, head back to Code School and complete their free course called Rails for Zombies. This is still a high level overview of Rails, but it is interactive, so it will test out your skill and help you get a clearer idea of how Rails works. This should take a couple hours to complete.

5. Move onto Rails Guide next. This tutorial may take you the weekend to get through. It’s more in depth and you’ll build a blog. If you’ve already done the JumpStartLabs tutorial, this will extend the features you created in that project.

6. If you’re still in the mood for more, check out Hartl. His guide is exhaustive. You’ll get a lot of information on test driven development (not covered in any of the other tutorials mentioned) and you’ll have built up enough basic knowledge to appreciate the level of detail he provides. Best of all, thousands of people have gone through the Hartl tutorial, so if you get lost or something starts mysteriously breaking, you’ll likely encounter an answer to your exact problem through a Google search.

7. Now go build something of your own! Good luck and happy Railsing!

Code Academy: A week in review

We’re just starting on our second week at App Academy and I wanted to share some thoughts on the first week.

Days are typically 12 – 15 hours long, with all kinds of coding in between. We started with 20 students and lost 2 (both women) in the first two days. The course is extremely demanding, and the couple days were a huge adjustment. It’s a bummer to see people not make it through the “sink or swim” environment.

The first two days we completed Test First Ruby and then moved onto understand API’s and building our own program to connect with the BART and Google Maps API. The week was rounded out with a deep dive into rails, which is extending into week two. We’ve also begun writing our own tests for our rails application, and learning test driven development has been pretty cool!

After forty hours of pair programming, I am unsure of its usefulness. Having pairs work together that have vastly different levels of experience leads to the more experienced driving the whole exercise. On one hand, it’s awesome because they can solve all your tough problems and get the project done. On the other hand, it’s bad because they can solve all your tough problems and you don’t learn by struggling through the problem (something I believe is imperative to learn). I vastly prefer the idea of working on the same project with others, but doing it by myself, going to the group when I need help. That’s not the philosophy behind App Academy, but I think that should be taken into consideration for the next course.

My social life has gone into hibernation, considering all the classwork I’m doing, so I hosted a Coding Brunch on Sunday with friends from App Academy and elsewhere. We made waffles, coded and had an awesome time!

Waffle Brunch! Photo by Rose Auravide.

I am looking forward to the start of week two. We’re switching our hours from 1 – 9pm to 11 – 7pm (yay!) and I’m liking toying around with Rails. We’ll be building a URL shortener using Rails this week, so stay tuned for more news on that.

Signs you might be a Ruby developer

I’ve been learning Ruby nonstop at App Academy and have noticed some interesting changes happening in my brain. Here are some signs you may be turning into a Ruby developer:

1. Gems are no longer those fancy stones to put in jewelry.

2. Dreaming of hunting down code, slaying arguments and searching for the ultimate treasure — ruby gems!

3. Using while statements and for loops for your everyday life. I often find myself doing this when I’m cooking (“While dinner is cooking, do set the table”)

4. Trying to fall asleep by telling yourself:

gem install "sleepytime"
require "sleepytime"

I’ll add more to the list as they come!