Today is a good day to code

Teaching my 7 Year Old Daughter to Code (Crypto)

Posted: August 24th, 2011 | Author: | Filed under: Lifestyle, Parenting, Programming, Ruby, Teaching Coding, Uncategorized | Tags: , , , , | 1 Comment »

When I started teaching programming to my children, I thought starting with JavaScript was a good idea. I still think that JavaScript is one of the most important languages to learn early in a programming career.  It just doesn’t seem to be the right choice for teaching someone to program when they are 7.

The reason is likely not what one would naturally think, the code isn’t too opaque, and the syntax wasn’t much of a problem for her.  It was just so much work to get output.  With my son, we worked on a really simple Python program working on his hand-me-down OLPC, my daughter was upgraded to an Acer Aspire 1 for her birthday.

With the Python, I felt like we made more progress due to the availability of a REPL.  We were able to make changes to the core code that was solving the problem and see results on the command line quickly.  With the JavaScript, we had to create an HTML page, load it into it, create some sort of markup output, etc… It just wasn’t as clean an approach to programming.

I have been asked by many about using “kid friendly” programming languages.  I think the people working on those are doing good work, however there is nothing “kid unfriendly” about the languages that I use for programming as an adult.  I think that in general when educating our kids, we need to stop coddling them so much.  Creating an approximation of an already dumbed down environment to write software to drive machines will not help them.  Most of the kids that I have seen are already beyond logo and they don’t even know it.  What they seem to want to do are real world things, and there is no reason they can’t.

What I settled on was to use Ruby for the tasks.  It is a language that has a great REPL, and is easier to read.  It also has the benefit of having a sane shell input mechanism as well as not requiring a ton of objects to get started.

We discussed what she wanted to do, there were several things, all of them were deeply social, but the one we settled on, I thought was the easiest to implement.  I thought that encrypting messages to her friend where only she and her friend had the crypt key would be enlightening.

She agreed, so we started into coding it up.  First we ended up working through a few encryption techniques on paper, taking short messages, converting them into their character codes and then shifting them by adding the char codes of each letter of the crypt key to each letter of the message.

def encode msg,key
	coded_msg = ""
	msg.each_char do |letter|
		coded_msg = coded_msg + add_cipher(key,letter)
	return coded_msg

def add_cipher cipher,letter
	code = ""
	cipher.each_char do |cl|
		code = code + pad(cl[0] + letter[0])
	return code

def pad num


   if length > 3 then
      padded_id='0' * (3-length)  + num.to_s
   return padded_id

At first, she put the crypt key into the program, but we discussed that it would be a bad idea since anyone with the source code could then crack the message.  She then asked me how her friend would decode the message.  I told her that the only way was for her to create a “pre-shared key,” something that she told her friend verbally that they would both have to remember, only then could that key be used to decrypt the messages.

What we did was to create a multi step command line program to accept the key and then the message.  We haven’t gotten around to the demux yet, but here is the mux:

print "Enter the crypto key, or die!: "
key = $stdin.gets.chomp

print "Tell me what to do ( 1 for encode, 2 for decode ): "
op = $stdin.gets.chomp

if(op.to_i == 1)
	print "Enter message to encode: "
	message = $stdin.gets.chomp
	coded_message = encode(message, key)
	print "Here is your message: \n"
	print coded_message


The nice thing about all of this is that the code is approachable, and the execution path makes sense… this happens, then this happens, etc… she can easily understand the flow of this program. We had significant problems with the flow of a client web application.

One of the first things that my daughter noticed was that whenever you make the crypt key longer, the message gets a bit longer, and that the encrypted message was many times longer than the original.  So it is working, not only is she understanding programming, but basic cryptography as well.  The only thing I am concerned about now is what happens when she is encrypting her posts on the social media site du jour at 16 with quantum encryption techniques.  How will I ever crack her codes?

Come Through Rails Back to PHP

Posted: November 17th, 2009 | Author: | Filed under: PHP, Programming, Rails, Ruby | No Comments »

I am struggling mightily with this one. I love ruby and rails, but more and more I am resenting the constraints of the controller architecture, the router, and activerecord, and I miss writing and tweaking raw SQL. This is not to say that I don’t love rails for quick and dirty stuff, and it has done wonders for writing MVC web applications, but I miss being able to break that pattern where it applies and being able to understand the result. I view rails just like I view Cocoa Bindings. I love the magic that they do, but there is a performance cost, and it is suboptimal for me to have little to no visibility into how they do what they do.

