Blog programming

Avatar

Byron source code on Subversion

The source code for Byron, the heavily under-development content management framework for ASP.NET is now available through my Subversion repository.

Subversion is a system that allows developers to work collaboratively on applications, because it puts all of the source code in one place. You can also let guest users download the code, and it makes versioning easier and ultimately gives multiple developers more control over their projects.

As I’m the only developer I’m mainly using Subversion as a way of allowing others to see my work. Other sites exist for .NET developers (like CodePlex, Microsoft’s answer to SourceForge) but they often lack the automatic element that allows you to push your changes back to the server quickly. (I use Microsoft Visual Studio 2008 with a plugin called AnkhSVN that provides a fully integrated interface to Subversion.)

Byron is now being used for the Rhubarb Radio Website to power both the text content and the schedule, and in time (once I’ve made a few more tweaks and started writing the documentation and improving the code commenting [ie: adding some]) the framework will have its own site.

Anyway, should you fancy taking a look, you can find the source code for the libraries that are included in a Byron Website at svn.bluemilkshake.co.uk/byron/. Once the system gets its first major version number a test site will be included in the repository, so you can see how a site uses these libraries.

Programmers vs developers

While chatting with Josh Hart - he of Live Brum fame - we both hit upon the idea of programmers being different from developers. This has been discussed elsewhere, but I felt it worthwhile to look at this angle, two years on from the original article that prompted the post in that link.

WARNING: Grotesque instance of management speak following in later paragraphs.

It’s easy to think about the difference between developers and programmers as one that is based on knowledge: a programmer has a deep knowledge of the languages and frameworks he uses, and a developer has a broader but consequently less holistic understanding of them but has the ability to plan, talk to clients and manage a project. There are elements of truth in that statement, but it’s not wholly accurate.

I for example have a foot in both camps. I learned VB by sitting in my room, playing with my custom-built Windows 98 PC and not kissing girls. I got a job fixing computers then went on to develop desktop applications for large companies. I now develop Websites for a living, and I code for the fun of it: the results of which are currently TweetPaste.

But I also blog, work with and build WordPress plugins, collaborate on different projects like The Big Picture and Rhubarb Radio, all of which have come from an active social life. I work on open source and “closed” systems alike because I’ve got the end in mind, not the means. I can do the handshaking, business-card swapping, coffee meeting thing, and I really enjoy it when it’s with people who are there to revel in the exchange of ideas.

Josh told me he doesn’t consider himself a developer, but when presented with the code for Live Brum which he’d written almost entirely single-handed - and was able to thoroughly explain - I balked at that claim. He corrected me however, saying that he was a developer, not a programmer (not to be difficult: simply to draw a distinction).

It may come down to a difference in brain types: some people are logical, others are creative. You can have elements of both of course, but I think one will always outweigh the other.

I’ve had similar conversations with my friends David North who runs Digital Rant and Kevin “DigiKev” Rapley, a programmer and designer respectively; both people with an appreciative eye of the other’s discipline, but a firm understanding of their own strengths. Currently they’re both either engaging in or undertaking projects that will see them finding a middle ground, but having approached it from opposite directions, so perhaps these titles are defined, but not set in stone.

Given the right framework a developer can build very powerful Websites, but can you then take that knowledge and learn a new language from scratch, thus becoming a “real” programmer? Similarly can a “hard-core” programmer take the helicopter view and acquire time management and client-facing skills? Yes, probably, but what’s more important is the question of whether either wants to.

Some are very happy being given a problem and figuring out how to solve it, whilst others like to be given an idea and told to run with it or wait for inspiration to strike. There are opportunities for both, unfortunately there are also frameworks for both. ASP.NET is seen as the programmer’s language whereas Ruby on Rails is for creative types. This is partly because creative people embrace the ideals that open source licensing embodies, but also because of the reputation of the likes of Microsoft, as a stuffy, almost archaic organisation.

Or is it just about mindsets? MySpace is (now) built in ASP.NET, and Facebook which is programmed in PHP is under constant criticism for creating a walled garden (a closed space, far from the ideals of the open source ethos).

So therefore the technology - and even the ideals behind them - are not what makes a programmer or developer what they are: it’s what they do with those technologies that makes a difference.

There’s a whole bunch more I could say on the subject but I think I’ve gone on long enough, so if you fancy telling me which camp you think you belong in - or whether there’s room for a third...or more - please comment away!

Byron’s first stumbling block

On Thursday I started work on my new content management system for ASP.NET, called Byron. I wanted to make it both flexible and efficient and in doing so I’ve had my first setback, and it’s all to do with data.

ASP.NET has a great model for creating flexible applications that can be configured very easily and without having to write too much unnecessary code. The Provider module means that you can put all the logic for a set of functionality in one place, and worry about the nuts and bolts later.

For example, I started off with a DataProvider system. I created a base class with a load of functions for accessing information about users and their roles, so that I could build a login system for the admin area later down the road. I then built a MySqlDataProvider which inherited from the DataProvider class and which would actually handle the instructions that the DataProvider was being given.

So basically the user system says “reset this user’s password” and the DataProvider says ”OK. Oi, MySQL? Check this user’s password would you?” MySQL comes along, resets the user’s password and tells the user system it has done so. (A very simplistic description, but hopefully it makes sense.) That all works great because the MySqlDataProvider knows what data to access, in what table and what to do with it. Now comes the tricky part.

I want the system to be a framework or platform, more than a CMS. I want Byron to form the basis of all .NET sites I develop in the future, so that means the system needs to be flexible enough to deal with any type of content, be it a page, a blog post, a contact form or a news article. Because there are subtle differences between examples 1, 2 and 4, a catch-all system wouldn’t work, so total flexibility was what was needed.

So I built a ContentProvider and setup a whole load of stuff in the site’s configuration file so that new types of content could be created, understood and rendered. It all went swimmingly until I came to the point at which I’d have to access data for each page, post or article.

And that’s where the stumbling block came and whacked me square in the noggin. How do you access data from a database without knowing

  1. what the content will be used for, and crucially
  2. what form that data is held in?

It could conceivably be XML, a MySQL or MS SQL database or even - heaven forfend - a bunch of text files. If I wanted the system to be totally flexible it would have to cope with all of these, and more. And that’s actually OK as long as you know what data you need, but because the content system was dynamic too, I didn’t.

I knew that if I really knuckled down I could create a really fancy generic query system where the complexity of each query could be communicated and passed from the ContentProvider to the DataProvider and back again. But this would end up slowing the system down, and I’d have a foot-long white beard by the time I’d finished. So I had to make a compromise, and from now on, Byron will only support a MySQL database.

I wanted to allow the support of any database that can interpret SQL (a “programming” language for databases), but there are limitations which I won’t go into, so it’s MySQL or no SQL. Hey, if it’s good enough for WordPress it’s good enough for me!