We have three new layout changes on Engine Yard Cloud coming out soon, and we’d like to tell you about them.

These layout upgrades make the Dashboard easier to use and visually clearer, but they don’t affect functionality or your established workflows. Most importantly, the new column dimensions will help us deliver other features and user experience enhancements over time.

1. Tools are up top.

“Tools” are now a part of the header system, in a drop down menu to the upper-right. The “Dashboard” link does the same thing as the blue house icon that appears on almost every page.

2. Fix it quicker.

It’s now easier to file a ticket or visit our documentation. If you are the owner of an account, you will also see a link where you can manage your support level.

3. I’ll take my messages on the side.

Alert and notification messages are now on the right side of the page, making them more readable and preventing them from pushing everything else far down the page when they stack up.

Next up.

Our next steps include improving the messages and alerts to make them context sensitive and to let you filter them. We’ll also be rolling out some cool navigation updates. Sit tight and we’ll post here again soon.

Holla at us!

We would love to hear your feedback regarding these changes! Please email ux@engineyard.com with your comments or suggestions.

Hello again from the Data team! We are excited to start 2012 with a new Beta release: PostgreSQL 9.1 is now in Beta and available in every new environment.

• Homepage: http://www.jruby.org/
• Download: http://www.jruby.org/download

The primary goal of the 1.6.x series is to round out our 1.9 support by fixing any reported incompatibilities. Of course, as with any JRuby release, we will continue fixing any found incompatibilities and also improve performance. All users of 1.6.5.1 (and lower) are encouraged to upgrade to 1.6.6.

Because master keeps getting further and further away from our 1.6 branch we have decided to make this our last 1.6 release. We largely fulfilled our goal of having reasonable 1.9 support. Follow up fixes for 1.9 support will only be fixed on master from this point forward. JRuby 1.7.0 will be the next release of JRuby.

Notable Changes:

• Updated stdlib to match Ruby 1.8.7p357 and 1.9.2p312
• Updated RubyGems to 1.8.15
• Multiple 1.9-mode yield/splat bugs fixed (pp, rspec 2.8 working again)
• Multiple 1.9-mode encoding bugs fixed
• Critical fixes in Random and Fiber
• Map Scala operator methods to symbolic names ($plus, etc)

1.6.5 Issues Resolved:

• JRUBY-6386 time.localtime not taking any arguments
• JRUBY-6384 yaml broken for last 1.6.6 build?
• JRUBY-6383 Scala integration breaks with 1.6.6
• JRUBY-6382 1.9: Padrino can’t generate an app
• JRUBY-6381 java.util.Collection#each dose not respect to_ary defined by objects that are iteratered
• JRUBY-6380 Original array is overwritten when select! is called on a copy
• JRUBY-6377 rspec .should include() fails in –1.9 mode
• JRUBY-6375 Uninformative YAML parser error
• JRUBY-6373 ThreadError: Mutex is not owned by calling thread, when interrupting thread using a Ruby Mutex
• JRUBY-6370 Regression in 1.6.6 in –1.9 mode
• JRUBY-6367 –pre command line switch not working in 1.9 runtime
• JRUBY-6366 More array splatting bugs in 1.9 mode
• JRUBY-6361 RbConfig reports wrong OS type on Solaris
• JRUBY-6359 Can’t convert nil to String building ActiveSupport RDoc in 1.9 mode
• JRUBY-6354 SyntaxError: (RegexpError) invalid multibyte escape in 1.9 mode in the 50th iteration
• JRUBY-6338 JRuby does not look for .jrubyrc in home directory on Windows
• JRUBY-6324 random seed for srand is not initialized properly
• JRUBY-6323 JRuby does not pay attention to either -U or LANG in determining encoding for ARGV (it is always ASCII-8BIT)
• JRUBY-6319 ‘binding’ returns wrong binding
• JRUBY-6318 Tempfile#open does not return the value of the block given to it
• JRUBY-6307 Powering operation of Integer sometimes gets a wrong calculation when 1.9 mode.
• JRUBY-6303 Cannot gem install from a remote repository in 1.9 mode
• JRUBY-6295 Dir.chdir, $HOME and $LOGDIR behavior
• JRUBY-6284 Calls to Kernel#exit result in an exception printed on stderr
• JRUBY-6282 Colon is not allowed in a file name on Windows
• JRUBY-6281 1.9: Applet does not work in the 1.9 mode
• JRUBY-6272 Encoding exception running JRuby 1.6.5 (1.8 mode)
• JRUBY-6233 jruby-complete-1.6.5.jar!/META-INF/jruby.home/bin/rake missing
• JRUBY-6227 1.9: Struct#members and Struct::members should return an Array of Symbols in 1.9
• JRUBY-6224 In MRI 1.9 the flag for Module#const_get also controls lookup of toplevel constants but not in JRuby
• JRUBY-6217 Coverage module not working with Rails ActiveRecord associations
• JRUBY-6214 Dir#rmdir raises improper exception if directory is not empty.
• JRUBY-6212 IO#inspect in 1.9 could be prettier
• JRUBY-6209 Hash#rehash does not work under some condition
• JRUBY-6208 bad gem file creation using mode –1.9
• JRUBY-6206 Incorrect SHA1 on two required packages in Maven Central
• JRUBY-6205 ‘Bad file descriptor’ when using IO.popen4 with OpenJDK 7
• JRUBY-6204 UTF-8 char in XML hangs in Joni
• JRUBY-6202 JIT-ed class names only use method names, causing collisions
• JRUBY-6201 File reading performance regression
• JRUBY-6200 1.9: Loading some Unicode characters results in non-printable characters on Windows
• JRUBY-6199 JRuby is hardcoded to use ‘-mmacos-version-min=10.4’ which is not compatible with ‘-rpath’ being used
• JRUBY-6198 When calling dup on file open in binmode the new object does not respect binmode
• JRUBY-6192 jruby::Handle declarations use ‘extern “C”’, causing linker symbol mismatches
• JRUBY-6182 Marshal.dump yields different value after adding/removing instance variables (and disagrees with MRI)
• JRUBY-6176 SecureRandom.uuid is not implemented
• JRUBY-6173 pp is broken in –1.9 mode
• JRUBY-6172 Requiring a file from a JAR that has a path inside the JAR that coincides with a path on the file system that includes a symlink fails
• JRUBY-6171 Enumerable does not splat
• JRUBY-6170 Fibers are broken in JRuby 1.6.5

