The functional programming works based on the concept of data immutability and on mathematics expressions where each pure function has a particular return that can be used as param by another pure function.

“As developers, we gravitate toward frameworks that help us create extensible and clean application architectures. Yet the complexity of our codebase still gets out of control, and we’re challenged to re-examine the basic design principles of our code.”

I start my review with this citation coming from Luis, it synthesizes why functional programming is so important. I can’t help to think this book has surprised me and surpassed my initial expectations. It happens due to the fact I thought it’d be quite a challenge to share and exemplify the functional programming on a JS universe the way he did.

He’s constantly pointing issues between the functional programming concepts and how the JavaScript is meant to work. But as soon as he does that, he goes ahead and provides us with a perfect workaround suiting every single scenario. For example, he indicates the use of the Object.freeze method to stop the mutability nature of JavaScript and the Ramda lib, which is an outstanding addition to your project in terms of using pure functions and data manipulation.

The book relies on several examples, going from really straightforward ones to others in which you’ll have to carefully prepare the environment installing some third-party libs. I’d strongly recommend you to follow each example in order to be able to fully understand and fix the concepts behind that specific excerpt of code.

Another aspect worthy of mention is how he dissects both imperative and functional programming, tracing, most of the times, a parallel between each and every aspect of those two different paradigms. It makes the book really uncomplicated to understand.

One thing that disappointed me was the book length x detail level comparison. For instance, I believe he could achieve the same overall result with dozens of pages less. That would have made the book lighter, more concise thus providing its readers a faster and smoother experience.
It’s ultimately a functional programming book, but it requires a certain level of JavaScript proficiency from its readers, especially because of the practical approach he opts to use to explain the concepts.

I’d say someone partially aware of how to apply the functional programming concepts in other languages such as F#, could have a hard time trying to figure this one out. In other hand, it’s a perfect fit for those who have an advanced JavaScript knowledge and want to give functional programming a try.

Most of the devs possibly start their careers using imperative programming. It’s the most common paradigm, hands-down. A strong opposition to this paradigm is the functional programming or just FP.

The functional programming works based on the concept of data immutability and on mathematics expressions where each pure function has a particular return that can be used as param by another pure function.

Broadly adopted in the academic universe, FP has also started to gain territory in a professional context.

Even though the final outcome will be pretty much the same, these two paradigms are so different from each other that this can largely impact the workflow and the code maintenance.

One of the best ways to explain the FP is to compare it with the imperative paradigm.

In the imperative programming the dev writes the code as a sequence of orders so the system behaves as expected. The software will then execute the predefined actions as it should.

Functional programming is quite different in this regard, since the dev should write the functions and the software will work based on the interact built by these functions. The result of a function will become an important param of another function and the cycle goes on.

It also generates a code that is easier to read, maintain, and brings many features to the devs. It doesn’t happen to the important paradigm, where a single change can create unnecessary repetitions or incongruities. FP also provides a better and smoother experience with tests and debugging due to the fact the functions are more isolated and simpler to be evaluated.

The bad part about FP, is that it can be harder to assimilate in a first moment. Also, it can be more difficult to estimate deadlines making the management process more challenging than the imperative model.

Separation of Concerns, was a term created by Edsger W. Dijkstra.

For instance, it’s the thermology used for when you can identify and isolate each aspect of a software so it becomes clearer what every part is supposed to accomplish.

This approach gives us many advantages such as: maintainability, easier debugging and bug fixing and the software overall. By using it accordingly it gets easy to replace a portion of your website whenever needed.

Single Page Applications

Let’s try and categorize each aspect of an SPA. We can split it into three sub-items: State, View and Actions.

State
All data inside an app, from a request response to all data that was statically set on the code.

View
It’s basically our HTML + CSS, they’re rendered according to the data fetched from the app itself.

Actions
These are the events that occur inside our app, sometimes they modify the State, sometimes not.

We can split these events in two:
— User interaction: Button click, data being filled in a form, etc…
— IO: Network events, such as a request being made.

Now, how do they integrate? It’s quite simple actually. The State is responsible for storing the data and delivering it to the View. The View then will render relying on the data received. If an Action takes place, and changes the data inside the State, then the State sends the brand-new data to the View and the whole cycle restarts.

This description can be seen in every SPA, regardless of the technology involved. The question here is that several frameworks have those three parts glued together, being impossible to replace each ‘agent’ behind them.

React
Of all three parts we discussed, React takes role within one, the View. React doesn’t really care about how you manipulate the State or Actions, he just gets the data through the props and interact with the DOM to render the View.

Redux
In other hand, Redux is responsible for both the State and Actions, giving you the ability and flexibility to work with the View as your will.

A Redux Store contains three methods that allow you to work with the State via public API:

subscribe
By using this method, you can add a listener to the Store, that will be later invoked whenever a State change is performed.

dispatch
With this one you can trigger your actions.

getState
This method gives you the power to read the current State. It’s usually used inside the listeners, to capture the State when a modification occurs.

With these three methods you can pretty much integrate Redux with whatever View render lib you opt to use.

