2013: More is Less

122110calvin_resolutionsThis year my resolutions are focused around the concept of “more” rather than “less”. I am not making any resolutions to lose weight, eat less sugar, drink less, watch less TV, eat out less… you name it. I’m chucking those out the window.

Instead I am focusing on the notion of “more”. I think taking an additive approach to my life is going to be more helpful than a restrictive one, and I believe that both accomplish the same thing. As mom always said, “It’s not what you say, it’s how you say it.”

With that in mind, I have one resolution for my health: Eat more whole grains and natural (unprocessed) foods

This just seems like a good, common sense idea. Good for my health, my body and may lead to some of those other benefits I mentioned above (weight loss, I’m looking at you).

With health covered, I’ve got another resolution for my mind and spirit: Write the next Great American Paranormal Romance Novel

Ok, that’s only partially true. I don’t know if I can overshadow the “opus” that was 50 Shades of Grey, but I think it would be a riot to try. I will admit, I find the paranormal romance genre to be fascinating (my once deep and dirty secret) and I’ve always wanted to try my hand at self publishing, so why the hell not. Plus, the barrier to writing anything palatable in this genre is EXTREMELY low. If you can hold a pen upright and have a coherent stream of thoughts, you’re 85% of the way to surpassing the drivel that pervades paranormal romance.

What have you resolved to do in 2013?

 

About these ads

2012: Rediscovering my love of writing

blank sheet in a typewriterI find it hard to avoid reflecting on the past year as I await the bells tolling in 2013. So much has happened, and I realize that 2012 was really the year of trying new things — BIG THINGS — and being totally ok with the outcomes of my adventures. If you’d asked me a year ago what I’d planned on doing in 2012, I would have said, “It’s the year I become a developer”. And yes, I suppose that did happen, but something else quite unexpected happened in the course. I rediscovered my love of writing.

Take a walk with me down memory lane…

After years of pining for a more technical position, I landed a highly technical contract at Yorba. It was tough work — I often spent my days doing serverside work, learning bash and triaging support requests. I managed the translation of their software into 50 languages and spend most of my days staring at code, trying to figure out how to get from A to B. I think a certain amount of fear is healthy when approaching your work, and I sure as heck was scared. But I learned a lot, and ultimately, I learned that I don’t really enjoy that type of work!

With my heart still in technical work, but more interested in the programming side, I spent a month at App Academy, learning Objective-C. And guess what– I hated it! Objective-C was not my cup of tea, so I jumped ship for the fairer shores of Rails.

And so I began my self study of Rails and consistently found myself more drawn to writing about my experiences in Rails than writing code. And that’s when it struck me — had I forgotten my true love? Writing had always been my dream, recently cast to the sidelines while I pursued other avenues. But there she was, so willing to let me pick her up again. I’ve always been a storyteller at heart — some of us tell stories through code, but my strength lies in the spoken and written word.

With that in mind, I’ve taken up a position running content marketing for a mobile startup. Coding is a hobby for me these days. He looks a little bit like a hillbilly third cousin, with banged up teeth, a bashful grin and wonky eyes, one bigger than the other. Not to say I don’t love him — he’s just a bit different and hard for me to relate to.

I never thought that through learning to code I’d rediscover my love of writing, but it happened. It’s been years since I’ve been able to say that I truly love and am challenged by my work, but that’s the truth! And ultimately, my interest in coding and in mobile technology has greatly benefitted me in my current position. If I hadn’t learned any Objective-C or Python or Rails, I wouldn’t be nearly as good at my job as I am. Funny how life does that.

always-make-new-mistakes1.jpg-w=490

My advice to you: Make lots of mistakes

One of the most memorable gifts I received for my birthday last July was an eraser from my boyfriend’s mom, Robyn. If Yoda came in the package of a beautiful and charismatic woman, it would be Robyn. On the back of the eraser’s packaging, she wrote, “Make lots of mistakes!” And so I’d remind you (and myself), that making mistakes is A-OK, trying and learning you hate something is totally fine. You are your harshest critic. So get over yourself and try what’s been scaring you. You won’t regret it.

mistakes

Adventures in shedding my smartphone

I got rid of my smartphone a couple weeks ago, sick of the high price of service and horribly battery life. I felt like I was paying $90 a month to use Twitter, and having to constantly charge my phone when I wasn’t running between work and home.

It seems easy enough, getting rid of your smartphone — until you realize how much we rely on them for directions, constant communication, restaurant reservations, photo sharing and I’m sure much more. Fact is this: I rarely call people, I’m not a heavy texter and I was using my smartphone primarily for the apps. I don’t work “on the road” so I am often in a wifi enabled workspace. If you’re like me, read on. I’ve managed to cut my phone bill drastically and not sacrifice all those services completely. Here’s how:

1. Pick up a good used dumb phone on eBay.

