Pivot to Video

Every year it happens. WWDC comes and unleashes a bunch of new stuff for all of us to learn. For most people the last few years, WWDC hasn’t been that exciting because it’s primarily been graphics and augmented reality stuff. For me, it’s been Christmas. I love Metal and ARKit and all the new shiny graphics stuff that gets released each year.

However, inevitably I will encounter some aspect of my workflow that doesn’t involve low level graphics. I will have to connect to a network backend. I will have to figure out the new user interface framework.

I want to get back to my fun graphics stuff as quickly as possible, so I Google tutorials and sample code for these things I don’t want to think too much about. The results come up. Perfect! I found exactly what I want!

I click the link and my heart sinks. Instead of a nicely written blog post or article about the technology, I stare into the void of a 5+ hour video course someone put together.

Videos Are Terrible

The last few decades have show the emergence of this idea of different learning styles. Some people are “visual learners,” whatever that means. Some people learn things by doing, which to be honest is basically how everyone learns?

This has unleashed this unholy deluge of instructional videos for the poor, underserved portion of the population that learns by watching other people talk. These are probably the same people who learn by listening to the same three white dudes in tech talk about cars on podcasts.

I’m sure there is some portion of the population that learns by watching videos. And videos have their place. I love watching short cooking videos. Cooking is a physical thing and watching how someone folds a dumpling or condenses a 3 hour baking project into a three minute video that cuts out all the prep work and waiting can be quite instructive. None of that applies to programming.

Programming isn’t suited to a video medium

I know that someone who won’t read this blog post is going to “Well, actually…” me on how video is great for programming because it shows you how to use the IDE/game engine/etc… I am not talking about videos on how to use storyboards or set up an animation loop in Unity. I am talking about code. Words you type into a text editor or IDE with no software interface.

Programming is inherently word based. I have used the analogy that programming is what you would get if Math and English had a baby. It’s got language and syntax and grammar. All of which gets lost in translation when you have someone trying to verbally read it out loud.

Every bad tech talk I have attended at conferences goes the same way. The presenter spends a few minutes introducing the topic of their talk and gets everyone excited about using the framework. Then they pull out all the slides covered with code and it all goes downhill from there. People’s eyes glaze over. They start chatting on Slack. They surf Facebook. Everyone waits for it to be over, but hey, beats being at work I guess?

Code wasn’t meant to be read out loud. It’s the most efficient compromise you make with the computer to be able to communicate. You can read through code and bounce around asynchronously to see how everything works in a way you can’t if someone is just talking.

If you have a nicely written tutorial and you didn’t quite get something, you can scroll back to see where you got lost and review what you don’t understand.

Which leads into the next point.

You can’t search for what you need

It’s incredibly frustrating to spend hours looking for something that covers the exact topic you need, only to find out that the presenter isn’t going to cover the part that you need. When you have a video, you have no idea what the specifics are that the presenter will actually cover. I went to an Accelerate talk where the presenter said that he would not cover any of the math that the framework utilizes, which is basically the entire point of the framework!

If I am dealing with a book or documentation, I can utilize a search function to see if the document I am looking at contains what I need. I can zero in directly on the part that I need to understand and be on my way in a few minutes. If what I want isn’t there, I haven’t really invested anything into it.

If you’re dealing with a video, it’s a crap shoot as to whether the author is going to speak about the one specific thing you need to know at any point in their long rambling video. Sometimes they are helpful and will give chapter titles so you can guess if they’re going to talk about the thing you need to do. But usually the author has created an elaborate project that is dependent upon you watching everything up until that point for anything to make any sense.

You can’t do anything else

I learned to code by working through the Big Nerd Ranch iOS book multiple times. I didn’t quite understand the concepts the first time through, so I would do them again and again. By the time I got to the fourth or fifth time, my brain had been introduced to the concepts enough that it began to understand how everything works together.

To keep myself from going insane, I would throw on episodes of Star Trek: The Next Generation. I worked through the entire series by having an episode on while I coded through a tutorial. This worked for me.

If I have an instructional video on, I literally can’t do anything else. I’m held hostage. You can’t read or check email because you miss something and have to rewind to figure out what someone said. If you’re coding along, you have to keep pausing and rewinding to catch what the person said. You endure long bits of watching someone writing the same code as you in real time. This is miserable and tedious. Not to mention mentally exhausting in a way that reading is not.

I do have some Unity videos I will throw on in the background, but I do this knowing that I am not engaged enough with the material to actually learn it. I can’t do this for something I must use for an active project.

