UPDATE: Text below has been updated slightly to reflect the current plan as of November 2011. Small changes have been made, but the spirit of the original idea has been preserved.

Throughout the first year of working on Mendicant University, we grew faster than anyone could have expected us to. We managed to make it a whole year without a formal plan, growing and changing organically as we worked on finding our way. But with the growth came the growing pains, and a couple months ago we began to worry that if we continued at the pace we were going without at least some minimal planning, we'd burn out.

It took us several weeks to regain our bearings, but now that we have, I'm happy to announce the plans we have for next year. What follows is just a summary, but it should give you a glimpse into where we plan to take things.

• We are changing our community service exercise in the core skills course so that it is now mandatory, but more open ended. Students will be able to select from a list of open source projects and community mentors and then are expected to make a small contribution to the project they choose. This will give the students an opportunity to contribute to an existing open source project in a supportive learning environment. This new requirement will effectively double the publicly visible impact of our sessions, as students will still also be releasing their own individual projects as open source.

• We are reducing the number of core skills courses from six per year down to three. The next three sessions will be held in September 2011, January 2012, and May 2012. We may or may  not reduce the class size from 15 down to 12, but September will run with 15 seats open. There are many reasons why we need to reduce the number of core skills sessions, but the main one is that it is the most labor intensive course we have to run. In addition to being a huge commitment for the students, it takes the effort of two instructors, three alumni mentors, and a visiting teacher to bring folks through this session. We want to make sure that we focus on quality rather than quantity, and reducing the number of core courses is one way to do that.

• We plan to greatly expand and extend our mentoring program. Eric Gjertsen and Shane Emmons are still working on a plan for exactly how we will go about growing the program, but our goal is to be reaching a much broader audience of folks who could use a code review or some guidance about what they should be studying and practicing. This will hopefully counterbalance the reduction in core skills courses, as many folks will still be able to engage with Mendicant University even if they're not formally taking courses here.

• We are increasing the number of courses taught to our alumni. We plan to run web development sessions, software design sessions, and several pilot sessions as well. Pilots may include technical writing, statistics for programmers, and possibly a session on Ruby in the industry.

• We will be doing an increasing amount of projects with our alumni, some public facing, some meant to help shore up Mendicant University's infrastructure. However, it's very likely that within the next year you'll see our students and staff working on projects of high importance to the community, on an as-needed basis. (EDIT: As an example, we've done a Ruby documentation drive and a social good hackfest in October 2011)
  

These changes will hopefully lead to a more sustainable, stronger program. It isn't quite as ambitious as what we shot for in the first year, but it's solid and I think we'll be able to make it all happen. Our goal was to come up with a plan for our second year that would make sure we'd still be here in our third year, and I think this will do that. Have a question about where we're headed? Just ask in the comments section below.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis. Monthly contributions from community members help make that possible. If you like what I'm doing and want to support it, please find the PayPal subscribe button at the bottom of this post. Currently I have 73 subscribers for a total of $760/mo before PayPal fees. This is not yet nearly enough to live off of, but does help offset my expenses.

PuzzleNode

With the help of Andrea Singh (@madebydna), and several testers from the Mendicant University alumni network, I launched four new PuzzleNode problems. Our goal was to create problems that encourage the use of object oriented programming, but they're still very much language and paradigm agnostic. I think we may have accomplished that goal with all but Puzzle #12, which we allowed to be a wildcard.

Mendicant University

Our July session is under way, and eight of our twelve students made it through the first checkpoint. The assignments we are running in this session are very challenging, but I'm happy to see the students rising to meet that challenge. It's been a lot of hard work, but it's also been fun.

We will open up admissions for our September session on Monday, July 18th. Those who wish to get a head start should focus on solving at least two problems from PuzzleNode #9-#12.

Thanks to alumnus Andrew Cox (@coxandrew), Mendicant University will soon have a brand new public website. Jordan (@Jordan_Byron) and I will be making some final revisions to the design Andrew created and populating the new site with content over the next week or so. We expect that if all goes well, the new site will launch within the next 7 days.

Practicing Ruby, Volume 2

I am starting to reach the point where I need to have more revenue coming in to make sure my bills get paid, but I'd rather not go back to consulting work just yet. The mendicant supporter money has helped extend my runway, but I need to augment it somehow. I've decided that it's worth a try to restart my Practicing Ruby newsletter, which was highly successful the last time I ran it. When I asked whether people would resubscribe if I started it back up, the response was overwhelmingly positive, with 25 "Hell Yeah" type comments within the first few hours, and close to 100 trickling in over the next several days.

I expect that the newsletter will officially relaunch some time in August, but for now I am working on building up a backlog of content. I've decided to release my early drafts of the articles to the Mendicant Supporter network, both as a way of saying thanks for supporting me, and also because I could use some feedback. I sent the first one of those out last night: an article that explains the differences between load(), autoload(), require(), and require_relative().

I also plan to complete the conversion of the articles from volume 1 and release them for free on the Practicing Ruby blog. The first thirteen issues are already up there, if you haven't seen them already. There are thirteen more that have not yet been released, so prepare yourself for a massive dump of free Ruby content over the next few weeks!

Software Development for Beginners (Training in New Haven, CT)

Jordan and I ran our intro session for our "Software Development for Beginners" course on July 6th. The event was a huge success, we ended up overbooking our space even though we announced the event only a week before it started. If you're interested in how it went, you can check out the course notes and code examples. Additionally, one of our students wrote a review of the session.

We will be charging for these events in the future, but we plan to aim for something akin to a dance class or yoga lesson, at $20/session. Our goal is to reach a wide cross-section of the community, and not just those who are already writing code professionally.

RubyGems Work

No new tickets have been entered for RubyGems guides, but #3 and #4 remain open if folks want to do a little bit of easy work. Right now my work on RubyGems is on the back burner because there are no urgent issues I'm aware of and I've got lots of other things to work on. What I have been doing is watching the RubyGems keyword on Twitter and watching what problems people are having. I help them where I can, but I am also making mental notes for when I do eventually get around to writing guides myself. Please let me know if you're still experiencing major problems or frustrations with RubyGems, I'll make sure that they get looked into.

Want to help RubyGems in a more substantial way? Nick Quaranto (@qrush) is looking for some folks to help maintain GemCutter. I'm too busy to do this myself, but I'd totally recommend helping Nick out, he's a great guy and GemCutter is obviously an important project.

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis. Monthly contributions from community members help make that possible. If you like what I'm doing and want to support it, please find the PayPal subscribe button at the bottom of this post. Currently I have 69 subscribers for a total of $696/mo before PayPal fees. This is not yet nearly enough to live off of, but does help offset my expenses.

RubyGems Work

A couple weeks ago I volunteered to help shore up the RubyGems documentation effort, working on the RubyGems guides in particular. However, it's been slow going because I'm so busy with many other things. I still plan to work on this eventually, hopefully finding time for writing some guides in August. Between now and then I will still review and commit their patches as they come in. The guides site is a simple jekyll static site hosted on github, so it is very easy to contribute to.

Want to help but not sure where to start? Tickets #3 and #4 only need a bit of work before I can merge something, so that's probably as good a place as any to dip your toe in. 

MiniTest Helpers

With the exception of mocking frameworks, I typically don't go beyond Ruby's standard library to meet my testing needs. That means that over time I've been building up a test helper file that is gradually growing with things I find to be generally useful. As a fan of citrusbyte/contest on Test::Unit, this does something similar for MiniTest while adding a couple other features as well. To some extent it is a duplication of MiniTest::Spec, but doesn't load in the assertion syntax and has some other important difference I can't remember.

I am thinking of possibly releasing this test helper file as a gem, but not in the traditional sense. Instead, the gem would set up something like a minitest-helper script that could be used to generate a helper file locally rather than requiring these helpers directly from a library. This is the workflow I'd prefer, so that this helper just starts as a base and then gets built up as your project goes on. It will also make it so that you never need to worry about versions since you don't actually depend on my gem. If that idea interests you, please let me know and I'll get a gem out.

