Jan
05

Becoming A Mobile Developer

[message_box type=”info”] This week we have a guest post from new-ish LunarLincoln crew member Cory Wilhite. Enjoy! [/message_box]

Today there are a million ways to get started as a developer. From traditional routes like classes in high school and college to newer paths like coding bootcamps and self-taught routes through online courses, the resources are readily available to get into the world of programming. While we’ll go over the many different ways to learn about software development, we’ll also dive into why you might like being a developer.

Motivations

Technology is infiltrating every facet of our lives. With the phones we carry around, the computers we use, and now where even lightbulbs and refrigerators are computers, programming and computer science is the common thread that helps in understanding how the world around us works. Whether you’re interested in designing websites, mobile applications, building new uses for hardware, or even building tools for other developers there is something out there that needs creating. At the core of the many environments and concepts that involve programming is the common thread of logic, problem solving, and the desire to continuously learn new things. One of the more satisfying daily elements of programming is to find solutions for problems that you previously knew very little about.

solution

 

Whatever your motivations are, its important to know what steps you can take to either get started or further your education as a developer.

Traditional Paths

Up until a few years ago, the most straight forward way to start down the path to being a developer was found in academia. A computer science degree at college, and even earlier with AP computer science classes at high school. These programs focus on everything between the fundamentals of programming languages, the most optimal way to write software, and what makes a computer function. While often not being directed towards working with any specific technology or language, a computer science program will give you a broad understanding of the ways to write software and how to conduct research on deeper computer science concepts.

Self Taught Paths

There are several ways in recent years to learn programming through websites and online resources. One of the first websites to start online interactive learning was Codecademy. They provided free tutorials that a student could follow along with by actually completing code challenges in the browser all while learning that specific language or technology.

This concept of online interactive learning has been expanded on by several companies (e.g. Treehouse, CodeSchool, etc.) which also provide in-depth videos and quizzes to go along with the interactive coding exercises. A commonality between the online coding resources is that they make themselves accessible by focusing in on a language or technology that you might want to learn.

If a traditional computer science program is a broad stroke of knowledge about computing and software, these online courses are precise dives into a specific topic. They can be great as an introduction to programming because they give you the ability to get hands on and complete projects right out of the gate. On the topic of motivation, the feedback of being able to see your work in working product is a great motivator. Each day there are more and more resources to take advantage of online.

Bootcamps

With the introduction and success of online learning resources, there is a new type of learning resource that could be classified as being in between self-taught courses and a computer science degree. 3 to 6 month bootcamps have been cropping up (Iron Yard, DevMountain, etc.) that offer crash courses in different paths within the software development industry. These paths are more directly focused on the common career paths such as web developer (back-end and front-end), mobile developer, and even offering courses in becoming a user-interface/user-experience (UI/UX) designer. Where websites like Codecademy will dedicate a course towards one language like Ruby or Javascript, these bootcamps will base their paths on diving into the technologies and tools used currently in the industry for a specific career path.

How I got started

For myself, I took a mix of traditional and self-taught education. In high school, I took advantage of a web development class when I was first starting to get interested in programming. This lead me to further that learning with AP computer science. One of the important motivators in those classes was that they each left me with something tangible and just enough knowledge to be dangerous.

In my web development class, the final project was open ended and I took advantage of that by learning how to build a flash website. In AP computer science, our final project was to build Pong in Java. I ended up going to college for Audio Engineering Technology, but I decided to make my minor computer science because of those classes in high school and the interest I had in computers and programming. In between high school and college for me, Codecademy was just launching. I took full advantage of the free courses they provided at the time to learn Javascript and Ruby. I also utilized another company that was just launching called Coursera that featured real semester long college courses for free. I took classes that interested me (like Digital Signal Processing, Calculus, Game Theory) along side the education I was receiving at the college I went to.

It was a desire to keep learning and building on the knowledge picked up in traditional classes that had me pursuing further education on my own. Even after getting a job as a developer you never stop learning new things. Learning from other developers on websites like StackOverflow or following high profile developers blog posts to see what new techniques they’re experimenting with or problems they’re overcoming provide a deep community of knowledge and is something that I think separates the programming industry from every other industry out there.

