LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Feb
29

Solving Hard Software Development Problems

  • Posted By : Travis Smith/
  • 0 comments /
  • Under : Coding

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

  • Posted By : Patrick Goley/
  • 0 comments /
  • Under : Coding

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
16

Startup Growing Pains and Working on my Google-fu

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business

You see in the news all the time “Startup acquired in $$$$ deal” or “Local Startup hires 2983742742 new employees”. But how do those companies get to that point? Growth is hard guys. Can’t we just work in our own little bubbles?

When starting LunarLincoln, we knew some of the basic things we needed, and we knew we wanted to be one of those companies in the news with fantastic results, but connecting the dots from point A to point B – well, we weren’t so sure about how that worked.

How do you get from the beginning to the end?

200

Things we knew to do:

  • Register a company
  • Pick a name
  • Build a website
  • Get some clients through word of mouth or past contacts
  • Promote on the interwebs
  • Go to events/meetups
  • DO GREAT WORK

But doing the work is the easy part. We knew how to do that, whether it was code or design.

But how do you do all that other stuff that gets in the way of work?

Things we had to google in the past year during super-growth-time (and are still not sure we did it the “best” way).

  • How to rent commercial office space
    • What’s a CAM?
    • Why are there no office/commercial spaces that are small/medium sizes and NOT in a coworking space?
    • What are some commercial real estate sites that AREN’t horrible to use?
    • What do you mean we have to build the office after we rent it?
    • Where do you buy office furniture? Should we even buy “office” furniture?
  • How to properly interview developers
    • Average salaries for developers in the southeast
    • Good interview questions
    • How to fire an employee
  • How to write an employee handbook, offer letter, contract, etc
  • How to find a lawyer
    • How to negotiate contracts
    • How to leverage your legal team when problems arise (Why can’t you pay on time!!!)
  • How to find an accountant
    • How to use Quickbooks
    • Why is Quickbooks the devil?
    • Alternatives to Quickbooks
  • Do we charge sales tax in Tennessee for development?
    • Why do we have to pay tax on our stuff (I’m looking at you Schedule B)?
    • Payroll taxes, sales tax, federal tax, unemployment tax – why so many taxes?
    • How to not miss a random tax payment
  • How to buy small business and health insurance
    • Tech insurance
    • Dental & vision insurance
    • Rental insurance
    • ALL the stupid insurance (I left out workers comp, short term disability, & long term disability ugh)
  • How to set up a company 401k
    • Why are 401ks so expensive?
    • What is a simple IRA?

That list above – there was hardly ever a simple google answer. The internet always had 200 different ways to do each task. What was right for us? What was right for Nashville? What was right for a tech-services company?

Late at night after sifting through the conflicting advice and moaning “whyyyy, whyyy” at the wall about the most recent puzzling question, we would joke that there had to be some sort of AA meeting for startups.

200-4

So, my lovely internet peoples. I would welcome with open arms any of the following:

  • Not a tech mentor, not a design mentor, but a small business mentor. A fairy godmother of answers. A veritable Ask Jeeves
  • Some sort of “How do you do this business thing?” Question-Time Meet-up
  • A wonderously detailed forum or QA series on a local tech site so I can quit trawling page three of the Google search results
Maybe these things already exist…
…but, I’m just too tired to google them right now.

I just want to get back to the work part of work.


Feb
15

2015 State of the Union

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business, Coding
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
  • Complicated algorithms for fuzzy, health-based logic
  • GPS tracking and payment systems for the local shuttle revolution
  • Building the world’s most innovative and challenging UI controller
  • Optimizing an app to be energy efficient while constantly running in the background and logging a user’s location
  • Writing algorithms to clean up data given to us by Apple’s sensors
  • Crunching enormous amounts of data into usable insights
  • Magic cards!
  • Streaming video from face cameras
  • Leveraging the JIRA REST API
  • Maintaining native SDKs and their associated APIs
  • Creating a wicked fast PDF renderer to display PDFs in a customized way
  • Making progress at a reasonable rate on legacy codebases
  • Syncing audio output between multiple devices
  • White-labeling
  • Apps to test apps
  • Apps to ship apps
  • Things that aren’t apps but are in fact websites. (We can do them now, but still hate front-end development)
  • Swift!
