Standup – 22 October, 2009

Pivotal Labs

Thursday, October 22, 2009

Interesting

A lot of us have been seeing significant slowdown and memory problems with RubyMine lately. One of the Pivots brought this up again today, and remarked that RubyMine performed much better after he removed/detached a bunch of gems and only added back in the ones he was concerned about ever having to go into again.
Still in the vein of RubyMine, my Pair and I at one point set the memory allocation for RubyMine higher than the initial settings a weeks or so ago. I got to talking with a few of the Pivots about RubyMine and its memory settings and they said this is actually what you do NOT want to do. Apparently if RubyMine has too much memory available, then it doesn’t garbage collect anywhere near as often as it probably should.

Helps

In an Rspec test file, integrate_views is set up to be active by default. However, we want to run a particular describe block in the file in isolation mode. We tried using ‘integrate_views( false )’ right after the describe header, but that didn’t seem to do anything like what was expected. Just calling ‘integrate_views’ when the default is Isolation mode runs a describe block in Integration mode, but is there a way to do the opposite?

Standup – 21 October, 2009

Pivotal Labs

Wednesday, October 21, 2009

Helps/Interesting

It was brought up that Snow Leopard has finally, completely,
disabled the ability to
re-enable
the “Awesome” extra functionality of the Screen Sharing app. Once you
upgrade to Snow Leopard, you’ll have to pay for Remote
Desktop to get that awesomeness.

Stand Up – 19 October, 2009

Pivotal Labs

Monday, October 19, 2009

[Title]Standup 19 October, 2009

Pretty tame for my first day as the Standup Blogger for Pivotal Labs. I think the other Pivots were taking it easy on me today.

Helps

Someone (sorry, still trying to learn names and match them to faces) asked if anyone had an information regarding Ruby Enterprise Edition. Good idea? Bad idea? It was brought up that, for a while at least, REE was broken for 64-bit. Is that still the case?
The only other thing brought up was another Pivot asked if any of the Jasmine and Jelly experts would stick around after Stand Up to give him some advice.

Planning, WebOps

Pivotal Labs

Saturday, October 17, 2009

This thread on the Agile Systems Administration group is particularly good:

http://groups.google.com/group/agile-system-administration/browse_thread/thread/7c32b729aaa1079b

There’s some great stuff in here about planning in a highly interrupt-driven environment, and I particularly like Allspaw’s breakdown of ops work at Flickr (the “MumbleMumble” process). Anyone who’s wondering what’s generally involved in making webops go ought to have a look.

The Bold Italic Launches

Pivotal Labs

Saturday, October 17, 2009

We’re excited that The Bold Italic launched into public beta yesterday. The Bold Italic is a local-content website we developed with Ideo for Gannett. As they describe it, “(Their) mission is to help people become better locals, equipping our members with rare local intel, backstory and potential adventures.”

Given our focus on Test Driven Development, I was pleased to see the launch article was on Test Driving. (Test driving pickup trucks in this particular case, but it still made me smile.)

We’ve had a great experience working with the Gannett 11g team, and producing this powerful, flexible, and hyperlocal publishing platform with them and Ideo. We’ve been reading the great content they’ve been writing while it was in Alpha, and are excited that everyone gets to share it now that public beta is here.

We wish them well with their launch!

It's all about usability, people

Pivotal Labs

Saturday, October 17, 2009

I just started my day with a chain of usability fail from the good folks over at Wells Fargo. It probably wouldn’t have turned into a blog post if Carl Smith hadn’t just come and given his excellent talk, “It’s a Matter of Trust,” on the importance of the customer relationship, just yesterday in our talks series.

It all started when wanted to open a brokerage account at Wells. (One, for the record, that I thought had already been set up after the half-hour long consultation with a banker at Wells.) I followed the link from my checking account page to what purported to be my brokerage account, only to be taken to an application page, not horrible, but still misleading.

On the application page, they tried to upsell me certificates of deposit. I was interested enough to see what the rates were, so I checked the box.

