Category

Articles

8 Favorite Open Source Projects of 2018

By | Articles | No Comments

Wow! 2018 has been a banner year for opensource-centric companies. RedHat one the original open source companies was acquired by IBM for $34B. Github — the developer platform built around the open source tool git — was acquired by Microsoft for $7.5B.  Gitlab – a company built on open source products raised $100m and is now valued over $1B.

At Orange Robot we leverage the awesomeness of open source projects to build new software projects faster. The huge breadth and quality open source projects are always amazing.  In fact, the free software often amazes/confuses my non-technical clients (“Why would anyone give this away?”).

This list does not include fundamental projects such as Linux, git, and Python that are critical to custom application development. Instead, here are some our most used/loved projects in 2018.

More Features less Fuss

  1. Django makes it easier to build better Web apps more quickly and with less code. More than just Django, the entire ecosystem is fast, secure and scalable. I am often amazed how fast you can build sophisticated REST API with Django and Django Rest Framework. Django dumped Python 2 support in 2.0 and is an awesome reason to migrate legacy projects to Python 3.
  2. ReactJS is a JavaScript library for building user interfaces. It is wildly popular which means there is a lot of great packages (e.g. Create React App, Material-UI), a growing base of knowledgeable developers. ReactJS is our default tool for building user interfaces in web applications.
  3. PostgreSQL, the self-proclaimed “world’s most advanced open source relational database”. In fact, Postgres is older than many of the devs these days, with over 30 years of active development; however, it is still rocking along. The great GIS support, JSON capability, broad support, and multiple SAAS offerings make it a great database choice.

Putting the Dev in DevOps

  1. Kubernetes is an open source container orchestration platform that can automatically scale, distribute, and handle faults on containers. Its popularity is boon to companies as they can now run services in all the major cloud providers: Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes (Amazon EKS), Azure Kubernetes Service (AKS) using Kubernetes. Even upstart cloud providers like DigitalOcean have a Kubernetes offering.  Kubernetes gives customers more choices and saves development and deployment dollars.
  2. Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy. Developers need “glue” to connect everything together in cloud-native architectures built on top of multiple services. Ansible is a great glue layer.

Developer Tools

  1. Prettier is an opinionated code formatter. Code formatting seems simple — but style guides can lead to holy wars and an inconsistent code base is just yucky and confusing to developers. Prettier takes all the opinions and EFFORT out of code formatting. Prettier is my favorite new (to me) tool of 2018. For the reason, A simple but excellent tool that saves time and sanity. Let’s be real no ONE likes formatting code.
  2. Black – Same as Prettier but for Python. See above☝️. Python formatting is way easier than Javascript, so Black is not quite as revolutionary as Prettier.
  3. Atom is a hackable text editor for the 21st Century. We spend all day editing files and Atom makes it easy.

All done! ✨ 🍰 ✨

Check your S3 Storage Settings!

By | Articles | No Comments

Psst, Your S3 is showing!

Your application security might not be as good as you think. S3 security breaches are in the news way too often. These breaches are not the result of sophisticated hacks, but simple misconfigurations akin to not locking your front door.

Having private moments exposed can be embarrassing. Leaving all your sensitive files open for all to view is more than embarrassing. It is publicity nightmare with legal ramifications.  More than ever, application security is critical for application development.

Cloud providers have great solutions for file storage – AWS S3, Google Cloud Storage and DigitalOcean Spaces.
These tools allow unlimited storage of your files, fast access, and an affordable price. The systems use on-disk encryption and access over https.

With all these security features your files are safe and sound, right?

Maybe, maybe not. If your development team is not up to speed they can press the ‘easy button’ and allow all your files to be publicly readable. Instead of properly implementing security they rely on obscurity.

“There are some many files on Amazon Web Services they will never found ours.”  — said many embarrassed developers

Of course, your rockstar development team would never do that — right?

Obscurity never works for long. There are numerous public tools that scan Amazon for public S3 buckets with hidden data (e.g. DigiNinja Bucket Finder).

S3 leaks are not new but have been happening at an alarming rate in recently.

It has already happened to likes of Booz Allen Hamilton, a partner of Verizon, Dow Jones, and a DoD security firm and many many others. These failures exposed nearly 10,000 resumes, 14 million customers records, sensitive military files and more.

What can I do?