Items we shipped publicly (mmm, yes shipping)
  • Compass (Beta)
  • Guestbook for Emma
  • Metric for Emma 1.2 for iOS and Android
  • Expo
  • Joyride Backend
  • Joyride Customer for iOS and Android
  • Joyride Driver for iOS and Android
  • Band in Hand 3.0
  • TappedOut for Android and iOS
  • StyleBlueprint 1.3 for iOS
  • Playmaker CRM for Android
  • XOEye for iOS
  • LoLo 2.0 for iOS and LoLo for Android

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.

  • Vandyhacks – Building Epic $*&%^
  • East Highschool Magnet – What does it take to build apps?
  • CocoaHeads – Creating Custom Views
  • Nashville Mobile Usergroup – Native versus Cross Platform Cage Match

12087275_1005315902852421_2662332177277726035_o

22962232300_c8e64b8d79_o 

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

  • Sponsoring Creative Mornings & Nashville CocoaHeads
  • Going to SF for Quantified Self Conference and pitching our hearts out
  • Becoming a finalist for the Nashville Next Awards!!!
  • Watching Expo compete at Pandoland with an app we built for them

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

  • Posted By : Travis Smith/
  • 0 comments /
  • Under : Coding

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


Feb
04

From office noob to Android czar – Building a League of Legends App

  • Posted By : Travis Smith/
  • 0 comments /
  • Under : App Advice, Coding

[message_box type=”info”] This week we have a guest post from LunarLincoln developer Travis Smith. He spent 2015 working on a side project which he finally shipped (yay, shipping!) and we wanted him to give us a breakdown of his initial foray into indie development. Enjoy! [/message_box]

Sometimes it’s hard being the only Android user in a shop full of mobile developers.  You’d expect nearly equal representation as Android currently dominates global markets, but alas, mistakes do happen (yes, mistakes). However, a positive consequence of this misfortune is the compelling urge to prove Android is the superior operating system. And what better a way to do that than to become an expert Android developer.

chart-ww-smartphone-os-market-share

Android’s Lollipop OS was released around the start of my development journey and alongside it the beautiful style guide known as Material Design. Coupled with the release of numerous support and design library features, I knew I wanted to create something awesome both as practice and for fun.

giphy-2In addition to being the only Android user in the office, I’m also the biggest video game nerd. My favorite these days is League of Legends, arguably the most popular PC video game in the world. And luckily for me, Riot Games, released a beta version of their public API just a few years ago. Being no stranger to the Riot API (I rigged up an automated system to pull in millions of game records for statical purposes back in early 2014), I knew I wanted to push both my skills and the API to their limits. But where to start? There were already a handful of League of Legends apps in the Play Store and some had hundreds of thousands of downloads.

What was a problem in League of Legends that hadn’t yet been solved?

Friends. All of the existing apps I found made it easy to drown yourself in data and statistics about any player you wanted. However, none of them made it easy to see how your friends were doing, or whether they’re actively playing a game at the moment you’re using the app. Additionally, all of the existing apps were designed before the advent of Material Design.

I could see in my mind what I wanted:

  • A name. I chose League Buddy. It’s simple, a little corny, not violating any copyrights, and unused. Works for me.
  • The home screen should be a list, or maybe cards, of summoners.  I could show their names, their profile pictures, and when they last played a game (or if they were in game that moment!)
  • A Floating Action Button at the bottom could present a popup of some sort that allows users to add new summoners to their list
  • A single swipe to refresh could update the entire list at once and let me know immediately if my buddies were playing without me
  • Tapping a summoner should do… well, something. I hadn’t figured out exactly what I wanted here yet. Maybe show some in-depth detail about the summoner?

Simple, right?

Time to learn some new tricks.

Around the time I started, Android released its ‘upgrade’ to ListView, the RecyclerView, and encouraged developers to stop using the ActionBar and instead use the new more generic Toolbar, which would prove very useful in implementing a core Material Design feature. I had my first screen laid out in my mind, but I still had a few questions.

  • What are the best practices with Activities and Fragments?
  • Does the Toolbar belong to the Activity or the Fragment?
  • What about the Floating Action Button?
  • What if I want to support multi-pane on landscape tablets? How should landscape look in general?

