After 4.5 awesome years at Dubberly Design Office, I’ve decided to leave my job. In two weeks, I’m headed down to a little internet start-up called [Google]

It was a terribly difficult decision to make. I’ve been quite happy at DDO. I didn’t like the idea of commuting to Mountain View. I also wasn’t sure about Google’s relationship with design. In the end, the folks at Google really impressed me and I decided to join.

I’m thrilled. I’m excited. And, I’m a little nervous—going from a 12-person company to a 26,316-person company will take getting used to. Let’s hope I can make an impact!

If you’re curious, here’s the portfolio that helped me land the job: http://chanpory.com

If you want to follow what’s going on with me, circle me on Google+!

I’ll also try to find time post on here again. Perhaps, on the Google shuttle bus. ;-)

Cheers for now!

[20]: http://blazingcloud.net/ “Sarah Allen”

We also learned about “associations” or how to make separate database tables relate to each other. For example, if you’re making a contacts application, you’d probably want a People table to relate to an Addresses table. Dealing with tables and associations were traditionally a huge pain in technologies like PHP, but Rails makes it so easy.

What works

In my previous diaries, I focused a lot on the class rather than the content. Today, I’ll spend a little more time talking about Rails itself.

Less typing

The beauty of Ruby on Rails is its conciseness. It’s as if Rails read The Elements of Style as a pimply teenager in high school and took it to heart while growing up. The resulting D-R-Y philosophy is so apparent in Rails, I found myself asking, “Really? That’s all I have to type?” The answer was, “Yes!”. I even heard a classmate say, “In Java, this would have taken ten times more code to write.” For lazy and dumb programmers like me, this is awesome.

Getting real

The best part of learning Rails is making applications that do real things. After years of faking things in Photoshop and Illustrator, it’s so much fun to make something work in a short period of time. I just feel like I’m really creating, not just imagining. It’s also great to gain insight into how web applications are put together. It’s like getting to look under the hood of a BMW, and knowing how all the parts fit together and why.

What doesn’t work

Lack of good documentation for beginners and designers

Sarah recommends Agile Web Development with Rails and Rails Pocket Reference as resources for more on Rails, but admits she hasn’t found a good guide for absolute beginners yet. (Open-sourced software is notorious for poor documentation.) I suppose you’ll have to take her bootcamp class.

Yellow Cab fiasco

Two students had to wait two hours for a cab to get to class. What is up with taxicabs in San Francisco!?

The bottom line

Rails is fun to learn and to use. For designers who are serious about designing for the web, a class like this is a must. Even if it’s just to know how applications are built.

All Bootcamp Diary Entries

Rails Bootcamp Diary: Day 1

Rails Bootcamp Diary: Day 2

Rails Bootcamp Diary: Day 3

Rails Bootcamp Diary: Day 4

What works

Context and the big picture

For me, it’s vital to understand the big picture when learning a new technology. So kudos to Sarah for explaining the history and rationale for Rails: to let programmers worry about real application features rather than common development tasks. This means less typing, less configuration, and easier debugging. And more time to design and test.

Hands-on fun

After the quick intro, we created our first skeleton app with just one line of code. It’s really satisfying to create an app and begin interacting with a database within minutes. Amazing. For the rest of the day, we edited View templates and Model files (the M and V of the M-V-C application mode). Since we haven’t covered Controllers, I’m still not totally sure how it all works together. But, I know it’ll make much more sense by the end of the week.

Clear explanations

Sarah did a great job explaining each step as we tried them out. I particularly loved the walk-thru of every directory and file types within a standard rails app. She also did a good job of pointing out common pitfalls and best practices.

Q & A

The last hour of the class was reserved for questions and answers. This gave us the chance to get clarification on any confusing points from the day.

What doesn’t work

Location still sucks

Even with the cab stipend, it’s still a pain to get to Marakana. The facility is set between the projects and industrial barrenness, so we have few options for walking around during lunch. Thankfully, food is provided. Though, we have little common area to sit, eat, and talk.

Set up could be smoother

We spent about 30 minutes at the beginning of the class just making sure we had the right version of Rails, Heroku accounts, and the required dependencies. We did get some instructions by email before the class, but not every step was included.

The bottom line

