A Developer's Journey

How Employee Equity Works

Employee equity has always been a nebulous topic for me. Every time I thought I understood how it worked, I would read or hear something that made me question my understanding. Thank goodness people like Fred Wilson exist. He is a venture capitalist, blogger, and a budding professor. The video I embedded below is Fred Wilson explaining Employee Equity to a classroom full of future entrepreneurs. The video is 70 minutes long and is very thorough so if you want an expert in the field to walk you through how Employee Equity works (and some of the tax implications), I urge you to watch the entire video.

If you're short on time and you're an employee with options, the first 30 minutes will suffice for a basic understanding. If you're an entrepreneur, you'll still want to watch the last 40 minutes of the talk since it's more about strategy of how to structure your company's employee equity.

The reason I didn't simply tweet out the link to this video is because I wanted to list some of the topics that he provided clarity to for me. Below is a brief recap of what I learned.

Restricted Stock vs. Options

Founder stock vs. restricted stock vs. option grants were a point of confusion for me in the past. Mr. Wilson does a terrific job differentiating the three as well as providing great examples for when a company would give out each of the three. I'll try to give my best summary of what he said:

Founder stock - when the company is formed, it's most likely worth nothing so it's most economical to divvy up the shares at the beginning (which is actual ownership) and pay the taxes up front for a nominal amount.
Restricted stock - typically this stock is only given to early employees. Just like Founder stock, this stock is comprised of actual shares of the company and is immediately taxable. Restricted stock differs from Founder stock as it usually has the same vesting provisions as Options (i.e. 4 years, 1-year 25% cliff).
Options - what most non-founder, non-early employees receive in terms of equity. As mentioned above, Options come with vesting provisions. The biggest difference, however, is that Options aren't actual shares of the company - Options are a right issued to you to buy a certain allotment of actual shares at a set price (also known as 'strike price').

I'll play out an example of how Options work:
If a company had a valuation when it was just formed, each share would be worth next to nothing. If the company then received an Angel or Series A round, the investors would value the company to determine how much of the company they own based on the valuation divided by their investment. As a result each share would now have a value. For the sake of this example, let's say each share is worth $.50 now. If you were to join the company at that moment and were issued options (let's say 10,000 options), your strike price would be $.50 per share. If you stuck around for four years and vested all your options and your company was bought at a much higher valuation, say $5.00 a share, you could exercise your grant of 10,000 options and pay $5,000 to own those shares (10k options x $.50 strike price), which you could turn around and sell for $50k at a $45k net profit. Savvy? It's important to note that striking on your options is a taxable event, which is why most people wait until the options are valuable (i.e. your company goes public) before they exercise their right and deal with the tax implications.

One last thing about Options. The quantity allotted to you in your Options grant is entirely relative. 10k options at one company could be worth less than 1k options at another. Outside of vesting, there are three variables in the Options value equation: quantity (# of options), number of outstanding shares in the company, and company valuation. If you're company is worth $50mm and there are 10 million outstanding shares in the company, each share is worth $5. When you exercise your options, the options in the employee equity pool become shares with real values. So if someone offers you Options at a company, it's very important to take into consideration the current value of each share (if the company is willing to disclose that information).

Dilution

When you start a company, you own 100% of the company. As soon as you start hiring people, you're going to need to give away equity and, as a result, your ownership of the company dilutes. If you hire a co-founder as your company is forming, your 100% would likely become 50%. After hiring your founding team, you could be down to 40%. If you receive a round of fundraising, it will dilute more and so on. Generally speaking, dilution appears as something you would try to avoid. However, that's not always the case.

The biggest takeaway I had from this video about dilution is that your ownership diluting is not a bad thing if the event that caused the dilution adds more value to your company. Quick example. Let's say you own 40% of your company and it's worth $1mm before funding. Your investors put in $250k for 10% of your company at a $1mm pre-money valuation. Your shares dilute 10%, which brings you from 40% to 36%. Before the round, your 40% is worth $400k. After the round, your 36% is worth $450k (1.25mm x .36). So not only do you have $250k in the bank for your company to use, you just added $50k of value to your share of the company. More money for you, more operating money for company. Dilution - not so bad after all.

For supplemental reading, check out Fred Wilson's Employee Equity blog post. Also, I should disclose that I'm not a lawyer or accountant so please consult a professional about anything tax-related.

Chrome Developer Tools Tricks & Tips

If you're a web developer and you have spent time writing JavaScript and/or styling with CSS, odds are you're familiar with Chrome Developer Tools (CDT). When I discovered CDT, my front-end productivity sky-rocketed. Editing CSS on the fly, inspecting HTML, and interacting/debugging with the page's JS console have become more engrained in my day-to-day workflow than any other development tool I use. I love TextMate, but if someone put a hypothetical development gun to my head and asked me to choose between CDT and TextMate, I would be asking around for good a Vim tutorial if you know what I mean.

Quick disclosure: all of the tricks and tips below have been tested with CDT, but there's a chance they won't work with FireFox's Firebug Add-on.

JavaScript Debugging

There are three very useful tools in CDT to debug your JS. The first is the most obvious - the interactive JS console. When you open up the developer tools (⌘ + Alt + I), the interactive JS console resides with the 'Console' tab. You can also press (⌘ + Alt + J) to dual-load CDT and the console tab. This console allows you to interact with the page's DOM. You can execute any JavaScript you want here and also interact with objects (like the window object or any local objects you've defined) and inspect their contents/functions. One important note is that when this console loads, the DOM has loaded as well, which means if you're using jQuery and it's working on the console, but not in your source file, you're probably missing a jQuery $.ready() wrapper.

The second debugging tool is fairly new to me. If you click on the 'Scripts' tab and choose one of the JS files included in the page, you're able to add breakpoints to the code by clicking on the line numbers. Once the breakpoints are added, you can step through every breakpoint. It can be tedious tracking down the code you want to put the breakpoint in if you have many files. It's especially painful if you're writing in CoffeeScript as the line numbers you're editing in your .coffee file differ from the compiled line numbers of the same .js files (what you see in CDT).

Last week a colleague of mine, Wilson Collado, told me about the 'debugger;' call. If you put 'debugger;' in your JavaScript, it's the equivalent of putting a breakpoint through the scripts tab. It's a really useful trick that can save you a lot of time. One last thing about the scripts tab - make sure you take a look at the call stack information panel (located on the right side of CDT's scripts tab). In this panel you can also inspect all the local variables at the time in which the breakpoint/debugger was reached. Very helpful when stepping through your JS.

I would be remiss if I discussed JavaScript debugging and didn't mention the 'console.log()' function. In your JS, you can pass any object to console.log and it will print out the object on your console when the code is executed. You can then inspect the object to look at its value/properties. Simple, but very useful. In addition to log(), console also has warn(), info(), error() and assert() functions. Assert is really nice as it will evaluate the contents of whatever is passed into the function as a boolean. Beware that leaving in console calls will break your JavaScript in Internet Explorer, so make sure to take them out before you commit your code.

HTML/DOM Tricks

If you right click on any part of a website in Chrome (with the exception to a website built in Adobe Flash), there's an option called 'Inspect Element'. This is any front-end dev's bread and butter. You can view/edit HTML, traverse the HTML hierarchy, view CSS for any HTML element...the list goes on. For the most part, inspecting the HTML is elementary (yes, pun intended), but did you know that if you select an element, go to the console, and type '$0' - the last element you inspected is now tied to that variable? I didn't. Will User dropped that gem on me last week. The $ command dumps previously selected nodes, try typing $2, $3 and so on.

Here's another one that is news to me. There are certain CSS selectors that are used on every custom-styled button (or link). They are ':hover' and ':active'. If you have a button that is supposed to change it's image when you cursor over it or press it, you're invoking one of these selectors. It's a pain to style them though because when you hover over the element, the CSS properties show but you can't edit them without moving your cursor over to the CSS property (it's hard to explain, just try to do it and you'll see what I'm talking about). Enter the 'Toggle Element State' feature. In the CDT CSS pane, click the 'Styles' arrow and then click the button with the dotted square with a cursor in the center of it. Now you can toggle these selectors. See below:

Console DOM Tips

Lastly, let's go over some tips that involve both the console as well as the Document Object Model (DOM). Fire back up that console press (⌘ + K), which will clear the console. Grab an element off the DOM with jQuery (or do $0 if you've recently inspected something). Now call 'dir()' and pass in the element. As you'll notice, 'dir()' will print out every attribute/property that exists for the element. There are definitely some properties I didn't even know existed after using it for the first time.

Let's say you're generating something on the console. Maybe a calculation or you're scraping a page for some text. Did you know that you can pass in JavaScript to the 'copy()' function and it will copy the result of the JavaScript to your clipboard? The potential uses are probably not obvious, but it's another solid tool to keep in that JavaScript debugging toolbox.

If you have some CDT functions/tools/tricks that I didn't list, please share them in the comments.

Design Inspiration

Being inspired is one of the strongest types of motivation for me. When I see something great, I can become inspired to build something of equal caliber or at least put more effort into what I'm currently working on. Sometimes the execution of an idea can be just as inspiring as the idea itself. One great example of this is Path. The more you use their app, the more you can appreciate how much attention to detail was involved in building the app. Every interaction, every pixel, is perfect. It's hard to put into words the experience that is felt when you use something and everything is just 'right'. It's not easy pouring over every detail like that, but so much satisfaction can be derived from watching someone use something you built and everything working perfectly.

So just in case you need some inspiration, here are some websites and Dribbble shots that I find inspiring.

www.BlameStella.com

Other than giving thredUP a great score, Stella's website has non-obtrusive tones that emanate an inviting feeling. It's refreshing to see a website that isn't exploding out with 20 call to action buttons.

www.1minus1.com

I love the graphics on this site. A carefully crafted back-end is just as important as a pixel-perfect front-end and the illustration of design and development being poured together into a funnel is a great visualization of this.

Fork CMS

When I'm looking to use a new library, gem, or application, I find that the presentation of the product impacts my judgment towards my willingness to give it a try. Fork CMS is a great example of this. There's no reason for me to use a new CMS, but after visiting their website I wanted to download it and give it a try anyways.

Dribbbles

Now it's time for a couple of Dribbble shots. This Twitter share shot is awesome for a subtle reason. Twitter makes it very hard to change the style of their Tweet button. You can do a custom button that links to Twitter.com with a pre-built Tweet message, but the pop-up tweet only works with their button/widget. This person designed around the button, instead of re-designing the button itself, which keeps the best functionality intact while making the developer's job easier.

No explanation needed for this one, I just think it's awesome and would be a really cool login interaction.

I'm not embarrassed to show the inspiration (or exact copy) of my work portfolio design. I was brainstorming the best way to allow users to interact with my professional experience on my website and a colleague of mine sent over this Dribbble. The UI looked so cool that I wanted to code it up just for the fun of it, but I liked it so much that I ended up keeping it.

A lot of these websites were discovered on line25's Websites of the Week series. It's a great RSS feed to follow if you're a fan of web design. If you have any websites you would like to share, please link to them below in the comments.

New Additions for your Rails Toolbox

One of the biggest advantages to using Ruby on Rails as your web framework is the open source community. They unselfishly release new gems every day. They build the best tutorials for free and they commit to the latest Rails builds on a daily basis. The only variable left in the equation when you're building a Rails app is knowing what tools to use when approaching a project implementation. Having a solid toolbox at your disposal is essential to furthering your professional development as it allows you to take on more challenging projects that are outside your comfort zone.

When I first started developing with Rails, I was blown away by my CTO's ability to nonchalantly take on challenging projects. The project or feature would seem outlandish and at times borderline impossible, but he would say something like "we'll figure something out" and somehow he always did. It seemed like magic. After watching closely for many months, I came to realize he had three things: a positive outlook, a solid toolbox, and a creative imagination. The combination of the three were a potent arsenal for tackling epic projects. He wouldn't think about why it couldn't be done - he would start in the ideal world that everything's possible and begin brainstorming from there.

Having a good outlook and creative imagination is not something you can attain from reading a blog post, but you can always add more tools to that handy toolbox. Here are four new additions to my toolbox; hopefully one of these will help you one day when you come across a new project.

Storing your ActiveRecord Objects in Redis

Link to article →

Speed is important. Rails contains a fair amount of overhead and it's considered one of the harder frameworks to scale. It isn't an issue when you're website is small, but as you grow you'll discover some of the earlier code that was written in your app won't hold up as the user base grows. This results in feature re-writes and becoming more clever with your implementation. One of the first tools to reach for when attempting to speed something up (outside of profiling your DB queries) is cacheing. We use memcached at thredUP, but the problem with memcache is that the data isn't persistent. If your memcache server goes down, you can lose all the cached data within it. This makes memcache only feasible for information that can afford to be lost. What about data that needs to be written to the DB? You can't reliably do it with memcache, but you can with Redis.

The tool I linked to above is a gem that the fine folks of Gowalla, recently acquired by Facebook, wrote to accommodate quick writes and reads of an ActiveRecord object. Their example is 'liking' something. You have to be able to like something quickly and pull back information on that like such as how many others have liked it and who they are. Personally I've been wanting to re-write thredUP's in-house notification system for a while as it hits the database on every logged-in page load and this is going to be the first tool I reach for when that time comes.

Converting Dates Between Ruby and JavaScript

Link to article →

This one is very straightforward. In multiple parts of our app, specifically areas of the app we're doing background AJAX polling, our JavaScript scrapes time data off the DOM (like timestamps of objects stored on an attribute of a div). The problem is that JavaScript's time (local) and our server's time (GMT) are in different time zones. The link I listed above will give you a quick and easy way to go back and forth from Ruby's time class to JavaScript time class.

Lazy Evaluation and Method Chaining

Link to article →

Most people know about method chaining in Ruby, especially within the context of ActiveRecord methods. Most people also know that an ActiveRecord call does not hit the database while it's still an ActiveRecord::Relation object, which is an example of lazy evaluation. The real tool comes from using both of these together.

The best example I can give is compound filtering. If you go to an e-commerce website and select 'Sort By: Lowest Price' and 'Gender -> Men', those are options that will compound to filter your results. One way of implementing this is having a nasty 'if params[:sort] = "Lowest Price" && params[:gender] = "Gender"' block for every possible filtering scenario. That is obviously not ideal. But if you were to add some named_scopes that build conditions for each individual filter and method chain all the compounding filters onto a ActiveRecord::Relation object that executes its call to the DB at the end, then that would be a clean way of doing it.

ActiveRecord Key Value Stores

Link to article →