If you already have a project deployed to the cloud – you should audit your file permissions right away. Any buckets with public access need to careful scrutiny.

If you are in process of developing a new web application check with your development team to ensure all your S3 buckets are secure.

We can help. Orange Robot provides software management consulting services and turn-key development solutions with a focus on reliable secure applications.

Schedule a Free Call Today

 

It Started as a Simple Request

By | Articles | No Comments

It started as a simple request.

It was a cold, lazy day and my wife asked me to move furniture from room A to room B. Easy enough I can get that done in a couple of hours — I foolishly thought.

Initial estimate: 3 hours.

As with any project, initial estimates are highly speculative.

After removing the first desk, the scope creep starts. The wall behind the desk was a mess. It needed to be repainted.

“How about Accessible Beige?” New paint color — more scope creep.

Luckily, it was still early in the day. I could prep the walls, make a paint run, and get the walls painted today. Right?

New estimate: 1 day.

“Those are soooo ugly.”
Issue #2 (or is it 3?) The desk was hiding two vintage outlets that matched the old wood paneling. Even worse, outlet boxes were metal and stuck out from the wall slightly as a holdover from the original wood paneling design. (Technical debt is everywhere!)

At this point, we had to make a decision to fix it right or ignore the problem.
Adding electricity and legacy technology into the mix kills any schedule.

New estimate: Unknown.

Given there no hard deadline (i.e. company coming over), we pushed ahead to fix it the right way.

Removing, the old outlets I found that one of them was black inside where it had shorted against the metal outlet box. Bonus points: fixing fire hazard!
At the end of the day, the electricity issue was closed. The next day, we got the room painted and it looks great.

Final work time: 2 days (16 hours)

Sound familiar? From a schedule point of view, the project seems horrible: 3 hours to 16 hours (For program management nerds: Schedule Variance -433%)!

On the other hand, keeping the original schedule would have resulted in a product that was requested, but not what was wanted.

Moving the furniture into a room that looked bad would have simply resulted in an unhappy customer and new work to move the furniture (again) and repaint.

Next time, you are working on a software project consider a project at home. How often does the project grow?
In my experience is about 100% of the time.
“What about if we also did this?”

Software estimates are almost always wrong because of changing the scope and the unknown technical difficulties. To keep your project on track here are a few tips.

  1. Ruthlessly focus the project scope to achieve your goal.
  2. Understand the why! You need to have a measurable goal tied to the project. Acquire X new clients in first 3 months. Improve conversion rate by 10%.
  3. Technical gotchas, are a fact of life in any software development project but hiring experienced team can help fix the fire hazards and defer the annoying issues.
  4. Track your progress regularly. At Orange Robot, we prefer weekly updates. Longer time periods can turn a small misunderstanding into an expensive mistake.
  5. See 1. “It might be nice” kills more projects. Focus on 1 goal at a time. If it is not critical to your “why” do not do it.

Have a new software project that needs help with scope or roadmap?
Or a sinking software project that needs to be rescued?

We can help. Orange Robot provides software management consulting services and turn-key development solutions. Alas, we are not available for home remodeling help.

Schedule a Free Call Today

How Building an Application is like Building a House

By | Articles | No Comments

When people plan to build a house, they may contract an architect to design it. He’s expensive, but he’ll make sure you get exactly what you want, is up to code, and will probably even suggest things you will also want to potentially add that you didn’t even think about. You’re not stupid…he’s just good at it and it is what he does… and he’s done it a lot.

When it’s time to actually build the house, you don’t generally give that guy a hammer. He’s probably done it. And he’s possibly efficient and meticulous. But a carpenter can do the job, and he can probably do it for a whole lot less per hour. Of course, your carpenter probably isn’t also a licensed electrician… or plumber. You’re going to have to contract several people/firms. And you’re going to want to make sure they are good at what they do. Not pretty good at doing everything.

When you plan to build an application, you want to have it thought out by a guy that has built things before. And someone who is good at it. A Software Architect that can take your ideas and requirements, and design a solution that gives you exactly what you want, is up to code, and will probably even suggest things you will also need potentially to add that you didn’t even think about.

When it’s time to actually build that application, you don’t generally give that guy a keyboard. … you’re getting the point. Hire a Software Developer. More specifically, hire a Software Developer who is exceptionally good at the specific things that the design requires.

