Here are my thoughts on the kinds and backgrounds of learners we currently see in the Mendicant mentoring program, and who we might see if we opened it up to beginning programmers. Like Gregory's essay on a similar topic, this was done as part of Greg Wilson's P2PU course.

Do you have experience in teaching absolute beginners? What do you think we would need to put in place to have an effective beginning mentoring program at Mendicant University? Are there other kinds of beginners you think would benefit from such a program?

Let us know what you think either via the alumni mailing list or via the public mendicant-research discussion list.

I work on the rstat.us project, and one of my personal goals is to make it easier for people to start contributing.

With that in mind, I've made a few index pages to our rocco documentation in the same style, but with the project's directory structure on the right hand side instead of the code. There's an index for the top-level, the app directory, and the test directory.

The app directory index, especially, tries to give an idea of the architecture of the application. There's an explanation of each of the models and controllers.

What do you think? Is this helpful? I'd love to hear any comments or suggestions, either via github issue for corrections or improvements, or you can reach me on twitter or rstat.us for any kind of comment.

In Greg Wilson's P2PU course on how to teach programmers, our second task was to try to figure out what kinds of learners we are targeting through the use of biographical sketches. Because Mendicant University already has a very real and diverse community, I simply couldn't allow myself to construct fictionalized bios as the exercise called for.

Because I still wanted to give the other students in Greg's class a sense of what Mendicant University's community members are like, and because I wanted to fulfill the spirit of the exercise if not the exact instructions, I did come up with a handful of broad-based personas that I feel map fairly accurately onto our alumni network. It was a real challenge and I feel it lacks the depth and subtleties that really make this community great, but it's still interesting to try to answer the question: who should study at Mendicant University?

I would love to hear what folks think about this essay, either via the alumni mailing list or via the public mendicant-research discussion list. I was quite uneasy trying to group and define you all, and would prefer if you help me by defining yourselves :)

Many of us spend our working days in front of computer monitors, surrounded by nearby electronic equipment, each item emitting radiation. Because of the duration of this exposure (many hours every day), computer radiation is a real health hazard.

Here's an article on how to protect yourself. In short:

1. Use your computer, monitor and UPS at as far a distance as you can
2. Don't use your laptop in your lap
3. Use wired connections whenever possible
4. Put desktop computers on the floor

What would happen if we unplugged from Twitter, Reddit, Hacker News, etc. and instead relied on smaller communities to gain exposure to the broader interweb of ideas? Would we end up painfully behind the curve? Or would we instead end up with more contextualized, more curated access to the resources we need?

I explore these questions and more in an essay over on my personal website.

Short answer? Absolutely.

There's much we can learn from many years of formal education. Many of the recommendations from the 2007 IES study are independent of whether you're sitting in a classroom or studying software development by yourself at home.

For my own perspective on this topic, check out this article.

Who doesn't love emoji? I know I do! And I wanted to add those fun little icons to all my apps. So I wrote a tiny rails gem which adds emoji parsing to redcarpet.

WARNING: This is alpha software which I hacked together while eating breakfast so use at your own risk .... and enjoy!

Pat Shaughnessy wrote another post about how MRI implements Strings – and if you’ve always wanted to dip your toes in the whole C side of Ruby’s original implementation, but were afraid of the complexity or your lack of C knowledge, this is a great starting point. The post not only shows the C structs behind Ruby Strings, but also contains a sweet, small example on how to implement a Ruby method in C, along with the right mkmf invocation.

This week I've challenged Practicing Ruby subscribers to analyze and improve a simple brainfuck implementation that Jia and I built. The goal is to practice code reading, refactoring, and design noodling on a non-trivial codebase in an interactive setting.

Mendicant University folks (along with the broader Ruby community) are welcome to join in and participate in this challenge as well, even if they're not subscribed to Practicing Ruby. Check out the full challenge details and dive in if you want to help me build The Most Incredible Brainfuck Implementation EVER!

I love both Sinatra and Rails, for different reasons. I've heard a few different heuristics for which framework would be better for your application, but I'm not sure the answer is all that simple, really. Regardless of which is correct for your application, I haven't seen a lot of people discussing how to move between the two frameworks.

I've done this move a few times now, so I wrote a blog post about the process you'd take to move a project from Sinatra to Rails.