Today’s class was inspiring, well-structured, and clear. All the pain from the previous two days prepped us, but it was also Sarah’s ability to communicate the material that really helped in understanding. A great class, but please move Marakana fast.

All Bootcamp Diary Entries

Rails Bootcamp Diary: Day 1

Rails Bootcamp Diary: Day 2

Rails Bootcamp Diary: Day 3

Rails Bootcamp Diary: Day 4

• Blocks and yielding
• Procs and Lambdas
• Enumerators
• method_missing
• Regular expressions
• File input/output

I absorbed only about two-thirds of the material. Ideally, we’d have more time to explore each concept. But I guess that’s why I have Google and foggy San Francisco nights. Yes, Ruby’s gonna keep me warm, baby.

Despite the frustration of cramming everything into two days, I’m falling in love with the Ruby. It’s intuitive, easy-to-read, and a lot of fun. I wonder how I ever mucked around in PHP, Perl, and Javascript. Most of my classmates seemed to enjoy Ruby as well. Although, those familiar with Java and ActionScript 3 found the concept of “dynamic typing” a bit odd. Don’t even ask me to explain what that means right now.

I’m excited for the rest of the week where we”ll dive right into Rails. This is where I’m hoping the fun will explode.

Oh, an aside comment: San Francisco cab companies are horribly slow to arrive. So call early, if you want to get anywhere on time.

All Bootcamp Diary Entries

Rails Bootcamp Diary: Day 1

Rails Bootcamp Diary: Day 2

Rails Bootcamp Diary: Day 3

Rails Bootcamp Diary: Day 4

I’ve just completed my first day of an intensive Ruby on Rails bootcamp. No, I didn’t get to wear a uniform, don macho combat boots, or get yelled at by angry drill sergeants. But I do get to fumble around in a shell terminal, which is just about as painful (and I suppose kinda sexy, too).

Here’s a recap of the first day:

Let’s start with some pictures

Quick stats

• Taught at Marakana’s facility in San Francisco
• All day from 10am to 6pm
• 11 Students
• 2 teachers
• 1 TA
• No rooftop access for lunch (lame)

Why the hell am I in a programming class?

For the past 10 years, I’ve worked as a visual and interaction designer within a painful waterfall process like this:

1. Gather requirements
2. Create wireframe turn it into specifications book with a billion pages
3. Create Photoshop PSDs with a billion layers
4. Send to engineers, and pray it turns out how you hoped

This process is painful. It’s slow. It’s expensive. And it’s demoralizing, since most projects get killed before the engineering process. 90 percent of the projects I’ve worked on never even made its way to a browser window or desktop.

Then I read 37signals’ Getting Real, a treatise on rapid software development. I drank the Agile kool-aid and decided the flavor is good. Two years later, I’ve convinced my bosses to pay for a programming class. So here I am getting down and dirty with Ruby on Rails.

My hope is to unstuck the traditional design process and learn how to create dynamic prototypes which users can actually touch and use.

Class structure

The class starts with two days of Ruby, followed by three days of Rails. The Ruby part is taught by Liah Hansen and the Rails part by Sarah Allen. Both work at local development agency, Blazing Cloud.

Today’s Ruby began with an overview of test driven development, creating classes, defining methods, and string manipulation.

What works

Diverse classroom

I loved seeing that most students were from out of town. Students came from as near as Portland, Oregon and as far as Switzerland. Since software development is a bit of a boys’ club, it was also refreshing to see about 40 percent women in the class.

Project-based

I’m a huge fan of Why’s (Poignant) Guide to Ruby, which introduces Ruby via a hugely entertaining, though insanely weird, narrative. It’s more of a reference book, so it doesn’t walk you through creating a program. In today’s class, however, I got started creating mini Ruby programs immediately. It’s very satisfying to make something work!

Relatable instructor

Liah is very approachable, friendly, and interactive. She’s collaborative and behaves more like a peer. She’s definitely not a drill sergeant.

Display mirroring

I sat at a desk with my friend and DDO colleague, Sean Durham, who’s also taking the class with me. Each pair got their own table with a monitor in the center, which mirrored the instructor’s display. I’ve never seen this type of setup before, and it was great to see exactly what the instructor was presenting.

What doesn’t work

Location