Trapped users abandon

After filling in additional account information, I was taken to a screen asking me how much I wanted to put into a CD. After entering a smaller number, entering a funding source account, and an account into which to deposit interest, I found out that the minimum was actually $5,000. I entered $5,000 into the field (which fortunately I had available in one of my accounts, god knows what would have happened otherwise) and found out that the CD rate at Wells was lower than my savings account rate at ING Orange, not a strong inducement to tie up my money for 9 months. But of course there was no way for me to remove this product from my shopping cart on this page All I could do was ‘continue’ or ‘go back’. (More on the latter option in a moment.)

So I opted to continue, hoping (but no longer expecting) that there would be a way to remove this item from my cart before the end of the transaction.

I filled out the information to open and fund a brokerage account (which of course was the whole reason I was here) and a few clicks later was at the confirmation page.

And of course by this time you’ve guessed: There was no way to remove the CD product from my transaction. There was a link that looked like it may have let me change things, but all it really let me do was to save my application for later, at which future time I’m sure I would have experienced even more frustration at not being able to remove this under performing instrument from my application.

You can tell I was pretty motivated to do all of this, as most people would have abandoned much sooner. I really wanted to get that cash out of the under performing savings account it was in and into the market, so I really wanted this to work out.

It was at this point that I decided to see what the back button could do for me. I paged back, back, back, through all 7 layers of forms I’d already filled out, all the way back to step 2, where I’m verifying my address, all the while cursing that I can’t just click on the handy breadcrumb trail at the top of the wizard that tells you what stage you’re at. And then, as I get to step 2, the back buttons run out. This most basic promise of a back button, that you can keep going back, finally breaks its promise to help me undo this stupidity. And I’m mad.

20 lines or fewer

At this point, it’s time to contact a real human person. There’s a contact us link right there, which just takes me to their phone number, and email form. (Chat here would be nice, and contextual, and cheaper for them than having people on the phone.) No actual email address, of course, though in their defense they claim to want to keep conversations about banking matters secure.

So I write this email in their clunky email form, detailing what happened. And of course you can probably guess: After explaining in sufficient detail that they might learn from what’s happened and actually improve things, I try to submit the form.

Any guesses? Yes of course, my email to customer service is “too long”. (The actual error message is: You have exceeded the character limit in the Questions or Comments field. Please keep your responses to approximately 20 lines of text.) Someone really needs to explain to their dev team that it’s ok to use something larger than a VARCHAR(255) to store things like, oh, the voice of the people who are giving you their money?

Oh, and by the way, their solution to the session timeout problem is to tell you up front: Please complete your email in 20 minutes, or we’ll automatically log you out. Nice to feel like they really want to hear from me. (And of course you know this is a smell from the amount of hate mail they surely received before ‘fixing’ the problem by adding that text.) There are good, secure solutions to letting users extend their sessions. It’s called JavaScript. They should look into it. (And just before anyone reminds me that having JS keep the session open would not be secure, I want to be clear: They could alert you 2 minutes before the session was ready to time out, and give you that 2 minute window to send an AJAX request to keep the session alive for another 5 minutes. A little annoying, but ultimately secure.)

In the meantime I’ve gotten he helpful email that reminds me I’ve saved my application, and encourages me to come back later and complete it. And I’m somewhat surprised to see that it doesn’t come from an obvious noreply@wellsfargo.com-type address, but instead comes from mywellsfargo@wellsfargo.com.

Since I had the foresight to copy off my buffer to the clip board, I figured, what the heck, let’s give it a shot! And I replied with my civil explanation of the problem.

And of course the email to mywellsfargo@wellsfargo.com bounced. Is it somehow poetic that the mail server at Wells Fargo replies with “User unknown”?

I then shortened my email to Wells, asking them to please let me know where I could send them something longer than 255 characters to explain a problem, and we’ll see what they write back with.

Maybe in the era of Twitter, they will finally have to start listening to customers, or ignore them at their peril. Interesting how often the words “sorry” and “apologize” appear in their twitter feed already….

