I am noticing a disturbing trend. On every device I use (e.g. iPhone 6 Plus, desktop, tablet) websites seems to be getting slower and slower to interact with. This isn’t true for every website I visit. However, for all of the bigger and more heavily trafficked websites it is definitely true.
Specifically, I have noticed the following:
When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed. Of course, my classes had to be backed by unit tests and this often resulted in a combinatorial explosion. This how I look when I try to imagine all of the possibilities and how to test them.
Let’s assume we are doing TDD (and maybe BDD too) and we don’t want to write software without a failing test.
Back in the day, whether you were writing PHP, Java, or Asp.Net, testing your server side application was easy. You wrote unit tests for your models, controllers, data objects, etc. Then, you ran them every few minutes as you wrote new code and features. Everything was simple and all of your tests existed in the same language and execution environment as the business logic (i.e. the server).
I have worked with a couple of statically typed languages and a few dynamically typed languages. I have noticed that when using statically typed languages I get all kinds of IDE support. That IDE support makes me really productive. It also really helps me to move stuff around without breaking things too badly (i.e. refactoring). Tests also help with ensuring that I didn’t break things. Compile times are usually sub-second due to partial compilation. Auto complete allows me reduce typing down to a two or three keystrokes per identifier (e.g. class name, variable name). Documentation and type info for the method or variable often pops-up automatically. This allows me to stay focused in the IDE.
Haven’t you ever wished you had an easy to use chronograph, set of constants representing the days of the week, or perhaps months of the year? Maybe you have forgotten the exact format to use when writing datetime’s to a MySQL database (i.e. ‘Y-m-d H:i:s’). I know I have.
Normally, cache entries are invalidated using one of two methods:
1. The cache entry is explicitly removed via a call to a
remove() method of some sort.
2. The cache entry is removed due to time-based expiration.
3. The cache entry is removed due to being ejected to make room for newer entries.
PHPUnit is a great testing framework. However, over time I began to find myself wishing it had certain features. So I created KissTest. It is a Keep-It-Simple-Straightforward (KISS), very fast, and absolutely gorgeous xUnit style unit test library.
As you can see in the screenshot, the display of the results is right in the browser. Everyone loves the command line and I am no different. However, there is something to be said for seeing the results laid out beautifully like this. Also, the PHP CLI binary is technically different from the one that is used to serve web pages. Generally, I try to keep the execution environment for the development environment and the production environment as close as possible. In fact, my development environment is identical to the production environment except it is running in VirtualBox. KissTest facilitates this. Sweet!
I am a huge fan of type hinting in PHP. When using great tools like PHPStorm it gets even better because of the amazing auto-complete and refactoring capabilities the IDE provides. Unfortunately, PHP doesn’t provide type hinting for scalar values. The SPL provides a set of classes for scalars, but they are not very popular. So, the package PHP Scalars (https://github.com/joefallon/PhpScalars) was born.
When learning Ruby, one of the interesting language features that I came across was the calling of methods within class definitions. When a class has finished loading, the method calls that exist within the class are executed, one after another. The purpose of these method calls is generally to make modifications to the class and change its functionality, although this isn’t necessarily always the case. One of the most common examples of this feature is the attr_accessor method. The ability to modify a class via code execution is very powerful, although somewhat surprising to the new Ruby developer.
Let’s take a look at how this works.
If you’re like me, then your email Inbox can sometimes get out of control. I have tried several different methods to control my Inbox. For example, I have created sub-folders in my Inbox based on topic or who the email is from.
However, this often fails as a solution because there will be emails that don’t fit into a particular folder, or worse, fit into multiple folders. Another method is using sub-folders that are named based upon a temporal scheme such as month, fiscal quarter, or year. Neither of these solutions works in the long term.