Recently at MyBuilder we’ve started to adopt React more and more (Facebook’s Javascript UI framework), and it’s presented me with some really interesting opportunities to start changing the way I build and style interfaces. My goal here is to explain how somebody like myself — a designer — can get up and running with React quickly, and start building and styling components.

When a project becomes sufficiently large in size you will undoubtedly encounter the need to simplify certain tasks, such as managing external dependencies or configuring environment parameters. Within the MyBuilder code-base we have required these kinds of processes for some time.

Promises are an invaluable abstraction around ‘eventual’ results within asynchronous operations. I recently had the need to be able to retry a Promise-based action in the event of a failure. It turned out to be very easy to implement such a process using simple recursive constructs.

We were recently sent a tweet in-regard to a text-area client/server-side length validation not correlating. After some detective work we were able to find two issues that could have caused this to occur. In this post I wish to discuss our findings, and how we resolved each issue.

In a recent project we felt it beneficial to introduce the Money pattern. There are many good resources on this pattern, so I will delegate to those for further definition. We decided that encapsulating this into a immutable value object allowed for a cleaner API and removed the fear of any unexpected mutation bugs. However, we noticed a spike in memory and processor usage when wishing to perform many successive actions on such values i.e. summation.

In this article we will talk about how to use Xdebug remotely. We will assume that you already know some basic debugging techniques, and also, that you already know how to configure Xdebug. If you missed it, or you just want to refresh your memory, we strongly recommend checking out our previous article about how to configure and use Xdebug locally.

When a web application reaches a sufficiently large size, it can become infeasible to perform all actions required within a single web request/response life-cycle. You may find yourself wishing to for example - batch up and send queued emails at particular intervals, or process payments asynchronous to the point in-time the user made the initial request. In this post I would like to discuss our changing use of background processes (both time-dependent and continuous) due to increasing throughput demands.

At MyBuilder, we do a lot of user research. From guerrilla testing to working with research agencies such a Fluent Interaction, user research is an essential part of how we work. Our in-house usability testing set-up needed some work, though. Our team wasn’t able to view usability testing sessions while they were happening. This how we solved this problem with the tools that were available to us.

An interesting problem arose last week when we wished to generate a listing of recently completed jobs (along with their shortlist fees). Upon review of some earlier attempts, we did not like the aesthetics present when many of a particular shortlist fee were clustered together (i.e. two or more adjacent jobs with the same shortlist fee). What we were instead looking for was to create a constraint-based ordering that when applied to the recently completed jobs, would give an even distribution of shortlist fees (data-set permitting).

We assume that you use PHPStorm on a daily basis, and this guide will help to debug your code locally using the IDE. A remote debugging guide is available, but we strongly recommend going through this one first as it explains the very basics of debugging.