I’ve been using NodeJS for a project of mine and I was used to setup my package.json in this way:
I thought: the newer a library is, the better.
And I was wrong. In this way there’s no control on what is going to production/staging servers, if a new version of some_external_lib becomes available, let’s say 1.5.0-i-am-very-alhpa, that unstable code will be deployed on production.
Since the local environment is no longer aligned with production/staging (even if we cast a npm install locally), any bug introduced by unstable code will be very hard to spot in the local environment (likely you’ll end up debugging on production server).
Lesson learned: eradicate any “>=” from your package.json.
Using many callbacks without embracing a functional style of coding can lead to mistakes that are very difficult to spot.
Consider this example: we have an array of user object and for each of them we need to fetch the first and last name using Facebook Graph API.
Using a procedural style:
This is just a pseudo code, suppose the method $.api.FB() fetches information from Graph API.
At the end of the cycle, each record has the fields first_name and last_name filled in with values from Facebook.
That in theory.
The problem with this piece of code is that it launches several asynchronous operations and you cannot tell which one is going to end first, likely the entire loop will end even before the first asynchronous operation is complete.
In a cloud environment, where every request could hit a different physical server, is not assured that the first call will end before the next one.
To avoid this error, just turn the code in a functional style:
Here it works because the idx var it’s local to the anonymous function inside the each and, thanks to the closures, it will live until the functions defined inside the scope (the callback) are complete.
Every time we create an anonymous function we have a brand new context in which we can mess around without worrying about what is happening before and after: less side effects and less errors, adieu for loops.
Have you ever tried to work on your local code base of WordPress using a shared database (for example the database on staging/development server) with the rest of the team?
Normally it’s not possible since WordPress stores the URL of the blog in the database and immediately redirects if the current host name doesn’t match the stored value.
Using a centralized version of the database might be useful, in particular if more developers are working on the same blog and they don’t want to replicate locally all the settings of the database in staging/dev.
Here is a plugin for that:
Just copy and paste this in a file inside the plugin directory (for example /wp-content/plugins/disable-redirect.php).
P.S. There are similar plug that works on the redirect_canonical filter, which works for the home page, but it doesn’t for the administration panel. This plugin cheats WordPress faking the option “siteurl” and “home”.
Works nice for blogs hosted in the root directory of the domain, for blogs hosted in subdirectory additional PHP might be required in the fake_siteurl() function.
Pay attention on disable the plugin in a production environment since it could compromise the blog security.