How we built Coderoulette, a collaborative learning experiment
First of all, if you want to know what Coderoulette.com is, check this post or…
Note: Coderoulette was created as an experiment on collaborative learning, and the technologies we used and the decisions we made were not based on scalability or performance for long-term.
What did we use to build Coderoulette?
Coderoulette was built with Meteor. Meteor is easy for prototyping as it gives a quick way to build ideas that probably will be going to the trash afterwards. If you don’t know Meteor, it gives you a framework based only in Javascript for both the frontend and the backend (Node.js and Socket.io on the inside).
We worked with Less for CSS and jQuery.
We also used WebRTC with the SimpleWebRTC plugin + Signalmaster server to handle STUN and TURN connections.
For the real-time pair programming IDE we used the mizzao version of ShareJS for meteor that includes the Ace editor.
Mongo for the DB.
And Heroku for the all the servers.
For source code validations we work with Sphere Engine.
If you haven’t play with Coderoulette.com yet, check it out now, so you know what I am talking about :)
My opinion about Meteor now
After working with Meteor, which I learned during this project, I have mixed feelings.
I would not recommend it for big projects, as it’s limited in a few aspects, and it has its own tricky things. Also, the everything-has-to-be-async thing is very annoying sometimes.
In the other hand, it has been great to be fast (the first experiment took 2 weeks to build, the second experiment took 2 months). However, being able to use only Javascript for everything is awesome!
Then, why we decided to use Meteor?
When Ariel and I talked about this project, he had already created a very simple IDE based in Meteor and ShareJS.
I had then the opportunity to start building it with another language (which I did during 3 days on Ruby on Rails), but the truth is that I thought learning something new and having the base of the experiment done already sounded more fun and easy that the “good” long-term solution.
Which challenges did we find while building Coderoulette?
As this was just an experiment, we tried to maintain the costs as low as possible, so sometimes that gave us some headaches in a few areas of work.
For example, WebRTC with STUN and TURN connections. They are a pain. We thought about integrating some external solution but in the end I wanted to do it by myself, and probably it was the thing I spent more time fixing, sometimes without even knowing what was going on.
Working with Sphere Engine was incredibly useful. It saved us a lot of time. However, it was challenging sometimes. The documentation wasn’t perfect, and they changed things without notice. For example, they have response codes, and once they changed the “accepted” code from 14 to 15 without telling anyone. So, sometimes, using external tools also requires time and patience :D
Why Heroku?
I am just a fan girl of Heroku. Being able to deploy with just a single line in the terminal and without being worried about literally anything else is the best thing server-side haters like me can wish for.
Why didn’t we think about the long-term?
Being honest, it’s not completely true that we didn’t think long term. We thought about it (more Ariel than me), but it wasn’t our main focus. Coderoulette was just an experiment, something we wanted to test. Why should we spent twice as much time doing something that will be discarded?
It’s very common to hear talks or read posts about how to properly build an app/web/startup thinking in all possible cases that might happen if you grow a lot even if you are doing an MVP (I was like that not that long ago) but the thing is that it requires a lot of time and effort and sometimes those are things you can’t spare.
I would love to hear more about other people building small ideas fast and forgetting about impressive, great, ninja-quality code and technologies that will never be perfect, not matter how hard you try :)
If you are curious about Coderoulette, check it out now.