PuzzleNode

My main focus for the last several days has been on preparing the next batch of PuzzleNode problems. Rather than sourcing puzzles from our entire student body at Mendicant University, we're taking a more curated approach this time. I came up with the basic idea behind all four problems, and one of our instructors-in-training, Andrea Singh (@madebydna), has been helping me flesh them out. We've tried to create problems that encourage the use of object oriented programming, but they're still very much language and paradigm agnostic.

The puzzles will be released to the public on July 15th for the next Mendicant University entrance exam. My paid supporters as well as the Mendicant alumni network will get access to them some time this week to help test them and shake out any problems before they go live.

Mendicant University

We have reviewed and accepted proposals for twelve student projects to be worked on during our July core skills session. We've got some folks building games, some building developer tools, and some others even building educational programs. It's the usual mix of awesome ideas, so be sure to check out the results at the end of July and see what comes out of this session.

Andrea and I have our curriculum fleshed out for the course, we just need to prepare some writeups. We don't publicly discuss exercises in detail until the sessions are completed, but we are thinking of doing something with FFI for our integration problem, something to do with Train games for the challenge problem, and possibly a parsing problem for the academic problem. The community service project will as usual, feature a range of things that can be done to help out the school, including work on university-web, puzzlenode, and other things.

Software Development for Beginners (Training in New Haven, CT)

Jordan (@Jordan_Byron) and I launched the registration page for our "Software Development for Beginners" course intro session last week, and we'll be running the session with over 10 people tomorrow (6/6) at the SeeClickFix offices downtown New Haven. This should be exciting because it'll be the first time that I try to teach a group of raw beginners about how to write code. Andrea helped us a lot with forming some ideas for cool demonstrations we can do, so I'll be sure to report back next week with how the first session went.

Supporters Network

The Mendicant supporters network is shaping up to be interesting and useful, even if we haven't quite figured out what to do with it yet. Since the last progress report, we've traded a few emails on the mailing list doing a quick code review for one of the supporters. I also want to use it for bouncing ideas off a smaller group of folks who are supportive of my work before making public commitments. Over time, I think that this network will become something of value in of itself for those that have been making monthly contributions to me, but for now most folks there have reassured me that these semi-regular updates on my blog is enough to keep them happy. That means they're really nice people :)

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 70 subscribers backing me for a total of $728/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1300-$1800/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.

RubyGems Work  (Week 5)

I have been holding off on doing too much new work on RubyGems documentation because I needed to meet with Nick Quaranto (@qrush) to make sure that my plans matched with his original vision for the RubyGems guides. If you check the commit log for the guides, you'll see I pulled in a couple small fixes, but otherwise haven't made much progress on new guides. That said, I finally caught up with Nick over IRC on Wednesday, and we're on the same page, so I'll be able to do a lot more with guides in the coming weeks.

Mendicant University

Our plan for the next year of Mendicant University has been sent out out to our alumni network and the general consensus is that it's a good plan and that we'll move forward with it. I gave paid supporters an inside look at what we're planning by passing along the same video and PDF that I sent to our alumni, and that lead to some interesting discussion on the ruby-mendicant-supporters mailing list. I was excited to see some folks get involved who aren't directly involved in Mendicant University, but are supporting it through this subscription program. For those who aren't in either the Mendicant University alumni network or in the supporters network, we'll make the whole plan publicly available by July 15th.

Additionally, I just sent out the course guidelines for our July course today. That means we'll start seeing students send in project proposals soon!

Teach Me To Code podcast

I mentioned last week that I recorded a podcast with Chuck Max Wood about various things ranging from Mendicant University to RubyGems. It was released a few days ago, so check it out if you want to hear even more about what I've been working on. 

Software Development for Beginners (Training in New Haven, CT)

Jordan and I will be hosting a local training here in New Haven, with our first session on July 6th. The first session will be free, and future sessions will be $20, to keep it affordable for anyone who wants to take it. The goal of this program is to take folks with no programming experience, show them what is possible, and then give them some guidance on how to get involved with programming as a hobby or possibly even a career. Stay tuned to this blog for registration information, and if you have friends or family in New Haven that you think would enjoy this sort of course, please send them our way.

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 69 subscribers backing me for a total of $724/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1300-$1800/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.

I was away visiting family and trying to ward off sympthoms of burnout for a few days, but still managed to get some things done since the last progress report.

RubyGems Work  (Week 4)

Things have really quieted down around RubyGems, and that means we've had a chance to catch our breath and consider priorities. Some effort is still going to be made on a compatibility layer, likely in the form of a backports gem, but the new plan is to focus on stabilizing the new APIs so that new breakage won't happen, and to help folks port old code to the new APIs as much as possible. That work is best left up to the maintainers of RubyGems, but for my part, what I can do is help with documentation. I now have commit access to RubyGems and the RubyGems guides, and will be gradually improving documentation over the next several weeks.

So far, I've only done a little: patched the README of RubyGems  to fix an outdated reference to the RubyForge tracker, and triaged two requests in the rubygems/guides issue tracker. Due to my relative lack of experience with RubyGems itself, I am trying to encourage folks to contribute documentation patches themselves so that I can just help with cleanup and merging. However, I'm going to keep working on this even if I have to do the legwork myself: I think I can make an upgrade guide for end users and plugin developers that would be handy for those wanting to move to RubyGems 1.8. I have enough material from various tweets I've sent along to those trying to upgrade that I should be able to put together something useful.

Mendicant University

We are still working through our plans for the next school year of Mendicant University, which will start in September of this year. We are making a large number of small changes that should add up to a big difference in the way we do things. We still need to send our plans to our alumni network for review, but the staff has finally reached a consensus and we think we have a good plan put together. We will release the entire thing to the public within a few weeks, but for now I don't want to commit publicly to any of our plans without first getting feedback from our students.

If you're one of my paying supporters and want a bit more of an inside scoop, just ask on the supporters mailing list. These aren't secrets, I just rather not talk about work-in-progress plans in public right now. Everyone else, I apologize for how long this process has taken, we take changes to Mendicant University very seriously and are just trying hard to get it right.

Other Miscellaneous Stuff

I met with Sandi Metz on Tuesday to provide some feedback on her software design book that she's working on. She is doing some awesome stuff, and I'm really excited to be able to help her make the book even more awesome. This isn't exactly related to the Mendicant experiment, but still interesting and worth noting.

I was also a guest panelist once again for the Ruby Rogues podcast, this time around the topic was on debugging. You'll also see me on the Teach Me To Code podcast with Charles Max Wood some time next week. It was recorded yesterday, and covers various topics including Mendicant University, a retrospective on the Ruby Best Practices book I wrote a couple years ago, and my thoughts on community and open source.

Still fighting burnout

There has been so much going on in my life that I still find myself very exhausted and feeling kind of overwhelmed with everything. I think these feelings will pass once I get through all the various planning phases for my numerous projects and can buckle down and just get some work done. But for right now, I'm needing to take a few more breaks than I would like to just to remain feeling halfway productive. Please bear with me for the next few weeks, and then we should see productivity increasing once more.

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 68 subscribers backing me for a total of $720/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1300-$1800/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.

This week is a bit light on the community side because I had to do a bit of commercial work to keep cash flowing, but there are still a few things worth reporting.

RubyGems Work  (Week 3)

I've been busy on twitter finding people who are having problems with RubyGems and encouraging them to upgrade to 1.8.5 to see if it fixes their problems. For the most part, it has done the trick. Rails 2.3.12 was released yesterday, which fixed the compatibility issues many were experiencing. I've also been talking with Eric, Evan, and Ryan about various miscellaneous things behind the scenes, I'll be sure to report if any of the things we discussed actually materialize. The two main things I want to focus on is improving end user documentation, and on helping Evan with the compatibility layer stuff, but we're still trying to figure out what kind of work I'm best suited for.

