1. First off, before anything else, you want to make sure you've got classroom discipline in order or you'll never be able to teach anything. You basically want to start off tough, not smiling, and with high expectations. Then reward their hard work by easing up a bit as you go. Right from day one:
* Try to memorize some names ahead of time. You should have a computerized attendance system where you can see pictures of the students.
* You arrange seating on day one. You are the boss. Let them know it. You are not their friend.
* Have some simple class rules ready on day one. Go over those rules on day one.
That said, it sounds like older students, and it's an elective class, so you shouldn't have much discipline trouble (though don't bet on it). In all likelihood you can start easing up on discipline after a few days and everything will be fine --- but they must know that you'll bust them if they do anything that damages the learning environment you're trying to create.
2. Aside from discipline, here's my advice on actual teaching: At first, you want to alternate between "smart small and get fun things working" and "grand overview to give them a feel for what the heck they're doing". For example, on day one you might be doing stuff like telling them exactly what to type to make something interesting happen. Once you've shown them that they can produce neat stuff, they're going to want the overview stuff. After enough overview stuff, they're going to be like, "ok, enough already, let me do it". Then after some labs when they've moved on and are getting frustrated again, you go back into "overview" mode again. And so on.
Soon, your handholding isn't as explicit anymore, and your grand overviews start to get deeper, and you find yourself settling into the standard "lecture, work, lecture, work" style.
* * *
Regarding the split between the grade levels, I'd suggest trying to arrange things so that sometimes the more experienced students are working on their projects while you work with the less-experienced students to help them catch up. Relying on pairing less-experienced with more-experienced to have the more- teach the less- will probably lead to resentment ("I didn't sign up for this to teach! I signed up to code!").
This is because Python is a rather simple and straightforward language. It's not the sort of language that makes you panic at all when you first see it. It doesn't fit. Python is not a "seat of your pants, what the hell is going on, what do you mean my house is being demolished today?, oh the plans on display in the disused lavatory with the sign marked "beware of the leopard"?, oh well may as well enjoy the ride" type of language. The Python community is co-opting the wrong name.
There's gotta be a million better names to use. Some Monty Python-related ideas:
* Yorkshireman's Python Guide: You've got it easy!
* Python Guide: It's wafer thin!
* Python Guide: I like it runny!
* Self-defense against fresh Python: A guide
* Python! Wink wink, nudge nudge, say no more!
* Spam-free guide to Python
* Python: Our chief weapon is simplicity ... simplicity and readability ... readability and simplicity ... Our two weapons are simplicity and readability ... and namespaces .... Our three weapons are simplicity, readability, and namespaces ... and an almost fanatical devotion to Guido .... Our four ... no ... Amongst our weapons .... Amongst our weaponry ... are such elements as simplicity, readability .... I'll come in again.
I don't think it takes millions and federal loans to make an EV. Scratchbuilt or otherwise. Enthusiasts have been converting small ICE cars ("internal combustion engine" cars) into electrics for many years.
Electric cars are simple. For the most part, all they require is:
* batteries,
* a charge controller,
* power controller,
* some gauges, and
* a motor.
Car companies like to make them out to be more technologically advanced so they can charge more and get more government financial assistance. And for that matter preserve their existing ICE-based business. But EV's are fundamentally way simpler than ICE vehicles.
Edit: Yes, I realize that Aptera's 3-wheeled vehicle is amazing and is not something that a couple of guys could probably put together in their garage. I'd love to see Aptera or a company like them be able to employ engineers to work on those sorts of futuristic spaceships. However, I'm saying that you don't need to go all-out top-end to create an EV. Make a simple "VW Beetle-style" economy EV for cheap instead. It won't require astronomical funding and early adopters will go nuts for them.
I've found that [Pandoc](http://johnmacfarlane.net/pandoc/) has picked up the Markdown torch. It's got the most-needed additions using the probably least-controversial markup additions. Works great, is fast, well-documented, and is actively-maintained.
For those of us who weren't around, could you please tell me why we deplored thick client apps in the 90's? Was it just that they had to be MS Windows Win32 or MFC apps? Or is there some other reason?
> Would you say that requiring an actual physical address for each job on the site is feasible?
If I'm searching for a job, I've usually got a max commuting time in mind. Some towns are closer, but take longer to drive to because there's no highway leading there, or no train. Some are very far, but the train goes there, and so I'd consider the commute.
So, when a job ad has an address, that's what I'm thinking about when I see it: commute time.
Some job boards have a geographic search, but they "stretch the radius" so as to return more listings.
So, I'd say that "good geographic search" == an honest one (that is, give me the results that are actually within the radius or area that I specified).
2 things:
1. First off, before anything else, you want to make sure you've got classroom discipline in order or you'll never be able to teach anything. You basically want to start off tough, not smiling, and with high expectations. Then reward their hard work by easing up a bit as you go. Right from day one:
* Try to memorize some names ahead of time. You should have a computerized attendance system where you can see pictures of the students.
* You arrange seating on day one. You are the boss. Let them know it. You are not their friend.
* Have some simple class rules ready on day one. Go over those rules on day one.
That said, it sounds like older students, and it's an elective class, so you shouldn't have much discipline trouble (though don't bet on it). In all likelihood you can start easing up on discipline after a few days and everything will be fine --- but they must know that you'll bust them if they do anything that damages the learning environment you're trying to create.
2. Aside from discipline, here's my advice on actual teaching: At first, you want to alternate between "smart small and get fun things working" and "grand overview to give them a feel for what the heck they're doing". For example, on day one you might be doing stuff like telling them exactly what to type to make something interesting happen. Once you've shown them that they can produce neat stuff, they're going to want the overview stuff. After enough overview stuff, they're going to be like, "ok, enough already, let me do it". Then after some labs when they've moved on and are getting frustrated again, you go back into "overview" mode again. And so on.
Soon, your handholding isn't as explicit anymore, and your grand overviews start to get deeper, and you find yourself settling into the standard "lecture, work, lecture, work" style.
* * *
Regarding the split between the grade levels, I'd suggest trying to arrange things so that sometimes the more experienced students are working on their projects while you work with the less-experienced students to help them catch up. Relying on pairing less-experienced with more-experienced to have the more- teach the less- will probably lead to resentment ("I didn't sign up for this to teach! I signed up to code!").