Joseph Mosby josephmosby

One of my first projects as a Ruby/Rails programmer is simply getting static pages served on Heroku. That's it. Nothing fancy. I know that some would argue that I should be coming up with an "application," and I'm getting there. A friend had an immediate need to roll his static page over to Rails as he began to plan for more functionality, and I was happy to help to get some practice.

A few things pop into my head here. I have only been programming in Ruby/Rails for two weeks now, and that has been at night after the day job. I haven't even been fully invested in it each and every night, and yet I still feel like I'm growing in proficiency fairly quickly. Rails has its own set of frustrations - but 90% of the time, I feel like this is just how things should be DONE.

However....

Rails is an opinionated framework. It has a prescribed way of doing things, and it doesn't quite care if you don't want to do things that way. I still have no idea how I would di

I have now hit my first "wow" moment with Rails, where I actually understood why it has the following it does. It has raised some questions for me about the pedagogy of Rails, but that is not the language's fault; it is a question for the community.

Rails is fast. Mind-blowingly fast. From my cursory looks at the framework, it is immediately apparent that this was designed from the ground up to give me everything I'm going to inevitably want in a basic web application. And yet, for some reason, it isn't immediately sold that way. It's instead sold with stuff like...

"I'm not even joking when I say this, but I think some of the resources out there make it intentionally hard for non-technical people to start learning."

The above line was from a class on Rails - not a Ruby class, but a Rails class. The class was designed so that you could have no coding experience whatsoever and build an MVP, and it advertises itself as such. I think learning to code, even at the lowest level of difficulty, is a fantast

I am taking a step back in my Ruby on Rails journey, as it seems that my initial goals may have been a bit too ambitious.

As I said in a previous post, this is not my first foray into web applications. I've been working with Python and its associated frameworks for some time. When I was asked by a friend to work with Ruby, I thought that there would be a fair amount of similarities between Rails and Django given the structural similarities between Ruby and Python. I could not have been more wrong.

The Ruby and Python communities have taken their languages in completely different directions, and that's just fine. Ruby has no Benevolent Dictator for Life like Guido van Rossum, and 37signals has rejected any implications that their organization can be the sole deciders for Rails. That leaves a community free to evolve however it chooses to do so. There are pros and cons to this. Ruby (and consequently, Rails) has the ability to

This will either be the first of a series of posts on "how I became a Ruby convert" or "why Ruby is the worst language on the planet."

I've spent the last two years of my life working with Python and its popular web frameworks (Django, webapp2, and Flask). Python was the first language I ever learned, so I'm admittedly a bit biased toward the "Pythonic" way of doing things. Python favors readability of code, but it also favors exactitude. I can push bits around in memory with the same ease as a GET request. The entire community feels like it's made up of scientists who want to support that - so libraries follow the Pythonic way of doing things. Boolean tests are written the same way in each library as they are in the core Python language.

So you can imagine my frustration when I start working with Ruby on Rails... and specifically, RSpec.

Let's take a look at a webapp2 test:

import unittest

The Weeds of Markdown

Consider this a first experiment in John Gruber's Markdown. For the uninitiated, Markdown is a syntax combined with a tool that allows you to take specially formatted text and translate it into HTML. Though most out-of-the-box blogging platforms handle this conversion for bloggers, it gets a bit dicier as more customization is added.

I'm not going to get into the weeds of Markdown syntax, as Mr. Gruber's explanation is far better than mine. Instead, I'm going to do a brief intro on how to write a Python script to perform the task you'll most often need to do with Markdown: convert .md files to browser-readable HTML.

pip install markdown

The Markdown libraries are now standard in the PyPi repository and can be installed through pip (or your method of choice). Markdown has no dependencies and is a relatively quick install.

 def apply_converter(match, replacement, test_string):
 	if match in test_string:
 		pos = test_string.find(match)
 		new_string = test_string.replace(match, replacement)
 		return apply_converter(converter, new_string)
 	else:
 		return test_string

	def strip_out_tags(html):
	out_of_tags = []
	inside_tags = []
	words = []
	beginning_pos = 0
	end_pos = 0
	if html[beginning_pos] == '<':
	in_tags = True
	else:
	in_tags = False

	<h1>Choose Your Favorite Color</h1>
	<p>You will be shown two colors side by side. Pick your favorite color of the two. This is based on your personal opinion.</p>
	<p> </p>
	<p>Choose your color:</p>
	<table width="100%" cellpadding="5px" border="1" bordercolor="black">
	<tbody>

	<tr height="100px">
	<td bgcolor="${color_hex1}"><br />
	<!-- the ${color_hex1} variable is the syntax for the first color we'll input. -->

	import markdown
	import codecs
	import sys

	# First argument passed in must be an MD-compliant file.
	# Second argument is the file to write to.
	# For discussion, check here: https://gist.github.com/2713759

	md_file = codecs.open(sys.argv[1], mode='r', encoding='utf8')
	md_input = md_file.read()

	def propListBreaker(x):
	listmsg = re.split(r'(\D)',x)
	for i in listmsg:
	try:
	listmsg.remove("")
	except:
	break
	return listmsg