When I first started working (some 20+ odd years ago), I fancied myself as a Company Man. Think old-school IBM… back in the day when you gave a company your life, and they took care of you for life. Unfortunately, I was born about a decade too late for that to be a useful career plan. The industry gained momentum. So many technologies, languages, platforms. Just as the medical field advanced from the days when a generalist could do everything, now we require specialists. And it is impossible for anybody to be a specialist at everything.

So, why do some developers feel underpaid? Because for the most part, the current industry will hire full-time generalists. And a general developer doesn’t always provide a service that requires a specialist level of pay. Companies hire the software equivalent of a handy-man, because they may not always understand what they are going to need, and when they might need it. In fact, some of the today’s larger companies actually do employ a cavalcade of specialists but treat them as a group of generalists due to a lack of specialized skill tracking over time.

So, if you pay your Architect a Carpenter’s wages over the course of a year, then he’s going to feel underpaid. Alternately, if you need an Architect for a couple months, but you hire him full-time for an entire year (worried you might need him), then he’s going to feel overpaid for the carpentry work. He probably won’t complain about the money… but he knows you and he is both not getting the full potential.

Unless you’re a company of plentiful ideas and solid R&D budget, don’t hire a full-time Software Architect. You should contract a Software Architect. Let him work with you to design (or re-design or performance analysis/improve) your applications. Then hire or contract (or search your current developer base) the right team of specialists/generalists to build and maintain from a solid foundation.

That provides a value proposition that is appealing to both sides of the coin.

Mobile Dev Stack: Cross-platform toolset or not?

By | Articles | No Comments

As you start to build a new mobile app (or maybe you have a mobile app that needs major renovations) — the first technical choice is: Do you leverage one of the many cross-platform tool-set available or go directly to the iOS and Android SDKs?

There are absolutely situations where the cross-platform tool-set approach is preferable to writing and maintaining purely native applications on multiple platforms. But before you hook your horse up to that attractive looking wagon, let’s discuss a few important considerations that might save your project, and your bottom line.

Cross-platform mobile development has come a long way in the last couple of years. Lessons learned have pushed the development of these frameworks to address the more painful points (performance, access to native APIs, test-ability…), moving further from the old Hybrid approach that leverages WebView components toward a much more native experience.

That being said, here are 5 Things to Consider Before Leveraging Cross-platform Mobile Development Frameworks

1. It Ain’t All Technical.

Oh, I’d love if it were. But let’s not pretend that it is. If it were, then the considerations would be much easier.

You only get one chance to make a first impression. And if your application is not responsive and intuitive, then your retention rate will suffer. Of course, if it takes you 2 years to get your MVP into the customers hands, they may already have something else to hold.

I will say this unequivocally: An application written entirely using the native platform SDK directly will result in an application that is functionally equal or better than one written using any proxy framework.  I will not qualify this statement here except to put the burden of proof on the counter-point: How can a tool-chain that relies on generated native code (as well as a bridge to access said code) ever perform better than something written directly to the native platform? It cannot, and thus the choice isn’t about technical superiority, it is about time and money.

The reality of the situation is that there are a lot of tough decisions when you intend to spend good money creating something that you expect to leverage to make better money. Somewhere the Wallet behind the work is going to want some input on how much it’s going to cost, and how quickly bills are going to start filing back in instead of falling out. This is probably the greatest driver behind making the tough choices. I support the Wallet, and I don’t envy his job. What I will tell him, and I am telling you now, is please sit at the whiteboard with me and discuss the risk versus reward of the next 4 points we’re going to discuss. If you can’t say them out loud, then maybe you don’t yet understand the risks. And if you don’t understand risks, then you don’t really understand the final costs.

2. Hold My Beer, I Got This.

I get it… People are comfortable with what they know. And they honestly believe that if they are proficient enough with a certain tool, then they can carry that tool out into the world and do magical things … that the tool was not originally designed to do. Let’s say you already have a full-time software developer, and he’d like to keep his job, thankyouverymuch. He’s already proficient in a programming language (say… JavaScript), and most bankable developers these days are proficient in two or three, then you probably feel you can tackle this mobile problem without hiring and training new talent.

Your JavaScript web developer is going to be tempted to point out that React Native, developed and maintained by Facebook as an open-source framework solution, can be used to create “native” mobile applications using only JavaScript.

Let me slow your roll right there.

