Category Archives: Objective-C

Are you a Developer or an Engineer?

Posted on by

Last month my boss, Daniel Pasco, posted this thought on Twitter:

developerEngineer

Developers focus on making great code.
Engineers focus on making great things.

This really struck a chord with me. I have observed a few behaviors that I didn’t really have any context to express and I feel like this quote sums up a lot of things that trouble me about the programming community.

Hipster Coding

“Nobody goes there anymore. It’s too crowded.”
– Yogi Berra

I went back to school in earnest to learn programming in 2012. I wasn’t sure what I wanted to do, but I knew I wanted to find whatever would work best for me in the long run. I initially went for Java because I knew there was a lot of demand for it, but I didn’t realize there was also a lot of supply and it was difficult to find an entry level Java job because most of them demanded 3-5 years of experience. I couldn’t break through the layers of bureaucracy and I just stopped trying.

I initially got involved with the Ruby community. I knew a lot of people who were active there and it seemed like it was the new up and coming thing.

I would talk to people about how to get into Ruby and I would be asked what open source projects I worked on. I didn’t really understand open source and would ask for help about how to get into open source. Their looks would immediately change to a combination of disdain and pity and they would stop talking to me because I wasn’t a contributor.

I struggled with this a bit trying to break into Ruby, only to discover that all the people who had been doing Ruby had moved on to Clojure. Then they moved on to Haskell. I think they were interested in Swift for a bit, but I have lost track of whatever the new hot language is. Might be Go…

I think a lot of people feel like they missed out on the Gold Rush of the iPhone. I know that I do. By the time I started taking iOS programming classes in 2012, the whole point of having an app out on the store was to use it as a resume builder to find an actual job. We were being prepared for the world as it exists now/over the next few years where there is less contracting and more enterprise development.

I feel a sense of chasing after something that doesn’t exist anymore. We still have the dream of writing a killer app and making mad bank, but that is growing more and more difficult. I feel like any time Apple releases a new piece of hardware, like the Apple Watch or the Apple TV, people feel like they need to immediately mark their territory on it because they think that if they get there first, they can strike gold and move on before everyone else gets there.

This has created a situation where we have platforms that seem to be abandoned by developers because there is something newer and shinier that has come out and everyone wants to be the first one there.

I Have a Screwdriver and Everything is a Screw

My introduction to programming was back in 2008. I was kind of loafing around unemployed because I had no idea what I was doing with my life. My dad would take me to work and I would go and hang out with the weird IT guy. My nickname for this guy was Jesus because he looked like Jesus if Jesus wore a shirt and tie.

He was really into programming and told me that learning programming was a valuable skill. He set me up with a book and a laptop in the corner. He showed me where the Terminal was and taught me how to write code in TextEdit and compile it on the command line.

All of this was done in Perl.

The book he gave me was the Llama O’Reilly book from I think 1998. He told me that the language was stable and didn’t change, so it was okay that the book was old.

I started telling people that I was learning Perl and I got horrified looks from people telling me no one uses it anymore. I was told to learn PHP because that was the future.

I talked to Jesus about that, and he told me not to bother learning PHP because everything that I want to do I can do in Perl. Perl does everything.

Replace “Perl” with “JavaScript” and that is exactly what we have now for a fairly large portion of the programming community.

I am not going to get into an argument about whether JavaScript is “real” code or not. That isn’t the point I am trying to make. JavaScript is a tool. It has its uses. If I want to write a website, I can’t do that in Swift with the Cocoa frameworks.

What worries me is that I see a lot of people treating JavaScript the way my friend Jesus treated Perl. It’s the thing they know, so they want to make it work for every single possible thing that exists.

There was a great blog post I read recently saying that the state of web development is static right now. Large companies like Yahoo are basically rewriting their websites over and over again in whatever the new hot JavaScript framework is.

I think I read recently that someone created a framework on top of JQuery, which is it’s a framework on top of JavaScript. I think someone tried to create a JavaScript framework to do server back end work. It’s a web language! It was designed to do one thing and one thing well. It’s being convoluted into weird, abstract shapes because people don’t want to learn new things.

Fleeting Fame

fleetingFame

“ObjC culture carriers were people who’d been building products for years using it. Swift culture carriers see a chance for fleeting fame.”
– Graham Lee

When Swift first came out, there were a lot of prominent members of the programming community that were incredibly anti-Swift. They had invested 15 years in Objective-C and saw no reason to pick up this goofy new language and get knocked back the the beginning of the board with everyone else.

A lot of us scoffed at these people and told them to get with the program because Swift wasn’t going anywhere.

It’s nearly two years later, and we’re now seeing that a lot of these people have come to terms with the fact that this language isn’t going anywhere.

This doesn’t mean that they are sitting back and figuring out the language. On the contrary. Many of them are just as loud and opinionated about it as they ever were, but now they’re actually trying to use it.

I have noticed a shift in the last six months or so where the people talking about Swift aren’t the early adopters who were coming from Haskell backgrounds who wanted to share their functional programming knowledge. Instead, we’re getting people who feel like they need to have an opinion about Swift to feel important.

Lots of people want to post tirades about how Swift should be done. They don’t want to listen to people who have been working with it for the last few years. That defeats the purpose. They want to be the one who can go and write a convoluted piece of code to break the compiler and have everyone tell them how clever they are.

A lot of the sense of community that I felt back when we had Objective-C has evaporated. Back then, new people could enter the community and have seasoned professionals give them a hand with understanding things. Now, everyone feels like they have to establish themselves as an expert and no one is willing to ask actual questions that would make them better Swift programmers. Their shouting is drowning out everyone else’s thoughts and opinions and making it even more difficult for beginners to actually learn Swift.

How We Should Be Doing Things

I worked for Brad Larson for a year. We spent that year porting a legacy code base from Objective-C to Swift. There were two important reasons for doing this:

  1. The code base was fragile and at a point where we could not go in and add or change anything without breaking it.
  2. There were problems that we had encountered over the years that would not have happened if we wrote the code base in Swift.

There was a point when I was working with Brad where he showed me this crazy code that was full of functional programming stuff. I felt very depressed because I didn’t think I could ever come up with something that interesting or complex. It bothered me, so I kept talking to him about it.

