Category Archives: English

Important information about our Elixir and Ruby Open Source projects

You may have heard that Nubank has acqui-hired Plataformatec. Plataformatec has been working with Nubank over the past few months and Nubank saw great value on the practices and expertise shown by our teams. According to Nubank leaders, Plataformatec consultants have provided restructured rituals and new working agreements to its teams, and also brought improvements … »

Read more at the source

Elixir: What about tests?

There is no arguing about how important tests are for our application. But from time to time, when we are dealing with it, some questions came up on a daily basis. A very common day-do-day case is our application relying on APIs and external libs, but one of the things we don’t want our test … »

Read more at the source

OKR: lições aprendidas para você começar a aplicá-lo de forma efetiva

Depois do sucesso do livro Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs de John Doerr, praticamente toda organização vem buscando utilizar OKR como forma de desdobrar seus objetivos e medir os avanços dos resultados. Assim como qualquer modelo, framework ou ferramenta, existe uma tendência natural das pessoas acreditarem que o artefato … »

Read more at the source

Relation between Story Points and Development Time (Lead Time)

Frequently I hear speculations about story points and their relation with the development time. Questions like: “Why a 3 points card took so much time to be developed” “How long it takes to deliver an 8 points card?”, “Why the team took so long to deliver only this amount of points?” and others are frequent. However, when … »

Read more at the source

Review: Learn Functional Programming with Elixir

I have recently finished reading the book Learn Functional Programming with Elixir, from Ulisses Almeida, published by PragProg. I was curious about this book in particular because I wanted to know how a book that explains functional programming for people that are starting this journey would be My path to learning functional programming was not … »

Read more at the source

Welcome Wojtek Mach to Plataformatec!

We are glad to welcome Wojtek Mach to the Research and Development department at Plataformatec. Wojtek will help us towards our Elixir efforts, contributing to Open Source, communicating with our Elixir teams across multiple projects and joining our Elixir Development Subscription team. Wojtek is a software engineer with 10 years of experience. He started working … »

Read more at the source

Stop hiding the error and start fixing the problem

I’ve been working on Plataformatec for 5 years and one common mistake that I see developers making is hiding the error, instead of fixing the problem. This kind of behaviour can turn your product full of problems quickly by having a codebase with unnecessary defensive programming. Let’s explore that by taking a look at an … »

Read more at the source

What’s new in Flow v0.14

Flow v0.14 has been recently released with more fine grained control on data emission and tighter integration with GenStage. In this blog post we will start with a brief recap of Flow and go over the new changes. We end the post with a description of the new Elixir Development Subscription service by Plataformatec and … »

Read more at the source

Lead Time Experiment: Calculating Lead Time of the whole process

As you might have noticed, we have been testing new methodologies on our projects in order to improve them and be more agile. We started using Monte Carlo Simulation (Forecasting software project’s completion date through Monte Carlo Simulation), limiting the WIP of our process (Case Study of a WIP Limit Implementation: Why, When and How … »

Read more at the source

Using the test pyramid to have better feedback from your test suite

In this blog post, I’ll explain the problem of developers spending too much time trying to discover a problem in a failing test suite. A cause of this issue may be the lack of a good test feedback. A good feedback is one that happens fast with a helpful message. To illustrate this problem, consider … »

Read more at the source

Five reasons object-oriented design makes sense for PHP

March 13, 2014

Editor’s Note: Today we have a guest post from Brandon Savage, an expert in crafting maintainable PHP applications. We invited Brandon to post on the blog to share some of his wisdom around bringing object-oriented design to PHP, a language with procedural roots.

One of the most common questions that PHP developers have about object-oriented programming is, “why should I bother?” Unlike languages such as Python and Ruby, where every string and array is an object, PHP is very similar to its C roots, and procedural programming is possible, if not encouraged.

Even though an object model exists in PHP, it’s not a requirement that developers use it. In fact, it’s possible to build great applications (see WordPress) without object-orientation at all.

So why bother?

There are five good reasons why object-oriented PHP applications make sense, and why you should care about writing your applications in an object-oriented style.

1. Objects are extensible.

It should be possible to extend the behavior of objects through both composition and inheritance, allowing objects to take on new life and usefulness in new settings.

Of course, developers have to be careful when extending existing objects, since changing the public API of an object creates a whole new object type. But, if done well, developers can revitalize old libraries through the power of inheritance.

2. Objects are replaceable.

The whole point of object-oriented development is to make it easy to swap objects out for one another. The Liskov Substitution Principle tells us that one object should be replaceable with another object of the same type and that the program should still work.

It can be hard to see the value in removing a component and replacing it with another component, especially early on in the development lifecycle. But the truth is that things change; needs, technologies, resources. There may come a point where you’ll need to incorporate a new technology, and having a well-designed object-oriented application will only make that easier.

3. Objects are testable.

It’s possible to test procedural applications, albeit not well. Most procedural applications don’t have an easy way to separate external components (like the file system, database, etc.) from the components under test. This means that under the best circumstances, testing a procedural application is more of an integration test than a unit test.

Object-oriented development makes unit testing far easier and more practical. Since you can easily mock and stub objects (see Mockery, a great mock object library), you can replace the objects you don’t need and test the ones you do. Since a unit test should be testing only one segment of code at a time, mock and stub objects make this possible.

4. Objects are maintainable.

There are a few problems with procedural code that make it more difficult to maintain. One is the likelihood of code duplication, that insidious parasite of unmaintainability. Object-oriented code, on the other hand, makes it easy for developers to put code in one place, and to create an expressive API that explains what the code is doing, even without having to know the underlying behavior.

Another problem that object-oriented programming solves is the fact that procedural code is often complicated. Multiple conditional statements and varying paths create code that is hard to follow. There’s a measure of complexity — cyclomatic complexity — that shows us the number of decision points in the code. A score greater than 12 is usually considered bad, but good object-oriented code will generally have a score under 6.

For example, if you know that a method accepts an object as one of its arguments, you don’t have to know anything about how that object works to meet the requirements. You don’t have to format that object, or manipulate the data to meet the needs of the method; instead, you can just pass the object along. You can further manipulate that object with confidence, knowing that the object will properly validate your inputs as valid or invalid, without you having to worry about it.

5. Objects produce catchable (and recoverable) errors.

Most procedural PHP developers are passingly familiar with throwing and catching exceptions. However, exceptions are intended to be used in object-oriented development, and they are best used as ways to recover from various error states.

Exceptions are catchable, meaning that they can be handled by our code. Unlike other mechanisms in PHP (like trigger_error()), we can decide how to handle an exception and determine if we can move forward (or terminate the application).

The Bottom Line

Object-oriented programming opens up a whole world of new possibilities for developers. From testing to extensibility, writing object-oriented PHP is superior to procedural development in almost every respect.

PHP is the next language we’ll be supporting on Code Climate. We’ll be rolling out support in phases over the next couple of months, but the sooner you join our PHP early access mailing list the sooner you’ll be able to try it out – so reserve your spot today.

[…]

The Ruby Rails Aggregator