If I am working with written materials, I can take mental breaks for a few minutes and come back. I can copy/paste code if I don’t quite get it written correctly. I can reread things a few times if I didn’t quite get it the first time. I can have on music or do literally anything else to make it easier to stand at my computer for hours force feeding myself technical information.

Back when I used to work for people, I would be asked to figure out something I didn’t already know. Rather than flailing blindly around I would look for something written that I could look through to learn the things I need to get working immediately.

It’s a lot easier to sell your employer on the idea that you’re actually working if you’re reading something and have a code editor open. If you’re watching a video, it looks like you’re slacking off. It also means that if someone interrupts you, it’s way more disruptive than if you are reading something. In the age of surveillance capitalism, it looks bad if you try to learn something by watching a video. This is not the case if you are reading something. Perception matters.

The podcast problem

I don’t listen to podcasts, which is ironic because I have hosted three of them. Podcasts tend to be two or more people rambling about some topic and making in jokes that only they find funny where nothing is edited out. Sometimes you get someone who knows enough audio production that they will fix levels and remove long awkward gaps in conversation, but rarely do you get a well focused discussion about a topic with an interviewer who not only knows what questions to ask but who will keep the conversation on track.

A lot of instructional videos are people just kind of turning on a screen capture app who then begin to work on a demo project they feel like working on. There isn’t really an agenda for them to follow. They don’t think about how best to present information. They leave in their coding errors.

It’s this idea that it’s a lot easier to just record yourself talking than it is to have a well thought out plan as to how you are going to take a complicated topic and explain it to someone who doesn’t know everything you do.

Final Thoughts and Complaints

I really do not understand why this video explosion has happened. I don’t know if it’s similar to that Facebook pivot to video ads where they lied to people about the impact of video and everyone dove in wallet first and got screwed over.

It may just be easier to half ass a video than it is to write a good tutorial. There was that ghastly Hacker News bit saying that a group of coders could start up a news room in a month which was totally bullshit. Writing is a skill. A lot of people are not good at explaining things. Everyone complains about the quality of Apple’s documentation coverage, but think about how hard it is to scale up a team of people who are not only technically savvy enough to understand all the code but can also write clearly. There are a limited number of people out there who can do that.

That isn’t to say you can’t improve. The first few things you write might be terrible, but if you know they’re terrible and it bothers you, you can work to improve it.

I dunno. I might just be a crusty old person who is stuck in my ways yelling at the kids to get off my lawn. But after they do I am going back to my she shed with my programming books and my 600 queued episodes of Chopped.

Streaming WWDC 2016

I have never had the privilege of attending WWDC. Most years (including this one) I never bothered to apply to the lottery because I couldn’t afford to go. The one year I could afford to go, I didn’t win a ticket and I decided I would rather have the money as a buffer than go out to WWDC. This was the correct decision.

I attend a lot of conferences. I speak at a lot of conferences. Unfortunately, I have had some difficulty actually attending sessions at conferences. I have panic attacks when I am trapped in a room full of people and I can’t get up and walk around. This was one reason I was never super disappointed about going to WWDC the last few years. The idea of being stuck in a room for a whole week makes me feel like curling in a ball and crying. I go to conferences to network and drink with my friends. Now I am at the point where it’s just networking since I gave up drinking.

One thing I had forgotten about was discovering new things by attending sessions I hadn’t thought to go to. When I went to my first CocoaConf, I encountered a lot of interesting things because I wanted to watch Jonathan Penn and Josh Smith present.

When Swift was introduced two years ago, most of the conference sessions revolved around talking about Swift. I like Swift, it’s a neat language, but I am sick of talking about it. I am tired of hearing people talk about side effects and protocols and immutable state. I miss the first few years I was an iOS developer when people talked about frameworks and weird little nooks and crannies of the Cocoa architecture.

Taken together, this has created something of a perfect storm where I got burned out on iOS development. I got sick of talking to people about it because it always boiled down to Swift and arguing about code purity and a bunch of other bullshit.

I saw the Keynote this year and I had absolutely no enthusiasm for anything this year. I was irritated and cranky and didn’t want to deal with anything. But I noticed that this year Apple decided to stream most of the sessions live. The sessions were always available online later and last year they started showing select sessions. I watched the Swift ones because it was for my job and was still new and exciting. But I rarely watch the sessions afterward because when I watch the sessions, I sit there and pause every few minutes to try and process the vast amount of information that is being presented. There is a massive backlog of lots of sessions I think would be nice to watch but I never get around to watching. I did not think I would do anything this year.

