development Archives - LunarLincoln

Sep

Working with Us

How does this whole thing work? Head to Hand. Brain to Phone. Lightbulb to Lightning Cable?

If you already have an idea of how building “apps” works then you’re most likely coming into the office with all your information ready and questions answered. However if you’re not really sure about how the idea gets from your head to the phone – we would like to give a little rundown of our process.

First. We discuss the idea.
There are two questions that need to be answered before any work can begin. First, what problem does this app solve? Secondly, who is the app for? If you don’t have solid and concise answers to these questions, you’re in for a whole lot of frustration and financial pain down the road. When you’re a month into development, and much too close to the project to remember where you started, you’ll love being able to go back and see if your new questions fit your initial value proposition. Yes? Great. No? Leave it. Knowing what you’re building prevents scope-bloat and allows for marketing/pitch success.

Second. We refine the idea.
Once we know what we’re building and for who, we sit down with our UX expert to refine features. You need a calendar app – great. Does the calendar need to send meeting invites? Do you need to see detailed listings or just high level? Do you want the views to be changeable (daily, weekly, monthly). Will the calendar send push notifications? What about having multiple calendars? As you can see requesting “a calendar” can have a lot of options.

We are here to show you what is ideal for your app and its users, what is possible, and what is cost efficient. When you say you want a house – is it this? or this?

screen-shot-2016-09-29-at-3-48-06-pm

During the ideation process we build wireframes. Wireframes are individual screen plans for all of the app’s features. The final wireframes allow us to give you a really strong idea of scope and timeline for development and serve as the app’s architectural plans. Without building wireframes we could guess at a feature list like “calendar, menus, list of cats” but it could easily fluctuate depending on what your interpretation of that feature really means (see the “houses” above).

Third. We design and test with real live users.
We take the wireframes and lay design on top. We will get a feel for the design on the project not only from who the targeted users are but also the brand and goals of the product. We do this in several ways – looking at competitors, apps the client likes, and making pinboards (yes, they’re useful for more things than your mom’s craft projects). We also place the design in a prototyping tool, Invision, where testers can click and explore. Post-design/pre-development is the best time to make sure what you’ve built works well with your users. You’d be surprised what you learn.

giphy

After the design is approved and flows are optimized based on user testing, the assets are exported and ready for development.

Fourth. We get to coding.
Our developers take the wireframes, designs, and interaction instructions and build “user stories”. These stories compose the scope of the project. “A user can tap a login button to view a login screen” or “A user can tap “support” to bring up a completed email” or “A user can view a loading animation”. These user stories are the meat of the project. If a feature is not clearly specified in a user story the developer will not know what to build. Or really – we can make assumptions. But we all know what happens when you assume….

Many times while coding, there are additional choices to be made (how should this baby be built under the hood?). With code being broken into smaller user stories a client can come in at any time and re-prioritize tasks, leave notes on current tasks, or adjust the plan without affecting the past work or current schedule.

Fifth. We test and deliver the code.
During development, when a set of user stories are finished (similar user stories are grouped into Epics – ie. “onboarding”, or “settings”) they are tested and reviewed by other crew members. If everything looks great, it is sent to the client. We generally like to send “builds” of code to the client at least every two weeks.

200

Steps Four and Five on repeat.
Code. Review. Test. Code. Adjust. Review. Test. Adjust. Code. Code. Code. Review. Test.

Sixth. We publish the app.
When everything is ready for a current version – we push it to the app store. That doesn’t mean it magically appears in a user’s hands. Apple and Android once again review your code and make sure it is in working order for the user. After their approval, it is in the store ready to be downloaded, promoted, and used by your adoring fans.

200

Apr

Working to Live not Living to Work

“Startup Life” – everyone knows this means long hours and intense work schedules right? It’s all about doing more with less, and if you’re not putting in more time than everyone else you’re clearly not cut out for startups right? Right?

Working to live at LunarLincoln

A little known fact: LunarLincoln has a 35 hour work week.

We also let our crewmates work whatever hours they want to. Why? For so many reasons. Because we want to create a sustainable work environment for our crew. Because we know we get better quality work when our dev’s are fresh and in the proper mindset for the task at hand. Because sometimes you hit a wall and just need to take a break to clear your head. We don’t put in “Let’s check Reddit since I have 30 more minutes till 5pm” time, and we don’t put in “I’ve already worked 50 hours this week on this project but have to put in 10 more to push it across the finish line, who cares about code quality at this point. Get. It. Done.” time.

http://alifeofproductivity.com/number-of-hours-work-a-week-to-be-the-most-productive-35/

Graph courtesy of http://alifeofproductivity.com

We only require 32 hours because our crewmates are individuals who deserve to be husbanded and treasured. They aren’t expendable and they’re not interchangable. We aren’t a code factory, we’re a small shop of craftsmen. (Plus there is some science to this madness ^)

Do your work. Do it exceptionally well and be proud of what you’ve created. Then go home and enjoy your life. If that life is learning more about mobile app development or building your own apps, awesome. If it is going to concerts and throwing dinner parties, that’s awesome too. We want our team to take that time and recharge and refresh, and most importantly we want them to live their lives.

But wait, you said a 35 hour work week, what are those 3 extra hours?

We want 32 hours of client-billable work. The work that supplies the paycheck. But you know what not only helps our crew but the final client product too? The time to learn new things. Learn the best new techniques, programs, and languages so that we can be more efficient, effective, and on top of our game. Those three hours are for personal development, whether that is reading blogs, using some extra time to try a new thing, or going to an event in town. It’s important and nonnegotiable.

While there are many approaches tech companies take for “salaried” workers we feel that this equation works the best. “Startup Life” doesn’t have to equal epic burn out.

200a

For us, “working to live” makes for a happy balance and keeps us excited to build new things each and every day.

Feb

Tools We Love: Paw

icon128-2x Here 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, 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