Coding Archives - Page 2 of 4

Jan

Becoming A Mobile Developer

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

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

Motivations

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

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

Traditional Paths

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

Self Taught Paths

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

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

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

Bootcamps

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

How I got started

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

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

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

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

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?

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

When does it make sense to hire an app developer?

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.

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.

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?

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.

Apr

Native vs Web Apps

When building a software product for mobile, there comes a time early on when you must decide between building a native application or a responsive web app. When making such a decision, it’s very important to understand the implications of going one way or the other. A native app is typically more expensive to build, but the extended capabilities and high speed execution often makes it necessary or at least advantageous for certain products. Today we’ll explore a few benefits of building native apps to help make this decision easier for anyone setting out to build a new mobile product.

blog-42

Why go native?

Direct Hardware Access

Icons8 One huge advantages of natively built applications is they have direct access to many hardware features that web apps simply do not. While HTML5 has brought easy access to the camera and microphone with the <input> tag, these elements simply output a file and don’t give you access to the media in real-time. If you want to build fun camera filters or do any kind of signal processing, you’re much better off in the native realm.

While web apps have some access to media capturing hardware, they don’t have any access to some of the other sensors on the device. For example, native apps on iOS have full access to all HealthKit data (should you allow them) collected by the motion co-processor and other activity trackers, which are always working whether your app is running or not. Native apps can also use geofences and other location-based triggers to provide context-aware behavior and offline notifications, which can draw your user’s attention back to your app at opportunistic moments.

Blazing Fast Execution

200 (4) Native apps can work more efficiently because they run directly on the hardware, meaning there’s very little overhead to performing computation. This can make a huge difference when doing lots of graphical work or anything that is computationally expensive. While hardware-targeting makes applications less portable, it allows them to really take advantage of the processors they run on, giving you the high resolution and fluid graphics you see in native games and media apps today. Apple’s graphics library Metal is a great example of this, being designed specifically for the GPUs in Apple’s products to achieve maximum performance.

User Experience

There’s usually a clear difference in appearance and quality between native and web-based apps, as web apps lack the responsiveness and familiar UI elements of a native app. While web apps can certainly accomplish a lot, the extra layer of separation brought by running in a browser or web view rather than natively means the app can’t respond as quickly to things like touch events. This accounts for the slight lag you experience when interacting with the UI of web-based mobile apps, which amounts to a less-than-stellar user experience. Also, users may not pick up on custom UI controls from the web when they are used to a consistent experience from native apps on their platform, which can lead to usability problems. If the user feels like they’re swimming upstream to use your app, they probably won’t keep at it for long.

Offline Functionality

One clear limitation of web apps is the necessity to download them over the internet each time they are loaded. Since native apps are installed once and can store tons information on the device, they can provide all kinds of functionality without an internet connection. iOS apps can even preemptively load data before the user opens the app through silent push notifications that “wake up” the app to retrieve new data.

Even with an internet connection, the first few seconds of a web app experience often consist of spinners and sluggish stylesheets causing elements on the page to jump around as it loads. This requires a measure of patience from your user, which might be too much to ask from some users especially after navigating through a few pages. With user attention spans getting shorter and shorter, you need to capitalize on every second they spend in your app, creating value for them and not putting them on hold to download and render bloated web pages.

"We're getting really close to ready" – the false dream of hybrid apps pic.twitter.com/xyvXT3qNao
— Bill Morein (@wmorein) May 5, 2015

In short, while native certainly isn’t the right choice for everyone, there are a quite a few cases where it’s necessary or at least beneficial. It’s important to consider these implications not only for the current state of your product but also for it’s future, as it would be unfortunate to commit to a web-based platform only to have to rebuild later when you need native-only features. While historically writing native apps have meant coding for one platform at a time, there have been big developments in native, cross-platform solutions such as Xamarin, now backed by Microsoft, and React Native, brought to you by Facebook. These solutions, while still growing, hope to deliver the fully native experience without limiting you to a single platform which can greatly reduce the cost of certain projects.

Apr

Mobile Madness – The Championship

This is it, you guys. THE CHAMPIONSHIP. Who will be the ultimate winner of Mobile Madness 2016?!?

200

Swift vs Jake Wharton

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

Swift

Swift has had a crazy, semantically satisfying ride to the finals in this tournament. It was picked in Round 1 over the world’s most used programming language, Java (*ahem* thanks fanboys *ahem*). In Round 2 it beat out it’s arch nemesis, the big, bad Objective-C. And then in a crazy match up that left even Apple fanboys wondering who would win, it stomped iOS. Finally, Swift beat out the juggernaut that is AWS to earn a spot in the finals!

We’ve covered Swift’s benefits and shortcomings fairly thoroughly in previous posts. To recap for you fair-weather fans:

“Swift is quite new on the scene, which only hit 1.0 in September, 2014. It has been acclaimed for it’s use of functional programming and value types which can help simplify problems in the minds of developers. With much to prove for general use outside of iOS and Mac apps, it’s support from the open source community as well as big players like IBM is driving adoption for the language at a rapid pace.”

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

Jake Wharton

Aaaand on the other side we have the legendary Jake Wharton. In Round 1 Jake scored a win over UX giant Roman Nurik. Then he won the battle of the Jakes to advance over iOS indie Jake Marsh. He faced off with Swift contributer Erica Sadun and came out victorious to advance to the final 4. And somehow he beat out Steve Ballmer (!!!) to advance to the finals.

