Rethinking My Music Storage

I’m not a huge music collector, at least not compared to some other people I know. I do have about 150 GBs of music in my iTunes collection — lots of it being video game soundtracks I enjoy listening to while I program.

A few things I have not liked about my historic setup:

  • Because the collection was 150 GB I could not store it on my main computer’s SSD (which was 256 GB in size).
  • iTunes sucks. I don’t want to get into details here but as a music player and organization tool it’s awful.

Some goals for my new setup:

  • I want to get rid of iTunes.
  • I’d like to store my music on Dropbox, preferably in a way where I can control which Music (if any) gets synced to my other Dropbox setups.
  • I have recently become a Spotify member. It’s got a nice collection I feel I can lean on AND it has some tools the player UI to support local files as well as streaming songs which I think will be key.

With all that said, what I’m up to:

First thing, I made a new iTunes library on my desktop and have started re-downloading my old iTunes music purchases. I have lots of music that is still DRM wrapped and these new downloads do not have such DRM.

Next, I’m going to slowly start to put the music into Dropbox. I’ll have a root level Music folder but inside I’m going to split the collection into Rare and Common. Common being for songs that are streamable from Spotify and thus being a folder I can selectively NOT sync on my other computers. The Rare folder will have all of my video game soundtracks and other albums I find to be incomplete or missing on Spotify. As I said, I like how Spotify can bring in local music into playlists and even lets you control the source folders and I’m hopeful this will work nicely.

We’ll see how it goes over the next few weeks. I’d love to hear if anyone else has an exotic setup like this.

Also, next up for a rethink is photos. Again, I’m really not happy with the current Apple solution and am thinking of alternatives. Feedback welcome.

Dongle Emotions

After letting my bedroom / office get out of hand, I took some time today to clean up and get organized. I wrapped and grouped up my wires and even opened up some of the new USB3/Thunderbolt3 dongles I had ordered to go along with my new MacBook Pro order.

Now I don’t want to get into the current dongle drama surrounding the new MacBook Pro — but I do have a funny story.

A few years ago I worked as a self-employed contractor doing iOS work. I was at a meeting with a new prospective client. Overall the meeting went well and it looked like we’d be working together. At the end I was packing up all my gear and there was an accusation that I had taken their projector dongle. I was fairly certain I was in the right and this was a dongle from my laptop bag but did I really want to risk this multi-month contract for a $30 dongle? It was something out of a Seinfeld episode. Suffice to say, I left the dongle with the client that day to ease tensions.

Don’t mess with another man’s dongle.

These days I mark all my dongles (and I need a ton of them as a traveling instructor not knowing what a room will have) with “ZORN” to alleviate confusion.

How We Record Talks at Philly CocoaHeads

I came across this post from Rico Jones on how he records the Portland Ruby Brigade’s monthly meetings and thought I’d do something similar for how we record the Philly CocoaHead presentations.

Capture Setup

Why Only Main Talks

This first thing I’ll note is we do not record the entire meeting. Early on this was to due to the experimental nature of our recording setup but more recently, at a leadership meeting, we made the call to continue to only record our “main talks”. We do this for a few reasons:

  • Not recording the “show and tell” talks lets those be a little bit more free-form, with less pressure on the presenters (which is a big reason why they are in the agenda).
  • Many of the show and tells are in-progress app demos, and so there is benefit to keeping them non-public.
  • We expect a higher level of preparedness for the main talks, and to ask for people to put that much time into a talk, it would seem wrong not to capture it.
  • If the whole meeting were being captured / broadcast it would encourage people not to come.

The Setup

Starting from the presenter’s laptop we provide an HDMI cable. If they want to present or demo from an iOS device we have an HDMI to Lightning adaptor.

The HDMI cable then feeds into our capture device, an Elgato Game Capture HD. This device is targeted at the streaming game market but is just as viable to capture normal HDMI signals. The device itself is an HDMI passthrough with no frame drops or anything. The device is even powered through the USB cable so no need for a power cord. The video / audio is then compress into mp4 (on device using hardware encoding). The compressed signal is sent to a Macintosh running some custom Elgato software. I use an older Macbook Air to act as our dedicated capture computer. While there are many other features for dedicated streamers, we simply press record.