The languages for mobile development are Objective-C/Swift for iOS, and Java/Kotlin for Android. If you do not have a developer with these proficiencies, then you may not be able to objectively make the right decision. I’m not saying your RockStar developer isn’t capable of “stackoverflowing” his way into a demo-able version in the vein of your MVP. But are you both sure he can actually produce that MVP on his first attempt into this new realm? Can you afford this new expedition? This leads to my next point…

3. Down the Rabbit Hole.

Shortcuts can be dangerous. One time, pre-Google, my wife and I were trying to get to a party. The major roads were busy, so we decided to cut through a neighborhood we’d never been in before. We knew the destination was just on the other side. We certainly spent the time moving in the right direction, and we saw some really nice houses and landscaping that we decided we might incorporate ourselves. However, what we learned after spending that time is that even though we got close to where we wanted to get… we couldn’t quite get there. We had to go back to the front of the neighborhood, and get back onto a path we knew would succeed.

Your lead developer is your navigator. If he’s not familiar with developing mobile applications, then bear in mind that choosing the cross-platform shortcut may take you down a path that will not lead easily (if at all) to your MVP.

4. Keeping Up With the Jones’.

Apple and Google have done a fine job of making sure that iOS and Android stay current to meet the ever changing needs of the consumer and push the capabilities of our evolving mobile devices. XCode9 with Swift4 is coming out this fall. Kotlin is just starting to get its hooks into Android, as Java 1.8 support is leaking into Android Studio (Canary). Think about this… there is no other platform on which the underlying hardware technology evolves, the operating systems evolve, and the very development languages evolve on a semi-annual frequency that is adopted by the general population. Quite literally, if it takes you 6 months to author both iOS 1 and Android 2 applications, your development lifecycle will experience at least one major-revision language migration on one or both platforms. And note the key words in that last sentence: “major-revision”. They aren’t tweaking the languages, they are transforming them. Not to mention the myriad of hardware accessible changes (Bluetooth Low Energy, Graphics, Camera,…) and additions (Watches, VR devices,…). Keeping your application, unit tests, and build environment up-to-date with all these changes will be a full-time job. Whatever methodology you choose to bank your code base on will need to move just as fast. This sets up my last point…

5. Who’s Steering this Boat?

Whenever you choose to put a proxy between your code and it’s target platform, you are choosing to give up some level of control. This is the risk/reward point that you will eventually have to make. What you are deciding is to take the risk to speed your MVP to market at the expense of some level of control. For simple, minimal applications that don’t interface too heavily with external components and don’t have very complex background tasks, this is very advantageous. For applications that are more complex, there will be a need for some level of Native coding in addition to the cross-platform work. And this means learning not only the native languages but also the framework environment that sits between you and your platform. And if your choice of cross-platform tool-set can’t keep up with the shifting landscape from point 4 above (or worse, fails to maintain support at any level), then you’ll learn the hard way that the risk you thought you were taking just tore off your rudder and threw out your oars.

And remember, not only are these frameworks supporting changes to the Native APIs, but they are also trying to keep up with changes to the other underlying technologies on which they are built. Take for example Ionic, who recently released Version 3.0 that was migrated to Angular 4. Since the initial release, there were 13 updates address numerous bug fixes — in just 4 months.

Need a Little Bit More…

Don’t let me scare you away from the cross-platform tool-set. But the risk rewards truly need to be quantified through analysis. Consider that Facebook leverages a cross-platform framework for part of their mobile offerings. But Facebook isn’t likely to let that framework (React Native) steer their application. Facebook will steer React Native. After famously transitioning from using an HTML5 approach to a native application offering (2012), Facebook authored their own cross-platform framework. Not many companies can mitigate the dependency risk that way.

If you’re still early in the life-cycle of your mobile development and don’t have your own Native mobile application team, let us help you understand your risk/rewards.

Orange Robot is customer software development firm that designs and builds native mobile applications and back-end server solutions.

Looking to build or refresh a mobile app? Let's talk

5 Interview Questions to Ask your Mobile App Developer

By | Articles | 2 Comments

You are ready to get your app built, but where do you start? How do you find the right mobile app developer? There are lots of options to choose from large mobile app development agencies to freelance mobile developers and everything in between.

When you find your mobile app developer, how do you know they are the right one? This guide gives a few fundamental questions to help weed out the pretenders from the contenders.

