Ruby mentoring history

1016-12-26
,

Ruby > Ruby mentoring >

Table of Contents [hide]

Ruby 1.9 reasoning ∞

I originally began with 1.8.7. This was the most recent stable version, and the best documentation out there is for the 1.8 series.

However, I worried that if Ruby 2.0 came out, the transition from 1.8 => 2.0 would be very confusing to a new programmer. (See also Ruby 1.8 to 1.9 transition)

I considered 1.9 because I had heard the feature was pretty close to what 2.0 would become.

I worried that 1.9 may not be supported by various toolkits.

As it turns out, 1.9.2 was considered a stable release of the 1.9 series. I thought that all of 1.9 was unstable.

Also, I learned that many people had already been transitioning to 1.9 because 2.0 had been taken so long and there were features they needed.

What forced the switch was learning that the Shoes GUI toolkit required 1.9

What was initially downloaded on Windows:

History ∞

This is a rough list, from oldest to newest, of the things that we discussed or tried. Notice how different this looks from tutorials!

The programming begins:

  • displaying text
  • delaying – sleep
  • pausing after a script is run
  • getting input
  • comments – and comment-based bullet-points to get ideas down, and programming based on those ideas.
  • comment-blocks with =begin and =end
  • variables
  • quoting – " '
  • using irb
  • running a script in irb (unknown)
  • arithmetic
  • “arithmetic” with strings
  • conditionals ( if / then / else )
  • variables within strings #{var}
  • converting between strings and integers .to_i .to_s
  • methods – re-using code.
  • floats
  • arithmetic with floats
  • scope and global variables
  • object class

  • how to present a good bug report or explain something you want to learn

# I do this
# I get this
# I expect this
  • case
  • conditionals ( if / then / else ) with simple Regular expressions
  • learning the platform ruby is running on
  • learning the version of ruby the script is being executed with

  • cross-platform methods

  • Putting methods in another text file, and including it with require.
  • Make a simple batch file (Windows) to allow a command prompt to be opened at that particular directory.
  • Making a simple cross-platform program that clears the screen.
  • Some early experimentation with OCRA worked ok, but there are some problems with libraries not being seen when the executable is moved. This is an issue with the require that we use.
  • Passing a variable to a method. (var)
  • Passing multiple variables to a method. (var1, var2)
  • Passing any number of variables to a method (*var)

  • Understanding scope better – variables assigned and used in a method are totally separate from variables outside of that method.

    • This is a challenging thing to understand.

  • Briefly showing some odd variable assignments: a,b=1,2 and a=b=1

    • I shouldn’t have done this, to keep things simple.

  • Arrays – a=["one","two"] and a[0]

  • multi-line variables
  • do loop
  • reading and writing files
  • .each
  • .each_char
  • Made a cross-platform method which will get a keystroke from the keyboard.
  • print vs puts
  • a text-tileset program. It can read ascii art from a text file and output it intelligently in various forms. Spreadsheet-format, coordinates as well as character translation (e.g. ‘X’ becomes ‘x’)
  • debugging, simplifying and relying on modules. We went through some hell because the program was just way too complex for us to really figure out, and odd bugs were appearing.
  • checking out Ogre.rb, rubygame and their dependency hell. This was a REALLY terrible experience.

  • settled on Gosu.

  • Working with gosu, creating a playing field that’s generated by a text file.

  • A user-controlled character

2010-10-13 ∞

He’s been playing on his own and has progressed in leaps and bounds. A friend of his knows Ruby and helped with something we were both stuck on. I was going to do a bit of research today but I ended up being bogged down with a system overhaul. See 2010-11-10 Linux testing nightmare for some of that.