Why Wouldn't You Use Erector?

Alex Chaffee

Thursday, October 8, 2009

No, seriously. Why wouldn’t you use Erector? Cause I think it’s a pretty awesome view framework, but for some reason it hasn’t caught fire yet. So if you think writing actual Ruby to emit HTML, with a clean, nestable syntax with full support for Ruby features like inheritance, delegation, and yield is neat, but there’s something holding you back, then please let us know what it is. At best we can fix it, and at worst, at least we’ll know why.

Here are some reasons I think you might not use Erector:

You love angle brackets. If this is the case then I can’t help you. I don’t think anybody can.

You like typing every tag name twice. Since Erector elements are Ruby statements, every open tag gets automatically closed.

You like invalid HTML. Since Erector elements are Ruby statements, every open tag gets automatically closed. (See how that works?)

You always remember to call ‘h’. Rails 3.0 is going to HTML-escape all output by default. Erector’s been doing this the whole time. Cause, you know, why wouldn’t you?

You like having to rewrite your code when you extract a partial, and then again when you extract a helper method. In ERB, templates, partials, and helpers all have slightly (and annoyingly) different syntax for things like referring to variables and calling other code. Erector is all Ruby, so you can use your favorite refactoring browser, or just cut and paste, to move your code around. Check out this excerpt from Jeff Dean’s RailsConf talk to see this in action, or read the slides from the whole talk on SlideShare.

You hate encapsulation. You think that your views should have direct access to all the instance variables of your controller. Unless they’re partials, in which case you shouldn’t, even though you can, although the names might be different. Confused yet? So am I.

You like putting code for one component in three separate files. Erector’s new “externals” feature allows you to put all the code — HTML, CSS, and JavaScript — inside a single Ruby class. The CSS and JavaScript then get output inside the HEAD, once per HTML page, while the HTML gets rendered in the BODY as usual, as many times as necessary. This follows the OO paradigm of cohesion, otherwise known as “put similar stuff together,” which is the complement of loose coupling, which means, “keep different stuff apart.”

Okay, so those were sarcastic reasons. Here are some more possible reasons why you wouldn’t use Erector. I suspect that these next ones hit closer to the mark. But I believe that they’re all specious, if not downright false.

Your site contains a whole lot of complex HTML and a few inserted Ruby variables. OK, this makes sense. Erector’s not great for static sites. But I’ve never personally worked on a web application where the code inside the views didn’t quickly get complex enough to require codey things like loops and functions. And if you’re writing code, then why not do it in a programming language?

Your designers don’t know Ruby. I’ve heard this complaint a lot, but I have yet to meet this mythical designer who’s smart enough to understand modern HTML, CSS, JavaScript, ERB, and partials, but is not smart enough to learn that “div ‘foo’, :class=>’bar’” outputs “<div class=’bar’>foo</div>”. On the contrary, I’ve worked with several designers who, after a few tutorial pairing sessions, were comfortable checking code in and out and editing Erector view code at will. Like any junior coder, they need to stay away from the tough stuff, but they’re pretty good at knowing what they don’t know and asking for help when they need it. (Which they would also do if working inside ERB.)

View code needs to look as similar to HTML as possible. Well, I hear this, but have you looked at HAML? That language is hella popular, and it doesn’t look anything like HTML. Its structure is similar, in the abstract, but so’s Erector’s, and at least in Erector the method for emitting a div is called, you know, “div”. And it’s a method. And I don’t want to turn this into a war between HAML and Erector — I think HAML is gorgeous — but HAML suffers from the same design flaw as every templating technology: views are not objects, and markup isn’t code. After a certain point of complexity, HAML’s elegance breaks down and you’d be better off doing loops and functions in code.

You’ve already got a bunch of stuff in ERB and it’d take too long to convert it. Yes, legacy code is a pain, but we have a command-line tool that converts ERB (or HTML) to Erector to make it a bit smoother. And you don’t have to convert your whole app to Erector at once. Erector views can interoperate with ERB or HAML in Rails and Sinatra.