We then take the other end of the HDMI cable and route it to our projection system. Now the Apple Store that hosts us has a very impressive setup but sadly it’s not as easy as it should be. They have an HDMI connection, and while it works for the Apple TV it doesn’t register when we plug it into a Mac. To get around this we used to use an HDMI to DVI adaptor and the alternate DVI input. It worked fine but doing it this way lost the audio. Recently we’ve fixed this by buying a converter box that splits the HDMI into both DVI and an audio jack. Again, the Apple Store does have a in-house roof speaker system but for us sadly it’s been down. In the interim we’ve been getting by with a Beats Pill Speaker the Apple Store is nice enough to provide.

While not part of the capture, I will give a friendly nod to Fin, an iOS performance timer we run on an iPad mini to help the speakers know how much time they have left. Works great.

I’ll also recommend the presenter remote I use. It’s a Kensington, with a nice simple to use USB dongle that slips into the remote when not in use. It has a laser pointer too but I can’t say I use it much. Battery life has been very good for this device.

So that captures the video and audio from the presenter’s laptop or device but what about the speaker’s voice? For that we use a lapel clip on mic and Digital Audio Recorder. The recorder can work without the mic if you are looking to capture a room discussion but for 1 person, adding the mic is a real quality difference.

After the meeting we combine the video and audio captures using ScreenFlow. Editing is fairly simple for most cases, usually as simple matching up the action and adjusting some audio. The finished product is exported and then uploaded to Vimeo Pro, which acts as our library of sorts. (We pay for Vimeo Pro to keep ads out and to make sure we have API access.) People can watch the talks through Vimeo itself or our new Apple TV app, “PhillyCocoaHeadsTV” (search for “CocoaHeads” on the TV).

Future Improvements

Overall I’m pretty happy with the current setup but I do have some ideas:

  • It would be nice if we could get the Apple HDMI connection to work, that would simply our wires a bit.
  • At work we use a Catchbox to help capture Q and A. It would be nice to work out something similar for us.
  • While it might save a bit of editing time to convert to a wireless mic, it’s pretty low on my list. Would have to improve some other aspect to make it more worth while.
  • There is a lot of equipment to carry in, setup and carry out. It’s very reliant on me personally at the moment. I’ll probably be missing a meeting or two this year so I hope to train someone else to run this while I’m gone.

Hope you enjoyed my rundown. If you help capture stuff like this and have any tips or tricks, let me know. Thanks.

Xcode Shortcut: Quick Open in Assistant

This answer / revelation caused a bit of a stir in the Philly CocoaHeads Slack so I figured I’d share it here as well.

Lots of people know and live by Xcode’s Quick Open Menu. You hit Command-Shift-O and start typing the name of a file, a class or a method and have some very good options made available to you. Make a selection, hit return and bam, the file is now live in your editor.

But what about the assistant editor? Historically some of the best uses for the assistance editor was to view a file’s counterpart file, the header for an implementation file and visa-versa. With Swift’s lack of a header files, some people have come to put use the assistance editor of test files.

Regardless as to what you want in the assistant editor it’s always been a little clunky to pick the file. Well now you can use the Quick Open menu for this too, and it’s oh so simple.

Hit Command-Shift-O and make your selection as normal. Instead of hitting Return, hit Option-Return — the file will now open in the assistant editor pane, opening it if need be.

Quick Open in Assistant in Action GIF

That’s all there is to it. It’s a small feature but very handy for those trying to stick to their keyboard and avoid the mouse while moving around in Xcode.

For a handy Xcode 7 Shortcut Reference Card check out the Big Nerd Ranch iOS Course Resource repo for a PDF download. You can also get the card in print by ordering our latest edition of iOS Programming, 5th Edition — updated for Xcode 7 and Swift 2.

PS: Props to @lyricsboy for catching my typos!

Philly CocoaHeads: History

