A source of happiness

Recent developments by Aady and Rick, who were working this weekend on reverse engineering the servers that ran Silencer resulted in a played game by Rick (who dropped), DarkProdigy, and me. This game was one of my favorite games years ago, but got shutdown when WON.net shutdown. Being able to play a game, even if it was hosted by someone on dial-up, has made my weekend. See Arsia-Mons forums for more.

On advertising and Internets

Slashdot had an article titled "The Morality of Web Advertisement Blocking" posted today. In essence, it was a followup to another Slashdot article talking about how some websites were blocking Firefox users from visiting their site, due to the seemingly common use of the Adblock Plus plugin. The question posed was:

Whereas TiVo users freeload on the relatively fixed broadcasting costs paid by TV networks, users of web ad-blocking technology are actively denying website owners revenue that would otherwise go to pay for the bandwidth costs of serving up those web pages. If the website designer has to pay for bits each time you view their website without viewing their banner ads, are you engaged in theft? Is this right?

The response was probably all to expected; most people shot down the idea of comparing web advertising to television advertising for one reason or another. There were a few people who seemed to seriously consider the question, but the majority of the crowd seemed to learn towards the attitude of "I download what I want." I can't say I entirely agree, but I definitely think the "why is Firefox blocked" website is retarded. At best, I think most websites that use "myth" or "cult" in a demeaning way tend to be FUD. I mean really. The Firefox cult? We worship the Firefox god, lord of all the Internet.

Many people seemed to think that advertisers have no business on websites that they visit, since it's their bandwidth, and they should do what they want with it. In some cases, I think this is a reasonable argument; for example, when viewing sites from a mobile phone, having advertisements seems typical unreasonable. Do they really have a right to complain if they're on a cable line, or something like it? I don't really think so. Ads might "take more bandwidth," but this argument is ridiculous for, say, AdSense ads, which are simply text.

Others say that advertising online is a flawed business model, since you're requesting all of the information you want, as opposed to TV, where you get what you get. This seems like kind of a lame reason, but I have no real marketing background. A lot of big sites seem to advertising (Engadget, for example...and Google) as a source of revenue. To claim that this isn't a legitimate business model is basically saying that many of these sites shouldn't exist. Can you imagine what the Internet would be without Google? They've been around long enough that I can't really remember what the Internet was like back then, except the whole frames, animated GIFs, etc.

There are other interesting posts, but I'm not really here to rip on people for disliking ads. Heck, I dislike ads. Only a weirdo would like ads. I still don't use an ad blocker, though. I actually had a conversation with a friend last night about it:

Not Me (8:25:56 PM): whoa, an ad in my firefox
Me (8:26:03 PM): ruh roh
Not Me (8:26:06 PM): that was actually fairly startling :O
Me (8:26:54 PM): I don't actually use an adblocker heh
Not Me (8:27:15 PM): que?
Me (8:27:30 PM): I see ads quite often in firefox
Not Me (8:27:52 PM): why no blocker
Me (8:28:00 PM): lazy
Me (8:28:03 PM): I don't really use plugins
Not Me (8:28:33 PM): :D
Not Me (8:28:46 PM): adblock plus updates its own blacklists and everything
Not Me (8:28:52 PM): literally like 3 clicks and you're done forever :I
Me (8:29:01 PM): I know
Not Me (8:29:04 PM): i haven't even thought about it in months
Me (8:29:04 PM): that's the sad part of it all
Not Me (8:29:04 PM): kay
Not Me (8:29:06 PM): lol
Not Me (8:29:16 PM): if i were near you i'd come to your house and do it for you
Not Me (8:29:20 PM): because that's just pathetic :-(

Yeah, the secret's out. I'm really, really lazy. Okay, that wasn't really a secret. Also, that conversation has practically nothing to do with anything, I just wanted to say that I don't use an ad blocker. As far as text ads go, I don't really mind them. I've actually seen interesting AdSense ads (okay, maybe once...maybe). I don't think anyone has a right to complain about non-intrusive, text-only ads. You can pretty much ignore them; I can usually just skip right through them, even if they're in the middle of a page. They don't really take up much bandwidth, and Google seems to be better at relevance than most people.