I was wrong.

Streaming the sessions live has completely changed my life this week.

I work from home and so I just kind of threw the live stream on while I worked on stuff. I have it on in the background. I can’t pause the live stream, so I am not poring over every second of each video minutely. I am getting an overview of what they are talking about so I can go and research things later. I also have a team of people on various Slack channels who are watching it with me that I can chat with about the things we find new and exciting.

There were five whole sessions on Metal this year. The last two years I only got through the first Metal video because I felt like I didn’t understand it well enough to move on to the next video. This year, since they were just on, I could passively leave it on and get through all the videos. If this was a normal year, I would not have encountered the thing that has excited me the most this year, which is doing neural networks in Metal. That was introduced in “What’s New in Metal Part 2,” which was the fourth Metal video streamed. I did not need all the context from the first three videos to get excited about the new stuff in Metal.

I got to watch all the videos about GameplayKit, Photos, SpriteKit, etc… All of these technologies that I have been interested in but in a passive way were all just there for me to listen in on. I got introduced to so many things I didn’t know about in obscure frameworks that don’t get a lot of love because most people need to pay the bills and so they don’t do sessions on SceneKit.

This is what it was like at the beginning when I started going to conferences. I would discover so many new things that I would go home excited to get working on something. I haven’t felt this way for the last two years.

I worked for Brad Larson for a year. He told me that the reason he got into making Molecules and got into OpenGL and doing GPUImage was because he had a free period at WWDC and just decided, on a whim, to watch a session on OpenGL. It’s crazy to me about how things you do on a whim or by chance can completely change your life. By not being exposed to these sessions over the last few years, I have been cutting myself off from these chance encounters to find something truly special that I can learn and make my own.

It has been a great gift to get to participate with WWDC from home. Being able to get up and walk around during a session and cuddle with Delia while listening to people give their talks has helped me tremendously. I can talk to people on Slack from all over the world about the sessions as they happen so we can all be excited together. I know that people get something out of being there and getting to talk to the engineers, but for someone with mental health issues that prevent them from being able to be comfortable with massively large amounts of people, this has been a godsend.

I am planning in the future to go back and watch all the videos from previous years that I never watched because they took too long. I can have them on in the background while I work on other things. I can pick out the parts that interest me and look into them further.

For the first time in a really long time, I am excited about iOS development. Thank you Apple for giving that back to me.

Minimum Viable iOS Engineer

Parable of the Shrew

My father works at the Botany Department at UW-Madison. When he was a graduate student he worked as a naturalist at a state park in South Carolina. When I was growing up he told me a lot of stories about this park. One story that he told me in particular has stuck with me most of my life. I have been meaning to write a blog post about it, and I feel like now is the time.

One day while he was working at the state park, he found a shrew. A shrew is a small rodent that eats crickets. My dad captured it and took it back to the office with him. He knew it ate crickets, but wasn’t sure how many or how long it had been since the shrew had eaten. He wanted to be safe, so he put the shrew in an empty aquarium with a hundred crickets, figuring that would be enough.

He came back the next morning to find the shrew dead on its back with all four little furry feet in the air. It was surrounded by dead crickets. The shrew was so fixated on killing every cricket in the aquarium that it forgot to eat any of them and it starved to death surrounded by food.

Resist the Temptation to Be the Shrew!

Yesterday Apple had their announcement of the new tvOS, along with a lot of other new toys that made my head spin.

I noticed a lot of people dropping the watchOS stuff to pick up the new tvOS stuff because it was the new thing and they didn’t want to get behind.

I want to say something that is going to make you feel bad. Take a deep breath. Relax. Here goes.

We have reached a point with the platform where we can’t know everything.

When I started programming I figured I would learn a few languages to cover my bases and give me options for when I went looking for a job. I realized that this was a bad tactic so I picked the one I most wanted to work with. I have further specialized to more and more specific areas of Apple development.

Every time that something new and shiny is announced, I feel compelled to learn something about it. I have Ray Wenderlich’s WatchKit by Tutorial on one of my computers and I don’t know if I have ever opened it. I also have their Animations, Core Data, and several years of iOS By Tutorial in a folder on my computer unread. I feel an incredible amount of panic because no sooner do I hear an announcement about something, my Twitter feed explodes with people who have dug into the docs and are sharing what they read. I have barely processed that something new has come out and already people are doing something with it. It gives me tremendous anxiety and makes my head spin.

