Disqus - Latest Comments for blinks

Re: The Last Starfighter

blinks — Wed, 14 Jan 2009 15:03:23 -0000

I think we did. :) The QS developer works here now, and this is his project, IIRC.

Re: Shaman (alpha): Request for Playtesting and Feedback

blinks — Thu, 08 Jan 2009 14:40:56 -0000

Being the crazy developer person I am, I'm keeping all the materials for this game in a Git repository: http://github.com/blinks/shaman -> that link will always have the most current version of the rules.

Re: Cauldron

blinks — Tue, 30 Dec 2008 16:34:00 -0000

Turns out that AppEngine has some limitations that make writing and ranking full-text search less than useful. I'll be rewriting in Django -- this site is on Pylons.

Re: The Last Starfighter

blinks — Wed, 24 Dec 2008 15:13:40 -0000

Hmm. Not that I know of -- crazy to hear of another clan of Blinkinsops, though.

Re: The Last Starfighter

blinks — Tue, 23 Dec 2008 21:24:07 -0000

I don't think there's any weather information there, but if you were pulling the RSS feed, you could use it to create a mashup map of traffic incidents, and that, by itself, is very cool.

Re: The Last Starfighter

blinks — Tue, 04 Nov 2008 10:13:10 -0000

Awesome. Sounds like he'll be joining the ranks of the Pythonistas relatively soon.

Re: The Last Starfighter

et764 — Tue, 04 Nov 2008 01:34:15 -0000