We’ve written a lot about Jake in our pervious posts, but for those not paying attention here’s a recap:

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

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

Who will be the winner?!?

In a lot of ways, this matchup comes down to iOS fanboys vs Android fanboys. After all, those of us who grew up in the early days of Android development would have had a tough time without Jake’s timely and useful libraries. On the other hand, Swift has breathed some new life into iOS development and actually got us excited about a programming languages. So who will you pick to be the one to rule them all?

Vote in our final Twitter poll here!

Mar

Mobile Madness – Round 2 (People and Code)

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

[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

[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

[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

Mar

Mobile Madness – Round 2 (People and Tools)

The results are in and the winners from yesterday are: Xcode, Android Studio, Jenkins, and AWS. Here is your updated Bracket.

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

We are entering the second round of Mobile Madness 2016. The pairings are getting a bit more interesting as we move towards the finals. Welcome to the sweet 16!

Steve Ballmer vs Steve Jobs

We love so much about both of the tech giants, but only one can win today in the battle of the Steves. Who’s it going to be?

Steve Jobs brought us so many things, and in many ways LunarLincoln wouldn’t exist without the App Store. Forgetting that Jobs was famously against having an App Store, we still owe him credit for so many incredible inventions. Plus, he was a pretty inspirational guy:

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

And then we have Steve Ballmer. The man. The legend. I mean, if you can get Bill Gates to dance on stage to celebrate the Windows 95 launch, what can’t you do?

[responsive_video link=”https://www.youtube.com/watch?v=XKVJoBGq-7g”]

So which Steve will take home today’s prize? Answer the twitter poll here

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

Jony Ive vs Felix Krause

Up next we’ve got industrial design genius Jony Ive vs newcomer and epic craftsman Felix Krause.

Jony Ive has brought us so many beautiful pieces of hardware over the years and has been instrumental in the Apple we all know and love today. He also inspired one of our favorite parody videos about the new Macbook One:

[responsive_video link=”https://www.youtube.com/watch?v=KHZ8ek-6ccc”]

Felix Krause on the other hand has saved us countless hours over the past few months with his amazing suite of Fastlane tools. We used to true through mundane development tasks, but now we can automate all the things. Here he is speaking about Fastlane:

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

So who would get your vote? Chamfered edges or developer automation made simple? Answer the twitter poll here

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

Xcode vs Android Studio

And here we have a classic showdown. The most popular IDE for iOS vs the most popular IDE for Android. If you’re a mobile developer, odds are you spend almost all of your time working in one or both of these programs. They can be your best friend or your worst enemy.

If you’re a mobile developer, you probably have very strong opinions about each of these. Xcode, like most things Apple, tries to make things simple, but as developers we often play the role of power user. We love storyboards, playgrounds, and the speed of deploying a new app to the simulator. On the flip side, using Xcode always feels like you’re one step away from disaster, and frequent crashes and restarts will wear on you after a while. This erratic behavior has even lead some developers to think Xcode is a sentient being. Android Studio provides a great environment to craft your Android masterpieces. Google’s constantly putting out beta versions of new releases so developers have more tools at their disposal as fast as possible. While Android Studio lacks some features like a robust visual layout editor and proper Android simulation (not emulation, which is what Google currently offers, and is terrible), it makes up for it with its great refactoring tools and the ability to create gorgeous layouts with simple XML (I dare you to edit your XIBs in XML!). Plus, Android Studio is an extension of IntelliJ which has tons of great support from its developers and the community. You may use and love both programs, but only one can reign supreme!

If you’re a mobile developer, where would you rather spend your time? Answer the twitter poll here

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

Jenkins vs AWS

In our final match of the day we’ve got Jenkins vs AWS.

Though not directly related, both Jenkins and AWS provide invaluable services to developers. Jenkins provides a simple yet extensive interface for continuous integration which keeps dev shops constantly aware that their tests need to be updated (because a failing test clearly means the test is wrong, not the app). Amazon Web Services is perhaps the leading cloud hosting platform and their fame is nothing short of awesome. Developers can deploy directly to their Elastic Beanstalk instances with a single command and integrating your apps with their hosted storage (S3) and database options (RDS, DynamoDB, etc.) is well documented and incredibly useful. It’s hard not to love both of these services for their essential contributions to shops big and small, but you can only vote for one!

Answer the twitter poll here

Mar

Mobile Madness – The Tools

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

[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

[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

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

Mar

Mobile Madness – The Code

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

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

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

First up: The Kings of the Mobile Kingdom

iOS vs Android

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

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!).

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.

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.

Answer the twitter poll here

123 4

Actually, it depends.

Advantages of Hiring

Advantages of Partnering

On CTO Full Stack Ninja Unicorns

There are always downsides to both

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

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

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

Why go native?

Swift vs Jake Wharton

Swift

Jake Wharton

Who will be the winner?!?

Limor Fried vs Erica Sadun

Jake Wharton vs Jake Marsh

iOS vs React Native

Objective C vs Swift

Steve Ballmer vs Steve Jobs

Jony Ive vs Felix Krause

Xcode vs Android Studio

Jenkins vs AWS

Xcode vs AppCode

Android Studio vs Eclipse

Jenkins vs Travis CI

Heroku vs AWS

iOS vs Android

React Native vs Xamarin

Objective C vs C++

Java vs Swift

Recent Posts

Archives

Categories