Rails logging to two log files

I wanted to have a Rails 4 app output a local log and ship logs to a central logging server and format these files slightly differently. ActiveSupport::Logger.broadcast makes this really easy but I couldn’t find any documentation or examples online, so I thought I would post this.

I already had a log_formatting.rb initializer file so I added the following to it.

 


Fetch Request Template (Part 2)

 

I was looking into how to optimize queries in Core Data and wrote some code to test the various ways. It turned out that creating Fetch Request Templates was faster but I had no idea why and wrote a blog post about the results I got in various ways to do fetches in Core Data. I ended up asking about this in Stackoverflow and at first didn’t get much of an answer at first. The next day, I ended up realizing the biggest of the difference between a regular fetch and running on via a Fetch Request Template was that programmatically creating a fetch request it’s required that we provide a sort (versus a Fetch Request Template which doesn’t require the results to be sorted). I was going to update the code to test this assumption and just got around to it.

After a few days of that question on SO going unanswered, someone put a bounty on it and the question got enough attention to get it answered by more experienced iOS devs. I never realized how useful a bounty was.

So as you can see in the screen capture to the right, most of the difference between a regular fetch and a template fetch is due to the absence of a sort. Once I put a sort on the template fetch it was almost as slow as a regular sort – still a bit faster. I’m not sure what the insert/update costs of a index on the sort are but indexing both the search field and sort field doesn’t help all that much. There is still a bit of a difference between a regular fetch and a template search but nothing like the difference in putting an index on the search or sort field.

Again, here’s the code if you want to test other things: https://github.com/jinyk/CoreDataFetchTests.

 


Different Ways to Fetch Data with Core Data

For the life of me, I couldn’t find any decent information about optimizing Core Data fetches, specifically whether creating Fetch Request Templates improves performance. How best to use caches and indexes to improve performance. So I started some sample code to test these questions. Pretty simple app, but it gave me an opportunity to play with a data set from OpenDataPhilly. I picked the test scores of Pennsylvania high schools. Maybe, I’ll write something else using this dataset.

The source is up on github.

Notes:

  • Creating a Fetch Request Template is about 9 times faster writing out a NSFetchRequest.
  • There’s got to be something I don’t understand about setting the cacheName value of NSFetchedResultsController, but it’s exactly the same speed.
  • Creating an index improves performance as expected, approximately about an order of magnitude on this specific test.
  • At first I thought that maybe creating a Fetch Template created an index which is why it improved performance. But it’s definitely more than that because when I created a Fetch Request Template on an indexed field, it improve performance even more.

Testing iOS Apps

At this moment, if you search on Google for “unit testing ios,” the second result points to a page on Apple’s developer site that is outdated and now points to a generic “Tools Workflow Guide.” Most of the first page of results are really brief overviews on the topic or dated. Coming from Rails world, perhaps I was spoiled by the abundance of mature frameworks with tons of examples, tutorials, documentations, and even whole books on the topic. As much as I really enjoyed diving into the world of iOS development, I was very disappointed by the dearth of tools/documentations available on this front. I’m just starting to cover new code I’m writing with tests.

I’m writing this in May of 2012 so using Xcode 4.3. Apparently, until 4, the built in tools kinda sucked so GHUnit was pretty popular. As of Xcode 4, OCUnit is a very reasonable tool to use. Combined with OCMock, pretty easy to setup, easy to use, and good enough for me for now. These tests are compiled and there’s no system environment to load so they run fairly fast. I miss being able to have tests run automatically when I changed tests or code. I also miss being able to run specific tests. I’ve read somewhere that some consider this behavior a feature. Meaning that it’s best to always run all your tests. I’m not sure I buy this, but I don’t really care as long as they run fast.

It looks like there are some other functional/integration testing tools they seem a bit immature to me still. For now I’m just going to be sticking with built-in tools, a.k.a. using Instruments/Automation to record user testing scripts. This basically requires a functioning app to create these tests though. So I think the workflow for me will be to write unit/functional tests in OCUnit, implement the feature, then write integration tests in Instruments/Automation. I’m not religious about TDD but I did appreciate that it really got me write more tests. As with most people, I find it hard to get excited about writing tests for features already implemented. As much as I believe in the ability of these tests in reducing the overall implementation time, for me, the best incentive is to make the process of writing tests more enjoyable for myself.

The app I’m primarily working on now had zero test coverage before I started. It was apparently bit of a rush to implement features until now, the codebase was a rather hacky around the edges, no model layer to speak of (not using Core Data, basically no separate model code, and not syncing information with a backend). Largely due to not using Core Data in the first place, the app tended to use idiosyncratic ways of doing things in favor of idioms/apis/sample code that Apple lays out in its documentation. The scariest part was that the app was interconnected to other parts of the codebase in ways that made the app brittle to change. By far the thing that would have help on-boarding on to this app that much easier would have been to have some tests to run while I was getting familiar with the codebase. It’s hard inheriting then refactoring/adding features to a codebase you haven’t written, but to do it without any sense for how your changes are affecting the rest of the codebase is pretty nerve-wracking. I don’t think this benefit of writing tests for your code is covered enough. Having reasonable coverage helps when you have a team of people working on something, and especially when you add to the team after foundations have been laid out.


import “” vs import <>

Dang, had a hard time finding this information:

from: http://msdn.microsoft.com/en-us/library/8etzzkb6(v=vs.71).aspx

Search Order for filename

filename is optionally preceded by a directory specification. The file name must name an existing file. The difference between the two syntax forms is the order in which the preprocessor searches for the type library files when the path is incompletely specified.

Syntax form Action
Quoted form Instructs the preprocessor to look for type library files first in the directory of the file that contains the #import statement, and then in the directories of whatever files that include (#include) that file. The preprocessor then searches along the paths shown below.
Angle-bracket form Instructs the preprocessor to search for type library files along the following paths:

  1. The PATH environment variable path list
  2. The LIB environment variable path list
  3. The path specified by the /I (additional include directories) compiler option