Technical

One of my projects in the past few weeks has been to put together a SOAP server for a client. So suddenly I've had to learn a lot of the nitty gritty details about what works and what doesn't...

While they're fresh, let me jot them down here. WARNING: Extremely technical content ahead.

At Freelock, we're always trying to figure out ways to do things better. Recently I started digging into a developer tool that's making, as Bryan over at the Linux Action Show would say, my head explode.

For a long time, we've managed our custom code projects and business documents in a central repository, called Subversion (also known as svn). Subversion is relatively easy to understand--it's like having a library of files you can check a copy out of, do some work on it, and then check it back in. Subversion is the librarian that tracks who has copies of what, and when they checked it out. So if Erik checks in changes to a brochure, and then Jill goes to submit changes to the same document, Subversion will say "hey wait a minute, that document has already been changed--you need to make sure you put Erik's changes in your document before I'll let you put in your document."

This is great for managing conflicts between people working on a single team, or for code that is being developed in relative isolation from the rest of the world.

The problem is, we're doing more than that--we're taking code from various open source projects and either customizing it or building new applications on top of it. And so when the outside projects get updated, we need to manually update anything we've written that depends on that code. There is no longer a single repository where we control our code--there is our code library, plus another one for every project we use.

This makes managing add-ons for projects like Joomla or ZenCart quite challenging, because our add-ons get scattered throughout the filesystem to be able to hook into the right place. And if we have to touch a core file, we're going to end up needing to re-implement our change with any update to that core file.

There are other issues we run into, managing our code and hosting, all of which take fairly time-consuming, manual intervention. Here's the list:

• Since we host and provide security updates for Joomla, Word Press, Zen Cart, Drupal, and others, we need to upgrade dozens of installations any time there's a new release that has a fix for a security vulnerability. With Joomla this has happened quite a lot, and every Joomla installation needs to be upgraded individually--and tested. And since each installation is slightly different, we can't manage them easily within a single repository, while updating the underlying code.
• Templates, modules, components, blocks, themes, plugins, and whatever. Developing these types of add-ons are our bread-and-butter. But code for these often get scattered across an installation, making it quite difficult to manage just our add-ons while we develop them, or roll back to earlier versions if there's a problem.
• The Dojo Toolkit, and builds. We're doing a lot of development with Dojo right now, to add desktop-like functionality such as trees, sortable tables, right-click menus, animations, and lots of other really cool things. However, if you don't "build" the code after you write it, it's painfully slow in a web browser. And due to the nature of how Subversion works, you can't easily store a built Dojo tree if you ever want to change it again. Which means you'd need to build it every place you deploy it. And on some computers, it can take a long time to build--on our demo server, one of our projects currently takes 8 minutes.
• As we get more directly involved with open source projects like LedgerSMB, we're finding the need to change core files while we hack away at some particular feature. To do this, you create a branch of the code, work on your feature, and then merge your changes back into the "trunk." If you don't have access to save directly to the project repository, doing this gets a lot more complicated.

Git to the rescue. Git solves all of these issues. Read on for a technical discussion of how.

Packtpub is running a sample from a developer's guide for customizing SugarCRM. The author describes how to set up hooks for particular modules to build a custom workflow.

Custom workflows are a feature that is limited to the proprietary version of SugarCRM--they have not been available in the open source version. With custom development using techniques illustrated here, you can add your own workflows.

This looks to me like it's written specifically for versions of SugarCRM before version 5.

I've been struggling to get Project Auriga to set HTTP Auth from a nice pretty login form, and think I have it working.

What follows is a very technical discussion--if you're a business reader, you should probably skip this post...

HTTP Auth is a specific mechanism for handling authentication. HTTP Auth is built into Apache and IIS, and so the server can handle authentication purely through configuration, offering many different back ends for storing the data.

PHP development is one of our specialties at Freelock Computing. I've written quite a few PHP applications, some from scratch, some starting with other people's code, some as extensions for open source projects. I've also read a lot of criticism of PHP, and while some of it comes from knowledgeable programmers expert at PHP, most of it is uninformed hogwash. So in this post, I'm going to dispel many of the myths about PHP code, and identify its real strengths and weaknesses.

There are thousands of languages out there, but only a couple handfuls are used for web applications. Of these, PHP is a runaway success. Yet I constantly see it criticized by developers of other languages, often for completely untrue reasons. PHP has a bad rap, and while it certainly has its pitfalls, there's many good reasons it has become such a popular language for web applications.

I consider there to be three major sets of languages currently used for web development.

Ok. Last post on the quality code series. One of the downsides of getting older is realizing you do have shortcomings. You know how when you're young, going into a job interview, the toughest question is the one about your weaknesses? We're all quite blind to our weaknesses, until experience comes up and forces you to realize you're not perfect. Sometimes this happens early, sometimes late, but it happens to everyone sometime.

My coding weakness, it turns out, is reliability. I'm terrible at handling errors, building test frameworks, doing unit testing.

Before code can be customizable, it must be clear. But clarity is not enough, if you're going to be using a codebase in multiple places.

Many open source projects excel at customization. People have enough different uses for an application that very few work perfectly out of the box for everybody. Most companies want to apply their branding to the software we use. Some people need an application localized and translated for their audience.

Programming is an exercise in understanding a problem. To program effectively, you need to fully understand, in intricate detail, the problem your program is solving. Sometimes as a programmer you don't fully understand the problem until you've wrestled with it a few times in code.

Most experienced programmers will tell you that when creating a large program, you almost always have to scrap your work at least once. At some point, you find that you've programmed your way into a dead end, that you just can't quite get where you're trying to go without doing it again.

Programming borrows a lot from the construction industry. Many programming terms derive from construction: hacking, builds, development, architecture, scaffolding, frameworks, and dozens of others. But in some ways, programming has an element of power beyond construction.

Take, for example, a building. When you build a building, you start by pouring a foundation. On top of that, you construct a skeleton, add walls, a roof, sheetrock, siding, and all the plumbing and electrical.