Being the lead organizer of the Philly chapter of CocoaHeads, I always welcome the opportunity to chat with members of other meetups. It’s great to compare notes on how we run our groups, what’s worked and what’s failed. In particular I’ve recently chatted with the leadership of the Nashville CocoaHeads and was also able to attend an Atlanta CocoaHeads meeting while visiting Big Nerd Ranch. It was a great experience and has me inspired to capture some of my thoughts here on the blog. This first article is a walk down memory lane to document the history of Philly CocoaHeads.

Getting Started

The Philly chapter of CocoaHeads started out of IndyHall in 2008. IndyHall is a coworking space, a place for people who can work from home but choose not to; perhaps because they want a work/home separation or just to participate in the greater creative community. Back then IndyHall was still fairly young but had attracted together a strong tech following including:

  • Andy Mroczkowski and Far McKon who were working for the local company Neat, and their Mac software / scanner combo.
  • Jason Allum who was working on RipIt (which would later be sold to The Little App Factory).
  • Dave Martorana who had a few apps, including MultiFirefox and Multiplex (a media server app ahead of its time).
  • Joah Aas, who worked for the Mozilla organization and is now most known for his help with the Let’s Encrypt project.
  • Randy Zauhar, a local professor teaching Bioinformatics and Chemistry at University of Sciences. Randy had previous help run and host a group called: PHAD, Philadelphia Apple Developers.
  • And myself. I was a basic IndyHall member and was working on ProfitTrain updates at the time.

Philadelphia Apple Developers (PHAD) never grew to be anything very large but I remember it fondly. It would usually be about 4-6 of us sharing a pizza and showing each other our Cocoa projects. I vividly remember Randy showing off his spreadsheet app which listed chemical equations on one side and then had an OpenGL cell rendering the compositions on the other. I also remember doing talks on Subversion and then Core Data. Again, they were small meetings but having even a few people who were interested in or working in Cocoa back then to bounce ideas off was a huge win.

The early meetings of our group were ran by Andy Mroczkowski and actually marketed under the name PhillyCocoa and not CocoaHeads. The meetings were very demo heavy with lots of roundtable questions and discussions filling in the cracks. Some members took to working on a side project, a calculator, outside of the meeting. The project didn’t get too far but the remanence of it have been preserved on GitHub.

Early IndyHall

This is a photo of IndyHall, Strawberry Street Edition. The first “CocoaHeads” meeting was held in that back meeting hut.

As the iOS SDK (or iPhone SDK as it was called back then) was announced there was a serge in new members and interest in the group. The biggest hurdle seemed to be Objective-C itself so we planned and ran a workshop.

Over two Saturdays, mixing lecture time and coding exercises from Learn Objective-C on the Mac, by Mark Dalrymple, Scott Knaster we got 12 or so people a head start on iPhone programming.

New Leadership

Meetings continued, now at IndyHall’s new home on 3rd Street (or N3RD Street as it would come to be known as). Eventually a December meeting was announced and Andy let it be know that if you were interested in the future of PhillyCocoa to attend. At the meeting Andy announced his upcoming departure to head to San Fransisco to be apart of a startup. Two volunteers came forward to help organize the group in his stead, myself and Mike Deaven.

Meeting Format Changes

Over the next year me and Mike enacted a handful of changes we’d hope improve the group.

An Early IndyHall Meeting

One immediate change we did was move the website to WordPress. Previously Andy had a custom Ruby CMS / publish thing going and it wasn’t easily portable. I was able to get all of the old post converted into WordPress. The main goal here being enable multiple people to post and not have the code be machine dependent.

Another change was subtle, but I started to embrace the CocoaHeads brand in our naming and introductions. I always was aware of them and to me it seemed helpful to take the name and have our chapter listed on the main global site.

We also started to fiddle with the meeting format itself. Moving the pizza / social time to the front end of the meeting. This helped since we usually had a lot of stragglers arrive between 6:30 and 7:00, so by having the pizza upfront we could make sure to start the meeting with everyone present.

I also started to be a little more rigid in the introductions, making sure to repeat the basics of the group, who we were, what we did, when we met. I wanted new people to quickly get a sense of expectations.

Another IndyHall Meeting

