Will Beer for Code

jonyiveredesignsthings: Jony Ive redesigns the OS...

Tue, 18 Jun 2013 17:38:00 -0400

jonyiveredesignsthings:

Jony Ive redesigns the OS X.

Credit @lukespencerpie

I wish it was Sea Lion.

Tue, 18 Jun 2013 10:53:09 -0400

I wish it was Sea Lion.

WWDC 2013

Mon, 10 Jun 2013 00:32:28 -0400

I’m in San Francisco right now for WWDC 2013 and I’m pretty excited about it. I’ve never been to San Fran or WWDC before, so I don’t really know what to expect, but I’m hoping to come away with my excitement for iOS reinvigorated and more resources for when there’s a problem I can’t figure out.

I must be a businessman. on Flickr.

Wed, 05 Jun 2013 14:54:51 -0400

I must be a businessman. on Flickr.

Photo

Mon, 22 Apr 2013 20:43:15 -0400

InstaCrab

Sat, 23 Mar 2013 13:22:45 -0400

The world’s #1 Social Media app that adds random crabs to your photos was just released to the app store! While I feel we can all agree that crabs are awesome, I think the idea behind the app could still bear some explanation.

I got the idea for InstaCrab, predictably enough, while eating lunch in a fancy restaraunt. I was eating some sort of fish, and it occurred to me that the dish would be greatly improved with some crab. There should be an app for that!

Startup idea: Instacrab. Not sure what it would do yet, though.
— Jose Ibanez (@jose_ibanez) January 5, 2013

Initially I was thinking it would be an app that would use location services to find the nearest place you could go to get crab, with a system for users to report in when they find a crab special or the like. Then I decided it would be easier to just take a picture and add a crab to it. There’s something delightfully absurdist about an app that only does one thing, and that one thing is completely useless. Like the meme that makes the rounds every once in a while:

I have a computer in my pocket which accesses all the world’s knowledge. I use it to get in arguments with strangers & look at pictures of cats

I’m considering adding some additional crabs via in-app purchases, or maybe some Old Bay. I’ve also got a few ideas for some other apps along similar absurdist lines, but even something as simple as InstaCrab took a significant amount of work.

the chemical brothers: "Velodrome" Vinyl Contest Winners Announced:

Mon, 18 Feb 2013 11:14:06 -0500

the chemical brothers: "Velodrome" Vinyl Contest Winners Announced::

thechemicalbrothers:

Greetings Chemical Brothers & Sisters,

At the end of last year we shared a special holiday mix download and collected your names for a prize drawing of the extremely rare “Velodrome” Vinyl. We’re pleased to announce the winners:

Jose from Lafayette Hill, PA

Hey, that’s me!

Glamor shots of the Enjoy By bottle.

Fri, 15 Feb 2013 00:00:00 -0500

Glamor shots of the Enjoy By bottle.

Stone Enjoy By Coming to Philadelphia!

Mon, 07 Jan 2013 19:01:30 -0500

Stone Enjoy By Coming to Philadelphia!:

I’m stupid excited about this. I’ve actually had two Enjoy By series already. I had the 09.21.12 during my beer tour vacation to San Diego this past summer, and my cousin managed to get me a bottle of the 12.21.12. Both were absolutely spectacular. I will be picking up as many of these as I can.

Stone Vertical Epic Lunch

Sun, 23 Dec 2012 21:11:22 -0500

This past Saturday City Tap House and @PhillyStone hosted a special beer tasting lunch that sampled most of the Stone Vertical Epic series. Each year, Stone has created a unique take on a Belgian style that was meant for long-term aging, resulting in some exciting, rare beers. The first batch was the 02.02.02, and each advanced by a year, a month, and a day, up to the most recent, and final, batch 12.12.12. As one might imagine, these beers tend to be very hard to come by, so I couldn’t pass up this opportunity to try so many of them.

The lunch itself was a great time. The crowd was great, the food was great, and the beer was awesome. At the end of the night, they decided to auctions a growler of each of the 10 Vertical Epics and the Lukcy Basatrd, with the entire amount being donated to the Ronald McDonald house. We walked away with a growler of the 06.06.06.

Tasting notes and beer porn to follow.

1st Course: Lukcy Basatrd w/ Scallop Shrimp Ceviche w Serrano chiles

The 02.02.02 was one of the two vertical epics that we did not get to taste. Instead, the first course was paired with Lukcy Basatrd, which is a good, hoppy, malty amalgam of all of the Bastard beers. Good kick from the serranos in the ceviche, went very well with the hops from the beer..

2nd Course: 03.03.03 w/ Beef Taquitos

Belgian Strong Dark Ale. Deep copper color, warming, very malty, more Belgian yeast flavor emerged as it warmed.