After doing this for a while I figured out the right question: What problem is this code solving?

When he started to tell me about how unsafe our previous code was because of the constraints of Objective-C. He had spent years trying to figure out a better solution for his problem and he understood what needed to be done intimately.

Brad is an engineer. He didn’t set out to use all the new toys in Swift because he was looking for an excuse to use them. He had problems he needed to solve and wanted to find the most elegant way of solving them. That solution just happened to include a lot of functional programming concepts. I think he actually rewrote the code a few times because he realized there was a better way to solve the problem.

Code exists as a tool to solve problems. It isn’t an end in and of itself. You can write the most insane Rube Goldergian piece of code imaginable that will work, but why bother?

Writing an app or an open source framework or anything is a little like adopting a puppy. It’s a long term commitment. I don’t think that the people who released the first apps for the iPhone realized they might be on the hook for supporting them for close to a decade. No one anticipated that.

Now that we have a better understanding of that, it’s important to spend time thinking about what your app will solve and how to maintain it long term when it stops being cute and starts peeing on your floor.

One of my goals this year is to release an app. I have done other projects like books and talks, and as such you can take what I say with as many grains of salt as you want. I have been hesitant to produce anything because I worry about the long term maintenance of what I am doing. I know I should just put something out there and learn from my mistakes. We’ll see.

I want to find one, solid piece of functionality that I want to see out in the world. I want to start with whatever the smallest bit of that is and work out from there. I want to keep the scope small and make sure that each piece works and can be built off of to add functionality.

I know that I want to be an engineer. I want to solve problems. I don’t care if no one buys my app or if it is just a tree that falls in the woods where no one can hear it. I just want to know that designed and implemented something well. The problem I need to solve right now is getting over my fear of fucking up and to just do something.

We Didn’t Start the Fire(Wire)

Posted on by

I have written about this before, but at my current job my boss and I are rewriting our robotics control software in Swift. This is an excellent blog post here that explains why we are doing this.

This is the camera setup we have on our robotics systems. Cameras help with dispenser positioning and we support both video and image capture for our users.

This is the camera setup we have on our robotics systems. Cameras help with dispenser positioning and we support both video and image capture for our users.

There have been a few projects we have open sourced after implementing them in this project. This blog post details the most recent project we have completed and open sourced, which was to write a wrapper class allowing us to connect to an external camera that conforms to the IIDC standard. This project can be found here.

Cameras are an important feature in our robotics systems. Users use the camera to help position their dispensers and to capture media. Videos and images of the dispensing process have been used in papers and documentation of scientific research, so continuing to support this functionality is vitally important.

What is the Goal?

Back when the code was initially written in 2007, AV Foundation and GPUImage did not exist. There was not really an easy way to hook up an external camera to an application. Additionally, the standard for rapid data transfer at the time was Firewire.

The fact that there were no easy solutions meant that our code was overly complex. There were much easier ways to connect to a camera and run the video through a filter that we simply couldn’t implement because our code touched too many other things. We set out to simply the code in our rewrite.

One major goal of this project was to make it easier to add additional cameras while still supporting the legacy cameras out in the field.

Since this company has been around for over a decade, we do have legacy hardware out in the field that we still need to support. Currently we have three different kinds of cameras out in the field associated with our robotics systems: Unibrain, Point Grey Flea2, and Point Grey BlackFly. At some point in the next year or so we will need to support a fourth camera because our current camera, the BlackyFly, has been discontinued.

What is IIDC 1394?

IEEE 1394 is a serial bus standard for high speed, real time data transfer. USB is another serial bus standard that is more widely adopted because IEEE 1394, aka FireWire, was proprietary to Apple.

Our first camera type, the Unibrain camera

Our first camera type, the Unibrain camera

Even though FireWire ports are no longer available on Macs being sold today, there are still many cameras that conform to the IEEE 1394 standard. Our current Point Grey BlackFly cameras have a USB 3 plug but they conform to the IEEE 1394 standard.

IIDC is the FireWire data format for live video. In order to be able to interface with an IIDC compliant camera, we have to conform to their standard.

There is a library to interface with IEEE cameras, libdc 1394. We have integrated that library into our project and adapted it in order to be able to communicate with our cameras. This library’s functionality is what we are wrapping in our GPUImageIIDCCamera class.

We did not integrate the GPUImageIIDCCamera class into the primary GPUImage framework. The libdc 1394 library has less permissive public licensing than GPUImage has, so for legal reasons, the class could not be merged into GPUImage proper and must remain a separate entity.

Objective-C? Why Not Swift

Taking a legacy piece of software that integrates with hardware is something of a challenge. Since Objective-C is a superset of C, there was a lot of low level C programming that could easily be integrated into the previous iteration of the control software that now presents some challenges when we attempt to implement them in Swift.

One such challenge was figuring out how to interact with our hardware. Prior to attempting to connect and control our camera, we had to determine how to talk to our micro controller. We were able to do this within the current constraints of Swift, but there is one feature of the C language that Swift does not yet support, which is mutable function pointers.

Since this was an integral part of our process, it was necessary to write this class in Objective-C. This, for the record, is the first time in our six-month process where we encountered a problem that we could not code in Swift. This didn’t prevent us from being able to implement this feature, it simply meant that we had to finagle a few things to fully integrate the Objective-C class into our control software code.

What do we Need the Code to do?

These are several things we needed this class to accomplish:

  • Connect to the camera
  • Capture frames
  • Set up the proper video format for the camera type
  • Remap the YUV colorspace to RGB colorspace
  • Get and set camera settings for things like brightness and saturation
  • Handle camera disconnection

Challenges

One of my personal challenges was simply understanding the code. Since much of our functionality would be done differently in the new code, I couldn’t just port it over from the old version of the software. It was important to get a sense of how to wrap the IIDC functionality in such a way that it would be easy to implement new cameras into our process. It was also important to figure out what lifting would be done by GPUImage and what would be done by the IIDC camera class.

Our current camera, the Point Grey BlackFly

Our current camera, the Point Grey BlackFly