The hardest thing back then was getting people to do talks. There were many meetings in the early days where we did not have a formal speaker and so it was on my shoulders to build a presentation to keep the group entertained. It was a lot of work but I think a major reason why we were later became more successful. I think it’s incredibly important to be consistent, to have that meeting every 2nd Thursday no matter what. Setting up that pattern and not giving into canceling meetings really helped solidify the group.

To help spur talks we started to request smaller commitments, show and tell time. A short talk or demo usually 5-15m in length. Much less to prepare and much less anxiety. It started slow but eventually kicked off a pattern of people coming forward to do talks, even “main” talks.

Adding Members through Meetup.com

Up to this point Philly CocoaHeads did not promote itself too much. You heard about it through word of mouth or via IndyHall announcements. Looking to grow the community we decided to join Meetup.com for more exposure. It took a few months to get going but eventually started to bring in tons of new faces. Meetings quickly grew from about 10-12 people, closer to 20-25.

As of today we have about 870 registered members on Meetup.com. Now most of them are not active members. I’d guess if you defined “active” as participated in a group event sometime in the last 12 months, you’d probably end up with ~200 members.

Alfie joins us from NY via a Double

Alfie joins us from NY via a Double.

New Events and Expanding the Leadership

When iOS 7 was announced we decided to do a special hack day to celebrate. We sold tickets to help buy a nice catered lunch and gathered at IndyHall on Saturday to hack on new iOS 7 APIs. The event was a huge success.

One newer member wanted to help do this more often and so Tom Piarulli joined the leadership to help run what has now become known as Side Project Saturday. SPS is typically the last Saturday of the month, starting at 10am and running until about 5pm. People come and go, work on their side projects, ask questions and otherwise socialize with their fellow geeks.

Tom at a SPS right after the WWDC announcements.

At around the same time the leadership also welcomed Kotaro Fujita to help run our website and Twitter account.

Kotaro talks about his favorite tool.

Moving to the Apple Store

We are fortunate enough to have a very nice Apple Store here in Philadelphia. Sometime in 2013 I was approached by the business relations manager from the store. He came to a few meetings and introduced himself. He was really impressed with our group and offered to help us out and possibly host the meeting.

I was kind of torn. We had our start at IndyHall and while we were definitely starting to outgrow the space I didn’t want to leave. Me and Kotaro took a trip to the Apple Store to checkout the Briefing Room. The room is incredibly nice. It’s on the second floor of the store, not open to the public. It’s kind of a VIP area for larger demos and meetings. It had 5 mounted TVs, all wired up for AirPlay and sound. A huge wood table with 16 swivel chairs but plenty of space around the edges for fold up chairs. Fully laid out we could host 40-45 people and have a great AV setup to help support the speakers.

We made the move in November 2013 and it’s worked out great. The space is extremely accommodating and many of the members certainly enjoy the prestige of getting to meet in such a private venue.

Apple Store Meeting

Workshops, Suburb Side Project Saturdays, and CocoaLove

In 2014, Curtis Herbert who had already been very active in the community as well as doing some talks for us joined the leadership team and started multiple new projects.

Curtis teaching his ObjC Workshop

Firstly was CocoaLove, which started out best as I can recall as friendly outburst during my “Industry News” section while reviewing upcoming conferences. “Why don’t we have any conferences here in Philly?” — and so it began. CocoaLove is not an official child of CocoaHeads but we obviously share a lot of the same goals.

Curtis also helped spur new educational events we came to call Workshops. Typically one day, 5 hour events with paid for tickets (most money going to the speaker to help compensate them for prep time). We ran about six or so over the last year and a half, covering introductions to Objective-C and then later Swift, App Marketing, UX design, and more. Workshops are incredibly loved by our members and sell out quickly. The hardest part about running them is the custom content creation. We have some ideas on how to improve that moving forward and hope to offer more Workshops in the year ahead so stay tuned.

Marketing Workshop

And finally we have our “Suburb” edition of Side Project Saturday. The city of Philadelphia is very flat and wide, with an extended suburban layout. We have many members who live outside the city and can not always participate with our center city events. To help, we started running a “Suburb” edition of our Side Project Saturday event. These are held at the Apple Store in King of Prussia. We’ve been able to host a few and hope to do more. Again, Curtis has been very helpful in organizing this.

Videos