I have been working myself into a tizzy just trying to keep up with what I am doing at my job. I have not used the iOS frameworks in about a year. I have a book out on iOS development but I don’t use it every day and it’s basically gone from my memory. I know if I had to use it every day I would pick it back up again fairly quickly, but it still disturbs me that I just don’t remember this any more.

I keep feeling like I need to know Core Data and Networking to stay marketable. I have a list of things that I think I need to know because if I don’t know them then I am not a real developer and people will shun me when they find out. This fear leads me to work all the time. I regularly suffer from exhaustion. The last two weekends I spent two days in bed internally screaming at my body for giving up on me because I have deadlines I need to meet and I don’t want to let people down.

I can not continue this way. If you are going through this, you can’t do it either.

This year at 360iDev there were a lot of talks about the death of independent development. We’ve moved beyond the point where you can make an app in your free time on nights and weekends that is going to be a minimum viable product. Believe it or not, this is a good thing.

Back in 2009 when the platform was relatively new, you could know everything. It was possible. The reason it was possible was because the platform was incredibly limited. There were a lot of things you couldn’t do, or couldn’t do easily. Now we are living in an embarrassment of riches where almost everything is possible, which means YOU CAN’T KNOW EVERYTHING!! Stop trying!

What is the Bare Minimum You Need to Know

I celebrated my first work anniversary on Tuesday. Before that I worked at a start up for two months, worked on an OpenGL contract application for three months, coauthored a book, and did over a dozen conference talks. I have a shocking amount and diversity of experience for a developer who has less than two years of experience.

I don’t know Core Data. I don’t remember most of iOS. I haven’t worked with Interface Builder in a year even though I intended to specialize in graphics and design for iOS.

I think that the amount of things you need to know to be a beginning iOS developer is smaller than most people think.

I talk to students at the tech school I attended and all of them think they need to know a lot of stuff. I would argue that you don’t need to know a lot of stuff, but the stuff you do need to know you need to know well.

Here is my list of what I think you absolutely need to know to have an entry-level iOS job:

  • Some fundamental understanding of either Objective-C or Swift. Both of these languages have a lot of unique aspects and I would argue it is important to have enough of a grasp of one of these to understand why you don’t program them like Java or some other language.
  • The MVC design pattern. This is a fundamental pattern that permeates all of iOS. If you do not understand this pattern, you will not write good iOS code. It is vital to understand this.
  • Know how to use the Apple documentation to look up how the frameworks work. You can’t know everything, but you at least need to know how to learn what you need to know.

I think knowing Core Data or Networking or any of the other multitudes of things are nice career embellishments, but I think if you are looking to bring on an entry level person and train them, this is what they need to know.

I don’t know how to do Networking. I have never had to know it for any job I have had. Same with Core Data. I know a lot about things most people never need to use like how to connect to a FireWire camera and how to parse LibXML2. These are things I learned because I needed them for the job I have. If I were looking for another job I am sure knowing Core Data would make me more marketable, but I wanted to find the right job for me rather than being qualified for a lot of jobs that aren’t really a good fit.

I don’t think not knowing how to do NSURLSession or how to make an Apple Watch app makes me an impostor or a bad developer. They haven’t affected my ability to get a job yet and I don’t think they ever will. If I need to learn them for something I am doing, I know enough that I can teach them to myself and if I forget them again, then I wasn’t using them.

I worry about people spending so much time learning “superficial” stuff that lets them build an app but does not teach them how the app works so it can’t be applied to anything else. I think instead of creating an aura of fear at not knowing everything, we focus on what is the essential amount you must know and enable people to learn the things they need to know to specialize or that interest them.

Specialize

At 360iDev last year Saul Mora and I were discussing the possibility of setting up something like a co-op for developers. If you had an app idea where you needed to know something you didn’t know, you could post it on this message board and if someone knew how to do it, you could negotiate working with them on it. I don’t particularly want to learn a bunch of stuff I don’t care about to make something and I would love to work on someone else’s project only doing the things that I want to do.

Like all good ideas that are formed by committee, this got bogged down in a lot of implementation details and forgotten. I still think this is the only way for independent development to move forward.

If you have a group of four people with different technical skills working together, you can put out a really nice app in your spare time. The gold rush is over, but I would hope that some people are involved in app development because they enjoy it and have ideas they want to share with the world.

I feel that Ray Wenderlich has embraced this idea. He has a large team of people working together on the tutorials because it simply got to the point where he couldn’t do it alone. We have a large pool of knowledge and resources and we are able to accomplish more than any one person could. I think he’s a great example of what you can do if you start trying to think cooperatively rather than singularly.