Marakana is way out in San Francisco’s industrial district past Potrero Hill. It took two busses to get to the facility, a converted live/work loft. Fortunately, I just found out the course includes a $36 a day taxi stipend. Maraka is looking for a new space downtown. Let’s hope they move soon.

Not for absolute beginners

The class moves pretty quickly, and it does assume you have some programming knowledge. If you’ve never touched any kind of code or markup in your life, you might get lost. My previous experience with Javascript and PHP definitely came in handy. Check out _why’s guide if you need an absolute beginner’s tutorial.

Needs better metaphors

The course reader so far is bland and lacks any narrative or thread to tie the concepts together. I wish the course adopted some of the brilliant metaphors for programming concepts in _why’s guide. This would help aid memorization and foster a deeper understanding of the Ruby language.

Should be team taught

The class is large with 11 students. (Marakana’s competitor, AcademyX, has an average of five per class.) With this many students, the class could be team-taught. Liah’s had about a year of Ruby experience, so it’d be great to pair her with someone who knows Ruby like a mad man. This would help answer more advanced questions and also provide even more direct interaction. If only _why hadn’t vanished. He’d be perfect.

The bottom line

Today’s Ruby class was fun, hands-on, and collaborative. I love the project-based approach, but I yearn for a bit of jazz, sizzle, and bang. With a little more pathos, the class would really resonate and could turn into a hit.

All Bootcamp Diary Entries

Rails Bootcamp Diary: Day 1

Rails Bootcamp Diary: Day 2

Rails Bootcamp Diary: Day 3

Rails Bootcamp Diary: Day 4

Need examples of witty writing with few words?

Check out The Listings in The New York Times’ Weekend Arts section. You’ll find some succinctly superb snippets under Long-Running Shows. Here are my favorites from last Friday:

Billy Elliot The Musical
Ballet dreams in coal country

Mamma Mia
The jukebox musical set to the disco throb of Abba

Chicago
Jazz Age sex, murder, and razzle-dazzle

West Side Story
Romeo on Juliet’s fire scape, once again

Wicked
Oz rivisited

Mary Poppins
Supernanny

What are your favorite examples of ultra-short writing that packs a punch? Share away.

I’ve been trying to order an iPhone 4 since 1am this morning. But AT&T’s crappy networks and Safari’s session expirations were preventing me from getting closer to My Precious. Thankfully, the new Apple Store app on the iPhone worked like a breeze. It took me two minutes to pre-order. Give it a try.

After you make the reservation, the app might give you an error if try to reserve another one. So I guess it’s one per customer.

Your portfolio doesn’t need extra doodads, tassels, sequins. If your design work and writing is awful, it’s still awful no matter how much you dress it up. And since student work almost always is terrible, I’m much more interested in your enthusiasm, how well you think, and the quality of your writing.

Good portfolios are simple, unassuming, and relatively cheap to make. Even a humble wire-o bound portfolio works. Big images, lots of process work, readable type, and good writing is all you need.

So if you’re a student, don’t shell out $400 dollars to make a precious museum-piece portfolio. Instead pay down your student loans, or spend the money on an HTML/CSS class.

It’s old, but here’s my portfolio from ages ago.

Not.

Turns out, all it did was stress me out at home and on the weekends. There’s always an annoying email about a problem I can’t do anything about since I’m not in the office. And usually, the sender finds another way to solve the problem.

More emails just meant more worry.

So, this weekend I’m completely separating my work email from my personal email. If there’s a real urgent need to get a hold of me, then call me. ;-)

After looking at all the jobs I’ve had, I realized one thing: when I stopped learning, I became much more keenly aware of other job factors like salary, office space, and vacation time. Boredom makes it way easier to obsess about money and perks.

The jobs where I learned the most were the ones I stayed the longest. I’ve been at DDO for over three years and expect to be here for a long time.

Why?

Because the office has a culture of learning, sharing, and mentoring. We even get an education budget every year. Free classes? Hell yeah.

A job that teaches you keeps you interested. It also makes you nimble and adaptable when major changes happen—like a downfall in the economy or a shift in technology standards. This versatility makes you more employable now and in the future.

Of course, money and perks matter too. But they’re not permanent. The skills and knowledge you learn on a job stick with you for a lifetime. The education you gain can’t be taken away from you.