Tonight, I stumbled across a great resource made by the folks who are organizing the January 17th Occupy Congress protest. It's a fact sheet on all 435 congressional representatives, including their top funding sources and how they voted on several important bits of legislature (NDAA, TARP, Healthcare Reform Act, SOPA sponsorship, etc.)

The problem is that they distributed this information as a single PDF file that is 40mb in size and several hundred pages long. Many folks were complaining in the comments about having trouble downloading the files due to the file size, so I figured I might be able to help out. Using OS X Automator I split the fact sheets out into individual files and extracted the text from the, and then processed them into an easy to navigate hierarchy with a crappy little Ruby script.

You can find the fact sheets broken out into individual pages over on Github now. I was inspired by Steve's "Don't be a slactivist" post and wanted to do a tiny bit to actively help a cause I believe in, so this opportunity came at the perfect time.

It's important to remember that slactivism is no substitute for actual activism, and on a day like today, it's even more important to remember.

I normally hate to link to Gizmodo, but this article is a good wake up call:

Today it's very, very easy to pretend to care about something. The election, racism, pro-democracy uprisings. These causes are noble, and most of the people supporting them are lazy. Today, let's remember what giving a shit really looks like. Hint: not your twitter picture.

More and more public data is available every day, much of it published on the Socrata platform. Socrata provides an API called SODA but its querying feature is difficult to use.

My new app helps programmers construct SODA queries. Read about it on my blog and check out the Socrata Query Helper.

Al­most every day some­one teaches me some­thing new and hope­fully I can help oth­ers by sharing that knowledge. This process is re­ally re­ward­ing but looking back I've no­ticed some mistakes I've made so I've written down some dos and don'ts for answering questions on the internet.

I'm working with several students from Mendicant's January 2012 session and encouraging all of them to SEND ME TEH CODEZ as soon as they've got something worthwhile to talk about. The result has been nothing short of amazing and I'm really starting to see the power of Github's pull request system.

But using Github to discuss code isn't my idea. Zach Holman's talk, "How GitHub uses GitHub to build GitHub" proposes that pull requests are for discussing code. Because of that they should be created right away so the discussion and feedback can occur faster, resulting in better code

I'm currently taking Greg Wilson's P2PU course on how to teach programming outside of the traditional classroom setting; a topic that is directly relevant to my work here at Mendicant University.

The first assignment was for students to compare their own teaching practices to the ones recommended in an evidence-based report by the Institute of Educational Sciences. If you're interested in how these ideas map to the way we run our courses here, be sure to check out my Reflections on how I teach essay over on my personal website.

In my new blog post, I write about the #rubythankful hash tag and why I'm sad that it seems to have dropped of the face of the earth. Thereby I elaborate on why I think that it even matters and that it is especially important to appreciate work in an open source community.

Here's a short tutorial I wrote awhile back on using Rack::Parser to encapsulate parsing logic in web service applications, as part of Mendicant University's "saying thanks to OSS maintainers" challenge back in August 2010.

Comments are welcome!

I was interested in learning Unity for game development so thought I'd make some videos showing my process. Hopefully this will be useful to anyone else wanting to try Unity 3D and the Boo programming language. Covering 5 functional categories in 16 videos the series is 3 hours and 24 minutes so it's much more thorough than the average quick tutorial.

The Unity system is a really interesting platform because it not only provides the engine but an integrated 3D development environment that links to MonoDevelop or VisualStudio for writing code. This tight integration makes rapidly developing games a lot easier and the workflow is incredibly fast.

Unity allows for cross platform deployment on Windows, Mac, iPhone, Android, and the web with licensing but they also have a free version for hobbyists so you can publish your games on Windows, Mac, and the web at no cost.

Come watch me live code and learn along with me as I figure out how to create an Asteroids type game in Unity3D using the Boo programming language.

In this blog post, I've attempted to distill a year and a half of lessons learned about how to build good code study groups based on my experiences at Mendicant University. I tried to address both technical issues and social issues, in the hopes that we can see more great places for technical learning crop up.

md_preview unobtrusively adds markdown preview ability to textareas in rails. Just add the gem to your Gemfile, require md_preview in your asset pipleline, then you're in business!