30 Jan 2014
With Mahapps.Metro we've always had the problem that discussing new plans with the core team and the contributors, or questions from the users didn't really work over Github issues. The core team communicated over Skype and we also had an open IRC channel, which was really cumbersome since IRC doesn't preserve the chat history without everyone installing a bot that logs the history on their own server.
Today I discovered Gitter, a fancy new service that allows people to create chatrooms for projects on Github.
They're currently invite only (meaning only people with invites can create chatrooms but people without invites can join them), but after asking I almost immediately got an invite and created the MahApps.Metro chatroom
Gitter has an awesome Github integration, there's a configurable activity log on the right side of the chat where recent issues, pull requests, commits, etc are displayed. The chat also supports auto-linking of issues, code snippets and Markdown support.
After only a few hours, I've got most of our current contributors to switch from IRC to Gitter and what should I say, it's been an awesome experience.
The team of Gitter responds insanely fast to questions on Twitter and you can also drop in on the GitterHQ chatroom and ask them questions directly (they even changed that you don't need to be the owner of an organization, but only require push access in order to create a chatroom for a organization repository after I asked them if it was possible)
The bad parts
I don't have much to write here.
Gitter requires write access to your Github account, this is a limitation of the Github API, they have it described here and here
This isn't too much of a problem for me.
Gitter is an awesome piece of work and I believe it will simplify the collaboration on the projects I'm working on.
The only thing that's currently missing for me is an Android app, but from their website it seems that this is in work.
11 Dec 2012
I'm currently experimenting with ruby and one thing I needed to do, was retrieving the content of an external website.
My first approach to this was using the
The problem: this doesn't follow redirects.
My second approach was a more complicated version that catches a redirect and requests the content again with the redirect url.
Taken from the ruby docs
The problem: If the website redirects to https, it will fail with a 400 HttpBadRequest.
After a bit of research, I stumbled over the httpclient gem.
Well, this looks much better!
07 Dec 2012
Simplicity is everything
To every developer out there: Make it simple for users to report crashes of your application.
I've recently created a simple window that lets users send me the details about crashes that occure in my current project Espera. It only consists of a message that informs the user that the application has crashed, a details box and two buttons: Send and Cancel.
You wouldn't believe how much bug/crash reports I've received in 2 days after I releases the new reporting system. Bugs that I hadn't the time to cover in my unit tests, or that I never would think of. Bugs that were invisible to me, till users experienced them.
As a user and developer at the same time (some people might disagree), I can tell you one thing: Make it easy for users to submit crash- and bug reports. The last thing you want is to fiddle through a dozen of steps so you can submit this one bug to the developer of an application.
FogBugz makes it easy
Since I'm the only developer of Espera, I'm able to use the free Student and Startup edition of FogBugz. 20 lines of code later, I've integrated it within my the application, since FogBugz allows the send bug reports directly through a Http request.
One thing I learned: always send at least the version number of your application with the crash report, so you can easily distinguish new crashes from crashes that appear only because the user hasn't updated the application yet.