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!

Bundler and public applications »

Created at: 19.01.2012 23:24, source: Phusion Corporate Blog, tagged: ruby Ruby on Rails

I think Bundler is a great tool. Its strength lies not in its ability to install all the gems that you’ve specified, but in automatically figuring out a correct dependency graph so that nothing conflicts with each other, and in the fact that it gives you rock-solid guarantees that whatever gems you’re using in development is exactly what you get in production. No more weird gem version conflict errors.

This is awesome for most Ruby web apps that are meant to be used internally, e.g. things like Twitter, Basecamp, Union Station. Unfortunately, this strength also turns in a kind of weakness when it comes to public apps like Redmine and Juvia. These apps typically allow the user to choose their database driver through config/database.yml. However the driver must also be specified inside Gemfile, otherwise the app cannot load it. The result is that the user has to edit both database.yml and Gemfile, which introduces the following problems:

• The user may not necessarily be a Ruby programmer. The Gemfile will confuse him.
• The user is not able to use the Gemfile.lock that the developer has provided. This makes installing in deployment mode with the developer-provided Gemfile.lock impossible.

This can be worked around in a very messy form with groups. For example:

group :driver_sqlite do
  gem 'sqlite3'
end

group :driver_mysql do
  gem 'msyql'
end

group :driver_postgresql do
  gem 'pg'
end

And then, if the user chose to use MySQL:

bundle install --without='driver_postgresql driver_sqlite'

This is messy because you have to exclude all the things you don’t want. If the app supports 10 database drivers then the user has to put 9 drivers on the exclusion list.

How can we make this better? I propose supporting conditionals in the Gemfile language. For example:

condition :driver => 'sqlite' do
  gem 'sqlite3'
end

condition :driver => 'mysql' do
  gem 'mysql'
end

condition :driver => 'postgresql' do
  gem 'pg'
end

condition :driver => ['mysql', 'sqlite'] do
  gem 'foobar'
end

The following command would install the mysql and the foobar gems:

bundle install --condition driver=mysql

Bundler should enforce that the driver condition is set: if it’s not set then it should raise an error. To allow for the driver condition to not be set, the developer must explicitly define that the condition may be nil:

condition :driver => nil do
  gem 'null-database-driver'
end

Here, bundle install will install null-database-driver.

With this proposal, user installation instructions can be reduced to these steps:

1. Edit database.yml and specify a driver.
2. Run bundle install --condition driver=(driver name)

I’ve opened a ticket for this proposal. What do you think?

Building a Modern Web Stack for the Real-time Web »

Created at: 18.01.2012 10:00, source: igvita.com

The web is evolving. After a few years of iteration the WebSockets spec is finally here (RFC 6455), and as of late 2011 both Chrome and Firefox are SPDY capable. These additions are much more than just "enhancing AJAX", as we now have true real-time communication in the browser: stream multiplexing, flow control, framing, and significant latency and performance improvements. Now, we just need to drag our "back office" - our web frontends, app servers, and everything in between into this century to enable us to take advantage of these new capabilities.

We're optimized for "Yesterday's Web"

Modern backend architecture should allow you to terminate the user connection as close to the user as possible to minimize latency - this is your load balancer or web server occupying ports 80 and 443 (SSL). From there, the request is routed on the internal network from the frontend to the backend service, which will generate the response. Unfortunately, the current state of our "back office" routing is not only outdated, but often is also the limiting factor in our adoption of these real-time protocols.

WebSockets and SPDY are both multiplexed protocols which are optimized to carry multiple, interleaved streams of data over the same TCP pipe. Unfortunately, popular choices such as Apache and Nginx have no understanding of this and at best degrade to dumb "TCP proxies". Even worse, since they do not understand multiplexing, stream flow-control and priority handling goes out the door as well. Finally, both WebSockets and SPDY communicate in framed messages, not in TCP streams, which need to be re-parsed at each stage.

Put all of this together and you quickly realize why your own back office web stack, and even the popular platforms such as Heroku and Google's App Engine are unable to provide WebSockets or SPDY support: our services are fronted by servers and software which was designed for yesterday's web.

Architecture for the "Real-time Web"