I spent so much time researching everything about best practices that I actually discouraged myself for a few weeks. Eventually I realized that the only way I was going to really learn what worked and what didn’t was by trying my best and fixing my mistakes.

giphy

Since I knew I only had one screen in mind, I decided to put multi-pane support on the back burner. However, I did prepare for the future and opted to implement my layout inside a Fragment (which was really just containing a RecyclerView) and put that Fragment in my Activity along with the Toolbar and Floating Action Button. Back then, I was using a library for the Floating Action Button since there wasn’t an official widget (yet). I created a small view that would slide up from the bottom when the button was pressed and that view allowed users to input a summoner’s name along with the region of the server they played on. For example, I play on the NA (North America) server, but there are about a dozen servers across the globe and I wanted my app to support them all.

unnamedNow I needed some way to persist data. On a previous project at work I had used Sugar ORM as a wrapper on a SQLite database. It worked well but I wanted to try something new. I came across a brand new tool called Realm which touted itself as being incredibly fast. Though still in beta and lacking some features (including null support and subclassing entities), I decided to give it a go.
All that was left was to set up the actual connection to Riot’s servers. Writing an API wrapper was easy, especially since most of my code from my previous Riot API project was up-to-date. I used Retrofit to talk to Riot’s server and Picasso to display profile pictures. After a few nights of work, I had accomplished my goal – an app that showed a list of summoners, with a button to add new people, and the ability to refresh the list. It was crude, not too pretty, and lacked lots of key features (like deleting summoners from the list), but it worked.

And then I stopped working on the project for a few months. Work picked up and summer meant vacations, so I halted progress.

But then, Android released some neat new tools that inspired me to resume development!

The first was an official Floating Action Button. The second was a new view called the CoordinatorLayout which allowed the Toolbar to hide as the list below it scrolled down. Last was a NavigationView class which made implementing a Material-themed navigation drawer incredibly simple.

Implementing the CoordinatorLayout proved to be very challenging. I had placed a view at the bottom of my fragment that indicated the last time the data had been refreshed, and this was throwing off the scrolling of the fragment. Despite aligning the view at the bottom and the RecyclingView above it, the scrolling did not work properly. Somebody else had filed a bug report about this exact issue and fortunately somebody had devised a workaround. However, now that the Toolbar slid out of view when scrolling my summoners list, I couldn’t imagine how multi-pane support would work at this point. My second screen was scheduled to be a scrolling list of cards containing tidbits of high-level information about a summoner, and having two scrolling views under one Toolbar would be very unwieldy for a user if that Toolbar was also sliding.

The next hurdle was the Floating Action Button. Now that Android had an official widget which directly related to the CoordinatorLayout (the button would hide on scrolling), I knew I had to replace it. However, I disliked my current implementation of adding a new summoner. A messaging app called GroupMe provided some much needed inspiration. When tapping their Floating Action Button, the button expanded outward until it filled a small rectangle. I loved it and had to have it. As it turns out, this animation is called a circular reveal animation (surprise!). Android had incorporated a utility class for performing this exact animation, but it was limited to devices running Lollipop or newer (which was a very paltry 10% around this time). Fortunately I found a library that provided the exact needed functionality to my app.

unnamed-1Along the way I encountered a new pattern I had never seen before: the event bus. While I’m still torn today over its fit as a best practice, I decided to integrate Otto into my app to help with loading and passing data. In hindsight, I regret this decision a bit, as it led to some poor coding practices and tangled dependencies. As practice, I also decided to upgrade all of my API calls to return RxJava Observables, as functional reactive programming is something I’m becoming more and more interested in.

Creating the summoner overview cards screen was fairly easy. The card styles were adapted from official examples and look very clean. I was able to use a StaggeredGridLayoutManager to allow different orientations and screen sizes to show different numbers of cards side-by-side. Because of switching to using RxJava Observables, loading all of the necessary data (since none of this data is persisted) was easy. I threw together a quick Settings screen which let users change their default region (which will be automatically selected when prompted to add a new summoner) as well as their preferred language (which all Riot data will be automatically translated to).

After a brief QA round across different devices and SDK versions, I had a working, ready app. With one problem.