You’re stuck on an old version of Erector. Yes, legacy code is a pain, but we have an upgrade guide for getting to 0.6.0, and people on the mailing list ready to help.

Erector’s too slow. Lies! Erector is faster than a greased rattlesnake going downhill. Check out these benchmarking results. Erector is about 2x as fast as ERB and 4x as fast as HAML about the same speed as ERB and HAML(*) under typical conditions. We make sure to use the same output stream to minimize string copy or realloc, and using Ruby objects means much lower parsing overhead.

(*) Update: the “2x/4x” figure was based on a benchmark program that didn’t use template caching, which speeds things up for both ERB and Haml. With template caching, Erector and Haml are about the same speed; Haml is about 20% faster when rendering a page with no partials. See this ongoing thread on the Erector list.

There’s no documentation. More lies! We have a whole bunch of documentation at http://erector.rubyforge.org, including a FAQ and a user guide.

You got burned by Markaby. Underneath the elegant facade of Markaby lay a confusing and often counter-intuitive engine. Its use of instance_eval and other tricks made simple things break in weird ways and made debugging a real chore. Erector was born out of those frustrations, and one of its main design goals is “no magic.” Also, there was a long time where Markaby wasn’t being maintained (although that’s changed recently); we have a core group of developers committed to responding on the mailing list and github, and we run integration tests against the latest stable Rails release (and soon, against Edge) to catch incompatibilities early on.

Rails has all these great helpers and I want to keep using them. Okay, go right ahead! Erector’s Rails integration allows you to call any helper, either directly through a proxy method, or indirectly through the helpers object. If you find a helper that doesn’t work, let us know and we’ll add it to the list of supported helpers. (We haven’t done all of them yet because it’s a pain in the neck to look at each function and figure out what its input and output semantics are. Does it return a string or emit directly onto the output stream? Does it take a block? An options hash? An html_options hash? Etc.) We’re also slowly putting some Rails functionality into Erector, either in the base class or in custom widgets. If there’s something you need, ask on the mailing list, or better yet, send us a patch.

Its name is a dirty word. I’ve heard this more from people who didn’t grow up in the United States, where the Erector Set was a popular toy among the 6-to-12-year-old DIY set in the 70s and 80s. (Apparently it was called Meccano in the UK.)
Erector is a normal word, used all the time in the news and in business names. And as the name of a view library it’s evocative in a way that’s relevant and interesting, in that it’s a builder, and you build a view up out of parts.

But we have heard this complaint, and in sympathy, changed the name of the command-line tool (oh, sorry, guess I can’t say “tool” either)– uh, executable– from “erect” to “erector” even though the former is a venerable English verb that’s grammatically appropriate (”I asked him to erect the scaffolding.”). If you introduce the library and your coworkers get all giggly then I think if you just say the name with a straight face and then roll your eyes and mock your bawdy buddies when they snicker then all will be well. After a few repetitions it won’t sound odd at all.

You’ve never heard of it. Help spread the word! Post a review on your blog! Ask your favorite app framework whether they support it! Post code samples in Erector and when people say “What’s that?” then point them at http://erector.rubyforge.org! Give a talk at a meetup! Write your congressman and ask if she supports the Erector Mandate Bill of 2009! Buy ad space on the moon!

So, in conclusion, and despite my somewhat snarky tone throughout, I am honestly and desperately curious to know why the world has not yet beat a path to Erector’s door. Anybody got any more ideas?

Standup 10/7/2009

Mike Grafton

Wednesday, October 7, 2009

Interesting

String#to_xs behavior can change if you happen to have the fast_xs gem installed.

Rails tries to require the ‘fast_xs’ c-extension to implement String#to_xs (it falls back to a pure Ruby XML escaping algorithm if it can’t find it). Unfortunately, fast_xs is not API compatible with the built-in version provided by Rails (it escapes double quotes, for no apparent reason).