If you’re thinking about going down the path to being a developer, find something you’re interested in and get started right away! Even if it stays as a hobby, theres always something to learn.

Mar
23

Mobile Madness – The Code

The results are in and the winners from yesterday are: Limor Fried, Erica Sadun, Jake Marsh, and Jake Wharton. Here is your updated Bracket.

[separator type=”” size=”” icon=””]

On to the third bracket of Mobile Madness 2016 with the numbers, the code, the languages and platforms. FULL STACK BABY!

First up: The Kings of the Mobile Kingdom

iOS vs Android

iOS and Android have been battling it out in the mobile space from day one. Globally, Android has a whopping 84.7% marketshare while iOS has only 13.1% (Q3 2015). Having multiple hardware manufacturers and OS distributions, Android provides many options to the end user, but at the cost of a consistent and reliable experience between them. iOS can deliver a high quality experience across all devices because Apple is fully in control of the design and production of their hardware and software, but it comes with a higher price point and fewer options.

AndroidvsiOS

So which wins? Beauty or Breadth of Market? Answer the twitter poll here

[separator type=”” size=”” icon=””]

Second Bracket: Everything to Everyone: Cross Platform 

React Native vs Xamarin

React Native is a version of Facebook’s React.js, developers can write javascript that controls native UI elements among other things. React has been praised for it’s architectural design and the resulting increase in developer productivity. Xamarin, recently acquired by Microsoft, is a cross-platform development solution for writing native apps in C#. It comes with a robust IDE called Xamarin Studio that makes building cross-platform apps a breeze. One major difference between the two is that React Native is open source, while Xamarin is not only closed source, but requires a monthly subscription to use (but you get real support!).


react-logo-1000-transparent

RDXWoY7W_400x400

 

Who knew we’d bit pitting Facebook against Microsoft in a mobile development battle. What do you think of these unlikely platform contenders?  Answer the twitter poll here

[separator type=”” size=”” icon=””]

Third Bracket: Languages in the Key of C

Objective C vs C++

While both languages are in the C family, Objective-C and C++ have some huge differences. Objective-C is a dynamic language where everything compiles down to C code that uses the Objective-C runtime library. C++ is usually compiled to assembly and has no runtime library which means it’s generally much faster. Most Objective-C programs are now compiled with ARC which will manage memory for you, whereas a C++ developer must be very careful of how they allocate and free memory in their program. Objective-C has proven very productive for writing high-level code such as UI or business logic. C++ is less productive but much more powerful when you need to work at a low level, like when implementing high-performance graphics or audio processing.


url

CPlusPlus

High brow or low power? Which C will it be? Answer the twitter poll here

[separator type=”” size=”” icon=””]

Fourth Bracket: Old Kids and New Kids

Java vs Swift

Java is generally accepted as the most widely used programming language today, and has been for some time. Swift is quite new on the scene, which only hit 1.0 in September, 2014. Swift has been acclaimed for it’s use of functional programming and value types which can help simplify problems in the minds of developers. Java works mostly with objects and reference types and only recently added functional programming capabilities through lambdas. Swift is entirely open source whereas only some Java implementation are (see OpenJDK). Swift still has much to prove for general use outside of iOS and Mac apps, but support from the open source community as well as big players like IBM is driving adoption for the language at a rapid pace.


Java7VM

icon

Answer the twitter poll here

Feb
29

Solving Hard Software Development Problems

One luxury we as programmers often take for granted is the vast wealth of others’ experiences available for perusal at our fingertips.  Rarely do we encounter a software development problem so challenging that Google and StackOverflow cannot offer assistance. However, when working with cutting edge technology, these elusive obstacles arise more frequently and I’ve dealt with my fair share of them here at LunarLincoln.

While there is no steadfast problem-solving algorithm, most code artisans (I’m hoping this name sticks) will first consult the web.  More often than not, the hunt ends here.  An experienced developer will know the specific keywords that will help narrow the search for the solution to their problem.