Additionally, Brad did some extra work on our version of libdc1394 and his changes had not been documented. I couldn’t use the general documentation, what little of it there was, for the code.

Initially we thought that we would not need to use any OpenGL to process the video frames. It was later determined that a shader would be necessary for finding the frame size. This was beyond my present OpenGL experience, so Brad needed to write the necessary shader to accomplish this.

We also had to deal with different video modes. There are about thirty types of video modes we have access to, but all of these boil down to one of two types: Format 7 or anything else.

Format 7 allows you to set the frame size and the colorspace. All of the other video modes specify those things in their mode name.

Point Grey Flea2 camera mounted on our Desktop system

Point Grey Flea2 camera mounted on our Desktop system

Not all cameras support Format 7. Our first camera, the Unibrain, does not support Format 7. So we needed to make sure we were able to connect and use both Format 7 and non-Format 7 cameras.

We also had to deal with the fact that we were talking to a piece of hardware. Those settings, along with brightness, saturation, and others are all set on the physical piece of hardware. We can communicate with the hardware using C functions, but the point of wrapping this class is to avoid having to touch the messy underlying C library.

Each property associated with the camera that we can set has overridden getters and setters. We override them in order to make sure the camera and the application are on the same page about what each expects the settings to be. When you drop this class into another application, it appears to work the same way for the programmer with all the nasty bits tucked away in accessor methods.

Final Thoughts

When I worked on figuring out libxml2 at the beginning of the year I thought that was the hardest thing I would work on. That was just a warm-up for this project.

This was a huge challenge for me personally. I think trying to figure this out has been the hardest thing I have done in my career so far. In addition to how difficult this has been, not working with Cocoa since 2014 has made trying to get back in the swing of Cocoa development has been a bit of a challenge.

I hope that as I progress in my career it gets easier for me to pivot from low to high level development more easily. I wish I could have done this entire thing by myself, but I understand that we have deadlines that need to be met. I am proud of the amount I was able to do here and the growth I have experienced as a programmer by pushing myself to work on something this difficult.

The Trick to Forgetting the Big Picture is to Look at Everything Close-Up

Posted on by

Any sufficiently advanced technology is indistinguishable from magic.
– Arthur C. Clarke

Back when I was a programming student, my teacher Eric told me that over the years he has learned and forgotten a dozen programming languages.

At the time, it was inconceivable to me that anyone could learn and forget so much. Two years later, I am shocked to discover that he was right.

Two years ago when I really doubled down on learning iOS programming, I worked on it eighty hours a week. I was working through the Big Nerd Ranch iOS book. They had a series of about five chapters putting together a table view that would display a detail view populated by a singleton.

Every day I would wake up and code this over and over again. The first time I coded the examples, they made no sense. I typed a bunch of words that didn’t set off the compiler warnings, ran them, and magic happened. The second time was not much better. But by the third for fourth time, I began to realize, “Oh, I am creating this object because later when I load this detail view, I will be showing all the stuff I am keeping in this object. This is where it comes from.”

At the time Storyboards Interface Builder wasn’t particularly good for things. If you listen to many people online, their assessment of this situation has not changed. I used .xib files for each of my view and my custom cells and did all of my transitions programmatically. It took me weeks to wrap my head around all of these moving parts to figure out how they worked together. It wasn’t enough for me to just have something work, I really wanted to understand it.

Over the last year and a half, I haven’t really worked with user interfaces much. I had a contract job where there was no UI in Interface Builder because it was a legacy project from 2008. Then I spent a bunch of time running around like a chicken with my head cut off trying to figure out shaders, which are a tiny subset of a program. Then for the last eight months I have been working on porting another legacy project to Swift. We are just now getting to the point where I am working with interfaces again. It’s been over a year since I dealt with interfaces.

I am working on my first application. It is going to be rather limited to start off with, but I have plans to add additional functionality over time, so whenever I finally get it out, no, that is not the final product, more will come later, so don’t give me crap about it.

I am working with HealthKit. In HealthKit, there is a HKHealthStore that you are only supposed to have one instance of in your entire application.

I have been trying to figure out where to make that instance. I know that it needs to be accessible through the entire application and that you’re not supposed to make a bunch of instances of the same thing. I also know you have to pass it along to a lot of different places. I know many people don’t like singletons and I don’t want to create one of those, even though I am pretty sure HKHealthStore is a singleton. I was trying to figure out how all of the controllers can know about something while minimizing global state.

I talked to Brad about this a bit and he was talking about how it should be created in the root view controller for the application because that is responsible for the views that are controlled by it. As he was talking about all this stuff, it dawned on me that he was talking about the same things I was bashing my head against two years ago.

It wasn’t like I had spent a week mucking around with this stuff. I spent eighty hours a week for MONTHS trying to piece together how all this crap worked. I can’t believe that after spending all that time and pain on these concepts that they were buried in some far corner of my brain.

It also made me wonder about all the people who are learning programming now who use storyboards because, honestly, they are easier to get things done quickly. If you just push a couple of buttons and things happen like magic, how do you get a full understanding of what is actually going on? It makes me wonder about what else I don’t know about because I came into programming relatively recently. I know that my knowledge of memory management is bad because it was never something I had to deal with. I came in around iOS5/iOS6, so we had ARC and GCD and a lot of other things that abstract out a lot of the lower level programming stuff from you. Will understanding how root view controllers own detail views go the same way? I know talking to a guy at my first job he didn’t seem to understand this concept and it drove me crazy. I guess I have gotten to the point where I don’t understand it either.

It frightens me about how vast the knowledge is of everything that happens within the iOS ecosystem and how incredibly difficult it is to remember everything because really delving into the low level stuff means that you don’t know how to get things done quickly in the abstracted level. Sticking to the abstracted level limits your ability to do anything really customizable because you don’t see how the pieces fit together.

I am hoping that over the course of the next few years I can figure out a balance that works for me. I hope I can remember enough about how things work that I can deal with the abstracted layer without fundamentally forgetting everything.

What’s an Object?

Posted on by

I was editing my interview with Orta Therox yesterday when I realized I mentioned asking my boss Brad Larson what an object was.