This is all well and good if that’s what you decide go with. But unfortunately, fast_xs is a c-extension, which means that if it’s been installed on your system for whatever reason (say, installing Hpricot), then Rails will start using it, and there’s no good way to turn it off (unless you consider hacking your ActiveSupport gem “good”). So the behavior of your app could change without any explicit intention on your part.

fast_xs also exists as a gem that wraps the c-extension, and if you use to_xs (i.e. your app emits XML), it might behoove you to depend on the gem explicitly. It was noted that for apps that emit a lot of XML to be performant, you will need fast_xs, anyway.

Standup 10/6/2009

Mike Grafton

Tuesday, October 6, 2009

Help

Why is upgrading to Ruby 1.8.7 so painful?

More specifically, a Pivot was wondering why there seem to be so many ways to install Ruby and Rubygems on a Mac. There are a lot of different places where gems end up being installed depending on which version of Ruby you have installed, and the specifics of how you installed it. The conversation turned into one about RVM and Yehuda Katz’ Bundler, two technologies that appear destined to make it much easier to easily combine a version of Ruby with a set of gems under a particular project.

What is that technology that allows for more complex condition hashes in ActiveRecord?

This must be ActiveRecord::Extensions, which allows for an expanded syntax in the conditions hash of AR finders. A debate was had as to whether hashes and arrays could possibly comprise a reasonable DSL for complex query logic, but surprisingly, the final word on the subject was not reached during standup.

We are using curl to talk to a Mongrel/Rack server that is running some specs. That server is emitting dots (just as any Rspec process would), but we cannot get those dots to show up in real-time on the client. The only way we’ve been able to force a flush is with a newline character, but that gives us an ugly vertical column of dots. Any suggested hacks for this?

The Bay Area Chef Meetup Group is meeting on 10/14 in Mountain View. If you’re into Chef (and here at Pivotal we use it extensively), you might want to check it out.

Need a Job? Come Work with Pivotal Clients!

Lara Owen

Tuesday, October 6, 2009

At Pivotal Labs, one of the services we provide is bootstrapping startups, including helping them interview and hire. We currently have clients looking for skilled engineers to build their development teams. This is an excellent opportunity to learn Extreme Programming by working side-by-side with Pivotal’s talented and experienced developers while at the same time getting in on the ground floor of a small and dynamic product team.

Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring. General technical requirements include serious web development experience, and a significant subset of Ruby, Rails, CSS, JavaScript, or MySQL.

Here are short descriptions of The Bold Italic and Honk, San Francisco-based clients of Pivotal Labs currently looking for developers. The full job postings follow.

The Bold Italic is an online collection of stories uncovered by the city’s most passionate citizens. We’ve spent the last 6 months in San Francisco discovering what people want to know about their city. We found that people are looking for an insider’s backstory – the story behind the story. We see a great opportunity to connect citizens to merchants in a way that celebrates and supports the city’s culture. A 100% Ruby on Rails web project developed exclusively by Pivotal Labs over the last 3 months, The Bold Italic also stems from a collaborative effort between Gannett’s Design and Innovation group and IDEO. We are looking for a smart, creative, analytical, visionary web developer to join our San Francisco based team on contract for the next 3 months.

Honk.com is a new online automotive website that will make car shopping fun and social. We will enable consumers to experience a new way to explore new cars. We have partnered with a top social website to deliver this new way of car shopping and are funded by one of the largest media companies in the world. Our small team is made up of an experienced group of humble, efficient, and hyper-passionate individuals who are veterans of the automotive industry and social media space. We are proud of our ego-less culture, one that promotes team thinking, not individual accolades. If you’re interested in helping prove that social media and car buying go hand in hand, social networks serve a bigger purpose than keeping up with one’s day, and a small team can outdo the work of an army – then we may have a seat waiting for you.

If you are interested or for more information please contact the company directly. This is an exclusive service provided to our clients, no external companies or recruiters please.

Full job postings follow.

The Bold Italic

