LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Mar
09

Helping clients out with the tech terms

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

Everybody knows that software development depends on understanding various programming languages like Java, Swift, and Objective-C. But sometimes the most difficult language to understand is our own.

jackie-chan-illuminati

Tech geeks and project managers often have an unfortunate habit of using vocabulary that is lost on the ears of their clients. We use certain terms and phrases all the time and forget that we work in a niche environment. I want to take a moment and demystify some of the lingo we use when talking about our work.

Server

A server can be thought of as a computer program which runs code specifically for Internet applications.  For example, websites are hosted on servers.  A server isn’t necessarily an entire computer (sometimes a single physical computer can host many servers) but for the sake of understanding, imagining a server as a single physical device works just fine.

Back-end

More often than not, mobile applications need to connect to the Internet to perform their feature sets.  The back-end is what we call the server that powers our applications.  If we have to store user accounts, fetch data for various screens, or any other feature that requires external data, we’ll talk to a back-end.  Some services like Amazon Web Services and Parse offer simple back-end solutions.

Front-end

As opposed to the back-end which is strictly computational, the front-end is what the users get to see.  A front-end can be a website, a mobile app, or any other visual interface for your product.

When building a website you often need a “front-end” developer and a “back-end” developer since each part’s code works in fairly different ways.

API – Application Programmable Interface

An API is the means by which a back-end serves data to external applications – a set of instructions for a specific task if you will.  For example, if I created a back-end for storing user accounts, I would create an API endpoint allowing my app to save a new account (sending new accounts to the server back-end).  Each endpoint on an API performs a specific function (or set of functions based on the query parameters given to it).

Untitled

APIs link different things up with translatable instructions.

Push

Push can mean many things, but for brevity sake, I’ll only talk about the two most common times when we use the word ‘push’.  Every product we make is backed by a version control system called git.  A full explanation of git would take at least one or two more blog posts, so I’ll spare you the details on how it works.  When a developer has finished a task an wants to save his or her code to the central repository, they ‘push’ their code up for review.  Similarly, the other instance we use the word ‘push’ is when submitting finished products to their respective app stores.  Both instances of the word ‘push’ have to do with submitting finished work.

If you don't push your code - it won't be added to the main codebase

If you don’t push your code – it won’t be added to the main codebase

Build

In our world, the word ‘build’ is used often as a noun.  A build is a compiled instance of an application.  For example, if I wanted to send a beta version of an application to a client, I would create a build and push it out for testing.  One might say that they’re ‘building a build’ which would mean they’re preparing to distribute a version of the application.

release

Source Code

Not to be confused with the terrible 2011 Jake Gyllenhaal movie, source code is the main body of code that composes your mobile app or website. We often break off small chunks of code to work on (branches), but when we’ve properly added to this piece and tested it, we then push it back into the source code. When we are done with a project, we will send you the “source code” aka all of the code that is needed to run or “build”  the project. Often if we are working with a new client who already has a product, we will ask for access to their “source code” to see what has already been written and the quality of code that we will be working with. Is it going to need some restructuring? Is it all tidy in there? How is your app built?

User Story

A user story is an example of a feature we’d like our application to perform from the perspective of a user.  For example, if we have a screen that allows users to sign up, a user story might say, “A user can enter their credentials to sign up for an account”.  This ideology helps us imagine our goals as if we were using the application instead of building it.

user-story-card

Agile

This is how we operate!  Agile development focuses on building features incrementally and with room for flexibility throughout the project.  Whereas more stringent methodologies such as Waterfall rely heavily on extensive planning, Agile is a more rapid system.

agile-methodolody_695x260

Iterate

When we say we’re going to iterate on an idea, what we mean is we will keep making tiny changes, builds, or designs until we slowly, gradually develop what we are building into the ideal format. Instead of building once and declaring “This is it!”. We will frequently iterate over tough problems until we arrive at the best workable solution. Iteration is the core of the agile methodology (see image above).

That’s it for now you guys. Hopefully this has been an informative tech terms 101 for you. Now you can sit in meetings and nod wisely as we blather on about “taking the most recent iteration and pushing the back-end source code build up to the server“. Let us know if there is anything else we missed or if we need an entire round 2 of “What the heck are you saying?”.

200-2

 


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

 


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