I think we need to move away from the idea of the solitary developer working in their basement over a weekend and move towards the idea of having a team of friends you can work with and share ownership of a product with. Even if the app never earns a dime, the act of working with your friends to make something you are proud of is a goal in and of itself.

So, to everyone feeling shitty because you can’t keep up with the new and shiny, stop it. Go easy on yourself. We’re at a turning point where things are going to be different and you can’t hold yourself to those standards anymore. Focus on the fundamentals and what is important to you and you will be fine. The platform has matured and it’s a good thing.

Functional Programming in Swift: A Chapter by Chapter Analysis

I preordered the book ”Functional Programming in Swift” shortly after it was announced. I got a chance to meet Chris Eidhof at 360|iDev, which was a really awesome experience. He really knows his stuff and he is a wonderful person.

However, I have found it has been a little difficult to get into the Functional Swift book. I know there is a lot of really important content in here that I think is vitally important for people to be aware of, but I feel like it is being presented in a slightly obscure manner. This is not a beginning programming book and it can be a little difficult to break into.

I am trying to write more technical posts on my blog. I wasn’t doing this for a while because I was working on my book ”iOS 8 SDK Development.” I was so stressed trying to learn all the stuff we were writing for the book that the thought of going and writing technical posts for my blog was a little discouraging.

Now that the book is pretty much completed and I don’t have any conference talks to prepare for a while, I would like to spend more time writing technical blog posts. One series of posts I would like to do is analyzing the Functional Programming in Swift book.

I was a beginner not too long ago and I know how incredibly daunting it can be to be confronted with a bunch of technical stuff you don’t quite grok yet. I know that Chris is passionate about functional programming and I hope that he will not be offended by my efforts to spread the word about his work and to try to sugar coat it a little for people who are not as far along as the target audience for his book was.

I am going to try to tackle a chapter every week or two. If I am slacking on this, please harass me on Twitter so that I know that people are actually reading and getting some use out of my posts.

If people have things they would like me to write about, please hit me up on Twitter about it. I am happy to go out and figure something out that people want to learn more about.

I hope that doing this analysis will open new people up to things in Swift that weren’t possible in Objective-C. I know that right now it is very hip to hate on Swift. I was rather unhappy about Swift when it was first announced because I was under the impression that many things we do were going to be abstracted away. I didn’t like Ruby on Rails because you could write three lines of code and have a functioning website without understanding anything going on under the hood. I am an incredibly curious person who wants to have a deep understanding of how things work. When I was able to shift my perspective on Swift I became very excited about learning a new way of doing things. I hope that other people will do the same when they become familiar with how to effectively write Swift.

If you want to know what my current long-term project is, check out this blog post from my boss, Brad Larson. So far, we have not found anything we have wanted to do that could not be done more efficiently in Swift. We have had to use a few work arounds with the compiler, but we have not encountered any show stoppers.

I have been disappointed with all of the people who are claiming that Swift is broken and that it shouldn’t be used for serious projects. If Brad and I can use Swift on the Mac to communicate with an electronics board through a serial port, you can figure out how to use Swift to communicate with an API. It is just a question of working with the language, not fighting against it.

I hope over the next few months I can help others learn how to work with Swift. I think that is is a promising language and I hope that people can learn to open their minds to new ways of thinking about how to program.

Lexical or Preprocessor Issue

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.

Heavy Metal

Hair Force One announcing Metal

Hair Force One announcing Metal

I know that the big new hotness from WWDC 2014 for most people is the Swift programming language. Swift has a large impact on me and on the project I am working on that I can’t publicly announce yet, but that was not the most intriguing thing announced to me. The most interesting thing that captured my attention was Metal.

I have been interested in learning OpenGL ever since I heard about it. I had to make the terrible choice last year of choosing whether to learn OpenGL or Core Audio because it would be complete idiocy to try to learn both at the same time. Since Chris Adamson didn’t write a book on OpenGL, I made the choice last year to learn Core Audio. It was the first programming book I read cover to cover and I got to spend a day with him in Boston at CocoaConf doing Core Audio. That was an amazing experience, but it’s time to move on to the next thing.

I started to learn OpenGL ES in earnest back in March. I had a few books and I have primarily been reading the same materials over and over again hoping that my brain translates them.

GPUImage

GPUImage

One accepted way learn OpenGL ES is to work on the GPUImage framework. There is a great blog post about how to write a custom shader here.