giphy-2

But what if you encounter a problem that nobody knows how to solve?
Worse, what if nobody else has ever tried to do what you’re doing?

This is where we have to break out the big guns. Let’s use an example.

When I worked on Compass, I was tasked with figuring out how to stop it from draining the user’s battery so much.  At the time I hopped on the issue, Compass was tracking location data, motion data, HealthKit data, calendar events, photos, weather and more.  All the time.  Yikes.

compassiconintegrations1

Unsurprisingly, most phones didn’t react well to this kind of stress, and the largest complaint we got from testers was the drain it had on their phones.

Since everybody knows that premature optimization is the root of all evil, I had lots of avenues of attack.  The first matter of business was to figure out the biggest culprits.  Using Apple’s Instruments program, I was able to run the app and observe the battery usage levels as well as find out which parts of the app were consuming most of the CPU cycles.  As it turns out, recording a user’s location was creating huge spikes in battery consumption.  Knuckles cracked and fingers wiggling, I was ready to take a stab at it.

Adventure Time Deer

The first thing I did was dig into the current implementation to see how it worked.  The app was always tracking location, even in the background, with the highest quality accuracy.  And that’s great for results, but bad for battery.  Fortunately, I had a place to start looking for a solution.  Todd had a pull request ready which he said improved battery life but was ruining the accuracy of the location data.  His idea was to use geofencing.  He would wait until a user stopped moving, disable the GPS, and activate a geofence around the user.  When a user had moved a significant distance, the geofence would trigger, and the app would resume high accuracy tracking until the user stopped moving again.

I thought that was a brilliant solution, but as I researched all my options for tracking location, I learned it wasn’t going to work as we wanted.  Geofencing just didn’t offer enough precision.

giphy

The location logger app

The location logger app

The second solution was the phone’s motion coprocessor.

We were already tracking the user’s activity state, and I opted to hijack this information to determine when to activate and deactivate the GPS.  When a user is stationary, turn off the GPS.  Otherwise, crank it up.

Now I needed to create the algorithm to make this happen.  To iterate on the fine details of algorithm, I created a really small, ugly, but highly functional app that tracked my location and let me plug in my actual activity state (to make sure the motion coprocessor was accurate).  I would walk and drive around the neighborhood to test its accuracy while measuring its battery consumption. (Ben even went on runs to test the running measurement, and may or may not have eaten it on a piece of random construction material. Sorry Ben!)

The location accuracy visualizer app

The location accuracy visualizer app

When the tests were done, I would export the data and compare the location data to the route I actually took.  I created another tester app just to map the travel lines.  Using this, I could see whether my algorithm was precise enough to meet our needs.

In the end, I was able to create massive gains in battery performance without any noticeable hit to location accuracy.  Of course, the app still needs a lot of battery, but my models showed that multiple more hours of idle use could be seen, especially when stationary.

This form of rapid prototyping helped immensely in crafting a solution to this open-ended problem.

Surely this wasn’t the only way to solve this problem, nor is this guaranteed to be the best solution.  But one of my favorite ways to tackle a problem is to build myself some proper tools.

 

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” – (Probably not) Abraham Lincoln

Feb
24

Tools We Love: Paw

icon128-2xHere at LunarLincoln, we’re always on the hunt for new tools that help us design, build, and test our apps and we’ve decided to share our favorites with you! To kick it off, we’re going to talk about a great app call Paw. Paw is a fully featured API client that can help you blaze through testing, debugging, and even implementing your networking calls. Whether you’re building apps or working server-side, Paw is guaranteed to save you time and frustration.

One of the most critical parts of mobile app development is integrating with web services. If you’re lucky, the service you’re using has wrapped up everything you need in a nice SDK for your platform. More than likely though, you will be talking directly to the API and have to hand roll each request to the server. This is where Paw comes in.