3rd Course: 04.04.04 w/ Mushroom and Asparagus Salad

Belgian Strong Pale Ale. Amber color, lots of Belgian yeasty funky spiciness. The mushrooms were awesome.

4th Course: 05.05.05 Inspired Dark Chocolate Gelato

The 05.05.05 was the other vertical epic we didn’t get to try. Instead, we got this “05.05.05 inspired” palate cleanser. Crushed red pepper gave the chocolate gelato some late kick.

5th Course: 06.06.06 w/ Beau Soleil & Kumamoto Oysters

Strong Belgian Dark ale. Black in color. Trappist yeast lends a familiar spice, but there’s a lot going on. My first sip reminded me of red wine, later sips were more stout like.

6th Course: 07.07.07 w/ Lamb Meatball

My favorite so far. A nice hoppy, spicy saison. Very quaffable.

7th Course: 08.08.08 w/ Onion and Jalapeño Pepper Jack Quesadilla

Belgian IPA. My new favorite. Clear amber color. Belgian spice and some underlying sweetness balance the hops, which were pretty intense for a 4 year old beer.

8: 09.09.09 w/ Pastrami Burger on Rye

The pastrami burger was tremendous! The 09 is more stout-like. Not my new favorite. Black in color, very complicated, no one understands it.

9: 10.10.10 w/ Grilled Marinated Squid

Lots of citrus up front, with a detectable hint of white wine, decently hoppy. I’d rank it just behind the 07 and 08.

10: 11.11.11 w/ White Bean & Chorizo Soup

Strong malty backbone, with some good peppery notes. Sorry, 10, this is in 3rd now.

11: 12.12.12 w/ Crostini with Cheese

Cinnamon up front on the nose and the dominant flavor. It’s more in THE WIFE’s wheelhouse than mine.

UICollectionViews and NSFetchedResultsControllers

Fri, 21 Dec 2012 17:29:00 -0500

Anyone who’s hooked up a UITableView to Core Data is probably familiar with NSFetchedResultsController and its delegate methods. It’s a very elegant way to be notified whenever anything in your managed object context is updated, inserted, or removed, and it dovetails very nicely with UITableView’s interface for presenting updates. However, UICollectionView’s block based interface for updates breaks this 1:1 relationship. This is easy enough to get around, but I’m going to rant about it anyway.

NSFetchedResultsControllerDelegate methods look like this:

-controllerWillChangeContent: is called before changes are made
-controller:didChangeSection:... is called for changes to individual sections.
-controller:didChangeObject:... is called for changes to individual objects.
-controllerDidChangeContent: is called when all changes are complete.

This is exactly what UITableView’s updating methods look like. You call -beginUpdates: before changes are made, make individual changes to sections or rows, and then call -endUpdates: when you’re done. Easy.

UICollectionView eliminated the begin/end updates methods in favor of a block-based approach, -performBatchUpdates:completion:. This is generally the direction Apple has been moving since they introduced the block based UIView animation method, so I can understand their reasoning. Unfortunately, without an equivalent block based delegate method from NSFetchedResultsController, this requires the developer to jump through some extra hoops.

I originally found this blog post demonstrating how to implement a basic collection view, and made a few modifications to better suit my programming style. while I’m still slightly unhappy with having to add new instance variables to my class, I feel like this is a pretty elegant way of shoehorning the individual changes into the block call.

#pragma mark - NSFetchedResultsControllerDelegate

- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller {
    _sectionChanges = [[NSMutableArray alloc] init];
    _itemChanges = [[NSMutableArray alloc] init];
}

- (void)controller:(NSFetchedResultsController *)controller
  didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo
           atIndex:(NSUInteger)sectionIndex
     forChangeType:(NSFetchedResultsChangeType)type {
    NSMutableDictionary *change = [[NSMutableDictionary alloc] init];
    change[@(type)] = @(sectionIndex);
    [_sectionChanges addObject:change];
}

