bgror

Bridging the Gap Between Development and Design »

Created at: 19.01.2012 23:49, source: Engine Yard Blog, tagged: Technology Tips & Tricks

At a recent conference, I had the privilege of attending a talk entitled “Developers Can’t Design (and other completely untrue design myths)” by the incomparable Jen Myers. Jen is one of those rare individuals who effortlessly flows between design and development, having a formal education in computer science, but also a passion for design. I am not one of those people.

At least, not yet. For, you see, I have traditionally considered myself in the “graphically challenged developer” camp. There was no hope of bridging that gap. I know my limitations and embrace them. But Jen said something that caught my attention.

“Design is teachable.”

What’s that, you say? But what if I don’t have the eye for it? What if I don't have the natural talent? Doesn’t matter, she says.

“There are rules to be followed. It’s about solving problems, not just personal preference, or what you think looks good.”

Hmm, I like rules. I can follow rules. There are a lot of rules to development as well. Maybe she’s on to something.

“It’s not magic.”

Jen then went on to describe basic design principles (such as balance, proximity, emphasis, unity, repetition) and a few design concepts (such as positive/negative space, color theory, contrast, typography, ratios). As well, she says that there should not be “design” or “development” silos, but the two should be fully collaborative, and work as one team from start to finish. Jen says she's hard on designers who have no interest in learning any code, as well.  Being able to speak the language of the other person can make all the difference.

One of the biggest takeaways I got from Jen was the encouragement for developers to just break out of our comfort zone.

“Find a UX group. Go to a UX conference. We won’t bite, I promise. In fact, we’ll be thrilled to see you there.”

Good advice, indeed. Really, that’s what it comes down to. Us breaking out of our comfort zone and being open to learning something new. The “I can’t design” fallacy is really just that. Instead, we should s/can't/haven't taken the time to.

Coincidentally, the awesome @rands also recently posted a fabulous article on his blog, A Design Primer for Engineers. He goes through the different types of design, and gives us all food for thought.

“Engineers are uncomfortable with ignorance, but worse, we’re bad at asking for help outside of our domain of expertise.”

I don’t know that this applies to everyone, but in general, yes. Perhaps that’s the case. He also provides some books to check up on, one of which being “The Design of Everyday Things.” Jen also mentioned this book in her talk, and I can personally vouch for its awesomeness. Believe it or not, it’s fascinating.

Probably the best words of advice in his post mirrors what Jen had to say.

“Party. More. Together.”

Bringing our communities together seems to be the best answer to bridging the gap between development and design. So what are we waiting for? It’s not magic.

• Find a design or UX Meetup near you
• Go to a design or UX conference
• Read The Design of Everyday Things , the Non-Designers Design Book (or any design book by Robin Williams)

Have you already bridged the gap? Do you know of other resources that will help others do the same? We'd love to hear them!

Introducing the New Feature Request Forum »

Created at: 17.01.2012 20:30, source: Engine Yard Blog, tagged: Technology Tips & Tricks training

Please check out our new Feature Request Forum and share your thoughts on what enhancements you would like to see in our products and services.  We are looking forward to hearing what you think!

Best Practices: Your Engine Yard Cloud Account »

Created at: 11.01.2012 03:20, source: Engine Yard Blog, tagged: Customers Technology

