Engine Yard Cloud

Log in

Blog

Bridging the Gap Between Development and Design

By | January 19th, 2012 at 1:01PM

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.

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

By | January 17th, 2012 at 10:01AM

Here at Engine Yard we are committed to making you, our customer, successful. Today we are happy to share with you a new Feature Request Forum available to you within our support ticketing system. The Forum is a place for you to communicate directly with us and with other users. We hope you’ll use it to exchange ideas with the community, and discuss ways we can continue to improve our platform and services to better meet your needs.

This is the first of many community topic forums we will be opening up in the near future. Your opinions and ideas are very important to us, and we want to ensure that you have the platform to share them, not only with us, but with the rest of the community.

All you have to do is log into your Engine Yard Support account and you will see the “Forums” tab on your home page.

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!

Chicks That Rip: Carin Meier

By | January 12th, 2012 at 11:01AM

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

By | January 10th, 2012 at 5:01PM

It’s the new year and often that means new roles and responsibilities and contact information. Please tell us what’s going on in your business and make sure we are up to date.  Here’s how you can keep us informed:

  • 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

By | January 5th, 2012 at 12:01PM

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.

« Older Entries
Newer Entries »
Connect with us: RSS Twitter Facebook LinkedIn

Copyright © Engine Yard, Inc. All rights reserved.