The real culprit here, in my opinion, is the evolution of advertising in the past few years. Starting with those pesky "Warning! Your computer is broadcasting an Internet IP Address!" ads, things spiraled downhill very quickly (Congratulations. You've just been selected to win two free Apple iButts). Then came the flashy, annoying, animated GIFs, which evolved into Flash advertisements, and then Slashdot had a post talking about Java advertisements. Seriously? Java? I should just uninstall it right now. I hate Java. If it's used for ads, I hate it even more. Obviously they're simply trying to get your attention, but really, this could be harmful for site traffic. My process of visiting a site with flashy advertisements is something like this:

1. Visit site, probably to read some article.
2. Start reading arti—why hello there, annoying advertisement with a flashing background that's enough to send a person into seizures.
3. Well, I can concentrate on reading, right? Here we g—what the hell.
4. Close tab/window.

If a website wants this kind of traffic, purely for generating revenue, they don't deserve to exist. Web administrators need to realize that to keep their content readable, they need ads that don't suck. Yeah, it probably means generating less revenue per view, but at least you stay relevant. Users don't feel like shooting themselves after visiting your site. Unfortunately, instead of being reasonable, I guess a handful of webmasters decided to "ban Firefox" instead. Yeah, right. Ban Firefox? What a joke. The only point you're making is that you're a jerkoff, being completely inconsiderate of people who use Firefox without an ad blocker. Apparently we're just a statistic, and since they're losing so much money, they figured it's just best to kill us all.

So now we've traced the blame from the ad blockers, to the ad-laden website owners. Of course, it doesn't stop there. What's with the ad companies producing these wacked up ads that they must know just annoy the crap out of everyone? Yeah, they're trying to get our attention, but in what feels like the worst ways possible. Unfortunately, even Google seems to be moving in the direction of video ads. Sounds totally evil, but I can only hope their implementation is better than it sounds. If not, I'll just have to quit the Internet.

But these crazy ads must work on some people—obviously not tech nerds like us, but believe it or not, "less intelligent" people do exist! Or maybe it isn't that they're dumb. Maybe they're just heavily invested into materialism.

If you've never read Feed (Slashdot review), I highly recommend it. I read this for ENGL106, and it's probably the one thing I really enjoyed doing in that class (thanks to Jennifer Eason for having us read it). Essentially, to copy Wikipedian vocabulary, it's a dystopian novel about corporations, consumerism, and computer technology. It's kind of scary how it seems like advertising is heading in that direction. The premise behind the novel is basically that ads become completely integrated with people's lives. People get flooded with ads whenever they go places. I don't want to spoil it too much, but if you have no intention of ever reading the book, the Wikipedia article seems to do a decent summary. You think ads are bad now? I bet it'll only get worse.

Pythonic programming and the "self" keyword

Bruce Eckel recently posted an article which expressed seeming disappointment in the direction Python 3000 was heading. Particularly, he seemed to think the grandeur of a four digit version name was too much for what new things Python 3.0 will bring about. I can't really say that I care about some of his points (the GIL argument is one that's popped up on Reddit several times in the past few days), and obviously I only care to comment on one topic: the self keyword in Python. In his original post, he says the following:

This is something I really hoped to see in Python 3K, but the beloved self seems to be hanging on.

self is inappropriate noise in a language that lays claim to clarity and simplicity. No other mainstream OO language requires it everywhere like Python does, and it's a hurdle for people who try to come to Python from those languages. Maybe it's a significant reason that Java programmers seem to be more comfortable with Ruby; Ruby takes care of it for you just like C++ and Java do.

And posts later in a reply:

Exactly, and it's not the writing but the reading. Python generally makes code that's easier to read, but 'self' is an intrusion.

And parroting "explicit is better than implicit" is a misuse of that maxim. All languages provide abstractions; Python (generally) produces clear abstractions that tell you what's going on -- these abstractions are explicit in "the right places." But 'self' is something we don't need to see inside classes. You're in a class, so 'self' or 'this' can be implied, just as it is in every other OO language I know of. Ruby, I think, has it right on this one.

Some of you who have really long memories or have too much spare time on your hands would remember that I actually mentioned this topic in a blog post a long time ago. Obviously, with that mentioned, I disagree on both counts with Bruce's reasoning.

To begin with, I wonder just how much of a hurdle learning Python is because of a required self for referencing instance members. While they may not be required in other languages, they most certainly exist, usually in the form of this rather than self. Is requiring self really a hurdle? In terms of using it inside method bodies, I don't think it's a very big deal. Specifying that a variable belongs to an object makes it more clear as to what's going on, especially in a dynamic language where variable declarations don't exist. Even Ruby, as mentioned in the thread, uses @ as a scope resolution operator.