I realized when listening to this that I hadn’t given any context because I wasn’t anticipating talking about that during the interview and I come off being rather ignorant in the course of this question. So, to avoid having to turn in my nerd card, I am going to give some context and give a more nuanced explanation behind that question.

My Personal Background with Object-Oriented Programming

I started going to school in 2010 for computer programming. I was 28 and I had almost no experience whatsoever with computer programming. My background was writing HTML when I was in high school and learning how to compile “Hello, world!” in Perl. At the time I enrolled I was working at Target because I failed to find a journalism job after I graduated and I really didn’t want to work at Target for the rest of my life. Programming seemed like it would be a good fit and it didn’t seem like it was going anywhere for a while.

I got through my first semester of introductory programming okay. Starting in your second semester, you had to pick a language to study for the next three semesters. At the time I was making this decision, there were three languages to pick from: Java, PHP, and VB.Net. I decided I would pick whichever one fit into my work schedule. The one that fit was VB.Net.

Our introductory class kept getting further and further behind. By the time we got to the end of the semester, we had never spoking about object-oriented programming. It was something we were supposed to do, but we just never got around to it.

The following fall, I took the advanced class. It was a night class, which I don’t really do well with anyway. The first class period, my teacher showed me object-oriented programming for the first time. I had no idea what the fuck he was talking about.

A bunch of code was in other files! How did it work together? How does the computer know to look in these other files?? Wait, what the hell is polymorphism? Am I having a bad acid trip??

After three hours of this, the teacher said since this was all review he was never going to go over any of this ever again. That was when I realized I was kind of screwed.

I decided to drop out after I asked what a constructor was and the teacher asked me if I learned anything the previous semester. At this point I had a decent job with people that I liked. I figured I was too stupid to learn programming because I wasn’t born with an intuitive sense for it and I was tired of feeling stupid all the time.

Six months after this, I took a new job that was the most miserable job I have ever had. The plus side to this job was that I taught myself programming while I was there. I realized I hadn’t put enough effort into it and if I just programmed forty hours a week I could learn it. So I went back to school.

I finally grokked OOP when I took the Intro to Java class. They introduced objects immediately and forced you to use them throughout the whole semester so you could get used to them. I started to understand about file paths and how the program knew how to find your other classes and how you imported them and how you constructed them. I felt like after I understood this for the first time that I was a “real” programmer. I hadn’t felt that way before grasping object orientation.

OOP is Not the Only Paradigm

I went from Java to iOS/Cocoa/Objective-C programming. I had a few vague issues when I was learning Objective-C with trying to pass around things that weren’t objects. Rather than really think about it at the time, I just got annoyed and turned all of my ints and floats into NSNumber objects to shut up the compiler.

Here is a sample header file you might commonly make if you were creating an Objective-C project:

@interface MyViewController ()

@property (nonatomic, strong) UIImageView *backgroundImageView;
@property (nonatomic, strong) UIImageView *blurredImageView;
@property (nonatomic, strong) UITableView *tableView;
@property (nonatomic, assign) CGFloat screenHeight;

@end

In my experience with Objective-C, everything was an object. You created classes, which were objects, and you populated them with instances of other objects and in turn instantiated your new object in instances of UIViewController objects.

You had header and implementation files. The name of your class was the same as the name of your implementation file. Every file has a class. This is what programming is. It’s objects all the way down.

My first experience with understanding that this wasn’t the only way of doing things came several months ago. I was working on translating a plug-in we were using to a piece of code we kept internally. I had a weird method I was dealing with that wouldn’t compile.

After fighting with it for a while, I took it to Brad and asked him what I was doing wrong. He told me I was treating the function like a method. This statement kind of blew my mind because I thought that methods and functions were the same thing. I thought we called functions methods in Objective-C the same way that Java interfaces were the same thing as Objective-C protocols. (Yes, I am aware I am probably wrong about this as well. I am still learning.)

I didn’t know that there was a difference in Objective-C between functions and methods. Functions exist outside of classes and methods are functions that are embedded in a class. I hadn’t really thought about this or why anyone would want to do that. I simply assumed that all functions were methods and everything had to be encapsulated in a class.

This was only the tip of the iceberg.

Becoming Functional

Back in November, Brad went away for a week for a trade show. We were planning to rewrite all of our control software in Swift and he wanted me to take a look at the code he had written so far to make sure that I understood it.

What I saw completely broke my reality.

He has posted a sample project on GitHub including some of the code I looked at initially. Here is a small sample of what I saw that changed the way I think about programming:


import Foundation

// MARK: -
// MARK: Error protocols

public protocol ErrorType {}

protocol PresentableError {
    var errorTitle: String { get }
    var errorInfo: String { get }
}

// MARK: -
// MARK: Error types

enum CommunicationsError: ErrorType, Printable, Equatable {
    case ReadWriteTimeout
    case WrongByteCount(expectedByteCount:UInt, receivedByteCount:UInt)
    case CorruptedResponse(expectedResponse:[UInt8], receivedResponse:[UInt8])
    
    var description : String {
        get {
            switch (self) {
                case .ReadWriteTimeout: return ".ReadWriteTimeout"
                case let .WrongByteCount(expectedByteCount, receivedByteCount): return ".WrongByteCount(expectedByteCount:(expectedByteCount), receivedByteCount:(receivedByteCount)"
                case let .CorruptedResponse(expectedResponse, receivedResponse): return ".CorruptedResponse(expectedResponse:(expectedResponse), receivedResponse:(receivedResponse)"
            }
        }
    }
}

enum ElectronicsError: ErrorType, Printable, Equatable {
    case ElectronicsDisconnected
    case UnrecoverableCommunicationNoise
    
    var description : String {
        get {
            switch (self) {
                case .ElectronicsDisconnected: return ".ElectronicsDisconnected"
                case .UnrecoverableCommunicationNoise: return ".UnrecoverableCommunicationNoise"
            }
        }
    }
}

// MARK: -
// MARK: Equatable protocol compliance for these errors

