bgror

Exciting New Integration: Badgeville in our Helpdesk! »

Created at: 15.05.2012 18:17, source: Engine Yard Blog, tagged: Customers Technology Tips & Tricks

We are pleased to announce that we have integrated Badgeville’s gamification technology into our Zendesk ticketing system.  As you use the helpdesk to perform different actions,  (searching documentation, contributing to forums, completing satisfaction surveys, etc.) you will be able to earn many different badges and complete many different missions.

Through this integration we hope to increase community engagement, and to not only give you new channels to share your experiences and ideas, but also to reward you for it!

While inside our helpdesk, if you hover over a user’s picture, a little summary profile will appear showing how many points and rewards that user has, as well as the last badge that they have earned.

By clicking on “Click for profile” you will be brought to the user’s showcase that shows their progress on the current missions, with hints on how to earn the badges associated with them.  You will also be able to see your showcase anytime, by clicking on the “Profile” link in the upper right corner.

Also, there have been a few new Community forums opened up in the last week, so if you want to share your ideas and start earning some badges, check them out here!

Keep your eyes open. We will be introducing additional missions in the future.  If you have any questions or feedback, please open a ticket and I will get back to you!

Happy playing!

All About High Availability »

Created at: 09.05.2012 02:22, source: Engine Yard Blog, tagged: Technology Tips & Tricks training

What is a High Availability system? There are multiple opinions/definitions of high availability. Some people refer to it as Disaster Recovery; I refer to it as an implementation to ensure that business systems spend minimal time down from a disaster.

For the purpose of this post, I think we should establish a description of Disaster Recovery and how it relates to High Availability. Disaster recovery includes the processes, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster. There are 7 tiers to disaster recovery; tier 0 is no data loss prevention or basically several single points of failure, while tier 8, which is a fully automated failover system with zero to minimal data loss. Tier 7 and 8 are more in the classification of High Availability. Recognizing that there are plenty of discussions, opinions, and confusion regarding High Availability/Disaster Recovery, I have decided to discuss what I believe is the most logical solution for e-commerce and mission critical cloud applications.

Utilizing cloud technology for applications has grown immensely over the past 3 years. This growth is due to the fact that IT organization (or lack there of) has minimal responsibility, overhead and maintenance. All of this equates to less money spent and larger margins on revenues.

Although this has its upsides, there are many pitfalls associated as well. Some of these are lack of control over infrastructure, lack of knowledge as to what infrastructure is to be utilized and a lack of knowledge about the maintenance of this infrastructure. It is important to remember that cloud infrastructure is subject to outages just as normal infrastructure would be. A virtualized environment is a great way to minimize costs and maximize margins, but it does not prevent against outages. To minimize the lack of control clients have over these systems it is recommended that one invest into an insurance policy that would minimize down time during a man made or natural disaster.

The most logical or practical insurance plan to ensure ones business stays up with minimal down time is to implement a geo redundant High Availability system. A geo redundant system is basically a master/slave system located in two separate geographical locations. This is very similar to what most everyone implements with their local databases, in the event of the master database failing the slave takes over to where the application has minimal to no data loss with minimal application downtime.

Accurately implementing requires that the database replication is constant, in our agile world we also need to ensure that all code is pushed to both locations, the directory structures are replicated at a specific intervals and that all of the policies and procedures are in place to fail over from one geo location to the other geo location with minimal downtime and maximized efficiency. With the lack of control in cloud computing and the definite knowledge that an outage will occur, the logical solution to ensure Application up time and minimal Data loss is to implement a Geo-Redundant High Availability system.

We at Engine Yard recognize the need that clients have in running their applications on the cloud and that downtime equate to loss of revenue and more importantly possible loss of client. We have now implemented this technology and are offering it to clients that need that solid insurance.

Check out Engine Yard Professional Services page to learn more. If you have any questions about services offered for the Engine Yard PaaS, please feel free to contact proservices@engineyard.com.

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!

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.