For the last while, he’s been doing his own artwork. Nice, and we should also have our eyes open for free sources for sounds, music and art.

  • working with random numbers

  • Better planning

  • Using methods, breaking down ideas

  • 2d arrays

  • Teaching me more about classes

  • Collision detection. It’s half working and is acting odd.

  • Zombies, AI interaction, a bit on pathing

  • Solving limitations through workaround hackery. I’m not sure how to describe this.

    • So there was a serious speed limit with having too many zombies all chasing after the player. They each were operating 60 times a second and it was bogging down his computer. Various solutions were explored. Turning down the update timing in gosu seemed to make things choppy. Building a special exception to update the zombies only 30 times a second didn’t seem to help. One idea was to only make them wake up inside of a certain range and chase the player inside of a slightly larger range. While this works it’s not optimal. We’re definitely exposed a limitation in our underlying use of gosu or perhaps even in gosu itself (but I doubt that).

  • Learning how planning and the underlying structure of a programming can back us into a wall and limit our options. Learning how good and modular programming can allow us to drop in new code or play with ideas very easily.

  • Optimizing and rearranging code. How create many methods that carve things up into “ideas” that each cover one very small thing.

  • Developing with geany, press F5 to run the script. Wow, he already figured that out.. did I mention this before?

    • He’s developed preferences for syntax highlighting in one editor versus another. Isn’t it annoying how different editors can sport wildly different and equally important features.. and juggling two editors becomes oh so tempting.

2010-11-30 ∞

Although we’ve met a few times, my compiled website was broken and during that time I didn’t really get into writing notes. Our main games project has progressed spectacularly, and my mentee has developed nicely into a paired programming partner. His skill has surpassed me in areas, he can fit large chunks of his pet project in his mind and understands things clearly. He lacks breadth in his skills, polish and a real knack for looking up and using new (to him) features new libraries. Good research skills will definitely be high priority.

  • The challenge of taking breaks

    • Visiting old code, keeping skills sharp.

  • hacker subculture

  • Mythryl, compiled and scripted languages, research languages, thoughts on being a polyglot and the value of portable programming skills.

  • more on the value of optimizing code

    • talking about c++ libraries used by scripting languages
    • talking about a developer also using a “better” language for the slow parts of their own projects. Things like Ruby using an OpenGL library written in (probably) c++. This is similar to both optimizing ones own code and to offloading the responsibility of programming certain boring parts to other projects. It’s much more fun to just grab all kinds of pieces that have been programmed “out there” and assemble it onesself and have ones own core programming project be about developing ones ideas without the need to develop all the libraries and scaffolding necessary to bring ones ideas to life in the first place.
  • Talking about the “80% finished” idea a bit (a bit more, did I already touch on this?). Hackers work on the fun 80% that solves their problem / scratches their itch. Then they hummingbird over to a new interesting project. And another. And another.
  • Scripting vs c++ vs assembly language vs machine language. Talking about how ones and zeros were used by the geniuses of the past (whose names I don’t even know!) to create the assembly languages that were used to develop c++ (by the grey-beards of today). Talking about self-hosting programming languages.
  • An explanation of why a “c++ killer” isn’t coming any day soon. It’s really the same explanation as why a natural language like English isn’t going to be killed by a planned language any day soon.

  • How did my compiled website break? Well it was because trailing spaces were being stripped? How could that matter? Going into regular expressions with some simple-ish code. (ok how else was I going to broach that topic?, heh).

    • /regex/ vs %r{regex}. How I use %r{regex}x and break a regex into a variable that’s on multiple lines. How an escaped space as the last item on a line will have its space stripped and can pretty much break reality.

We did no programming today, but he recognized the value of talking shop in general, going over theory, exploring ideas etc. Well I’m not even sure I can keep up with this guy for much longer.

I was considering ruling on the need to have a portion of time spent on theory and the “soft” or otherwise ineffable skills brought on by pure research, philosophy, theory etc. But he has already picked up on that.

Although there is a huge library of functionality he has not learned yet (and a sizable amount that I haven’t learned yet!), the step from programming-as-laying-brick to programming-as-art isn’t as far away as I may have thought. I just have to patiently toss out breadcrumbs of theory, best practices and subculture in the midst of the flurry of learning basic features to solve existing problems.

*- diffs, and the value of revision control

2011-02-23 ∞

After a long break that I needed, we spent some time chatting.

2011-02-25 ∞

  • versioning systems

Ideas ∞

See Ruby mentoring program ideas.

  • ensure, and pausing
  • better file sharing / hosting.
  • Look at my more complex platform detection code? it’s in ruby_notes.rb

  • Check out some GUI toolkits

  • Check out some multimedia development frameworks

  • Ruby testing? (check into my old projects..)

Questions and research ∞

Footnotes


  1. was https://ruby-doc.org/core/ [ ↩ ]
Comment

Leave a Reply

Your email address will not be published. Required fields are marked *