Blog ASP.NET

Avatar

When best practises collide

Best practises are methods and techniques for achieving a certain goal. By their very nature they set the standard for us to follow, and form a mechanism by which developers can be judged.

ASP.NET is my platform of choice when developing applications, but it gets a bum rap from developers on both sides of the open source debate, for its creators’ inherently arrogant approach to Web standards.

While working on a new project I thought I’d have to bite my tongue when I saw some of the .NET markup that was being used, but after a while it dawned on me that what was being written wasn’t incorrect, it was simply following Microsoft’s best practises rather than, for example the W3C.

Under ASP.NET, the tools that allow developers to change the styling for Webpage elements (font faces, sizes, colours, etc) are very close to hand. When adding a text box control to a form, the user can specify its border style, font size and colour aswell as the usual stuff like maximum length and validation functionality. Now as part of the XHTML and CSS methodology, which encourages the separation of content and styling, this type of customisation is abhorrent: it’s simply not the done thing. However, when developing the .NET Framework (and specifically ASP.NET), Microsoft were simply following a pattern.

Some people actually don’t realise, but the .NET Framework in and of itself has nothing to do with Web development: it is simply a software framework. Programmers can build desktop and console applications, libraries and games with it. Now in desktop application development it is very common for developers to be given the option to change how a form looks by hard-coding the window styles directly into the application. There is no CSS technology for desktop applications, and so programmers pick colours from a specific palette (which include system colours) and fonts from a dropdown list, to suit their needs.

Not only can you build both desktop and Web applications with the .NET Framework, you can also use the same software (Visual Studio) to build both types of application, so developers could make the transition from building Windows Forms apps to producing Websites. Microsoft even took care to give the Web versions of their controls (like textboxes and labels) the same or similar name as their Windows Forms counterparts, with the same abilities to change styling that programmers had grown used to.

So I think it’s unfair to rail at Microsoft for not embracing W3C, when this isn’t actually the case. As a standards-conscious developer I’m not forced to use the hard-coded styling method that I would use with Windows apps: I can apply CSS classes to my controls just like I could in HTML.

So hard-coding your “look and feel” doesn’t make you a bad Web developer: just one that’s following one set of practises. Problems only arise when developers pick and choose elements from different methodologies to create their own which makes picking up someone else’s project that bit more difficult.

This realisation has made me a more forgiving programmer: now I just have to learn to resist the urge to force my ideals onto others.

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!

TweetPaste - A webapp in 12 hours

On Thursday I thought of a problem. I like the microblogging site Twitter, and sometimes I like to mention what my friends are talking about.

However, there is a problem. In order to preserve the status update (or “tweet”) as it’s known, you have to either copy and paste it - and get rid of all the nasty code that goes with it - or worse, take a screenshot of the tweet, save it, upload it and paste it onto your post.

Solution: After spending a couple of seconds on Google - that’sreally all you need - I discovered that there wasn’t anything out there that would do the job, so I thought I’d have a pop, and thus TwitterPaste was born.

It’s a ridiculously simple app: all you do is copy and paste the link to the tweet you want to embed (which you can get fairly easily), hit the big button and copy the code you get itno your blog.

Another problem: it doesn’t work on WordPress. Although this site is built on my new Byron CMS, any collaborative blogging projects I am involved in tend to be run on WordPress because it’s something bloggers are very familiar with...and it’s really good. The problem is however that, unless you’re editing in code view (which shows you all the “raw” HTML as apposed to the formatted text) all the code that TweetPaste generates gets stripped out.

Solution: The TweetPaste WordPress plugin. This simple one-file plugin generates the code needed to embed a tweet onto a page. And because it uses IFrames it deprocates so RSS readers should be able to display a link to the tweet, if they can’t display the IFrame.

And in other news, this is my first ever WordPress plugin! WOOT!

So now I can embed tweets into my blogs, and allow others to do the same. And all in less than 12 hours.

Oh, and to prove that it works, here’s me tweeting the fact:

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!

Say hello to Byron

A few conversations, be they online or offline have lead me to think about whether I should be demonstrating my .NET skills through my own CMS. My priorities have shifted since I setup this site on WordPress, and now I think demonstration is more important than procrastinating.

My mate Kevin is already using version 2.0 of Bluemilkshake.ContentManagement on his site DigiKev, but it doesn’t give him everything a blogger needs. Yes he gets the basics: he can add new posts, add links, images, metadata and so on. But it doesn’t ping any servers when he updates his blog, and it doesn’t notify any posts to which he has linked.

Plus the system is not necessarily the most efficient. It was built on a module basis (a little like WordPress widgets, except those widgets don’t have to be stuck in a sidebar: they actually form the makeup of each post), so each block of text is one module, and an accompanying image is another.

It’s because of the issue above that I thought, rather than upgrade an existing system I should think about it from a new perspective, taking the things I love - and removing the things I hate - about WordPress. I should point out though that I’m not out to produce WordPress for ASP.NET, and I’m not creating a blogging platform. I want to create a content management system that implements a really solid blogging system.

So Byron is born. It’s an ASP.NET 2.0 application using a MySQL database. Why MySQL? Because Microsoft SQL Server is just too damned expensive. Why ASP.NET? It’s too long to go into, but it’s by far the more powerful language, at very little extra cost when looking at shared hosting. I’ll be writing it to support any form of database (or even a set of XML files), but this might not come till later in the development process.

I thought it’d be a great idea to blog the development process of this new project through from its conception to its first deployment and provide code snippets where they have value. If you’re not a programmer this will hopefully give you an idea of how a CMS is built, and if you’re a PHP developer this should show you that ASP.NET developers are real-world programmers.

I should point out that in an earlier post I extolled the virtues of systems like WordPress because of their “pick-up-and-go” style. That still stands. You can setup a new WordPress site in about five minutes from a standing start and that’s no mean feat, so I have nothing but respect for that system. It works too; really really well and the development community behind it is immense. I just think it’s important to put my skills on show on my own site.

Wish me luck!