HTTP is not going away anytime soon, and we will have to support both the old and the new protocols for some time to come. One attempt at this has been the SPDY > HTTP proxy, which converts a multiplexed stream into a series of old-fashioned HTTP requests. This works, and it allows us to reuse our old infrastructure, but this is exactly backwards from what we need to be doing!

Instead of converting an optimized, multiplexed stream into a series of internal HTTP dispatches, we should be asking for HTTP > SPDY infrastructure, which would allow us to move beyond our outmoded architectures. In 2012, we should demand our internal infrastructure to offer the following:

• Request and Response streaming should be the default
• Connections to backend servers should be persistent
• Communication with backend servers should be message-oriented
• Communication between clients and backends should be bi-directional

Make SPDY the default, embrace dynamic topologies

The first step towards these goals is to recognize that translating SPDY to HTTP is a convenient path in the short term, but exactly the wrong path in the long term. SPDY offers multiplexing, flow control, optimized compression, and framing. We should embrace it and make it the default on the backend. Once we have a multiplexed, message-oriented protocol on the backend, we can also finally stop reparsing the same TCP stream on every server. Writing HTTP parsers in 2012 is neither fun nor an interesting problem.

Finally, this architecture should not require a dedicated OPS team, or a custom software platform to maintain. Modern web applications are rarely powered by a single host and require dynamic (re)configuration and management. Services such as Heroku, CloudFoundry, and GAE have built their own "routing fabrics" to handle these problems. Instead, we need to design architectures where the frontends and the backends are decoupled by default and require minimal intervention and maintenance.

Adopt a modern Transport Layer

Building dynamic network typologies is not for the faint of heart, especially once we add the additional requirements for message-oriented communication, multiplexed streams and a grab bag of performance constraints. Thankfully, libraries such as ØMQ offer all of the above and more, all wrapped behind a simple and an intuitive API. Let the frontend parse and emit SPDY frames, and then route them internally as ØMQ messages to any number of subscribers.

Mongrel2 was one of the first web servers to explore this type of architecture with ØMQ, which allowed it to sidestep the entire problem of backend configuration, as well as enable a number of interesting worker topology patterns. There is still room for improvement, but it is a much needed step in the right direction. As a concrete example, let's consider a sample workflow with SPDY and ØMQ:

1. An HTTP (or SPDY) request arrives to the frontend
2. Frontend parses the request and generates SYN_STREAM, HEADERS and DATA SPDY frames
3. The messages are delivered into a PUSH ØMQ socket (ala Mongrel2)
4. Backend subscribers use a PULL socket to process the SPDY stream
5. Backend subscriber streams a response back to the frontend

The communication is done over a persistent channel with message-oriented semantics, the frontend and the backends are completely decoupled, and we can finally stop punching "TCP holes" in our networks to support the modern web.

Supporting HTTP 2.0 in the back office

The new protocols are here, but the supporting "back office" architecture requires a serious update: SSL is becoming the default, streaming is no longer an option, and long-lived persistent connections are in. SPDY is gaining momentum, and I have no doubts that in the not so distant future it will be an IETF approved protocol. Similarly, ØMQ is not the only alternative for internal routing, but it is definitely one that has been gaining momentum.

Fast HTTP parsing and routing is simply not enough to support the modern web use cases. Likewise, punching "TCP holes" in our infrastructure is not a viable long-term solution - in 2012 we should be asking for more. Yes, I'm looking at you Varnish, Nginx, Apache and friends.

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!

#316 Private Pub »

Created at: 16.01.2012 10:00, source: Railscasts

Private Pub makes it easier than ever to publish and subscribe to real-time events in a Rails app. You can use publish_to with a block of JavaScript or supply a hash for use with JSON.

Chicks That Rip: Carin Meier »

Created at: 12.01.2012 21:48, source: Engine Yard Blog, tagged: community Carin Meier Chicks That Rip

Carin Meier is a ballerina-turned-developer who hails from Ohio. I met her at JRuby Conf 2011, where she gave a fantastic presentation on Semantic Web and JRuby. She is a comitter to the 4clojure project and a Ruby devotee who loves to explore new development communities in the Cincinnati area, where she works at EdgeCase with the likes of Jim Weirich and Joe O'Brien. Carin's got a lot to say about the power of shared data and the value of JRuby--check it out!