Bruce also argues that the "explicit is better than implicit" maxim is wrongly cited as a reason here, claiming that implicitness improves readability. I definitely don't agree here, either. In C++, Java, and C# (and probably more?), classes are well defined with what members they have, so implicitness works fine. In Python, since you don't really have instance variable declarations, being implicit seems like a bad idea. If you're maintaining someone else's code, you'd have to make sure all of your local variables weren't actually instance variables, lest ye overwrite them and screw something up. GvR's response also indicates a technical challenge in removing the required self.

Brandon Corfman also responded, saying:

The problem is that the 'self' plague doesn't stop there ... don't forget that self is required as the first parameter of every class method. For example, the following code that forgets to use self as the first parameter of printInfo:

class MyClass(object):
    def printInfo(s):
        print s
   
def main():
    m = MyClass()
    m.printInfo('Hello')

When running main, you get the following traceback from Python:

Traceback (most recent call last):
  File "", line 1, in 
  File "hello.py", line 7, in main
    m.printString('Hello')
TypeError: printString() takes exactly 1 argument (2 given)

Except I am giving one argument! What second one is it talking about? Oh yes, the interpreter is expecting 'self'. Totally confusing and brain-dead requirement. Why does this need to be the first parameter of every class method?

I think explicitly using self as the first argument is a good idea, to some extent. It's kind of quirky (I'm pretty sure you can name it whatever you want, and it would still work), but having self be in the parameter list shows C programmers (and other, maybe more inexperienced OO programmers) how instance methods basically work. They aren't some voodoo magic higgity biggity, they really just pass the object as an invisible first argument to the method. In the above case, m.printInfo() is really just shorthand for MyClass.printInfo(m). Python's explicit requirement of self as the first argument makes it so that it's clear to people what the difference between instance and static methods are (even though they're different in Python than Java, et al). The exception message is still kind of confusing until they make the revelation of that m is basically the first argument, but this concept is probably something most programmers who deal with OO should know.

The Scheming senior

Life has been busy once more, since school started. For some reason, I thought it would be a good idea to take three CS classes (software engineering, programming languages, and cryptography) as well as music theory. Music theory appears to have homework due every class, which sucks, even though it's pretty easy so far. In addition, being a senior now, I have to start worrying about what direction I want my life to go in next year. Of course, being me, I'm still rather indecisive over graduate school versus industry.

Research, to be honest, is so far basically what I made it out to be—boring. It didn't help that I picked a topic that I wasn't particularly interested in, but I'm doing my best to stay interested. Professor Mathur seems to be very passionate about what he does, which helps my motivation a bit. Even though it's not that exciting (calling it flat out boring is also an exaggeration), I guess this is a good experience for me to actually have a mentor that's been in the field for years. Hopefully I can get the motivation to finish this research project and publish a paper at the end of the semester, which would look nice on a resume for grad school. Weekly meetings should boost my motivation, at least a little bit.

Classes are kind of "meh" right now. Software engineering is definitely a lot less exciting than I thought it would be, and kind of wish I had taken something else instead. The project is some sort of grunt work from HP that has to do with finance. It definitely sucks compared to the project binder that we saw, which was a game of some sorts. From what the programming languages book is saying, the class will get more interesting as time goes on, but the current chapters are boring. Cryptography is pretty interesting; it's probably the most interesting thing right now. Music theory hasn't gotten past playing scales, so it's not very exciting. Playing on the keyboards on Friday is kind of fun despite the simplicity, since I haven't played piano in about seven years now.

Perhaps the most interesting thing that has happened lately (at least to me) is the arrival of my latest shipment from Amazon, consisting of:

• The Little Schemer, 4th ed.
• Serenity, Collectors Edition
• The Design of Sites

The Design of Sites is more to get some inspiration for web design, since I clearly suck at it. I guess this is necessary, since the web is the wave of the future. Or whatever. It seems to be very illustrated, but I haven't really looked too carefully at it, yet.

Serenity came out recently, which I couldn't resist buying, even though I already own the original edition. Firefly is one of my favorite series, and extended scenes and more bonus features makes an already awesome science fiction universe even more legen—wait for it—