First, let’s talk about API clients in general and how they can help you. An API client, such as Paw, lets you configure HTTP requests, send them off, and inspect the response. This is great for developing against an API, as you can quickly work out the details of the request and response in isolation before you start mucking things up with your code. Without a standalone client, you’re left to tweak code, recompile, set breakpoints, pull to refresh, and  furiously debug your code until that elusive 200 finally makes it’s way back from the server. Now do this for each endpoint and do it again whenever you have bugs because, hey, it could be the servers fault (and it usually is right?).

tweak, pull to refresh, check, tweak, pull to refresh, check, tweak...

tweak, pull to refresh, check, tweak, pull to refresh, check, tweak, pull to refresh, check, tweak…

Forget that! We need to isolate the components of our system, allowing us to quickly narrow in on whatever isn’t working, be it the server or, shudder to think, your own code.

What makes Paw great?

Now that we understand the usefulness of API clients, let’s look at what separates Paw from the rest of the pack. A lot of Paw’s great features are made possible through extensions to the program. Many great extensions are built-in, but they are also written and submitted by the community, so if you can’t find what you’re looking for, you can always build one yourself. Extensions are little bits of javascript that add functionality to Paw, and they fall into three main categories: code generators, importers, and dynamic values.

Code Generators

One of the great features of Paw is to take one of your saved requests and export it in code specific to your platform. There are code generators for most major development platforms and even some specific to certain networking libraries, including AFNetworking (and Alamofire), jQuery, Ruby, Python, and even cURL to name a few. Code generators are an excellent way to make sure your perfectly configured request doesn’t get lost in translation when implementing it in your codebase. There’s even a generator that will produce a human-readable form of the HTTP request, which is great for communicating with API developers and providing example requests.

Importers

Importers are the inverse of code generators, taking code or domain specific languages and turning them into Paw requests. This features really shines for API definition languages like Swagger or WADL. These languages can be used to generate API code, but with the right importer can also produce a matching set of Paw requests for each supported endpoint / method combination. There’s also a cURL importer so you can stop banging your head against the terminal. If you’re currently using Postman to test API’s, Paw has given you an easy out with an importer to migrate all of your Postman requests into Paw. Now you really have no excuse!

Dynamic Values

Dynamic value extensions allow you to use macro-like functions that either compute a value or pull it from somewhere else. Paw can even carry out something as complicated as OAuth to get an auth token as a dynamic value. One common use case is the need to apply a hash to a password before sending off a log in request. You’d be very sad if you had to manually hash the password, especially if you’re testing with multiple accounts. Instead, create a dynamic value in your request body that will hash some input value. Fun fact, inputs can even be another dynamic value!

 

 

Screen Shot 2016-02-23 at 10.55.27 AM

 

Another use for dynamic values is pulling values from one response to use in another request. For example, say you want to test creating and deleting a resource with your REST API. First, make the request to create the resource, which returns a new object with an id value. Now we want to delete the resource that was just created, so we’ll make a dynamic value to pull the id from the create response and insert it in the URL of the delete call. This makes it very easy to chain requests together and operate on the same pieces of data without having to update each request.

 

Screen Shot 2016-02-23 at 10.57.38 AM

 

 

One area where dynamic values really help are when dealing with multiple server environments. During development, it’s common to have development, staging, and production servers, all with different databases backing them. Paw accounts for this by providing environments, which are essentially a collection of variables and related values that can be swapped out on the fly. One use case would be to handle setting the domain each server so you can easily switch between them.

 

Screen Shot 2016-02-23 at 11.02.20 AM

How we use Paw

Paw has provided useful for our team in a myriad of ways. Whether we’re building against a new API or debugging an existing one, we always opt to use Paw over debugging our code. We also commit our Paw files with the project to let them serve as working documentation for the API.

On top of thoughtful features, Paw has a polished design that makes it look right at home on OS X, which can’t be said for a lot of other API clients (I’m looking at you jMeter). I’ll stop gushing now so you can go start your free trial.

Happy networking!

200-7

 

Feb
15

2015 State of the Union

Clients, Crew Members, Friends, Family, and Fellow Americans: welcome to LunarLincoln’s State of the Union address.