In 2015 we continued to evolve and expand what we offer, this time with recordings. We’ve been talking about recordings for awhile but in 2015 things started to fall into place. I’ll go into detail as to how we record in a future blog post, but put simply it’s capturing what video we pipe to the monitors and then using a lapel microphone for the speaker to capture their voice. After the meeting we match the two together and then publish to Vimeo. During the fall we also added a custom AppleTV app which streams the content as well (search for “CocoaHeads” and you’ll find it).

Video Capture Setup

Apple TV App

Book Club

Another new endeavor for 2015 was the Book Club. We started it over the summer reading through Cocoa Programming for Mac OS X and then restarted it this winter with HackingWithSwift.com. Book Club basically has members work through chapters and then meet online to discuss how it went. Over the summer we met every other week, while the winter edition has been more aggressive doing it every Monday. A big thanks to Michael Mayer for helping to run the latest Book Club season.

The Future

So it’s 2016 and things continue to look good. I’d say the biggest problem we have is that we occasionally max out of room occupancy at the Apple Store but not enough to really justify a new venue. We also recognize our website could use a lot of work to meet our high standards but it remains a fairly low priority overall.

As the main organizer I’m extremely lucky to have such great support from the members and the rest of the leadership. There is no way we could do this much work if it wasn’t for the many volunteers we have. I’m extremely proud of the community we’ve made and continue to run.

Recommendations

To those running similar meet ups a few closing recommendations:

  • Be consistent with meeting dates and locations.
  • Be willing to do a lot of personal presentations and/or MC of roundtables when other speakers are not available in the early days.
  • Don’t be afraid to shake people down for talks. Also remember it’s much easier to get them to sign up for a talk a few months from now than in a few weeks. Take advantage of that.
  • If meeting after work try to have some food and drink available. We do pizza cause it’s relatively cheap and easy. You want to feed them but remember they aren’t coming for the food. In the early days a donation jar can usually cover most of the costs, later you might need sponsorship. I’ll have more to say on that in the future.
  • Help spread the responsibilities. Even smaller things like handing the food, taking meeting notes or running the group Twitter helps turn “the group” into “our group”.
  • Have fun.

Staying Secure on OS X with a Few Unsigned Apps

I could get into some real heavy talk regarding Apple’s policies about installing software outside their stores (and maybe I will someday) but for now let us all be thankful that not all Mac software must come to us through Cupertino. Let us also be thankful for Gatekeeper, a nice compromise Apple offers.

With Gatekeeper, Apple allows people to distribute Mac software outside the store but requires it be signed with an identity registered with Apple. The general idea being if a developer gets marked as distributing malware Apple can blacklist them so as to not effect users in the future. I’m not aware of any honest developer being wrongfully blacklisted and my general understanding is that the program is working well with known limitations.

OS X ships with a nice safe default via Settings > Security, “Allow apps downloaded from:” set to “Mac App Store and identified developers”. Unfortunately even though Gatekeeper has been around since 10.7 there are some apps that are not signed nor will never ever be signed that you want to run. Most users will sadly turn off the Gatekeeper check entirely at this point, leaving their system vulnerable. Below I’ll walk you though how to allow a unsigned app to run while leaving the security setting as-is.

By default OS X ships with the setting set to “Mac App Store and identified developers”.

default settings

When you try to open an unsigned app you’ll get a prompt like this:

prompt

Click OK and then go back to System Preferences and you might notice the pane has changed:

Open Anyway option

Now you can choose to “Open Anyway” for the last app blocked by Gatekeeper. Go back and try to launch the app again. You’ll get a final prompt asking if you sure, and upon clicking Open you’ll be able to run you unsigned app while still maintaining the default security setting.

Last check

While a little tedious jumping back and fourth for the initial approval, I’d much rather do this and leave Gatekeeper on than to run without the identity check. I highly recommend you do so too, and if you can, maybe a friendly email to your app developer asking him to sign his app.

UPDATE: Was informed by @boredzo and @ abrahamvegh that there is a shortcut to this flow if you anticipate the app requiring approval. For example, if you download an app you know will need this special exception you can control-click it and choose Open from the context menu. Doing so will cause a similar prompt that will whitelist the non-signed app and allow you to run it without turning off Gatekeeper. Thanks for the extra info guys!