I decided a good way to learn OpenGL ES was to do a talk on GPUImage. Many of the tutorials I have seen on the framework basically just tell you how to plug it into your project and use the built-in filters. I wanted to do a talk about how the framework actually works and how to write your own filters. The creator of the framework, Brad Larson, lives in town. He has been extraordinarily generous with his time and knowledge about OpenGL ES. I pitched this talk and got it accepted at two different conference: CocoaConf Columbus and 360|iDev in Denver. Both of these conferences are in August. I pitched these talks around May. I figured that would be a decent amount of time to figure all this stuff out.

Then, like everyone else, I got slammed by WWDC.

I know that I don’t have to talk about Metal. It’s only been publicly announced for a few months and it only works on a handful of devices. There was no reason I couldn’t just keep my original talk topic. No reason except I had some existential questions I wanted answered.

Every time I heard about GPUImage I heard it was faster than Core Image because it was programmed on the GPU. What does that mean? All of my research on OpenGL ES says to push as much work off the GPU as possible, but they never specify what work the GPU is doing. I read a whole book on OpenGL ES without having any real clue what work is being done on the GPU.

The Defending Champion, OpenGL ES!

The Defending Champion, OpenGL ES!

I really wanted to do a talk on how to optimize OpenGL ES. I also wanted to explore what exactly it was that Metal was doing that was so much better than OpenGL ES. I heard a lot of bemoaning about how slow and inefficient OpenGL ES was, but after talking to Brad about it for a little while, I wondered if the mob was wrong.

I am doing my first talk on Metal three weeks from today. I have exactly one slide from my talk done as of 1:00 this afternoon, but I am in the process of gathering the answers to my questions.

One resource I can’t recommend more highly is the video tutorial series done by Ray Wenderlich. I had a list of questions in my head that I now have answers to because of his series on OpenGL ES. I am a quarter of the way through it and subscribing to his video tutorials is the best money I have spent on tech resources this year. It is my hope that one day he will produce a 3D graphics programming, hopefully after I know it well enough to be able to contribute to it!

So, I am going to take some time, but not too much, cataloging my work on this talk. I also have a debugging talk to complete in three weeks along with some obligations for my unnamed project. I think this is doable if I don’t have a panic attack or get distracted by squirrels.

The Famous Utah Teapot

The Famous Utah Teapot

I am planning to include links in my blog to any resource I have found to be particularly useful.

My goal before going to CocoaConf is to have a working Metal application with a few of the GPUImage filters translated from the OpenGL Shading Language to the Metal Shading Language. I would like to show the performance differences between GPUImage and Metal using the same project. I would also like to be able to intelligently explain GPU programming to people who are coming into this without knowing anything about OpenGL.

Three weeks. Two talks. Git ‘er done!

Why I am Not at WWDC

Seeing a lot of the normal “Why are there no women at WWDC??” posts that tend to come out this time of year. I want to offer my very limited perspective on why I am not at WWDC.

I did not enter to win the WWDC Golden Ticket lottery because I could not afford to go. It isn’t just the cost of the ticket. It is also the flight and the cost of the hotel. I estimate going to WWDC costs about five grand.

Five grand is a lot of money. That is a Mac Pro or a vacation to Europe.

There are a lot of people who go out there who do not have WWDC tickets who still paid between three and five grand to just be out there and talk to their peers.

My understanding is that a lot of people who go to WWDC work for companies that pay those expenses.

I don’t work for a company. I used to, but that company did not really value sending people to conferences, so I doubt they would have paid to send me even if I were still there.

I took two years off to go back to school to learn programming. I am now in the rocky process of trying to establish myself as a professional.

I have some health issues that prevent me from being able to work all those crazy hours that are expected of you if you work at the kinds of innovative start-ups that want to do cutting edge iOS technology or have enough money to send people to go play with the new toys.

Replace health issues with family issues and you will see the problem a large number of women have trying to get to something like WWDC. Even if you can afford to send yourself, you are still leaving your children/family for a week to go run yourself ragged.

For better or worse, women are still the primary caregivers of children. My conference excursions are becoming longer and farther away and it is causing an issue between my husband and I. He doesn’t think it is fair that I am going off on these trips without him and expecting him to subsidize the costs associated with them. Even though I am a speaker and many of the costs get taken care of, there are always some costs that we wind up paying.

