2013.

Unlike 2011 and 2012, 2013 was less of a year of new things. This past year was a year of focus and learning. By now, I have settled into college life, and have already lived and worked in the Bay area for two summers. I am no longer a teenager, and have entered my twenties. Overall, I spent more time working and thinking, and became more deeply involved in what I did in my everyday life – whether it be relationships and friendships, software engineering, or schoolwork.  

I spent less time on social sites, and instead spent more time reading. I took more of an initiative to keep my things organized and my room clean. The past few years were focused on breadth – more people, more topics, more adventures, etc. This year I still had those interests, but instead had more of a focus on depth – really learning about my friends, taking time to learn computer science and what it takes to be a good software engineer, reading up on music, coffee, etc. Instead of wasting a ton of time on Facebook , constantly refreshing the page to see if any friends posted a new picture or if I have a new notification, I would spend time looking up bands I liked, or reading more technical websites on computer science and programming. I found myself wanting to spend more time with a smaller group of friends, rather than spend my time at larger parties or events with lots of people I only barely knew.

It was a good year. I was able to spend a summer at Apple in California working on iOS as an intern. It looks like I even (hopefully) got a patent out of it. I drank a lot of coffee and talked to a lot of cool people.

2014 will be interesting. I will be entering my final years of college, and be turning 21. I am excited.

This past summer.

This past summer I was able to spend a summer in Silicon Valley working at Apple.  I was a software engineering intern, working on iOS. I also lived in downtown San Francisco with some of my best friends from the University of Michigan. I learned a ton of things and would by far call this summer one of the most important times of my life. Here are a few thoughts.

Apple.

When I found out I had an offer for a company I had been obsessed with since I was about 13, I honestly didn’t know what to feel besides an incredible amount of  excitement to start working. It would be impossible to write out and explain everything that I learned from Apple. Apple isn’t simply a company that people go to because they want to just make some money and do whatever they got a degree for.  People end up at Apple because they love what they do, have strong opinions, and want to build incredible products that impact millions and millions of people. Everyone you meet at Apple is there for a reason.

Beyond just caring about their work, people at Apple seem to do something incredible: they combine what they truly care about with whatever they do for Apple  producing authentic, incredible products. Whether the interest was  parasailing, reenacting Shakespeare, or owning a winery,  everyone brought these sometimes bizarre, quirky interests to work and produced some really incredible things. The best work of your life comes by combining all of your interests, not replacing your passions and interests with some job that pays the bills.

Additionally, Apple maintains their culture by embracing a brilliant mixture of psychedelia/surfing/engineering/music/art/zen/liberal arts. In addition to discussing how to optimize the performance of a UITableView, my manager and I would discuss what music we both liked, where to take good road trips, and what lenses I should buy for my camera.

Silicon Valley Internships. 

Although I am  biased, I would say that interning at a company in silicon valley is one of the best experiences you can have in college, and will truly change your life. You will meet people who are very similar to you from across the world, and have a few months to hang out with them and have the adventures of your life. Much of the “growing up” I have done in college has been during my summer internships, and not so much during my school years.  Internships are a perfect intersection of the exploration and learning of college with the freedom and work of the real world.

Other Things I Learned. 

I have smart friends.

Mission Dolores Park is a way of life on weekends.

IMG_5545

Summer bonfires on the coast are fantastic.

IMG_5912

San Francisco is not cheap.

San Francisco is much more amazing if you explore the neighborhoods and become well acquainted with them.

Tim Cook loves oreo froyo. (There is a very stalkerish photo I have somewhere on my instagram if you really are that curious.)

Taqueria Cancun will forever make Chipotle taste bland.

Road trips are fun (especially in nice cars)

IMG_6375f2466ed601ff11e3b2e322000a1f9a5c_7

Chris is impossible to wake up on weekends.

Sam hates chalk.

Storyboards/Nibs vs. Doing Everything With Code in iOS