Analyzing both React and Redux makes it clear how they complement themselves and work in an independent way.

Redux is conceived on some functional programming concepts, such as immutability, and pure functions. We manipulate the State through these functions called Reducers, who have this signature:

(currentState, action) => newState

Watching the signature above closely, we notice we don’t depend on Redux to develop our unity tests, since we only have to call a reducer passing an object to simulate the current State and another one representing the action.

The same goes for other tests that must be pure functions as well. There’s an entire session designed for tests in the Redux documentation that’s definitely worth checking.

The functional programming concepts brought by Redux help us to expand our knowledge and the way we think logic. It’s also an entry point to this paradigm.

Redux and React are based on a unidirectional flux, which gives us a much stronger control over our app. And the best part is that this control comes without any difficulty when we need to integrate our app with a new lib.

React induces us to develop a component-oriented app, encouraging us to reuse code and create a modular app. Not only that, we can also rely on countless tools that improve our workflow such as React Hot Loader and React Storybook.

Wrapping it all up, these two technologies teach us how to think our apps in a modular way, inducing us to properly identify and delegate responsibilities in an intuitive manner. The simplicity to work with components brought by React leads us to divide them into small pieces, which stimulates us to reuse code. The way each lib has its own role to be played on our code teach us how to develop independent apps. The conclusion is that both React and Redux are a superb addition not only for me but for all of us devs.

The book starts telling us how the waterfall model, which is frequently adopted by the companies, is ultimately the reason behind many delays and increased costs. In this particular methodology, a large long-term plan is made on beginning of each project, resulting on some gigantic and almost useless reports.

The Scrum was designed to change that, aiming primarily to achieve a higher productivity plus quality combination. Hence the question: Is this utopic? Well, as soon as you read the book, and mainly start to working following the Scrum concepts, you convince yourself that it is definitely not.

Scrum was conceived based on its homonym coming from Rugby. In Rugby, the scrum is a moment on the game where every player should be perfectly tuned with his teammates, putting efforts in a coordinated and synched way.

The concept behind Scrum, is the idea of making regular breaks to check whether the project is following the right path. These breaks are also meant to identify obstacles, their workarounds and check if the partial results are satisfactory so far.

One of the main points Scrum brings is the idea of time management. For instance, how to do more in less time. Sutherland cites in his book: “Time makes up your life, so wasting it is actually a slow form of suicide”.

The book gives us a heads up when it comes to Multitasking, it encourages us to do one single task at a time. By doing so, we can both intensify our efforts to a specific job and avoid wasting time with the change of contexts.

Every meeting in the Scrum model, known as Sprints, ends up with important questions such as: What went well? What didn’t go well? What can be improved? The Japanese people use a word to describe this attitude: “kaizen”, literally meaning change for better.

I strongly recommend you to follow the Scrum model, as it is a proven way of increasing productivity and quality for every sort of project, especially those in the software development area.

The WordPress is a platform with the ability of captivating people, it is not unusual to see people becoming charmed with the WordPress universe. From my point of view Brad Williams, David Damstra and Hal Stern are a perfect example of this statement, in fact they wrote an outstanding book and it is possible to feel that they used this passion as the main fuel to accomplish that.

The WordPress’ functions are almost limitless, that being said, it is really difficult to have an approach that covers a high amount of features so deeply the way this book does. Starting from a single post and going all the way through Multisites, Themes, Plugins Development and even more.

The book has the hard mission of conciliating both theoretical and practical knowledge, and it deliveries it in the right rhythm. To almost every new feature shown, the book presents exercises to help you apply and reinforce the knowledge you just gained. Focusing on the fundamentals in the first half of the book, is not only essential but also the right move to allow people to be able to perform the advanced lessons in the second half.

In the beginning they present the core, they not only explain it but also show the importance of not hacking it. Moments later it is explained for us the role of the Loop and how it is the backbone of the WordPress itself. It is impossible to create Themes, Plugins and the most advanced Websites without knowing exactly how the Loop works and how to extract the maximum of it.

The book gives an overview about the Database design and its background working process, it is possible to check diagrams, and a detailed explanation about the meaning of each table and field. It is showed to us how to safely modify the table behavior and how to apply some security measures such as change the database prefix to decrease the likelihood of a successful invasion. Taxonomies and Metadata also play a great role in the WordPress universe, mainly for two reasons, first because it was always a major concern to build structures that allow the appliance of heritage in computer systems and second because the way the Database schema was build, this was not only the best approach to reach this process of heritage, but probably the only one so organised and straight-forward.

In the second part of the book it is showed to us key techniques and procedures as Plugin and Themes development. Due the way WordPress was brightly designed, is not a great deal to build Themes and Plugin.

At this point the reader has been told how to do advanced development and customization in WordPress, and if the book had ended there, it would probably already be worthy, but they would be missing something. What? Well, the true heart and fuel of the WordPress universe, which is the community behind it. This is another key point of the book, the way they explain the relevance of the community, the camps, the meetings and the friendly environment. It shows that WordPress is not only a platform, it is also a lifestyle.