There are two easy things that Apple could do to get more women at WWDC:

  • Set aside 100-200 tickets for women in technology. Either set it up as a lottery or have women apply using an essay or something. Try to pick people who are doing interesting things and not just the token woman board member at Zynga.
  • Do something to help ameliorate the cost. Waive the cost of the ticket. Set up a roommate system so that if you want to spilt the cost of a room with another woman you can do that to save money. Each time I have gone to CocoaConf Chicago I have ridden down and roomed with a woman I met when I picked them up to go to Chicago and both woman became very good friends.

I will probably never work for Apple. I can’t afford to move out there and I can’t work the number of hours expected of an Apple engineer. I probably won’t ever get to go to WWDC. I think it is disappointing because I would love to go to all of the OpenGL and Core Audio labs and sessions that I hear are a ghost town because no one cares about them. I am working within the constraints that I am given and doing the best I can.

Apple could make bringing women to WWDC a priority. They think bringing students to WWDC is a priority and the set aside 150 tickets for students. If they wanted more women there, they would do that for them too.

But then again, they would also set aside tickets for a lot of the prominent iOS companies that got shut out of the WWDC lottery. They probably had 100,000 people enter into a lottery for 5,000 tickets. They could double or triple the cost of a ticket and still sell out every year. They had nearly 400,000 people download their Swift programming guide within a day of it being announced/released.

Apple is going to do fine without people like me. I can throw a hissy fit about them not including me, or I can just accept the fact that I am in the same boat as a lot of other people and do the best I can with what I have.

I am not going to have the same career as everyone else. That doesn’t make what I do any less relevant than working at Facebook or trying to create a social photo sharing start-up. I don’t think I have to measure myself based on what other people use for measures of success.

To quote a famous philosopher:

“Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. But the only thing you can’t do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”

Just because I am not at WWDC does not mean I don’t exist or that I am not a developer. We’re out there. It might take a while, but you will see more of us. I am not quitting.

iOS 7: The Year that Was

iOS 7 was the first new iOS that I remember having to learn. I started around the time iOS 6 lifted its NDA, so all the books I was reading were out of date with Modern Objective-C.

Since iOS 6 was sort of my first one, I don’t really remember anything “new” from it. Everything was new and I was simply in a panic to try to learn the basics before everything up and changed on me again.

That was different with iOS 7. I had enough of a grasp on iOS programming to be able to grok the differences between it and iOS 7. The fact that there were a multitude of changes stylistically helped things tremendously.

With WWDC just around the corner, I have been talking to some people about iOS 7. Specifically, what worked and what didn’t. There were a lot of new APIs and technologies that were supposed to revolutionize how people created and designed their apps. Some of these technologies were the focus of several WWDC talks. How many of them were actually implemented and have changed the way we design our apps?

  • Borderless Buttons: Borderless buttons are among the most despised changes that I have heard people openly complain about. I can’t find anyone who likes the borderless buttons. Everyone I am encountering is trying as hard as humanly possible to ignore that part of the HIG. I haven’t looked recently, but I think that in Xcode 5 they removed the ability to give a button a border in IB. It seemed to me that this was something Apple really wanted people to be doing, but so far everyone I talk to is avoiding it like the plague. Will be interested to see if Apple backs down on this or if no one is actually going to give a crap about it.
  • UIKit Dynamics: So, Apple wanted developers to add motion effects to their apps? UIKit Dynamics was kind of cool, but it looked very much like a stripped down Sprite Kit. I think it might have been possible to find something new and unique to do with dynamics, but it just seemed like those obnoxious JavaScript effects you used to use on your Geocities site back in 1995. I would love to see someone figure out a neat and innovated way to use these, but generally speaking they don’t really contribute anything to the functionality of most people’s apps.
  • Translucency: This one confused me tremendously. I think that having the interface be layered with translucency could have been a really cool thing to do, but to the best of my knowledge, Apple did not provide built-in functionality for this. If you wanted a blur effect you had to roll your own. If Apple wanted this to be the preferred way of doing things, I wonder why they didn’t make it easier for developers to adopt.
  • Text Kit: Text Kit was the subject of at least three different WWDC 2013 sessions. It seemed like it was an API that Apple was promoting and pushing very strongly. I know that there were some easy implementations of Text Kit to make the text responsive to the user’s font size settings, but I haven’t really heard anyone talking about Text Kit.

    I know of one person doing a talk on it at CocoaConf, but my impression was that this experienced developer was having trouble using it.

    It’s possible that people have done the easy implementation of Text Kit into their apps, but again, not really seeing people getting excited over it and not seeing people evangelizing it, at least not to the extent that I thought they would.

  • Sprite Kit: Again, this surprised me. I know when this was announced that it was a very popular subject with students in my iOS classes. There was a lot of genuine excitement around Sprite Kit.

    I have seen a couple of books about it, but I am not really seeing a lot of people advocating it. I am wondering if it because people already know another engine like Cocos2D that would allow them to port to other systems or if it is because people are not enthused about making game for the iOS platform anymore or what is going on with this.

  • Auto Layout and Animated Transitions: Going along with some of the other style changes from iOS 7, this was another thing I don’t see people doing much with. I have been trying to learn Core Animation, but with the renewed emphasis on Auto Layout, it has been tremendously difficult trying to reconcile those two battling pieces of technology. Auto Layout wants to keep everything in one place while Core Animation wants to make things move. We are supposed to utilize both of these APIs, yet again Apple does not make it easy to reconcile them.