Key value stores are awesome. They're super simple and super fast. To get geeky for a second, searching with key value stores in big O notation have a time of O(1) (that's the fastest). I like to hack together Hash look-up objects in Ruby all the time to speed up checking whether a ActiveRecord ID is in a collection. The alternative is using an array (assuming it can't be looked up in the DB) and even if the array is sorted and the array look-up call is using a simple B-tree algorithm, the notation is still O(log n). You just can't beat key value stores for look-ups.

The link I referenced is leveraging the method_missing method of a class as a way to arbitrarily set key values. I would never use something like this on a heavily used model such as User as using method_missing like that is dangerous, but it does make sense in context of ApplicationSettings. Either way, it's a clever implementation for dynamically setting class attributes and it opens up your imagination for ways in which it can be used.

Have a tool you would like to share? Post it below in the comments!

Asana

thredUP has been using Basecamp as our project management tool since before I started in September of 2010. We're an agile development team and it's important for us to have a collaboration tool to manage our user stories as well as organize our projects/sprints. Our sprints are two weeks long. We develop for the first 10 days, test the code on staging servers internally, iterate, deploy the code, reflect with a retrospective, and then move onto the next sprint. We move very fast and it requires a lot of organization.

All of our stories start in a 'Backlog' list, move to a 'Work in Progress' list when development has started, and finishes in 'Review'. Stories, which are essentially a task within a list, shuffle in and out of all these lists during a day and entire lists are often re-arranged to accommodate for a shift in priority. Tasks and list order stay in a constant state of flux and a vast majority of the communication that occurs during the chaotic flux resides in Basecamp...until recently.

After our CEO and CTO played with Asana privately for a month to explore its capabilities, our entire team switched over to their service at the beginning of the year. Based on the feedback from the team, it doesn't look like we're switching back anytime soon.

Comparison

First, let me go over the basics. Asana is free. Basecamp's prices range, but I believe we're paying something in the neighborhood of $149 per month.

Second, and more importantly, Asana is real-time. When a co-worker of mine is editing a task, note, project, etc. and I'm on Asana too, I can see all the changes happening live (like Google Docs). Basecamp doesn't have this feature and it's a shame. When there are 30 or 40 tasks within a project and one person is re-prioritizing, Basecamp becomes a synchronous tool that can't be used until the re-ordering is done for fear of conflicts. In Asana, everything is happening right in front of you so you can go about your business and work asynchronously with your co-workers.

The third advantage Asana has over Basecamp is the way they embrace HTML5 and JavaScript. Sure Basecamp uses AJAX for some of their tools, but Asana is built on top of their in-house Luna framework. For all intensive purposes, the experience is that once Asana loads in the browser, no page refreshes occur afterwards. I know this is the not the case (because they aren't using URL hashbangs), but it is indeed the experience. In addition to this, just about every element on the page is HTML5 draggable and editable. Any project or task can be re-arranged by dragging and text can be edited by simply clicking on it. There are no save or edit buttons, you simple just 'do'.

Lastly, the biggest edge Asana has on Basecamp is the UI. Sure it's pretty (see below), but its practicality is superior. In Basecamp, traversing through different projects is a huge pain. If you want to view a task's details, you start at your root dashboard and then you select a project to enter. Then you select the To-Do list you *think* the task you want is in. Then you select the task. Basecamp Dashboard -> Project -> To-Do List -> Task. 4 pages to see the details of the task (and you can't do any re-arranging once you get to the task). Asana took a different tack on project traversal. Asana's UI utilizes a sliding 3-pane layout. Projects on the left, lists of tasks in the middle, and task details on the right.

Asana makes traversing through projects, lists, and tasks a breeze. The sliding panes are not fixed widths either; whichever pane your currently focused in becomes larger and the other two dynamically slide to smaller widths.

There are other tools that Asana has that I'm still learning. For example, you can add tags to tasks. Our development team has split into 3 separate teams to tackle the projects at hand. We have a tag for each team and every task that is designated for a team receives the corresponding team tag. Why is this useful? Because you can sort by tags. Asana gives you the ability to have dynamic sorting, which is quite cool when you think about it. They also have a list of keyboard shortcuts and mark-up syntax that I'm learning so I can work even faster within Asana.

Downsides

It's hard to blame them since the company is so young, but unfortunately Asana does have some inadequacies. The first noticeable one is a lack of a developer API. We didn't use Basecamp's API often, but we did use it to scape every To-Do list for each sprint to determine our development team's point velocity - a useful tool when trying to determine how much our team can chew through in a given 2-week sprint.

Next, 37signals (the makers of Basecamp) offer a suite of products. Our development team uses one of their products called Campfire, which enables all of our developers to chat in real time. Because of Campfire's API, we're able to pipe in every GitHub commit into the chat so our developers know what code is being committed at all times. This is an incredibly useful feature that will keep us using Campfire regardless of whether we leave Basecamp for good.

Lastly, I've found Asana cumbersome for long-form discussions. The notes section for a task is small and comments on a task collapse after a certain size, which makes it hard to see everyone else's feedback chronologically. I'm sure that's by intent, but when we release our sprint testing steps internally to our team, they are typically long and detailed. Emails aren't a good alternative for testing steps and we avoid them like the plague as email threading quickly breaks down when there are 10-20 responses. Hopefully they will have something to alleviate that pain in the future. I know one thing is for certain, if Asana can continue to execute with the quality of their first public version, they are going to be a very promising company.

Contrarian Development Philosophies

After spending the last 6 hours catching up on Build & Analyze podcasts (one of the few podcasts that I never miss an episode of), I'm compelled to write down some thoughts on the development philosophies that were discussed.

I listen to the show for one reason: when Marco talks about certain development topics, I find myself utterly riveted by his logical reasoning. It's obvious that he thinks critically on every problem so when he talks about one of these topics in detail, like how he scales Instapaper, he starts with providing enough background for everyone to understand the problem. Then he proceeds to systematically deconstruct the problem and describe the available solutions. After he states which one he chose, he walks you through his solution and the way he arrived at that solution. I've found it to be very helpful for improving my own problem solving skills.

Now onto the topics I've come across through Build & Analyze or Marco's blog that I think are contrary to the industry standards for development teams.

Create the optimal, productive development environment

In a recent episode, Dan and Marco discussed the different ways to setup an office for a development team and some of the tips they had for people to be productive in those environments. They talked about wearing headphones to block out audible distractions or making sure your desk isn't pointed towards the door as you'll be momentarily interrupted every time someone walks in and you instinctively look to see who it is. These are two good tips, but the general theme is eliminating distractions so you're able to focus for longer periods of time.

Here's the thing: at a start-up, the only thing that matters is results. Unlike bigger companies, you don't have to worry about office politics, insane HR requests (I wasn't allowed to wear headphones when I worked at Toyota), or bureaucratic policies that make it harder for you to do your job. Start-ups are meritocracies. If you're twice as productive in a coffee shop then you are in the office, then work there. If you code best at night, then re-arrange your schedule to put the bulk of your work hours in those late night time slots. Ultimately, your bosses will know whether you're producing or not and if you really are more productive in certain environments than others, than make the change and prove yourself. As long as you can balance your team's responsibilities (team meetings, bug fixes, etc.) then it's best for the team and the company for you to utilize your hours in the most efficient way possible.

Whatever works best for you

Marco actually has a post on this very topic. In it he states this:

You should use whatever works for you. And I no longer have the patience or hubris to convince you what that should be. All I can offer is one data point: what I use, and how it works for me.

We have a similar policy at thredUP, whatever development setup that works best for you works best for us. In a very similar vein to the previous topic, we want you to be working with whatever will deliver the best results and make you happy while you're doing it. The reality is that you're going to spend the majority of your time in the year (excluding sleep) with your work computer. It's very important that your computer, desk, chair, keyboard, etc. is just the way you want it because when you're not working with your optimal setup, you're adding friction to your ability to stay on-task and be productive.

Work life balance is very important

From a work/life balance post on Marco's blog:

I never let a job prevent me from having a healthy relationship and home life. You just need to stand up for yourself: if you need to work long hours constantly (not just in occasional “crunch times”) to remain competitive and reasonably paid, your employer has serious cultural problems that will probably never be fixed.

First, I would like to say that if you're doing a good job managing your time and being efficient with it, working long hours is not necessary even at demanding start-up jobs. I know a couple of friends who complain about working long hours, but I know for a fact they spend an hour or two a day doing personal emails and surfing the web. If they were productive with those hours, working late wouldn't be necessary. The only caveat is in the "crunch times" that he references, which are necessary for any small development team when you release often and work quickly to hit aggressive deadlines.

thredUP has a very liberal vacation policy - in the simplest terms, there is no policy. As long as you don't abuse it, we want you to balance working hard with getting the necessary down cycles that keep you fresh. Developers are paid to code, but don't burn yourself out. If you're sick of coding it will make you miserable and it will affect your output. Manage your internal drive: rest when you need to, go code crazy when you're in the zone. Just remember that start-ups aren't built overnight so make sure you're pacing yourself for long haul.

Documentation, only when necessary

A lot of development teams harp on strong documentation - every method should be documented to explicitly state the purpose, the parameters and the result. I couldn't disagree more with this. When methods and variables are named intuitively, those methods will be self explanatory. The only situation in which I find documentation important is when you have a complex method or class that is doing something obscure or not easily perceived. If you spend a couple of hours re-factoring your code when your finishing up a project, it will become obvious which parts of your code could use a little documentation and which parts are fine as-is. No need to waste your time if you don't have to.

Lastly, Marco had a great point in a recent episode that wasn't particularly related to development but still great nonetheless. Don't underestimate how much your boss deals with that you're not aware of. Hiring, firing, salaries, taxes, bills, office leases, insurance, lawyers, funding, and much more. They have to deal with all of that while thinking ahead on the product roadmap and staying sharp in the present. Next time you think your boss has it easy, make sure to weigh in everything he/she might be dealing with offline before you jump to conclusions.

If you have any other gems from Marco or one of your favorites I didn't list, I'd love to hear it below in the comments.

Facebook FB.ui() apprequests IE Bug

That title was a mouthful! This post is a simple bug fix for an IE 7/8 issue that I couldn't find any solution for on the interwebs. The bug is as follows: if you use the Facebook JavaScript SDK to send apprequests (the invites that show up in the Facebook notifications jewel) and you're doing so through the FB.ui() method, the default settings will not work in Internet Explorer 7 and 8.

FB.ui() requests use Facebook Dialogs to render the modal. In your FB.ui() call you can reference the way in which you want Facebook Dialogs to render the modal. The options are 'page', 'popup', and 'iframe'. The Facebook documentation states that 'page' is the default, but for FB.ui({method: 'apprequests'}) calls, 'popup' is the default - which looks great in Chrome/FireFox/Safari; however, in IE, the modal never appears. So for IE users you need to set the display method to 'iframe' and it will work fine.

All you have to do is write some simple JavaScript browser detection code to toggle the display method. Here is my CoffeeScript to do this:

In case you're not a CoffeeScript fan, here is the equivalent to the above in JavaScript.

Rails Association Tips

Rails is one of those languages where you can infer how it should interpret code. A more simple way to word that is this: sometimes you'll be coding something for the hundredth time and all of a sudden you'll think to yourself 'I wonder if this will work' and you'll try to change a convention based on your previous experiences with that language. This recently happened to me and I wanted to share what I discovered.

We have a lot of named scopes in our app. Typically our named scopes look something like this:

In that example, our User model has_one :concierge_information (btw, definitely check out our new thredUP Concierge app). While I was creating this scope, I wondered if I could infer which 'joined_via' column I was referencing since I was querying over two tables. So I tried this:

And it worked! Much prettier, right? That example doesn't save a lot of keystrokes, but it should help keep things organized if you're joining across multiple tables and/or querying a lot of ambiguous columns (when you're query references a column name that exists on multiple models you're querying across). While I was writing this, I thought it might be nice to share some other association-related tips I've learned.

ActiveRecord Association Tips

Rails associations are awesome and they come with a lot of built-in class methods/helpers. The basic rule of thumb that I use is that if you're accessing an object's association, you probably have access to the ActiveRecord methods the association's model has. For example:

In that example, you can do any ActiveRecord query on that user's orders as if you were querying a subset of the Order table itself. This can be very handy if you have nested associations.

Object Association Tips

One that I recently came across was the built-in method for creating an associated record that is a has_one association. It ended up just being 'create_#{association name}'. It's not life changing, but it's nice to know. Here it is in action:

In case you're wondering what the has_many version looks like:

This brings up an important note about something I was fuzzy about until recently. When are these objects saved? Obviously a .create() call will write to the DB, but what about when you create/build the object outside of the association and then assign it afterwords? Here are some examples (these are all under the pretense that @user is already stored in the database):

That was helpful for me to learn as unnecessary .save calls result in additional calls to the database.

Lastly, I came across an edge case scenario that I was curious about. If you're using the '<<' operator to associate newly created objects, how do you know if the object you're creating failed? The answer is you don't. However, you can use the .push() method and it will do the same thing as the '<<' operator except that it will return true or false depending on whether the creation was successful or not.

If you know of any association tips that you found helpful and that I didn't list, please post them in the comments below.

Podcasts You Should Be Listening To

Audiobooks are great, but sometimes I'm not ready to commit to a multi-week book. Music is also great (obviously), but I listen to music while I code during the day so I'm prone to burning out on how much music I can listen to in one day. The one thing I can always listen to is podcasts. I love them. I listen to podcasts on the way into work to wake my brain up. I listen to sports podcasts at the gym to pass the time faster. I listen to podcasts on the way home from work to help my mind decompress. Doing laundry, running errands, etc. - there are many reasons to listen to podcasts. Here are some of my favorite (free) podcasts that you should check out.

Casual Listening

If you enjoy learning about random people and events as well as having awesome tidbits of information at your disposal at any time, then the HowStuffWorks.com staff are your best friends. They have two podcasts that are absolutely killer. Stuff You Should Know is a podcast explaining how both normal and complicated things work. Sometimes you'll have a podcast like 'How Ponzi Schemes Work' that is relevant to mainstream news and sometimes you'll have a podcast like 'How the Moon Works' that seems mundane, but ends up being extremely fascinating.

Name: Stuff You Should Know
iTunes Link: itunes.apple.com/us/podcast/stuff-you-should-know/id278981407
Frequency: 2x per week
Average length: ~30 minutes
Twitter: @SYSKPodcast

In the same vein, their sister podcast, Stuff You Missed in History Class, is an informative journey of people and historical events that provides much more insight than typically found on a Wikipedia article. When I was younger, I loved to sleep through history class. Now I find myself hanging on every word when they discuss the lives of people like Nikola Tesla or John Dillinger. Some examples of other topics they cover are famous shipwrecks, assassinations, and my personal favorite - military battles.

Name: Stuff You Missed In History Class
iTunes Link: itunes.apple.com/podcast/stuff-you-missed-in-history/id283605519
Frequency: 2x per week
Average length: ~20 minutes
Twitter: @MissedinHistory

Sports Podcasts

Bill Simmons is awesome. He's a podcaster, an author, and the founder of Grantland.com. He's a blend of sports fanatic, degenerate gambler, and pop-culture enthusiast - my kind of guy. Plus, his mailbags are awesome. Anyways, Bill's podcast is the B.S. Report. He usually has one-on-one conversations with analysts of all the major sports, but he also likes to have fun podcasts with his friends. My favorite is during the NFL season when he and his friend, Cousin Sal, break down the weekly NFL gambling lines and also comment on the previous week's games. Hilarity often ensues. During the MLB season, he brings on his buddy Jack-o who is a die-hard Yankees fan and they go back and forth ripping into each other's teams (Bill is a Red Sox fan). It's awesome, trust me. If you love sports and pop culture, this is a must-listen.

Name: B.S. Report
iTunes Link: itunes.apple.com/us/podcast/espn-the-b.s.-report-bill/id254098743
Frequency: 3x per week
Average length: ~60 minutes
Twitter: @sportsguy33

I used to listen to the ESPN's PTI and Around the Horn podcasts for daily sports commentary, but they overlapped too much on content and didn't spend enough time on things I wanted to hear extended commentary on. Enter Mike and Mike in the Morning. I don't listen to them every day, but when an event occurs that I'm interested in (like a great MNF game or a big trade), I listen to their podcast so I'm able to hear what the public consensus is for the topic. Also, in the Summer, they do a series called 'two a-days' which breaks down every NFL team and talks about their off-season - it's incredibly helpful for preparing for fantasy football drafts.

Name: Mike and Mike in the Morning
iTunes Link: itunes.apple.com/us/podcast/espn-radio-best-mike-mike/id154597838
Frequency: 5x per week
Average length: ~60 minutes
Twitter: @MikeAndMike

Tech Podcasts

I would be remiss in my duties if I didn't name some tech-related podcasts. I used to listen to about 10, specifically surrounding start-ups or web development, but I've found that after a long day of coding and working at start-up, the last thing I want to hear about is more code or people speculating about start-ups. I read the TechCrunch RSS feed for start-up news and I rely on professional development goals to further my coding knowledge. With that being said, there are two tech-related podcasts I listen to.

The first is Build and Analyze . This show is hosted by Dan Benjamin (founder of 5by5.tv) and Marco Arment (founder of Instapaper and co-founder of Tumblr). Marco is an incredible developer and there is a lot to be learned when he talks about his development philosophies. They typically discuss iOS development, Apple, and general web development topics. The only downside is that they bash Android pretty hard.

Name: Build and Analyze
iTunes Link: itunes.apple.com/us/podcast/build-and-analyze/id404064215
Frequency: 1x per week
Average length: ~90 minutes
Twitter: @marcoarment

I listened to This Week in Tech (TWiT) for over 2 years. I'm sad to say that I don't listen to it that often anymore. I love Leo Laporte (the host), but the show moved away from intelligent people dissecting Tech news and moved towards (pardon the hyperbole) old people going on irrelevant tangents about the good 'ole days of tech. The only shows I tune back in for are those that include Baratunde Thurston or Kevin Rose. I've heard that Tech News Today (TNT) , which is also on the TWiT network, is very good though. It's a 45-minute daily podcast hosted by Tom Merritt. If you like tech news, definitely give TNT a try.

If you listen to some good podcasts that I didn't list, please post a comment below so I can check them out!

Setting Up Sinatra with MySQL and ActiveRecord

Sinatra can be used to do a number of things. Here at thredUP, we're using Sinatra to turn some of our most used models into services accessible through an internal API. The Sinatra apps that we're building will still connect to our main Rails 3 app's MySQL database, but we'll be able to spin up multiple instances of our most used services which will help us scale as we continue to grow.

We use ActiveRecord for the models we're turning into services so when I was setting up the Sinatra app, I figured a simple Google or StackOverflow search would yield the necessary information I needed to connect the new Sinatra app to the database through ActiveRecord. Nope.

If you're looking to use sqlite3 with ActiveRecord or DataMapper, then this StackOverflow post will be your guide. For those with ActiveRecord and MySQL, here's what you have to do:

Assuming you have the 'active_record' and 'mysql2' gem installed already, all you need to do is create a config file that you require in your main Sinatra .rb file. The contents of the config file are relatively straight forward:

The env variable is important if you have different database settings for production, development, and any other environments. Here is an example of what database.yml might look like:

I know this is simple and easy, but I figure I'm not the first person to have to come across this.

Two other useful Sinatra resources:

5 Most Inspiring Steve Jobs Stories

Like a lot of other people in the tech. community, I've spent a fair amount of time reading about Steve Jobs this past month. Steve had some really incredible quotes, but some of the stories I read left me feeling especially inspired. Here are my favorite five:

Steve Jobs on the original iPod

When engineers were working on the very first iPod completed the prototype, they presented their work to Steve Jobs for his approval. Jobs played with the device, scrutinized it, weighed it in his hands, and promptly rejected it. It was too big.

The engineers explained that they had to reinvent inventing to create the iPod and that it was simply impossible to make it any smaller. Jobs was quiet for a moment. Finally he stood, walked over to an aquarium, and dropped the iPod in the tank. After it touched bottom, bubbles floated to the top.

"Those are air bubbles," he snapped. "That means there's space in there. Make it smaller."
- from Quora - original article here

Steve Jobs on dealing with a failed product

MobileMe was a dud. Users complained about lost e-mails, and syncing was spotty at best. Though reviewers gushed over the new iPhone, they panned the MobileMe service. Steve Jobs doesn't tolerate duds. Shortly after the launch event, he summoned the MobileMe team, gathering them in the Town Hall auditorium in Building 4 of Apple's campus, the venue the company uses for intimate product unveilings for journalists. According to a participant in the meeting, Jobs walked in, clad in his trademark black mock turtleneck and blue jeans, clasped his hands together, and asked a simple question: "Can anyone tell me what MobileMe is supposed to do?" Having received a satisfactory answer, he continued, "So why the fuck doesn't it do that?"

For the next half-hour Jobs berated the group. "You've tarnished Apple's reputation," he told them. "You should hate each other for having let each other down." The public humiliation particularly infuriated Jobs. Walt Mossberg, the influential Wall Street Journal gadget columnist, had panned MobileMe. "Mossberg, our friend, is no longer writing good things about us," Jobs said. On the spot, Jobs named a new executive to run the group.
- from CNN Money - original article here

Steve Jobs on simple design

Mike Evangelist (yep, that's his name) still remembers one of his first meetings with Jobs. It took place in the Apple boardroom in early 2000, just a few months after Apple purchased the American division of Astarte, a German software company where Evangelist was an operations manager.

Phil Schiller, Apple's longtime head of marketing, put Evangelist on a team charged with coming up with ideas for a DVD-burning program that Apple planned to release on high-end Macs -- an app that would later become iDVD.

"We had about three weeks to prepare," Evangelist says. He and another employee went to work creating beautiful mock-ups depicting the perfect interface for the new program. On the appointed day, Evangelist and the rest of the team gathered in the boardroom. They'd brought page after page of prototype screen shots showing the new program's various windows and menu options, along with paragraphs of documentation describing how the app would work.

"Then Steve comes in," Evangelist recalls. "He doesn't look at any of our work. He picks up a marker and goes over to the whiteboard. He draws a rectangle. 'Here's the new application,' he says. 'It's got one window. You drag your video into the window. Then you click the button that says BURN. That's it. That's what we're going to make.' "

"We were dumbfounded," Evangelist says. This wasn't how product decisions were made at his old company. Indeed, this isn't how products are planned anywhere else in the industry.
- from Fast Company - original article here

Steve's Reality Distortion Field

Bud Tribble, manager of the original Mac software development team:
"Well, it's Steve. Steve insists that we're shipping in early 1982, and won't accept answers to the contrary. The best way to describe the situation is a term from Star Trek. Steve has a reality distortion field. In his presence, reality is malleable. He can convince anyone of practically anything. It wears off when he's not around, but it makes it hard to have realistic schedules."
- from PC Mag - original article here

Steve's Spontaneous Genorosity

Givens recalled one day when a secretary was late, and Jobs demanded to know why.

“(She was a) single mom, good secretary,” Givens said. “She said, ‘My car wouldn’t start.’ So, that afternoon, (Jobs) walks into her office, throws a set of keys to a brand new Jaguar and says, ‘Here, don’t be late anymore.’ He was always doing things like that, surprising people.”
- from Quora - original article here

CoffeeScript for Beginners (Part 2 of 2)

My first post on CoffeeScript was primarily focused on getting CoffeeScript installed and having Node.js continuously compile your .coffee files. I touched on creating simple objects and iterating in a for loop, but this post will be all about the standard .click() handler and AJAX function (as well as some nice tricks).

Click Handlers

The .click() handler is probably the most used jQuery method and it happens to be an easy implementation in CoffeeScript. For the rest of this post, let's assume you have a JavaScript file (app.coffee) with a .setup() method that is called on page load. So somewhere in your view (after you have included the compiled JavaScript file), you have something that looks like this:

That code will ensure your app.setup() method is called after the DOM has loaded and your JavaScript is aware of every element. So what does your .click() method look like? Like this:

AJAX

AJAX, which stands for asynchronous JavaScript and XML, has become a staple for Front-end engineers. Anytime you want to talk to a database or load some foreign information without refreshing the page, you'll turn to AJAX. So for the sake of our example, let's say you want to make an AJAX call when someone clicks on a button. I'll assume you know what the JavaScript equivalent is and I'll only show the CoffeeScript:

Going the Extra Mile

There are certain best practices that can help deliver the best and most responsive experience to your users. There are two things in particular I like to do when I have a button that triggers an AJAX call.

The first thing is adding a disabled state when someone clicks the button. The user may not notice the activity spinner in the browser's tab so having a different button design that indicates a change will let the user know that the website is responding to your click. It will also give us a flag to determine if the button has been clicked so we don't make more than one AJAX request if they double click it. Keeping all this in mind, here is what the click handler looks like now:

This does 2 things. The preventDefault() call is there in case you have a valid href attribute on the anchor tag. This will prevent the link from executing. The second thing in here is adding the class 'selected' to the button and then surrounding the AJAX method call with a .hasClass check to make sure the 'selected' class hasn't been added already.

The other thing I like to do is handle the data response from the AJAX call. If something goes wrong in your controller (I'm assuming you're using a MVC framework), but all of the code executes anyways, your JavaScript is unaware that something went wrong and you'll never enter the 'error' block of your AJAX call. This why I always set an error flag in my controller that I pass back. Here is the block of code you'll need in your controller to respond to a AJAX call.

Now that our controller is passing back whether an error occurred or not, our JavaScript can handle accordingly. Here is everything coming together:

Useful Resources

One Year Retrospective

When I started working at thredUP a little over a year ago, I was the 5th full-time, non-founder employee. During that year, the user base has grown over 15x and there's now 22 people working at thredUP including the founders. We've been moving fast and there's been a lot to learn in the process. So much learning that I would say I've had more professional growth this past year than my entire professional career.

Some of the growth came from mistakes I made or from the condensed Rails learning I went through, but the most valuable learning came from the evolution of our development team and from working soup to nuts on a number of large projects. On a recent boat trip in Northern California, I took some time to reflect on the year to determine what I did well, what I did poorly, and figure out what the next steps were. During that time I came away with two very important things I learned that I want to continue to focus on this year:

Leveraging Your Knowledge Is Your Job

If you're a developer at a big corporation, especially those with big teams, the natural tendency is to take on 'rock-star' projects, hoard knowledge, and specialize in certain niches that are important to the company so that you can become indispensable. If you do this ‘right’, the value you create for yourself over a potential replacement will yield a lot of benefits (i.e. raises, promotions, etc.). At a start-up, the return is only short term and you’re hurting the company as a by-product.

When your team is small, you become responsible for large pieces of your app. Not because you’re trying to hoard anything, it’s because there’s a finite amount of developer resources and there’s a lot to do so you split up the work. As the team grows and more resources become available, you arrive at a point where you’re forced to make a decision: let your new colleagues go through the same growing pains you experienced and expose the knowledge dichotomy or leverage everything you know to help them skip all the road blocks you experienced along your path.

It sounds like a black and white decision - help yourself or help the team. It sounds simple, but you’re intentionally making yourself less valuable when you give away all your tricks, knowledge, and keys to the niches you specialized in. What I learned was this:

The ability to leverage your knowledge and create more value for the team is essential to scaling a company. To become very valuable to your team is one thing - to be able to help others become just as valuable as you is what can truly make you indispensable.
Your professional growth ends when you isolate yourself to a few domains of expertise. To learn new things, you need to move past what you already know and exit your comfort zone.

The Last 10% is the Hardest and Most Important

Every decent-sized project contains a variable amount of work that is unforeseen. On the Back-end, it’s typically the flows that weren’t thought through or the business logic that was sound on paper but didn’t add up in code. On the Front-end, it’s the hover/active/disabled buttons that weren’t in the designs or the edge cases of too much or too little of data that breaks the design/layout. Even if you're meticulous, something always springs up.

The reason why this chunk of work is so hard is because at that point of the project, most of the fun stuff is out of the way and everyone is waiting for the end product. To polish all those unplanned pieces would require grinding through test scenarios and working late to make sure every design interaction is perfect. It's not the most rewarding work, but from my experience I’ve found this is the most important phase of the project.

I have never ‘wowed’ anyone on a project that wasn't completely buttoned-up no matter how cool it was or how extensive the functionality was. When things are ‘off’ or ‘clunky’, it will consume the focus of the page and a lot of your great work will be looked over. Worst of all, the projects of yours that will be remembered the most will be the ones that are the most buggy. I think every developer has heard the following and cringed: ‘I found a bug. Who coded the ?’

If you build features that break often, your name will be associated with bad code or some sort of negative connotation regardless of how difficult or complex it is. The more you care and focus on that last 10%, the less your name will be brought up for the wrong reason. At the end of the day, if you want to be the 'go-to' person, you need to care about that last 10%.

From the Dev Couch: Redwood, Backbone, and Capfire

Apps to Improve your Workflow

App: Redwood
Link: redwoodapp.com

I'm about to gush: <earmuffs> this app is fucking awesome </earmuffs>. I hate searching for things - it's a complete waste of time. A while back I installed Alfred App to allow me to 'jump' straight to launching an application after hitting a hot key and it's a huge time saver (not to mention I never have to organize my application folder again). So Alfred is for your apps, but what about for all your files? Enter Redwood.

If you're like me, you have emails, messages, and attachments scattered throughout Gmail, Basecamp, and Dropbox. Only Dropbox is mounted locally and I use Thunderbird for my mail needs so I have to log into Gmail to search and I just pray that I'm searching on the right Gmail account. Redwood is a local app that allows you to add Gmail, Basecamp, PivotalTracker, and Google Docs accounts to and gives you the ability to search across all of the them.....amazing. So I have Alfred mapped to Ctrl + Spacebar, Redwood to Opt + Spacebar, and Spotlight to Com + Spacebar. Hello efficiency world.

Learning About New Technology

Technology: Backbone.js
Example: todos.js
Homepage: documentcloud.github.com/backbone/
GitHub: github.com/documentcloud/backbone/

If there was a ranking for the adoption rates of new (so excluding jQuery/Prototype) JavaScript frameworks/libraries, I would bet Backbone.js is second only to Node.js.

Backbone.js allows you to create a MVC of sorts inside your JavaScript. If you're anything like us, a lot of the functionality on your website is handled with JavaScript. Whether it's AJAX posting, error checking, or complicated modals, odds are you've dealt with JavaScript spaghetti. So similar to Rails, or any other good MVC, Backbone provides you with a framework of how to organize, write, and structure your code. It's sort of hard to explain, so here's the official summary of Backbone.js:

With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a "change" event; all the Views that display the model's data are notified of the event, causing them to re-render. You don't have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.

I haven't created anything with it yet (my learning plate runneth over), but give it a try and let me know what you think.

Rails Gems Worth Checking Out

Gem: Capfire
Link: rubygems.org/gems/capfire

The thredUP Dev Team has started to use Campfire as our chat collaboration tool of choice. Questions, Github commits, and countless emoticons dominant the chat room. As a development team of 10, we come across many issues about learning different parts of our app or programming language specific questions and it doesn't scale to just ask one person every question - so we post the question to the Campfire chatroom and let the first available person answer it. So far it's working out really well. So where does Capfire come into play?

Capfire is a gem that automatically posts a message to your Campfire chatroom after someone (namely someone who has Capfire installed) deploys your app. We already have Github hooks in place for pushes to remote repositories, but I think it's valuable to know when new code is being deployed to an app - especially if you have code in that deploy. To install Capfire, check out these install instructions as they're the best I came across.

The Power of Lambda, Bindings and Blocks in Ruby

I've been slowly making my way through the Dave Thomas series of Advanced Ruby vodcasts. The series has been very enlightening as I'm learning a lot of powerful features that Ruby offers as a programming language. A particular topic that he covered that sort of blew my mind was Ruby bindings and lambda.

Lambda

Lambda is something I've been working with for a while. The two main ways we utilize Lambda in the thredUP app is with named scopes and dynamic hash values. Examples:

The examples above are pretty standard usage of lambda. What I didn't know is that you could do something like this:

I think this is particularly useful in the event you're lambda block takes in options. Typically I see that people construct an options Hash object and then pass it in. By denoting the asterisk (*) before the last parameter, it allows you to just pass in all your options within your method call. If you have a lot of options, the call will look unwieldy and the Hash object creation is probably best.

Bindings

Two days ago was the first time I heard the term 'bindings' in regards to programming. Although I'm still trying to think of useful implementations of bindings inside of our thredUP app, the knowledge of how to use them should become a handy tool when brainstorming solutions in the future. My understanding of a binding is that it allows you to hook into's a block execution and retain the ability to enter into that block through the hook at will. Ruby-doc says that bindings 'encapsulate the execution context and retain this context for future use'. I like my definition better.

So once you create a binding, you're able to invoke said binding using the Kernal#eval method. Here is a simple example:

One could easily argue against the practicality of this example, but it was the best I could come up with in a couple of minutes. This particular binding gives you access to an instance variable of a class without setting up an attribute accessor. Also, since eval() is used, dynamic construction of objects opens up a little world of possibilites. If the EMPLOYEES constant contained classes instead of strings, eval() could dynamically create new objects for those classes (or access methods of those classes) within another class (such as Thredup) with the use of a binding.

It's a bit mind-numbing to think about good use cases for bindings, but it's a nice addition to a developer's toolbox. You never know when you might have to throw every tool in your toolbox at a problem to arrive at a solution - so every tool counts!

Blocks

I came across something that I thought was really interesting. A method can accept a block if you denote the parameter name with the '&' symbol. The block will come in as a Proc.new() object (almost identical to a lambda) and will therefore require the .call() method to invoke the block that was passed in. For once, I have a practical example of how valuable this is:

This cache_me method could be used as a tool to cache or retrieve (fetch) a metric based on a cache key and an expiration. The key and expiry could also be combined into one dynamic key if you want to add some syntactic sugar to your metric pie.

Improving Your TextMate Proficiency

TextMate is great, but on more than one occasion I've come very close from going 'Office Space' on my computer when TextMate thought it would be fun to beach ball and stop responding. Over time, much thanks to my CTO, I've found some ways to make my TextMate experience faster.

PeepOpen

Pressing (Command + T) in TextMate brings up the 'Go To File' window. The suckiness of this feature is two fold. First, if you have a large project (thredUP has over 2,300 files in our project) the 'Go To File' window will hang frozen for about a year. Second, if you have multiple files similarly named then it's practically useless. Enter PeepOpen ($12).

PeepOpen is awesome for a number of reasons. For one, PeepOpen keeps a persistent index of your project files so lookup is incredibly fast. Also, through some sort of magic, you are no longer limited to just typing file names to find a file. If I were looking to load the './app/controllers/admin/users_controller.rb' file, I could type 'admin users' and the results would be dramatically narrowed. You can type any part of the path and it will match against the index.

Also try: (Command + Shift + T) brings up a window to find a method within a file. Especially handy in large models.

Project Searching

If you're searching within a file, TextMate's built-in (Command + F) is fine. If you want to search multiple files such as a folder or the entire project, don't bother pressing (Shift + Command + F). It will take forever to find anything. Luckily there are multiple free and easy to install alternatives.

The first alternative is AckMate. I think it's the most widely used search plug-in. I didn't like it. First off, it doesn't support .haml files out of the gate. So I use a much less known plug-in called NiceFind. It's simple to install (double-click the NiceFind.tmplugin file after download) and it's very fast. It also allows you to select a directory in TextMate and press (Command + Shift + T) to only recursively search in that directory.

If I'm doing a costly search such as searching through some logs, I always default to the good 'ole grep command. However, sometimes you're on the command line and outside of TextMate and you want to search for files regardless of where they are stored in your app. If that's the case, then project_search is going to be your buddy. For example, I could do 'script/find helper "def emit_"' and it knows to only search helper files for that method.

Snippets

My favorite part of TextMate. If you aren't aware of TextMate Snippets, open TextMate and go to Bundles -> Bundle Editor -> Show Bundle Editor and explore all your different options. They are broken up by file detection, which I believe is done by your bundles. So your models might be under 'Ruby' or 'Ruby on Rails' and your views might be under 'Ruby Haml' if you have a separate bundle for HAML. I could list some good ones, but this cheat sheet is all you really need.

You can also go one step further and create your own snippets. While you're in the Bundle editor, select the bundle you want to add a snippet for and then click the '+' button in the bottom left. One of the ones I made is for Haml. Very commonly there is a JavaScript file I want to include for a page that also requires a jQuery DOM Ready setup call. So I created this snippet:

For the Activation field, I selected 'Key Equivalent' and put in the three letters 'cfj'. What this means is if I'm in a Haml file and I type cfj and press the tab key (which is usually how most snippets are activated), the following code is output for me:

The $1 variable set in the snippet is a way to autocomplete portions of the text. So after you press tab, the cursor will be waiting in the open quotes on the JavaScript include tag. Whatever I type there will also go before the .setup(); function call as well.

ReMate

Lastly, if you have a really large project, ReMate (free) is a must. Have you ever selected TextMate and it just hangs there? It's probably because TextMate is refreshing the entire project tree. If you install ReMate, you can disable this feature. After you install ReMate, go to Window -> Disable Refresh on Regaining Focus. That simple. You can toggle this option if you want this on or not and if you want to manually refresh your project tree, right click in the folder pane and select 'Refresh All Projects'.

If you know of good ways to speed up (maybe speedUP?) your TextMate usage, I'd love to hear about them in the comments below.

Responsive Web Design

I've been waiting to write a post on responsive web design (RWD) for a long time. I think it's a really powerful tool for websites that care about usability and UX. Definitions for RWD vary depending on the source because it's a relatively new 'technology', but I would describe it as developing a website in such a way that the layout/look responds accordingly as the browser changes by dimension or by device.

There's an important distinction to make about my definition. Just because a website looks different on a mobile device than it does on your computer, doesn't necessarily make that website responsive. A lot of websites detect whether you are viewing the website on a computer, phone, or tablet and either serve up a separate CSS file specifically built for that device type or they might even serve up a completely separate mobile version of their website or application.

For example, if you use 37signals' Basecamp product and you login on your computer versus logging in on your phone, you will be using their product on two completely different development frameworks. I don't doubt that they use some responsive elements in their design, but RWD is when it's the same exact website that uses a combination of specific RWD techniques, such as media queries, to alter your client-side interaction while the server-side code remains the same.

It should also be noted that RWD isn't for all websites. If you have a very large website (i.e. 50+ pages), it's going to be very hard to make all those pages responsive with any continuity without sinking an excessive amount of time into it, especially if your layouts differ from page to page. It also adds overhead in the sense that any design change requires another level of upkeep and quality assurance.

If this still isn't making sense, I listed a couple example below that illustrate what RWD looks like in action.

The most simple use case for this is adding it to your personal website. A really good example of RWD in action is Joni Korpi's personal website. I meant to write about Joni Korpi in my web designer portfolio post, but his three-tier responsiveness was too perfect for this one.

If you look at the picture below, you'll notice there are 3 different layouts to his website. Each layout corresponds to a certain browser dimension. If you go to his website (it's been re-designed since I captured the images) and re-size your browser to those dimensions, you'll notice the website's layout/design changes on the fly - it's pretty cool.

Next up is the French Earth Hour conference website. On a quick tangent - I think the colors of this website are awesome. Anyways, I only noticed two different responsive designs for this website as you see below. For some websites, that's all you really need. The creators of this website probably only wanted to optimize the design for full-width and standard mobile dimensions; I'm guessing this is the case because people typically hear about a conference through email, social media (both viewed in full width browser) or through oral referrals away from the computer (mobile browser). Something especially cool about what they did for their second layout (the one on the right) is that they removed some elements of the page to ensure the most important content was still above the fold - sweet trick.

Last, but not least, is Trent Walton's blog. Websites that contain content that can be consumed on multiple mediums is the most natural need for RWD in my opinion. I spent a good amount of time inspecting the source/CSS of Trent's blog as it was very helpful for building my new website's layout in a flexible and fluid way that is optimized for RWD.

As I just mentioned, I'm currently re-building my personal website, hence the lack of posts, but one of the first things I'm going to do once it's finalized is start working on making it responsive - which I'll attempt to document the best I can for another post. If you're looking to make your website responsive, I would check out the following posts:

FitText - jQuery plugin for inflating web type to make font-sizes flexible
ThinkVitamin Media Queries: Introduction - video demo of media queries and fluid layouts
A List Apart: Responsive Web Design - detailed write-up about RWD from people who are much better at writing than I am :)

Overriding the Default Retrieval Limit in FbGraph

One of the many thredUP projects I'm fond of is the Daily Thred. Every weekday, two of the Moms here at thredUP post a new article that is discussed in the chat tray on the right side of the page. This chat tray was built from scratch utilizing the Facebook Graph API and FQL with JavaScript.

One of the many challenges that surfaced was collecting metrics on activity occurring in the chat tray, since all the activity was stored in the Facebook databases. I didn't want to pull these metrics with JavaScript and since our server language of choice is Ruby, I turned to FbGraph, which is a full-stack Ruby Facebook Graph API wrapper.

It's a cinch to install and the usage is intuitive - I couldn't have been happier with the gem. After I finished implementing the metrics for the chat tray, I deployed to production and quickly found a problem. The way our chat tray works is as follows: every article is tied to a Facebook Post object. All comments made in the chat tray are Facebook Comment objects where the parent_id is the Post's id. Simple enough. So to fetch all the comments for a post to analyze the results for the metrics, I did the following with FbGraph:

The problem was the number of comments returned maxed out at 50. Since some of our chat tray conversations have over 300 comments, it was crucial I had access to every comment. I tried some standard ActiveRecord conventions like post.comments.limit(1000) to no avail. After a round of Google searches and sifting through some Github issues, I came across someone who had a similar concern. Their solution involved paging through the comments. This wasn't sufficient for me so I went poking around in the gem.

After a quick cd `bundle show fb_graph` command, I started to peruse around the gem's lib files. Inside the Post class, I noticed the associated @_comments_ object was created through the Collection class. Once inside the Collection class (/lib/fb_graph/collection.rb), I noticed there were four variables that def fetch_params checked for - one of which was 'limit'. So after adjusting my script like below, all was good.

From the Dev Couch: All Ruby Baby

Rubyflow is a great Ruby blog aggregator. I subscribe to their RSS feed and every day there are multiple posts that either pique my interest or are relevant to gems or technology that I work with. I don't have time to read all of them everyday so I bookmark all the good ones and set aside a couple of hours every week to parse through them all. Featured in this post are the articles that I learned something from or determined are worth saving for a later date as it could become handy in the right situation.

Realtime Data Overlays Using Google Maps

The Ghostly Map
A couple of months ago the thredUP dev team wandered over to Cloudflare's office in SOMA to celebrate their recent achievements. While we were enjoying a couple of beers, we stumbled across a 10-foot projector screen displaying a realtime geo-mashup of their service in action. My colleagues and I all looked at each other and knew instantly we had to do something similar. While our version is still on our 'fun to-do list', this post on Stac's blog is a good walkthrough about how to make a realtime maps mashup with Rails 3. They cover using Rails' cache store API, use of Backbone.js, Underscore templates, GeoKit, and the Google Maps API. Read more →

Automatic Page Loading

Endless Page Scrolling with Rails 3 and jQuery
This has to be the coolest post I came across. Do you ever wonder how Facebook only displays a certain number of comments or status updates and when you approach the bottom of the container, they automatically add more? Well, this is how you can do it. It's a relatively simple implementation using jQuery to attach a custom handler on an element that makes an AJAX call to your Rails controller to append more data to the element. The only required file is his custom jQuery library, which can be found on GitHub here.

Altering Rails' Naming Conventions

Pluralizations and Singularizations (Inflections) in Rails 3
When I first started learning Rails, I found the naming conventions difficult in routes, controllers, and models. What was plural, what was singular, and what stayed the same - i.e. if the model is history.rb, is the controller histories.rb? In general, Rails is pretty good about getting that kind of stuff right, but if you want to override how they pluralize or singularize anything, then this post will be great for you.

Optimizing MySQL

Tuning MySQL - Innodb, Buffer Pool Sizes, and Rails Stack Server Advice
I'm not going to even pretend I know 10% of what's going on in this post. Even though it's way over my head, I have to imagine every person who works on a MySQL-based app can read this post and have some valuable take-aways. Did you know you can log slow queries by changing performance values in your MySQL my.cnf file? You can even change how many seconds constitutes a long query for your app. On top of that, you can log queries that aren't using indexes. Now that's pretty slick. There is also good advice for those using an Apache/Passenger/MySQL/Memcache stack, which is what we use at thredUP. Read more →

Notable mentions

Rails 3 Calendar - Draggable calendar events and AJAXed event creation and updates
RVM Rails 3.1 Install - Easy copy/paste-able steps on how to install Ruby Version Manager (RVM) and using RVM to install the Rails 3.1 Release Candidate
Ruby Method Lookups - Using 'super' to demonstrate the order in which Ruby methods are looked up

Checklist Driven Development

Until recently, I was under the impression that my obsessive use of checklists was just a way for me to ensure nothing slipped through the cracks. Then something entirely changed my outlook on checklists. In mid April, Jack Dorsey tweeted he was giving out copies of The Checklist Manifesto to Twitter employees. Being both a Jack Dorsey and checklist fan, I impulsively bought the book on Amazon. If you read the book, you'll notice that Dr. Atul Gawande, the author, wastes little time getting to the thesis - checklists are extremely powerful when used correctly.

Throughout the book, the author takes you on a journey through all the different applications of checklists. He has fascinating stories that illustrate how and why checklists are used in different professions. Through all the tips and pitfalls, the biggest takeaway was the following:

[Checklists] improve outcomes with no increase in skill.

In essence, checklists are a simple form of life hacking. A checklist can save you from forgetting a simple, yet crucial step or task, which can lead to more work. The more unnecessary work you can cut out, the more efficient you are. I typically look at life hacking as simple tools that allow you to exert less effort to achieve equal or better results. Checklists definitely fall into this category in my opinion.

There is a caveat with checklists. They don't make you more intelligent, they simply allow you to work more intelligently. The difference is subtle, but important. If you have ever heard of Test Driven Development (TDD), then the easiest metaphor would be saying checklists are essentially adding test coverage to the management of a project. Sometimes it's monotonous and overkill, but it's all worth it when you catch that small oversight that can be critical to your project's success. Plus, if you're anything like me, checklists (and proper TDD for that matter) allow you sleep with a clear mind at night.

One of my favorite quotes from the book is '[checklists] are quick and simple tools aimed to buttress the skills of expert professionals'. A common misconception is that checklists aren't functional in complex lines of work. The author proves the contrary with countless examples ranging from specialized surgery, building skyscrapers, flying a Boeing 747, and even venture capitalist investments. To demonstrate the practicality, Dr. Gawande created a checklist for the World Health Organization (WHO) to help combat common mistakes that can occur in an operating room during surgery. He goes into great detail about how he researched, created, and implemented the checklist; the outcome of said checklist was the rate of complications for surgical patients falling by 36% and deaths by 47%. It's hard to argue with those results.

So how can checklists be applied to development?

I've always found that the most important and often hardest parts of a project are the first 10% and the last 10%. Figuring out where to start and determining the first steps can be a tedious and overwhelming process. In my experience, if you build a checklist of all the deliverables that must be completed and then elaborate on each deliverable point-by-point, the momentum will begin to build and anxiety will recede.

As for the last 10%, it's typically just a matter of covering all your bases and polishing. If you discipline yourself to write down every loose end you come across as the project matures, then it's just a matter of crossing off those items 1 by 1 and giving them the attention to detail they deserve.

So taking that into consideration and incorporating the lessons learned from reading The Checklist Manifesto, my personal use of developing daily with checklists has evolved into what is described below.

Daily Checklist

In the past, I more or less broke down every project into a series of checklists and then slotted them into my calendar at the beginning of every sprint (thredUP's dev team is agile). It was essentially a checklist version of a burn down chart.

I found my system faulty for two reasons. First, it assumes the priorities remain static over the course of all your projects, which they rarely do. Second, it leads to developing with blinders on as after the initial super checklist is built, then all I did was crank out the remaining items. This is why I now create a brand new checklist every morning.

The daily checklist contains a bulleted list of everything I plan to accomplish that day. I often group the items by project and clearly define what items, if finished, would constitute a productive day. Anything that isn't completed will be recompiled and re-prioritized the next day. This is the key to the daily checklist - build it from scratch every morning so you can re-weigh the priority of each task in the context of how each project is progressing. The daily checklist keeps you on track throughout the day, ensures nothing obvious is passed over, and it helps give you some momentum as you progress through the list.

Project Checklist

For every project, assuming you know how to do it, determine the critical path and identify every step along the way. Those steps become the project checklist. Granularity on those steps should be a balance between diving in far enough to uncover any logic gaps on your implementation strategy while staying away from getting too into the weeds that you lose perspective. Once you know how you're going to do every one of your projects to a certain extent, you won't be stressed.

By not becoming too granular, you don't trap yourself into one way to approach the problem. I found that when I broke down all my projects in advance to very specific tasks, I was more resilient to change. If you balance it just right, you'll be able to talk intelligently on how the project will be done without becoming married to the specifics. I haven't mastered that last part yet, but I do try to keep it in mind.

I was going to talk about my secret weapon - my email inbox - but I'll save that for a different post. As for how I actually create these checklists, I do it the old fashioned way - pen and paper.

For the project checklists I'll often start on a whiteboard and transfer it to Basecamp so I can circulate my strategy to the project stakeholders.

In conclusion, I do not propose that this post will apply to all developers or even a large subset. Also, this definitely isn't applicable to all work environments so think about this in the context of your unique situation. This was not written in stone and I'm always looking for ways to improve it or have some of my assumptions proven wrong. If you have thoughts, ideas or criticism (whether it's constructive or not), I'd love to hear about it in the comments below.

Working for a Start-up: Developing Outside Your Demo

When you work at a start-up, you're not given a bulleted feature spec. document detailing every design detail, each UI interaction a user will experience, or how every page of a feature is supposed to flow. Although it can vary, you're usually given three things: what the feature is, why we are building it, and basic expectations of the deliverables. Some people find this overwhelming. I, however, wouldn't want it any other way.

The freedom of taking a feature concept and turning it into a functional aspect of your web app used by thousands of people every day creates a certain level of responsibility that is intoxicating.

Every decision is important. Deciding how your feature will hook into the current app on the back-end, how users will navigate to your feature, etc. are all decisions you need to work through on your own and they typically require a decent amount of thought. The easiest way to go about this is putting yourself in the shoes of your user and asking yourself, 'if it were me, how would I expect this feature to behave?' But what if you can't put yourself in the shoes of your user?

thredUP.com's demographic is comprised of over 99% women. 100% of thredUP members are parents. One could make a very strong argument that it's not possible for me to be further from our demographic, yet I develop for thredUP every day and build features that our members enjoy (I hope). So what are some of the tips I use?

Align Your Perceptions

If you're not a power user of your service, find one and talk to them. My CEO is a parent of a 9 month old girl and he uses thredUP for almost every piece of clothing she wears. Because of this, I can pick the brains of one of our super users without leaving the office. I might think a feature is great, but then again I don't have children and I'm not using the service out of necessity so my perceptions aren't really aligned with reality.

Another great way to ground your assumptions is to do customer service. Talk with your users. See what problems they are having and what isn't obvious to them. Something you think is intuitive might be confusing to your user. I live in a world of Macbook Pros, iPads, Androids, and know what AJAX is and how it should behave. However, over 47% of our members use Internet Explorer and some of our users are notorious for 'double-clicking the internet'. This is why we've started disabling buttons once you have clicked them and display activity spinners every time an AJAX call is made to let our users know the service is processing something. Intuitiveness is relative. The dichotomy between Windows users and Mac users is sizable enough where you can't assume that a behavior you find second nature on your iPad won't be obscure to half your users.

Use Your Service

This might sound ridiculous, but you have to use your service as your members do. If I worked at Quora or Twitter, two services I use and enjoy, this wouldn't be an issue; however, some of us work and develop for services that are not intended for us. This shouldn't stop you from experiencing your service the way your members do. For example, I pick and list boxes at thredUP and I even have a public profile on our website. The last time I listed a box, I found myself noticing how 4 steps should really be 3 and that an email I received wasn't as helpful or descriptive as it could be. These are the things that help you avoid developing blindly and building features no one will use.

Of all my tips, I fall victim to this one the most and it's probably the most important of them all. My bosses emphasize doing this on a regular basis and I'm grateful as it's important to discover the pain points of your service first hand.

Metrics, Metrics, Metrics

Figures don't lie, but liars figure ~ Mark Twain

Have you ever gotten into an argument where someone states something like 'all of our users ' or 'no one uses ' and you know they are wrong but you can't prove it? This is why you need to become friends with metrics. If you can't pull them yourself, find a developer who can and ask them for a specific data-set. Sometimes the easiest way to do this is to tell them exactly what you're hoping to derive from the statistics. Translation can be lost between models/databases and the names of features thrown around the office. A good developer should be able to find conclusive data for the metric you're looking for.

Solid metrics with proper baselines can save you from arriving at the wrong conclusions. I wish I did this more, but benchmarking all your features after enough time has passed to collect a valid sample set of data is foolish not to do. I sometimes say to myself 'if only I had more time', but that's just a lazy statement. You could run one query that takes you a minute to write that could save you days of development. One great example of this is when we launched a new homepage design that we all thought was amazing, but the metrics disagreed. The homepage had notably worse conversion rates and it became apparent that we had to move on and figure out why our development assumptions were off. I actually wrote about the dilemna we faced and the art of swallowing your pride and admitting when you're wrong. Which leads me to my last point.

Know When You're Wrong

If you're not in your demographic.
If you're not a super user of your website.
If you don't have metrics to back up your assumptions.
Then you have to face the music.

The fastest way to lose an argument, lose your leverage in arguments, and lose respect is by making unfounded statements. Bite your tongue unless you know what you're talking about. Before you go into a meeting and discuss the conception or evolution of a feature, think out your reasoning and be ready to back it up with something undisputable (metrics) or personal experience with the matter (user stories). Maybe your still wrong, but you won't lose respect if you're prepared and you're offering conclusions on valid assumptions.

CoffeeScript for Beginners (Part 1 of 2)

If you're a Rails developer, CoffeeScript is something you need to pay attention to. With the news that CoffeeScript will be included by default in Rails 3.1, CoffeeScript is definitely generating a sizable amount of momentum and the core Rails team believes it's the future. Knowing this, I was looking for an opportunity to use it and a clean project presented itself this sprint at thredUP. So with the help of my colleagues Kylie and Chris, we dove in and started playing away.

The first step is to install CoffeeScript (really?). I used CoffeeScript's official installation instructions, but I ran into some weird export PATH environment issues so I installed it with Homebrew instead.

To install Homebrew, just run this command in your terminal (assuming you have xCode installed already):

Next, you need to install Node.js, which will compile your CoffeeScript for you. With Homebrew installed, all it takes is one line:

You're almost there. Just two more install commands left. The first is installing Node Package Manager and the second is using NPM to install CoffeeScript.

Done! Pretty harmless, heh? Time to start writing some CoffeeScript! Since people abbreviate JavaScript as JS and I'm a sucker for typing less, I'll just refer to CoffeeScript as CS throughout the rest of this post. It doesn't matter where you place your CoffeeScript files, but I believe Chris told me the best convention is in your app/assets folder. So if you haven't done that, go into your terminal and make the directory:

You can end your CS files with .coffee or .js.coffee, so create a new file in there so we can finally write some code. The project I'll be using as my example is heavily focused with DOM manipulation and since thredUP's library of choice for that is jQuery, you'll be seeing a lot of that in here.

When I first got everything setup, I was a little bit paralyzed. I didn't know where to even start. So the first thing I did was I wrote what I wanted in code in plain JS:

It's basically a setup function that calls another function which iterates over an array and logs the contents. What does this look like in CS? Like this:

Pretty sexy, right? CoffeeScript is very clean (based on Ruby and Python syntax) and it makes it much easier to work with, to read, and it's easier on the eyes. Before I get ahead of myself, there's a couple of things in this code that need to be explained, but first let's give you some resources. Syntax reference for CS can be found here. Once you're on that website, click 'Try CoffeeScript' and an interactive window appears which allows you to type CS directly into a console that the website compiles the corresponding JS right in front of you. This is what it looks like when I typed in the code above on their console

The first thing you're going to notice is the JS code that I original wrote and attempted to create is different from what was outputted on their console. The reason is because CoffeeScript's compiler is a better JavaScript programmer than me :) I can assure you that my original block of JS code and the compiled CoffeeScript JS code execute the same, but the CS version is going to do it a lot smarter and probably more efficient. CS is going to compile into the best JS it can without changing how your JS functions.

Another note worth mentioning is that the marketDemand object is oriented off of the JavaScript 'window' object. I didn't know this, but apparently this is something I should have always been doing as it prevents objects, variables, and functions that you write from spaghetti scoping out of control. I think it's one of those "trust me, it's better practice this way and you don't want to discover first-hand why it's necessary, but it is" things.

So let's paste that code into the .coffee file you created. The next step is to compile it on your terminal:

If you paste that into your terminal, it will compile all CS files in your app/assets/coffeescripts folder (-c stands for compile) and output them into your public/javascripts/coffeescripts/ folder (-o stands for output). Now, if you're always looking for short-cuts like I am, you'll like this next one:

That command will watch a specific CS file and when it detects a change, it will automatically re-compile it for you. Pretty killer, right?

This post became a lot longer than I originally intended so I broke it into two posts and I'll post the second one in a couple of days. In the next post I'll be going through using jQuery in CoffeeScript and covering if/else statements and other standard snippets of JS -> CS that you might find handy.

Minimum Product Strategy

When you're creating a new feature or adding functionality to your web app, you typically don't have time to dive into the minutia of every aspect of how the feature will look, behave, and function. Obviously you can indulge yourself into that level of detail, but it is typically the most time consuming aspect of a feature and it shouldn't be tackled until the minimum required functionality of the feature is complete.

If you get caught up in the sexy or fun part of the project, the user-facing portion, it's possible you'll use all of your allotted time for the project carrying out non-critical feature development and you won't be able to release anything as your feature still isn't functional. If you develop in such a way that you make the feature usable and functional first, you can spend all the remaining time layering on the subtleties of good UX. If things go wrong and you end up having very little time to layer on the aesthetics, at least you can release the feature and come back to the subtleties later. This strategy for building features is commonly known as Minimum Viable Product (MVP).

I am a very big proponent of developing with a MVP mindset. If I'm given a 3-day window to work on a project, I'll determine what the MVP and critical path for that project is within the confines of 3 days. With this mindset, my only enemy is scope creep. Scope creep is inevitable with every project and unless it's absolutely necessary, my natural reaction is typically 'great idea, but it should probably go in version 2 of this project'. This approach is a double-edged sword. Because I take this stance, very rarely are my projects not completed by the designated time; however, it's possible that the MVPs I develop are too bare-boned to be a feature that users will be delighted by. This is where we enter a gray area.

I can go the extra mile and try to delight the users, but then I will run the risk of spending too much time determining what I think the users will perceive as delightful, which is highly subjective and not always obvious. It leaves a certain level of uncertainty in determining the completion of the project that I'm not comfortable with.

The concept of building towards a delightful product, or Minimum Delightful Product (MDP), was coined by either James Reinhart or Oliver Lubin, I can't remember which. Respectively, they are the CEO and CCO of the company I work for - thredUP.com. MDP is a very forward-thinking strategy to product development, but I'm going to go against the grain and disagree with my bosses and their concept. Before I do so, I want to elaborate on the idea of MDP.

I believe MDP is the evolution of another strategy that bares the same acronym, Minimum Desirable Product. Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users. That definition is a direct quote from Andrew Chen's aptly named blog post 'Minimum Desirable Product'. In this post Andrew Chen (@andrewchen) explains that MVP tends to center around the business perspective of a feature and what you really need to focus on is what feature your users desire.

What my co-founders argue in favor of building for delight over desire is that sometimes what users want (desire) is different from what will actually 'wow' them (delight). If users were able to add every feature they desired, you potentially could end up with a cluttered product. While there are many examples of this, my favorite is the homer-mobile. Homer Simpson once created his dream car with every bell and whistle he could possible want, but it ended up looking like this:

I could also demonstrate the other end of the spectrum by showing a product that succeeded in ignoring feature requests and still delighting their users - the Apple iPad. Users wanted Mac OSX on the iPad and countless other features, but Apple determined the core experience they wanted the iPad to emanate and built towards that while letting many features fall by the wayside. I think we can all agree that the iPad has been a smashing success and the simple experience and usability is a fundamental reason why. I'm not saying that building for what users desire leads to building cluttered apps, but there's definitely a gap between what users desire and what will delight them. Because of this I believe there is great merit to the Minimum Delightful Product way of thinking. So why am I hesitant to buy into it then?

The reason why I am hesitant is that 'delightful' is a very subjective term and assuming you know what the users will consider delightful is a bold statement. Outside of Apple and a few other companies, most struggle with always delivering a delightful experience and if you're not in your product's demographic (like myself), it becomes even harder to identify what will be delightful for users before the product is built. I'm not saying building a Minimum Delightful Product is wrong, I'm just saying it's difficult and you're bound to arrive at the wrong subjective assumptions every once in a while.

I don't believe in criticizing without offering a solution, but my spin on the strategy is kind of a cop-out as I believe the right approach is a balance of all three. Obviously the complexity of the project and resources available will always dictate your flexibility on strategy, but in the optimal environment I would prefer to build an MVP that is structurally sound on the back-end and then put a thin layer on top that will elevate the feature to what the users desire while showing glimpses of how version 2 of the feature would delight them. It's basically right in between building desirable and delightful product.

With this approach, you are less likely scrap work made on inaccurate assumptions. The only requisite to my approach is you have to schedule version 2 of the feature very soon after version 1 is complete. If you don't bake V2 into the schedule right after V1, I doubt you'll come back to V1 and ever make it a delightful feature for your users. Build V1 -> collect feedback -> adapt the feature -> release V2. It's eerily similar to the 'MVP -> release -> iterate' agile workflow, but somehow in my head it's different in all the right ways. I think I'll call it the Minimum Dan Product so I can have another MDP acronym to be confused with.

From the Dev Couch: Designers and their Portfolios

There are back-end developers, front-end developers, and then there are designers. BE devs primarily work with models, databases, and then set-up the controllers so the front-end can get the data they need for their views. With that data, FE devs typically work in the views and use HTML/CSS & their JavaScript framework of choice to make compelling pages. Designers, on the other hand, typically aren't coders and they spend their days in Photoshop/Fireworks taking a wireframe in sketch form to something visually spectacular. If you are one of the few designers who can code as well, we have job openings ;)

There is another type of person in the web community and those are the people who say they are designers when they are not. You can teach someone how to become a programmer, but you really can't teach someone how to become an artist. I admire great designers and because of that I find myself getting upset when I come across pretenders. So for all those who claim to be designers, here are some real designers and here is what your portfolio should look like:

Stephen Caver

Website: Homepage || Portfolio
Dribbble: stephen
Twitter: @deadgraviti

If your a designer, your website should be something special. If it's not, then you better have a pretty good portfolio available. It's difficult to determine if someone is a good developer or not by glancing at their websites or even their source code because there are so many factors that have to be taken into consideration. Were they the sole developer? Is the code theirs or is it a plug-in they're using? Did they even write the code or are they claiming credit for something they just modified? With designers, their work is more transparent. So what's a good example of a designer's website that's special? Take a look:

It's unique. It's expressive. It demonstrates competency in the area of web design and graphical design. Did I mention it's also responsive? My next post will be on responsive design, but if you're new to the term it's when your website responds to different browser dimensions with separate designs. Take Stephen's website and make it smaller. Now make it bigger. Notice how all the elements change? This is so the viewing experience is great on all types of media devices and in all sizes. I love his website.

Chris Spooner

Website: Homepage || Portfolio
Dribbble: chrisspooner
Twitter: @chrisspooner

Chris Spooner is a whole different league of designer. He can code, blog, design and he's an almost unattainable freelancer because of demand for his work. In addition to his freelance web shop, he runs a web design blog called Line25, he has his own personal blog, a graphics blog, and even one for his dog Jake. I'm not saying that if you're a designer you should be like Chris and do all of these because that's unfair. But I guarantee you could learn a couple lessons from looking around on his website and following some of his articles.

His graphics are stunning.

Daniel Burka

Website: Homepage
Dribbble: dburka
Twitter: @dburka

There are exceptions to the rule and Daniel Burka is one of them. He doesn't have a portfolio per sé, but that's because he has held prominent positions in a number products that regularly feature his work. When you're the creative director at Digg or director of design for a game primarily known for it's graphics like Glitch, you have living portfolios and a formal, consolidated portfolio is less necessary. Freelance developers require something to show all their work in one spot, but entrepreneurs and design professionals are able to share their projects (if they are big enough) and let the person inquiring experience their design for themselves. I can only imagine what Daniel and his good pal Kevin Rose are cooking up with their new mobile app in-house incubator Milk.

A good example of these living portfolios is our Chief Creative Officer Oliver Lubin and the graphical/design lead Heidi Howland. Oliver might not have a public portfolio, but he practically designed every UI element on our website thredUP. If you sign-up and use our website, you take a tour of his portfolio. Same goes for Heidi. Every graphic on our website from the clouds in the thredUP sky to the badge icons to subtle background graphics on our How it Works page.

Polishing my Rubies: Instance Variables & the 'self' Object

If you're not interested in learning about Ruby, this post may not be valuable to you. Proceed at your own dorky will.

Super quick backstory: Ever since joining thredUP back in early September this year, I've been new to Ruby. I spent my first couple of months learning our app and gaining a functional knowledge of Ruby on Rails. 9 months later, it has become time for me to go back and back-fill the fundamentals of Ruby that I missed.

In my opinion, having sound fundamentals in anything, from Ruby to basketball, is what allows you to consistently produce quality results. Luckily for me, thredUP schedules in a healthy amount of time to be designated for professional development. This post is the first in a series of many that will catalogue what I previously did not know or were ambiguous at how they worked behind the scenes.

Please take a look at this example I wrote:

This is mock class that will demonstrate how using self in Ruby works in the context of instance variables. If you read through this class, you'll notice it's pretty straight-forward. Take a minute and write down what you think will be outputted when lines 28-36 run and don't cheat by looking at the bottom of this post.

Don't worry, I'll wait.

Once you're done, compare your results to the code at the bottom of the post. If you were anything like me an hour ago, you would have made some wrong assumptions. So let's figure out why. First, let's define some vocabulary.

self - this refers to the current object in Ruby.
explicit receivers - the object you are setting to be invoked upon in Ruby.
instance variables - commonly denoted with the '@' sign such as @variable. These types of variables are not public (their scope is confined to self), but they are global (broader scope accessibility than standard variables).

That might not seem so tricky, but if you're not careful when using instance variables then you can find yourself accessing or overwriting the wrong variables. So let's dive in head first. On line 28, when we print self out to the screen, the output will show the class name Dolphin. Simple enough - we're in class Dolphin when it's called so there's no surprise there. When we output @display, you'll notice 'no dolphin specified' is printed out. Since that's its original value set on line 2 and no other call has been made yet, this shouldn't be a surprise either.

Next we call Dolphin.bottlenose on line 31 to build our new Dolphin object, which we set to a standard variable named dolphin. Here's where it gets tricky. When we invoke the display method on our dolphin object, we are setting dolphin as the explicit receiver, which will change the object that self is pointing to and therefore the scope of @display changes. You'll notice that the first time we output @display from within the display method, the value is blank or nil. Weird, huh? It's because @display in the context of your dolphin object (i.e. #<Dolphin:0x1001370d0>) is different then in the context of Dolphin. The simple distinction between what the current explicit receiver is set to determines this. If it's still a little confusing, read on as I'll clear it up.

After we finishing outputting within the display method, @display now holds a new string value when the dolphin object is the explicit receiver. Line 34 will demonstrate the difference as it will once again print 'no dolphin specified' since the self object is now referencing the class Dolphin again.

So why is this useful? Well, take a look at what line 36 outputted. You'll noticed that even though @display was not set within the color method, we're still able to access the contents of the instance variable that was set within the display method since the color method was invoked on our individual dolphin object, which changed the context of self again.

Hopefully this was as helpful to you as it was to me for learning how to differentiate how instance variables are set, accessed and scoped. Here is the source code with the output directly following it to make it easier to read what's going on:

Working for a Start-up: How to Pace Yourself

This post is more so a running inner dialogue as I have not completely figured out how to successfully throttle my efforts to achieve maximum output without ever reaching the burn-out phase.

When you first start at a job, everything is exciting and you're able to work your ass off to get near the point where you can contribute at a level your accustomed to. As you start to catch on and get familiar with your new job, it takes less effort to achieve what you need to as the amount of unknown barriers and new technologies to learn begin to dissipate. I do not believe, however, that your work ethic and output have a direct x = y correlation.

If x is work ethic and y is the output, I believe there is a coefficient that needs to be calculated into the equation. This coefficient is how smart you work, which for this example we will call z. In my mind, the real equation is x * z = y where z is a number between 0 and 1. If you're working as smart as you can, z = 1. If you're meandering your way through your work, the value of z drops to some arbitrary number less than 1 (i.e. .65) and your output drops even though your work ethic remains constant. Working unintelligently can be as simple as falling off the critical path on a project by not focusing on the crucial parts of a project and putting too much energy on the trivial parts.

In my experience, burning-out typically causes your z coefficient to drop and in result causes your y value to drop as well. When this starts to happen on a regular basis, you enter into the burn-out phase.

The burn-out phase I'm referring to is when work needs to be done, but your completely apathetic to actually making it happen. Another symptom is when you become surly when discussing a project and demonstrating reluctancy to change the project for the better as it would result in re-engineering some of your initial efforts. I plan on addressing some remedies I've used to get through these periods, but first you have to identify what type of burn-out phase you're going through.

There are two types of burning-out that I believe exist. One is a short-term problem and the other is much more serious long-term problem. The short-term problem I see is typically when you have worked really hard or long on one project and it simply keeps getting larger or every time you think you've crossed the finish line somebody tacks on an additional 10%. The 10% can be scope creep or it can also be bugs that you originally lacked the foresight to test for. Either way, I consider this type of burning-out a short-term problem. Here are some ways to avoid or break through the short term burn-outs:

Grinding it Out

I know what you're thinking: this is a shitty remedy. Sorry, but for a lot of the barriers you come across, grinding it out will resolve the issue. Sometimes you just need to suck it up and crush it. If you find yourself having to grind it out very often, then there's probably a bigger underlying issue and you'll need to find a more sustainable solution then just adding more to your workload.

Getting your Little Wins

It's the little things in life. You can argue otherwise, but the smallest things can often have the most profound changes in your mood and outlook on life (or work). You need to identify where these little wins are and get them. It's important to keep things in perspective as well. The average developer makes $75k a year. That means your company is dropping $1,500 a week on you to do your job. If you take off one day from being lazy or burnt-out, you essentially just wasted $300 of your company's money. If you were to take that $300 and do something with it to remedy the reason why you're taking a day off, then you're doing yourself a solid as well as the company.

It doesn't have to be big either. If your little win is getting a bigger monitor, new computer or new coffee maker and you think this will make you happier to the point where you'll be productive, I guarantee it will pay for itself a couple times over. It doesn't have to be physical goods either. If getting to the gym during the middle of the day gives you more energy and revives your second half of the day, then do it. If your boss asks you why you need what you're requesting and you explain to him/her that it will make you more productive and relieve the stress of your monotonous day, there's no reason for him to say no (assuming he/she is rational). It's almost implied, but I'll say it anyways - every time you ask for more, more will be expected of you so be careful not to overdo-it.

Disconnect for your Sanity

If the two suggestions I wrote above don't work, get out of town. Take a little vacation to anywhere that will make you seem disconnected for your work. First, actually leaving your work and not allowing yourself to come into the office on Saturday or Sunday will force you to work more efficiently during the week as your normally flexible working window is now confined by outside forces. Once you're out of town and you've worked hard to take care of everything that needs tending to, remove the tether to the electronic world. Turn-off emails on your phone and don't open your computer. Engage in conversation outside of your profession. If you're a developer or work at a start-up, avoid talking about the tech. like the plague. Let your brain turn off and you'll free very refreshed and ready to go come Monday morning.

Abandon Routine for Perspective

If all else fails, change it up. Take your schedule and flip it on its head. Breaking routine will force you to take a fresh look on everything and re-evaluate why you do everything the way you do.

What if it's not a short-term issue?

The long-term problem is when either your job or the company you work for is becoming the common denominator for lack of ambition or motivation. I have only come across the short-term version of burning out and hope to never come across the long-term kind so I don't have any suggestions to counter-act this. The only thing I can say is that whenever you need to radically change a prevalent aspect of your daily life, you need to shake up your routine in a drastic way. Coming from someone who was overweight for a large portion of their life and lost 60 pounds 5 years ago and haven't put a pound back on, you need to do something big. Small changes are easier to relapse on and you'll fall back into your problematic lifestyle before you know it. You need to go down to your core and summon as much will-power as possible to generate some sort of movement against the current that has led you to your unhappiness your currently experiencing.

How to Develop Locally with the Facebook API

When you create a Facebook application, they require you to give them the domain of your website that will be accessing the Facebook API. The Facebook app keys they supply you with are only valid through the domain of the URL you listed. This strikes the following question: how do you develop locally if your development domain is something like 0.0.0.0:3000 or yourapp.local? The answer is SSH remote tunneling. You use a service to connect a port on your local machine to an open port on a public server somewhere (preferably securely). I've been using tunnlr.com to do this. Tunnlr is not the flashiest service, but it works really well. The following tutorial was made based on my experience with a Rails app, thredUP.com, that I develop for. I'm not sure how useful this tutorial will be to you if you're using a different framework.

Tunnlr Account

Once you sign-up for an account at Tunnlr, you will be given your Tunnlr URL. It will look something like http://web1.tunnlr.com:11908. Write this URL down, you'll be using it later. While you're on your Tunnlr account page, you'll find a section towards the bottom that says 'Need help?'. Follow the steps listed under 'How do I use Tunnlr with Rails' including the plugin and two gems along with created the tunnlr.yml file. I'm not positive you need to do this for creating manual tunnels, but I did just in case. The remote port variable is the number at the end of your tunnlr URL. For example, if your URL is web1.tunnlr.com:11908, your remote port would be 11908. Tunnlr says to use port 3000 for you local port, but I've been using 80 because of some issues I ran into with our app.

After everything is configured, it's time to get this baby up and running. I've always deferred to creating a manual tunnel as opposed to doing any rake tasks, but to each their own. The command to do so is in the 'How do I manually start a tunnel?' help section. It should look something like this:

In this example, 11908 is your remote port number and 2202 is your user number, which you can find on your Tunnlr account page. If you plan on tunneling a lot, I suggest creating a bash alias like this:

Now I can just type 'tunnelme' into my terminal any time I want to test Facebook locally. So assuming you're ports are ok and your local development server is running, you should be able to go to your Tunnlr URL (i.e. http://web1.tunnlr.com:11908) and view your local app. If this doesn't work and you have good reason to believe it has nothing to do with your local development, try adding the facebooker.yml file that is detailed in the 'How do I use Tunnlr with Facebooker?' help section.

Facebook Setup

Assuming your tunnel is good, now you're going to need to setup a second Facebook application to develop locally. Go to Facebook developers page and create a new application. When they ask you for your Site URL, paste your full Tunnlr address (http://web1.tunnlr.com:11908). For the Site Doamin, just put web1.tunnlr.com. Boom, you're done. Enjoy :)

Parting Gift

Most Rails apps have different config files for each environment such as development, test, and/or production. This is really convenient in the context of developing for Facebook applications as this is great way to handle having different App ID, API Key, and App Secret variables. Definitely setup your Facebook app in a way that is indifferent of what environment it's running on.

If you have any questions about setting this up or I messed up somewhere along the way, leave a comment below and I'll follow up the best I can.

From the Dev Couch: SoftFacade, Pow, Flow

I'll start doing some more tutorials, gem configurations, and code snippet posts soon, but these posts are a lot of fun and I've come across some cool websites and apps recently that I wanted to share.

Inspiring Websites

Topic: SoftFacade
Link: SoftFacade.com
Twitter: @SoftFacade
Dribbble: dribbble.com/softfacade

Let's kick it off with a fun one - SoftFacade. Wow. Where to even start with SoftFacade. Their work is so visually stunning that it will leave you questioning how it's possible to even compete in the same stratosphere when designing your own graphics. If you haven't seen any of their portfolio, here's a quick montage I made containing some of their work:

Crazy, right? Who wouldn't kill for a logo like that? That's not all either, as I eluded to in my post last week about SimpleGeo, SoftFacade also does front-end UI work. Rarely do you find graphic shops capable of understanding what it takes to deliver a professional web presence for a company, but they obviously have that skill in aces as well. In addition to SimpleGeo's website, they also did Project Noah and SendGrid. Very excited to see what this top-notch Russian shop has in store next.

Apps to Improve your Workflow

Topic: Flow
Link: getflow.com

Flow is a web application that allows you to tackle lists and projects by yourself and with others . . . . . . . you're probably thinking to yourself 'Did someone else really make another task management app?'. Yup, but it's awesome. Unlike BasecampHQ or Lighthouse, Flow has a social spin to it. Not Color social, but real social. Flow's video demonstrates it best, but they have an iPhone app that allows you to collaborate on things in real time - i.e. planning a party. They also have push notifications, so if you made a list of things to get for a party and your friend bought the beer and checked it off in the app, you'll be notified and not through email.

Did I mention it was designed by MetaLab? They are responsible for some of the best looking websites out there. MetaLab and SoftFacade's portfolios would be the equivalent of the Rumble in the Jungle if they squared off against one another. Back to flow, the design was so good that they made it fun to make lists and tasks, something I already have a perverse pleasure in. Quick tangent - if you're a list-oriented person, you'll like this book I've started reading called The Checklist Manifesto . If you want more info about the app, check their website out (which is pretty rad) to see more.

Learning About New and Old Technology

Topic: 37signals Pow
Link: pow.cx
GitHub: github.com/37signals/pow

37signals released a lightweight, open-source chunk of software that let's you develop faster? Am I a sarcastic question talker? Apparently. And yes, 37signals has made another contribution to the open-source community with their release of Pow - a super simple and fast Rack server.

While it may not be at the same level of Ruby on Rails in terms of potential impact to the development community, it's still a noteworthy offering on their behalf. If you develop on apps using Rack (Rails, Sinatra, etc.) then Pow will become your buddy. When you have multiple apps you're working on, it can become a really big hassle setting up your virtual host files and configuring IPs in your webserver of choice. Pow takes care of all of that for you. All you do is run the install, set-up a symlink to the app's directory and you're off and running. If your project is located at /Sites/thredUP, then the server address becomes thredup.dev. You can setup as many apps locally as you'd like and they are all able to talk to each other (really handy with APIs and sub domains). They also did an amazing job designing the webpage for the project:

If you're familiar with Jason Fried and the 37signals suite of product designs, you probably would have expected nothing less.

I can tell you from first-hand experience that it's really hard to turn a project you're working on into something that can be used and developed further by everyone. It takes a certain level of abstract thinking to exclude all your app's specificity when you're at the design phase of the project. For more of 37signals open-source work, check out their GitHub repository. I'm always a fan of those giving back to the open-source community and I hope someday soon I'll be able to do the same.

From the Dev Couch: SimpleGeo, IndexTank, Loggly

thredUP is hosting the San Francisco StackOverflow Meet-up this Wednesday, April 6th at 7pm at thredUP HQ. If you're a developer, designer or interested in getting into the web development field, you should really come. There's going to be beer (assuming you're 21), some snacks, and three really cool companies demo'ing their new, cutting-edge services. The great thing about all three companies that will be present at Wednesday's meetup is that all of them could be very useful for most apps. Below you'll find a little bit about each company and their services.

Learning About New and Old Technology

Topic: SimpleGeo Context
Link: simplegeo.com/products/context/

Andrew Mager, SimpleGeo's developer advocate, gave the thredUP dev team a demo last week about the 3 services SimpleGeo provides: Storage, Context, and Places. I'm not sure how to describe our reactions other than being absolutely blown away. All of our minds were racing with ideas. There were times during his demo when one or more of our jaws dropped, literally. If you can come to our Meet-up this Wednesday you can see for yourself and realize I'm not exaggerating at all. You don't have to be an engineer to appreciate what they can do either.

Storage provides a way to store location-based data in a system that scales well and is lightning fast to query. Places is a way to use that location-based data to find points of interest all of the world (and their database is growing rapidly). Context, however, is the one that could open doors to hundreds of new ideas and apps. Imagine being able to take a location, whether it's an address or latitude/longitude coordinate, and extracting specific contextual relationships that are defined and accessible like this no where else on the web. What does that mean? It means given a location you can determine someone's postal code, their weather, school district, neighborhood, census data, and the list goes on. Think about using all three of these services together and your head might explode. Proceed thinking with caution.

Web Services for your App

Topic: IndexTank
Link: indextank.com

I don't know if you've ever played around with indexing and search engines, but it's not a walk in the park. There are a lot of different options when it comes to search (Sphinx, Terrier, Solr, etc.), but if you're not savvy with linux and hooking up 3rd-party gems/libraries to utilize and maintain the indexes necessary to run these engines, you should probably look into a service like IndexTank. IndexTank does all the indexing for you and allows you to add search functionality to your website using their API, which is available in Python, Ruby, PHP, and Java. If your team is small or your resources are limited, don't re-invent the wheel especially when someone has a great, simple-to-use implementation that is cost effective.

Assuming you need robust search capabilities, think about how many man hours it would take to build and maintain a new search engine, calculate your developer's hourly rates when you break them down and I'm guessing this will become more and more appealing. Reddit, one of the top 100 trafficked websites with 75 million monthly visits, only has 1 full-time developer now and they use IndexTank. If that doesn't convince you to take a look then I don't know what will.

Topic: Loggly
Link: loggly.com

I'm a metrics junkie, sometimes to a fault. If you're like me or you enjoy optimizing your app then Loggly is your chance to finally geek-out on your logs. Loggly provides a way to analyze your app's logs while presenting the data to you in a consumable way. I've lost an evening before sifting through a 300MB production log file in search of an errant Ruby process that would eat up our server's resources like a worm until it consumed the CPU usage and crashed the instance. If I had known about Loggly, I could have searched the log (they index it for you) with a number of different criteria to narrow down the possibilities dramatically instead of blindly grepping through time windows that *I hoped* the process could have possibly ran within. Do you know how many log entries can occur inside a 15 second window of time on an app? Thousands. Save some time and check out Loggly - they will be speaking this Wednesday as well at the Meet-up.

Inspiring Websites

Topic: SimpleGeo
Link: simplegeo.com

I couldn't resist not commenting on how beautiful the SimpleGeo website is. First, their icons are captivating. Look closely at the detail in each one of them. They're all masterpieces. After you have marveled at the graphic design, check out the SimpleGeo team page and start clicking the different departments (i.e. 'Engineering'). Only the members in the department you clicked will remain visible while the others fade out. This isn't hard to do with jQuery, but it provides an elegant experience and an easy way to deduce the size of each department and make the connections between the faces and the roles. It's the subtle, intuitive UI elements like this that demonstrate superior user experience in my opinion.

From the Dev Couch: Node.js, Facebook Open Graph, Practical Ruby Blocks

Like many others, I come across a lot of great articles and websites every week. The problem is I don't have time to give each one their fair due so I end up bookmarking them for a later read. I'd rather set aside a block of time to read each one thoroughly then skim and move on because I'm always paranoid I'll glance over something profound. Since I took the weekend off, I've been able to plow through about 30-40 of the articles in my backlog and I thought I would share a curated list of ones I think are worth your time. I've broken them out into different categories so people can skip to the topics that interest them the most.

Learning About New and Old Technology

Topic: Node.js
Link: mashable.com/2011/03/10/node-js

It seems like every week there is a new JavaScript framework coming out that will supposedly change the JavaScript landscape forever. After reading this article, Node.js might actually be that framework - but in a completely different way that I anticipated. Node is nothing like jQuery or Backbone. Node is not a client-side framework. Using the JavaScript V8 parser, Node is extremely fast, scalable, and is an event-driven programming model (not that I entirely comprehend EVP). After reading this article and multiple other Node-related articles, I can't say I still fully understand how Node.js works. I think Node is one of those technologies that you can't effectively 'learn' until you've actually played with it. The Mashable article I listed does a pretty good job talking about the background of Node and some practical applications.

Inspiring Websites

Topic: Mutant Labs
Link: mutantlabs.com

Inspirational websites really speak for themselves. I'm not a graphic designer, but I can appreciate attention to detail and mastery of a craft. Click around and I'm sure you'll see what what I'm talking about.

Cool Snippets of Code

Topic: Practical Uses of Ruby Block
Link: viget.com/extend/practical-uses-of-ruby-blocks

If you develop in Ruby, odds are you write a lot of these types of blocks - you assign an object and then wrap your block of code around an 'if object' statement. I think these are fine and they take up the same amount of code as the new way; however, I like the clean assignment and readability that the new code proposes.

Rails Gems Worth Checking Out

Topic: Facebook OpenGraph to ActiveRecord Gem
Link: github.com/rubenrails/acts_as_opengraph

So this is really cool. Facebook integration is everywhere these days. What if you were able to take a model and turn its objects into Facebook Open Graph objects? That's what acts_as_opengraph does. For example, what if you were building a blog engine or basically any type of model that has a show page that will need Facebook integrated on it. Well all you do is take the model and add the dependency like this:

Then you just integrate this into your layout and views wishing to use the Open Graph:

Hopefully you found some of these interesting as I have about 30 more articles that I'd like to post in a similar fashion in the upcoming months.

Working for a Start-up: Ambition

I'll start this post off with some irony. I felt inspired to write this post...about 3 months ago. I was at the airport waiting for a delayed flight and wanted to make good use of my unanticipated downtime. It's only fitting that I'll be finishing this post 3 months later at the same airport making the same trip from SFO to LAX.

Ambition and inspiration are closely tied. One inspiring idea can create a wave of ambition - the stronger the inspiration, the bigger the wave. The inverse also applies - a lack of inspiration can create a stagnant pool of untapped ambition. The dynamic of how individuals create and process their own ambition ranges greatly from what I've seen. Some people are fortunate enough to be born with a self-sustaining drive that seems to never end. They wake up in the morning, run 5 miles, answer 50 emails and then continue to kick the day's ass with little effort. Others want nothing more then to work 9-5 and go home and enjoy the smaller things in life. Some, like myself, have outside forces that can push and pull on one's ambition. In my opinion, people you're surrounded with, self-discipline and inspiration are the most substantial forces in ambition. If you find yourself in the perfect storm of all three, the desire to attempt something great is born.

Inspiration can take many forms. For some people inspiration can be the result of utter fascination of a topic. A great example of this is Jack Dorsey, founder of Twitter and Square. The initial conception that morphed into Twitter was based on Jack's fascination of big cities and the networked data surrounding emergency and other dispatch services within the cities. The key is to start small. Try to wrap your head around something you can fathom. If you have something very interesting in your hands, see what you can make of it. Jack started by manually entering data (i.e. a vehicle is doing X from point Y to point Z) onto a map. I'm sure when that data was laid out in an intuitive fashion he was able to start iterating on ideas about what to do with the data. He ran with what inspired him and look where it led him. Sure, it couldn't hurt working with a great product guy like Ev Williams or a front-end guru like Biz Stone, but aligning yourself with other like-minded, intelligent individuals is part of the recipe to genuine inspiration.

Recently, in an interview with Kevin Rose, Jack talked about having the sheer audacity to start something big and not only having the desire to do it, but to make it beautiful as well. He went on to say that the pairing of vision, architecture and engineering is the culmination of this desire. You can't do it all by yourself. One person didn't build the Golden Gate bridge. At thredUP, our CEO is in firm command of the product while our CTO is making the magic happen behind the scenes. There's still a gap between these two pillars of the company and that's where our CCO (Chief Creative Office) architects how our customers will interact with thredUP as a product. The three founders complement one another well and bridge the gaps between great ideas and turning those ideas into a great product. Pair your strengths with others who are strong in your week suits and only good will come of it. If you rely solely on yourself, you will burn up your ambition on things others are far more capable and suited for. Ambition is a self-replenishing resource, but only when managed in a sustainable fashion.

Lastly, finding the source for your ambition is important, but what you make of it is equally important. Harnessing the energy and inspiration that surrounds your ambition is the fuel to creating something special. Unlike fuel, inspiration cannot be stored and you have to act on it. You might get that urge to write a blog post, start the new app you've been thinking about or re-design something that has been irking you, but if you let it pass or if you let laziness rear its ugly face, that urge may never come back. As I am still in the learning phase of my career, this post is as much of a call-out to myself more than anything else. I want to be accountable for inspiration when it appears and channel it into something substantial. We live in a world where every person with a computer is capable of starting their own company or working for one where they can make a difference. Disciplining yourself to make something happen when the inspiration hits while leveraging others who can help you in its conception is all that it takes.

Working for a Start-up: Expectations

The following was written by Mark Suster (original post found here) regarding new hires and start-ups:

Join our company if you think you’ll learn from being here. I think you will.

Join if you think your career will progress because you’ll be given more responsibilities than elsewhere and if you’re good at what you do you can move up quickly. We’re a meritocracy.

Join because you know you’ll be earning less than you could elsewhere at some meaningless job cranking out non-core code, producing Powerpoint slides or shuffling paper. You can always earn more. But join here if you want to grow.

Join because you like the culture. You think you’ll have fun. You’ll consider your colleagues close friends.

Join because in three year’s time when you look at this job and this company on your CV you’ll feel proud and it will be part of how you got where you were going.

Join because as we grow our ability to reward you will grow and your income will grow with our success that you contributed to.

We give out stock options. I hope they’re worth money to you some day. But let them be “icing on the cake.” If they pay off handsomely that’s great. But don’t count on it. Don’t let it be your motivator or your driving decision.

I am currently working at my third start-up, thredUP, and after reading what Mark Suster wrote and how dead-on it is, I couldn't resist elaborating on his post. Each start-up I've worked for has been dramatically different from the others. My first start-up was funded by the founder's friends, the second was self-funded and thredUP is VC backed. I wish I would have read Suster's post when I graduated from college because only my current company would have passed this gauntlet.

Join our company if you think you’ll learn from being here. I think you will.

There's a subtle assumption hiding in here: you must be willing to learn, especially if you're not coming in at an executive level. You must be comfortable trading off immediate financial gains for potential, long-term financial gains by way of experience obtained (or stock options actually returning something in the rare case).

Join if you think your career will progress because you’ll be given more responsibilities than elsewhere and if you’re good at what you do you can move up quickly. We’re a meritocracy.

Checkmate! This is my #1 selling point. I will never join a company that I don't think is a meritocracy. I want to know that my hard work will be awarded above any seniority-based or politcally-based merit system. My age, duration of employment, or who I know shouldn't play nearly as large of a factor as what I'm doing for the company. In the ideal world it should be based on contribution, teamwork and efficiency. If I'm not performing, I shouldn't be rewarded.

Join because you know you’ll be earning less than you could elsewhere at some meaningless job cranking out non-core code, producing Powerpoint slides or shuffling paper. You can always earn more. But join here if you want to grow.

Anyone who has worked for a large corporation knows what this point is referring to. Ever seen Office Space? Ever filled a TPS report? You get the picture.

Join because you like the culture. You think you’ll have fun. You’ll consider your colleagues close friends.

All three of these sentences could have been broken out into separate points as they are all crucial to enjoying your job. Start-up culture is jeans, flip-flops, t-shirts, music, beer and HR jokes. Mix these with close colleagues (aka friends) and you'll end up with fun. You're going to need to have fun because it will help offset the workload. You'll need that fun as an escape to the grind. If you don't think you'll have fun, don't take the job.

Join because in three year’s time when you look at this job and this company on your CV you’ll feel proud and it will be part of how you got where you were going.

I've been working at thredUP for 6 months and I could turn my previous 1 page resume into a stacked 2 page resume now. You'll be amazed at the amount of ground you can cover (project-wise) in a start-up. What's more important is that you'll have a sense of pride in your work. At a start-up, your contributions have a direct correlation to the company's success. When you go the extra mile, it actually means something. Someone will see it. The inverse of this applies as well. If you slack off at a start-up, you're only hurting yourself.

Join because as we grow our ability to reward you will grow and your income will grow with our success that you contributed to.

This point is the reward of being in a merit-based company. If you're killing it for a sustained amount of time at a start-up and you're being compensated with a salary sizeably less than industry standards and you don't have a vested interest, it's possible you're being taken advantage of. Being humble is a requirement at a start-up, but you must remain shrewd. Your time is an investment - make sure the return is proportionate to the contribution (even if the ROI isn't imminent). Shrewd patience will prevail...I hope.

We give out stock options. I hope they’re worth money to you some day. But let them be “icing on the cake.” If they pay off handsomely that’s great. But don’t count on it. Don’t let it be your motivator or your driving decision.

I think this is wise. A vested interest is a very strong motivator, but don't let it be the only one. If you care too much about options you might bail if the situation becomes temporarily bleak. 99% of start-ups won't have Facebook, Zynga, Twitter or Groupon valuations. Manage your expecations.

AJAX Content Pagination with Dynamic URLs

Sorry about the ugly title, I couldn't think of a better way to describe the post in fewer words. The long title would have been: "How to paginate through content with AJAX and still be able to share the current content piece that is viewed without the page refreshing". See why I shortened it? Onto the post.

AJAXing content in and out creates a nice experience for the user when done correctly. You can flip through posts or articles in a magazine-like fashion. If you're having trouble visualizing this, a good example is daily.thredup.com. The Daily Thred is a new project that a colleague of mine, Heidi, and myself created over the past month. Heidi was in charge of all of the front-end (design/layout/templates etc.) and I was responsible for the back-end implementation and JavaScript. Since we're a Ruby on Rails shop here at thredUP, I chose the Refinery CMS gem to handle the majority of the functionality. As for the JavaScript library of choice, we use jQuery. I love jQuery.

jQuery makes working with JavaScript fun. Seriously. A lot of people think of JavaScript and cringe, but I always look forward to the part of my project that involves JavaScript. Anyways...a big requirement (at least in my mind) of this project was being able to share the URL at any point in time on The Daily Thred and having that URL reference the current piece of content the user was viewing when they copied the URL. If you're reading this, you probably know that if you change the URL in the browser (i.e. thredup.com/how-it-works -> thredup.com/register) with window.location.href, the page refreshes automatically. Not very convienent for the problem we're trying to solve, but I'm sure there are security reasons for having the browser respond the way it does. The answer is not the window.location.href object in JavaScript. Close though, the answer is the window.location.hash object. Subtle yet important difference between the two.

The hash portion of the URL (http://thredup.com#hash_portion) is not visible to the controller. You can play around with the params variable in Rails all day or the $_REQUEST variable in PHP, but you'll never find the string 'hash_portion' anywhere. This is why we have to use JavaScript. I came to this conclusion after doing some brief reverse-engineering. I knew Facebook allowed you to browse pictures without the page refreshing while still being able to the share the URL of the specific photo you were viewing at all times. So I watched the URL while flipping through some photos and sure enough I saw that the URL was changing with each new picture, but only after hash portion of the URL. I figured this must be the key and I began Googling, which is a developer's best friend.

After reading a couple of posts on Stack Overflow, a developer's 2nd best friend, I quickly discovered a couple of plug-ins and libraries that already existed for this exact purpose. The only problem was they didn't seem easy to configure to our app's needs and they weren't lightweight. I wanted something fast, very fast. I also wanted the feature to fail gracefully in the event garbage was entered to the URL's hash parameter. So I decided to write my own implementation.

There are two parts to my code. The function definitions and the setup calls. As usual with most jQuery plug-ins, the setup calls need to be made when the DOM is ready. I also have an additional call that should be the first jQuery call made after the jQuery <script> includes. Here is the setup:

The paging.check_hash() call (which I'll show the code for in a second) checks the URL's hash string to see if the URL is actually referencing another piece of content. This function will intercept the current page from loading and swap out its contents for the hash string referenced content before the user ever notices. Here is the rest of the code:

As you can see the URL's hash string is updated upon a successful AJAX request. You'll also notice there's a function called refresh_social(). The purpose of this function is to find the Facebook Like and Twitter Tweet social plug-ins on the page and activate them. My controller returns a block of html to the AJAX method and therefore the JavaScript within that block will need to be called/refreshed once the DOM is visible to the new elements. Without those calls, not only would the Facebook/Twitter widgets not be unique to each content piece, they would never be clickable as the 3rd-party API calls need to be made first.

Hopefully that was helpful in your AJAX endeavour. As always, shoot me an email (contact info. below) if you have any questions or see any flaws in my code. Also, if you're looking for a new job and you're interested in learning Ruby on Rails or are already a RoR developer, send me an email and I'll forward it along to the right people because thredUP has some openings on the dev team (and it's an awesome team to work for).

The next step for this plug-in will be adding forward/backward functionality with the hash event. Should be fun.

Refinery CMS Review

If you're looking to try out Refinery CMS for your app, there are a couple of things you should know ahead of time. If there is anything I don't cover in this review, shoot an email to dan[at]thredup.com and I'll see what I can do.

Background

Refinery is a Rails 3 compatible CMS gem that allows users to perform the standard Content Management System (CMS) tasks - create, edit and manage content on a website. However, given its Rails nature, Refinery is capable of much more than this. Refinery was developed in a way to allow 'engines' to be seamlessly integrated into the Refinery app.

To take a step back for a moment, Refinery can be used in many different ways. For example, if you have a large pre-existing app, such as thredUP, Refinery can be used/integrated to serve up all your public facing content such as your help section, press releases, or any other content you might want non-developers to edit. I think this type of application of Refinery is using the CMS in the traditional way. Another way of using Refinery is using it as the founding architecture of a whole separate app. This is what we did with the Daily Thred, which is a good transition point back to using engines within Refinery.

The analogy I use for engines is that they are to Refinery as gems are to Ruby on Rails. Engines tap into the existing infrastructure of your app and typically extend or add new functionality. You can use pre-existing open sourced engines or you can build your own engines to mold Refinery into your project's necessities. This open, modular approach has turned me into a Refinery proponent.

Installation

It's easy. I went from gem install to posting my first page in about 5 minutes. Refinery has a great guides section of their website dedicated to getting all the essential components one might need setup. Here's a look at my Gemfile and the custom gems we ended up choosing:

Pros

It's free and open source (thanks open source community!)
It's easy to install, configure and extend
Decent documentation and the guides are adequate
Needed urgent help once and their IRC channel came through for me
Readily updated (last commit was less than a day ago)
Really easy to style
Engine list is growing

Cons

No post scheduling - had to create myself
No easy previewing - had to re-write the system
Any changes to system require overriding files (not sure how else I would do it though)
Image storage implementation is ambiguous

Conclusion

It's open source, so there's not much more you can ask for. If you do want something that's not there, fork it and do it yourself - that's the beauty of open source :). As you can tell the pros definitely outweigh the cons and therefore I recommend Refinery and hope others start to pick it up as the community will grow and more engines will be available. If you want to try it out, here is their github and here are the creators.

How to Dynamically Add a Selected Class to a Sub-menu

I haven't created any blog-worthy code contributions in Rails yet (hopefully soon), but I have something that I think is pretty cool to help people who have multi-level, navigation menu user interfaces...say that tens time fast. It's common UX practice to inform the user what page they are on through some sort of visual mechanism - i.e. you're on the 'Contact Us' page and the 'Contact Us' link is underlined or styled in a way that differentiates itself from other navigational items. This is simple to accomplish in Rails. You can set a variable in your controller and pass it down to your view to discern the current page. Then it's as simple as attaching a {:class => selected_class} on your anchor tag where selected_class is the variable set in your controller. Simple enough. What about when you have sub-menus that contain individual links there as well? Well, you can keep passing down the current page from your controller to your view, but at a certain point your navigation menu code becomes scattered with duplicative logic. I believe I've found a simple solution to this.

The first image is part of our in-house metrics navigation menu. The second image is an expanded view of the sub-menu that lies within each top-level menu item. Each top-level menu item has its own controller, which passes down the variable selected_class to layout view, where the navigation lives. I do a simple check above each top-level menu item to determine which controller I'm currently working with.
It looks like this:

The class 'active' is a style set in the CSS to differentiate your top-level item from the others. Now to set an additional style to whichever sub-menu item is currently also selected (as shown with the green background of 'Avg Star'), I wrote a simple jQuery function to scrape the current page's URL and check it against all the sub-menu anchor tags and their href attribute values. Once it finds the sub-menu item with the same href value as the current URL, I add a class onto the element.
The code looks like this:

There are three blocks of code that run on DOM ready. The first is a .click() handler that reveals the sub-menu hiding below each top-level navigation item. The second is a command that does what the first handler does for the currently selected top-level navigation item (that was set by selected_class). The last finds the currently selected top-level item and looks through it's sub-menu to place the additional .active class for the specific page we're on.
For some context, here is what the source HAML code looks like:

Hopefully that was straightforward enough to understand. I know it's pretty dry, but maybe you can think of another use for the code or be inspired to create something better. If you have questions or can think of a more efficient way, shoot me an email (dan@thredup.com).

Also, if you're a Ruby on Rails developer or an ambitious programmer looking to learn Rails, check out our jobs page or drop us a note at jobs@thredup.com. I've been working here for a little over 3 months now and I can honestly say that the grass over here is at green as it looks.

Rails Learning On the Fly

When you're learning a programming language out of necessity, you skip some steps along the way in order to accomplish the immediate goals you're focused on. Going back and finding those missed steps is important once you get to a point where you're comfortable executing your daily tasks without reference. So here are some Ruby on Rails pieces of code I learned after the fact.

Manipulating data sets in Rails is made simple by two simple symbols - ampersand (&) and bar (|). & takes two data sets and returns the common objects in the set. Bar (|) returns all items in both sets but only unique items. Simple tools for your Rails toolbox and if you missed them in the beginning of your learning, like me, they can become very handy when thinking through solutions.

If you're a C++ or PHP guy, this next one is great. Collect is a method on array that is extremely useful when you want to access a particular attribute on an object in one line of code. Example 1 is there to should the length alternative that accomplishes the same thing.

Both of these next blocks execute the same query, but one is much cleaner than the other. It may be somewhat subtle, but the difference can do a lot in terms of code readability and consistency. There's also a hidden gem in there - :historical_ID => pkg_arr where pkg_arr is an array of ideas. This is the same as "historical_id IN (3234, 2349, 23434)". Very useful for big sets.

Last one is simple. How to build a quick array for iterating purposes. Both examples achieve the same goal, but one in less than half the code.

I know these aren't much revelations in the code world, but every ounce of productivity matters and if one of these can save you a couple lines of code, well then it's worth it.

Working for a Start-up: Sprinting for the Win

thredUP operates in 2-week sprints. This means that every two weeks teams are either transitioning to or already working on their next project. Personally, I love this project management methodology and would urge other teams/companies to look into this strategy for a variety of reasons. Since I didn't create this idea and am not in the position to make strategic decisions of this nature, I'll only give you the perspective of someone on the ground floor working in sprints and how it impacts my work-flow on a daily basis. So if you're in the power to make these kinds of decisions at your company, here is why I suggest you do so or at least entertain the possibility.

First, let me quickly provide some context for the term sprint with a brief background of its origin. Sprints are a key component of Scrum development. I'm not 100% positive it is the reason why we do sprints here at thredUP, but since the dev team has 'scrum' meetings every morning, I think it's safe to assume that 1 + 1 = 2 in this situation. Scrum is a highly iterative and agile development project life-cycle strategy. Plan out the sprint, break-down who will be doing what, then get your hands dirty. It's pretty fun. I like to think of it like a 3-man weave in basketball. For those not familiar with the term, it's when 3 people pass the ball back-and-forth down the entire length of the basketball court without ever dribbling. From a distance, it looks like three people running very fast bobbing and weaving across a court and eventually ending with a simple lay-up. You never hold onto the ball long enough to dribble and slow down. You never get the chance to over think what you're doing - execute and react, it's that simple. You rely heavily on your team members and timing and this is why I think it is very similar to the ebb and flow of a sprint. At the end of each sprint you evaluate, plan how you will iterate accordingly, and then plan out the next sprint. Rinse and repeat.

For a real-world application of how this works, we recently released the ability to become a ;thredUP military member, a member role that is eligible to receive additional benefits. This project touched many areas of our application and in result the project was broken out into several smaller tasks that could be assigned to small groups of team members and tackled quickly. Back-end, front-end, design and marketing all worked together to roll this out in two weeks. By breaking into small groups and assembling teams from different departments, it allows us to provide quality results in a short time frame that cover all angles of a project. When you work closely like this, everyone is exposed to every facet of the project and therefore the feedback is immediate. You can iterate and pivot at a much earlier point in time when everyone is banging (heavy testing/usage) on what you're working on. So your individual projects are agile in that sense. If you take a step back and look at all the sprints and your product from a broader level, you're agile there as well. All of the individual sprints are little cogs in the product and you can assemble and move around pieces very easily.

The flip side of is would be if you spend months developing a big iteration or feature of a project. You'll end up banking that it will be a success because if it fails, you will have wasted a lot of time and resources. I hate to throw one of my favorite websites under the table, but Digg v4 is a great example of this. Digg spent what seemed like 6 months to a year preparing the roll out of their new design, interface, feature set and back-end implementation. Complete overhaul. All the apples in one basket. How did it turn out for the once powerhouse crowd-sourced news aggregator? Well, within 2 months of launching v4, the CEO, CFO, and CRO (Chief Revenue Officer) have all left their positions. As if that wasn't enough of an indicator, Digg laid off 37% of their staff (plug: thredup.com/jobs), lost over 20% of their traffic, and they have already started reverting back to some of the previous version's functionality they took away. I think Kevin Rose is a talented entrepreneur and I believe he can help Digg bounce back and when they do they should really try out Scrum. If they would have iterated and released earlier, the backlash from users would have occurred at a much earlier stage and the agility of Scrum would have allowed them to adjust and avoid the downfall. I could go off into a monstrous data-driven development rant and why it's so important but I'll save that for another day.

So Scrum is solid from a business point of view, but why would your employees or me for that matter enjoy this as well? I'll break out my rationale into a list:

You never get bored. How can something get old if you don't spend more than 2 weeks on it?
Goals and milestones are actually attainable. Every day I can reach a significant milestone if 10% of the project's time passes by every day. These tangible goals are motivating and leave no room for procrastination. There's never a point where you think to yourself 'no one is going to see this for another 3 months, today doesn't really matter'.
The energy levels are always high. New projects and ideas are always right around the corner and the creativity is contagious. Boredom is canceled out by this energy and since boredom and productivity have an inverse relationship, everyone is always churning out results.
Developing inter-personal skills and relationships with co-workers is an excellent by-product of sprinting. You learn new tools and skill sets from working closely with team members and you enhance your ability to explain/write code that can be easily built upon. There's also the added benefit of developing an excellent rapport with your co-workers.
There's no pigeon-holing. You have to turn into a Swiss army knife and be comfortable attacking any component of a feature. It allows you to be more versatile in future projects.

Hopefully this post illustrates why I find sprints as motivating and productive as I do. Honestly, I can't imagine ever going back to a traditional product life-cycle after dipping my toes in Scrum development.

Working for a Start-up: The Art of Switching Gears

When you build something that you pour a lot of sweat and tears into, it's very hard to let it go. You build something awesome, execute with high quality and you're asked to let the project go because it's not in the product's best interest at the time being. Even if the decision is right, it's a tough pill to swallow. Your natural inclination is to fight tooth and nail, but you need to let it go and switch gears as it's your job to do what's best for the product. So how is this done? Well, thanks to our CCO (Chief Creative Officer) Oliver Lubin, I'll be able to tell you exactly how it's done.

Oliver recently built an awesome prototype for thredUP. When you're logged into thredUP.com, there is a 'lid' in the top right that contains all the useful information a user would want to have access to when logged in (link to your account, sign-out link, etc.). He made a killer design to re-do the lid and added some sweet functionality for it. He passed around the design for feedback and I think we all thought two things: 1. it looked awesome. 2. it was information heavy/dense. At this point, no one expressed enough serious concern to squash the feature. So Oliver entered the implementation phase of the feature.

Quick tangent - for me, this is where I bond with the features I make - when I put all the nuts and bolts together behind the scenes. I think the reason for this is because after you mock-up the design for the look and feel of the prototype and you start putting the code in place, the feature has gained momentum and it's harder to pivot its direction. Every step you take forward with the project further cements the rigidity of the feature and your ability to detach your emotions of what you're building. Time spent working is energy used. Wasting energy is not something I enjoy, it's something I struggle with, but enough of me, back to the story.

Oliver finished his implementation and it worked exactly liked the mock-ups envisioned. When the feature's entry into the website was discussed, it was ultimately decided that his initial conception of the 'lid' needed to be scrapped. He took the news in stride and got right to work on the new 'lid'. I was in awe. 'That's it?', I thought. Not even an ounce of complaining? Nope. Smile on his face he went back to the drawing board. I had to know how he could do this, so I wrote the following email to him:

Oliver, I'm writing an entry to the dev team blog and would like to know if you have any advice on switching gears. Specifically, how did you accept the fate of the lid that you spent days (and nights) building?

His response was:

Sometimes your gut will tell you things you ignore. Luckily this time wasn't one of them. I'd say the key in these critical moments is listening to and trusting your gut. I had a feeling something wasn't right. Creative things often make sense better in the minds of their conceivers -- I know where every little nuance is and why it all just makes sense, to ME. But that kind of bias can get you in trouble. You have to watch people's reactions, see how many questions they ask, how much explaining you have to do of the things that you think are just obvious. Observe yourself and others no matter how much you like it. If you hear yourself saying "man, I really hope people get this." you're in trouble. At that moment where you have to switch gears you have to recognize what's really broken. Is it the idea or the execution? And don't be afraid to let it be the idea more often than not -- your ego will thank you later either way.

Oliver's humble approach to design is very refreshing. Integrating his philosophy into your everyday workflow helps keep peace of mind because in the ideal world, every feature would be agile enough to permit changing the direction at any moment, but we all know this is rarely the case. Even if it were possible, letting yourself let go of the time you sank in the project is hard - it's conceived as wasted time. If only someone would have said something earlier... Well we don't live in this ideal world and this situation presents itself to an engineer at one point in their career whether they like it or not. Don't look at the time or energy as wasted when the project is axed - it's a learning experience to value and build upon next time. I would be surprised if you didn't gain some new tools along the way as well. If you always put the company and product's best interest at the forefront of your decision making progress, I guarantee you will become a valuable asset to your team.

Rails Code Snippet Starter Kit

Sometimes one piece of code in a language doesn't translate verbatim to another. Sometimes 5 lines of code can be written in 1. That is what this post is about - the snippets of code you lean on during the early stages of your Rails learning.

1. Avoiding use of if/else/unless when unnecessary

Ever heard of a ternary operator? No? It seems like one of those names that no one remembers and every one just creates their own name for it. There's a good chance you've seen one before because they're quite handy in the right situation. Here's what they look like:

2. Use the tools Rails blessed you with

Rails provides a lot of cool, built-in functionality with accessing your models. Before you re-invent the wheel, make sure Rails doesn't have something in place for you to use. For me, I wrote a lot of duplicate code in the beginning (and still do unfortunately) because I just didn't know all the tools at my disposal. So here's a helpful one, the Rails 'find_by' method. Instead of writing out an SQL-like statement for your model, use the 'find_by' method like this:

3. Knowing your 'self'

Pretty cheesy heading for this one. Sorry, I couldn't resist myself. Using 'self' can be confusing at first, like when to use 'this' in JavaScript, but it's something you need to get under your belt and once you do it becomes common practice. Here is a simple example:

4. How to use variables in database look-ups

This is one that caused me to go back and re-write a lot of my code. Not only is it good practice, but there are serious security concerns around using variables in database queries. If someone knows their way around escaping values, you run into some nasty potential SQL injection problems. This might not be news to you, but if you've never been told, here's the right way:

Hopefully some of these are helpful. I plan on adding posts similar to this as I learn more.

Text Editors - Getting it Right from the Start

As I am still in the elementary stages of learning Ruby on Rails, my contributions to this blog will be limited to helpful resources for beginners until I am able to share substantial Rails posts. By sharing the failures I encountered along the learning process and how I could have avoided them will hopefully save others from discovering valuable information the hard way. One of these pieces of information is the topic of today's post and is somewhat of a heated debate amongst developers: text editors. (Disclaimer: if you are using Windows or Linux, I'm not sure how useful the following information will be as I don't have a lot of experience with any robust text editors on those platforms. If you are on Mac OS X however, read on.)

From what I've seen, most seasoned developers have customized and fine-tuned their development environment for maximum efficiency. They are wizards with short-cuts and use the command/option/control/shift keys to navigate and manipulate the code they are working on. The combinations of those keys and shortcuts can eliminate the need for a mouse completely when developing. The time saved might seem very small while using these shortcuts, but the more important theme is that you're working smarter. Working smarter is something I have been focusing a lot on recently because as my workload increases, the room for sloppy mistakes decreases. A smart worker can outperform a very hard worker in a lot less time and it's all because of one thing - always do it right from the start.

So what does this have to do with text editors? Well at my new job with thredUP, the text editor of choice is TextMate. Don't let their simple website fool you, it's a much sexier product than it appears. Back in the day, I used the infamous Dreamweaver for web development. I'll save you some time, don't buy it. It's expensive, clunky and built more for a designer more so than a developer. I needed something faster, so I went out and bought Espresso. Espresso is $89 (over $300 less than Dreamweaver) and made by the MacRabbit team. If you like to edit server-side and usually work on small, design-oriented websites, Espresso is a great product for you. I still needed more, so I moved to Coda next. Coda was a step in the right direction for me and there is a very good case to be made if someone wanted to argue that Coda is the best editor for a Mac. $99 price tag, built-in FTP capabilities, great server-side/local searching, in tab terminals, and a decent collection of add-ons make Coda a viable option. I actually did a trial of Coda and TextMate at the same time and chose Coda after my initial trial period ended. However, TextMate won out in the long run.

The out of the box TextMate application is underwhelming; however, the power of TextMate lies within the ability to add custom-made bundles that optimize your coding experience. TextMate is a blank canvas for developers to create a personalized development environment that is unique to your preferences, technical stack, and any 3rd-party products you also use that can be integrated with. The bundles are amazing. For example, if I wanted to define a method in Rails, I could type 'def [tab key]' and my Rails TextMate bundle would properly define and close a method. That's not that impressive, right? Well if I wanted to write a new controller, I could open a file and type 'cla[tab key]' and options would be presented to me about how I wanted to define the class. I select one of them and BAM, the entire controller structure appears out of nowhere. This saves time. You can do all of this in models, views, cucumber tests, rspec definitions and the list goes on. This doesn't apply just to Rails, TextMate has bundles for most programming languages. Textmate has a free trial, I suggest you check it out and start learning your way around a text editor from the beginning.

Here are some more resources:

A Beginner's Journey with Ruby on Rails

thredUP, the company I'm working for, uses Ruby on Rails (also known as RoR or Rails) for their development language of choice...and it's awesome. I'm more of a Front-End developer than anything else, but I have a degree in Computer Science and Engineering that gave me a head start on things like Model View Controllers (MVC) and other Back-End architecture patterns. I can't say I actually enjoyed the back-end classes in my degree and therefore I was somewhat skeptical to what extent I would enjoy or not enjoy working with Rails. After reading the Rail's Wikipedia page, I was starting to become intimidated. Unfamiliar terms like 'agile/rapid development' and 'scaffolding' were being tossed around casually and my concerns started to grow. I knew there was only way to proceed - jump into the deep end and see if I can swim.

What I quickly learned is that Rails takes care of a lot of the ugly work behind the scenes. A lot of things 'just worked'. I didn't thoroughly understand how they were working, but I grasped enough to be able to continue on and I think that's important in the beginning. Take manageable, bite-sized assignments/tasks and just focus on what's right ahead of you. Those little goals can go a long way in terms of confidence and motivation to continue learning.

I think a lot of beginners (such as myself) wonder what will be challenging at first. Well if you're a Back-End layman like me with most of your experience lying within basic server-side scripting languages such as PHP or ASP, the first challenge you will encounter is the syntax barrier. When I went from C++ to PHP, the jump wasn't hard at all; however, unless you're familiar with Python, Ruby will be confusing at first. No semi-colons to end lines of code, everything is dictated by formatting, functions becomes methods and everything you create is an object. It was a completely refreshing experience to start from scratch. I relate it to moving from one city to another. A fresh start is good if you embrace the situation - you can kick bad habits and have a clean slate to work with. Once I got used to the syntax, I started to really enjoy the clean formatting and easy readability of the code. So after you get a handle on the syntax, what's next? Resources.

Surrounding yourself with the right resources is key. I happen to work for an amazing CTO who is very patient and able to help me whenever I come to a dead end. When he's not around or occupied, online resources become my best friend. Rails has great online documentation. For example, if you're looking to install Rails, look here. Ready for a couple of guides to get your feet wet? Try the official Rails guides. If you're ready to start building your own app from scratch, this Rails API is great for looking up Classes and supported methods. I happen to be a 'learn by doing' person as opposed to the 'study first, do second' person. If you're like me, then get your environment set-up and start going through guides - it's the quickest way to feel comfortable working in a Rails environment. If you're working on an app that's already built, try building off previously built models/views/controllers instead of building your own. Seeing working code in action and modifying it is a great way to understand the intricacies of Rails. If that's not your style and want to read up on Rails/Ruby first, it's not a bad idea. Rails has it's own way of approaching problems and it's probably best to have a basic knowledge of principles like DRY (Don't Repeat Yourself) before you develop any bad habits. Supplementing your hands-on learning with studying is probably the best idea, but to each their own.

That about wraps up my introduction to Rails. As I'll be purchasing a new computer in the next month, the next post will be about getting the environment up and running. What apps to use (TextMate, Coda, GitX, etc.) and other fun things like bundles, syntax highlighting themes, and command line tips/shortcuts. I plan on turning this into its own series of blog posts as I continue to develop my Rails learning so stay tuned for more posts that actually contain snippets of useful code, epic failures I'm bound to cross, and useful gems/technologies/implementations that I come across along my journey with Rails.

So Long, Los Angeles

In general, I think most people don't like it when bloggers mix personal posts into their normal feed. Since my average amount of visitors could all fit inside a taxi cab together, I'm not too worried about alienating my following or lack there of.

As I alluded to in an earlier post, I left Los Angeles on Friday to move to San Francisco. The opportunity is exactly what I'm looking for and turning it down was not an option. With that being said, it hasn't been easy letting go of my adopted home of Los Angeles. I'm originally from Michigan, but these past 16 months in LA have been surprisingly meaningful. I'm experiencing the same wave of reflection, melancholy, and nervousness I did after leaving Michigan after 22 years.

I've entered a stage in my life where I want to focus as much energy as possible towards my career. I want to be instrumental (or at least very helpful) in the development of something important, something to hang my hat on, something to be proud of. This next project has a lot of potential and has the right team behind it, the exact formula I was looking for. Now it's time for me to put my head down, work hard and see what comes of it. It's always harder than it sounds though.

The hard part isn't becoming motivated or trying to find ambition, it's severing the ties that were built along the way. My decision to move to LA in the first place was almost entirely professional and yet emotional ties were made during my tenure there. It's easy to say I'll miss my brother who lives in LA or I'll miss a certain lady friend who I've entered into a relationship with, but it's the little intricacies of being brought into a community. It's the doorman at the gym who knows you by name (and who I know by name too). It's playing in a soccer league for almost a year and creating budding friendships. It's the small things. When you say goodbye for the last time and know it's likely you'll never see them again. It's walking off the soccer pitch and wondering if you'll ever walk back on it. These are the lasting effects of moving.

Los Angeles treated me well. I had a lot of great things going for me but a wise person told me "it's better to shake things up when you're on top because you'll never encounter the inevitable demise and you'll leave with only great memories". This quote helped me a lot. When you have to leave behind parts of your life that just started to take form and become important, you need quotes like this to get you through it. I am prideful for a lot of things, but I know when to look to my close circle of friends and family to support me. So for now, I will embrace San Francisco for all it has to offer me. I will see you again one day LA and the reunion will be glorius, but until that day comes I intend to move forward, full steam ahead.

Website of the Week: thredUP.com

Some very exciting news in my world - I'll be moving to San Francisco this upcoming weekend and starting a new job on Tuesday. There are some websites you go to and they blow you away. thredUP is one of those websites and I'm fortunate enough to have the opportunity to work alongside their team. What is thredUP? Glad you asked.

thredUP is a used kids clothing exchange website. Simply described on their 'How it Works' page, there are three easy steps:

Pick a great new box full of clothes for your child - just $13
Post a box of gently-worn clothes your child no longer wears
When another member picks your box, send it 100% free of charge

It's as simple as that. The response I typically receive is "so it's Netflix for children's clothing" - which is a good description I think. Kids grow very fast and buying new clothes for every size can be expensive, so send in the clothes that don't fit and receive the next size up that does fit. The concept is pretty cool, huh? So is their website.

thredUP tailored their website to their demographic. The design is playful but organized and the user interface is simple. The choice of colors are gentle and the graphics give off a comfortable and fun experience. Having an engineering background myself, I'm used to visiting a website and trying to find all the bells and whistles that a web application might have. I'll click on everything and hover over anything that looks like it could potentially do something. thredUP took a slightly different approach it appears, the website seems to have just enough features to make the website feel entirely adequate without a sense of overwhelming.

Now I don't have a child, but if I did I think there are some great, addictive features that would have me coming back to the website frequently. First, they have a sponsor that supplies thredUP with 'Golden Threds'. Essentially, if you're a Pro member of thredUP and you're browsing through the listed boxes available, one of them could be a 'Golden Thred' that contains brand new children's designer clothing from the sponsor. Good exposure for the sponsor and a valuable reward for the user equates to a smart decision from thredUP.

Another great feature on the website is the socially competitive nature of the rating system. Each box is rated for quality (measured in stars) and style (measured in 'stylies'). In return, each user has a rating associated to them that is visible to the users. The highest rated users are featured on the leaderboard (shown above) and their listed boxes are picked faster. Some people are opposed to user leaderboards as it can lead to 'gaming' the system and new users feeling discouraged that they won't be able to make a difference. I don't believe thredUP has to worry about this considering the nature of their users.

I think thredUP has a lot of promise surrounding their idea. It will be very exciting to see what the future entails for the company. Check them out on Twitter at @thredUP or on Facebook at facebook.com/thredUP

Dropbox Is Badass

If you're thinking to yourself 'is that a picture of a T-Rex riding a shark with an AK-47 and an eagle with a grenade on its back?' - well then you would be 100% correct. In what can only be described as an epic display of awesomeness, Dropbox (the on-line file management service) decided to have some fun on their job listings page. Some other fun facts about their culture, laser tag wars inside the office! Check it out here.

Fanboys Give Apple a Bad Name

I grew up in the PC world. They did what I needed them to do and there usually wasn't a problem I couldn't handle. I defragmented my hard-drive, did error checking when necessary, and if my computer was really acting up, I just re-formatted the hard drive and put on a fresh installation of Windows. To a certain extent, I was satisfied.

MacBooks were always around but I thought three things: overpriced, underpowered, and the applications I need aren't there. I eventually learned that the hardware specs between a PC and a MacBook are not analogous. Apple wrote the OS and spec'd out the hardware themselves so the performance is optimized. The applications are there, they just have different names. The price...well they can become expensive as you climb the model ladder but the base-line models are affordable. So why did I wait so long to get one if I de-bunked the common misconceptions early on? Those damn Apple fanboys.

After I bought my MacBook and brought it out in front of people, I received those glances. Those 'oh, you're one of those people' glances. I knew exactly why too. I had gone over to the dark side in their eyes. I didn't blame them for giving me those looks, I perfectly understood why and I often found myself attempting to defend the purchase. I would tell them I was a PC user my entire life and I wasn't a fanboy, but it wasn't enough to convince them. This is because Apple fanboys are the most arrogant technology bullies that ever roamed the planet. No matter what product Apple releases and how good it actually is, fanboys swear up-and-down how 'revolutionary' the product is and how much better it is than everything else on the market. What they don't realize is that it's not for everyone. If you're a fanboy, this might sound shocking, but it's definitely true.

It's like Android and iOS, they appeal to different audiences. If you want to customize every facet of your software and root your phone easily without having to worry about jailbreaking and constant patches, it's probably best you choose an Android. If your focus isn't something creative and your primary use of your computer is tailored to something Windows does great such as Microsoft Office, enterprise applications or even computer games, Windows makes more sense. So if you're a fanboy and you really want to preach to non-Apple users and try and convert them, know who you're talking to. And God forbid they don't want to hear about what your Apple product has to offer, leave them alone. If you really want to allow people to encounter the full experience, then keep your mouths shut. I didn't realize how cool MacBooks were until my cousin purchased one and I kept noticing cool features such as Spaces and Exposé. The features are there and if people want to find them, they will.

Apple's products have the ability to sell themselves. With exception to a couple missteps (i.e. that damn Mighty Mouse or Apple TV), once someone plays around and figures out a cool feature or two on their own, the user can typically see the value in the product. Instead, fanboys try force-feeding the product down everyone's throats. Stop fanboys, you're doing more harm then good.

Website of the Week - Kuler

Website of the Week is going to highlight up and coming start-ups, websites that contain useful resources, and web applications that server as valuable tools. Kuler is definitely the latter. For web designers and especially web developers who have little design background, choosing colors can be one of the most challenging obstacles when designing a new website. Sometimes it's not even an entire website, it could be a new feature or even a new submit button. Keeping a website's color scheme intact is essential to maintaining a consistent user experience and adding one wrong color can push the color balance off kilter. So what do you do when you never took a color theory course? You turn to Kuler.

Kuler is your home for brainstorming new color themes. If you completely lack the eye for spotting good color themes, Kuler's homepage has user submitted color themes. You can look for the newest themes, the most popular, or even sort through random themes if you're looking for something very original. Once you click on one of these themes or choose to create your own, you're taken to a page that presents more details (such as hex values) about the theme and allows you to modify the theme further.

Once you're in the 'create' mode, you have some really great features at your disposal. Select a color or area of the color spectrum you would like to work with and then select one of the rules such as 'Complementary'. If you like a shade of blue, Kuler will display a mix of colors between the blue you selected and some orange shades since orange is the complementary color of blue. Pairing up orange to blue might be obvious, but when you start to select some obscure colors, the complementary colors are harder to determine off the top of your head.

Another useful feature is the 'Shades' rule. If you're working with websites and colors, you'll find yourself searching for good colors that don't deviate from your theme for certain elements such as visited links, hover effects, or even page headings. The shades rule is great for this. Select your base or primary color and you'll be presented with some darker and lighter shades that are great for differentiating new elements on the page from the standard elements.

Whether you're a web designer, graphic designer, or someone who is just creating a new powerpoint presentation and needs colors, Kuler is definitely worth bookmarking. Play around with the features and see what you can create. If you create one you think looks good, let me know by leaving a comment here or tweeting me @dandemeyere. For a feed of user created themes via twitter, check out @kulerfeed.

Website of the Week - Forrst.com

Forrst.com is a website for web developers and web designers to share snippets of code, screenshots, links, and other useful chunks of information that are worthy of sharing. I think Mashable put it best when they said Forrst is 'microblogging for developers and designers'. Pretty decent concept, right? Let's take a look at their website.

When you first go to Forrst.com it's very easy to get distracted by the amazing, playful art work that is on the home page. Best of all, no Flash was used! Another great example of how being creative with jQuery/HTML/CSS can result in some captivating designs. After taking it all in, one might think it's time to go inside the website and start looking around....not so fast. Forrst is an 'invite-only' community. You can either apply on their home page or be invited by a fellow developer or designer that has earned invitations. I had mixed feelings about this at first. It seemed a bit elitist to require an approval process and also the additional barrier of entry left a sour taste in my mouth. Regardless, I was intrigued enough to fill out their application. After a couple of days of waiting, I was notified I was accepted to be a member. Once I logged in the first time, it quickly became apparent why the gate to the community was so tightly guarded.

The quality of posts and comments are very high caliber. Whether you post a question, post a snippet of code, or share a link or screenshot, odds are it's going to be interesting enough to check out. Comments are thoughtful and often provide greater insight into the original post. You don't come across immature shorthand (i.e. rotfl), unnecessary profanity or users trying to troll the website with 'bury' brigades. Careful moderation is also performed by the website's creator Kyle Braggar and other prominent users in the Forrst community. They comment respectfully if a post seems to be irrelevant, improperly categorized or contains incorrect information. If you participate in any forum-like community, you'll find this courtesy rare to come by. On top of all of this, the UI is terrific:

When a UI is so appealing that it actually makes engaging in activity fun, your goal as a UI designer is accomplished. I couldn't help but try out every feature Forrst had to offer because I felt like a kid in a candy shop. The experience wasn't predictable either, there were pleasant surprises around every corner such as their automatic loading post feed. When you're at your dashboard, Forrst loads 3-4 pieces of activity for you to look at. As you scroll down, more pieces of activity are loaded seamlessly and an absolute positioned up arrow is placed on the right side of the screen in the event you want to go back to the top of the page.

Overall I think the website is great and it made its entry into my bookmarks folder of websites I check on a daily basis which is saying something for me. Give it a chance and tell me you what you think about it. Be sure to look me up if you're a Forrst user, my username is @dandemeyere.

Case Study Retrospective

As I sit in the back of a car driving up the gorgeous coast of Southern California, my demented mind can only think about cataloging the conclusion of the case study I recently posted. What a roller coaster this design release has been. Even a calculated, well thought out multi-month project isn't enough to avoid a large back lash from the users. From the choice of colors, to the new features we added, to the way navigation buttons were worded, pleasing every one just wasn't possible.

To find the middle ground between our vision of the website and the user's vision, we engaged with the community in a very public fashion to collect all their concerns and attempt to address as many as we could. Newsletters, forums, emails and blogging were being checked constantly for anything pertaining to the design and our goal was to answer candidly with honest answers for any reasoning that was questioned. During this ongoing discussion with our users, we were on a mission to find the holy grail of statistical sets that quantified the level of activity between the legacy version of the website to our new design. These statistics were crucial for us to determine whether our design choices were valid or not.

Our back-end team had implemented a logging system that essentially tracked every meaningful action a user made while on the website. In combination with running intensive database queries and parsing through said activity logs, we slowly narrowed the scope of the information we were gathering as we dialed in the importance of the data. We only concentrated on new user sign-ups as existing users were already accustomed to the previous functionality and were less likely to try the new features. After we chose the features most important to the website's success, we selected users who signed-up after the new design went live and separated their data depending on whether it was the old or new design. Since we flipped a coin every time a new visitor came to the website to decide which design the visitor received, we knew this method would be fair. The results were overwhelmingly in the new design's favor.

Of the many things I learned throughout this process, the most important was in the statistical analysis. You have to account for every statistic you find. You have to know every detail surrounding that number. You have to rule out all external forces that could affect that number. The numbers you present are your argument and thesis. The second one of your numbers falls under scrutiny or faces a question to which you do not know the answer of, your argument and case loses its reputation and influence. Double check every statistic, look into the database to ensure what you're querying is what you perceive and bounce your logic off someone you trust. Often times you'll discover when you explain your logic out loud, it's different then what you though it was in your head. These are good recipes to having confidence in your findings and gaining trust from the recipients. Confidence is essential. If you don't believe in your findings, no one else will either.

ReWork: Read It!

A couple weeks ago I was watching an episode of This Week In Start-ups , a podcast hosted by Mahalo.com's CEO Jason Calacanis, and something really grabbed my attention. Jason was interviewing David Heinemeier Hansson, founder of 37signals and Ruby on Rails, who was systematically destroying Jason in a debate on the essentials of running a start-up. I've used 37signals's on-line project management tool Basecamp before and had read parts of JHH's first book Getting Real, but I never had the opportunity to hear him speak before. It's really something, have a listen (beware: some profanity): Calacanis vs. JHH.

JHH talked in great detail about the misguided intentions of many internet start-ups: get as much traffic as possible and work towards the big buy-out. Whatever happened to creating a sustainable business model? What about having pride in your company and working to grow and develop the company instead of prepping it for the pay day? Maybe it's harder and less glamorous but I believe it's more worthwhile.

I didn't agree with everything JHH said but it was enough to sell me on the book ReWork he co-wrote and was plugging. The book's flow is a bit fragmented as it jumps through small chapters that contain advice about all different aspects of working in a start-up, but the tips and stories are helpful and in more than one occasion I found myself writing down notes. If you work for a start-up or simply want to improve efficiency at your workplace, I suggest giving it a read.

Here's a quick excerpt out of the chapter called "Meetings are Toxic":

"When you think about it, the true cost of meetings is staggering. Let’s say you’re going to schedule a meeting that lasts one hour, and you invite ten people to attend. That’s actually a ten-hour meeting, not a one-hour meeting. You’re trading ten hours of productivity for
one hour of meeting time.

If you decide you absolutely must get together, try to make your meeting a productive one by sticking to these simple rules:
• Set a timer. When it rings, meeting’s over. Period.
• Invite as few people as possible.
• Always have a clear agenda.
• Begin with a specific problem.
• Meet at the site of the problem instead of a conference room.
• Point to real things and suggest real changes.
• End with a solution and make someone responsible for implementing it."

Living in a Case Study

Ever read a case study about a website? Typically the thesis of a case study is painting an accurate portrayal of your user base, determining how these users interact with your website, and what you can do to improve your website based upon the findings. Get your data -> interpret the data -> extrapolate your interpretation into plans of action. Sounds simple enough, right? I wish.

At my current job, I'm consulting for a company going through the final stages of a complete website overhaul. From a completely re-written and custom back-end to a re-design with all new front-end functionalities, this website is radically different from version 1 to version 2. We beta tested the new version for two days last week and based on the initial feedback there are still some necessary tweaks to be made before the website is ready. However, it's time for me to take these two days and benchmark the data against the legacy website's average data. I love challenges and I relish this opportunity so here's what my plan of attack is. The first step is discerning the information that will be able to uniquely quantify the changes we made. The second step is gathering user feedback and determining how heavily I should weight their responses. We have some very dedicated and powerful users who provide a lot of value to the community and our website's purpose, but should we tailor to our current users or potential new users? I just read in Re-Work there are always more people not using you're product then those who are so build for the general appeal. Let's hope there is a balance between both of the groups.

Do you hate the kind of movies that end unexpectedly and with little to no closure? The kind where the credits roll and you look around with that 'Really? That's it?' expression on your face? Well, you're not going to like this post...more to come when the results are in.

Website of the Week: Mint.com

I know I'm a little behind the times on Mint but better late than never. Every once in a while I come across a new web application that I find amazing. The kind of application that has you reaching for your phone as you use it to tell your friends they have to try it out too - Mint.com was this web app. for me. Usually I'm intrigued by some specific aspect of the website that was executed well such as a great UI (see Gowalla), intuitive layout and design (see thredUP or Zooppa), or functionality that sells me in a matter of minutes (see Shopify or Squarespace). The list of websites that are able to achieve all three are very rare and the ones that are able to be profitable (Mint sold for $170 million less than a year ago) as well puts Mint in an echelon all by itself.

I had heard about Mint in the past through various podcasts and blogs but had never given it too much thought for two reasons: what can Mint really provide me that my current online banking can't and security. Special emphasis on the latter. Mint would have access to every dollar in my bank account, credit card, and investment. Besides Google, I couldn't think of a company I would entrust this information to, especially a company I had never used before. In addition to having access to my funds, there are privacy concerns. This is very privileged information and advertisers would drool of being able to access someone's age, sex, income, savings, and most of all spending habits. Can you even imagine how well they could advertise products when they know every credit card transaction you make? Even the data-mined Facebook couldn't hold a candle to providing as accurate and relevant ads as they could. Despite all of this I gave it a try and it was well worth it.

First, sign-up is easy and Mint is free. After verifying an email address, you can add as many accounts as you wish. Their account adding system is simple, fast, and has two levels of security. You have to enter your username/password information for the account you're adding (through that institution's log-in interface) and answer the security question the institution (i.e. Bank of America) asks. You can also add credit cards account, investment portfolios, loans, cars you own, etc. Once you have a robust profile built, Mint let's you know how liquid you are, what your debt is, your money earned/spending trends for each month, and what I love the most - the ability to budget each category of spending. Mint shows you how much you're spending on gas, groceries, etc. and they have a budget system intact that is editable. These statistical and visual representations of your money allow you to responsibly maintain your finances. What's in it for Mint? They have a section that shows you savings you could be making by switching banks or credit cards and they receive money for every person that switches over. The business model is solid, the user interface is great, and the feature set is robust. If you haven't tried it out yet, I suggest you do so because well....I'm impressed.

Apple vs. Adobe: No-win Situation

I'm not a big proponent of Flash. So when Steve Jobs wrote his open letter to Adobe, I was in full supportof the move. Flash is CPU intensive, a RAM hog, and crashes frequently. With Applebeing the king of controlling the experience, it made very little sense for Apple to allow Flash to be on the iPhone/iPad. It's not personal, it's a strategic business move. Or is it?

Steve Jobs is no stranger to grudges and controversy (see Jobs vs. Gizmodo) and when I found out via TWiT that Adobe took it's development of the video-editing suite Premiere away from the Mac platform for a number of years against the wishes of Steve Jobs, I had to wonder whether this move was retribution against Adobe. Steve Jobs is shrewd, cunning, and ruthless and a lot of his reputation is derived from this, but this attitude and determination is what drives Apple to put out the caliber of products they do. Whether Jobs was paying Adobe back or not, dropping Flash was the right move.

Even though Windows is easily the most prevalent operating system and the iPhoneOS controls a minority of the cell phone market share, Apple's position on Flash caused a ripple effect of content providers to move their video encoding efforts to the HTML5 friendly H.264 almost over night. That amount of power is dangerous and should be used delicately. Even though I'm happy with the outcome and the push for HTML5, I can't create a hypothetical scenario where I could definitively say only good prevailed.

Social Media: Perception vs. Reality

Social media is a hot term right now that I believe a lot of people in the general public don't fully understand or don't use properly. Social media can be a powerful and effective tool for some and complete snake oil for others. I read and hear about people calling themselves social media consultants and experts who can leverage the viral nature of social media to increase website traffic, sales, and awareness for brands. This is only true if you're content is desirable or you're offering something valuable to the public. As cheesy as it sounds, content is still king.

Clever advertising and marketing only goes so far. If you're lucky enough to get someone to your landing page, you still have to sell the person on your product. This is why you must focus on your product first - if you offer high-quality products or services and clearly define what separates you from your competitors, then your product will sell itself. I'm not saying don't build up a social following as you work on your product but people must realize social media only get's you so far. Social media should supplement your brand awareness and outreach efforts but should not be relied upon solely for marketing. Joining every social network and blasting people with updates/information/links isn't necessarily going yield tangible results. A good example is Twitter - by following/adding as many people as possible regardless of relevance and every follower's agenda is going to return nominal results at best. Either those people are following you for the same reason you're following them (to plug whatever you're trying to push) or they're not your demographic. Offer tips, helpful links, great customer service, etc. and you'll receive genuine followers that will actually digest what you're tweeting.