func == (lhs: CommunicationsError, rhs: CommunicationsError) -> Bool {
    switch (lhs, rhs) {
        case let (.ReadWriteTimeout, .ReadWriteTimeout): return true
        case let (.ReadWriteTimeout, _): return false
        case let (.WrongByteCount(expectedByteCount, receivedByteCount), .WrongByteCount(expectedByteCount2, receivedByteCount2)):  return ((expectedByteCount == expectedByteCount2) && (receivedByteCount == receivedByteCount2))
        case let (.WrongByteCount, _): return false
        case let (.CorruptedResponse(expectedResponse, receivedResponse), .CorruptedResponse(expectedResponse2, receivedResponse2)): return (equal(expectedResponse, expectedResponse2) && equal(receivedResponse, receivedResponse2))
        case let (.CorruptedResponse, _): return false
    }
}

func == (lhs: ElectronicsError, rhs: ElectronicsError) -> Bool {
    switch (lhs, rhs) {
        case (.ElectronicsDisconnected, .ElectronicsDisconnected): return true
        case (.ElectronicsDisconnected, _): return false
        case (.UnrecoverableCommunicationNoise, .UnrecoverableCommunicationNoise): return true
        case (.UnrecoverableCommunicationNoise, _): return false
    }
}

The name of this file is ErrorTypes.swift. There is no ErrorTypes class. There is nothing in this file named ErrorTypes.

NOTHING IN THIS FILE IS AN OBJECT!!

We have several enums, which are not objects, that we are references for type conformity. We have UInts, which are not objects. We also have functions. Lots and lots of functions. That aren’t associated with a class. They’re just out there like llamas roaming free.

When I tried to understand this I felt like I went to a party and someone asked if I wanted to use another person’s liver. I didn’t know if was possible to call functions that were not associated with a class instance. I had never seen anything like this before. I couldn’t believe this would build and run and compile just fine. I felt like I fell down a rabbit hole and nothing made sense anymore.

Reorienting Myself with Reality

I, like many people, learned programming in the age of Imperative Programming. Java has been around for twenty years and many people learned programming with Java. A lot of us don’t know anything except the Object Oriented way of doing things. To many of us, this is what programming is.

It doesn’t have to be.

One reason I am so vocal in my defense of Swift is because this realization has completely changed my reality. I used to think there was only one way of doing things. Well, I won’t say that. There was one right way of doing things and then there was the “Dear god, what is this person thinking by having this property controlled in four different places?!” way of doing things.

Being exposed to Swift and seeing that you don’t have to put everything in a class has been a revelatory experience for me. It is forcing me to reevaluate everything I know about programming.

I never thought about what an object was before because there was no point because everything was an object. Now, I am trying to get a better understanding of what an object actually is. I wrote about the difference between structs and classes and at the time I really didn’t understand why you would want to use a struct instead of a class if they essentially do the same things. I now understand that you want to try to use structs when possible because they aren’t objects. Objects come with a lot of overhead. They let you do some more powerful things like subclassing through polymorphism, but you don’t always need to do those things. Looking at how powerful the enums are that Brad uses in his code, I am fascinated by how confined my own view was when I thought everything had to be an object and exist in a class.

So yes, I did ask what an object is. I know most programmers worth their salt can tell you the definition of what an object is, but I don’t think many of them stop to think about why we use them and if they are the best way of doing things. Or if they bother to wonder if objects are the only way of doing things.

Culmination of a Dream

Posted on by

Two years ago, I didn’t know Chris Adamson existed. I was taking my first semester of the iOS development degree at Madison College when I first found out about him. I was taking the Objective-C class mostly because I needed to have a full load in order to continue to collect unemployment benefits. I was planning to follow the Java track, get a job for a health insurance company, and lead a normal mundane existence. That all changed when I heard two words that would change the course of my life: Core Audio.

In my previous life, I went to school for audio engineering. I learned Pro Tools and Logic. One of my teachers was talking about the extreme guys who programmed those pieces of software and they fascinated me. I had no idea how anyone would program a digital audio workstation, so I kind of forgot about it.

When my teacher Eric Knapp mentioned Core Audio, he said it was one of the hardest things to learn in the Apple development environment. It was a toss-up between Core Audio and OpenGL. Me being the good little masochist that I am, I decided I would learn both of them. (Having tried my hand at both of them, I am awarding Core Audio with the trophy for being harder to learn.)

Trying to read "Learning Core Audio" while cruising and enjoying the ocean.

Trying to read “Learning Core Audio” while cruising and enjoying the ocean.

I bought Chris’s book on Core Audio and made the incredibly stupid decision to take it on vacation with me for beach reading. After seeing the unfamiliar and deprecated “NSPool” object, I freaked out and realized I had to work a lot harder in order to learn enough to understand what the hell is going on.

In February 2013 Eric told me that Chris would be speaking at a conference in Chicago. The conference was in two weeks. I was a poor, unemployed college student, so I had to scrape together enough money to be able to go down and attend this conference so that I could meet Chris.

I saw him around the conference, but he was a big important author and I didn’t really know what to say, so I didn’t approach him. On the last day of the conference, Chris did a talk on audio on iOS. I sat in one of the front rows and peppered him with a lot of impertinent questions about audio programming on non-iOS platforms. Having been on the receiving end of questions like this in my own talks, I commend Chris for his patience and restraint at not shoving my Ravenclaw scarf down my throat.

Kyubey and I grokking AV Foundation video.

Kyubey and I grokking AV Foundation video.

We wound up talking after his talk and having lunch together. He was one of the first people I have encountered that I felt completely in synch talking to. I wore a Doctor Who shirt trying to bait someone into talking to me about it. Chris saw it and commented that he would ask about it, but everyone and their brother was into Doctor Who. I pulled out my phone and showed him a picture of my pug, Delia Derbyshire. When I said her name, his face lit up and he got really excited. He was the first person I met who knew who Delia was without me having to explain it. Eric asked who Delia was and we were talking over one another explaining who she was. I was so happy. I was grateful to him for hanging out with me and talking about my stupid geeky audio stuff.

Several months later I got to attend CocoaConf Boston and spend a whole day with Chris doing Core Audio. That day was one of the best days of my life. I was having a lot of problems at that point in time and I felt like my life was falling apart. Spending the summer working through the Core Audio book knowing I would get to do this workshop in the fall gave me focus when I needed something to get me through my life.