When you start working on a new app, one major decision that needs to be made is whether you want to do all of the interface work graphically (through xibs/storyboards) or programatically. Each method has pros and cons. Hopefully this post will help you make the best choice for your project!

Why Storyboards are Actually Really Cool…

With my experience, I have found that the best time to use interface tools to build your app is when you are quickly prototyping something by yourself. If you are at a hackathon, or playing around with a new app idea, doing all the interface work in storyboards is actually quite ideal. You can very quickly iterate and pump out a half decent functioning app in very little time. Additionally, if you are just beginning iOS, it is incredibly helpful to have the ability to visualize how code is linked up to a functioning interface. Even though I usually don’t use interface builder in projects now, it greatly helped my understanding of iOS development by allowing me to visually link snippets of code to the graphics I would see on the screen. This is really cool, and makes concepts that can be hard to comprehend very intuitive. 

Why Storyboards Aren’t Always that Great…

So, even though Interface Builder and Storyboards are a really cool technology and are fantastic when learning and prototyping things on iOS, as you begin dealing with source control and collaborating with other developers, you will rapidly run into issues. For example, lets say I am on a team of developers, and by accident two developers fix the same bug or add or overwrite something on the same view using storyboards. This will cause a merge conflict (assuming you are doing source control with git). Now, since the actual interface “code” generated by Interface Builder is non-readable xml, it can be nearly impossibly to fix even the smallest merge conflict in a massive storyboard file. This could lead to massive amounts of work being lost or corrupted. This is a very bad thing. 

Next, since storyboards are essentially a level of abstraction on Cocoa, it can be much harder to do customization of UI. For example, if I wanted to recreate the now popular interface flow of sliding the main view controller to the right to access the side menu view controller, I would have to get a reference to the two view controllers and navigation controller stack.  If I built the app doing everything programmatically, this would be fairly straightforward and also be pretty clean code. With Storyboards however, just to get a reference to a single view controller I would have to do something like this:

MyViewController *controller = (MyViewController*)[mainStoryboard
instantiateViewControllerWithIdentifier: @"<Controller ID>"];

This is kind of gross and unnecessarily long code. Also, with this additional abstraction, it could be much harder to track down small bugs and other flaws. 

Finally, if you are working on a very large project over the course of a few months, if you have everything involving the interface in one place organized by the name of the view it is way easier to track down what happens where, and know where to add or remove code. If you have parts of interface “code” in a storyboard and part of what is driving the interface living in a .m file, it can become very confusing as to what actually controls what. 

 

 

 

A few thoughts after my second year at Michigan

Last week I finished my sophomore year at the University of Michigan for computer science. I had a ton of great experiences throughout the year and here are a few things that stood out.

1.) Computer Science and Software Engineering != Knowing to code. This new trend of “learning to code in 10 days” needs to stop. It is simply not the same as learning to build high quality software, and learning how to understand and interpret complex systems and problems. While yes, I knew how to code last year, I was nowhere near the ability to solve complex problems as I am now after taking more computer science courses and spending time learning how to approach larger, complex problems.

2.) Find friends that push your limits. (in different areas) Find a friend that is a genius at (or at least passionate about)  math, programming, art, english, etc. By having friends who are experts in fields different from your area of expertise, your conversations will be a blend of what you are good at and what they are good at. This will naturally lead to ideas that are cross discipline, both making you more creative and open minded.

3.)Explore. By far, some of my best times this year were those not on campus. I was lucky enough to take several trips with Michigan students. First, I was able to go to UPenn for a huge student hackathon. Being on a huge bus full of 50ish computer science majors and exploring the city of Philadelphia was a ton of fun – and lead to some great ideas. It was also fun building an iPhone app with friends for two days with little sleep. Next, I was able to go to San Francisco a few times – once for interviews, once for a conference – with fellow students. It was such a powerful feeling to have 20-30+ students travel 2000 miles and take over a city for a week. During the second trip, Michigan students also assisted at the conference making a huge impression on all of the recruiters, developers, and other people at the conference. They were amazed so many passionate students would use their spring break to come to a tech conference and hackathons to build products (or show off previously built projects)

