Tinyweb is an open source project I started last November with the goal of creating a minimal, service-oriented web application framework. I’ve been committing to the project ever since and it has now reached a level of maturity I’m happy with.
Full documentation for the project was completed recently and I figure it’s time to write a how to series of posts that cover the most interesting aspects of the framework.
So here we are with the first instalment. My goal for part 1 is to explain the thinking behind the project and show you how easy it is to file –> new project.
As programmers, the zone is something we are all aware of but something that we rarely explore. Yet we’ve all been there – totally focused and producing the best work we could have hoped for.
To some, the zone is seen as some kind of rare Zen state. Some think it’s a myth that doesn’t actually exist. Either way, it’s understandable that there are so many different opinions; it’s not an easy thing to objectively discuss.
But, what the hell – here’s what I think.
Today I gave a talk about textual sentiment analysis at BarCamp Sheffield. Here’s a summary of the talk and links to the slides, demo and code.
Sentiment analysis is the process of analysing data to determine its sentiment, or mood. It’s an important area of research as it relates to improving things like customer satisfaction and making advertising more effective.
I’m having a perfectly reasonable day, improved slightly by the amount of Tina Turner I had been listening to. I’m working on an application that captures interesting conversations from Twitter, with the intention of seeding it with a great discussion between Uncle Bob and Dan North from last week.
A few months ago I wrote Tinyweb, an ASP.NET web framework which dictates an SRP approach to building web applications. Since then I’ve used Tinyweb for a few internal things and I’ve been happy with the direction it leads you in.
So, we’ve all heard enough times by now the benefits of the SOLID principles. In particular, we know that we should minimise the responsibility of a class, with the aim of having just one responsibility per class and consequently only one reason for that class to change.
That’s an interesting word – change. We often refer to new work on an existing system as change, but unless the new work involves modifying the way something worked before, it shouldn’t be change, it should be extension.
As you know, another SOLID principle tells us that code should be open for extension, but closed for modification. Usually this refers to being able to extend behaviour by subclassing and using polymorphism to effectively replace the old behaviour – but can’t OCP be more generally applied?
What about our architecture, project layout, working conventions? Have these been arranged to support extension or will a change require that we have to rethink these things in order to accommodate future changes?
For a long time, the Microsoft technology stack was pretty much glued to Windows. If you wanted to use Microsoft technology, you’d pretty much need to use compilers, runtimes and servers that existed only for Windows. Back then, the closest thing we had to cross-platform were things like WINE which simply tried to emulate the entire runtime environment.
Times have certainly changed, particularly when it comes to web development. Thanks to awesome projects like Mono, it’s no longer the case that working with C# / ASP.NET binds you to Microsoft development tools and forces you to use Windows for development and hosting.
Mono brings a C# compiler and CLI implementation (in addition to other things) to operating systems such as Linux and Mac OS X, making technologies like C# and ASP.NET much more feasible and available.