I love Redux. It’s such an elegant and simple concept that solves so many problems. But like every other solution, adding new concepts to your code base can also introduce the occasional headache.
One of these headaches is that Redux does not enforce a lot of it’s conventions, but when you don’t adhere to them, things start breaking further down the road in strange ways.
Today, I’m going refer to one of Redux‘ three principles: State is read-only
Creating Microsoft Word documents in PHP can be a challenge. Word offers a multitude of options and settings and while creating a document in PHP you want do take advantage of those options to achieve a satisfying result. Perhaps you need to dynamically create documents for a client and the client will only know the capabilities of Mircosoft Word, but not the limitations of PHP libraries. This can result in an unsatisfied client.
In this article we will take a closer look at PHPWord and three different ways to create Word documents with it: basic easy templating, the creation of Word documents from scratch, and (going a little crazy there) the combination of both by merging existing templates with dynamically created documents. Hopefully, after reading through the text, you will have an idea of how to implement the perfect Word creator for your needs.
DreamFactory is a BaaS (Backend as a Service) that connects a multitude of data sources to APIs that apps can connect to. With our Agile Anti-Pattern App (MAPA), we wanted to move the patterns database out of the app, so that we did not have to publish a new version of the app every time we added or changed patterns. The simplest way for this was to put the complete data set (a tiered json file) on a webserver and tell the app to download from there. This would solve the problem, but be a pain to edit or version. The optimal solution would of course be a somewhat normalized database of patterns, their symptoms, their remedies, categories and a pattern-categories relation.
Wir alle kennen das: Projekte laufen wie geschmiert, es gibt wenig bis nichts zu bemängeln. Der Auftraggeber ist glücklich, die Stakeholder haben genau das bekommen, was sie wollten, und das alles in Rekordzeit und ohne das Team zu verbrennen. Und wieder haben wir ein Projekt erfolgreich abgeschlossen. Check.
Aber mal unter uns: Das ist doch ziemlich langweilig, oder?
Disclaimer: this article targets developers that are using Redux with React. If you are using Redux with another Framework, this article might not be important for you.
Last thursday, Dan Abramov gave a talk on JSConf Iceland called „Beyond React 16“. A few hours later, react-etc.net featured an article titled RIP Redux: Dan Abramov announces future fetcher API. While I agree with almost nothing that article has to say about Redux, the article got one thing right: Somewhere between 6 or 12 months from now, the way we are using Redux (at least when starting a new project) will be drastically different from the way we are using it today.
But before we take a gaze into the crystal ball, let’s take a step back and see what happened.