When I was in university Pablo de Olavide we used WebCT for the online presence of teachers and students. It was an extremely useful web system. Among the many thing WebCT could do was to manage documents. So teachers will upload notes for the Java class at the start of the course and students will be able to download it, study it and raise questions before the actual class starts. It was a very useful document store. Another very useful feature that we used intensively was the Task system. So a teacher will say 'Solve problems 13-18 and send me the code'. We will solve them and then send back the code, all using the web interface. It was very handy.

There are many other features, but they were all irrelevant since we didn't use them. Nonetheless it wasn't all perfect. It was far from perfect. The idea, the utility of the application was very good, yet the implementation could be much better. It was slow. The UI was ugly. Some times it will just explode and we will be without WebCT a few days until the IT figure it out what went wrong. Also, it was incredible costly for the university to use it, not just because of the important investment in IT infrastructure to serve 20000 users, but the actual cost of licensing the software. To get you an idea, they can't afford to upgrade to new versions of WebCT. And since the world is in recession and particularly in Spain the government is cutting education budget by 20% (for real) it doesn't seem likely that they will be able to update in years.

So that was the situation. When I was at my final year I took a web development course. I learnt a lot of technologies but the one that caught my eye was Ruby on Rails. It was an amazing piece of technology that allowed small teams to deliver working software in a matter of days instead of weeks or months. Real speed. I decided that I wanted to give it a go to creating a Learning Management System(LMS). I deliberately wanted it to be dead simple to use and to install. I didn't want universities to need a whole staff of IT just to support the platform. It must be open source, so that they could modify the source code to meet they particular needs. It needed to be fast so that people could spend their time actually learning and not just using the learning platform. It should be able to store documents and manage tasks.

• Speed
• Open source
• Easy to use
• Easy to deploy
• Document store
• Task Management

My first attempt was a shit. I didn't really knew how to use Rails and I was a beginner in CSS, HTML, knew nothing about JS. I made every possible mistake. I failed to create useful software, but I learned more and more of Rails. I started again. And again. And again. Each time a new project. Each time a new approach, different tools, different UI, different database, different testing approach, etc. It has become sort of my 'Hello World' application whenever I want to test a new cutting edge tech.

This time, the new tech I wanted to give it try was Apotomo, a component oriented framework for Rails. I also happen to be reading Designed For Use, a book on Usability, how to improve user interfaces so that they are intuitive, natural, discoverable, easy to learn and master. So as a was reading the book I was designing the UI of the new DaVinci LMS prototype. I think this time I have actually achieve to produce a fully working application that meets the IT needs to a school. And so I wanted to make it public, so that people can try it and give me feedback on what is right and what is not right. Also, I can use more fellow developers on this project so you welcome to contribute.

Check it out: https://github.com/Nerian/DaVinci-LMS

And there is an online demo: http://davinci-lms-testing.herokuapp.com/en/login

If this interests you, please catch up with me to discuss either via #mendicant on Freenode, or via the mendicant-alumni mailing list if you're a MU community member.

While the title screams link bait, Brixen has authored an excellent article on how we should be more skeptical and scientific in our approach to programming and technology in general.

Highlights include the need for criticism and conflict to advance ideas forward, avoiding logical fallacies such as appealing to authority, and taking an honest look at ourselves and our motivations.

I'm especially interested to see what everyone thinks about his assertion, "Programming is a behavioral science." Perhaps we can discuss this during Thursday's Social Gathering.

Mendicant University often has so much going on that it's hard to slow down and say thanks to the folks who are making a huge difference around here. But because it never hurts to give credit where credit is due, this series of community posts is all about offering periodic hat tips to folks who have been doing excellent work for the school and the broader community.

This time around, my hat goes off to Mendicant University's co-founder, Jordan Byron. While his work has benefited us from day one, he has done more work than I have for this community over the last few months. In addition to launching this community website, he also ran our "Mending Mendicant" month in February. Lots of folks contributed great patches to our various projects, but Jordan was the one who had to review and merge all of them.

In March, Jordan ran our third web development course, and helped the students work on building an early prototype for replacing our existing classroom management software . In addition to the course, Jordan also represented Mendicant University in a short lightning talk at MountainWest RubyConf. As if all of that weren't enough, he also participated in the 5th annual Connecticut Mission of Mercy event, using his technical skills to help real people in pain get the dental treatment they need.

I can't be more proud to have such an amazingly productive and helpful co-founder, and I can say without hesitation that Mendicant University would not exist without him. If you find time to offer him a few words of thanks, please do so!

Please feel free to email me suggestions for who should receive the next hat tip in recognition of their contributions to Mendicant University, the Ruby ecosystem, or the world.

Method shelters are an alternative concept to limit the consequences of monkey patching in ruby to a specific context. Method shelters are an alternative approach to refinements, which was suggested at the end of 2010.

