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

Working with Us

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business, Coding, Design

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.

200-5

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


Jul
26

Shipping Your First App

  • Posted By : Dheeraj Namburu/
  • 0 comments /
  • Under : App Advice, Business

[message_box type=”info”] This week we have a guest post from LunarLincoln Intern Dheeraj Namburu. He spent last month working on his very first app project and we wanted him to give us a breakdown of his initial foray into development and his take on our product-process. Enjoy! [/message_box]

Coming up with a good app idea is hard: it needs to be unique, useful, and attractive enough to attract a paid user. Hitting all of these criteria is essential in developing a successful app as I’ve learned these past few weeks. My first app ”The IFJ Reader” was a tool to make reading Intercollegiate Finance Journal articles much easier on an iPhone. The important distinction with my app is that I wasn’t seeking a profit, I wanted it to be a learning guide so that I could move on to other projects.

The best way to start the ideation process is to come up with as many ideas as possible – brainstorm. Your first few ideas may suck but you’ll find one to stick with. Choose something you’d actually want to use and find a way to make it unique, useful, and profitable. I decided to make an app that would help other people in my organization read the work that they’ve published. It’s important to be passionate about the idea you have while having some support from the user base. Your focus won’t dwindle when you get frustrated with all the minor issues that pop up because you will be accountable to the people for whom you’re making the app. You will fatigue, so you might as well choose something that you would appreciate spending day and night on (not that you will but still).

 

Planning Is So Important

The less you change your app design throughout your development process the fewer headaches you’ll suffer. Getting to create your own app gives you the ultimate control over the end product. I initially overreached on my first app and tried to add features like favoriting and searching that took too long to implement. Learning to trim the fat for your first MVP (Minimum Viable Product) will be invaluable while you’re designing your app.

It’s also important to understand the need that your app fills. If a feature doesn’t promote the solution that your app promises, that feature may need to be revised or scrapped entirely. It’s important to keep the scope of your app narrow, so that your focus is driven towards things that will reap the biggest benefit for a user.

Also, it’s important to do market research; it’s more than likely that someone has created something similar and you should take that into consideration. I looked at other RSS feed reader apps and determined what features they’ve implemented and what I could do better than them. Is the market saturated? If so, is your app specific enough that the people in your niche would use your app over others? Act like a user: Is your app flashy enough to capture the two-second attention span of an average human being? Is it compelling enough to compete with similar apps? While these criteria are important when trying to make a commercial success, it may be worthwhile to fulfill these criteria even on a side project. I made sure to develop an app that fit a small enough niche, that even in the RSS feed-reading category, my app would appeal to readers of the IFJ.

 

Make Rough Estimates 

Determining how long it takes for one to finish a task is an invaluable skill that takes time and practice to develop. Making estimates is a key tool to help finish projects on time. Appropriate estimates can help determine what the timeline is and if certain features can be added or cut based on the time frame remaining.

I wouldn’t worry if your time estimates were wrong, my first estimates were all over the place. Wiley helped narrow my focus and develop a more realistic timeline and this helped me take an app that I thought I could develop in a week, to a more manageable 3 week timeframe. The entire estimation and user story process allowed me to break a big task into smaller ones and allowed me to appropriately allocate my time to different tasks.

Screen Shot 2016-07-29 at 10.05.20 AM

Not only do rough estimates help you plan, they also feel rewarding whenever you finish a story. These small successes help you realize your goal and help fatigue from setting in, but they may also cause some tunnel vision. It’s important to avoid focusing so much on the small tasks and neglecting the bigger picture. It’s hard to see the end when it’s nowhere in sight, but it’s a good habit to step back once in awhile, admire what you’ve accomplished and get right back to work.

 

func  startDeveloping () {

Congrats! You’ve come up with an idea that you like, you’ve conducted market research to refine the idea, and you’ve created some rough estimates for each feature you want to implement. Now comes the actual coding part. Depending on your app, it’s important not to reinvent the wheel; just do a cursory search on Google to find libraries or examples of apps that attempt something similar. This way, you’ll save time and effort by piggybacking off of someone else’s work. Keep in mind, if you run into errors, debugging someone else’s huge code base written five years ago won’t be easy. Taking into account the benefits and drawbacks of outside codebases, it’s important to use them wisely, while writing custom code for any critical functions.

Coming in as a first time iOS app developer, I was kind of frustrated with the fast pace of mobile development. I learned to write in Swift but a lot of answers online were in Objective-C and translating between the two was difficult. I used a lot of help from the veteran developers here (everyone but me) so I had a competitive advantage. However, StackOverflow and Stanford’s online app development course were invaluable debugging tools. I’m glad I live in the age of the internet because I would’ve asked a lot of stupid questions in the office without it!

}

 