• Keep your Engine Yard Cloud account contact info updated.  Log in, and make sure it’s still accurate.
• Is the account owner removed from day-to-day ops? If so, consider making the owner the Technical POC instead, or change the email address to a mailing list or alias (i.e. google group, shared account, etc.) which you can add multiple people to so everyone gets information in a timely fashion.
• Ticketing System. Our ticketing system is a critical part of our support offerings. Have you logged in and set up an account? Do appropriate team members have access, either through a shared account or collaborator accounts?
• Adding collaborators to your accounts. You can add users to your account using our Collaboration feature (http://docs.engineyard.com/account-collaboration.html). To add other people to your account, click on the Account tab on the top right of your Dashboard. Then from there click Account Settings. At the bottom of the Account Settings page, you can add members to your Account.
• Once you have invited the additional users, they must accept their invitations to join your Account. They then have access to your dashboard and the ticketing system.
• Remember that only the cloud owner email address receives email alerts when we are sending them en masse.  Plan accordingly.  While we can be flexible and set notes in our ticketing system to alert various email addresses when opening tickets on a one-by-one basis, at this point in time, when we are grabbing email addresses to send out mass communications, it is the Account Owner’s email address that is notified.

Additionally: We strongly recommend that you take a look at your environment and consider upgrading to the latest version of the Engine Yard stack so you can take full advantage of the latest versions, bug fixes, and security patches. Full instructions for this process are at http://docs.engineyard.com/environment-upgrade.html.
Go to your application’s dashboard and take a moment and click the “Upgrade” button. It does not take immediate effect — instead it will list the various features that are about to change so you can consider them and decide if you’re ready to move up.
You can also review our release notes at http://docs.engineyard.com/release_notes.html.

My Summer of (Open) Source »

Created at: 05.01.2012 22:25, source: Engine Yard Blog, tagged: Open Source ruby Technology

The last few months have been an great experience for me. I’m a graduate student from Potsdam, Germany. However, as some of you might already know, I’m also rather active in the Ruby community. This past year, I had an amazing opportunity.

Engine Yard sponsors a couple of Open Source developers to work full time on their projects. When I asked Dr. Nic Williams whether they would sponsor me spending three months in Portland, working together with Brian Ford on Rubinius, I expected nothing but a no. Turns out, Engine Yard was at least as thrilled about this idea as I was. A few days ago, I finally got back to Germany, and I wanted to give you a quick overview of what I’ve been working on during my time overseas.Like many others, I started contributing to Rubinius a while ago. However, I never really dared to play with the internals. So, my first stop was the Rubinius compiler. To make sure I really understood it and that it’s as flexible as it claims to be, I wrote a Smalltalk implementation using the Rubinius compiler infrastructure and looked into improving its API.

It’s a fun thing to do, as the Rubinius compiler is written entirely in Ruby. And, since Rubinius is bootstrapped, it also runs on other Ruby implementations. That is how you usually install Rubinius: You load the compiler from CRuby, it then compiles the compiler to Rubinius bytecode. If you want to look into this, there is some excellent documentation available on the Rubinius website.

This bytecode can then be executed by the Virtual Machine, which was my next stop. It took me a while to fully understand how things work within the VM. It is actually the only major part of Rubinius not written in Ruby, and the main reason for it’s blazing performance and excellent memory footprint. I am planning ton writing another blog post, or possibly even a series of blog posts about these internals.

Apart from bug fixes and API improvements, I used the gained knowledge to fix, for instance, one of Ruby’s least known and most confusing feature: the implemented flip-flops.

The last thing I worked on was Puma, a new web server for Rails/Rack/Sinatra applications. Rubinius 2.0 is about to be released, fully able to make the best use of all your CPUs. However, most web servers used for deploying Ruby applications are actually single-threaded. Since there is no real threaded option that is still maintained and not JRuby specific, Evan Phoenix and I started working on a new server.

Like many other servers, it uses the rapid HTTP parser that comes with Mongrel. It also uses a dynamically sized thread-pool for processing requests in parallel. With Puma, you now have a go to choice when it comes to deploying web applications on Rubinius. And since it does not contain any Rubinius specific code, it also works quite well on JRuby or CRuby.

To make sure we are heading in the right direction, I started working on a tool for benchmarking web applications under realistic load. The main issue with just using ab, the standard solution for measuring HTTP performance, is that it results in unrealistic numbers both on JRuby and Rubinius. When using ab, you just send the same request over and over again, causing the JIT and code inliner to highly optimize for exactly that request. This usually doesn’t reflect the actual production behavior, though. I therefore wrote code simulating a real browser session and, of course, running multiple of these sessions in parallel.

You think that’s all? Far from it! The Engine Yard OSS Community Grant Program enabled me to speak at six different conferences all over America. At Rocky Mountain Ruby, RubyConf Brazil and RubyConf Uruguay, I gave a talk on “Real Time Rack”. In San Francisco, at GoGaRuCo, I gave a presentation about “Smalltalk On Rubinius - or How To Implement Your Own Programming Language”. At this past year’s RubyConf in New Orleans, I spoke about “Message in a Bottle” and last but not least I gave a presentation titled “Beyond Ruby” at RubyConf Argentina in Buenos Aires.

Tao of Documentation »

Created at: 04.01.2012 02:39, source: Engine Yard Blog, tagged: Technology Tips & Tricks

ritcheyer

In November I was given the honor of speaking at RubyConf Uruguay 2011. If you have a chance in 2012 to go to a conference I would highly recommend heading to South America. All the countries work together to setup a conference tour so you can start in Chile or Colombia and work your way down to Argentina and Uruguay. The Uruguayan conference organizers are amazing. Big props to Evan, Nicolás, Pablo and the rest of the crew.

Pain

I gave a talk on how I believe it is extremely important for companies to have very detailed documentation about how to use their product and how they can make it easier for their developers to help with that process without making them feel like they are wasting their time. It frustrates me a lot when I use a product that I really like, but I cannot for the life of me figure out how to use it because documentation is non-existent. The worst is when I find out about a feature from reading another users blog post about how he/she was digging around and found this awesome hidden feature. Seriously!! I should not have to dig around to find out how to use your product.

Open source projects sadly are not excluded from this offense. I am not referring to documenting the codebase by using YARD, RDoc or TomDoc, but rather having good examples, HowTo and FAQ sections. Look at projects such as fog,  Riak and Renee. Early Ruby on Rails users will remember how difficult it was to figure out all the aspects of Rails, however new users greatly benefit from the amazing Ruby on Rails guides that are constantly updated.

Journey

"Do the difficult things while they are easy and do the great things while they are small." This quote is from my favorite philosopher Lao Tzu. Taoism is awesome and if you do not know anything about it I recommend reading The Tao of Pooh, but I digress. Engine Yard definitely did not follow Lao Tzu in this regard and we felt the pain when we decided to fix the situation. Please DO NOT start this process late. I know it seems painful, but just like with TDD writing good Documentation for your users will keep you sane and happy in the long run. Our documentation in the early days were not updated frequently at all and it was frustrating. We had setup DokuWiki and found out later on that it was not the most intuitive wiki to use, but it was better than having nothing at all. "A journey of a thousand miles must begin with a single step." Well it took us a while, but we finally took that step and found the right tools and workflow that completely overhauled our documentation and I can proudly say that it kicks ass now.

Solution

There are a lot of tools out there that will allow you to write great documentation easily and quickly so honestly there is no excuse to have poor or zero documentation. Gollum, stasis, and nanoc are some of the many tools that you can look into using. Looking over all the tools we decided on using gollum with gollum-site that would convert the Markdown formated gollum pages into static HTML pages. We created a public ey-docs repo on GitHub so that it is easy for anyone to help contribute to our documentation. Using Markdown means that everyone who is comfortable with the syntax can clone the repo and start making changes in their respective text editor and push those changes up. Using the tools we picked allows us to easily change the style of the documentation site as well as structure the categories and pages appropriately. We even have a nice release notes RSS feed section so that our customers can be up to date on all the new updates we release to our technology stack.

Results

21 people have now contributed and we have had a 140% increase in the number of vistors to our documentation. Our guides on how to get setup to start developing with Ruby on Rails was so good the organizer of Tijuana.rb converted it to Spanish.

All Winnie-the-Pooh wants is to live a peaceful life full of joy. Shouldn't you want the same for yourself and your users? Go create some amazing documentation.

For those of you that have your own way of writing documentation let me know about the tools and workflow you use in the comments below.

If you care to listen to the talk and see the slides here is the link: Tao of Documentation. The link to the audio is in the description section.