In other news, one highly requested change was made: The RubyGems issue tracker is now on Github!

Mendicant University

Last week I mentioned that our May session was the most successful to date. Here are a couple reviews from the students who took the course: one from Vitor Pellegrino, another from Chris Geihsler.

Additionally, Jordan and I met to put together a plan for Mendicant University 2012. Our primary goal was to focus on quality rather than quantity and get together a plan that is sustainable. We are going to be putting this in front of our alumni early next week and will have something to report on by the next progress report.

GoRuCo Lightning Talk

I gave a lightning talk at GoRuCo outlining the history of the transition of PDF::Writer to Prawn, and it sort of came off as a rambling rant. Still, it's an interesting topic, and I've included the transcript of what I originally meant to say in my talk.

Monetization

After a few deep conversations with folks I really look up to at GoRuCo, it became clear to me that in order for my efforts to be sustainable, I need to stop worrying about whether I'm going to have enough money two months from now. These subscriptions help a lot with that, but they're part of the long term game, at least until they're clearing $2000/mo or more. So unfortunately, that means that I will need to spend some time on monetization which will at least partially take me away from my community work. However, I'm going to try to do that in classy ways, at least at first, so as to maximize the amount of social value of the work that I do.

Jordan (@Jordan_Byron) and I have put plans together for teaching an affordable local community course in software development for beginners here in New Haven. It'll be a six week course with the first session for free, and the five sessions to follow that one costing $100 total ($20/session). This won't come close to paying the mortgage, but might just be another trickle of revenue that's a fixed commitment and does something pretty helpful for our local community. I have to say though, the difference in pay is a bit staggering when I'm used to being able to charge $900 for a weekend at Compleat Rubyist. But the whole point of this is to make it affordable... so that's where we stand with that.

We're also still working hard on Duke Nukem Forever the book website for my Ruby Object System eBook. As soon as we get that passed through BrainTree, we can start accepting pre-orders which should help somewhat. We have a laundry list of other ideas as well if these two don't bring in enough in the near term, but in actuality I'll likely need to continue to dip into consulting here and there, which is better than nothing, but manages to be a huge distraction to me. Personally I just hope that these subscriptions continue to grow so that I can not think about these things, but that's just not practical on $700/month. That said, this money is making a HUGE difference for me, so I can't thank those who've subscribed enough.

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

NOTE: Taking a short break to visit family

Over the next few days I'll be stepping away from the keyboard and visiting with family and generally relaxing. I should be back on top of things by Tuesday, but have felt dangerously close to burnout for the last two weeks and need to recharge the batteries.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 62 subscribers backing me for a total of $644/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1450-$1950/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.

Mending RubyGems Fences (Week 2)

Since last week's progress report, I've been even more active on working to resolve issues surrounding RubyGems. I've been blogging things as I go, but the most significant progress so far is that we've got the team to agree to what I feel is a very reasonable release management policy. However, my efforts so far were not enough to stop the SlimGems fork of RubyGems from being released, which turned up the heat once more, but also brought some issues up that I hadn't considered before. I've decided that to be able to continue to be helpful with the RubyGems situation, I can't just rely on talking anymore, but need to roll up my sleeves and get my hands dirty with some code. I'm planning to get familiar with the RubyGems source code over the next week or so, in particular exploring the changes since RubyGems 1.3.7 to 1.8.5. I've also reached out to folks who have experienced breakage as a result of RubyGems upgrades, in the hopes that I can investigate what caused the problems they ran into.

Two concrete goals are on my radar as part of this expedition into the RubyGems source. The first is that I want to write some documentation about the internals and the changes that have been happening so that there is more information out there for folks to make informed decisions based on. The second is that I've been talking with Evan Phoenix about some creative ways to meet the 'backwards compatibility forever' goals of SlimGems in a less divisive way. However, both of these things depend heavily on how quickly I can front load on RubyGems knowledge, it may end up being a slow process.

Those who want to listen to an hour long discussion about this whole situation should listen to this week's Ruby Rogues podcast, I was a guest!

Mendicant University

We just wrapped up the May core skills course on Tuesday and have welcomed 10 new students into our alumni network. Our pass rate was 66%, with everyone except one student who stayed past the first week successfully completing the course. These are our best numbers ever, and that's largely thanks to the five other volunteers who helped out with the course: Shane Emmons, Steve Klabnik, Raoul Felix, Jaime Iniesta, and Justin Ramel. However, the end of the course is always the busiest part for me, because I have to review everyone's final submissions and individual projects. There were some very neat projects this time around, so I look forward to announcing them publicly within the next few days.

This week also gave way to a very significant milestone for Mendicant University, we have invited Shane Emmons to join us on staff! There is a short announcement over on our website, but we're absolutely thrilled to have Shane join us as our first teacher who is also an alumnus of our program. Shane's efforts will make it possible for us to really keep pushing things forward, and you'll be sure to see a huge impact from having him on our team within the next few months.

Last but not least, we're still in the process of selections for the July core skills session. It looks like we're going to fill up in the next couple days, nearly two weeks ahead of schedule.

There is a whole lot more going on at Mendicant University, but I'm going to need some time to catch my breath and also balance things out a bit with my RubyGems efforts. Expect to hear more next week, in particular, there should be at least a few interesting things of general value to the community by then.

Mailing List and IRC Channel for Ruby Mendicant Supporters

I have been promising for weeks now that I'd open up some communications channels for my paying supporters so that they can reach me in a more personalized setting. I have set up a mailing list and IRC channel for these purposes, and you should have received an email with info for how to access them if you're currently subscribed as a Ruby Mendicant Supporter. Please do make good use of these channels! I may be very busy over the next few days, but I would eventually like to talk with each and every person who is backing me, if only to find out what kind of things they're interested in and whether my work has been useful to them. I am not entirely sure how soon we'll have any sort of formal events such as office hours or other things like that, but we can at least start getting to know each other.

Want to Contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Please let me know what you think of what I've been doing so far. This has been a fun few weeks and I want to keep the momentum going, but I also want to make sure that the work I'm doing is in line with what the community considers valuable.

Permalink

Since December 2010, I've been working directly for the Ruby community on a full-time basis, with no formal sponsorship or funding beyond individual contributions. I want to make this sustainable on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 59 subscribers backing me for a total of $608/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1500-$2000/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now. To remain transparent, I am doing frequent updates on what I've been working on so that folks know what their money is supporting.

Mending RubyGems Fences

Since the last progress report, I've managed to throw myself into a difficult situation in the hopes of addressing some serious issues within the Ruby community. In particular, I have volunteered to act as a mediator to help defuse the intense drama that is currently surrounding the RubyGems project. I won't go into great detail in this report, because I've written extensively about it on this blog, but I can give a quick summary of what my goals are. First and foremost, I'm trying to collect some dispassonate information about the main source of tensions between the RubyGems maintainers and the community so that those on the sidelines can find out what's going on without getting sucked into the drama. Secondly, I'm trying to find areas in which compromises can be made so that folks on both sides of the fence have less reasons to be angry at each other. This approach seems to be working, though not as fast as some might hope. Lastly, I am trying to demonstrate by example that nerdrage is unproductive and harmful, and that acting civilly will not only help prevent people from getting so stressed, but also make the process of affecting positive change happen more rapidly. The results so far have been varied, but I feel the process is worth it and will be continuing on with it in the coming weeks, assuming nothing goes nuclear.

Ruby Object Model Book

Jordan (@Jordan_Byron) and I worked on building out the website for purchasing my book, because I do need some additional revenue streams coming in other than subscriptions, at least for now. But because the book is going to be released under a pay what you want model with a free option, I'll be happy to occasionally post excerpts here so that you can see what I've been up to. As a pre-requisite for prepping the book site, I needed at least a little sample content, so here are the first three micro-chapters as a PDF. At a first glance, this format might seem a bit weird to you, because it introduces classes, modules, and objects in the method lookup order rather than the way you learned OOP in school or in a Java/C++ book. It's an experiment that I think will ultimately be epic, but if you don't like the feel of it right now, wait until I have some more chapters written to express your doubts. I have what I think are good ideas for how this all will work but they're still tied up in my head.