You’ll be hard pressed to find any retailer selling dumb phones these days. I opted to go with a Nokia 1100. This phone’s heyday was about 10 years ago, made primarily for the third world. It was an extremely popular phone at the time, has a couple weeks battery life and could be hit by a bus and still work. As far as I can tell, Nokia 1100′s were sold by TracFone in the US. When I received this phone in the mail, it didn’t come with a SIM card, so I put in an old AT&T pay as you go SIM, but no dice. After many failed attempts to unlock the phone, I called up TracFone and got a new SIM card. I’m tied to their service (MVNO running on AT&T), but it is relatively cheap. I bought 400 minutes for $99, and considering how little I talk on the phone or text, I don’t plan on going through these quickly.

My new (used) phone

2. Get an iPod Touch

I must admit, owning an iPod Touch is what really pushed me to dump my smartphone. After all, I’d paid $200 bucks for an iPhone without an antennae. Seemed silly to keep paying Sprint $90/month for the privilege of using their network.

3. Free wifi is everywhere (at least in SF)

Another big concern was finding free wifi. I’ve been very pleasantly surprised by this. All Starbucks have free wifi, as does BART. I don’t find it 100% of the time when I’m out and about, but I also don’t need to be online 100% of the time. Taking a break from Twitter/Facebook/email has been a really nice disconnect.

4. Offline maps

While I don’t often use Google Maps, it is a feature I need when I’m driving to far flung places. I was happy to find MapsWithMe, a free app that displays offline maps. It doesn’t do driving directions, but that’s why I have a pen and paper for.

5. Set up Skype for outbound calls
My rule of thumb is this — if there’s no wifi and I need to make a call, use the Nokia. Otherwise, use Skype.

Now that minutes cost me, I set up an annual subscription on Skype. This costs me about $30/year and lets me make unlimited calls (US and Canada) using my old phone number. This works on my iPod! As long as I have wifi, I can make phone calls using Skype, directly from my iPod, and save my dumb phone minutes for other occasions.

6. Set up Google Voice for inbound calls and texting

I decided to port my old number to Google Voice. I get all my texts through them and it handles my voicemail as well, so I am not charged minutes for someone leaving me a long message. Best of all, I can view voicemails and text through their iOS app on my iPod, so I don’t even need to touch my dumb phone (and incur charges) when I’m in a wifi enabled area.

I’m sure there are some people out there that are really tied to their smartphone. Maybe you take a million calls a day, or need to be connected. Admittedly my way is more complicated, and maybe not worth the time and effort to save nearly $100 a month. But I’m pretty sure the $1200 dollars I just pocketed will afford me a nice vacation :)

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′
end

group :production do
    gem ‘pg’
end

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.

Life After App Academy

As some of my friends know, I left App Academy a month ago to pursue my Rails studying full time. I’ve always subscribed to the idea of “failing fast” and in this case, I learned pretty quickly that Objective-C is not where my heart lies right now. I loved working on Rails projects and feeling stressed out by the program, I knew I had to take the leap.

Being a guinea pig for the first App Academy class was a very memorable ride. I do think that Ned and Kush are awesome teachers and are extremely dedicated to seeing their students succeed. In no way do I want to rag on them or all the hard work they’ve done, but being the test case does come with the expectation that you will be contributing to identifying bumps in the road and helping resolve them for future classes.

If there’s one thing I’ve learned spending 40 hours a week holed up in a room with other students, it’s that we all have very different styles of learning and what works for one person doesn’t work for another. I’ve always been a loner, preferring the solitude of a dark quiet room and a big bright monitor to work. My dream environment doesn’t exist in this setting, and that’s something that was fairly challenging to adapt to.

Class environment aside, pair programming as a learning tool has its own set of challenges. At first I thought that pair programming was primarily about skill matchup, finding people that were perhaps similar to you in skill, or could teach you. But what I learned through the process, is that pair programming is a lot more like dating. This is about personality fit and finding that person you click with. There were a couple people I really did enjoy pairing with at App Academy. But as much as I liked working with them, I kept finding myself wanting more “me time” to tinker. I didn’t want the pressure of getting a project done, I wanted the ability to explore and poke around, make mistakes and get back up. And what I learned is that if you’re in a 9 week program that is looking to pump out developers, there isn’t really any time to explore. Where I wanted depth and strong foundations, intensive classes by their very nature are heavily project focused, preparing students to have a breadth of knowledge on a variety of topics.

I think that teaching Objective-C as a first or second language is a very tough route to take. I kept finding myself missing the good old days of Ruby and Rails, where a lot of the magic of programming is automatically taken care of. If Ruby is like learning Spanish, then Objective-C is Klingon. If anything, I’m more emphatic now than ever before that Ruby should be the first language an aspiring programmer learns. The folks at App Academy seem to have realized that as well. They’re not giving this course again, instead opting to focus on Ruby, Rails and web development work for future classes (smart choice!).

Having said all that, there are still 16 awesome students left in the program and are about to complete App Academy. Many of them come from a Computer Science background or have some technical prowess already. The fact is, this type of program does work for some people.

Of course the things that I miss are the camaraderie, the ability to call over our teacher and bug him at any moment (now I have Twitter, Stack Overflow and my boyfriend for that!) and working with others on the same challenges. And while the going is slower on my own, I have time to digest knowledge and really, truly understand it at my pace. I might just be a junior Rails developer today, but I promise you I’m going to kick some Rails butt as I advance!

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:
fortune

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

Image

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:

EOF
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!