action_dispatch.show_exceptions = truewill show exceptions in test.log for server exceptions with capybara.
Don’t stub object under test… it is normally bad.
- Ruby group meet up next Tuesday.
action_dispatch.show_exceptions = true will show exceptions in test.log for server exceptions with capybara.
Don’t stub object under test… it is normally bad.
Often when working on ruby projects that use Bundler, I see Gemfiles that look like this:
gem 'rails', '3.0.15' gem 'rest-client', '1.3.0' gem 'subexec', '0.0.4' gem 'uuidtools', '2.1.1'
The string on the right hand side of each gem specification is a fixed version specification. If you ask bundler to update any of these gems, it will make a bit of noise but those gems listed will essentially stay the same.
The typical reason for structure a Gemfile like this is to prevent changes in dependent software from causing compatibility issues or to reduce the chance of bugs or unexpected behaviour.
This strategy is problematic for several reasons: it keeps your project stale, makes it difficult to maintain overall project security and worse yet, can provide a false sense of security. There is a much better and simpler way of writing a Gemfile that will preserve the health and consistency of your dependencies.
The first and most obvious problem is that your application will quickly become out of date. The Ruby community moves very quickly and introduces changes quite frequently which means that if you freeze your gems, you may find it very difficult to upgrade later. This problem can be compounded when a security patch is made and the version of the gem you’re using is no longer supported.
A more subtle problem is that the gems listed in your Gemfile have dependencies, and those dependencies may not necessarily be required with as strict a version specification. If you do a bundle update, some of those dependencies could change and break your application.
If you’re the more conservative type, and you’re developing an application that might be in use for some time, you may also be aware that the gems you depend on might not be available forever. They could be removed from the repository, or even altered in a way that breaks your app. If this concerns you there is a much better solution.
The true manifest of gem versions is the file Gemfile.lock which is updated by bundler any time your gemset is changed. This should be kept in source control, so that whenever you or your collaborators run
bundler install, the exact versions of every gem are installed.
If a particular gem version breaks your project, by introducing a bug or a change to it’s API, lock it using the appropriate modifier.
Typically an API change is only introduced in a major version change (e.g: 3.x.x becomes 4.x.x). You can make sure your gem stays reasonably up to date but doesn’t change to the next major revision using a pessimistic restriction like so:
If the next minor version introduces a bug which breaks your project, lock the gem version with a specific revision (e.g
Whenever you restrict a gem version, document why! Sometimes the errors causes by a dependency change can be quite obscure and waste significant time. I like to leave a comment like so:
# TODO: Remove version lock when this bug http://github.com/project/issues/311 # is fixed. It breaks the transmogrification adaptor because of a missing method. gem 'descartes', '3.1.1'
The best indication that a gem has broken your project or needs to be managed more carefully is a test suite with good coverage. With good coverage, particularly integrations tests you can be confident that whenever you do a
bundle update everything still works.
If your gems are kept up to date most of the time and you use source control it will be quickly obvious which version changes introduced a bug.
And finally, don’t specify a version restriction in your Gemfile without a very specific and well understood reason. It can often be tempting to simply list the version of the gem available at the time or to lock the version if you come from a more conservative background. A healthy Gemfile has few version restrictions, explains clearly the ones it has and comes attached with a lockfile for quick deployment and development.
This was cross posted from my personal blog.
Postgres 9.2 will include a native JSON datatype. In addition to verifying that the data stored in the field is valid JSON, there’s also a couple of SQL functions that could be handy (array_to_json, and row_to_json).
There’s a promising pull request for ActiveRecord to support the new json data type.
Our open source developers this week have submitted a pull request to rubygems.org to display a gem’s license on the gem version’s page.
Make sure you add a license to your gemspecs!
Gem::Specification.new do |s| s.license = "MIT" #.... end
Gem::Specification.new do |s| s.licenses = ["MIT", "BSD"] #.... end
Pull request: https://github.com/rubygems/rubygems.org/pull/458
We want to set up our database in a master-slave setup and would like to know what gem is currently recommended.
Answer according to Palermo: Don’t use MySQL master-slave
Our client wants to run Redis with a Master/Slave setup. Has anyone ever done this? What experiences did you make?
Answer according to Davis:
There are 2 options, Redis Cluster which is complete vaporware and Redis Sentinel which is recently released. TLDR: Redis Sentinel
MySQL in the Google Cloud – Now you can use Google App Engine without being stuck with a key-value data store.
We’re getting more reports this morning from customers who are unable to load Pivotal Tracker images/css. We were optimistic that this was resolved by CDNetworks yesterday afternoon, but clearly that seems to not be the case.
We’re escalating this issue to the highest possible level, while at the same time working to set up a different CDN, as well as testing the effects of disabling the CDN completely, at least as a temporary workaround. Please bear with us, this is a top priority for our engineering team.
Please follow @pivotaltracker for the latest updates.
Great News! Our BlackBerry Developer Group Meetups are back!
Join us and BlackBerry Developer Evangelist Patrick Mollins on Monday, September 10, 2012 at 6 p.m for an overview of Cascades and a code walk-through at the Fox and Fiddle. Come out for free drinks and snacks as you learn how to create amazing BlackBerry 10 apps with an astonishing user experience using the Cascades UI framework.
To register click here!
Where: Fox and Fiddle, 27 Wellesley Street East, Toronto ON. M4Y 1G7
When: Monday, September 10, 2012
Time: 6:00 p.m. – 9:00 p.m.
We’ve moved all of the more administrative navigation links to a new dropdown in the top right corner. This is where you’ll find links to your Profile (where you can do things like change your password, update email preferences, etc) as well as to the new Accounts page, and Sign Out. If you’re using Tracker’s simple time tracking functionality, you’ll find the Time link here as well.
First, what exactly is an account, versus a user login? Let’s ask the Tracker FAQ:
Accounts in Tracker are separate things from personal user logins. A user’s login is always associated with an individual–their email address, an optional username and their private password. That login can own or be a member of one or more accounts, and accounts are, effectively, containers for projects.
Accounts allow you to group projects. For example, you might create, or be a member of, an account for your company projects, and have a separate one for your personal work. Every project belongs to an account. You can create as many accounts as you’d like….(read more).
The new accounts page, accessible via the Accounts link the new dropdown in the top right corner of the page, shows you all of the accounts that you are associated with, along with projects in the accounts that you have access to.
For each account, you can see what subscription plan it’s on, as well as how many private projects and collaborators there are in the account. Accounts on this page are grouped as follows:
Accounts that you own – these are accounts that you own, including the one automatically created for you when you signed up for Tracker.
Accounts that you administer – these are accounts that someone else owns, but added you as an administrator to (more on roles here).
Accounts you’re a member of – if you’re a member of projects in someone else’s account, or your company’s account, you’ll see that account listed here, and you can see who owns and administers it (hover over the admins link to see those). The owner or administrator of these accounts may have given you permission to create projects, in which case you’ll see a Create Project button.
Clicking on the Manage Account button for an account that you own or administer allows you to see and change the subscription plan (if you’re the owner), change settings, work with account members, etc.
Previously, projects were grouped by account here, but that made finding the right project(s) hard sometimes. That account grouping is now on the Accounts page, when you need to think about how projects are organized administratively, and the Projects page becomes a simple list of all active projects that you are a member of.
By default, projects are shown in most recently accessed order, so the ones you work with the most should always appear near the top. You can change the sort order to show projects in alphabetical order, by account, or by created date (newest first).
Hover over the cogwheel for various actions including changing project settings, archiving, and deleting.
Clicking the “Show archived projects” checkbox at the top of the page will do, well, just that – show all archived projects.
Creating projects can be done on this page, via the big button, or anywhere else now via the new Create Project option in the Projects drop-down at the top.
There aren’t any functional changes here, but your Profile page looks a bit better now, and allows you to make changes to individual sections without having to scroll up and down to get to the save button.
We hope these changes make it at least a little bit easier to do the more administrative things in Tracker and stay organized. We’d love your feedback on what else we can do, and if you need any help at all, just visit our help and support page.
Stay tuned for what else we’re up to, and what you can expect over the next few months!
At around 3pm Pacific today, we finally received word from our CDN provider that traffic had been rerouted around the “node” causing today’s problems for users in certain locations (manifesting as slow or failed loads of images and stylesheets). The change may have taken some time to propagate to everyone, but at this point the issue should be resolved.
If you’re still seeing any problems connecting to Tracker, or loading images/stylesheets, please let us know by email.
Unfortunately, this was the second CDN issue in less than a week, and we are less than happy with the length of time the problem took to get resolved. We have started to investigate other solutions/providers, and will likely be making changes to how Tracker static content is distributed within days.
Please accept our apologies, we’ll do our best to make sure this doesn’t happen again.
As some of you have (painfully) noticed, we’ve been having problems with our CDN (content distribution network), causing slow or failing loads of certain Tracker “assets” including images and style sheets. This is affecting users in certain locations only – over the weekend it was South America and certain US cities, while this morning it seems to be mostly the east coast and parts of Canada.
We’re terribly sorry about this, and know how disruptive not being able to get to your projects can be. Our hosting provider is on top of this, and has escalated this to the highest level with the CDN vendor. The issue appears to be related to network congestion in a particular CDN ‘node’, they are working to replace it and route traffic around it, temporarily.
Also, we’re actively looking at moving to a different CDN provider, and/or eliminating the need for CDN use by reducing the number of images/etc that need to be loaded in the app.
We’ll post updates as we get them via Twitter, please follow @pivotaltracker to get the latest.
SELECT (column1 + column2) AS super_column WHERE super_column > 1
- use a sub query in the FROM
- duplicate the logic for the calculated column
Github Drinkup in Brooklyn
Join @luckiestmonkey, @steveward, and @juliamae tomorrow night for drinks and great conversation on GitHub’s tab.
Wednesday, September 5th at 8pm.
674 Manhattan Ave.
Brooklyn, New York
(Title: 09/05/12: Better Late Than Never)
About 27 responses so far – even if you aren’t interested in reading or writing blogs, that’s still good to know, so please respond.
During the usual pair exchange we’ll have two great projects for you to help out on! For Open Counter, see Vinicius, for Open 311 see Matt Royal
Come and pair on personal or open source projects! Refreshments provided. Pivots only.
This is a series of articles on Building Social by Default on Mobile as part of our Caramel preview.
In order to design apps and experiences on mobile, it is no longer enough to just think about simple and correct functionality. Paring down is a necessity but no longer the only thing to consider on mobile. As a user discovers more apps and relies on their mobile device for their day-to-day use, there is an increasing need to make these apps work together. And to do so, we need to rethink the inbox.
Apps, as defined by Steve Jobs at his 2007 keynote for the iPhone, dictate the current smartphone experience. These single-function applications are designed to let you perform tasks and interact with the device. But the problem with apps is they lock your life into app silos, and these silos have a hard to time talking to each other. Your email is locked away into one, your text messages in another, and your contact list yet another. The idea of social networking on the phone is to connect us all together, but really its given us a boxed-in way to communicate – through many different apps. When someone asks: “Did you get my message?” You have to think, what do they mean? Was it an SMS, an email, a tweet, Facebook message?
An early success story on an inbox that helps aggregate these silos is the unified messages inbox on BlackBerry. This inbox provided a unique way of exposing all the things you did on your phone, which at the time focussed around emails, BBM messages and texts. This soon expanded to Facebook, Twitter and the current crop of social networks. On iOS and Android this behaviour is eventually emulated temporally via Notification Center and the notification tray on Android. New platforms must embrace this.
On iOS 6, Apple announced Passbook, a place to collect all your tickets, gift cards, boarding passes and other items that would normally be kept in your app. This is an inbox that aggregates on commerce activity and timing, and brings you this information when it’s relevant to you (it even will notify you when you need your boarding pass!). Notification Center is an inbox for your apps in a public place. With the launch of OS X Mountain Lion and Windows 8, this concept of aggregation is making its way back to the current generation of computing platforms across device classes.
Android Jelly Bean OS’s take on Siri is Google Now – a card system and voice search that helps you organize your life. Google Now will remind you in card form when you should be leaving for your next calendar appointment, tell you the weather in the area, provide you details of traffic conditions and so forth. It’s also an inbox centered around activity and context of what you’re doing.
The challenge: making your phone social by default requires rethinking the inbox. Our aggregated activity can’t just live in one place. Apps that use social networking need to be able to interact with their user in integrated means. Solely having access to notifications or just the app will limit what could happen if mobile platforms allowed services to be aggregated at the points at which a user’s activity meets the social network.
When we started Caramel this was the first challenge that we sought to tackle. We decided that we would develop a prototype that would demonstrate the ability to provide access to social networking data in core apps, and to be able to aggregate this activity into a social inbox. Just as Passbook and Google Now are centered around your activity in the real world, the Social Inbox is centered around your interaction with your friends in your social network. Check out how we’re rethinking the way mobile should be social at our Caramel preview.