Let’s start with the basics.

Version Control.

How do you store and share source code?

👍 Answer:

We share a Github (or BitBucket, etc) repo with you, so you can access and review our work at any time. We follow industry standard best practices for source control.

😱 When to run:

Version what?
We will send code to you anytime you ask….
We do not need version control — we backup our machine nightly.

Bottom line on Version Control.

Awesome source repositories are available for free or close to it. There is no reason for any developer not to use version control for mobile app development. Your app source code is your a critical business asset. We suggest signing up for an account at Bitbucket (or Github) and inviting your development team to your repo. This way you never lose control of your code.
A non-technical product manager, may not understand the source code, but it is critical to have control of in case something happens to your developer.

Do not hire developers without basic skills like Version Control!

Yikes! Why you need Version Control.

Collaboration

How will you collaborate with our product team?

👍 Answer:

We provide regular weekly updates via video conference, are available via chat, email, etc as needed. We use _________ (Trello, SmartSheet, Basecamp, et al.) to manage our backlog of work. To start we will work with you on initial scope and priority of tasks to match your budget and schedule. Ongoing, you have access to this tool to monitor progress and reprioritize remaining work for your mobile app development.

😱 When to run:

We will send you the product when it is complete.

Bottom line on collaboration

Regular, scheduled updates are critical to success. Doing the wrong work will kill your schedule (and budget) faster than most technical roadblocks.

Work backlog (todo list) needs to be managed in a tool; otherwise critical items can get dropped and no-core features can creep up costing you time and money. There are tons of good tools and something as simple as a Google Sheet works for simple projects.

Collaboration is a two-way street, the best mobile app developer will fail to deliver if the Product Owner is not engaged and providing regular feedback. Make sure your in-house team is ready to support

Security

How do you mitigate the OWASP Top Ten Mobile Security Risks?

👍 Answer:

We take security seriously at ________ and is huge subject. Here are five basic things we do make sure all our applications have a secure foundation.

  1. We use prefer to build natively on Android and iOS. This removes an unneeded layer and vector for attacks.
  2. Start new projects with the latest (stable) version of tools.
  3. Encrypt all data moving off the phone.
  4. Store as little data as possible.
  5. Request as few mobile permissions as needed. Less permissions also ease the app approval process.

😱 When to run:

🤔 O-What?

Bottom line on Securty

Application security is big deal and it is a dangerous world out there. The risk is a function of your applications and business. For high-risk applications (very large footprint to attack or very sensitive data), security and compliance are problems best left to a team of experts. For the rest of us, use well known supported and secure tool chains and follow development best practices.

Testing

How do you plan to test the new mobile application?

👍 Answer:

As features are built out during mobile application development, we build automated tests to make sure everything stays working! We will roll new versions of the application from internal testing, to external beta testing and finally to general availability. We also instrument our code, to watch for problems that crop up in the wild because they will.
In most cases, we do rely on you, the product owner, to provide domain expertise to validate the desired functionality.

😱 When to run:

🤔 We click on few buttons but depend on you to test most of the functionality.

Bottom line on Testing

It is often said that👇

An untested line of code is a broken line of code.

Ok, maybe this is not said that often but it should be! Testing may add some work at first, but in the long run, it makes any project easier to build features that delight your customers instead of spending money fighting bugs.
At this point, both XCode and Android Studio have provided so much framework around unit testing and ui testing that it is no longer reasonable to claim it takes too long to generate tests.

Listening

How would you attack this problem? (after you explain what you are trying to do)

👍 Answer:

Do you have a whiteboard? I can show you…

😱 When to run:

🤔 Buzzword. Buzzword. Buzzword. Trust us.

Bottom line on Listening

If you can not explain your problem and the mobile app developer reflect back an understandable plan of attack — then things are not going to work out. This plan will be wrong and incomplete, a good developer can draw you a map of where the hard things live and what features are easy. This on-the-fly plan will not have a price attached and may have black boxes that need to be filled in by other experts, but it should make you comfortable that your development team can listen to you AND speak in a language you can understand.

Is that it?

What about technical chops? Red Black Trees? Bloom filters? Data compression? Technical skills are important, but projects are often killed by the simple things, so make sure you get that right first.

Orange Robot is customer software development firm that designs and builds native mobile applications and back-end server solutions.

Looking to build or refresh a mobile app? Let's talk