Lastly, it is of my personal opinion that hiring social media 'experts' and 'consultants' isn't the most effective solution to raising your company's social media effectiveness. Social media should be a conscious effort for all your employees. How you and your employees engage with the public and what you divulge and offer to the public will be much more effective than anything one person can do. Social media allows consumers a certain level of intimacy with their interactions with your company and using the right amount of cleverness, unwavering customer support, and having a great product can turn potential customers into paying customers.

First Posts are Cliché

I am fascinated by technology and business. Most of my professional experience lies within the internet realm of technology so it only makes sense to have my own blog. The purpose of this website was originally to show off my personal projects, my resume and create a credible way for people to find out who I am when they search my name. I was crunched for time when I decided to make this website so I chose the wonderful start-up SquareSpace to host my website and use their incredible AJAX UI to create something fast. Well, I pay SquareSpace every month and it only makes sense to use what you pay for and since they offer an amazing blogging platform, I'm going to utilize it.

Keep an eye out for posts about business (i.e. start-up companies, consulting), web (i.e. design trends, website profiles, development platforms) and technology (i.e. electronic devices, infrastructure). I'll try to make this a fun read.

BTW: Forgive the design of the website, although I've designed and created about 30 websites in the past 3 years, I can never settle on new designs for my website. I have the uncanny ability to figure out what others want but not for me. I always come back to this plain and simple design - which I plan to change eventually.

P.S. I receive single digit unique visitors to this website on a daily basis and am fully aware that hardly anyone is reading this - have to start somewhere.