Last, but certainly not least, I've already gone through two chapters of The Little Schemer. The book takes on a very peculiar format, based purely (at least so far) in Q&A format. They ask questions that you can hopefully answer and give explanations for each answer. For a fairly advanced programmer like me, this is amusing at first, but tiring in some spots. I was hoping for a book that I could read cover to cover, but this doesn't seem to be the book. Not that I'm disappointed with it at all, I just don't feel like reading through levels of recursion that are obvious to me.

This brings about an interesting pedagogical method; Friedman and Felleisen take an approach that depends on the human ability to recognize patterns. It seems like if you ask enough questions, the reader should be able to figure out what a certain function does. I had kind of an advantage of already knowing what some of them did, so playing a game of 20 questions was a bit overkill, but I wonder how this teaching method would apply to a more inexperienced student.

Actually, I already use this method somewhat with students. Whenever a student asks me a question that I deem should be obvious or already known from previous labs/lectures, I bombard them with questions until they figure it out. Unfortunately, this doesn't always work, possible due to a few reasons:

• The student is lazy. This might be a mean thing to say, but I think it's true. Graduate TAs that run consulting hours complain about students being unable to debug on their own, which I believe should be fairly intuitive. I've even had someone cry, possibly to get me to write the project instead.
• The student doesn't really understand the language. Compared the Scheme, Java is pretty complex, and some students never really properly learn some language constructs (e.g. the static keyword). This presents a huge problem when you get errors like, "non-static variable referenced in a static context." This is more of a lack of knowledge than reasoning ability, so this is where I throw my hands in the air and tell them to read the textbook.
• I'm not asking enough questions or I'm asking the wrong questions. This is quite possible; unlike the concepts presented so far in this book, so it's not always possible to ask an exhaustive list of questions to make the student reason through exactly what mess he/she has just made.

Regardless of the potential for failure, I think this could be applied to some specific topics for students to look like. The static keyword is probably a good target to start with. It is not as difficult to make an exhaustive list of questions for the students to "pattern match" through for one single concept, but I guess it's too late to use this kind of method when they're working on projects midway through the semester. Hopefully I can get some spare time to concoct an article for using the static keyword, and get some response from students on how beneficial it was.

Anyway, this has been a very random grouping of topics and I think I've poured out my heart and soul enough for tonight.

Dary.

The not-as-exciting Austin post

Not to insult Austin or anything, but I'm lazy, and most of the work was done for me already. James posted a fairly comprehensive summary of what went down in Austin.

The only thing I have to mention is that I'm noticing a trend when comparing Purdue's campus to others (such as MIT and UTA). I wonder if it's really just because I've seen Purdue for three years.

The super-exciting Boston post

Yeah, so this post took about 5 days more than it should have. Oh well.

All was quiet from my end of the Internet this past weekend, since I was at MIT visiting my so-very-dear friend, Julia. Of course, like the rest of this year, my airport experience was highly unpleasant at best. I decided to fly US Airways since it was cheap; apparently they were cheap enough that they canceled my flight out on Friday evening without citing a reason, forcing me to fly out at 6:20am on Saturday to be able to spend any significant amount of time in Boston. My flights were delayed a little bit anyway, and filled with crying babies, further adding to the flight fun.

After arriving in Boston, we went to a Vietnamese restaurant around Harvard where I had phở for the first time, along with some sort of beverage made of jackfruit. Phở is basically a beef noodle soup, though there were some ingredients within that I couldn't identify (and thinking back, would probably rather not); it was pretty good, especially since I hadn't had breakfast, despite being awake since 4am.

After lunch, it was pouring extremely hard, so we spent rest of the remainder of the day in the comfort of a dorm room. The dorm is a graduate dorm, and it provides a better environment than any dorm at Purdue ever has (or will); the dorm is replete with computing facilities, conference rooms, as well as apartment-like suites that include kitchens as well as bathrooms, never mind the fact that each room was bigger than a shared double in Hillenbrand. For dinner, I stood by idly and watched Julia cook we cooked chicken parmigiana, and since I'm alive, clearly it wasn't toxic. Too toxic, anyway.

After waking up at noon on Sunday, we had pancakes, eggs, and sausage (read: fat) for...for lunch, I guess. We took a mini-tour around MIT's campus, which was interesting; it's pretty different from Purdue's campus, which I would call boring at best (and smelly during select seasons). To begin, Purdue's campus is fairly confined to a smaller area, unlike MIT (and IU, for that matter); smaller areas aren't very exciting, but I guess it's nicer for walking to class. MIT's campus is a little more widespread and more "scenic," being that it doesn't reside in a town as tiny as West Lafayette. MIT also has some fairly interesting architecture, such as their CS building, which is probably the wackiest building I've ever seen in my life (photo shown below; not mine). More to the point, most of Purdue's buildings are pretty boring (new CS building, anyone?); maybe the architecture is just a novelty that would wear off on me if I saw it every day for four years, though.