upload

QA and Review – Make Sure Your App Works

QA was minimal for my project, I mostly utilized my own testing of the app installed onto my phone to test the features that I wanted to and to ensure that the app would layout UI elements properly. I would fix whatever I could and then ask the developers here how to fix the other issues. Jennifer gave me valuable UI critiques, while Wiley, Patrick, Travis and Jack helped me write reusable and robust code.

While testing in-house is appropriate when creating a final product, it’s important to test the app in the field with actual users. To refine my idea, I decided to add some of the members from the IFJ to “TestFlight” the app. Having external testers requires a beta app review, but it also allows for easy app testing from end users, and this step can bring in valuable information for later revisions. Analytics and testimony from the users can help pinpoint trouble spots in one’s app and allows a developer to apply a polish that appeals to the end user.

Once all QA is completed, it’s a good time to send the app to review by Apple via iTunes connect. Get your killer app icons, screenshots and description text ready as you head to the App Store while you gear up to submit!

 

Post That App

The best part of doing all of this work is submitting to the App Store! Congrats, you’ve gone through the process of completing the development cycle of an iPhone app. Assuming your app has passed Apple’s review process, you can now post in the App Store. Pop out the champagne and celebrate!

Oh, but wait, no one’s gonna download your app if you don’t promote it… get out that old Twitter/Instagram account and start posting! Reach out to other people you know to get them to tweet about the app, do everything you can to get your app’s name out there. Leverage social media accounts, email lists, paid and free ads, anything that will get your app to the top of the App Store list.

 

Bathe in the Digital Benjamins

In the end you’ll have shipped your first app to the App Store. A process that might feel long and difficult, but relatively painless when compared to traditional application shipping. Thank your Apple overlords as you rake in that sweet app money.


Jul
21

When does it make sense to hire an app developer?

  • Posted By : Jonathan Wiley/
  • 0 comments /
  • Under : Business, Coding

People talk a lot about how to hire tech and where to find good talent but not a lot of people talk about whether or not you really need to hire.

You have a fledgling company – it is based in tech. Time to hire tech people right?

200

Actually, it depends.

Let’s let Wiley run the numbers for you:

  • Hiring a mobile developer costs at the very least $100k a year (salary + tax/insurance/perks/bonuses)
  • Hiring a development shop with a $100k budget would give you around 21 weeks of development
  • BUT. Most mobile apps take us between 4 to 10 weeks to build

What are you doing with that extra time (money)? What do you get for that cost?

Advantages of Hiring

With an in-house developer you get one set of eyes who knows the structure of the project closely. They’re with you for the long-haul (hopefully) and they sit right next to you (assuming they’re not remote). They have a set of best practices that will hopefully set you on a course for engineering greatness.

Advantages of Partnering

With a development shop you get multiple people – and as a result the ability to speed up your project timeline if needed. You get different areas of expertise. Need someone who does Android development? iOS development? Bluetooth Low Energy? A development shop has a team with a breadth of experience and can pull a person that matches what you need at the moment. You benefit from their deep reservoir of experience and industry knowledge. LunarLincoln even offers guarantees on certain contracts, so if a bug is found, it gets fixed at no extra charge (good luck getting your employees to work extra long hours to fix their mistakes).

On CTO Full Stack Ninja Unicorns

What if I just hire a bad-ass CTO who can do our development AND manage things? Experience, vision, and skill right? With this approach you’d be committing a percentage of their time to development, but the real question here will be efficiency. Has your CTO shipped hundreds of apps and updates to the App Stores, and do they know the tricks to get that right? Will they make the right decisions the first time or will they have to rewrite things several times to get it correct? Basically, how much time will your CTO have to spend learning to get to the level of efficiency that of a seasoned developer whose sole responsibility is building apps?  Plus, doesn’t your CTO have better things to do with their time? Why not focus them on the things that they’re really good at?

There are always downsides to both

What if you make the wrong hire? What if your developer only knows one language (iOS) and needs time to get the other platform down (Android)? What if your developer is sick, on vacation, quits during crunch time?

What if your dev shop doesn’t communicate well? What if they secretly put some noob on my project and the tech debt is staggering? What if they blew the budget and we’re only halfway done?

It happens. Hiring is scary. Spending money is scary. Partnering is scary. But you can do it.

tiny-potato

 

What does all this back and forth really mean? You’ve given me pros and cons but no assessment?

Can you just give me one of those sweet decision flow charts already?

Ok, ok, ok.


Hire an in-house dev if:

  • You know exactly what you need technically
  • You have the budget to hire the best (and know HOW to hire the best)
  • You’re going to need their specific skills long-term (beyond the initial push/development)