What a difference a year makes. What an incredible rollercoaster ride. We experienced so many highs last year, and we rode out the lows knowing that they were necessary to gain the momentum needed to reach the next peak.

Halfway through 2014, Wiley, Travis, and I (Jennifer) had just joined forces and were working out of a windowless 100 sq ft office attempting to pretend that we knew how this “running a company” thing works while writing code. Here we are taking a group photo and bemoaning moving out of our first office:

IMG_5157 

B5P80yEIgAEUvGf

Since then, we’ve said hello to new team members Todd, Ben, Patrick, and Jack. And then said goodbye again to Todd as he headed off to the big Apple (Cupertino, not NYC).


guysmural  

cityhousedinner


We moved into a palatial residence (bigger than our own house) and we began what has become a pretty impressive collection of moon AND Lincoln memorabilia.

TheOfficePano

But lets get to the interesting stuff:
Code. Apps. Creating Things. Amazing Clients.

We’ve worked on so many interesting projects. Some we can shout from the rooftops and some we can’t. Some of those we can talk about are on our snazzy new portfolio section of the website – go look at it, its beeeyutiful.

Cool things we got to learn more about last year
Items we shipped publicly (mmm, yes shipping)

We volunteered a ton. We pulled all-nighters at hackathons. We explained how pocket computers work to high schoolers. We gave talks to our fellow developers and also exchanged heated words at usergroup cage matches.


12087275_1005315902852421_2662332177277726035_o

22962232300_c8e64b8d79_o 

We made a ton of new friends at events around town and across the country

giphy-2

We did a bad job podcasting. We did a better job making our internal processes even stronger. And we’re building things for ourselves.

  • Finally finishing our own internal CI/CD system
  • Building a reporting platform to augment our JIRA instance
  • Starting on some products of our own (more details on that coming soon)
  • What happened to NSVille? (Ask @microchip128 & @ianbroyles to get back on the wagon)

 

It was a good year. Based on everything above – I’m not sure how we’re alive, but I can’t wait to do it all over again.

200-2

Love, love, love (and code),
Jennifer (and the guys) (and Abe)

Feb
11

Swift – No longer the new kid in school

It’s been nearly two years since Apple debuted Swift, its successor to Objective-C for iOS and OS X development, and since then the Swift language has evolved considerably.  When Swift was first announced, fans and developers were overjoyed. Objective-C was notorious for its overly verbose syntax and general scariness for new app developers, while Swift was much cleaner and modern without sacrificing any meaningful functionality.  However, most professionals, including the crew here at LunarLincoln, hesitated to adopt Swift at its inception. The language, though shiny and new, was unstable and still maturing.

200-2

Each Swift update brought forth the risk of breaking your existing code.  While Swift was incredibly fun for personal projects and smaller endeavors, it didn’t meet our needs for full-scale production. How would we explain to clients that we couldn’t complete a simple bug fix without totally updating their codebase to work with the latest version of Swift?

One year later – Swift 2.0

Apple open sourced the Swift programming language and implemented a heap of critical missing features like exception handling and protocol extensions.  The language had matured immensely in just one year and we felt it was finally ready for production use.

As of now, we’re still transitioning ourselves to a Swift mentality.  We’re doing our best to write all our new classes in Swift which is introducing all kinds of interesting problems that come with managing Objective-C and Swift in the same codebase.

While I still consider myself to be a Swift noob, I have to say I’m already a huge fan.  I love no longer needing to import class headers or having header files at all.  Wrapping my head around Optionals (pun intended) took a small bit of effort but using them in practice is helping me think about test cases I might have previously not considered.  Objective-C is still a crucial skill for even new iOS and OS X developers due to the sheer vastness of online resources, but I feel that it will slowly be phased out over the next few years.

And now I want to seize the low-hanging fruit that’s been dangling in front of me for this entire blog post.

For everybody on the fence about whether to jump to Swift, I’d say it’s time to get Schwifty!

ezgif.com-resize

Copyright LunarLincoln 2025. All Rights Reserved