Chris giving his penultimate Core Audio workshop at CocoaConf Boston 2013.

Chris giving his penultimate Core Audio workshop at CocoaConf Boston 2013.

Chris and I were able to work our way through our initial awkwardness due to both of us having some social anxiety issues to become friends. I stopped worrying that I was bothering him by commenting on his tweets and I began to feel comfortable asking him for advice.

Earlier this year I was again trying to figure out what I was doing with my life. I had a contract job that was ending in a few weeks and I had to figure out what I wanted to do. I applied for a QA position at a company in town whose employees I knew and liked a lot. Something in my gut told me that I didn’t want to do this job. I knew I needed a steady paycheck, but I just had a gut feeling that I wasn’t supposed to take this job.

I went to Chris and explained my situation. He patiently read through my long rambling email and responded back, “I should tell you to take the stable job with the decent paycheck and the nice coworkers, but I have an ulterior motive. I need a coauthor for my book and I would need you to start after your contract is over.” I immediately wrote back to the company and told them I was no longer available.

Like all recovering journalism and English majors, I always wanted to be a writer. I wanted to write books and stories. I have absolutely no idea why I wanted to be a writer. I don’t remember if I actually liked writing or I just liked the idea of being a writer. I sort of gave up on the idea of being a writer in high school when I realized everything I wrote was crap. I realized if I wanted to be a writer I needed to have some actual experiences. I had to get out of my comfort zone and change my perspective of the world. Sometime in college I just sort of decided not to think about writing for a decade to give myself a chance to actually find something to write about.

The Boston Breakpoints

The Boston Breakpoints

I began writing again last year around the same time I met Chris. I had another developer recommend starting a blog and I have written at least one blog post a month since I started my blog. I know a lot of people do podcasts because they are “easier”, but I have always found that writing really helps me get my thoughts out of my head.

Back in March at CocoaConf Daniel Steinberg had a session called “Book Chat.” It was for anyone who had written or wanted to write a book. The only other person there besides Daniel and I was Chris. Many people over the last year have tried to talk me out of writing a book. I heard the usual arguments that books take a long time and they don’t generate any money. Daniel asked me what I wanted to get out of a book. I told him I wanted to be able to type my name into Amazon and have a result pop up. I also wanted to take the cover of my book, frame it, and put it on my wall. That was all.

Today marks the culmination of a dream for me. I have a book I wrote being published. We are on a public beta and there is still more work for me to do on the book. But it is real. It is happening.

OMG! I got a shout-out in Chris's "Stupid Video Tricks" talk in Chicago!

OMG! I got a shout-out in Chris’s “Stupid Video Tricks” talk in Chicago!

I am thinking about where I was a year ago. I had weathered several failures and I felt broken. I had no idea what the following year would bring. I had the single-minded determination that I had to finish the Core Audio book and go to Boston. I didn’t know how or why, but I knew that it was a turning point in my life and I threw everything I had at that.

Going to Boston changed my life. It changed my perspective of who I could be. I was pitched by several companies there that I didn’t imagine would even be interested in me. None of those leads worked out because I was just too messed up to take advantage of them, but they made me realize what kind of person I could be if I wanted to. Josh Smith had me talk to Dave Klein about speaking in Chicago this year. I didn’t think I could be a speaker until that happened. I applied for another talk that happened a few weeks before CocoaConf Chicago, which wound up being my first tech talk, but that would never have happened without Josh Smith.

Mad props to Mark D for throwing Greek and trombone playing at us at 8:00 in the morning.

Mad props to Mark D for throwing Greek and trombone playing at us at 8:00 in the morning.

I love this community. I love that I came here from a really crappy background and that I found people who were willing to accept me for who I am. I am happy that I haven’t been discarded because I am damaged. My damage could even be considered an asset because I bring uniqueness and experience with it.

All of these people keep talking about the importance of teaching young girls to code, like somehow my generation of women is too old to learn new things and we are a lost cause. Meeting someone like Chris whose experience was so like my own and knowing that I could have another chance at life gave me hope, which gave me the tenacity to endure all of my various disappointments. He gave me strength to accept all the broken, dirty pieces of myself and accept that they are part of who I am. He woke me up and made me think about all the parts of myself that I had numbed because they were too painful to deal with.

I went from a world of “No” to a world where anything is possible with enough work and tenacity. These last two years has been a miracle.

“iOS 8 SDK Development” is my first book. I hope there will be many more where this one came from. I treasure this book because it represents something I didn’t think I would ever have. It is also a project I got to work on with a great friend whose presence has enriched my life.

I wish I could go back two years and tell the earlier me that I would meet these people who would change my life. But I can’t. Spoilers, sweetie.

Lexical or Preprocessor Issue

Posted on by

So, today was the day I decided to bite the bullet and start working on my Metal demo for CocoaConf Columbus and 360|iDev.

Since a large focus of my talk is on GPUImage, I am hoping to put together a light Metal version of GPUImage that processes an image using a series of filters. I want to write between three and five filters that are easily stacked on one another that have a GPUImage counterpart in order to test how fast Metal processes images compared to GPUImage.

I went to look at what sample code is available from Apple for Metal. To my delight, I saw that there was an image processing base project. It includes one filter to change an image to black and white and that is hardcoded. I should be able to go into this project, add my filters, and add some UI elements allowing me to add the filter shaders I write.

Today I opened the sample code. Immediately, there was an error.

“Lexical or Preprocessor Issue: QuartzCore/CAMetalLayer.h not found.”

This is why we can't have nice things!!

This is why we can’t have nice things!!

Huh. That is inconvenient.

Did some digging. Refrained from asking this question on Stack Overflow because the last time I asked a question about the betas I got a snide person telling me to go somewhere else. Headed to the Dev Forums and found this thread.

Apparently, for the time being, there is no support for Metal in the simulator. There should be support for Metal if you have an A7 device like the iPhone 5S (which I have) that is running the iOS 8 beta.