Ruby Mendicant University

I've still been cranking away at helping our May students make it through the core skills course, but because I've been so busy with the RubyGems fiasco, I've also been leaning heavily on my assistant instructor, Shane Emmons (@semmons99) to make sure our students get the attention they deserve. When you add in our mentors and our visiting teacher Steve Klabnik (@steveklabnik), the students have had no shortage of available help and the results have paid off, this is our best retention rate in the last few days of the course ever.

In addition to the core skills course, we also have admissions open for new students who will join us in July. Four have applied already: two were accepted, and two are still pending review. Many people are attempting the PuzzleNode problemset, so that means that we'll likely see more applications soon.

Finally, as I mentioned in the last status update, we are sitting on a treasure trove of ideas from RailsConf, as well as a brand new idea that came to me last night, many of which will have direct impact on the community as a whole, not just our students. However, I've decided to wait until the end of the May session so that we can include our new alumni in the discussions. Expect news within a week!

Want to contribute?

If the things I'm working on sound worthwhile to you and you want to support it, please subscribe! It will help me keep doing good stuff for the community without having to focus too much on making ends meet. I've been doing this since December but only recently started accepting funding, so it will really help me counterbalance several months of burning through my savings.

Catch you again next week! I will get a mailing list and IRC channel set up for subscribers before the end of the month, but for now, if you have questions or thoughts to  share, feel free to leave them in the comments section below.

Permalink

My free online school, Mendicant University, has a lot in common with a startup environment even if we're headed down the nonprofit path. In particular, we share an endless amount of interesting ideas, a lack of available time to implement them all, and a goal of reaching some level of sustainability before the money we've scrounged up runs out. The more ambitious our plans become, the more I see what a hard job it is to start something. While the title of founder is something I originally gave myself just to be a bit facetious, now that Mendicant University is starting to become a real thing, I'm having to earn that badge.

As an entirely volunteer organization, we are always limited in resources. What this means to me is that any student or staff member who has decided to lend a helping hand needs to be working on the things that will help make sure that Mendicant University will still exist a year from now. There are a thousand interesting things we could be working on, in fact, last week's RbMU summit at RailsConf probably gave us enough ideas to last us all a lifetime. But in that lifetime of work, the question remains: What can be done today that will help make sure that we will be here tomorrow?

I don't have an answer to this question just yet. But what I do have is maybe a strategy for helping to find that answer. It's something that should be familiar to object oriented programmers: Do one thing and do it well.  If the single responsibility principle works so well as an organizing principle for software systems, perhaps it will work for human systems as well. I even know the one thing that Mendicant University can do well, though it's far from surprising: We're really fucking good at teaching.

Yes, it's true that now that we've been around for almost a year, we're going to need to start treating this like a real organization and not just one of my experiments. That means we'll need to think about ways to engage the public, we'll need to consider fundraising options, we'll need to continue building up our infrastructure and do all the extra behind the scenes work that any medium sized organization needs to do. But the important thing to remember, throughout this all, is that all of this serves exactly one goal: to create an environment where high quality, personalized, experience based teaching can slingshot smart and interesting people into doing awesome stuff for the world.

So no matter what it takes for us to get there, that's what we'll be doing. What is the one thing you want to do well?

Permalink

I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 55 subscribers backing me for a total of $576/mo before paypal fees. Taking in account my wife's income, I still need to come up with about $1500-$2000/month more to maintain our current lifestyle. However, the current subscribers have given me a great start, and I'm continuing on with the experiment for now.

Since the last progress report, I've primarily been running the May 2011 Core Skills Session at Ruby Mendicant University as well as attending BohConf 2011 (at RailsConf). On Tuesday 5/17 we held a mini RbMU summit with several of the alumni who were in Baltimore for the conference. A tremendous amount of progress was made in figuring out what our plans will be for the next year as Ruby Mendicant University continues to grow and change. Unfortunately, because I want to give the rest of the alumni who weren't in attendance a chance to review the ideas and plans that came up, I won't be able to talk about the details of what we went over just yet, though I promise to reveal some of them in the next progress report.

During BohConf, I spent a lot of time with prospective students who were interested in Ruby Mendicant University, helping them figure out what educational programs and resources would be best for them in their current situation. Luckily, since both Steve Klabnik (of Hackety Hack) and Andy Lindeman (of P2PU) were also in attendance, I was able to help folks who weren't quite ready for RbMU find someone who could help them. Interacting directly with a number of folks at different skill levels revealed some interesting patterns that are probably worth blogging about.

Because I spent much of the last week or so interacting with people face to face and listening to their stories, I didn't get a whole lot of hacking done, and so don't have much to share over the interwebs just yet. Here are some things you might be interested to know, nonetheless:

• Jordan gave a great talk about Ruby Mendicant University's tech stack at Ignite RailsConf. In the near future, we'll be writing contribution documentation so that folks can help us with university-web and puzzlenode by contributing patches, even if they're not actively involved in RbMU.
• My work on RbMU won me the 2011 Ignite RailsConf ignition Grant ($2000). This award came complete with a giant check, which is totally awesome. Here's the video of my acceptance speech. I almost forgot I applied for this grant, so the win was a complete surprise, but also totally awesome.
• I had the distinct honor to join Aaron Patterson on stage for a live performance of Double Dream Hands. It was so intense.
• Admissions for Ruby Mendicant University's July session are now open! Whether you plan to apply or not, please enjoy the four new problems posted to PuzzleNode.
• Our first visiting teacher at RbMU, Steve Klabnik, won a Ruby Hero Award!
  

While the last week's efforts have mostly had to do with making progress behind the scenes, the next few weeks will surely bring plenty of publicly visible progress on my various projects. If my progress so far has  convinced you that it's worth contributing $4, $8, $16, or $32 a month  to help me keep working full time on community projects like these,  please do subscribe below. Whether or not you're a subscriber, if you  find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.

Catch you again next week! I will get a mailing list and IRC channel set up for subscribers before the end of the month, but for now, if you have questions or thoughts to  share, feel free to leave them in the comments section below.

Permalink

Two week ago, I announced that I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I have 53 subscribers backing me for a total of $556/mo before paypal fees. Only three of these were new subscribers within the last week, so maybe I need to ramp up the promotions somewhat. That said, the lack of new subscribers has not stopped me from keeping on with my work, and here's what I got done since last week's progress report.

• Added rudimentary support for chapter outlines in Bookie, in PDF, ePUB, and MOBI formats.
• Met with Jordan to plan RbMU activities for RailsConf / BohConf. We'll be running a programming contest during the conference and giving away a Kindle 3G!
• Made a 14 minute video that serves as introduction to working with binary file formats in Ruby. You can find it on YouTube.
• Wrote another small chapter for my book on the Ruby object system. I will release some sample chapters by the end of the month.
• Created a problem for PuzzleNode on Steganography (to be released on 3/15).
  
• Coordinated with Brandon Hays to get the RbMU alumni set up to test Puzzlenode problems. All problems are currently being worked on and debugged, and will be ready for the public on 3/15.
• Built three new exercises for the RbMU May core skills course, one on intergrating with command line applications, one on decoding binary file formats, and another on creating a conversation simulator. These exercises and some student solutions will be released at the beginning of June.
• Spent two afternoons doing office hours for RbMU students, giving some initial code reviews and general advice.
  

I probably did other things within the last week or so, but these are the things that haven't yet slipped my mind. If my progress so far has convinced you that it's worth contributing $4, $8, $16, or $32 a month to help me keep working full time on community projects like these, please do subscribe below. Whether or not you're a subscriber, if you find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.

Catch you again next week! I will get a mailing list and IRC channel set up for subscribers soon, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.