You started your career as a professional ballet dancer. How did you make the switch to computer science?

I really enjoyed my time dancing with ballet companies, but I always knew that I wanted to go to college as well. I chose to study Physics because it was challenging, appealed to my curiosity, and, quite frankly, the math just made my brain feel good. It also helped that I had a really inspiring female Physics teacher in high school. I remember distinctly one of my first Physics labs, in which we set up a ramp with a ball on top and calculated the distance to place dish to catch it. I made the calculations and when the ball actually dropped in the cup, I was hooked. This Math and Science stuff was very cool. Later in college, I worked on computer simulations with Mathematica and discovered that I really liked working with with software. So when I graduated, I took a job with a consulting firm and starting doing software development full-time.

What were your first experiences with software development like?

My first experience in the professional world was doing a HR conversion project for a large company. It was very different from the scientific modeling projects that I had done in school. The thing that I enjoyed about it was the immediate impact and value of the work that I was doing. Working with business owners and helping them solve problems was very gratifying. I also enjoyed collaborating with other developers in a team environment. Picking up all the new software development tools was not very difficult for me. Learning the domain and how to apply the right technology, was to me, the more challenging and important learning.

You mentioned that you have had the rare experience of working in two very different environments (as a dancer and as a programmer)—one where women are the majority, and one where they are the minority. Can you tell us more about this and what you’ve learned from both experiences?

I see a lot of similarities. Men in ballet are definitely in the minority. Ballet, in our culture's view, is more for girls and not boys. As a result, there are not many men in professional ballet companies. It would be much easier to have dance company of all women. However, dance performances are so much richer and more expressive when they have both men and women performing. Having both makes the performance better, the audience happier, and the company stronger. There are the same sorts of cultural stereotypes with girls in math and science. But, in my opinion, the benefits of having a diverse software development team are similar. It allows a more comprehensive and expressive application of technology that, in the end gives you a better product, happier customer, and a stronger company. I am very hopeful that as technology and software become a more integrated part of our children's lives that we will increase the diversity in our software communities too. I think role models are important too. I have a 5 year old daughter and was quite pleased when she announced that she wanted to be a computer programmer, like Mom, when she grows up. On the lighter side, one of the best perks of being a woman attending a technical conference rather than a ballet performance is - no lines for the women's restroom.

You’ve worked for Fortune 500 companies and startups, as well as running your own consultancy. How do these environments compare? Which do you prefer?

Each environment has it owns advantages and disadvantages in my view. At the large enterprise level, there are some really interesting technical problems to solve having to do with scaling and data wrangling that you don't usually encounter at the smaller company level. However, at the small company level, there seems to be more freedom in choosing and shaping the technology, as well as working directly with the customer. I, of course, loved the freedom of running my own business, but at the end of the day realized it was quite lonely for me and I preferred working in a team. Working with EdgeCase has been the best blend of all worlds for me.

How did you discover Ruby and what do you like about it? What has your experience with the Ruby community been like? What is the Cincinnati Ruby community like?

I discovered Ruby through our local community Cincinnati Ruby Brigade, which totally rocks. I was immediately impressed with both the people and the language. After working with Java, the dynamic power of Ruby and it's ability to create clean and concise code really got my attention. I was equally impressed with the Ruby community. I have found it a very warm and welcoming environment. There is always someone more than willing to help you learn and overcome any problems. The open source community is full of incredibly smart and vibrant developers making really cool things. Oh, I and really like the Ruby whimsical streak too.

In your opinion, what is the value of JRuby? How do you use JRuby?

JRuby combines all the dynamic power and expressiveness of Ruby with enterprise ready platform of the JVM and gives you access to the rich world of Java libraries. That is a huge win. At our EdgeCase and Gaslight Software office, JRuby is being used on several projects. One current example is a project that is using JRuby access PDF libraries that are not available in Ruby. Another project is using JRuby's ability to deploy as a war file to enable their product to be plug and play for any enterprise.

You gave a great presentation on Semantic Web at JRuby Conf 2011. Can you talk a little bit about why you’re passionate about this subject?