Riot’s development API key is severely rate limited. To get a production level key, I’d need to get them to approve my app. And to do that, I had to follow their rules. The first rule is that no client-facing application can have the API key embedded in its code. This meant I needed a server to act as a middleman between my app and the Riot servers to append my API key and return the data. The second hurdle was that I needed a website to showcase my app and provide screenshots, FAQ, etc. I took my meager bit of Node.js and Express knowledge and pieced together a very small server application which would cache results for a few minutes and return the data to my app. I hosted this on DigitalOcean, struggled to get a free SSL certificate, and eventually got it working. I purchased the domain leaguebuddyapp.com and worked with Jennifer to set up a very simple one-page website (which is almost done, I swear!).

200

(^Jennifers reaction to this statement)

I was ready to publish.

Presenting, League Buddy! It’s small, it’s nowhere near finished, it’s got some kinks, but it’s mine. I’ve got tons of ideas for future expansions to the app. A wiki page with data on every champion and item in the game, a statistics section that lets you compare yourself to your friends (or even professional LoL players, if you dare!), and tons more cards on the summoner overview screen. Not to mention all the detailed pages for nearly every card! I’m going to be busy for a very long time.

leageulegends

 

Despite the incredibly long blog post, this doesn’t cover even half of the sometimes silly and often frustrating problems I encountered on this journey. But I feel it was completely worth it.

I’ve exposed myself to so many new communities, picked up so many new skills, successfully learned which patterns I like and which I don’t, and ultimately shown I’m capable of creating an entire application from scratch, including its server and web components. It was fun, challenging, and awesome. With 2016 under way and my routine back to normal, I’m hoping I can commit a little bit of time each week to cranking out some new features.

In the meantime, check out my app and let me know what you think! I’m open to all criticism and suggestions for improvement.

And I should offer thanks to the entire LunarLincoln team for putting up with my rambles and questions over the last year about this hobby project. Even though they’re not exactly Android fanboys and girls, they’re all brilliant and offered tons of great suggestions. I’m immensely thankful for their help and looking forward to using my new skills on upcoming Android projects.


Feb
02

Life in the Fastlane: CI/CD Tools for iOS

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business

LunarLincoln’s own Patrick Goley spoke at CocoaHeads Nashville this week about continuous integration and continuous development tools for iOS. Some highlights of his talk were:

  • How to build and upload to iTunes Connect (or other services) with a single command
  • How to use Match to manage code signing for teams and build servers
  • How to generate screenshots for your app in every device/language combination (OMG!)

Check out his sample project with Fastlane integration on Github: https://github.com/patgoley/Todo

Download his slides here: Continuous Deployment with iOS

Or watch a video of the real deal:

[responsive_video link=”https://www.youtube.com/watch?v=eAUnFYEQ6sU”]

We’d love to see you out at CocoaHeads Nashville each month – great talks, great people, delicious pizza, and beer. It is run by the talented and charming Blake Merryman and Bryn Bodayle and there are a myriad of topics covered each year. Sign up for updates at www.meetup.com/Nashville-CocoaHeads/.

Hungry for more? Here are some videos of past CocoaHeads talks:

  • Scripting with Swift by Blake Merryman
  • Creating Custom Views by LunarLincoln’s Jonathan Wiley

 


Recent Posts
  • Copious Communication
  • Initial Questions for a New Mobile App Project
  • Gif TV: A LunarLincoln Product
  • Onboarding other peoples code
  • What’s in a name?
  • Don’t build it all. Picking a Platform.
  • Talk to your Users
  • Design for Fat Fingers
  • A new look
  • Hourglass for Jira
Archives
  • May 2021
  • September 2020
  • November 2019
  • October 2019
  • June 2019
  • April 2019
  • February 2019
  • January 2019
  • October 2018
  • August 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
  • August 2017
  • June 2017
  • February 2017
  • January 2017
  • September 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • October 2015
  • September 2015
  • July 2015
  • May 2015
  • February 2015
  • December 2014
  • November 2014
  • September 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • December 2010
Categories
  • Agency
  • App Advice
  • Branding
  • Business
  • Business
  • CaseCollage
  • Coding
  • Design
  • Design
  • NSVille
  • Uncategorized
  • Web Design
Copyright LunarLincoln 2023. All Rights Reserved