Permalink

About a week ago, I announced that I want to continue my Ruby Mendicant experiment on an ongoing basis by accepting small monthly payments from folks who want to support my community projects. At the time of writing this post, I now have 50 subscribers backing me for a total of $544/mo before paypal fees. That puts me 20-25% of the way to a livable revenue stream within the first week of this experiment, which isn't a bad start.

One of the things I promised my backers is that I'd do a weekly dump of what I've been working on, and so here's the first one. Enjoy!

• I started refactoring bookie (my Ebook generation library) a bit so that it can eventually become something suitable for general use and not just a hack for my own needs. In particular, I started fleshing out rudimentary chapter support, currently just setting up headers now but will soon have proper native outline support for ePUB, PDF, and MOBI. The current capabilities of bookie can be seen in this sample PDF output. While they're a modest start, I think they show some promise. NOTE: I need some Kindle and iPad testers for the ePUB and MOBI support, especially could use some help with iPad because I don't own one. If you don't mind loading up some sample files from time to time and giving me feedback, please let me know.

• I did some work on the introduction for my book about the Ruby object system. This book will eventually be both free as in beer (via a sliding scale payment with a free option) and free as in freedom (via the creative commons sharealike and attribution license), but right now is only accessible through private beta books program. Still, I should have a publicly available sample chapter soon. This book uses bookie for eBook generation, which should push bookie along as I continue writing.

• I converted Practicing Ruby Issue #11 from its original format and released it on the Practicing Ruby blog, completing the four part series on modules.

• Met with @Jordan_Byron to discuss some upcoming changes to the way code reviews are requested in RbMU's university-web application. In the near future, all students and mentors in a course will have an easy place to find all pending review requests for any given project. Will post screenshots of this system once we get it built.

• Worked with Brandon Hays (@tehviking) to get preparations underway for releasing the next batch of PuzzleNode problems. These will be a mixture of student created problems and problems I've written myself, to be released publicly on May 15th as part of the next Ruby Mendicant University admissions call. These will go into internal testing within our alumni network by Monday 5/9, so we will hopefully have several people solve each problem before we roll them publicly, avoiding the mess that we made when we released our first batch untested.

• Reviewed individual project proposals for the 15 students that will be participating in the May 2011 RbMU core skills session, helping students revise their proposals as necessary. As usual, it's an exciting mix of ideas, ranging from game engines to personal productivity tools to neural networks. I don't like to talk too much about student projects before they've actually completed their session, but needless to say, I'm very excited about the things our students will be working on, and you'll be able to see all their progress as open source projects on github three weeks from now.

• Made a video response to Brandon's post about why he still doesn't contribute to open source software, sharing my experiences both as a free software project maintainer and as someone who mentors beginner and intermediate software developers. You can find this talk on YouTube, it's on the long side at just under 50 minutes, but hopefully useful to anyone out there who has fears or reservations about participating in open source. Also, could be useful to maintainers who want to make their projects more friendly to new contributors. This was in part inspired by a talk that Erik Michaels-Ober (@sferik) gave at Red Dirt RubyConf, but only coincidentally, since it's based on my own opinions and experiences that happen to overlap heavily with his outlook on things.
  

I probably did other things within the last week or so, but these are the things that haven't yet slipped my mind. If my progress so far has convinced you that it's worth contributing $4, $8, $16, or $32 a month to help me keep working full time on community projects like these, please do subscribe below. Whether or not you're a subscriber, if you find my story interesting, I'd appreciate if you share a link back to this post on twitter or wherever else it might reach people who would appreciate it.

Catch you again next week! I will get a mailing list and IRC channel set up for subscribers soon, but for now, if you have questions or thoughts to share, feel free to leave them in the comments section below.

Permalink

Becoming a better software developer isn’t easy. While there are plenty of resources to help beginners understand some fundamental skills, this only establishes a basic level of proficiency. Expert developers are orders of magnitude more productive than even somewhat advanced beginners, but rarely produce resources that help folks climb out of the vast chasm that represents the population of intermediate developers.

Passive learning materials are of marginal assistance to intermediate developers. While reading a new book or blog might help familiarize someone with a new tool or technique, the gains from this are superficial and do not lead to the sort of plateau-busting realizations that are necessary in order to break through the many walls that stand between proficiency and mastery.

What intermediate developers really need is a bit of guidance to discover the right kinds of problems to be working on, the sorts of things that will cause them to ask the right questions, even if the answers to those questions lie somewhere off in the distance. They also need support from other developers who have traveled a bit farther down the path, so that they can learn about common pitfalls or get warned about dead ends before barreling down them at breakneck speeds.

Software development is hard, and that’s not likely to change any time soon. The necessary complexity of most computing problems is significant enough that there will still be more than enough challenges for a lifetime even if we never repeat the same mistakes others have made. A single experienced developer can make a massive impact simply by listening to what problems others are experiencing and giving helpful feedback based on what he or she has learned the hard way. A community of folks dedicated to providing the same sort of support is even better.

However, it isn’t sufficient just to have a group of people studying the craft of software development: those have existed as long as software has existed and if they were capable of closing this gap, they would have done so by now. A lack of sufficient context is what most frequently leads to tribalism in software communities, and the end result is a polarizing effect that causes direct harm to real progress by generating far more heat than light whenever a certain tool or technique is discussed.

It is necessary to seek deeper, more personalized connections so that both student and mentor have a stronger shared understanding of the surrounding context of any given problem.

RbMU exists because we understand just how much of an impact that software developers have on our world. While technology itself is neutral, we feel like given the skills and resources, those who write code can make a massive positive impact on the way that we live our lives.  By empowering those who may not have otherwise reached their full potential, we can touch the world in a much more significant way as a community than any of us could on our own.

To sum it all up, we believe that teaching changes lives, and software changes lives. So teaching software developers changes lives that change lives so that we can change lives while we change lives. Of course, we also do this because it’s fun. :)

Permalink

Perhaps predictably, I've become too busy with the actual running of Mendicant University to spend a significant amount of time each day talking about what we're doing and how we got where we are. I did spend a whole day wandering around in the Montreal underground city trying to figure out why focusing on real projects is so important to me, and the differences between amateurs, experts, and professionals. I struggled with thinking about how those three titles can apply to one person, and the tensions that exist between the three roles. The best I could come up with was a slightly modified form of a quote I found in a Go book: "Amateurs play the game, experts study it, professionals labor at it" (the expert bit was my addition).

I think that these stories are important for establishing a background story for what is still mostly an underground program. Perhaps it would be better if folks who are blogging elsewhere would contact me and we could do some interviews by email or Skype voice to answer the questions people might be interested in? Whether that happens or not, I'll revisit this project of telling our story some time in the future, but for now, I need to put this series on hold.

Permalink

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

One thing I like about Sir Ken Robinson is he has a way of concisely describing things that I've felt viscerally for years but didn't have the adequate words to describe. In particular, I like the way he breaks down the concept of education into three categories: curriculum, pedagogy, and assessment. Pedagogy is the bit where the real teaching happens, and like Robinson, I agree that it's the most important of the three components. I need to look no further than my own experiences in primary school and in college to see the huge difference that an emphasis on pedagogy can make.

Most of the educators I interacted throughout school were nothing more than glorified proctors. They handed me input material pre-defined by their state and federal curriculum requirements, in the format that those requirements prescribed, and then expected from me output that could be objectively tested and measured so that it could be attached as a line item to my student id number on a 'permanent record'. Both individually and taken as a group, good scores were considered an education success, and bad scores were considered a failure. Rarely were any of my teachers even permitted to interpret this in a different way, let alone act upon it and produce materials that would actually challenge students to think freely rather than numbly follow a sterile process of information collection and verification. Fortunately, some of the teachers I had were subversive types, and so I learned at an early age the difference between being taught a lesson and being 'educated'.

Listed in rough chronological order, here are the things that my real teachers did for me in primary school that the average 'educator' wouldn't dare try:

• In third grade, after realizing I was bored with basic arithmetic, a teacher wrote up a custom hand written lesson for me covering some basic algebra examples. During a study session while everyone else was doing arithmetic examples, I worked on the problems she gave me instead, and she'd occasionally stop by my desk to quietly give me some hints. I failed miserably at the problems she gave me because they were way above my level, but she taught me a ton in the process.
• In fourth grade, that teacher was re-assigned to teaching fourth grade. By luck or by back-room dealing, I ended up being the only student to stay in her class. In either case, it gave me another year of the occasional custom lesson and at least someone who supported me beyond what the exercises called for.
• In sixth through eighth grade, a shop teacher started all sorts of miscellaneous programs for bored students, including building kayaks from scratch and launching model rockets. Most of these programs ran far over their allotted time within the course, but the teacher let us use the shop whenever we wanted, including to work on our own personal projects. He almost certainly broke every rule the school had about this sort of stuff, and ended up buying materials on his own frequently to fund the courses.
• Throughout high school, a few science teachers hosted several independent studies to allow me to persue my own interests. They let me play with pretty much any materials I wanted, taught me on the spot lessons when needed, and one even started helping me design a circuit for a binary clock similar to the ones they used to sell on ThinkGeek.
• A teacher at the middle school that Jordan Byron and I went to gave us chances to do music and sound recording stuff for shows, I mostly helped run wires but Jordan learned a ton from that. He also gave us access to video editing machines and let us hang out and use the equipment well after he left and just told us to lock the doors on the way out.
• That same teacher got me a job as a sysadmin in my school district in my senior year of high school, because he knew I was good with computers and I was actually A+/Network+ certified. I hated that job and it eventually got shut down due to politics upstream, but it meant I got to start on paid computer work much earlier than most people have a chance to.

I could list out more things like this, but now that I write them out, I realize just how boring and ordinary each one of them sounds. They're just the logical things that a real teacher might do given the resources and time to provide opportunities for individualized education to those who clearly want it. But the thing that makes them interesting is that as a result of them, I frequently got in trouble with administrators or fell behind on my assigned work, making me graduate high school only slightly above the middle of my class. Additionally, while most of the things above sound harmless, most of these teachers made it clear to me that I shouldn't tell people about what they were doing for me, because they could get in trouble or even fired for it! You would think that such treatment would be reserved for those educators who were fondling girls in the closet or making racist comments in class, but not for those who umm... actually wanted to live up to the responsibilities that should come with their job, right?

In my time studying at university, things got a little better, but only slightly. Many teachers were too busy or too frustrated with the lack of quality of their students that they fell back on the same drill and test routines that plague primary education. But many others did start to give me interesting projects and enough academic freedom where I finally felt like I was being encouraged rather than stifled by the academic process. One in particular did some special interest courses with me that paved the way for the way that I'm running RMU, and so he deserves a story of his own! 

Permalink

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

In yesterday's post, I detailed my own personal story of how I got to the point where I could collaborate with and teach others. I also revealed the fact that since I was given so many great opportunities in life, I find it an absolute duty to find ways for others to benefit from the same good fortune I stumbled into by sheer luck. This to me is a key difference between a training relationship and a mentorship relationship.

A good trainer can give you incredibly useful skills, and to do that they need to understand enough about you to pick the techniques that will be effective with you. But a mentor must go beyond finding the most effective way for you to learn skills A,B,C and needs to touch on what you really want to do in life, and who you really are. Because mentoring relationships are inherently personalized, there's no way to put a dollar value on what they're worth. So for me, I feel it'd be impossible to settle up with JEG2 and feel like I had paid him back for the effort he put into me. That left me with no choice but to try to find some way to pay it forward through community service.

Back before I was even out of the baby pool as far as coding was concerned, I tried to help others by emulating what JEG2 had done for me. I tried to help beginning programmers learn how to code, with mostly disasterous results. At the time, I did not realize that it isn't simply a matter of presenting the information that the person needs to hear, but also reaching them in the way they needed to be reached. There are at least a few of my friends that I fear I've probably scared away from programming for life, or at least set them back by years by emphasizing on all the wrong things. I learned the hard way that without firm guidance from someone much more experienced, an advanced beginner teaching a novice is a bit like the blind leading the blind. Of course, at the time I assumed that because I had a great teacher, I myself would be a great teacher by default, and so assumed that every student I had was stupid until I started noticing all the evidence to the contrary. Thinking that the act of teaching was merely the act of providing access to raw information and explaining it was killing my ability to be useful.

My lack of success as a mentor early on forced me to find some other way to help. I was arrogant enough to blame my students, but not ignorant enough to see when my efforts weren't bearing fruits. Two things ended up working out much better for me: Writing a lot of technical articles, and hacking on open source projects. I was selected early on to be one of the initial bloggers for O'Reilly Ruby, which is now defunct, but at the time was a huge opportunity to get myself exposure. Similarly, through prodding from JEG2 I had been accepted into Google Summer of Code 2006, which gained me lots of attention from the community who I had accidentally tricked through my hubris into thinking I knew what I was doing. Between these two opportunities, I was able to finally feel like I was helping people. Many folks enjoyed my writing and my code, but many others taught me lots through their feedback about just what I didn't know. I even wrote a self-published book about Ruport with Mike Milner to combine these two passions of mine. Through years of repeating this process, I humbled myself a bit. Lesson learned here: Fuck up in private and you may never realize it, fuck up in public and you WILL learn something, whether you want to or not.

I decided that I wanted to stick with a lifestyle that let me hack on open source as much as possible, and write as much as possible. Thankfully, my early work with BTree Technology and later with Madriska Media Group made this very much possible by letting me choose my own hours, commit to only what I felt I had time for, and generally just make my own plan. I have always enjoyed my consulting work because I really like seeing the direct impact of my work on businesses, and over the year, that has become a real passion of mine. But sooner or later, I felt like I needed a break from that and wanted to go purely into open source coding for a while. Hence, the original Ruby Mendicant project was born. Of course, being one who tends to overcommit, I decided that with all my newfound free time, I'd also want to write a proper Ruby book that shared in a more humble way the lessons I had learned over the years, and so Ruby Best Practices was born around the same time.

Both RBP and the Ruby Mendicant project that brought us Prawn were tremendous successes in the sense that they filled big gaps that needed filling. But somehow, they left me feeling unsatisfied. In a case of the grass being always greener on the other side, soon after I completed these projects, I turned back to consulting with a renewed sense of energy, and in the course of a year with Brad's help made huge positive changes to the way we do things at Madriska, and built up a set of processes and a team that totally kicks ass. I think the draw of consulting to me was once again being able to see the fruits of my own labor, something you tend to miss when you do open source. In open source projects, while you may get some really awesome contributions from people from time to time, they come in fits and spurts and the vast majority of your interactions end up being with users, who often don't quite understand how free software projects operate. It's also very rare for people to show what they've used your software to build, even in a healthy community. Thus, the impact is more visible in consulting than in open source, on an average day. Writing is a little bit better in that the reactions tend to be helpful or positive, but generating buzz is a job in itself and isn't quite fun.

Over time, I got a bit fed up with an internet that you can pour so much into, know that people are using and appreciating your work, but get so little back in the way of feedback. I still struggle with this and feel like it's quite unfair until I realize that my own patterns of behavior reflect the same thing I'd want to criticize. How many authors of open source projects that I've used do I thank for their efforts. Not nearly as many as I should.  How many projects do I patch or report bugs against? Even fewer than those I send thanks to? How many inspiring things do I read each day that I either don't share at all or only go as far as posting a RT on twitter? God, it'd be embarrassing to mention that number. I don't think that we're all bad people for not doing these things, it's just the nature of the beast. The internet is a huge consumption machine, and producers rarely get proper acknowledgement for their work. My heart feels lighter when I go to users group meetings or conferences because the most common word I hear on the hallway track is "Thank you", either for work I've done, or coming out of my own mouth to someone else I've appreciated. That tells me we do give a shit, but that the internet is vast, and we're just too busy to say thank you all the time.