How To Play WWDC Sessions at 2x Speed

Now that all the new bits of iOS 9 and OS X 10.11 are in the wild you might find yourself wanting to get up to speed on some of the changes. One great resource to help you get started is Apple’s WWDC videos.

The WWDC video library has a lot going for it: HD and SD video sizes, slide downloads and now even full text search! The only real negative thing is the sheer amount of content out there. It can get overwhelming and time consuming to watch all the stuff you are interested in. Here’s the hint. Like podcasts, WWDC videos are mostly single voices speaking one at a time and if you have the tools to double the playback speed you’ll find them still very comprehensible.

Now for the tools. For downloading you can of course use the Apple website. I like this WWDC Mac app as well. Once you have the video file on your hard drive you’ll unfortunately need to look for something beside the built-in QuickTime player to help. Even with all its enhancements it sadly doesn’t have this tool of QuickTime’s past. The good news is you can still download QuickTime 7 and it works great!

After you open your movie in QuickTime 7 (you’ll find it installed in the Utilities folder), use the Window menu and choose Show A/V Controls. In this panel you’ll see a slider that let’s you adjust the playback speed.

QuickTime 7

Now you can watch your chosen WWDC videos in half of the time! Enjoy!

UPDATE: My thanks to Paul Brown who let me know that the native QuickTime player can playback faster, even if it is a little hidden. To increase playback speed, bring up the controls with your mouse, then option-click on the fast-forward control. This will increment playback speed by 10% each time you click. You can keep clicking this up to 2.0x playback speed but sadly the audio does not work at 2.0x, you’ll have to limit yourself to 1.9x to retain the faster audio. Thanks again for the help Paul!

Quick Launching for Cocoa Unit Tests

I was doing some proofreading and research today regarding the latest testing features in Xcode 7. In the process I ended up rereading this article from Mark Dalrymple on code coverage. It’s a great article but it also reminded me of a little tip I wanted to share on the blog.

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    ...
    // bail out early if we're running as a test harness.
    if (NSClassFromString(@"XCTestCase")) return YES;

    // otherwise load the main storyboard.
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil];
    UIViewController *vc = [storyboard instantiateInitialViewController];
    ...
}

Not only can this type of check help speed up your unit test times by a little bit, but, it also makes sure you aren’t loading things like crash log capture tools, performance monitoring injections, or other things that might otherwise interfere with your unit test logic or code coverage numbers. Now if you are doing the new UI testing you’ll probably have to use some other kind of flag to define this path, but regardless the core idea is the same.

Code Patterns Talk, Video Now Available

We’ve been trying to a better job of capturing our main talks at Philly CocoaHeads. You can find and subscribe to our small but growing collection of videos on Vimeo: https://vimeo.com/phillycocoa.

I did a talk last month reviewing a some iOS code patterns. The runtime is about 27 minutes. Feedback very welcome.

Some Code Patterns, Mike Zornek from Philly CocoaHeads on Vimeo.

This talk covers a handful of code patterns that were successful on my recent projects. Some of these patterns include Block Safety, "Tell, Don't Ask", Using DataSources for your network-based *Service objects.

Apologies the audience participation isn't well captured.

Think of the Smallest Possible Code Change, and Then Make It Smaller

I’m working on a client project right now. We do peer review of the code via pull requests. It works great, but the quality of the reviews you get are very dependent on the size of the pull request you make.

Take for example, one of my recent pull requests, which had the following git characteristics:

1,780 additions 
1,618 subtractions
24 files changed

Not my largest pull request ever but still way larger than what I’d prefer. I got zero feedback. It was merged on first pass. Now take one I did the next day:

80 additions
1 subtraction
7 files changed

We had 10 conversation posts on this pull request, discussing three distinct recommendations and/or questions. Questions on things I was already doing for a few pull requests already but I guess slipped by.

I don’t blame the reviewer, I blame myself. It’s really hard to be detail focused when there is so much to review.

So keep those pull requests small and focused. You’ll get better feedback and you’ll probably get integrated faster too!