seriously, though, awesome!

I saw your presentation on Ruby-USB at confreaks and it was very helpful. I am actually trying to do something with RubyUSN and running into trouble. I thought I could post a comment here and if you have any insights, it would help. (My apologies for posting the comment on a totally unrelated post)

I installed the Ruby-USB gem in Windows and then tried to use IRB to see if I can detect USB devices on my syste. I tried the following -
require ‘USB’
USB.devices

This always returned [], even though there are devices present. Any clue why it is not listing the devices?

Thanks for your help and good luck with your PhD

Now that I’m a RealDeveloper ™ I would be much more likely to go all the way through the tutorial… (just having documentation is a pretty awesome thing), so with experience I would definitely go through the tutorial…

I totally sympathize with your point; I’ve debated this myself, and decided to not require it for reasons Pro2 (plus a bit of Pro1 and Pro3). I’m a bit worried about 1, but it’s unclear if the students who succumb to 1 will do more than the bare minimum of any assignment we give. In the end, I will probably add something required if it becomes apparent folks haven’t done it. But, I want students to view this as a senior seminar, not a “class where I’ll be spoon-fed.”

In the other class I’m using Unity in, we had a simple warmup (do some modifications of Unity).

Once we get the Android environment set up, we will assign something trivial so everyone builds something. That will help. But, in the end, I will largely judge people by the overall success of their project, combined with what their teammates say their contributions are (perhaps I need to make this clearer?) so that folks will need to contributed. I anticipate giving A’s, B’s and some C’s, but hopefully nobody in the class will earn F’s (perhaps I need to make this clearer, too?).

* Tailing the newest log file.

* Comparing traffic patterns in log files to find unusual behavior.

* Select a set of files that have a name that matches a regular expression and/or have content that matches a regular expression, potentially unzipping that file if it is compressed.

* Once you have a set of files to operate on, you can mark them as “needing to be edited” if you have a source code control system that requires that .

* You can do a search and replace across that sub-set of files.

* Rename/move a set of files based on content of that file or the name of the file (like if you want to go to a “flat” directory structure).

* Automate all sorts of things. For example:

** When I checkout my source code with `git` I also want to set-up a symlink so my repository is viable via gitweb.

** Easily switch between directories using pushd and a macro that I call `sd` for “switch directory”.

Ultimately, I think the most powerful paradigm is a GUI that can be controlled via a macro language, and a status bar that shows you what you commands the GUI is sending so that you can easily automate stuff.

Another reason I like the command line is that no matter what computer I login to, I can have all my personal preferences set-up via `eval “$(curl -L http://brimworks.com/h)”` (WARNING: that command may overwrite your preferences!). Also, the command line allows you to manipulate remote machines without requiring a console nor does it require a “big pipe” (although latency certain makes the CLI experience less than fun).

I should also mention that `screen` is one of the best things in the world . I’ve had screen sessions last through several laptop crashes.

Cheers,
-Brian

Overall I think the reprise unix session turned out not quite as good as the original. Problems:

a. Much lower turnout. Talking with the students it seemed not everyone was monitoring the seminar board so no everyone saw my “2nd unix seminar” on there. I already disappointed a few students who approached me and asked about a seminar after it was already done.

What I should have done was asked in seminar “Hey, how about we do this *Tuesday*. Is everybody cool with that?” But I wasn’t sure I could say that…dumb…

Anywhoo this lead to less energy in the room.

b. With so few students I put them on the same team: mistake…that was a team of 6 which was too large given that they were placed along the wall (by the computers). In a corner…but still communication between 6 and 1 was really not possible. I think this made the team seem less close so there was less sharing of ideas.

c. I also maybe didn’t pay as close attention some of the quieter students who just would look stuff up but not talk and share. These folks lost out because they didn’t the benefit of what others had found and they didn’t share either. When I was working with the group this wasn’t as obvious (I had many loud students clamoring for my attention) but I think the problem was still there. Need to keep a closer eye, basically, not let people fall by the wayside.

That said the whole process was very good. I’m quite happy with how this turned out and with the enthusiasm of the students.

Regarding your bash/zsh requirement: this is sensible, since these are the two main feature-packed shells. However your note calls out ksh, which for programming looks fairly bash-ish, when csh/tcsh are the real problem. They act so totally different from normal Bourne-ish shells that you can’t even write portable code for a common minimal set of features. Since assuming a plain Bourne shell (“/bin/sh”) is the safest route to shell script portability, there is no good reason to learn or use csh.

Something that teaches them about “sort -n” would be good; this seems to stump people with numeric data. You could also couple it to Ben’s suggestion of “sort | uniq -c” in order to put the histogram in order of prevalence.

Pulling a column out of a text file or pipe also is a useful skill. Depending on whether you want to push “cut”, “awk”, or something else, you can (weakly) build on the previous example: “… | sort | uniq -c | sort -n | awk ‘{print $2}’.

Teaching the basics of “find” also would be valuable. It’s not the most intuitive command, IMO, especially if you are coming from a non-unix background. A good concrete example could be that you want to delete all “.o” files in a recursive build: “find . -name ‘*.o’ | xargs -n 1 rm”.