I still wrestle with those feelings, and have worked to figure out how to solve them. Then it dawned on me: the real joy and growth that comes from this feeled is through interactions, not mere production and consumption! This is the difference between giving a talk and a giving a training, which I learned by first doing some trainings at Lone Star Ruby Conf, and then later working on Compleat Rubyist with David A. Black and Jeremy McAnally. In a training, you're giving people some useful information, but then working with them to make sure they understand it and getting to see a glimpse of how they use it. This is profoundly different than talking at a group of people who have their heads down in their laptops for 30-45 minutes, or writing a long winded post on an open source project so full of assumed knowledge that the reader must have their mind reading device engaged to make heads or tails of what you've just said. Trainings not only help people, you get to see that you've helped them! This closed the loop for me, and made it so that I felt my efforts were being matched with a sense of personal satisfaction that helped keep me emotionally stable as I put great effort into these things.

By the time I started really digging into training people, I had learned a whole lot more about the field and was finally ready to admit how full of fail my earlier attempts were back when I was still in the kiddie pool. But as I said at the very beginning of this post, the thing that separates training from mentoring is that the former is a fixed, fairly well defined commitment, that you can at least begin to guess at the value of. Mentoring is about the long game, and is about personal connections. But this is something I truly didn't realize until *after* starting RMU, so we'd be jumping ahead to discuss it now. More about that in a future story!

Permalink

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

Those who have followed my works know that it's no secret that I've credited virtually all of my success in software development to a single mentor, James Edward Gray II. Given the huge amount of people I respect and have learned from in this field, this may seem like a bold or even disingenous claim to make. But despite those concerns, it's a truth that I'd bet my whole reputation on.

For a period of about three years when I was in my teens, JEG2 spent time with me on a daily basis showing me first, what a bad Perl programmer I was, and then later, what a bad Ruby programmer I was, even if he started learning Ruby only a couple months before I did. Before I met James, I thought I was an awesome programmer, and I didn't yet believe that programming is an inherently hard thing to learn. In fact, I didn't even realize that programming isn't a single skill to master, but instead a complex web of related activities that are impossible to practice in a narrow minded, linear fashion. With James as my mentor I learned that you don't just need laser-like focus to be good at this kind of work, but you also need to be able to carry a lantern from time to time to shed light on the big picture.

Once you know that a lantern is a key part of the programmer's survival guide, that opens you up to make meaningful connections in the broader software community. The next step is being able to form a clearer and clearer picture of what this field is about, personalized by your own desires and interests. Back in early 2004, Ruby's community was still somewhat centralized and it was fairly easy to get a group of people in a single room or on a mailing list and call them a representative population of Ruby programmers. During that period of time, I was particularly inspired by a handful of folks from Ruby's old guard, in particular Matz, Jim Weirich, Francis Hwang, James Britt, Hal Fulton, Zed Shaw, and David A. Black. It's not a coincidence that most of these folks happened to also be on JEG2's list of heroes, both because of the centralized nature of the community, and because I assumed that if James found someone technically interesting, that he probably had a good reason for it. Studying the works of these individuals, I found that they had lots of different views on things, and that sometimes, they had ideas or opinions that conflicted with what JEG2 believed, but didn't appear to have any obvious flaws. This is when I learned that even something as objective as programming has both subjective components and things that are sufficiently complex to cause experts to reasonably disagree with one another.

Over time, JEG2 and I transitioned from a purely student/mentor role to a role of collaborators, in which I could actually meaningfully help out in some way. My first project with JEG2 was HighLine, in which he did most of the work, but that to this day, there is at least some of my own code in it that wasn't completely ripped out and re-written. Later, JEG2 acted as an active collaborator on the first big project that I led myself, Ruby Reports, even if he didn't actually write much code for it. While it's not really a terribly important detail in the grand scheme of things, I think it's an interesting historical note that the Ruby 1.9 CSV standard library's initial development started as a need for the company that I was doing work on Ruport for.  Once the lines of our relationship blurred a bit in this manner, it gave me the necessary motivation to connect with others as collaborators. As a result of this, I ended up getting my first patch accepted to an open source library that I didn't help build by sending Aaron Patterson a couple crappy changes to Mechanize. Somehow this lead to a good friendship with him, even if that friendship mostly consists of me calling in the occasional favor to Aaron and by sheer coincidence, not doing much in return for him. I guess a single accepted patch buys you a lot!

Soon enough, I found myself in a situation where people were submitting patches to my own projects, and over the years gained great benefits from getting to know folks like Dudley Flanders, James Healy, and Mike Milner on my Ruby Reports project. Work on this project led me to a subcontracting gig that JEG2 helped me set up by just making an introduction for me to the founder of Madriska Media Group, Brad Ediger. What started as a bit of work on a single project led to a lasting business partnership with Brad and I that has now gone on for something like four years. This relationship has been so successful, that I pass all my consulting leads through Madriska not because I couldn't handle them on my own, but because I love working with Brad's company so much. While these days RMU prevents me from doing any active development work for Madriska, the commission I receive from my team's work, along with the small amount of project management I do for Madriska helps cover some of our basic living expenses. Without James, there's no telling if I would have ever met Brad. That'd be both a community loss as well as a personal one, considering that Brad is now defacto lead developer on the Prawn PDF generation library that I started but never quite finished.

These days, JEG2 and I have diverged quite a bit in our respective paths, but our interactions in my formative days as a software developer have shaped me in ways that I'll never be able to fully grasp. I take it as a good sign that sometimes we disagree these days, and that once in a while, I end up being the one who teaches JEG2 something in the process. But it should be at this point pretty obvious why I credit so much of my own success to James. After reading this story, you may be wondering what happens emotionally when someone takes on an arrogant, hot headed teenager who thinks they're some sort of Perl guru and shows them exactly how much they're missing, and then follows that up with all the support necessary to turn a train wreck into a success story? In my case at least, you end up with someone who feels an absolute responsibility to pay it forward in whatever way I can. More on that in our next story!

Permalink

Note: this is a bit of an unfiltered ramble, but I wanted to make some sort of public statement about how our first week after PuzzleNode's launch went.

Last week, we launched a programming quiz website called PuzzleNode as a fun way to conduct new student admissions for Ruby Mendicant University. While the primary purpose of this site is to act as a sort of entrance exam for our core skills course at RMU, it is also suitable for general use. Because it is modeled in the style of Project Euler or the Internet Problem Solving Contest, people aren't limited to solving the puzzles using Ruby, any language will do.

In less than 7 days, we've had 110 people create accounts, 27 attempt at least one puzzle, and of those folks, 12 solved at least one problem. Two folks have even solved all four problems, which amounts to no small amount of work. These numbers are modest, but better than we expected for a project that has only indirectly been mentioned through our call for participation for RMU. People seem to enjoy the problems we posted so far, and we're still seeing new signups each day. But after a week or so, we're feeling more embarrassed of our execution on this project than we are proud.

PuzzleNode was built in the same manner that our original work on university-web was conducted; an hour here and an hour there between active RMU operations such as courses, alumni network activities, and other administrative work. The code is something Jordan and I hacked together whenever we got a bit of spare time. This is not how we usually like to do our work, because it results in sloppy, unreliable products. To put it bluntly, we hardly tested either the puzzles or the application at all before we went live with PuzzleNode, and that was a very bad idea.

In the first hour after launch, I immediately detected a critical bug in the system that we did not anticipate ahead of time. We were using send_file for our file downloads, which worked fine when running the app in our local environments. But we quickly found that send_file did not work on our production server, which is Passenger based. I did not yet get a chance to look up the root of the issue, but I had run into this problem once before and found that it's possible to work around it by using send_data instead. So, I went ahead and cargo culted that old fix and it solved the problem, but likely not before lots of folks tried to download input files and got 0k file sizes.

