Web Development

It’s been over 20 years since Tim Berners-Lee and Robert Cailliau specified HTML, which became the standard markup language used to build the Internet.

HTML5 was supposed to finally solve our problems and become “one standard to rule them all (browsers)”. This was probably one of the most anticipated technologies since creation of the World Wide Web.

Today we have thousands of digital and printed resources that provide step-by-step instructions about developing all kinds of different web applications. Development environments are “smart” enough to catch and fix many mistakes that early developers battled with regularly. There are even many different development platforms that easily turn simple static HTML pages into highly interactive applications.

All of these development patterns, practices, and platforms share common ground, and they are all prone to similar mistakes caused by the very nature of web applications.

PHP makes it relatively easy to build a web-based system, which is much of the reason for its popularity. But its ease of use notwithstanding, PHP has evolved into quite a sophisticated language, with many nuances and subtleties that can bite developers, leading to hours of hair-pulling debugging. This article highlights ten of the more common mistakes that PHP developers need to beware of.

Web services and their APIs abound. Unfortunately, the vast majority are difficult to use. Reasons range from poor design, to lack of documentation, to volatility, to unresolved bugs, or in some cases, all of the above.

Follow the guidance in this post to help ensure that your web API is clean, well-documented, and easy-to-use. Such APIs are truly rare and are therefore much more likely to be widely adopted and used.

I love and use Django in lots of my personal and client projects, mostly for those involving relational databases and more classical web applications. However, by design, Django is very tightly coupled with its ORM, Template Engine System, and Settings object. Plus, it’s not a new project: it carries a lot of baggage from the past to remain backwards compatible.

In a few of my client projects, we’ve chosen to give up on Django and use a micro framework like Flask, typically when the client wants to do some interesting stuff with the framework. At the same time, we often need user registration, login, and more, all of which is easily handled with Django.

The question emerged: is Django an all-or-nothing deal? Should we drop it completely from the project, or is there a way to combine some it with the flexibility of other frameworks?

As a veteran telecommuter through multiple jobs in my career, I have witnessed and experienced the many joys of being a remote worker. As for the horror stories, I have more than a few I could tell. With a bit of artistic inclination and a talent for mathematics, I also have a fascination with patterns: design patterns, architectural patterns, behavioral patterns, social patterns, weather patterns—all sorts of patterns!

When I first encountered anti-patterns, I discovered a trove of wisdom I wish I had known before I had learned the hard way. Anti-patterns are recognizable repeated patterns that contribute significantly to failure. For example, the manager that keeps interrupting the employee in order to see if the employee is getting any work done is engaging in an anti-pattern that serves to prevent the employee from getting any work done!

Based on my own experiences and experiences of friends and co-workers, I am assembling descriptions of anti-patterns related to telecommuting.

In 2007, Bennett Haselton revealed a minor hack with major implications: querying ranges of numbers on Google would return pages of sensitive information, including Credit Card numbers, Social Security numbers, and more. While Haselton’s hack was addressed and patched, I was able to tweak his original technique to bypass Google’s filter and return the same old dangerous results.

RWD allows a site to adapt for optimal viewing on a variety of devices that range in size based on a media query for mobile and other screen widths. Nowadays, your website will be visited by a wide variety of devices: desktops with large monitors, mid-sized laptops, tablets, smartphones, and more. To achieve an optimal user experience, your site should be adjusting its layout in response to these varied devices (i.e., to their varied screen resolutions and dimensions).

Web Developers often fail to consider the consequences of thousands of users accessing our applications at the same time. Perhaps it’s because we love to rapidly prototype; perhaps it’s because testing such scenarios is simply hard.

Regardless, I’m going to argue that ignoring scalability is not as bad as it sounds—if you use the proper set of tools and follow good development practices. In this case: the Play! framework and the Scala language.