OmbuLabs Blog

Frontend development is so exciting nowadays! There is a wide spectrum of opportunities in each particular project. There can be tons of different interesting cases related to feature development, bug fixing and testing! A lot of new components, configurations, and flows.

Hello everyone, this is my first blog post on the ombulabs.com blog. I am so excited to have joined the company and to have the opportunity to write here.

Today we will discuss the I in SOLID which, you may or may not know, represents the Interface Segregation Principle (ISP). This is the fourth article in the SOLID series. We have already discussed the Single Responsibility, Open/Closed and Liskov Substitution principles.

In this post we will discuss the value of and the process for crafting easy to maintain interfaces. If we have enough time we will also discuss how interfaces might apply to dynamically typed languages such as Ruby. With no further ado, let us start by finding out what an interface actually is.

This article covers the basics of onboarding with a new client as a software engineer contractor. We will look at the people, resources and dynamics involved in successful onboarding with thoughts to reference as you onboard.

This post is the third one in the SOLID principles series. The first post discussed the single responsibility principle and in the second post we discussed the open / closed principle. Next, as the title suggests, we will take a look at the principle represented by the letter L from the SOLID acronym. L is for the Liskov Substitution Principle (LSP).

In simple terms LSP requires that supertypes and subtypes be swappable without affecting the correctness of a program.

In a previous post we considered the practical value of the Single Responsibility Principle (SRP). This is the second post in this series where we take a deeper look at each of the SOLID principles.

Robert C. Martin (a.k.a. “uncle Bob”) refers to the O in Solid as the heart of Object Oriented (OO) design. He goes so far as to say that this principle improves reusability and maintainability more than any other OO principle. You most likely already know that the O in SOLID belongs to the Open/Closed Principle (OCP).

We often hear about SRP or DRY (don’t repeat yourself) but seemingly less often about OCP. It turns out that this principle lays the foundation for many of the OO best practices. In this post we will talk about OCP and find out why uncle Bob is such an advocate of OCP.

We agree with Sandi Metz when she describes Object Oriented (OO) design as a style guide for arranging code. The so called “OO style guide” is underpinned by a few rules that we have come to know as the SOLID principles.

In this post we will discuss the S in SOLID. We will talk about the significance of this principle and perhaps even look at some practical ideas for applying it.

Last month, Snap announced a new product during the Snap Partner Summit 2020, Snap Minis. Minis are bite-sized third-party experiences that live inside of Snapchat and can be accessed through Snapchat’s Chat interface. They’re built on the same principles and technology as Snap Games and are easy to develop, allowing you to build an experience that is available to Snapchat users worldwide.

OmbuLabs recently developed a Snap Mini for one of our clients. In this article, I’ll share the main advantages of launching a Snap Mini and how we can help you get started:

With the constant pressure to both find and then execute on client projects, agencies often lose sight of the possibility of working on internal projects. While the initial reaction is often to dismiss them as a distraction from the important client facing work, carefully chosen interal projects can be very valuable. Aside from the obvious benefit of solving internal problems that might not have a readily available solution, they also provide training opportunities for developers. They give you a chance to try new ways of doing things with relatively low risk, or perhaps preview new languages and frameworks you’ve been considering.

One of the most fundamental tasks when writing or refactoring software of any kind is breaking the problem down into smaller parts. When you’re first starting out - and even as you continue to gain experience - figuring out what those parts should be, and where they should live within a codebase can be a daunting task. Design patterns and principles can help, but trying to keep them in mind as you design and implement solutions can be overwhelming.

Thankfully, there’s a pair of principles that can cut many of these gordian knots, and render decision making much clearer, simpler, and easier to articulate to others. Understanding and using the concepts of coupling and cohesion to guide my design and refactoring decisions yielded immediate results for me.

Tough Love

One of the first things that a journeyperson programmer will have to learn when they transition from full time student to working developer is that things in the real world are never as cut and dry as their classes may have made it seem. At the end of the day, software is not written because we love building castles of logic in the sky, it’s written to solve a real problem. That might seem like a trite observation, but it explains almost everything you observe as a working developer.

No app is flawless. We all know that. Quality Assurance is an important part of any software development process and the better the tester, the higher quality the software that gets deployed to production.

But… how to be a better manual tester? Applications have evolved greatly and are becoming more and more powerful, but the manual testing process stays pretty much the same. So what is it that will make you stand out?

Here at OmbuLabs we have some techniques that we employ that ensure our high satisfaction rates. In this post, we’ll share some tips with you.

Manual testing is a necessary part of software development and quality assurance. And although it’s important to have a dedicated tester in your team, you as a developer can also help speed up QA, and thus the software development process, by becoming a better manual tester of your own code.

But how to do that? I’ll cover 4 simple points that will help you get there!

As of 2016, we will no longer work with clients on fixed bid projects. They are not a good fit for us and we are not a good fit for them.

All of our clients are startups. Fixed bids are counterproductive for startups. They give the client a false sense of security and they punish changing requirements.

Fixed bids make clients think that their project will be finished in a fixed period of time if their requirements don’t change while developing the project. That is a big if!

Quality should be present in everything you do, but it should be balanced with the time you spend working on a feature. Does it feel like you’ve been working on this feature for a really long time? Maybe you have. Is it “done”?

That is a tough question, so I’ll write down our definition of done.