Many people use Disqus as a commenting system for their (static) blog. It's a free service, easy to get started with, and it has everything you'd expect from a commenting system. It's free up to the point where Disqus decides to show advertisements alongside the comments, and these advertisements are so bad, you will look for better options very quickly. The way out of advertisements, of course, is to start paying for their services. Actually, I would have paid already for their service, if only they would have reduced the tremendous amount of stuff they load on your page. And the cookies they need for tracking you across the internet of course.

So, even though I did start paying for Disqus to at least get rid of the horrible ads, I added a little card on my Trello board saying: "Replace Disqus". This turned out to be a nice side project, and after spending many hours on it, it's now ready for production. In fact, there has been a silent launch, but nobody has been using it so far. Let's see if that changes after today.

The commenting system that now finally replaces Disqus is called MailComments. I'm planning to make the software more widely available in a couple of months, but I first need some feedback from running it in production before releasing it in any way.

Triggered by Marco Pivetta who apparently said during his talk at Symfony Live Berlin: "If you still don't have tests, this is unprofessional", I thought I'd tweet about that too: "It's good for someone to point this out from time to time".

I don't like it when a blog post is about tweets, just as I don't like it when a news organization quotes tweets; as if they are some important source of wisdom. But since this kind of tweet tends to invoke many reactions (and often emotionally charged ones too), I thought it would be smart to get the discussion off Twitter and write something more nuanced instead.

First of all, many developers experience testing as slowing them down. They see the solution, so they can just write the code and be done with it. Just like any other case of technical debt, failing to write tests means you're cutting corners; it will feel like you're going fast, but you'll certainly go slower over time. In the end, untested code becomes very hard to deal with. If you or someone else looks at it a year later it will be hard to understand what its purpose was, and it will be difficult to change anything about it without breaking it. On top of that, having no tests prevents the design of the original developer to evolve according to new discoveries and insights of later developers.

In part 1 of this series we discussed the size and complexity metrics calculated by phploc. We continue with a discussion about dependencies and structure.