- (void)controller:(NSFetchedResultsController *)controller
   didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath
     forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath {
    NSMutableDictionary *change = [[NSMutableDictionary alloc] init];
    switch(type) {
        case NSFetchedResultsChangeInsert:
            change[@(type)] = newIndexPath;
            break;
        case NSFetchedResultsChangeDelete:
            change[@(type)] = indexPath;
            break;
        case NSFetchedResultsChangeUpdate:
            change[@(type)] = indexPath;
            break;
        case NSFetchedResultsChangeMove:
            change[@(type)] = @[indexPath, newIndexPath];
            break;
    }
    [_itemChanges addObject:change];
}

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
    [self.collectionView performBatchUpdates:^{
        for (NSDictionary *change in _sectionChanges) {
            [change enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop) {
                NSFetchedResultsChangeType type = [key unsignedIntegerValue];
                switch(type) {
                    case NSFetchedResultsChangeInsert:
                        [self.collectionView insertSections:[NSIndexSet indexSetWithIndex:[obj unsignedIntegerValue]]];
                        break;
                    case NSFetchedResultsChangeDelete:
                        [self.collectionView deleteSections:[NSIndexSet indexSetWithIndex:[obj unsignedIntegerValue]]];
                        break;
                }
            }];
        }
        for (NSDictionary *change in _itemChanges) {
            [change enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop) {
                NSFetchedResultsChangeType type = [key unsignedIntegerValue];
                switch(type) {
                    case NSFetchedResultsChangeInsert:
                        [self.collectionView insertItemsAtIndexPaths:@[obj]];
                        break;
                    case NSFetchedResultsChangeDelete:
                        [self.collectionView deleteItemsAtIndexPaths:@[obj]];
                        break;
                    case NSFetchedResultsChangeUpdate:
                        [self.collectionView reloadItemsAtIndexPaths:@[obj]];
                        break;
                    case NSFetchedResultsChangeMove:
                        [self.collectionView moveItemAtIndexPath:obj[0] toIndexPath:obj[1]];
                        break;
                }
            }];
        }
    } completion:^(BOOL finished) {
        _sectionChanges = nil;
        _itemChanges = nil;
    }];
}

With the updated dictionary and array syntax, this code looks a little dense, so the high level idea is there are two mutable arrays, _sectionChanges and _itemChanges. As individual changes come in, each one is converted into a dictionary with an NSNumber representation of the change type as the key and the index path to change as the value. That allows you to simply loop through your arrays in -controllerDidChangeContent: and make all the updates at once. I also feel that setting the arrays to nil in the completion block as opposed to simply removing all objects might be safer if new updates are ever sent before the change block is executed.

I would expect Apple to add a new delegate method to add a block based callback to NSFetchedResultsControllerDelegate in a future release; hopefully, along with an updated UITableView that supports batch updates.

One Night Only! on Flickr.I’m going to be drinking this...

Thu, 20 Dec 2012 19:18:52 -0500

One Night Only! on Flickr.

I’m going to be drinking this Unibroue La Fin Du Monde tonight at midnight to toast our universe imploding/poles reversing/meteor/earthquakes/birds/snakes/aero planes demise with a thematically appropriate beverage. Unfortunately, I don’t have any Fin Du Monde glasses, but I do have two Unibroue glasses featuring Ephemere and Blanche de Chambly. I hope the Mayans don’t mind.

Xcode LLDB Tutorial

Tue, 18 Dec 2012 11:19:59 -0500

Xcode LLDB Tutorial:

This is honestly one of the most helpful posts I’ve read in a long time. I had no idea how much you could do with breakpoints in Xcode.

My nerd merit badge came in!

Fri, 14 Dec 2012 19:08:17 -0500

My nerd merit badge came in!

cocoaheads: Xcode in a Nutshell

Mon, 19 Nov 2012 08:21:27 -0500

cocoaheads:

Xcode in a Nutshell

JICoreDataOperation

Thu, 08 Nov 2012 10:14:00 -0500

JICoreDataOperation:

Current best practices for using Core Data include performing as much of your work in a background thread as possible, and I’ve always preferred using NSOperation subclasses to encapsulate units of work to using GCD and blocks. Since it always seemed like I was implementing the same NSOperation subclass every time, I decided to consolidate my work into a simple NSOperation subclass and open source it.

JICoreDataOperation uses ARC and the parentContext property on NSManagedObjectContext, so it’s not appropriate for use in iOS projects targeting 4.3 or older, or Mac projects targeting 10.6 or older. Subclasses of JICoreDataOperation just have to specify a parentContext and implement the doWork method to get up and running.

thedrunkenmoogle: Meet Me at the Barby efleck

Wed, 24 Oct 2012 14:48:05 -0400

thedrunkenmoogle:

Meet Me at the Bar
by efleck

I’ve never seen so many firkins! (at Pratt Street Ale...

Sat, 20 Oct 2012 17:00:18 -0400

I’ve never seen so many firkins! (at Pratt Street Ale House)

Baltimore Beer Week’s Real Ale Fest (at Pratt Street Ale...

Sat, 20 Oct 2012 14:55:55 -0400

Baltimore Beer Week’s Real Ale Fest (at Pratt Street Ale House)

1st week at Comcast went pretty well, I guess.

Fri, 19 Oct 2012 17:55:48 -0400

1st week at Comcast went pretty well, I guess.