4.) Never become comfortable with your current skills or abilities. It is critical that you never become too comfortable with your current level of abilities or knowledge. Constantly push yourself to either know something even better, or learn something new.

JSButton: A simple way to pass blocks to buttons and trigger them with a UIControlEvent

My friend Josh Sklar (a senior at Michigan, and soon to be full time iOS dev at Detroit Labs) wrote a very cool subclass of UIButton that allows you to pass a block to a button and have it executed with a given UIControlEvent.

For example, instead of creating a ton of selectors, you can now simply do:

JSButton *buttonOne = [[JSButton alloc]initWithFrame:CGRectMake((self.view.frame.size.width - kButtonWidth)/2, kLabelHeight, kButtonWidth, kButtonHeight)];
    [buttonOne setTitle:@"Buton One" forState:UIControlStateNormal];

    [buttonOne performBlock:^(id sender) {
        JSButton *btn = (JSButton*)sender;
        NSLog(@"Some trivial code for touching up inside on %@", btn.titleLabel.text);
    } forEvents:UIControlEventTouchUpInside];

    [self.view addSubview:buttonOne];

Here is a link to the repo: https://bitbucket.org/jrmsklar/jsbutton

Developing for iOS by yourself vs. on a team.

When developing for iOS on a team of several other iOS devs, the way you approach and architect the overall project should be different from the way you would personally build an app. Neither approach is “better code” but each method simply allows for time to be saved in each situation. 

When developing an app on your own, it may be beneficial to use storyboards and .xib files in your project. The reason you want to avoid using these graphical files in a team setting is mostly version control. Since these graphical files automatically create large XML files that then compile into interface code, merge conflicts often occur when several people touch the same interface files. When you are working by yourself, since you will likely be the only person working on the file at one given point in time, merge conflicts should not occur. Additionally, writing all code for the interface may give more flexibility and allows for more customization of interface elements. 

When creating the overall flow of the app and figuring out a good code organization pattern, be sure to make code as modular as possible in a team setting. Although this is always a good practice even when working on your own private project, it is essential when on a team. Over this past summer, while working at Path, I quickly learned the benefit of modular code. One of the other iOS engineers on the team and I were working on the same view, and we needed the ability to easily delegate tasks on the feature we were working on. Since we were not using Interface Builder, and making sure to use modular code, he worked on one aspect of the feature as a subview, while I built the rest of it. Since we were not sure how exactly we wanted to implement the UI, by creating a View Controller that looked for the same properties on a subview, we could easily test and swap out different implementations. This saved us a massive amount of time and allowed us to effectively accomplish tasks. 

 

Storing and Saving Data in iOS

So, this will be a fairly short post, but I frequently get asked about storing data in iOS.

Essentially, when it comes to storing data  in iOS you have several options:

  1. NSUserDefaults. If the amount of information you want to save isn’t terribly large, and consists of NSData, NSString, NSNumber, NSDate, NSArray, or NSDictionary, you can easily store it in NSUserDefaults. NSUserDefaults can be read/written to in much the same way you would work with a NSDictionary. For example:                                                
    NSString *test = [NSString alloc]init];
    [test stringByAppendingString:@"test!"];
    //creates string object
    
    NSUserDefaults *myDefaults = [NSUserDefaults standardUserDefaults];
    [myDefaults setObject:test forKey:@"string"];
    [myDefaults synchronize];
    
    //and this data can be accessed by:
    NSString *newTest = [NSString alloc]initWithString:[myDefaults objectForKey:@"string"]];                               
  2. If you REALLY insist on writing to a local text file of some sort, do not put it in your application bundle. The bundle is read only, and you will spend an absurd amount of time debugging this.
  3. You could use sqlite. Code can get a bit tedious and ugly, but it still works fine.
  4. Core Data. http://www.raywenderlich.com/934/core-data-on-ios-5-tutorial-getting-started

That is all!