thredUP Labs

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.

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

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 illustrates a lengthy alternative to accomplish what the collect method does.

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 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.

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

by Dan DeMeyere - @dandemeyere

Emotional Graphical Design

White/negative space has been a very useful tool for designers to avoid clutter and gaudy colors/graphics. It was also easier for developers to create considering in the past Front-End engineers would work with designers to create the user-facing portion of a website. This is where I think there is a dynamic shift occurring that is leading to an emotional push in design. I'm seeing a lot more graphic designers who are capable of using CSS/HTML/jQuery to create a website that is pixel perfect to the design they created. Why I think this is important is because what appears in Photoshop and what shows up inside a browser are different in appearance and how you experience them. The scrolling, re-sizing of the browser window and other subtle things like hover and active states for buttons can be lost in translation between mock-up and implementation. Some developers don't have an eye for this level of detail so if it wasn't in the mock-up, improvisation probably occurs and rest assured the developer will be choosing the path of least resistance for completion, which typically means the design suffers. All the examples I have listed below contain a certain personal feel to them (cozy colors, custom font, etc.) and a lot of the design is made possible through text-shadows, jQuery DOM manipulation, and other enhancements such as custom font APIs. Have a look for yourself:

• Example 1 - Personal portfolio of designer/developer
  

  
• Example 2 - Custom search field and layered design
  

  
• Example 3 - Embossed effect (most likely created with CSS text/box shadow)
  

  

Designing Software-like User Interfaces

UI design is progressing to a uniform experience across all platforms. It's not uncommon to see a website's UI in a browser that would be identical on an iPhone as its own app or an Adobe AIR desktop app.

• Example 1 - try to tell me if this snapshot was taken from a website, a mobile app, or software app?
  

  

Consistent user experience is essential for brand recognition and ubiquitous usability. Allowing users to be proficient in navigating and using the functionality of your website on any device is very important so I wouldn't be surprised if start-ups begin designing their website, iPhone/iPad, and other device apps right from beginning.

Homepage Design

Recent developments in A/B testing have resulted in a higher statistical knowledge of important metrics about your website (heat maps, click-throughs, conversion rates) and in result companies are serving up multiple versions of the homepage and letting the numbers decide the best layout, color combination, and copy. The trend I'm seeing is a consistent formula - main content area below the header that stretches the entire width of the layout, then equal size blocks (less tall) below that contain important sub-components of a website to learn more about the product. Call to action on top with 1 sentence pitch, then supporting items below. The navigation bars are being hidden or reduced to appeal as a more simple site to avoid overwhelming the user. Essentially, homepages are becoming marketing landing pages. Even our new homepage uses this layout to some extent.

• Example 1 - A visual representation of what I'm talking about.
  

  

Finally, another interesting link I wanted to share. This trend is in its infancy, but I believe the next iteration we'll see is designers/developers creating new ways of displays form data. Horizontal signup forms, smarter validation with jQuery, and other usability enhancements.

Snapshots courtesy of forrst.com

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

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:

1. You never get bored. How can something get old if you don't spend more than 2 weeks on it?
2. 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'.
3. 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.
4. 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.
5. 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.

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

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.

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

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:

This is the block of code it replaces:

Copy/paste-able snippet of the ternary operator example.

2. Use the tools Rails blessed you with

Rails provides a lot of cool, built-in functionality for 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 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:

Which is equivalent to:

Copy/paste-able snippet of the 'find_by' method example.

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:

Instead of having to do something like this:

Copy/paste-able snippet of the 'find_by' method 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:

And here's the wrong way:

Copy/paste-able snippet of using variables in database queries.

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

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

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:

• TextMate Syntax Highlight Themes
• TextMate Bundles
• TextMate for Rails Peepcode Videocast
• TextMate Rails Short-cut Cheat Sheet

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com

by Dan DeMeyere - @dandemeyere

thredUP 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 as to whether or not I would enjoy working with Rails. Reading the Rail's Wikipedia page was rather intimidating, tossing around unfamiliar terms like agile development and scaffolding. I knew there was only one 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 continue, which is what's important in the beginning; take manageable, bite-sized tasks and just focus on what's ahead. 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 myself, and most of your experience lies within basic server-side scripting languages (PHP/ASP/etc), 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. There are 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 became familiar with 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 ones 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' type. 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 you'd rather 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. 

As I'll be purchasing a new computer in the next month, there will be a series of posts pertaining to getting the environment up and running, what apps to use (TextMate, Coda, GitX, etc.), useful snippets of code, epic failures I'm bound to cross (and how to protect yourself from doing the same), and other fun things like bundles, syntax highlighting themes, command line tips/shortcuts, and useful gems/technologies/implementations that I come across along my journey.

Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com