2006-07-20T06:31:15ZLast October I mentioned a board game called c-jump, with the following commentary: I think this concept of “teaching kids to program” meaning teaching them C-like syntax is symptomatic of a deeper problem in the industry; the idea that knowing...
Last October I mentioned a board game called c-jump, with the following commentary:
I think this concept of “teaching kids to program” meaning teaching them C-like syntax is symptomatic of a deeper problem in the industry; the idea that knowing how to program means only knowing the syntax for a language, being able to put together a file about which the compiler doesn’t complain.
More recently (okay, January) I ran across a very different concept for teaching kids to program, a development environment from Carnegie Mellon called Alice that answers my objections neatly. In Alice, there's no emphasis on the syntax itself; the environment prevents you from needing to know the syntax by enforcing correctness rules (at any given time you can only make changes that result in a legal program). The point is that then you can concentrate on what you want the program to do, rather than how you get the program to do what you want.
I think this approach would be much more successful at teaching kids programming; what's really impressive is that it includes some concepts that are rarely if ever actually taught in classes (such as concurrency and event-based programming) but that can be very important in the real world.
While I'm on the subject, I read another very interesting article recently. Coding Horror linked to an academic paper about predicting which students can become successful programmers, and which can't. Apparently between 30 and 60% of incoming C/S students fail their first programming course, not because they're not smart or hardworking (although there are those, too ;)), but because they either cannot form a consistent enough mental model to understand the system, or they reject the whole exercise as nonsense. It was actually kind of a shock to me to learn that some students not only aren't intuitively able to form a consistent model of assignment (one of the most basic requirements for understanding programming)--not even an incorrect but consistent one--but that they cannot do so even after a formal programming class. Some people, it appears, really can't learn to program. I guess what that says about me is that I have a high tolerance for nonsense. ;) The test (and answer key) is available at the paper's site, if you want to test yourself.
2006-06-22T18:52:42ZDue to a minor logic error which prevents FolderSyndication from publishing the XML in some cases, I’ve created a maintenance release. The package will automatically upgrade any previous versions, however, you should manually back up the .config file and any...
Due to a minor logic error which prevents FolderSyndication from publishing the XML in some cases, I've created a maintenance release. The package will automatically upgrade any previous versions, however, you should manually back up the .config file and any custom XSLT files you have added, as the installation process will overwrite or delete them.
If you have any questions, comments, or bug reports, please don't hesitate to contact me.
2006-06-22T18:52:25ZAnnouncing FolderSyndication 1.0. FolderSyndication is a tool that will watch folders and files for changes (new files, modified/renamed files, deletions, etc) and will publish those changes, for instance to an Atom feed (the default, although an RSS 2.0 feed is...
Announcing FolderSyndication 1.0. FolderSyndication is a tool that will watch folders and files for changes (new files, modified/renamed files, deletions, etc) and will publish those changes, for instance to an Atom feed (the default, although an RSS 2.0 feed is another provided option). If you don't like Atom or RSS 2.0, you can provide your own XSL transform to output whatever you want--Word document, raw XML, database update, whatever.
As with the other tools available on my website, FolderSyndication is licensed under a Creative Commons By Attribution license, meaning you are free to use and redistribute it as long as you give me credit as the original program author.
Download Link (Note: This package will not install on Windows 2000 or previous due to its use of the LocalService account. To install on Windows 2000 or previous, use this package instead.) Either package is about 400k in size.
If you have any questions, comments, or bug reports, please don't hesitate to contact me.
2005-10-05T04:18:31ZThe other day I read in Wired (which probably means it’s old news ;) about a “programming board game” invented by Igor Kholodov to teach kids the “basics of programming”. It’s called c-jump, and as Wired says, The board game... The other day I read in Wired (which probably means it's old news ;) about a "programming board game" invented by Igor Kholodov to teach kids the "basics of programming". It's called c-jump, and as Wired says, The board game turns players into skiers who must race down a mountain in the quickest way possible. With each roll of the die, players must follow instructions that are similar to computer program codes. Using basic math, players have to figure out which paths are open to them and then decide the fastest way to the finish line. The trick, however, is learning which paths are open to you using only programmer jargon like "if (X==1)" then you can take the green path or "while (X<4) you can take the orange path," where X is the roll of the die. No offense to Mr. Kholodov, but I always have the same reaction whenever people talk about "teaching kids to program". That reaction is, more or less, confusion. I don't know that "teaching kids to program" is a particularly valuable thing to do, at least as most people seem to envision it. Teaching them the basics of programming, to me, involves teaching them to think logically and algorithmically, teaching them to construct mental models and extrapolate consequences, and to balance competing objectives. I don't see much use in teaching them what "x==1" means, or teaching them how to follow an if branch. The important thing is not to learn the syntax, but to learn the concepts. Not to learn how to follow an if branch (any idiot computer can do that), but when and why you might want to choose between two courses of action. In fact, I think this concept of "teaching kids to program" meaning teaching them C-like syntax is symptomatic of a deeper problem in the industry; the idea that knowing how to program means only knowing the syntax for a language, being able to put together a file about which the compiler doesn't complain. Too many programs are constructed by trial-and-error, changing things semi-randomly until they work rather than understanding the system and considering the best method to use to solve the problem at hand. Rote programming is not an advantageous skill; if you understand the concepts, you can pick up any language quite rapidly. Just as importantly, rote programming is something that can be effectively outsourced; there's no point in teaching your child a skill that will put them in the position of needing to be the lowest bidder to get a job. The advantageous skills are ones not unique to programming, which makes teaching them even more useful; the kid may choose to never write a single real program, after all, while mental modeling is a widely helpful skill. These skills are also the ones that tend to result in higher-paying or at least more satisfying jobs, something I think all of us want for our children. I applaud Mr. Kholodov's interest and his creativity, I just don't think this particular effort is as successful as it could be. [...]
2006-06-22T18:52:15ZSome possible additions to Roy Osherove's comments on Defensive Event Publishing in .Net, with special attention to some performance scenarios introduced by Remoting. Several months ago, Roy Osherove posted a discussion of Defensive Event Publishing in .Net that discussed various problems with the "normal" methods of event publishing and raising in .Net. The naive programmer merely calls MyEvent(sender, eventArgs), never suspecting the minefield into which he or she is blithely strolling. Roy's post suggests several progressively more cautious methods of raising events to protect oneself against "bad" clients. At the time I commented that further improvements could be made, specifically to both avoid using Threadpool threads and to detect which callers are bad. I thought I'd finally get around to explaining what I meant and actually providing a solution I've used in the past. First off, not using Threadpool threads. I'm really not a fan of using the Threadpool for any operation that I don't have absolute control over, because there's a limited number of them. The default number can be increased, but you can't make it infinite (and if you could, it would defeat the purpose of thread pooling anyway). IMO threadpool threads are useful for short, relatively deterministic operations which won't ever call any client code and which either will never fail, or will fail in such a way that you don't care or can't do anything about anyway. Raising events just doesn't fit those qualifications for me. So the solution is to not use threadpool threads; this is a fairly simple thing to do if you're at all familiar with .Net threading. Depending on your implementation, however, and definitely if you use the code I've posted at the end of this article, then there are a few caveats to watch for; I'll note them along the way. The second way in which we can add to Roy's article is in detecting failed calls. His solution calls a OneWay async Invoke on the delegate; it's a fire-and-forget situation. Unfortunately, especially for an application that needs to stay up 24/7 for long periods of time, it may not be acceptable to just ignore failed calls; the app may want to clean up, or at least rid itself of the bad reference and let the GC pick it up. In order to do that, I use WaitHandles; each thread that I spawn for an individual delegate call will set a WaitHandle when it finishes. (Note that .Net events raised over Remoting automatically time out after a period of time. Using this method with non-remoted events would require additional code to detect timeouts, but would not require any additional code to detect clients that just don't exist anymore.) Here's one of our caveats: WaitHandle.WaitAll can only handle a certain number of handles; on the current .Net implementation (namely .Net 1.0 and 1.1 on Win32) that limit is 64 handles. Calling WaitHandle.WaitAll on > 64 handles will throw an exception. So, should you have more than 64 clients listening to the event, the code will automatically break them up into batches of 64 and wait on each batch sequentially. Another wrinkle is that WaitHandle.WaitAll isn't usable from STA threads--such as those used by Windows Forms--if you're waiting on more than one handle. This can be particularly tricky, as this means you probably can't raise an event using this code on your main Windows Forms UI thread. The code below doesn't handle this case (because our app wasn't a WinForm app and had no STA threads); if your code will be called from STA threads you will need to handle that situation (possibly by raising all events on a new thread). The final caveat is that only the class that declares an event can modify that event (other than a simple += or -= to add/remove a listener). Thus you can't modify the delegate list to remove a specific listener except from the original class. In order to get around this, my utility function returns a new delegate list that has all of the "bad" clients re[...]
2005-09-29T17:14:02ZColin Coller has created a very nice plugin for VS.Net called CopySourceAsHtml that lets you create colorized text by copying source from VS.Net. It produces pure HTML code (not the stuff spat out by Word) using embedded stylesheets: <style type="text/css">... Colin Coller has created a very nice plugin for VS.Net called CopySourceAsHtml that lets you create colorized text by copying source from VS.Net. It produces pure HTML code (not the stuff spat out by Word) using embedded stylesheets:
168: /// Creates a new socket server object and optionally starts it listening.
170: /// The friendly name for this socket server.
171: /// The port to listen on.
172: /// Whether to immediately start listening, or wait for a
173: public SocketServer(string name, int port, bool startListening)
2005-09-29T17:14:02ZDiscovery of a race condition in the TimedLock class (from Ian Griffiths and Phil Haack), and other ruminations on multithreading. Lately at work I've been dealing with a problematic socket server. The currently deployed version has something of a memory leak (to the tune of 140+MB/day), probably due to complications of incorrectly multithreading System.Net.Socket instances (note: they're not thread-safe). Unfortunately, when I redid the socket server to lock all the sockets and other non-thread-safe resources, I ran into a deadlock. In chasing it down, I used Phil Haack's modification of Ian Griffith's TimedLock class. That enabled me to find where the deadlocks were, and eliminate them. This class is really a very clever tool, with one small problem: it was throwing exceptions on the production server. The test server ran fine for days at a time, loaded down as heavily as I could manage, but the production server locked inside of two hours every time. The first error in the log was always an ArgumentException thrown by the stack trace hashtable, saying that the object being inserted as the key was already in the hashtable. After several days of debugging, and a few e-mails exchanged with Phil, he said the following to me: If the object wasn't removed from the hashtable via the dispose method before the second lock is acquired, that could cause the error. I started to write back, saying "But isn't the whole point of the locking that there is no way any other thread could acquire that lock until Dispose is called, thus calling Monitor.Exit and removing the object from the hashtable?", and then I was, as they say, enlightened. The sequence of events in the TimedLock runs like this: TimedLock tl = TimedLock.Lock(o); Monitor.TryEnter(o); StackTraces.Add(o); ... tl.Dispose(); Monitor.Exit(o); StackTraces.Remove(o); On a single-CPU machine (such as our test server), this code runs fine, I would guess, 99.99999% of the time. On a dual-cpu machine (such as the production server in question), however, it runs fine only 99% of the time. That 100th time, here's what happens...(assuming o is the same object in both threads) Thread A Thread B TimedLock tl = TimedLock.Lock(o); Monitor.TryEnter(o); StackTraces.Add(o); TimedLock tl = TimedLock.Lock(o); ... Monitor.TryEnter(o); // blocked ... ...waiting ... ...waiting tl.Dispose(); ...waiting Monitor.Exit(o); ...waiting StackTraces.Add(o); //****** StackTraces.Remove(o); The starred line is where the exception gets thrown. Textbook race condition -- if Thread B doesn't hit that Add() call between Thread A's calls to Monitor.Exit and StackTraces.Remove, then everything looks fine. But every once in a while (such as when processing a send and a receive simultaneously on a socket), it'll hit that tiny little target and blow the whole thing up. What's worse is that as written, once that target has been hit, that object can't be successfully TimedLocked (even though the original lock has been released) until the TimedLock that hit the exception has been finalized. This is true even if you wrap the TimedLock in a using statement (because the exception will leave using() with a null reference, which it can't Dispose). The fix? Simple -- swap the order of the Monitor.Exit() and StackTraces.Remove() calls. That ensures that the object will be removed from the hash table before any other thread can try to re-add it. This all looks very cut and dry now that I've laid it out, but before anyone goes accusing Phil of not knowing his stuff, reread the subject of this post. Multithreading is hard. .Net (and other modern languages) do a good job of hiding some of the comple[...]
2005-09-29T17:14:02ZSlashdot posted a story about a sign in Cambridge, MA that poses a mathematical riddle which, when solved, leads to a website which poses yet another riddle which, when solved, ends up being a recruiting pitch for Google. Google actually...
Slashdot posted a story about a sign in Cambridge, MA that poses a mathematical riddle which, when solved, leads to a website which poses yet another riddle which, when solved, ends up being a recruiting pitch for Google.
Google actually seems to be doing a lot of this--the current issue of Dr. Dobb's Journal has a leaflet in the middle which is several pages of strange or difficult (or both) questions and a postage-paid envelope. The envelope is addressed to Google, and encourages you to include your resume with your answers. This isn't the first time Google has used this particular billboard, either. And of course other companies have used similar, if not quite so difficult to solve, tricks as well.
I find this really interesting. Most companies act as if it's the potential employees' job to find and interest them, not the other way around. I don't live in any of the places they're hiring people like me for, but if I did I know this would pique my interest.
2005-09-29T17:14:02ZR. Frank Lutz has posted a tutorial on scheduled posts using MT3.1 which makes one of those statements that drives me slightly nuts: Task Scheduler, which comes bundled with Windows attempts to make automation of tasks effortless. Unfortunately, it is... R. Frank Lutz has posted a tutorial on scheduled posts using MT3.1 which makes one of those statements that drives me slightly nuts:
Task Scheduler, which comes bundled with Windows attempts to make automation of tasks effortless. Unfortunately, it is not very configurable and basic in what it is capable of. On UNIX and Linux systems, Cron is what is used for task scheduling. This scheduler is very configurable, and is capable of well more then its Windows counterpart.
This isn't actually true. I believe it used to be, though I'm not sure, but for years now the Windows Task Scheduler has been far more capable than most people realize out of the box--it just hides it well.
To set up a task that runs every 15 minutes, here are the steps:
Your task will now run every 15 minutes until you disable or delete it.
2005-09-29T17:14:02ZAnother update to SharpTerminal: this one fixes the large blank spaces on the bottom and right sides of the GUI, as well as a minor startup bug where if you hadn’t saved any default settings, and hit Connect without going...
Another update to SharpTerminal: this one fixes the large blank spaces on the bottom and right sides of the GUI, as well as a minor startup bug where if you hadn't saved any default settings, and hit Connect without going to the Config tab, you'd get an error. Going to the Config tab and back fixed the problem, but now it shouldn't appear at all.
The GUI bug was an interesting one for me. The computer I write SharpTerminal on had the DPI setting (Display Properties, Settings, Advanced) set to Large (90DPI). So the GUI looked fine on that computer, but it turns out that .Net is smart enough to perform Automatic Control Scaling according to the difference between the developer's settings and the runtime settings. This works great when the developer's settings are Normal and the runtime settings are whatever; Windows Forms scales the GUI appropriately. Things get a little weird when the developer's settings are Large (or possible any non-Normal setting)--as you can see in the screenshot below, on a system set to Normal, the scaling doesn't quite work:(image)
The solution turns out to be fairly convoluted. First, set the developer's computer to use Normal DPI settings and restart the PC. Next, open the solution in VS.Net and go to the code for the form with the issue. Look for a line that says
this.AutoScaleBaseSize = new System.Drawing.Size(6, 15); in the Windows Form Designer generated code region, and change the values to 5, 13 (the default values for a Normal system). Open the form in designer mode. Things will likely be very screwed up (controls will run off the bottom and right sides). Fix them. Note that some controls--for instance, the Microsoft ActiveX Web Browser Control--will probably have to be removed and readded in order to work properly. Recompile and the app should look right.
Of course, probably the best idea is for developers to not use strange DPI sizes to develop UIs in the first place. :-P
2006-06-22T18:51:46ZNew version of SharpTerminal available. Here’s the changelog: Fixed issues with COM ports not being consistently named between systems. Seems like the name of the COM port varies from system to system -> Mobo related? Added ability to disable local...
New version of SharpTerminal available. Here's the changelog:
2005-09-29T17:14:02ZSo today Erik Porter linked to a very silly list of reasons to switch from VB.Net to C#. I say very silly because most—nearly all—of the “reasons” are either nonsense, irrelevant, or outright wrong. As someone who recently switched from... So today Erik Porter linked to a very silly list of reasons to switch from VB.Net to C#. I say very silly because most--nearly all--of the "reasons" are either nonsense, irrelevant, or outright wrong. As someone who recently switched from working primarily in VB.Net to primarily in C# (not on my own initiative, and having no axe to grind), I feel I can shed a little light on this foolishness. In order, my comments in italics: For the Developer: Developers who program primarily in C# earn 26 percent more than those who develop primarily in Visual Basic .NET.This is about the only one I have no issue with, as long as the survey data is good. I'm not 100% sure I buy it, but at least it's not completely obviously off-base. C# just looks more elegant because it was consistently designed. VB.Net was evolved over many years and has inconsistencies.You can write C# code that looks like a mishmash of styles (and even languages) because--surprise!--there's more than one way to write programs! Similarly, it is entirely possible to write a completely .Net, FxCop-compliant application in pure VB.Net. C# is closer to Java which means it is easier for you to move to or from Java. This is good for your career.Poppycock. The real differences are not in the syntax--they're in the class library. Going from C# to Java will entail just as much of a learning curve as going from VB.Net to Java (since the BCL is identical for both VB and C#). Any developer worth the crud in their keyboard can learn a new syntax very easily; it's the BCLs that are difficult. C# is perceived as a ?real? language where VB.Net is still perceived as a ?toy? language.Maybe. And I say maybe. But perceptions change. Microsoft does all of its internal .Net development in C#. Even MS thinks C# is the better language.That's a lie. Microsoft internal teams do work in VB.Net. It's true that the majority of them work in C#, but they're coming from a C++ background--C# is more natural. VB.Net is in no way inferior to C# because of this. C# has the following features which VB.Net doesn?t have: Operator overloadingWill be added to VB.Net in 2005--and I've never missed it, anyway. How much real development involves overloading the + operator? XML code documentationHas been available via a free plugin forever, and will be in 2005. Yee-haw. Ability to write ?unsafe? code for better interoperability.In the (extremely rare IME) situation where you need unsafe code, it's trivial to drop down into C# or even C++ for it. Microsoft is actively adding new useful features to C# including generics, interators, anonymous methods, and partial types.Whereas VB.Net is stagnant? Hardly. Generics and partial types are coming to VB.Net at the same time, interators (sic) already exist, and some VB.Net features--Edit and Continue and the My classes, for instance--won't be in C# at all. For the Manager: Your code quality will improve because C# catches potential errors (example: variable use allowed before initialization and dead code) that are permitted in VB.Net.Am I the only one who's ever heard of Option Strict? As for dead code, yeah, it's nice that the C# compiler catches it, but I bet the VB.Net 2005 compiler will too. Your developers will be more productive because they will work in a language that they like.I really need a "confused" emoticon here. I don't know anyone (at least anyone who's ever actually used it) that doesn't like VB.Net. If your project is a mix of [...]
2006-06-22T18:51:35ZSo yeah, this is my new blog showcasing technology and programming, so that Jenny doesn’t have to read all that boring stuff unless she wants to. ;) For my first post, I’m going to present a little app I’ve put... So yeah, this is my new blog showcasing technology and programming, so that Jenny doesn't have to read all that boring stuff unless she wants to. ;) For my first post, I'm going to present a little app I've put together called SharpTerminal. As the name suggests, it's a terminal app (essentially a replacement for Hyperterminal) written in C#. It does a number of things Hyperterminal doesn't do, including a command buffer, easy entry of binary (non-printable) data, display of carriage return/line feed, etc. Oh heck, here's the ReadMe: Features: View communication as either ASCII text or hexadecimal values Save full session transcripts in multiple formats for easy analysis Open previous session transcripts Easy entry of binary data (prepend with 0x for hex entry) Unlimited command history (up and down arrow in Send box) Show or hide connection, control line, etc events. Colored text for ease of distinguishing between sent and received data Multithreaded for responsiveness Prettier than Hyperterminal Future Enhancements: Error Handling is not completely up to snuff. It won't crash, but it's not as pretty as it could be. Allow user to select encoding for "Text" mode. Enable DTR handshaking Consider allowing the intermixing of ASCII and binary? Add automatic crash reporting. System Requirements: Microsoft .Net Framework, version 1.1. It might run against 1.0, I haven't tried. Internet Explorer (any version 4 or later should work AFAIK). One or more serial ports. Licensing: SharpTerminal use is not limited; you may copy it, redistribute it freely, use it in a business, install it on a rocket and shoot it to the moon, or anything else I haven't mentioned here, with the following restrictions: No claiming it is your own work. You must include this ReadMe.txt file, UNMODIFIED, any time you redistribute it. Actually, that's pretty much it. If you really need specifics, see http://creativecommons.org/licenses/by/1.0/ Questions? Comments? Bugs? Feature Requests? Visit http://www.randomtree.org/sharpterminal/ or e-mail firstname.lastname@example.org All code, text, and images copyright 2004 Eric Means. If it sounds like something you could use, download SharpTerminal and give it a try (the zip file is about 1.5MB)! [...]