Hire an agency if:

  • You don’t know how to hire the best yet (we did it for you)
  • You have a limited budget runway
  • You need to get to market fast
  • Your project can benefit from a deep pool of technical skill
  • You may only need development for the initial push and then time to regroup


Hire a CTO/Dev if:

  • Don’t do this. Unless YOU are the CTO dev and then be prepared to be stretched really, really, thin.
  • Get a consultant, take someone out to coffee, you don’t need this until its time to growgrowgrow.

Working to live at LunarLincoln
Apr
25

Working to Live not Living to Work

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

“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.


Mar
29

Mobile Madness – Elite Eight

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business

The results are in and the winners from yesterday are: iOS, Swift, Erica Sadun, and Jake Wharton. Here is your updated Bracket. We’re moving on to some strange pairings. We’re getting into the really abstract comparisons of what is “the best” here at Mobile Madness. Join us on this journey.

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

Steve Ballmer vs Felix Krause

This is getting hard guys. The insane cult-of-personality that is Steve Ballmer or the straight up utility and approachability that is Felix Krause. Don’t make me make this choice!
Answer the twitter poll here


ballmercrazed

photo

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

Erica Sadun vs Jake Wharton

Ultimate indie expert battle – still iOS versus Android in this bracket. In one corner – Jake Wharton and his 1 billion excellent open source libraries and in the other corner Erica Sadun – Queen of Swift. Make your pick. If you can. Answer the twitter poll here


sadun_erica_c

imgres


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

Xcode vs AWS

Ok, whew, this bracket got weird. Let’s compare a development platform with a cloud service. Both are massive industry standards but which works better? Which is more integral to development?  Answer the twitter poll here


icon128-2x

aws_logo

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

iOS vs Swift

The parent or the child? What do you think of iOS as a platform in general? Is Swift its best incarnation? Is the future of iOS brighter with Swift? Can iOS win all bets as an innovator in its own field? I don’t knowwww! Answer the twitter poll here


poster_large

icon


Mar
28

Mobile Madness – Round 2 (People and Code)

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

The results are in and the winners from yesterday are: AWS, Xcode,  Felix Krause, and Steve Ballmer. Here is your updated Bracket.

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

Limor Fried vs Erica Sadun

Software versus hardware, each of these women is dominating their field. Make your pick!
Answer the twitter poll here


limor-fried-adafruit-entrepreneur-of-the-year11

sadun_erica_c

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

Jake Wharton vs Jake Marsh

Battle of the Jakes and at the same time battle of the iOS versus Android indie experts. Which Jake do you back?
Answer the twitter poll here


imgres

Mashable-User-Pic_400x400

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

iOS vs React Native

This is really a battle of native versus cross platform. Flexibility or doing it right? Which side are you on? Answer the twitter poll here


poster_large

react-logo-1000-transparent

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

Objective C vs Swift

Oh snap! Old school or new school? Have you dipped your toe into the new Apple paradigm? What do you think? Answer the twitter poll here


url

icon


Mar
24

Mobile Madness – The Tools

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business, Coding

The results are in and the winners from yesterday are: iOS, React Native, Objective C, and Swift (Obviously some apple fan-boys out there). Here is your updated Bracket.

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

On to the final first-round bracket of Mobile Madness 2016. The Tools. You need them, the love them, you hate them, you shout whyyyyy at the sky while Xcode hangs. Which is the best? Which is crucial to mobile development? Let’s begin.

First up: iOS Tools

Xcode vs AppCode

Xcode gets a lot of flack from developers because Apple more-or-less forces their developers to use it. Sure, it has tons of great features and debugging tools, but every little glitch or crash becomes colossally irritating because of a lack of alternative options. Enter AppCode, JetBrains’ introduction into an iOS and OS X IDE. AppCode attempts to solve a lot of the headaches Xcode creates, like improved refactoring support and auto-generated snippets. But AppCode comes with a hefty price tag and often lags behind when Apple releases new APIs. Is the increased convenience worth the cost? You decide! Answer the twitter poll here


icon128-2x

OBJC

 

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

Second Bracket: Android Tools 

Android Studio vs Eclipse

Eclipse has long been a Java programmer’s goto IDE for all of their needs. Console applications, GUI applications, applets, web apps, and more can all be cranked out from Eclipse. It’s no wonder why Google initially supported Eclipse when they debuted their Android SDK. But now a newcomer on the scene, Android Studio, has stolen the spotlight and captured the hearts of Android developers everywhere. With Google officially deprecating their Eclipse support and actively promoting Android Studio, you might say the sun is setting on Eclipse for Android development. But that hasn’t deterred many Android developers who have been using Eclipse for years and don’t feel the need to switch. Which will reign supreme: comfort or cutting edge? Answer the twitter poll here


Android_Studio_icon.svg

eclipse-1

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