MIT seems to have a more interesting history than Purdue does, as well. Maybe it's because of MIT's incredible nerdism that makes them measure bridges in terms of people, but as far as I know, Purdue feels pretty bland in comparison. Not that we don't have our own share of of urban legend to spice up our history, but it seems like our student population is confined typical college activities of partying and tipping cows studying hard. Of course, it's also quite likely that I'm left out of the loop, since I never leave my room.

MIT hacks are also a very interesting part of MIT culture. Putting fire trucks on top of buildings and putting blown up versions of a class ring on a stolen cannon seem to be above things that Purdue students (or administrators) could ever manage. Of course, I'm not exactly an expert of Purdue culture either, so I can't really make too many comparisons, but I think it's safe to say that Purdue is relatively normal; after all, we appear to be a relatively conservative campus.

Of course MIT has its downsides too, such as living through X years of torture, paying more money for one year than I pay for four years at Purdue, and so on. Paying so much more might entitle you to better living quarters among other things (being around generally smarter people, getting a job automatically, you know), but the the painted picture of the academic workload seems...well, crazy.

We walked around Boston for awhile; the weather was much nicer than it is in West Lafayette now. Even though it was overcast, it wasn't raining, and there was a nice breeze to keep the temperature nice. In West Lafayette, it's blistering hot, and I start sweating just walking back to my apartment from work. Lucky for me, I'm not playing tennis anymore, unlike two members of my family, or I'd probably be dead by now. Anyway, Boston was a pretty nice area; I certainly like it much more than I liked New York City when we visited for spring break (possibly because it was snowing and very wet). Boston didn't feel as congested as NYC always did (given that it was a Sunday), and I guess it just felt different (in a good sort of way?) walking around Boston; maybe I felt like I had a smaller chance of getting mugged.

It was kind of weird to see some university residences (MIT Greeks, BU dorms) sitting in the middle of a city, kind of like how Soochow University in Taiwan was right in the middle of a city. The buildings there were also unlike anything you'd ever see around Purdue, partly because some of them are very old compared to anything you would see in all of Indiana. I guess someone decided it would be fun to build housing vertically instead of horizontally to prevent people in Boston from getting fat; maybe I should move into one of those houses.

We ate at a Thai restaurant for dinner (I don't remember any names, I suppose I'm a bad tourist) and I had a yellow curry. I didn't realize they would just give you "extra" bowls of rice if you needed it, and there was an awful lot of curry sauce for just one bowl of rice, but it was still good. The rest of the night was spent watching South Park and failed attempts to get me to follow along with Japanese women doing aerobics and saying really odd things like, "I was robbed by two men" and, "take anything you want." I think their smiling faces indicated that they didn't know what they were saying.

We left for the airport basically right after waking up. My flight back was also delayed at each leg, and I ended up getting back home about two hours later than I should have. I don't know if I just pick terrible times to fly or what, since I don't think I've ever encountered this kind of luck before. At least I wasn't flying Northwest, who appears to be canceling flights like nobody's business, or I'd probably still be in Boston. Alone.

So all of this took way too long to think up and write, and I leave for Austin in a few days to visit James, a lazy bum who hasn't posted on his blog in awhile, all the while thinking he can bug me about my blogging!

CS180: Debugging

One major point that CS180 seems to be lacking teaching students about debugging--understandably so, because it seems like debugging should be a fairly intuitive process. However, when it comes down to programming projects, plenty of students come in to get help with the same situation: They've programmed their entire project, but it doesn't work. The degree to which their programming is hopeless varies by student, but in general, consulting TAs can get exasperated with bad programming practices and helplessness in regard to fixing bugs, be it at runtime or compile time.

One hopefully helpful way to attack this problem will be to have a lab about debugging, which will be fairly early in the semester. What I'm interested in hearing is what people think should be included in a lab like this. Since the lab is planned to be early on, it's difficult to have students attack complex scenarios and fix bugs in them. Perhaps the only thing we can teach them is the "development cycle," which seems to be: edit -> compile -> fix compiler errors -> compile -> run -> fix runtime bugs -> etc. This is pretty natural to students, and I haven't really seen any students who didn't understand that cycle. The problem really lies in the fact that they have no idea how to fix either type of bug.