I have not yet updated my phone to the beta. I know we are getting close to the point where it will be released, so it isn’t a huge thing to update to the beta, I just feel like I have no guarantee that stuff will work on there properly even after I update to the beta.

I must say that this latest wrinkle is not doing anything to sell me on Metal.

Metal only works on iOS A7 chips and now further won’t even work in the simulator. I usually use the simulator in my talks to demonstrate things I am doing, but now I have to get it on my device. I think I can use Airplay to show what the screen looks like, but that is one more step that can go wrong in my process.

The other things I am noticing in the sample applications is that most of the class implementation files end in “.mm”, which means that they are explicitly telling the compiler that there is going to be C++ code in them.

I have not worked with Swift as much as I should have, but I am wondering if this is going to be a problem with trying to write an app in Swift. I know that theoretically Swift is supposed to behave like Objective-C in that you can include C and C++ code, but I have not tried to write straight C code in a Swift class yet. Can you write C code in a Swift class, or is the support just that I can import a C class into a Swift-based project? How is this going to work with Metal?

At least with OpenGL ES you have the GLKit framework with should work with Swift. I am interested to know more about this, but sadly I don’t believe I will be able to explore these issues before I give my talk in Columbus.

I am also trying to figure out just how much C++ I need to know to fully work with Metal. I thought that I needed to know about the same amount of C++ as you need to know of C to work with GLSL, but after seeing the number of classes that are implementing C++, I am slightly worried that I am going to be out of my depth for a while.

These are things I am going to have to take into consideration and disclose during my talk. I know most of these issues will resolve themselves in the next few years, it is just slightly frustrating to sit on the sidelines trying to figure out how to make it work here and now.

Fortune favors the brave.

AVFoundation Audio at CocoaConf Chicago 2014

Posted on by

Overview

Two weeks after I had my first tech talk I had my second tech talk. This second tech talk was at CocoaConf in Chicago.

My Door

My name isn’t in lights, but it’s still pretty awesome!

In some ways, this talk had higher stakes than my first talk did. CocoaConf is a more hard skills conference. CocoaConf is invitation only. Most of the people who speak at CocoaConf are well known developers in the Cocoa community. My talk was only going to be in front of 20-30 people, but those people were going to be very well known people. Additionally, CocoaConf is very reputable about having well developed talks.

This was a very important opportunity I was being given. It was very important to me that I not embarrass myself or let down the people who were giving me this chance.

Considerations

I was trying to figure out how in-depth to make my talk. From speaking with other people, I was under the impression that most people think that doing audio programming is hard. Part of what I wanted to convey with my talk was that audio programming doesn’t have to be hard, but then since audio programming is easy, then why am I doing a whole talk about it?

Janie Talking

Picture of me delivering my talk in Chicago

I decided to err on the side of just showing what could be done easily. I spoke to a few people about how hard people expect what I talk about to be and I was told that no one was expecting WWDC-level complexity.

Also, I hoped that by focusing on audio session-based demos that it would have a nice, cohesive block of information that I could cover in an hour without glossing over anything or running out of time.

I tried to think about what the fundamental things were that people would want audio for. I know that I personally would like to build a synthesizer, but that it would take years to learn and what I am interested in is highly specialized.

Most of what people use audio for is just recording and playing back. These are things you can do with a few lines of code that used to take hundreds of lines of code. I made a determination to focus on things people could implement easily and achieve quickly.

Preparation

I knew based on what happened with my first tech talk that I really needed to make sure I practice my talk in front of an audience. After I finished that talk I approached Brad from Bendyworks about performing my talk at their workplace so that I could get an idea of how much material I have versus how much I need.

I got to perform my talk three days before I got to do it for real. I had a rough draft of my slides and working demos.

I am posing with the door that has my name on it :)

I am posing with the door that has my name on it 🙂

Everyone I talked to said to not include too much information on my slides. I did that in my first tech talk and that went badly. I was so nervous that I forgot to talk about things that weren’t on my slides. I know it isn’t super dynamic to have a lot of slides, but I wanted to make sure that I was providing the information I needed to.

One thing I figured out by practicing my talk was that if I just brought up a demo and tried to find the code I wanted to talk about I tended to stumble over it and not be able to find it while people were watching me. One change I made was to take screen shots of the code I wanted to talk about and include it as a slide rather than try to find what I wanted to talk about in the code base.

When I didn’t include code in my slides my talk was only half as long as I needed it to be.

I included a quiz in the talk because I wanted people to be engaged in my talk. One thing I added was to have multiple choice answers for the quiz because people tended to not remember the choices. Hell, I wrote the talk and I couldn’t even remember all of them off the top of my head!!

Having gotten an idea about what wasn’t quite working properly and how to pad out the talk somewhat I was ready to proceed to the main event!

CocoaConf Chicago

I had the great privilege to be in the first group of speakers after the keynote. I was planning to spend five minutes before my talk with my headphones on listening to music to get myself psyched and focused. That didn’t happen. I forgot that the Kleins ask you to pitch your talk to people in the morning, so I had to go up and do my spiel about why people should come to my talk.

Kyubey posing with my special pink CocoaConf mug

Kyubey posing with my special pink CocoaConf mug

Then everyone dispersed and immediately went to the rooms for the talks.

I had 10-15 minutes before my talk where everyone was waiting around in my room. I didn’t really want to start my talk early because I didn’t have enough material for that and there was a possibility that someone might come in at the time the talk was actually supposed to begin.

We had a few hiccups with my set-up. I didn’t think I needed a microphone or speakers, but Chris Adamson very wisely advised me to have some and since we had a bunch of time before the talk was supposed to begin we had plenty of time getting those things taken care of.

Still, after all of this set-up there was a substantial amount of time where there was waiting. I threw on my psyched music and I got to have five minutes of meditation before I had to perform.

One thing that I did for me was I had a stuffed Kyubey doll that I used as a prop in my talk. Kyubey is a character from Madoka Magica that makes contracts with girls giving them a wish in exchange for them battling evil.

I know he isn’t real, but having a “safety net” there where I could pretend that if things went really badly I could just make a wish to get another bite at the apple really helped me to not panic. I know that only one person in the audience understood the joke/reference. I hoped that if I didn’t spend too much time on it that if it didn’t go over well then it wouldn’t derail the whole talk.