Third Bracket: Continuous Build Systems

Jenkins vs Travis CI

When it comes to making sure your code is stable, Jenkins offers a great set of tools for building, testing, and more. As an open source project, Jenkins provides a high level of flexibility for implementing real continuous integration for any platform. Additionally, it’s free (as in beer)! Travis CI, much like Jenkins is no slouch when it comes to building your apps. With a beautiful interface, you can quickly check that status of your project. Additionally, Travis CI manages the infrastructure for you making it one less thing to worry about when it comes to working with CI tools. Which mustachio’d tool do you prefer? Answer the twitter poll here


headshot

687474703a2f2f61626f75742e7472617669732d63692e6f72672f696d616765732f7472617669732d6d6173636f742d32303070782e706e67

 

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

Fourth Bracket: Cloud Storage

Heroku vs AWS

From the juggernaut that revolutionized online shopping, Amazon is using their knowledge to provide the best in cloud computing. With it’s massive offering of paid services, you can design, build, and deploy all your digital content in a matter of minutes. If you have a DevOps need, Amazon has a service for it. On the other side is Heroku, the developer friendly infrastructure service. Heroku can help developers by clearing out the chaos that can come with managing your own stack, like with tools to automatically deploy and push on each code commit. As your application needs to scale, Heroku’s marketplace of paid add-ons is sure to have what you’re looking for. Answer the twitter poll here


heroku

aws_logo


Mar
23

Mobile Madness – The Code

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business, Coding

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


Mar
22

Mobile Madness – The Indie Experts

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

The initial results are in and the winners are: Steve Ballmer, Steve Jobs, Jony Ive and Felix Kraus. Here is your updated Bracket.

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

On to the second bracket of Mobile Madness 2016 with a continuation of the people that contribute to the mobile landscape. Some of these indie darlings have made the jump to the big leagues but for the rest, they soldier on one awesome book, blog post, or tweet at a time.

First up: Master Makers

Ayah Bdeir vs Limor Fried

Ayah Bdeir is the founder and CEO of Little Bits everyone’s favorite snap and play electronics toys. We’ve been geeking over the space kit for a while now and constantly suggest these as a great intro-to-electronics. Limor Fried is the founder of Adafruit the one-stop shop for all the whosits and whatsits to make your maker-dreams come true. Adafruit materials power our christmas tree and gif tv (really!).

littlebits-Ayah-Bdeir_37757

maxresdefault

So who build better tools for the builders? Big builders? Little builders? Answer the twitter poll here

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

Second Bracket: All things Swift 

Natasha Murashev vs Erica Sadun

Natasha Murashev more commonly known as Natasha the Robot is everywhere all at once with her talks, advice, and tutorials on all things iOS. She’s been a key figure in brining Swift to the masses, including help organize the try! Swift conference. Meanwhile, Erica Sadun has been a major contributor when it comes to Apple’s latest language, Swift. While her skills with Swift are only matched by her wit, according to the Swift Evolution project, she has by far the highest number of accepted pull requests. You can be sure her ideas are not taken lightly in Cupertino.

Both are rocking it with the new Swift language and have build a massive following for their questions, comments, and observations.


OFRHu0o9

32688

 

Who is the true education maven? Answer the twitter poll here

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

Third Bracket: All things Android

Jake Wharton vs Roman Nurik

Jake thrust himself into the spotlight with his incredibly famous open source Android libraries such as ActionBarSherlock and NineOldAndroids, as well as his contributions to Square’s massive catalogue of open source libraries such as Butterknife and Retrofit. He continues to deliver enlightening talks and presentations about Android and its continued evolution as a platform. While also an experienced developer, Roman is most famous for his work with the UX aspect of Android development. As one of Google’s most popular designers, Roman helped bring the beauty of Material Design to the Android world. He has also crafted a collection of open source libraries focusing on improving user interactivity and experience with your Android projects.


imgres

unnamed

Answer the twitter poll here

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

Fourth Bracket: iOS

Jake Marsh and Mattt Thompson

When it comes to iOS developers, Mattt with three Ts is virtually a household name. His brain children AFNetworking and NSHipster are still widely used and respected to this day. Go check out his other projects too for a host of other useful libraries and services. When it comes to the best tutorials in the shortest amount of time, Jake Marsh is your guy. His little bites of cocoa has become an overnight success, and is a great place to learn fun new iOS tricks that can be used in every day development. Both these guys have made their mark when it comes to contributing to the development community.

Answer the twitter poll here


Mashable-User-Pic_400x400

5333c08eae9005dd7a8cdd478202c818_400x400

 


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

 


1234
Recent Posts
  • Celebrating 10 Years
  • 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
Archives
  • August 2023
  • 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 2025. All Rights Reserved