I think for where he's at now, that would be information overload. However, I think you're right, I need to keep his end goal in mind. I've kind of been pursuing two milestones so far. The first is teaching him enough that he can understand and write a fractal like Koch's Snowflake or the Hilbert Dragon (I think those are the names anyway. The second is going down the text processing route, suitable for building dynamic web pages. I think the first is better for someone pursuing computer science, since it gives you a good grasp on recursion, but the second seems like it will be more useful to my friend in the long run, and probably more interesting. I think project management principles are important, but teaching them at this point would be like teaching someone how to draw up floor plans and get a building permit when they don't even know how to use a saw.

We had our first meeting tonight, and it seems like it went pretty well. He was sort of getting sucked into what he was working on, and he sounded genuinely excited, which I think is important. I covered os.system, so he can now write all the .BAT files he's ever written in Python instead. Then we got into turtle graphics. He started trying to write a program that would draw his son's name. I think it will take him a while (he got the first two out of five letter done tonight). His son's name is Corbin, so he drew a C, and then started working on the o. The o was basically a rectangle, so I showed him how to make a for loop, which made the rectangle take three lines of code instead of 8. Finally, we briefly covered variables, the input function, and how to concatenate strings. We spent only a couple minutes on it. I meant for it more as a "If you get bored of forward, left, right, backwards, pen up, pen down, you can start playing with this." I also showed him a Koch snowflake script I wrote and a script that prompts for a number, n, and then draws a regular n-gon. Anyway, we briefly covered enough that he could write a regular n-gon program if he wanted, though it will probably still take a lot of work for him the figure it out.

He looked pretty excited about everything. Even though turtle graphics are pretty basic, it gives you probably the most bang for the buck as far as quickly giving someone a set of blocks to play with and experiment with. He seems pretty excited about figuring out what pictures he can draw, and it's good practice for decomposing big problems (How do I draw a C?) into manageable parts (Go up, up, right, down, up, left, down, down, down, down, right, up). I'm excited to see what he comes up with before next time.

I'm kind of thinking a good next step will be mad libs. Start out by writing a program to prompt the user for each word ("Verb? Verb? Noun? Adjective? Plural noun?"), and then substitute those into the write part of the mad lib. Eventually you could build up to making a simple markup language ("The $(adjective) $(animal) jumped over the $(adjective) $(animal)."), writing a program to parse the strings out, prompt the user for the correct blanks, and then performing the appropriate substitutions. Eventually, you could make this a dynamic web page that builds a form that asks for all the information, then renders a mad lib for you.

Anyway, we're definitely starting from pretty much 0 at this point. He has written a couple of .BAT files, but they usually just do something like mapping a network drive. His HTML experience consists of "Save as HTML" in Microsoft Word. From my experience working on my church's web site, and mentoring a newbie developer there who even had some Java, C#, HTML, and CSS experience, a full blown web framework and source control can be a lot to take in at once. I definitely like the idea of building from the bottom up, but we need to start with smaller blocks in this case.

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 22:10:54 -0000

I think that if he's interested in admin tasks and dynamic web pages, you might have him start with something like Django, TurboGears, or Pylons -- get something up and running right away. This will, of course, need him to have a goal in mind for the pages he wants to write. Make sure that his goal isn't too complicated. Something simple (that ideally has him pulling information off the server box -- perhaps a remote process list?) that requires very little would be best.

That's my thought: find a simple web app, work with him to implement it with a framework. (Perhaps even App Engine -- sign-ups are free now.) The important part here is to teach good project management principles; unit testing, source control, automation, etc. Build things from the bottom-up, learning as you go.

Does that sound like it would be good?

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 18:37:49 -0000

Yeah, I've looked at doing some Python games before, but Pygame and Pyglet have more overhead than I want. One of these days, I'd like to make a simple tile-based sprite engine, so I can just say give me a 20x10 grid of 32x32 pixel tiles and let me create little creatures that walk around in them. That'd be really useful if you wanted to throw together a quick computerized Robo Rally or something like that.

I was thinking about this a while ago, how now there is Visual Studio Express and all kinds of awesome development tools available for free, which seems like if I were growing up again I'd be able to program a lot bigger things on my own. The thing is, the overhead to start hacking is a lot higher now. In a way, it sort of feels like I grew up with the development tools.

Anyway, Python has a built in turtle graphics module, so I think I'll probably start with that. Maybe start with Hello World, then do some cool turtle designs. I'll probably introduce os.system fairly early too. He says he wants to learn programming, but the applications he has in mind are things like scripting system admin tasks and building dynamic web pages.

What do you think would be a good set of topics, in what order, and some good exercises to practice each topic?

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 17:01:32 -0000

I think that time-to-cool (how long does it take to get something interesting running?) is definitely the most important metric for learning a language. Figure out what he's interested in, and figure out the "hello world" of that class of applications. It's a shame that writing games has so much more overhead now than it did when we were in school, or that'd continue to be the best way to do things.

Perhaps it's not so bad, but Pygame and Pyglet take way too much work, imho.

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 16:57:06 -0000

Way for me to not proofread my comments. I meant a series of programming _lessons_. Not languages. The languages I'll be using is Python. I just opened up SICP, it looks like that might be a lot of what I need.

Basically, I don't want to dive straight into deeper things like data structures and Big-O notation. I want a quick and dirty way to get your hands dirty. I'm remembering how I learned to program (and I think you followed a similar path). I started by typing random stuff into QBasic until it finally capitalized one of the words, meaning I'd guessed a key word. From then on, I read a bunch of the help files and started writing my own text-based Final Fantasy clones. Eventually I also started hacking Nibbles and Gorillas and stuff like that, and finally this evolved into Space Wars. and on into binary trees, object oriented programming, 3d graphics, etc.

Anyway, I've decided I completely reject the idea that you need to dive first into Java and Object Oriented programming. Not even seasoned software engineers care about UML diagrams, let alone someone who's never written a line of code in their life. I think a good place to start is something where you start typing instructions into computers and in 20 seconds you can say "Look at what I made the computer do!" In other words, if "Hello, World!" takes more than one line of code, the language isn't a good teaching language. I think this rules out most things, except for QBasic, Python, Ruby, and Perl. I like Python, since it's a clean language with low initial overhead, but it also scales up to object oriented and functional programming too. Ruby probably does about the same, but I haven't gotten around to becoming fluent in Ruby yet.

I think a good test for an initial programming exercise is the wife/four year old test. After our first lesson, will my friend be able to take something home to his wife or four year old (who has played WoW since he was three...) and have them be excited about what he's learned how to do.

I'm thinking Turtle graphics is a good starting point. I really want to pull in recursion and fractals, but I think that should wait a while.

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 16:42:33 -0000

Eric, if you could expand on this a bit, that'd be good. Do you mean an actual series of languages, or perhaps subsets of an existing language, or series of programming problems?

As to the series of languages, what about SICP?

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 16:40:59 -0000

(see http://adam.blinkinblogs.net/post/57791370/supp...)

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 16:34:11 -0000

Hey, on yet another topic, I'm going to start teaching a friend of mine how to program Python. He's an IT admin type guy whose company just got bought up, so he knows he's going to be laid off soon. Anyway, he figures since he's going to have lots of free time and that these jobs are more and more requiring scripting skills, he should learn to program.

Suppose you were building a series of programming languages for people that are somewhat computer savvy but have absolutely no prior programming experience. How would you approach it?

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 15:29:46 -0000

The other nice thing about knowing the difference is being able to tailor your grammar to the type of parser generator you're using.

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 15:22:48 -0000

Thanks, that makes sense. I never much cared about the difference between top-down and bottom up parsers. I just plugged my grammar into a parser generator and let that take care of it for me. It's good to at least understand it well enough to answer the question right :)

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 14:05:27 -0000

It does. It's pretty easy to reason about them when you remember that the top-down parsers need to break productions apart, while bottom-up parsers need to put them together.

When several productions have the same left-most symbol, a top-down parser doesn't know how to break that production apart without quite a bit of look-ahead, so it has trouble. With left-recursion, it's much harder to determine when to group symbols into a production, so bottom-up parsers have more trouble.

Recursion:
* list := epsilon | list element (left recursion)
* list := epsilon | element list (right recursion)

In the first, bottom-up parsers can never be sure when to collapse into a list without look-ahead, because it depends on whether the next token is an element or not. In the second, it can collapse for each element and be fine, because list can always end up being epsilon. This is how I think of it, anyway; I could be way off.

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 13:48:44 -0000

Decent. I never was very good at studying, so I'm running out of time to do much good. I finally got around to seeing which questions I missed on my practice test last night. It looks like I will get the most points by reading more carefully, and by reviewing my graph theory. A lot of times I answered the opposite of what the question was asking. Graph theory makes sense, since my pretty much hated that class. I didn't much care for the professor, which is sad, because graph theory should be really cool.

I brushed up on some terminology, like top-down vs bottom-up parsers, and recursive languages (Apparently recursive languages are just a synonym for decidable languages, but I was only familiar with the decidable term).

Just to make sure I got it right, in general, top-down parsers don't do well with grammars where there are several productions that have the same left-most symbol, and bottom-up parsers don't handle left recursion well. Does that seem about right?

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 12:43:13 -0000

How's studying going for the GRE?

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 12:35:29 -0000

If striking down unconstitutional laws and nullifying stupid ones makes you an activist judge, more power to you!

Re: The Last Starfighter

blinks — Mon, 03 Nov 2008 10:45:45 -0000

Sweet. Warning, though: I'd be an activist judge, all about the jury nullification. :)

Re: The Last Starfighter

et764 — Mon, 03 Nov 2008 02:49:28 -0000

I filled out my ballot tonight, and I think I'm going to take it by one of the drop off places instead of mailing it, since one is just down the road from me. That way I don't have to trust the post office to handle my ballot correctly, I just have to trust the rest of the people involved.

I decided to throw my vote away in style by voting for Bob Barr. Also, I voted for you for one of the judge positions. I have a rule where I always vote against people who are running unopposed, and most of the judges had just one person running.

Re: The Last Starfighter

blinks — Sun, 02 Nov 2008 11:47:07 -0000

Speaking of ideology: have you voted yet? Got to get absentee ballots postmarked by Tuesday, and all that.

Re: Abstract Source Control

blinks — Sat, 11 Oct 2008 10:35:37 -0000

The other thing to think about here is how distributed source control systems like Git and Mercurial work -- every time someone clones a repository, they're branching off of it. Every separate repository is a branch, and every push or pull (in Mercurial terms, at least) is a merge. Would that be an acceptable "psc branch" command? (I like the name!)

Re: Abstract Source Control

et764 — Sat, 11 Oct 2008 03:23:56 -0000

They should be different because we don't perceive time the way we perceive space. Sure, you make some nifty physics equations by treating time as just another dimension, along with length, width and height, but trying to visualize something like a rotation around the time axis makes almost no sense.

If you view source control as a directed acyclic graph, like Mercurial does, then I'd agree that branches and copies are both instances of one node having two children. The difference is that a traditional branch is a diverging timeline, but a copy is a diverging "spaceline." In a copy, you're branching in space rather than time, in that now you have two different coordinates within the file namespace that have the same parent node.

Another difference is that you traditionally branch a whole repository, while you'll only copy particular files or perhaps directories within a single repository. In general, I think this is a natural distinction to make, although it may not be universally true. For example, there have been times when I've wanted to spin a certain directory off into its own repository, which is less than intuitive in the source control systems I'm aware of.

I suppose you could resolve this by just viewing a branch as splitting the timeline at the root directory, while a copy is usually splitting at a subdirectory or file somewhere. Then the end result is you basically have a root directory with a bunch of named directories that are the different branches, somewhat like a Subversion repository is laid out. Maybe you've convinced me that branches and copies should be treated the same. I'd still like a "psc (platonic source control) branch" command in addition to the "psc copy" command.