The Bold Italic is a start-up offering funded by Gannett, Co. Inc the owner of USA Today, over 80 local newspapers, and 23 local television stations. The site takes a new, fresh approach to providing San Francisco with local news and information through rich visual design and new storytelling methods. A 100% Ruby on Rails web project developed exclusively by Pivotal Labs over the last 3 months, The Bold Italic also stems from a collaborative effort between Gannett’s Design and Innovation group and IDEO.

We are looking for a web developer to work full-time, on contract for the next 3 months, in San Francisco. The right person for the job will have the following attributes:

Talent: We are looking for a smart, creative, analytical, visionary web developer to join our San Francisco based team.

Experience: A college degree required and a demonstrable experience as a web developer. You should have deep experience working on Ruby on Rails, JQuery, CSS and Agile Methodologies, and be able to deliver high-quality results. Experience with Test Driven Development (TDD) is a must.

Personality: We adhere to human centered design thinking in all that we do. You should enjoy creating offerings that delight consumers and aim to meet their needs first. We’re a small group accustomed to playing whatever roles necessary to make things work. Hopefully, you thrive in a start-up environment that requires teamwork, flexibility, enthusiasm, and a proactive attitude.

Responsibilities: You will be the first in-house developer for The Bold Italic! As the first technical hire, you will be responsible for working independently to build new site features, provide technical expertise, as well as maintain the site on a daily basis. We like what we’ve learned from Pivotal and intend to use Pivotal Tracker to plan out site development.

Timing: You should be able to start immediately.

What is The Bold Italic? The Bold Italic is an online collection of stories uncovered by the city’s most passionate citizens. We’ve spent the last 6 months in San Francisco discovering what people want to know about their city. We found that people are looking for an insider’s backstory – the story behind the story. We also found that commerce is the glue that binds together culture and community. We see a great opportunity to connect citizens to merchants in a way that celebrates and supports the city’s culture. Ultimately, we believe that through The Bold Italic, San Franciscans will become better locals through the sharing and uncovering of distinctive, offbeat local experiences.

The Bold is releasing its Beta version in mid-October!

If you’re interested, submit your resume to work@thebolditalic.com

Honk

Honk.com is a new online automotive website that will make car shopping fun and social. Consumers experience a new way to explore new cars, focusing on what other real people actually think, not product specifications or biased editorial. Our site is 100% consumer driven with no journalists or former race car drivers telling you what minivan or sedan you should purchase. Instead, users find real people sharing their opinions and experiences. We have partnered with a top social website to deliver this new way of car shopping and are funded by one of the largest media companies in the world. Thankfully, our partners allow (and encourage) us to remain financially independent, unpolitical, and fast-moving… a true start up.

Our small team is made up of an experienced group of humble, efficient, and hyper-passionate individuals who are veterans of the automotive industry and social media space. We are proud of our ego-less culture, one that promotes team thinking, not individual accolades. If you’re interested in helping prove that social media and car buying go hand in hand, social networks serve a bigger purpose than keeping up with one’s day, and a small team can outdo the work of an army – then we may have a seat waiting for you.

Honk is developing a platform of distributed applications and a destination website that will engage consumers’ existing social networks. To be clear, we are not building yet another community or social network. Many of our social applications will reside on our partners’ sites with the intent to drive users to honk.com for a richer experience, including unique content, interaction, and transaction-oriented tools. We will continue to expand our product over the next twelve months. In addition to deep knowledge of Ruby on Rails and Agile / Test-Driven Development precepts, we hope you have a thorough understanding / are comfortable with:

Amazon S3/SQS/EC2
CSS/Javascript/JQuery
Thin/NGinx/Mongrel
RSpec/Webrat/Selenium
CSV and XML data feed integration

Previous experience working in online automotive or social media is desired, but definitely not required. Honk is currently located in San Francisco with some ties to Los Angeles. Our ideal candidates should reside in one of these two major metro areas, although we are open to “off site” developers who have the right skills and background.

Please send inquiries to Bruce Krysiak, CTO: techjobs@honk.simplicant.com