I have always had a deep respect for data. But, data alone is not as powerful as data shared. Semantic web gives us the ability to share and link data to other data in a standard way across the internet. This may sound like a simple thing, but look what sharing and linking documents to other documents through HTTP has done to our world. We have already seen great advances in search engines, analytics and data integration from Semantic Web technologies. But, I really think it is just the tip of the iceberg and I am very excited to see what the next few years bring as we shift our focus to an open data world view.

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.

#314 Pretty URLs with FriendlyId »

Created at: 09.01.2012 10:00, source: Railscasts

If you are tired of model ids in the URL, overriding to_param can only get you so far. The friendly_id plugin can help by making it easy to generate a URL slug and maintain a history.

My Command Line Prompt »

Created at: 05.01.2012 23:00, source: Nuby on Rails

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach & Paula Lavalle

Current Path
More

Last Command Status
More

Uncommitted Git Changes
More

RVM Config
More

Git Branch
More

Advanced Git!

One hour video.
Only ^$12! More Info…

Implementation

Setup

The following configuration directives should be in ~/.zshrc. See the full source for the complete setup.

Run these commands to load zsh’s color variables. You’ll be able to use readable values like $fg[black] instead of cryptic ones like \e[0m.

# Colors
autoload -U colors
colors
setopt prompt_subst

Last Command Status

I first saw this technique in Pat Allan’s shell. If the last command exited with a nonzero value, it will print a red Unicode frown: ☹. Successful commands will show a green smiley: ☺

It’s a nice way to quickly see if tests failed or a compilation aborted.

And you’re not limited to ASCII! Use the Unicode snowman, a skull and crossbones, or any other dingbats character.

# Save a smiley to a local variable if the last command exited with success.
local smiley="%(?,%{$fg[green]%}☺%{$reset_color%},%{$fg[red]%}☹%{$reset_color%})"

Current Path

On my local machine I want to show only what’s necessary. So I don’t show the current user, hostname, or anything other than the relative path that I’m currently in.

In zsh, that’s %~.

Assign it to PROMPT to set the left-hand part of the prompt. It occupies two lines: the path is on one line and the previously saved smiley is on the next. $reset_color is a zsh variable that restores your default text color.

# Show the relative path on one line, then the smiley.
PROMPT='
%~
${smiley}  %{$reset_color%}'

Git Branch, SHA & Dirty Status

It’s surprisingly difficult to get Git to tell you what branch it’s on. I’ve tried several scripts, including the multi-SCM vcprompt (which worked well).

My current favorite is a Ruby script that prints all kinds of useful information about your Git setup:

• Current branch name
• The current SHA (7 characters of it). Useful for anytime you need to get out of trouble with git reset --hard. See the PeepCode Advanced Git video for this and other Git tips.
• Rebase status (to know if you’re in the middle of a rebase)
• Dirty status Have any tracked files been edited? A Unicode ✗ is displayed if changes have been made but not committed.

The original script is from Ben Hoskings(requires Ruby 1.9). I edited it to work on Ruby 1.8 and used a brief git-current-branch script (source). The relevant edit is on the last three lines where it specifies a format and colors for the final display.

RPROMPT='%{$fg[white]%} $(~/.rvm/bin/rvm-prompt)$(~/bin/git-cwd-info.rb)%{$reset_color%}'

I chose to make the more important metadata stand out more. The Git branch name and dirty status are more important to me than the Ruby version or the current SHA, so they are a darker shade of grey. Ben uses an @ sign before the SHA, but I replaced it with whitespace.

Ruby & Git metadata.

RVM Config

The name of the current Ruby version as configured by RVM is actually in the previous snippet. It calls ~/.rvm/bin/rvm-prompt and displays it at the left side of the right hand prompt.

Put it Together

The combined prompt looks like this.

# Combined left and right prompt configuration.
local smiley="%(?,%{$fg[green]%}☺%{$reset_color%},%{$fg[red]%}☹%{$reset_color%})"

PROMPT='
%~
${smiley}  %{$reset_color%}'

RPROMPT='%{$fg[white]%} $(~/.rvm/bin/rvm-prompt)$(~/bin/git-cwd-info.rb)%{$reset_color%}'

The important thing is to customize your own prompt and make it work the way you want it to!

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.