In most cases, Java tends to spit out fairly reasonable error messages, which means students should be able to figure them out. Do they even bother to read them before calling a TA over? Sometimes I don't think they do--perhaps it would be in our best interest to have them sit on it for awhile, first. I seriously doubt it's difficult to understand what "missing semicolon" means. Another thing that needs to be pointed out is that compile time errors need to be fixed from the top, not bottom. Since one error (particularly syntax errors) can cause an explosion of false alarms, fixing from the bottom is often unhelpful and incorrect. Even though a compiler may spit out 100 errors, that doesn't mean you have 100 errors to fix!

Teaching students to fix runtime errors is, in my opinion, an order of magnitude more difficult. Part of it lies in the fact that some students will have the wackiest implementations you'll ever see that really make no sense at all, but also somehow work--most of the time. JDB is a potentially helpful tool, but this probably isn't something we want to teach this early on (I think it sucks compared to GDB, anyhow). Other ways of finding errors would be via unit tests, print-and-seek methods, or main methods for testing. The first has not been taught in CS180 at all (or in any CS class, for that matter), so the second is usually what I tell students to do. However, they seem to be unable to insert their own prints in strategic location. This should probably be mentioned in the debugging lab, since it's the easiest to teach. Writing main methods that do testing for you is probably a good idea as well, but this isn't as applicable until students get into projects with multiple classes.

The more and more I talk about this topic, the more I see that there might not be a whole lot that could be put into a debugging lab, besides reading. If the lab is to be early on, then we can only teach them a small amount. However, maybe it would be good to write a series of articles on more "advanced" topics for later projects? Good programming habits aren't really taught in CS180 either, for who knows what reason. For example, programming in incremental stages and testing (at the very least, compiling) at each stage will help reduce the bug fixing stress students experience if they try to program all of a project before compiling. Another thing to point out is that having methods be fairly small/contained is a good idea. It could make finding runtime errors a bit easier, compared to having a main method that's hundreds of lines long.

I also thought that having some sort of debugging exercises later on via CS192 might be helpful, but I have no responsibility in that part of the course planning (and at this stage, I don't really plan to). For now, we'll have to assume that we have to teach them everything they need to know about debugging in one very early lab, and put the reset off for individual reading later. Along that note, someone (Ryan, perhaps) mentioned that having a centralized repository for this kind of documentation would be good--would we have any contributors if this were to be set up?

For the tl;dr (or those too confused by my post that should be edited, but won't be), answer these questions:

• What should be in a debugging lab?
• What shouldn't be in a debugging lab but is still well worth knowing?
• Are you willing to write about these things for a central repository?

CS180: Writing easy-to-grade labs

Maybe I'm having delusions of grandeur, but I think this should be possible. I'm currently envisioning a method of writing labs that allows a script to perform automatic grading (yes that's right, I've gone mad) for the ease of the lab TA. A little adjusting to how comments in the skeleton are done can go a long way. I'm kind of lazy, so I'll be using my super-trivial code example that I ranted about some time ago, with two TODOs added:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    /* END TODO 2 */
}

Usually the skeleton code will consist of a bunch of blanks you need to fill in, so if we specify and ending line for said blank, then you can tell what the student typed in for the TODO. This is a pretty simple approach, and allows you to swap out TODO implementations (say, a student's implementation for the solution's), which can be done by a grading script. This method would also take away the problem of TODOs that don't compile by default, which is an issue for students who can't finish their labs. You can test one TODO at a time, using the solution for the rest of the program.

Edit:This doesn't really take away the problem of TODOs that come non-compiling, since students can't test their program until it does. Duh. More on this later, maybe. Suggestions welcome.

Theoretically, this idea could be extended to make a script generate the skeleton code as well, since it seems trivial to extract the text between the comments and call it a skeleton:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        return true;
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    else {
        return false;
    }
    /* END TODO 2 */
}

I can imagine creating a directory structure for creating labs (kind of like Rails...except not):

solution/
doc/

From this, the lab spec would be written inside doc (how this will be done is yet to be decided), and the solution in the solution folder. Running a script after the solution is finished would:

1. Extract all of the solution text from the TODOs to create the skeleton in a skeleton folder
2. Create a tests/ directory that has a subdirectory for each TODO, where the author can insert Java programs to test that TODO
3. Generate the lab spec in HTML format in a www folder

This entire structure would be mailed out to all of the TAs, while the skeleton and www folders would be what was exposed to the students. When it came time for grading, you could have a generic script (I hope) that would take a test directory and a solution directory and run tests for each TODO on every student's files, generating text that would be mailed to students.

While automation would probably speed up grading by a lot, I still think there's room for grading things by hand. Emphasis on style, such as proper indentation, non-terrible horizontal whitespace) is much more difficult to automatically grade (if someone wants to write a script to do it, be my guest). Granting partial credit and giving advice for writing better code also has to be done manually, and I think it would be good if TAs at least spent time on this once every few labs (perhaps this should be designated; every third lab, maybe?). This process also doesn't help if we create write-from-scratch labs.

I think I've rambled enough for now; comments welcome, etc.

CS180: Writing and grading labs

Part of my summer goals for CS180 include improving the way labs in CS180 are done. There seemed to be a lack of standard in handling labs over the semesters that I taught, which actually weren't a huge deal, but I think it's a problem worth addressing. Different TAs tended to write their lab specs in different formats, which could sometimes be confusing; some TAs also wrote labs that were hard to grade, which ended up being annoying for all of the TAs. Specifically, the goals I have are:

• Write a spec writing guide (especially since I may be the only returning lab TA)
• Write a lab spec template and source file template
• Write a few labs based on the specs
• Write a lab "best practices" guideline (slightly unrelated)

In addition, a change that will be made this semester is that the last few labs (or at least some labs) will be written from scratch. A complaint I heard was that CS240's labs were hard to deal with, since many of them were written from scratch. This is a silly problem, and students should be learning how to build a program from the ground up.

Grading is also a worthy problem to address; there is no standard for TAs to grade by, which leads to a natural unfairness in the lab grades. I think expecting the lab author to also create a grading rubric is reasonable, and should help TAs grade more fairly and more quickly. If labs are able to be script-graded, I would expect the TA to write a script for it as well.

Another aspect of grading comes in how the student sees how he or she did, and what went wrong. Traditionally, when us old people took it, TAs would print out labs and hand them back; I tried this last semester, and it was a bit cumbersome to manage all of the paper (and wasteful, in my opinion). CS158/9 had its TAs mail students back with comments, which I thought was a better idea, but the way they had us do it kind of sucked.

For the TAs, I think the improvements for a major part seem to boil down to scripting. I imagine Python scripts could be handy for writing grading scripts, among other things. For one, the best way to generate a uniform HTML page for the lab spec is probably to parse some markup that generates the HTML for you, rather than force everyone to hand-edit a bunch of HTML. Or maybe I'm just deluded. Python could probably make a lot of things easier, but more on that later. Hopefully.

Comments on any of the possible changes are quite welcome, as I'm kind of rambling.

CS180: Editors and IDEs?

For some reason, we started using jEdit as our official editor in CS180, since apparently our students weren't hax0r enough to handle Vim or Emacs (we stopped using Eclipse as well, for some reason that I don't really know). Looking back over the past few years, I wonder if jEdit is such a good choice. They tout themselves as a "programmer's text editor," but I think it sucks. We have 25 [apparently theoretically] identical computers in the CS180 lab, but jEdit does wacky stuff like behave really oddly if num lock is on (or off, one or the other), not syntax highlight properly on some computers, etc.

I'm hoping that as the next head/lead/whatever TA, I can persuade the course administrators to change the editor, if I want, but I'm not entirely sure what I would suggest using. The options seem to be:

• Vim
• Emacs
• Pico/Nano
• Eclipse
• IntelliJ IDEA
• NetBeans

Some of these options are laughable (if you ask me, anyway). Using vim or emacs as a main editor is probably still not a great idea; it would be wise to learn in CS180 anyway, but the warring of the two editors means some students would be learning one and some would learn another, as mandated by the instructing TA. This is probably a crappy idea, and students should try both on their own, since the USB has tutorials on both. Pico on lore doesn't have syntax highlighting; I don't really know why we don't use Eclipse (other than I think it can eat poop), IDEA looks interesting (but weaning new programmers on IDEs means they're going to have tons of fun in CS240), and NetBeans? Yeah...

I'm open to opinions, though I wonder if anything will ever come of it. Maybe I'm just posting so I don't feel so lazy.