Another thing that I did was I brought a bunch of candy with me. I didn’t want to just stand up there and talk to myself for an hour, so I brought candy to bribe people to engage me in conversation so that they weren’t just spending the whole talk checking their email and doing things on Twitter.

Yes, I have been told that I talk with my hands. A lot. Also that I should have pulled back my hair.

Yes, I have been told that I talk with my hands. A lot. Also that I should have pulled back my hair.

Overall, I think it went okay. I did have a few periods of my talk where I got really nervous. One thing that happens when I start having a panic attack is that I develop a speech impediment. This happened twice during my talk. I felt it coming on and I was able to shake it off before it got too bad.

I know that after I do more of these they will get better. Considering my level of expertise and comfort with doing something like this it could have been much worse. I know if I do more of these my delivery will get better.

Aftermath

So, I spent several weeks focusing on this talk. I was not employed at the time I was preparing for this talk so this was the only thing I had to focus on.

I was really happy that I got to go first. I could get the talk out of the way and enjoy the rest of the conference. Another aspect about going first that I didn’t take into consideration was how energetic people would be at the beginning of the conference. I noticed that with some of the later talks the next day people were tired and a little burned out. This was something I observed when doing my first talk. I didn’t think about what a gift it was to get people who were bright eyed and alert over people who were looking forward to going home to crash.

One thing I didn’t take into consideration was how keyed up I was about doing the talk. After I got done with the talk I crashed a little. I was sitting in another talk when I realized that I was done. It was over. This thing I had been waiting for a month to do and preparing for was over and I had nothing else I was looking forward to after it was done. That was a little sad.

My slides are here and my demo projects are here.

Comments

While sitting down to write this blog post I finally bit the bullet and read my comment cards.

I was expecting a lot of what I saw. People said I seemed nervous. I did some silly things in my talk. People said they wish I had not relied so much on my slides.

The one that I saw that really disappointed me was that many people complained that I didn’t tackle a hard enough topic. One person said they wished I had tagged this as a beginner talk and that they were expecting me to go more in depth with what you can do with audio programming rather than just the easy stuff.

I needed to make a decision about how hard to make the talk. I erred on the side of talking about something easier rather than harder because I didn’t want to frighten people away from audio programming. That might have been a mistake. I know it was something I struggled with and hoped I made the right choice on. I don’t know if the choice I made was right or wrong, but having more than one person explicitly say that it was the wrong choice makes me feel bad.

One thing people did not comment on that I expected to have commented on was my use of Kyubey. I didn’t utilize him as best I could. If I had been smarter or less stubborn I would have cut him from my talk. I included him just for me so that I would feel comfortable and that isn’t really a good thing to do.

In the future if I am going to include a prop I am going to include a prop that is a reference more than two people in the audience will understand.

Conclusion

Having the chance to talk at CocoaConf was one of the most amazing opportunities I have had. I am grateful to the Klein family for giving me the chance to speak. I hope that I did a good enough job that they would be open to me speaking there again.

I know if I want to be a better speaker I need to do it a lot more. I have been pitching a few talks to different conferences later in the year. I hope to have opportunities to learn and grow as a speaker.

One of my goals as a developer is to be able to share my knowledge with other people. I would like to write books and do talks. Being able to give back to this community is very important to me and I hope that I will be able to continue to contribute in the future.

Properties and Headers and Ivars, Oh My!

Posted on by

So I have been seriously coding Objective-C for about a year now. I have spent a lot of time just sort of typing things only having a surface knowledge of what I was coding and why.

One thing I noticed in my independent iOS studies is that there are a lot of different places to create variables. Also, there are variables and there are properties.

Why pick a property over a variable? Why declare the property in the header file instead of the implementation file?

Properties

If you are coming from a language like Java, you will know that you are required to write getters and setters for all of your properties. Back in the olden days of Objective-C, you used to have to do this as well. A few years ago Apple decided to introduce a @synthsize property to do the getting and setting for you. Then a few years ago they decided that since it was best practice to do that anyway, it is all baked into the code for you. Just because you aren’t doing it and you don’t see it doesn’t mean it isn’t happening under the hood.

Properties are backed by instance variables. So, if you declare a property in the implementation part of your .m file, a backing ivar is created.

So, if you have:

@property (copy, nonatomic) NSString *myString;

you will then be able to access it in your methods by using:

_myString = @“Hello, World!”;

In this instance _myString is an ivar of the property *myString.

Header Vs Implementation

One thing I wondered about a lot while working with tutorials is why you would choose to place things in the header file over the implementation file. Back when I was just typing until something worked I put everything in the Header files because they would show up in the autocomplete. Then I started seeing tutorials where they declared properties in the implementation file and used ivars.

If you want a property to be accessible by another class, you need to set the property in the header file. You don’t always need or want a property to be accessible to another class because it is something you are using internally. In those cases, use either a property or an ivar in the implementation file.

Apple’s best practices say to always use a property for data encapsulation. There is some debate about whether to use them or not, but that goes beyond the scope of what I am going to talk about here.

There is a wonderful blog post from the Big Nerd Ranch discussing this issue. In this post I am simply exploring what the scope of everything is, so if you are interested, then check it out.

Ivars

Instance Variables (or Ivars) are created in the @interface of your .m file. They are immediately differentiated by the fact that their declaration begins with their type and not with @property.

It is a coding convention to begin Ivars with an underscore. When you create properties that are backed by instance variables those will always start with an underscore, so it keeps things consistent in your program to start yours with an underscore as well.

Demo

I created a small demo project on GitHub to just generally show better examples of this code in action.

Conclusion

This is intended to be a gentle introduction to the scope of various properties and variables. I want to explore some of this topic further, such as what the strong, non-atomic, copy, retain all mean and why you use those, but that is a large enough topic for its own blog post.

If you have any suggestions about Objective-C minutiae you would like clarified and explored, drop me a line on either Twitter or App.net at @RedQueenCoder. Happy to take suggestions!

I hope this clarifies for you how to choose where you set your properties, or at least answers your questions about why they are set in so many different places.