Check out the video and slides right here:

We’ll be using the site as a way to keep you up to date with conference developments and details as they unfold. This will be the fourth annual JRubyConf and definitely the biggest and best yet! Join us in talking about and celebrating the union of the Java and Ruby communities. Follow the news section of the site to find out more about sponsorships, speakers, after-events and a soon-to-follow call-for-proposals. Also, stay tuned for more information about Workshop Day (Monday the 21st) and the conference schedule (Tuesday & Wednesday the 22nd & 23rd).

This year’s JRubyConf will take place in Minneapolis, Minnesota, home to some of JRuby’s main contributors and biggest cheerleaders, at the Guthrie Theater on the banks of the mighty Mississippi.

Want to support our cause? We’re currently looking for sponsors for everything from snacks to after-parties, so check out our prospectus for more information, or email us at jrubyconf@engineyard.com if you have other cool ideas. We’d love to see your participation.

Want to join us? Buy your tickets now. Can’t wait to see you all there!

Stable RVM has been available for some time now. Many of you may know what goes on in RVM, but there is still a story to tell.

RVM is now using git flow, following the model outlined here, which makes a diametrical change in the release model of RVM. We will no longer make small releases using the master branch. We will have rare larger releases (called latest). Even so, we will maintain a stable branch which gets only fixes and important updates like ruby version updates. This new release model will allow for development of new features in head whilst keeping a stable version of RVM available for production use.

To install stable RVM:

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

To update stable rvm:

$ rvm get stable # the same as:
$ rvm get branch wayneeseguin/stable

It is also possible to use your own fixes for rvm, which is especially useful for contributors. They can test their work or ask someone else to test their work before sending a pull request. Simply fork the project, add your changes, commit, push and then anyone can install / update to your fork:

$ rvm get branch mpapis/master

RVM now provides information about the age of the installation, in order to see exactly how old the installation is, we can run:

$ rvm info rvm
rvm:
version:      "rvm 1.10.0 by Wayne E. Seguin <wayneeseguin@gmail.com>, Michal Papis <mpapis@gmail.com> [https://rvm.beginrescueend.com/]"
updated:      "2 hours 52 minutes 49 seconds ago"

Significant changes to the output formatting of RVM should be noted—especially the installation and get / notes actions. RVM now displays less information and more readable output when it is installed and updated. The command rvm notes displays all of the important notes that were previously displayed in installation / update process. Updating rvm will now display only the newest updates for notes, so it is not required to run rvm notes after every installation:

$ rvm get head
...
Upgrade Notes:
* If you see the following error message: Unknown alias name: 'default'
re-set your default ruby, this is due to a change in how default works.
...

If we run it again directly afterwards, we will see that there are no new notes:

$ rvm get head
...
Upgrade Notes:
* No new notes to display.
...

Another recent but useful change is the automatic execution of rvm reload after rvm get ...:

$ rvm get head
...
RVM reloaded!

Important Changes

$ command rvm use 1.9.3
RVM is not a function, selecting rubies with 'rvm use ...' will not work.
$ rvm use 1.9.3
Using /home/mpapis/.rvm/gems/ruby-1.9.3-p0

$ rvm alias create default <version>

$ rvm install 1.9.3

$ rvm reinstall 1.9.3

$ rvm install 1.9.3 --force

$ rvm get head --auto

$ rvm user [gemsets/all]

$ sudo rvm user [gemsets/all] --skel

$ rvm install rbx --19   # will install Rubunius with default mode set to 1.9
$ rvm install jruby --18 # will install JRuby with default mode set to 1.8

$ rvm install 1.9.3 --universal # to build fat binary including both 32 and 64 bit binaries
$ rvm install 1.8.7 --32 # to build only 32 bit ruby
$ rvm install 1.8.7 --with-arch=i386 # is equivalent to the 32 bit one, but is available only via RVM, ruby 1.8.7 sources do not support it.

$ rvm install 1.8.7 --32 -n 32 # will fail
$ rvm install 1.8.7 --32 -n n32 # will work
$ rvm install 1.8.7-n32 --32 # equivalent of the above

$ rvm list         # will show the colored list by default in terminal
$ rvm --color=force list | less -R         # will show the colored list in less
$ rvm_pretty_print_flag=auto rvm list | tee my-rubies.list         # will automatically disable colors
$ rvm --color=no list         # will always disable colors

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!

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.

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!

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.

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.