Soon after that, bug reports started to roll in about the problems themselves. We simply hash uploads and compare them against a reference fingerprint, which means our system is very stupid about things like whitespace. This is something we're okay with because we keep the output specifications very simple, but two of our own solutions did weird things with whitespace by accident. We forgot to put a trailing newline at the end of our solution files, which is unintuitive and caused a bunch of false-negatives for submitters until we fixed them and re-uploaded them. Soon after that, the real problems began to uncover themselves.

Two of our four problems did not have unique solutions, which when you are using hashes to verify results, is a big problem. One we fixed by uploading a slightly modified input file which guaranteed a unique output. Another we fixed by introducing some instructions on how to break ties between equivalent solutions. It took a long time to discover that these problems were flawed, and took a fair bit of back and forth with frustrated submitters who were quite sure they had a correct answer, but not sure why PuzzleNode was telling them they were wrong. Thankfully, these folks took it in stride, giving us patient, helpful bug reports until we uncovered the root issues and solved them. Fixing these problems caused solutions to start rolling in, a sign that things were looking up. But somewhere along the line, bad turned to weird.

Lots of folks successfully solved Problem #1, so we had assumed it wasn't flawed. But we were also receiving problem reports from folks who were pretty  sure their solutions were right, which felt like a contradiction. Sure enough, our solution was wrong, but not for any reason that we could predict. We learned via a tweet that apparently, the support for Banker's rounding in BigDecimal in Matz's Ruby (MRI/YARV) is broken, and always has been. That forced us to implement our own rounding function, and cross check it against JRuby and 1.9.3dev to confirm our new answer. This seemed to solve the problem, but required us to post a glaring disclaimer that basically said "Be careful not to get bit by the same bug we did".

In the end, this whole thing feels like a bit of a clusterfuck, but it's worth mentioning that it was never meant to go this way, and that we've already put plans in place to prevent this from happening again in the future. Our original plan was to run the puzzles internally within RMU's alumni network for several weeks before the entrance exam opened, to test both the app and the puzzles for correctness. I was also supposed to sanity check the rough drafts of puzzles the students wrote, and maybe even hand verify their solutions. But instead, what I ended up doing is uploading them the day of release and letting them loose on the public. Such is the life of running something like Ruby Mendicant University, which is in almost in every possible way akin to a startup environment in which I'm the frazzled founder left holding the bag when the shit hits the fan. As important as PuzzleNode is to us, it was one of 100 things I needed to do for RMU that week.

Thankfully, our "Ready... FIRE! Aim..." approach has its limits, and we're actually craftsmen and professionals at heart. We know when we've botched a release, and we botched this one. We were scared that if we didn't release it on the date we promised, it might get buried under 100 other things, and bringing the site live forced us to treat it as a real thing. But we wasted a lot of people's time with badly tested infrastructure and problems, almost entirely due to my own lack of available time to do the proper QA checks. So, with that in mind, it's not enough to say we're sorry, I want to make sure something gets done about it.

Starting tomorrow, PuzzleNode is going to have a proper support structure for it. One of our alumni at RMU, Brandon Hays, has kindly volunteered to manage the triage, testing, production prepwork, and launch of new problems. We are also going to modify PuzzleNode so that we can pre-release problems to the RMU alumni network so that they can be tested ahead of time. In the future, every problem will be solved by at least a few testers before it goes live. This will also serve as QA testing for the app itself, which now that we're out of crisis mode on, we'll commit ourselves to working on in a bit more careful fashion. But when things do break down from time to time, you'll have an official way to reach us, and someone ready to help you when you do. This is what we should have launched with, and I'm sorry that we didn't. But hopefully, our ability to fix things up quickly will restore any confidence we lost by doing such a sloppy launch.

Stay tuned to the announcements page on PuzzleNode for details about the support system we're putting in place. Until then, please go ahead and try the puzzles now if you haven't seen them yet, or try them again if you were having problems before. All in all, it's a cool site that our staff and students have put a lot of effort into, and I hope that it becomes a fun diversion for any hacker who enjoys a good puzzle from time to time.

PS: For those concerned about the broader problem that the velocity of the materials and tooling being produced around RMU is coming at the cost the quality and consistency of our work, we hear you. The spring and summer are going to be dedicated to doing less, better, and we're taking lots of steps in that direction. More to come about that soon. And for what it's worth, all these corners we've been cutting are because we pour all our energy into making RMU courses themselves amazingly high quality. But there are ways we can keep that up without shipping crap for our supporting systems.

Permalink

As Ruby Mendicant University grows over time, it may well end up becoming Mendicant University, a multi-disciplinary free online school for all those who value intellectual curiousity, social responsibility, and the producer mindset. In the hopes that it will help me connect with others who want to make this dream a reality, today I've decided to list out some of the cultural and practical values that I think will be important to the future of our project.

So, in no particular order, here are the things I value which I believe would make Mendicant University a good place to be:

• Global access to all our courses, resources and learning resources without any fees to all those who can put them to good use.
• A firm focus on practical applications and producing something of value from every course we teach.
• A highly individualized learning experience which provides direct access to experienced mentors at all times.
• A sustainable funding model that is completely independent of corporate sponsorship of any kind, while simultaneously minimizing dependence on direct donations.
• A system which counterbalances consumer culture by giving individuals the means of production for creating valuable contributions to society.
• A deeply connected network of students and staff who share new opportunities with each other and genuinely care about helping each other succeed.
• Courses taught by field experts who happen to be good teachers, rather than "expert teachers". All of our instructors should be able to draw on life experience to bring their courses to life, rather than simply relying on a disconnected academic body of knowledge.
• Frequent and meaningful interactions with the industries and ecosystems that our curriculum is meant to prepare our students for.
• An emphasis on continuous improvement and life-long learning. There will be no such thing as "graduating" Mendicant University.
• A system of evaluation which emphasizes iterative development and continuous feedback rather than arbitrary scoring or simple pass/fail metrics.
• An organization which is mostly run as a do-ocracy, in which a culture of participation is strongly encouraged.
• An environment that rewards careful, measured learning rather than faith-based arguments and common appeals to authority.
• A highly transparent organization which does not hide its inner workings from those involved, and works towards consensus building when internal conflicts arise.
• A place in which acting out of self-interest may be part of the picture, but is not the dominating motivation among participants.
• A place which rejects the aggressive "winner-take-all" attitude that is common in many professional communities, simply because it is an ineffective way to make real progress.
• A place which embraces the Hacker Ethic, and encourages playful exploration through the Hands-on Imperative.
  
• A place where opinions may be strong, but are loosely held so that they may change when presented with new information.
• A place in which the beginner's open mind is encouraged and the expert's narrow mindedness is discouraged. We all have something to learn at all times.
• A community which embraces diversity in all its forms and welcomes all individuals who share our common values, regardless of gender, race, ethnic background, religious background, sexual orientation, socio-economic status, or any other form cultural categorization.
  
• A close-knit community in which all those involved can directly observe and help shape the cultural values I've described above.

Permalink

I have a strong appreciation for the ideas behind the Software Craftmanship Movement, but find myself to be simultaneously overwhelmed and a bit annoyed by the seemingly unending rhetoric that comes along with it. Since I'm probably not alone here, I've tried to collect a very short list of guidelines for those looking to practice small-c craftsmanship as a software developer. They are, in no particular order:

• Remember that anything worth doing is worth doing well.
• Care about your work and work on the things that you care about.
• Learn from skilled mentors, but don't forget to pay it forward.
• Treat techniques and methodologies as tools, not religions
• Above all, don't forget to ship real works often!

Personally, I don't feel we need to evangelize these basic points. Instead, we should collaborate with others who share these common values, and then collectively demonstrate their worth through the fruits of our labor.  This is what I am doing with Ruby Mendicant University, and I hope it's what you'll do in your own organizations as well. The true software craftsmanship revoution will not be televised.

Permalink