Method shelters were proposed by @flexfrank and you can check out a presentation from the end of 2011, that explains the concept of method shelters and different concepts to solve the same problem. You may also have a look at a prototype implementation at github, based on ruby 1.9.2, and a little readme explaining the concept.

The author gave a presentation at the AOSD conference. Personally I like method shelters better than the proposed refinements, what do you think?

This past week I participated in Connecticut's 5th Mission of Mercy free dental clinic in Danbury, CT. In two days the clinic treated over 2,000 patients and provided over $1.3 million in free dental care to those in need.

Way back in 2009 I wrote a Rails application to handle the logistics of running these massive clinics. This past year several Mendicant community members helped me upgrade the app to Rails 3.1 and add several new features to streamline the check-in process.

I hope these pictures from the clinic help illustrate how a handful of developers from around the world can come together and make a real positive impact on people's lives

I would like to introduce you my new open source project: Jackpot. It started out here during my core skills project as my and now its going through a major overhaul to get ready to hit its primetime.

Jackpot has pretty high ambitions, though. It aims to become the easiest way to get paid using rails. It abstracts all the nasty details and let you focus on writing your appliaction, not billing code. Billing code is a boring thing to write, so i expect you not having to do it all by yourself, at least not all the time.

I hope you may find that interesting and useful. As always, i look forward for any feedback the community may have.

Check for more details at this blog post

Keeping with my promise to release content from my Practicing Ruby journal, I've put together a massive link dump of articles from its second volume. Please enjoy them and share them with your friends.

• Issue 2.1: Ways to load code
• Issue 2.2: How to attack sticky problems
• Issue 2.3: A closure is a double edged sword
• Issue 2.4: Implementing Enumerable & Enumerator in Ruby
• Issue 2.5: Thoughts on regression testing
• Issue 2.6: Learning new things step-by-step
• Issue 2.7: "Unobtrusive Ruby" in Practice
• Issue 2.8: Ruby and the singleton pattern don't get along
• Issue 2.9: Building Unix-style command line applications
• Issue 2.10: From requirements discovery to release
• Issue 2.11: Domain specific API construction
• Issue 2.12: Working with binary file formats
• Issue 2.13: Designing business reporting applications
• Issue 2.14: Thoughts on "Arguments and Results", Part 1
• Issue 2.15: Thoughts on "Arguments and Results", Part 2

Practicing Ruby is a subscriber-supported service, and is literally how I pay my bills. If you like these articles and want to help make sure I can keep writing more of them, please become a subscriber. There is lots of content available to members that has not been publicly released yet, and I'm adding more articles regularly.

PS: Anyone who can't pay the full $8/month fee for ANY reason is welcome to contact gregory.t.brown@gmail.com for a free account.

With some node.js for the chat. In case you were wondering... the code is here.

In this blog post, Dave Fischer describes some really cool looking and ridiculously low tech old hardware from the 1950-1970s.

Dave explains what code is stored on board in his post, but it took me a few minutes to see how the octal codes correspond to the matrix. If you need a hint, here's what the top row of the matrix decodes as:

>> "0100000001010000".reverse.to_i(2).to_s(8)
=> "5002"

Favorite quote from the post: "The ROM is easily user-writable using a soldering iron and pair of wire cutters."

Mendicant University often has so much going on that it's hard to slow down and say thanks to the folks who are making a huge difference around here. However, I'd like to start doing exactly that by offering periodic hat tips to folks who have been doing excellent work for the school and the broader community.

While last month's push to improve Mendicant University's infrastructure saw tons of code contributions from over a dozen of our community members, I want to specifically thank Samnang Chhun for his efforts. It seems that someone forgot to tell Samnang that our focused month of contributing to Mendicant University's projects has ended, because he just keeps on sending in ideas and patches as fast as we can read them.

Thanks a lot Samnang, you're making Mendicant University a better place through your efforts. Keep it up!

Please feel free to email me suggestions for who should receive the next hat tip in recognition of their contributions to Mendicant University, the Ruby ecosystem, or the world.

My new blog post deals with the "Waterfall" process model and how the first paper about it already highlighted its weakness. Unfortunately few people know about this, so let's change that!

You may know the "infamous" Waterfall model, which was supposedly invented back in 1970 in a paper written by Winston Royce and can be seen as some kind of the "arch enemy" of agile methodologies. The problem is just that this paper didn't advocate the Waterfall model! It identified the pattern, highlighting its deficiencies and suggesting improvements. These improvements actually contain some agile thoughts, such as "involve the customer"! Winston Royce has been totally misunderstood...

Unfortunately this fact is little known and even PhD lecturers in the field of Software Development Processes seem to be unaware of this fact, at least some of them that I know. That's why I dedicated a blog post to this topic. In this blog post I walk the reader through the original paper of Winston Royce. I show the deficiencies of the model, which he identified more than 40 years ago, as well as the improvements he suggests.

