It's not often that I need these, but when there's a Memory Consumption issue in a Rails application, these references and tools definitely come in handy:
heroku addons
cron:daily
custom_domains:basic
logging:expanded
memcache:5mb
newrelic:standard
pgbackups:auto-month
sendgrid:basic
shared-database:5mb
One scenario in developing applications, is the application is built and then handed off to a Web Integrator to implement the CSS. The other is templates are created and these are integrated by the web developer. This checklist is primary for the first scenario, but is probably applicable to the second. Here is a list of checks you should make before handing off for integration:
Any thing I have missed? Please let me know in the comments.
Just a quick reminder to link all your assets with https:// when they are under SSL. Since libraries such as jQuery are hosted by third parties such as Google, it's easy to forget to use https. When a user accesses a page under https and some assets are not accessed securely, the user will see a dreaded message warning that the page has some unsecured assets.
In Rails I use the request protocol which returns http: or https://
= javascript_include_tag "#{request.protocol}ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"I have updated my Webmaster Launch Checklist to include this item.
In my post Leave a project how you would like to find it, I discussed how to leave a project with a great README. I added another item to that, how to preview emails. When handing off a project to a designer to skin, an issue that arises is previewing the application emails.
In his Scaling Labs video, Greg Pollack suggests handing of application emails to an email service provider. I think that is a great idea, but sometimes if you are working on a short lived website that might be over kill. So my solution is to create a rake that a designer can easily use. Here's my recipe:
Here an (edited) example of the rake task I wrote (lib/application.rake):
desc %{Sends test notification
Must specify RAILS_ENV=mail
EMAIL=you@example.com to specify email address}
task :send_notification => :environment do |t|
registration = OpenStruct.new
registration.first_name = Faker::Name.first_name
registration.last_name = Faker::Name.last_name
registration.email_address = ENV['EMAIL']
CompetitionMailer.deliver_notification(registration)
end
Now run rake send_notification RAILS_ENV=mail EMAIL=nicholas@example.com. Check your email inbox!
Platform notes:
There are other solutions that you may be interested in as well:
When I start a new front-end project coding HTML/CSS I will ask the designer to provide a style guide to outline the typography used through the website. I find when I mark-up the CSS for the typography first, before starting the grid, the overall CSS is cleaner. How do you communicate what elements need to be in the style guide? Well there are some basic elements such as headers, forms and table that I provide in a HTML file that the designer can start with. Then additional typography elements, such as typography in sidebars and call-to-actions are added to the style guide. Are there any elements you think need to be included in my basic HTML file? I like to keep it relatively simple so I don't add things like definition lists, but perhaps I should. Let me know.
Here is a basic pre-launch checklist I use when working on a Shopify Project. Of course this checklist can be used on any type of eCommerce project:
And don't forget training the client in using the administration backend. Shopify has a great set of resources for support and training:
The first thing you will probably want to do is help your client understand how to organize their products.
I started a new CMS project yesterday with Radiant. One aspect I am really focusing on is to ensure that all the "other" details are taking care of during the development, so when another developer needs to work on it, they can get started on it as quickly as possible.
The new Bundler and Rails 2.x config.gem have certainly helped with installing dependent gems, but I still think it's beneficial to have a step by step guide in the form of a README file on getting the application running and any other aspects of the application the developer should know about.
GitHub presents the README file of the homepage of the repository.
Please replace the default README file in your Rails or Radiant application (or any other open source application). Here's a basic outline of what you could include:
Are there any other items that should be in the README? Do you have any links to examples of great README's?
I have a bunch of checklists that I really need to start sharing on this blog. Here's the first one, the "Webmaster" Launch Checklist. Just some basic things to check before going live with a site. If you have your own online, please link in the comments. If you think there is something I'm missing, please let me know. Admittedly a lot of this is covered by by "blank-static" project, which covers the basics like custom 404 and 500 pages. It's the little things...
Before your application goes into production there are some maintenance and monitoring tasks you need to consider. These tasks include:
You need to maintain offsite backups for your application’s:
I have a set of backup scripts (executed via a nightly cron process) that dumps the database for each of my applications, which are in turn archived, and then downloaded to my server. Shared assets, those files uploaded via your application typically located in the public folder, are synced to my server and then archived. As my source control is hosted on Github, I don’t need to worry about backing this up.
Installing the logrotate package will take care of your system logs, but you will need to set up log rotation specifically for your Rails application. I typically deploy my applications using Moonshine, a server provisioning tool from the folks at Rails Machine, so log rotation has been addressed. There maybe some other logs that are generated by your application such as Ferret server. Consider these files in your applications log folder:
Monitoring is split into four categories:
Monitoring services such as Apache, MySQL or even processes that are apart of your application, such as the Ferret server can be monitored by Monit or God. If these services go down unexpected, they are automatically restarted by the monitor.
Performance Monitoring can be broken down further into Server and Application Performance. Munin is a good candidate for the first, while service providers such as New Relic and Scout are good for the later. With Server monitoring you will also want to consider the consumption of resources. For example, how much disk space do I have left? How much RAM do I have left?
An external monitoring service is useful. Services such as Monstatic, 24×7, or Pingdom can notify you when your server is inaccessible.
Finally, the Exception Notification plugin suits my needs to be notified of an exception, but you may prefer a service to manage this such as Airbrake Bug Tracker or Exceptional.
Sometimes you will need to run scheduled jobs against your application such as managing recurring subscriptions. Make sure these are installed and running. It’s best to make these a part of your deployment using whenever or again, my preference is using Moonshine.
If you are you are using ActiveRecord-based sessions in your application, then you will definitely need to setup a task to remove old records in the sessions table.
2002-2019 Nicholas Henry
All Rights Reserved
Please note this blog is no longer maintained. Please visit CivilCode Inc - Custom Software Development.
