I've finally found a bit of time to update Cedar to work with Xcode 4, and I hope to have it working smoothly some time in the next few days. However, I've already come across my first significant issue with the Xcode 4 changes: the location of build products.
Not unexpectedly, the problem has to do with command line builds using xcodebuild. By default, Xcode 4 now puts build products into a project-specific directory in the "Derived Data" folder; this looks something like /Users/pivotal/Library/Developer/Xcode/DerivedData/Cedar-somegianthashstring/Build/Products/Debug-iphonesimulator/libCedar-StaticLib.a. This isn't a problem, generally, because the BUILD_DIR compiler variable contains the build directory, should you need to find this location during the build process.
Sadly, when you build from the command line, using the xcodebuild command, the build products still go into the old Xcode 3 build location, but the BUILD_DIR compiler variable contains the new Xcode 4 build directory. This means any script that looks for the build results in the directory specified by BUILD_DIR won't find anything.
The build target for Cedar's static framework is simply a script that uses xcodebuild to build the static library for both the simulator and the device, and then uses lipo to make a fat binary from the results. Because it can't find the build results at the location specified by BUILD_DIR it now fails messily.
The easiest workaround I've found is to change where build products go using the Locations setting in the Xcode 4 preferences (details below). Unfortunately, this isn't a project-specific setting, so you'll have to change your preferences similarly to make it work. I haven't found any problems with changing the location of the build products, but this does mean the Cedar static framework (as well as the related static frameworks for OCHamcrest and OCMock) won't build with the default settings. Unsatisfying.
The longer term solution is for Apple to act on the bug I filed. We'll see how that goes.
UPDATE: Thanks to Christian Niles for pointing out the SYMROOT environment variable in a pull request. Setting this for command line builds forces Xcode to use the specified location for all build products, and updates the BUILD_DIR compiler variable.
Steps for changing the build location in Xcode 4:
- Open Xcode preferences (Command-,)
- Select the "Locations" tab
- Change the "Build Location" drop down from "Place build products in derived data location" to "Place build products in locations specified by targets."
As we've grown our mobile practice at Pivotal we've tried to apply to it the same principles and disciplines that have made our Rails practice successful. Often the one that we have the most difficulty translating is testing. In my experience the testing tools for Objective-C in particular are significantly wanting; there are some out there, but they're hard to find, often hard to use, and occasionally defective in frustrating ways.
One of the things I found I miss most in testing Objective-C, Java, or C++, is the hierarchical structure for organizing tests that frameworks like RSpec or Jasmine provide. I find nested describes indispensable for managing orthogonal aspects of the classes under test, for handling preconditions, for eliminating redundant setup code, and for generally keeping my sanity. So, when I first heard about the addition of blocks in the GCC compiler for Objective-C the first application that came to mind was testing.
So, I wrote Cedar, a BDD-style framework for writing tests in Objective-C. The code is available here. Perhaps more importantly, Cedar is in its infancy so I'm interested in any suggestions and feedback. To that end, I created a public Tracker project for it here.
As you may have heard, this year there aren't any Ruby projects as part of this year's Google Summer of Code. The Ruby community's response to this is a pretty amazing validation of the awesomeness of us! We have created our own Ruby Summer of Code, and raised $100K in just 3 days to sponsor 20 students to work on Ruby open source projects. That's actually a lot more than Google would have sponsored anyway. And Pivotal Labs is one of the six full-project sponsors, woot! We're sponsoring $5K, the amount to cover one student's work full time for the whole summer.
We will no doubt have some pivots volunteering for mentor spots. If you want to volunteer to mentor, you need to apply by the end of this week (April 3rd).
Pivotal Labs is also going to be providing desk space for (a couple?) local students who want to come work in the office for the summer - they'll get to come to our daily standups, eat breakfast with us, attend our tech talks, play Pivot Pong, and just be part of the Pivotal experience. We hope there are some local students who participate in RSoC and that someone comes to hang out with us for the summer. It's also likely that some local students would get to do a report on their projects at the Golden Gate Ruby Conference in September.
Students can apply for spots during the period April 5th-23rd.
Thanks to everyone for stepping up and supporting this great response. This is the kind of thing that makes being a Ruby developer so gratifying, and so fun too.
Rails 3 is now beta and the core team is asking people to try it out and report issues back. We decided to do a small spike to get some experience with the upgrade process and see if we could help identify any problems. The application we worked on was our own Pivotal Pulse CI aggregation display (which you can see in action).
Here's a quick overview of the steps we went through:
- Install Ruby 1.8.7 using RVM
- Install Rails beta gems
- Upgrade the app using the rails_upgrade plugin
- Tweak things a lot
- Drop incompatible dependencies
- Profit!
One of the things I've always liked least about building web applications is dealing with mod_rewrite. It's a very useful feature, but it's quirky and the config languages for webservers are difficult to use (at least from my experience with Apache and Nginx). But like it or not, mod_rewrite is often a necessary part of a web app. Until now...
Recently I had to redo the rewrite rules for pivotallabs.com when we switched from Apache to Nginx, which we did when moving to EngineYard's cloud hosting. Since then our Nginx config has grown to over 150 lines, mainly to deal with multiple virtual hosts.
Now, managing a custom Nginx config on the EY cloud system isn't as simple as I'd like, especially when the configs are different on production and demo environments. (Demo is what we call our usual environment for doing feature acceptance.) It's far easier to use the automatically generated config, but that doesn't work when you need to support multiple domain names.
The obvious thing to do was to move the rewrite/redirect logic out of the Nginx config. I found a couple Rack middleware components that did something sort of like what we needed, but none of them were sufficient for what we needed. So we created our own.
Refraction is a Rack middleware replacement for mod_rewrite. With Refraction we were able to replace our 150+ line Nginx config with a 50 line Ruby file, and go back to using the standard automatically generated config on EY cloud.
Here's an example Refraction config file:
Refraction.configure do |req|
feedburner = "http://feeds.pivotallabs.com/pivotallabs"
if req.env['HTTP_USER_AGENT'] !~ /FeedBurner|FeedValidator/ && req.host =~ /pivotallabs.com/
case req.path
when %r{^/(talks|blabs|blog).(atom|rss)$} ; req.found! "#{feedburner}/#{$1}.#{$2}"
when %r{^/users/(chris|edward)/blog.(atom|rss)$} ; req.found! "#{feedburner}/#{$1}.#{$2}"
end
else
case req.host
when 'tweed.pivotallabs.com'
req.rewrite! "http://pivotallabs.com/tweed#{req.path}"
when /([-\w]+.)?pivotallabs.com/
# passthrough with no change
else # wildcard domains (e.g. pivotalabs.com)
req.permanent! :host => "pivotallabs.com"
end
end
end
These rules are extracted from the full config file for pivotallabs.com. They redirect high-traffic syndication feeds to feedburner, rewrite a subdomain (tweed.pivotallabs.com) to a path for that sub-site (pivotallabs.com/tweed), and redirect some aliases to our standard domain name (pivotalabs anyone?).
Refraction is thread-safe, which means you can put it outside the Rack::Lock, something we felt was important for performance. It will never have the performance of mod_rewrite, but it will certainly be better than handling redirections in Rails itself.
Full documentation is available in the README. Contributions welcome.
And of course big thanks to Sam Pierson and Wai Lun Mang who both paired with me on developing Refraction.
Years ago, after I finished college but before I started working professionally with software, I spent a couple years working as a paramedic. I learned a lot from that job, not least about interacting with people who really, really don't want you in their lives.
One of the calls I remember most vividly happened around three in the morning, not long after schools had let out for the summer. A group of recently graduated high school girls had rolled their Ford Bronco on the highway. When we arrived an engine company was on scene, busily cutting the remains of the car into fun size Bronco strips. I followed the trajectory implied by the hole in the windshield and found my patient, the driver, on the pavement some distance from the car.
Yesterday I wrote about Wapcaplet, which is really little more than a Rails patch that didn't get accepted, but that some of us think Rails actually quite needs. To that end I submitted a second patch, which does the same thing but, by default, outputs a warning rather than raising an exception. I also included some methods for modifying the behavior on ActionController::TestCase. Specifically, if you want to ensure your tests aren't broken:
ActionController::TestCase.treat_parameter_type_warnings_as_errors
Or if you, like Pierre, don't care:
ActionController::TestCase.ignore_parameter_type_warnings
I don't know if these changes will make the behavior of the patch palatable enough for the core team to commit it. We'll see. After creating the ticket I considered pulling the new behavior back into Wapcaplet; I've decided not to for a few reasons:
First and foremost, no one pays attention to warnings. I can't count the times I've preached myself blue about eliminating compiler/interpreter warnings, to little or no effect. I recently broke the builds for several projects by deleting a method that had been deprecated for a year and half, and which generated a fairly annoying deprecation warning on every build for every project that used it (keep in mind that at Pivotal projects will build many times a day).
Any patch applied to Rails will affect every Rails project that upgrades. I believe people should fix their broken tests, but I accept that this change will break a lot of tests. I can accept warnings as a way to show people what may be broken without bringing the world down on their heads. Wapcaplet, on the other hand, is entirely opt-in; no need to handle users with kid gloves.
I believe that a test failure is the right behavior. We're talking about broken tests, they should act that way.
Remember, the lion ate Pierre.
We've had some trouble with test task errors causing failing builds on our continuous integration boxes ever since the release of the version 0.8.3 rake gem. Sound familiar? Read on!