And the next time someone wants you to do Waterfall-style development, please tell them that Waterfall was just a big misunderstanding from the beginning ;-)

That's right folks, such a feat is indeed possible - no more splitting discussions between the issue and the corresponding pull request. This is command-line-only, though.

Here's what you need:

1. Install Chris Wanstrath's hub gem; I recommend that you alias it go git also.

2. Clone the main repo with a plain old git clone; you might want to use git's new powers and reference a GitHub username and repo for that.

3. Run git fork. This will fork the repo (surprise!) and also add your fork as a remote with your GitHub username as it's name.

4. You can now hack away with your usual workflow (create topic branch and push to it).

5. When you are ready to create a pull request (that is, you want/need someone to look at your code, because pull requests are discussions), run the following command: git pull-request -i ISSUE_NUMBER et voilà! This attaches your code to the issue, even maintaining chronological order between the commits and the comments, and also redirects the issue's url to the pull request. C'est fantastique!

There are a couple other switches you can use with pull-request and a million other things that hub does, definitely check it out. Personally, I love that my git workflow can now be entirely CLI-based.

Steve posted an entry on his blog called Two Pomodoros containing a non-narrated video of him working on the RubyGems project. (For those unfamiliar with the Pomodoro Technique, as I am, two Pomodoros = 50 minutes.)

Why record almost an hour of editing with vim and running tests? Steve explains his own reasoning for doing this in the post. Go read it; it's brief.

Perhaps a better question is, why watch someone editing and running tests? When it comes to open source, I'm a newbie. I suppose I expected to catch a glimpse of hyper-efficient workflow, the super-secret sauce of the Ruby Hero. Which is exactly what Steve tells us not to expect.

What we see instead is someone methodically improving a piece of software, one edit at a time, complete with the occasional fumbling that makes me feel like a blockhead when I do it myself. Only he's doing it in public, where other people can offer criticism, hopefully constructive. Gutsy, and pretty cool.

Today I talked with Gregory Brown in the #mendicant-alumni IRC channel, to see how the charity-driven model that we started for W3Clove was going and think about the next steps in search of financial sustainability.

The Pledgie campaign has raised $240 in one week, and that's great as it allows me to cover the expenses I had in the previous months, and is enough for 2 or 3 months more of hosting.

But, donations are hard to maintain. You've got to be reminding everyone of the need for donations, and this is tiring for everybody. It's a good start, but if you want sustainability, you need a supporter network.

So, the next step is building this supporter network. A supporter will be a user that loves the service provided and is conscious that by making use of it, is making the server spend money. So, to keep the service alive, decides to support it with a monthly subscription.

What does the supporter get in return of this monthly fee, apart from feeling well about supporting a great service? Check out this gist for the ideas we came up with.

In this blog post I reflect on my experiences during the Mendicant University Core Skills course, which I completed earlier this week. I hope that it will give prospective students and interested onlookers a better understanding of what the school is all about. I summarize the goals of the university, what students go through, how the course differed from my traditional educational experiences, and quickly touch on how you can get involved.

I've removed all ads from W3Clove.com and started a pledgie campaign to ask for donations to help me pay the hosting fees.

I've also copyedited the site to tell what it really is, a personal project run by a single developer (instead of all those enterprisey plurals "our spider..."), and included a brief history about how the project was born at the Mendicant University.

With all this, I try to find a way to produce not only software, but also online services that are monetary and ethically sustainable. I prefer removing ads and ask users directly for donations, making them conscious about the costs that every web service has.

I've been stewing over a blog post for several months, unsure of how to accurately portray my journey so far in learning to program in a way that would help others understand how incredibly life-changing this activity can be.

In addition to "learn, learn, learn", my goal for the next few years is to drag more of a spotlight over to programming and do my best to make sure people know 1) why programmers are so freakin' special and 2) that anybody can do this.

It's posted in 3 parts:

Part 1 is just my story, you can skip it if you'd like. It may accidentally contain hidden signposts for others to perhaps follow, but it's just that: my story.

Part 2 is like 15 condensed blog posts I've been meaning to write with a few of the lessons I've picked up in learning to program and just trying to be observant about the culture and attitudes of those I work with.

Part 3 is how new people can get started, and why they probably should.

I've used a big, bloated IDE for most of my development career. I am very productive with it, but I've always resented the fact that I am bound to being productive on a single OS and in a small number of languages.

When I took up Ruby development a year ago, my reliance on an IDE was immediately apparent. I use a Mac at home, and so I started working in Textmate and tried RubyMine, but I was still struggling to feel comfortable or fast in any environment other than the aforementioned IDE.

A few weeks ago when I went back to watch several DestroyAllSoftware screencasts on vim, I was (once again) wowed by Gary's proficiency (and efficiency) in vim.

So, I've committed to learning vim to become more productive without the crutch of an expensive tool and to decouple myself from a specific OS. Here's what I've done so far.