by Neil Middleton 10:37 am Tuesday, 20 July 2010.
Note: This has only been tested to work with Heroku, my hosting service of choice. It's not been tested anywhere else. Regardless, you should still test everything yourself.
RPM is a fantastic tool for seeing how your Rails application performs in production, and to be honest, having run some production apps without it, you are completely blind if it's not set up.
However, the arrival of Rails 3.0 has brought some far reaching changes to the way the framework works, rendering the RPM gem useless with Rails 3.0. However, NewRelic have a newly released version (
2.13.0.beta5) which works with Rails 3, and I have running in a couple of production environments.
So how do you get it up and running?
Well Rails 3 means bundler, so first step is to include the following in your Gemfile:
1
|
gem 'newrelic_rpm', '2.13.0.beta5', :require => false
|
One this is done, create config/initializers/newrelic.rb and simply include:
Deploy the code when you're ready, and then flip on the New Relic add-on at Heroku. Hopefully, your apps still running, but now with added RPM goodness.
Posted via email from theskunkworx’s posterous
Comments (0)
by Neil Middleton 10:28 am .
Note: This has only been tested to work with Heroku, my hosting service of choice. It's not been tested anywhere else. Regardless, you should still test everything yourself.
RPM is a fantastic tool for seeing how your Rails application performs in production, and to be honest, having run some production apps without it, you are completely blind if it's not set up.
However, the arrival of Rails 3.0 has brought some far reaching changes to the way the framework works, rendering the RPM gem useless with Rails 3.0. However, NewRelic have a newly released version (
2.13.0.beta5) which works with Rails 3, and I have running in a couple of production environments.
So how do you get it up and running?
Well Rails 3 means bundler, so first step is to include the following in your Gemfile:
1
|
gem 'newrelic_rpm', '2.13.0.beta5', :require => false
|
One this is done, create config/initializers/newrelic.rb and simply include:
Deploy the code when you're ready, and then flip on the New Relic add-on at Heroku. Hopefully, your apps still running, but now with added RPM goodness.
Posted via email from :neil_middleton
Comments (0)
by Neil Middleton 2:27 pm Friday, 2 July 2010.
Comments (0)
by Neil Middleton 4:11 pm Wednesday, 5 May 2010.
Over the last few months, it would appear that global internet thermonuclear war has set in.
This, for the most part has been surrounding the mobile platforms out there. Apple’s i(Phone/Pad/Pod Touch) has been battling Google’s Android, Apple has been battling with Adobe
over Flash, and then there’s the patent wars between
Apple, Google, HTC and Microsoft.It’s a pretty big fight.
So, what do developers do? From a skills point of view we want to be aligned with the most popular platform that will give us the most marketability – yet from a business point of view we want our applications to work on as many platforms as possible to maximise the ‘attack surface’ in the various markets out there and gain the most revenue.
Then there’s the different markets – Apple have their
draconian approval process, but provide the class leading App Store, whereas Google is all about free-love and sell it how you want.
Then there’s the platforms. Objective-C, Java, Regular C, Flash etc etc etc etc. The list goes on.
So what are we developers to do – how are we supposed to navigate through this minefield of options? Well, it’s pretty simple actually:
Ignore it.
Every mobile phone manufacturer is striving to produce a browser on their phone that can view the whole web in a similar way to a desktop computer, and all are striving to support the latest and greatest. Therefore, surely the easiest way for us web developers to bring an application to a phone is to simply look at it through a browser?
Picture this, you have an application out there in the wild, you want it to work on the iPhone, so use Safari – job done. It’ll also work on Android with no changes, and is also not dependant on Apple’s approval or anything else, you can do it how you want. Additionally, with libraries like
JQTouch you can access phone hardware should you want to.
But OK, this isn’t ideal for all situations. You won’t have offline access as such, you won’t be able to build games, you won’t get amazing performance – but for the most part, that’s not a big trade off for most business focused applications.
So, in short, why are we worrying about learning all these different tools to make our applications available on different mobile platforms, when we are already expert in the single tool that will make our app truly cross platform – the good old world wide web…
Posted via email from :neil_middleton
by Neil Middleton 3:17 pm Tuesday, 4 May 2010.
Jo’s Cervical Cancer Trust approached us to refresh their old ColdFusion based website that we had developed for them a few years ago. After a clean sheet approach to the site, we decided to create a new Ruby on Rails based site for them using a new up-to-date design, with a much more sound underpinning for future development moving forward.
Now the site’s live we’re seeing some good feedback and Jo’s Trust is more than happy with what Monochrome were able to do.
Robert Music, director of Jo’s Cervical Cancer Trust said, ”We are delighted with the new website and have received only positive feedback from our users. We are grateful to Monochrome for going over and above the original remit to ensure our new site is modern, fresh, visually appealing and easy to navigate. Thank you”
“Working with the team at Jo’s Trust was a pleasure. Keen to deliver a website our client would be proud of for the long-term future of the charity, we initially focused on the conceptualisation phase to leverage the branding wherever possible. I’m sure we’ve created a foundation for further expansion as we look at new and exciting ways to engage with the audience” Adrian Munn – Monochrome Sales & Marketing Director
Comments (0)
Older Posts »