I recently upgraded the OS on my Macbook Pro 13' to Mountain Lion (OS X 10.8). As a Ruby on Rails developer, supporting many environments is a must, and the biological and technological diversity of our clients require a plethora of tools to be installed and operational on my Macbook.
Anywho I found that this guide was helpful with the upgrade:
At reInteractive we use Git Flow for all our projects.
But with lots of branches comes a problem. What happens when you have migrations that are branch specific? If you have used branching a lot on an in development Rails application, you are sure to have run into the problem of changing branches and having an inconsistent database state against your code.
We use Amazon S3 on almost every project we work on, and this usually means that we end up needing to create temporary buckets for use on staging or demo sites.
Obviously, we don't want to be reusing the same access key and secret key on every staging and development site, even if they are temporary. Instead we create a separate key pair for each.
We've recently been working on increasing the integration test coverage for a client app that is very form heavy. Eventually a lot of the forms on this application are going to be redesigned and restructured but before we get started on a big backend refactor we wanted to make sure the frontend coverage is up to scratch.
Typically, the best way to do this is to write Capybara based request specs. This works well but with big forms, it can get a bit unwieldy with a lot of copy and paste between tests. Worse, if your forms are bound to change going back over all the tests and changing CSS locators or Capybara method calls is a bit of a pain.
If you haven't tried Sublime Text 2 yet, and you code for a living, you should. It really is a great text editor that gets out of your way.
But I found when I was flipping between rails, ruby, features, specs, ERB, sass etc that the syntax matching wasn't so good.
Quick Tip: Find all models in a project that include a certain method.
Useful for some engine applications. When you don't know what the parent application has you can do things like:
One of our clients recently had some performance problems with a page that displayed a very large form. This form had a tonne of select boxes with large lists of dynamically generated options. The options were based on some property of the user, e.g. their home state, and in most cases the list of options were completely different for each state. In total, the select boxes took about 500ms to render!
Typically, caching forms is a bad idea, because the content is specific to a single user. To do it in a way that doesn't mess it up for all users, you would have to cache it on a per-user basis, i.e. something like this:
For one of our larger rails clients, the answer's a definite yes. This site is a shopping cart application where user experience, and retention converts to clicks which convert to dollars.
Shoppers on this site now feel the benefit of a 25% improvement in average response time (sampled across 36hrs) since the upgrade to 1.9.3 was deployed.
The past 12 months have been explosive, exciting and quite a management challenge for us here at reInteractive.
But most importantly, we helped a large number of clients achieve their online goals or furthered their ability to improve their business operations.
One project I've been working on has a bunch of remote MySQL databases that we need to attach to (but don't control).
The user specifies columns and we run jobs that insert data into these remote tables. This, of course, generates some really ugly sql, especially when the data you're inserting contains scraped websites.
