A working Palm m105 can be had for $25-35. "Typed" student papers (Graffiti'd in) could be transferred to your computer by IrDA or a serial cradle. If you're willing to reformat electronic readings to ePub format, readings can be transferred to students the same way. "Notes" up to 4kB hold about a page and a half of single spaced text. Small but readable screen, free applications that raise the limit on the editor to 32kB (about 12 pages single spaced). A pair of batteries lasts 1-2 weeks; using the IrDA is the big current suck, so use a serial cradle for everything. The "supercaps" in the m100 series don't hold a charge while switching batteries, so the device resets. "Hotsync" to a PC before & after battery swap makes that irrelevant. For those who must keyboard, an attachable full-size keyboard that folds up to pocket size is another $35.
The banks that don't have them in stock will almost always be willing to include a brick of $2 bills in their next currency order to the Fed if you agree to take all 1000 of them. It takes me about a year to go through a brick just using them for small cash purchases.
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development.
Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
The change from imperative/procedural languages to object oriented languages can probably be done through reading and experimenting, but an instructor-led course would be easier by far. If you can take one or two semesters at a local college of some object oriented language — Java and C# are the two most approachable, and conveniently have free IDEs and toolchains — that would put you back in the game enough to learn through reading and through playing around. Once you have your mind wrapped around OO concepts, a GUI framework (Swing, WinForms, GTK+, etc.) is easy enough to pick up. Similarly, learning how to exploit relational DBs is deserving of a course: I've never seen anyone self-teach more than about half of a relational DB's capabilities. I'd put off C++ to start: the language is fearlessly exploring what happens when OO concepts are applied orthogonally across a language, but Java and C# fit nicely into the 90% solution space that people actually use.
Slashdot Mirror
A working Palm m105 can be had for $25-35. "Typed" student papers (Graffiti'd in) could be transferred to your computer by IrDA or a serial cradle. If you're willing to reformat electronic readings to ePub format, readings can be transferred to students the same way. "Notes" up to 4kB hold about a page and a half of single spaced text. Small but readable screen, free applications that raise the limit on the editor to 32kB (about 12 pages single spaced). A pair of batteries lasts 1-2 weeks; using the IrDA is the big current suck, so use a serial cradle for everything. The "supercaps" in the m100 series don't hold a charge while switching batteries, so the device resets. "Hotsync" to a PC before & after battery swap makes that irrelevant. For those who must keyboard, an attachable full-size keyboard that folds up to pocket size is another $35.
The banks that don't have them in stock will almost always be willing to include a brick of $2 bills in their next currency order to the Fed if you agree to take all 1000 of them. It takes me about a year to go through a brick just using them for small cash purchases.
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
The change from imperative/procedural languages to object oriented languages can probably be done through reading and experimenting, but an instructor-led course would be easier by far. If you can take one or two semesters at a local college of some object oriented language — Java and C# are the two most approachable, and conveniently have free IDEs and toolchains — that would put you back in the game enough to learn through reading and through playing around. Once you have your mind wrapped around OO concepts, a GUI framework (Swing, WinForms, GTK+, etc.) is easy enough to pick up. Similarly, learning how to exploit relational DBs is deserving of a course: I've never seen anyone self-teach more than about half of a relational DB's capabilities. I'd put off C++ to start: the language is fearlessly exploring what happens when OO concepts are applied orthogonally across a language, but Java and C# fit nicely into the 90% solution space that people actually use.