PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation. PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.) PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all. But I’ve got to get this out of my system. So here goes, one last try.

We prefer Pyramid to Django, Flask, and Bottle due to its flexibility, scalability and speed. It gives us more control than Django and is easy to create a small app that can scale later without being rewritten. These are many of the same reasons for Why We Choose Python in general. Recently we provided some training on how Pyramid works that was recorded. It provides a great overview of why Pyramid is ideal and how to setup a basic app with scaffolds, routes, and persistence. We also built a ToDo App for a web shootout we organized in Indianapolis through IndyPy. Putting these together turned out to be a great introduction to Pyramid, so I wrote this post.

This document is an introductory course on Unix system programming, with an emphasis on communications between processes. The main novelty of this work is the use of the OCaml language, a dialect of the ML language, instead of the C language that is customary in systems programming. This gives an unusual perspective on systems programming and on the ML language.

Let's walk through a quick tour of developing apps with Play. Play has idiomatic support for both Java and Scala; this tutorial will start with some Java examples in the first half and move onto Scala for the second half.

CasperJS is an open source navigation scripting & testing utility written in Javascript and based on PhantomJS — the scriptable headless WebKit engine. It eases the process of defining a full navigation scenario and provides useful high-level functions, methods & syntactic sugar for doing common tasks such as: * defining & ordering browsing navigation steps * filling & submitting forms * clicking & following links * capturing screenshots of a page (or part of it) * testing remote DOM * logging events * downloading resources, including binary ones * writing functional test suites, saving results as JUnit XML * scraping Web contents

Flixel is an open source game-making library that is completely free for personal or commercial use. Written entirely in Actionscript 3, and designed to be used with free development tools, Flixel is easy to learn, extend and customize.

Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. The library, largely written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing. In addition, the Julia developer community is contributing a number of external packages through Julia’s built-in package manager at a rapid pace. Julia programs are organized around multiple dispatch; by defining functions and overloading them for different combinations of argument types, which can also be user-defined. For a more in-depth discussion of the rationale and advantages of Julia over other systems, see the following highlights or read the introduction in the online manual.

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

This is the first of a two part introduction to writing testable Javascript UI code. The first article presents a basic sample application containing several common anti-patterns and their solutions.

In the second article, the application will be refactored using the described techniques, a simple XHR mock will be presented, and add a test suite will be added to help future developers maintain the code.

The iteration is a cornerstone of agile development. It provides a heartbeat for the team and its stakeholders, and a structure for various routine activities that help keep development work aligned with what the customer needs. However, the way many teams run their iterations creates serious pitfalls which can keep them from delivering software as effectively as they could.

The orthodox approach to the iteration is to treat it as a timebox for delivering a batch of stories, which is the approach most Scrum teams take with sprints (the Scrum term for an iteration). In recent years many teams have scrapped this approach, either using iterations more as a checkpoint, as many ThoughtWorks teams do, or scrapping them entirely with Kanban and Lean software development.