Where Do We Go From Here?

I am wondering what impact iOS 8 is going to have on developers. I am wondering if, since there was such a radical change to the UI, people have simply not had time to explore any of these new APIs.

I am very interested in graphics and a lot of these APIs excite me a lot. Talking to other developers, many are not as focused on these things as I am. They focus on things like Core Data and table views and networking APIs.

So far not utilizing these new APIs hasn’t prevented anyone from putting an app out on the store.

I hope that in the new few years people become more comfortable with things like Text Kit and we see some real innovations in how people create apps. I don’t know if that will happen.

At CocoaConf Chicago, Justin Williams made the knowing joke about every iOS developer waking up in the morning deciding to make a weather app. I have observed that people want to do something that is easy or at least not particularly innovative.

When was the last time you saw a truly innovative app out on the store? I think we are stuck in a self-perpetuating cycle where app developers make something easy that already has a dozen instances on the store, doesn’t make money off of their app, then decides app development is a burst bubble and refuses to put any more effort into it.

I think there are a lot of possibilities out there for people willing to dig into these “new” APIs. I hope that in the next few years more people are willing to give this a shot and do something innovative. I would like to do something innovative (if I ever get any free time!!).

Again, this was the first year I saw a new iOS from beginning to end. I don’t know if any of these are going to be considered failures or what is going to happen in the coming few days, but I was very excited about a lot of what I saw last year and I hope that it is given some more time for people to get used to and to explore, along with all the other neat things we will see next week. I have faith.

AVFoundation Audio at CocoaConf Chicago 2014

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.

I Don’t Want to Bother You, But…

I am currently working on trying to figure out AV Foundation. AV Foundation, very much like the rest of Core Audio, is not very well documented. It has been broadened and expanded the last few years and a lot of the material out there in the world is from 2 years ago, which is a century in Apple development time.

I feel unsure about how I am proceeding with this. I go into the Apple documentation and see that there is a programming guide! Cool! This will be easy.

Then I look online and I see developers talking about how the guide is really out of date.

I ask a developer what to do. His answer: Watch the WWDC videos and visit the developer forum.

I get ready to do that and I notice that the guide was just updated less than two weeks ago. Great! That means it is up-to-date and comprehensive, right? Not necessarily. Watch the WWDC videos and visit the developer forum.

I don’t want to bother anyone. I feel bad that I am asking things that keep getting the same answer and I worry that people think I am dumb or I am not listening to what they are saying. I don’t want to be a time suck to people who are high level developers who need time to actually do work.

I don’t know if this is just a stage everyone who is interested in audio programming goes through, where you think, “There has to be more than just this.” Yes, somehow people who are experts on this stuff don’t know that there is some super secret easy guide to doing these things that I am going to magically find because I am a special unique snowflake who doesn’t have to deal with the same issues as everyone else :p

I really want to be a self reliant person who can look things up and figure things out. I keep hearing from two different camps of people. One camp says never to ask any questions because it will make you look stupid. The other camp says that asking questions is a good thing to do.

Earlier in the year I could not get a VM working on my computer. I took it to my teacher. He tried one or two things for a little less than a minute then immediately got up and started asking the teachers around him about whether they encountered that error before and how they would fix it. Five minutes later we resolved the issue and it was working.

I think it is good to ask questions, but I get wary when I notice that I am getting the same answer to a lot of the questions I am asking. I hope that if I can show that I listened to what I am being told and can follow through with it that hopefully my earlier obtuseness will be forgiven. Apple development is a small community of people and audio development on the Apple platform is an even smaller community of people and I don’t want to be known as the person who can’t figure things out.

Okay. Existential crisis over. Time to get to work!