Slashdot Mirror
Ideas for High School Computer Projects?
rcmpcbf asks: "HELP A TEACHER OUT! My Computer Science students often get bored doing stuff that the AP Curriculum or School Board asks us to teach. I would really appreciate the input of Slashdot members on interesting Computer Science projects for high school students. You would be helping other students, just like yourselves, not me." What kinds of computer projects do you feel would be stimulating for the high school age group?
One of the failings (that I see at least) of high school level CS classes is that they don't pay any attention to the real low-level hardware bits, down at the level of individual logic gates.
A lot - and I mean A LOT - of basic understanding of "why computers are built the way they are" comes from wiring up really basic componants, flipping some switches, and watching LEDs flash on and off.
For instance, I remember doing a project where I wired up 2 shift registers and an ALU chip to a rack of switches and 8 LEDs. By flipping the switches, one could input a pair of binary numbers into the shift registers, and then another switch (wired up as the clock) would trigger the ALU, and the resultant sum would show up on the LEDs.
After doing something like this, you gain understanding of such things as: Why do computers work in binary? How do instruction sets work? How do data busses work? What is the signifigance of the clock? And so on.
The only downside to projects like this is that you need some hardware - breadboards, power supplies, a selection of cheap ICs, a bunch of wire, and LEDs. But tinkering with this crap is just soooooo worth it - and it's fun!
Want to learn about race cars? Read my Book
I'm sure many of you have heard of the Iditarod -- the dog race from Anchorage, Alaska to Nome, Alaska over 1100 miles.
High school students in Nome were given an awesome project by their high school CS teacher -- we wrote the program that was used to keep track of the mushers during the race.
This was pre-internet explosion -- I'm talking mid- to late 80's here -- and we wrote the program in BASIC on our trusty Apple IIe's. It was a simple database; the users would enter a musher number, checkpoint number, time entering or leaving, and number of active dogs on the team. Once an hour we had to print off a report that was given out to the media reps sitting in Nome.
The ultimate perk was, once the race actually started, students could sign up for 8-hour shifts manning the computers at the Iditarod HQ in Nome. (Yes, even during school hours, but you had to sign up for 2 non-school shifts for every one school shift.)
About the time I graduated from school, Alascom (Alaska's big telephone corp) was using the data from our program to do the updates on their 800-number voice-messaging number. ("The current leader is Libby Riddles; her last checkpoint was in Ruby" and all that.)
Granted, we re-wrote the program from scratch every year -- not the best model if you want to teach code re-use and modularity (but then again, it was the mid- to late 80's). I suppose it's likely that, should a class totally screw off for the semester, that they'd pull an old copy off of the shelf to use. But it was a project that stimulated the creative drive of the students. Even the ones who weren't in the class; kids also helped out with feeding and caring for the dogs when they got into town. It was a real community effort.
I suspect that, since the Iditarod has become more "professional" a la the Olypmics, that this project isn't being done anymore. It's a pity.
Jay (=
10. How to install Linux/*BSD /. and teach them to hit reload every 2.5 minutes.
9. Show them the proper methods of beard grooming
8. How to dress appropriately for any occassion with only jeans and a t-shirt.
7. Teach them to drink coffee - lots of it.
6. It's never too early to turn them on to cigarettes.
5. Give them a web connection to
4. Get them turned on to Linux and teach them to make inane comments about how much KDE sucks if they like Gnome, and vise versa.
3. Make sure they never get to bed before midnight and make them get up at some ungodly hour.
2. Give all of them pagers and call them every few hours in the middle of the night and say "My computer has a message on it that says 'Press any key to continue.' What do I do now?"
1. Teach them how to be a BOFH!
I can remember in High School I became incredibly bored with Computer Science, being I already had advanced knowledge of computers, and took it just to get an "easy grade".
One thing that I had trouble with was keeping busy - the Teacher I had was bright, but not very skillful in computers. He knew I could run the class and that scared him.
I would suggest is asking your students *what* they want to learn - some might want to learn networking, some might want to program, others repair computers. Give them research time to browse the HOWTOs and other more in-depth information.
I got into alot of trouble in my CS class and ended up dropping out because I was at the point of losing my sanity.
If the subject is programming, don't tell them what kind of program to write - just tell them to make one! This is what motivated me. My friend and I spent all of our time writing a instant-messenger over IPX (it was a Novell LAN) while everyone else was writing "exercise programs". We didn't get a grade for it, even though our program was much more advanced than the others'.
Secondly, I would put your IT department to a test. Put $50 on the table and tell them the first one to hack the school's server will get it. This is not only beneficial to your security, it will keep the kids motivated. Make them share how they did it with the class and make a "lesson" out of it. Also, keep the kids busy by having them do computer work in the school. In my school most teachers would have a downtime of over a week before their terminal was fixed. It's free help for the school, and very educational for the student(s). Pair up the smarter kids with some of the not-so-smart-but-able-to-learn kids.
Have a "LAN party" day when everyone who has a computer brings it in and setup a game of "Worms Armageddon" (in this "post-columbine world" as JonKatz would say) Doom or Quake would not be acceptable if you are worried about your job. Have them setup the network and get all the clients configured and have them go at it.
Hope these help... I wish I had these to do in High School...
- Slash
Start a company
Syllabus: 1] Write code that does nothing - but has buzzwords like "B2B" or "Sharing" in it. 2] Be written up in Slashdot. 3] Get VC funding. 4] Be written up in Slashdot again, with nearly identical commentary to the first. 5] Make the cover of a half dozen clueless magazines. 6] Be ignored by Slashdot. 7] Count stock options worth several billion dollars. 8] Get sued by some equally clueless industry group afraid their fat cash cow is going away. 9] Be written up in Slashdot, with more redundant commentary. 10] Pursue the lawsuit in front of some absurdly clueless judge who slaps a restraining order on the idea of "programming" because it could violate some businesses ability somewhere to make money. 11] Did I mention being written up in Slashdot? 12] Go out of business, because after all, the code did nothing.
"The axiom 'An honest man has nothing to fear from the police'
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
At the beginning of the year, everyone picked a project -- two misguided students teamed up to write an OS, I picked a chess-playing program, someone did a database, someone did a simple BBS, someone did a symbolic math package, and so on. There were few restrictions on what you could pick, although you were encouraged to pick a year-sized chunk of work that was reasonably useful from a real-world perspective. We worked on these out of class for the year; she tried devoting class to status reports, but that was mostly useless -- who wants to hear the status of someone else's project? So she started devoting class to random CS tidbits, in chunks of a week or two. The only tidbits that really stick in my mind are a couple weeks' worth of Lisp (with most of the class being us solving in-class Lisp problems, on paper or in the computer lab) and a basic introduction to hashing. The in-class stuff was basically killing time, though; almost all the grades were from the projects. I think there was the occasional class devoted entirely to question-and-answer, also, although the saintly Ms. Bunn handled most project problems outside of class.
As I said, this was the most amazingly cool CS education I've ever gotten. In the course of finishing a project, you were guaranteed to pick up a whole lot of useful crap, but you also had the sense that you were doing something important (as opposed to the "Todaay, wee willl bee learnning aabout graaph algoorithmms..." style of education), and it was cool as hell once the projects got to the point that they were actually functioning programs ("Holy shit, it's really playing chess!") Most of the projects were structured so that there was no real stopping-place, so there was no risk of running out of work -- when I announced that my chess engine was as good as I could make it, Ms. Bunn smiled and gave me a book that described alpha-beta search, which kept me busy for the next several days continuously until it worked, and then until the end of the year trying to make it better. For the BBS or the symbolic math package, you could just keep adding features. The OS, of course, was barely begun at the end of the year, but what had been written appeared pretty sound, so I think the kids escaped without too bad a grade. I think a couple of people actually managed to "finish;" Ms. Bunn just let them slack for the rest of the year, but I could see you handling this differently.
Anyway, my advice to you is to try to separate the kids who want to take a class on CS from the kids who want to learn about CS, and then do something akin to the above for the ones who want to learn -- some of them will stun you with how much they produce when you let them produce whatever they want. Keep the class pretty small so you can keep track of each student's progress pretty regularly, make sure the students aren't afraid to switch projects if the one they're on is too hard, easy, or unrewarding, and throw good, informative books & websites at them like Mardi Gras beads -- if a student hasn't done any work for a week, it's probably because he doesn't know a certain syscall or file format.
A few more project ideas, somewhat modernized from when I was in HS: An mp3 player ("You're done? Okay, now write the encoder."), a side-scrolling one-player game, a simple web server, a corewars simulator, a packet sniffer (they'll love that), a file compression utility. None of these are completely beyond the reach of a talented HS student with a school year to throw at the problem, but they're all "real" programs, such that when people do start getting them working, they'll feel like gods. They'll also have long since forgotten that they're learning.
It seems to me there are a few basic concepts that I would want a student to come with after his/her first computer class:
1. The basics of computer hardware, and file systems. A *n?x box of some kind seems to be the best choice for this, but you can teach the same concepts with a Windows PC or a Mac if you have no choice.
2. Programming. For an intro class, you can get by with Basic, Pascal, or even shell scripting... the point is to get the concepts of loops, conditions, and so on intot he kids' heads. For more advanced students, move on to an object based language. Don't chew your nails over the platform choice... whatever they use will be obsolete by the time they are out of college anyway. Just get them started.
3. Relational Databases. The school guidance counselor is probably telling your kids that database knowledge is a boarding pass for the Gravey Train. They should be, anyway. Again, don't worry about which platform you teach from. The concepts are very portable, and nobody really knows which database company will be the "it girl" of 2004.
4. Networking. Programming plaforms change, OS platforms change, database platforms change (I'm starting to sound like Avrey Brooks), but networking is the past, present, and future of the digital revolution. Make sure your kids understand TCP/IP, everything from the basics of sub-net masks to IP spoofing. Get down to the nitty-gritty of network file systems. Talk at length about client/server, thin clients, fat clients, terminal apps, web applets, ftp, http, ppp, and lots of other acronyms ending in "p". Give them an introduction to IPv6, the Common Language the whole world will be speaking in a few years. Bring Cisco geeks in as guest speakers. Then, once your kids are network guru's, have them promise when they get older they will remember to send you a photo of their yacts from their summer homes in New Zealand, and let you be a guest at their Florida country club once in a while.
5. Project Management. Once your kids have all the basic skills covered, it is time to let them use a little creativity to come up with their own projects and strut their stuff. If they want to design a game, fine... have them form a design team and get started. Applied knowledge is where the real learning begins.
Information wants to be anthropomorphized.
My OAC Computer Science course (OAC=Ontario's Grade 13) consisted of, among other things, a term-long project for the entire class, which was learning about how to, and creating, a full-blown application.
At the start of the term, everyone in the class applied to "jobs", with resumes and everything. According to what you applied for, and how you presented yourself (not necessarily your skillset), you got certain jobs. One person was chosen as the "VP" (the Pres was the prof), and had to manage a lot of stuff, as well as do some work. We had three departments: Coding, UI, and QA (whose job it was to make the coders and the UIs co-operate). There were department leaders, and then inside the deparments, if there were special task forces, they had team leaders, and so on. Basically, our prof tried to make it as much like a company as possible. It was a lot of fun. No class (to my knowledge) has actually completed the project, but it's the process that's important.
For me, it was really helpful to learn how to work well in teams, and how the real world operates. It was a lot of fun, and I think you learn more than doing games, or anything like that.
"Free beer tends to lead to free speech"