My friends who are really into rails tell me of course, you can use it without those modules, namely ActiveRecord, but if my problem is with ActiveController, and its routing magic, along with the conventions then what is the point. I was looking at MERB, but it is difficult to say what the result will be in rails 3. But almost no matter how I consider the outcome of that Merb will inevitably become more Rails like. I mean, rails is the 800 lbs gorilla in the web dev space, who would argue with Rails and win?

Well, there are plenty of examples of ugly PHP sites, and there are some examples of almost elegant code in PHP. Better yet, there is no magic, I can avoid heavy frameworks if I choose and still have my choice of easy deployment options with mod_php. The rails community keeps saying that hardware is cheap, and it is if you have money to begin with. If I need to deploy on a $30 / month host, it is very hard to deploy a rails app with a homegrown framework on rack. I am sure they exist, but PHP hosting has gotten so cheap as to almost be an afterthought.

Some of the PHP code that I have written recently is quite clean and readable. Its using classes and MVC to a degree, but I have objects that implement a hydration base class that allow them to persist their contents by overriding some simple parameterized SQL via PDO in the subclass. That is really all of the database abstraction that I need. If I want to persist objects, I’ll just save them to disk. Ruby’s marshal works just fine for that, so does PHP’s serialize / unserialize. If I want to use a relational database, I’ll write SQL and let it play to its strengths instead of pretending that it doesn’t exist.

The functional and library support that PHP has is unparalleled in the web dev community. I would have to agree with Rasmus Lerdorf that I like my SQL to look like SQL, my JavaScript to look like JavaScript, and my implementation language to look like my implementation language.

This is not an anti-framework rant, despite the way it sounds. I love Rails, Cake PHP, Groovy, Struts, etc… I think they are a great way to get a project going quickly or as a way to learn good web development processes, but I also think there is a time where you need performance and control, and this is it for me. I think most web developers should start by learning one of these frameworks. Once they can understand the tradeoffs you make when using them, it is probably time to leave. I don’t differentiate, I think that JavaScript frameworks are the same thing. They are awesome until you are performance bound, or you are trying to express a design that the frameworks either didn’t consider, don’t support, or don’t match the framework creator’s view of the world. That is fine, I don’t want for DHH to accept that there are times when convention over configuration is too cumbersome and the performance tradeoff isn’t worth the simplicity, or that some things are better expressed in a functional way instead of an OO way. For those projects, I just won’t use his framework.

There are totally justifiable situations in which Rails is the absolute best choice. I work in Rails every day at work and love it for that particular problem domain. I just have started realizing that I have been seeing the world as Rails shaped nails. There is no one language, framework, design pattern, or library that is the end-all-be-all method for solving problems. It takes good practices and pragmatic choices to choose the best tool or tools for the job. I was getting away from that, now I am coming back.

Bold Predictions About Rails

Posted: December 27th, 2008 | Author: | Filed under: Programming, Rails, Ruby, Uncategorized | Tags: , , | No Comments »

Bold Predictions About Rails

Picture of IrvinFor a couple of years now I have been very disparaging of Rails, and in general the whole convention driven development movement. I have always figured that maybe I could do things a little better myself perhaps. Recently, however I have found myself using rails, and in a larger sense, adding Ruby to my toolbox, and have been a much happier programmer.

What suprises me is how many excuses I found myself making about why I shouldn’t use Rails. What I eventually realized is that I didn’t care if I could write that CRUD code a little better, or if I could shave a tenth of a second of execution time from whatever function I had written in *name the language* the important thing was that I could get my project done and get outside, or work on several projects simultaneously, instead of only two. I found myself spending time and thought cycles on code that was directly related to solving my problem, instead of code to get me to where I could start solving my problem.

Now I am always suprised when I hear my same old excuses coming out of other good developers’ mouths. I want to say, “you just don’t understand.”

The reality of the situation is that the ground has shifted under our feet. Because of rails, business stakeholders are demanding quicker turnaround on features and products, and non-rails shops are struggling to keep up.

Performance is always the first crotchety old excuse, the answer is memcache. Then reliability, f5 big ip is the answer.

Really everyone, evolve or die, it’s as simple as that.