It occured to me over dinner tonight with the inlaws and a couple of beers, exactly what I'm trying to capture in autoCode. It's detail.
Detail like in VS.NET's C# IDE when I comment a section how the section turns black for a split-second, before turning green. I speak from firsthand experience when I say that it represents a massive attention to detail. I would be so happy to have autoCode just consistently highlight comment sections without any bugs creeping in, but to create a timer and enable it in response to a section being commentized, and then to disable the timer on the next key press, it all amounts to attention to detail above and beyond the call of duty. They say that immitation is the sincerest form of flattery, and there are so many other cool details in VS.NET; Ctrl+X and Ctrl+C with no selection cutting & copying the entire line is simplicity in itself, but I could not live without it anymore. Simple, but so powerful. I love this about VS.NET; it's like a work of art, beautiful.
I took a look at google's source the other week, just by chance and found it to be beautiful. Because of attention to detail: somebody paid so much attention to the load time of the initial page that they condensed the jscript and html to practically a single line of almost unreadable source, to save on byte count. In the days of cable modems that again is attention to detail far beyond the call of duty, but I firmly believe that it's that extra degree of effort that creates great products.
The devil is in the details as they say, but too many people (read: managers) think that detail is below them, that the "nuts and bolts" is not, and should not, be their concern. That is why software projects fail. That's why poor or non-existent specs are produced, and why deliverables fail to meet users' needs.
But the beauty of detail is a double-edged sword; in a system where attention to detail is abundant, then where it is lacking, its absence is felt even more strongly. Example: in the VC7 IDE, I expected to see the similar cool comentizing of a region to show as black for a split second. It doesn't. But in the C# IDE it does. Minor? Of course. But people's expectations increase when they are presented with quality and they expect to see it throughout. Another example: SQL Server's Enterprise Manager -- it has a fantastic colorizer both in the MMC snapin and also in isqlw.exe. The quality is there in the MMC snapin; I don't know any devs who edit the sqlserver procs in anything other than the MMC snapin - but the lack of attention to detail is the fact that the proc/view/trig editing window is modal, and it doesn't even have a maximize button. That's just a crime. How many times have you been writing proc text and forgotten the name of a column or table, and been unable to dbl-click the table in the listview behind the code editor? If you're anything at all like me, it's hundreds of times. The terrible thing in this example is that it is so very easily solved if only the editor did not block UI access to the rest of the console.
I think I finally figured out the inheritence model for blogging:
Trawling through some past dev blogs, I encountered this by Raymond Chen.
This is just so true, and it has struck a chord with my development of autoCode. There are several places where I display msgboxs. Now, I have also felt that this is a totally intrusive thing to do, at the best of times. Like Raymond said, if you're going from A to B and along comes dialog C, you will just want to kill it: not even read it, but hit the Cancel or No button. Anything to just remove it; I know that I do this all the time, and I'm glad to hear that I'm not alone in being this impatient!
Of course sometimes an app really wants and needs to display info to the user, and wants him to read it. Enter the "Don't Show this Again" checkbox somewhere on the dialog, so that the user can absorb the info, safe in the knowledge that the app won't be troubling him again with it. This is good, because when I see a dialog with "Don't Show this Again" on it, it greatly increases the chances that I will actually read it.
This is all very well, except that it requires a custom System.Windows.Forms.Form, when a MessageBox.Show() used to suffice. Worse than that, it requires that the app in question tracks which dialogs the user doesn't want to see again, and which they do. This sucks large. What is wrong with:
i.e. give the WinForms runtime enough info to uniquely ID the msg in question, let the WinForms runtime do the lookup to decide if the user has previously elected to never see this particular msg again, and let the runtime append and manage a checkbox to the msgbox. This would be a Good Thing.
Just a trivial example of stuff that should be in the framework. It's like the framework is so advanced (at least compared with Win32 C-style, or VB-style development) that the ommisions seem all the more glaring, because what is there is so useful and labour-saving.
9/11: I dread this day coming, and driving to work this morning listening to the radio about the ceremonies being held in NY brought a tear to my eye. Man's inhumanity to man is truly astonishing; I would like to be able to pray for it to end, and for peace to prevail, but in my heart I know that God is not listening to our prayers. It is up to us alone to behave as more than animals, and to rise above our instincts of revenge. Unfortunately there seems to be little correlation between ones intelligence and ones ability to master these base violent instincts. Maybe it is because this world is so brutal and unfeeling that we love computers so much, with their order and simplicity: without any inherent confusion or chaos, but like a small microworld in which everything is of our own making, and everything can be right.
I'm having lots of fun & games implementing this particular feature, in particular maintaining acceptable perf levels, but that's a whole other blog. So here's a random observation based on today's development: it's so weird that I'm having to create an empty test harness to really prove to myself that this WinForms bug exists.
Basically, MouseMove event fires at random. It's true...! I thought that my mouse was at fault but unplugging it and using my laptop's trackpad produced the same results: namely the event would fire very few seconds in bursts of two or three events. The problem surfaced through my use of a subclassed RichTextBox, but even in a trivial test harness, controls like Form also exhibit this behaviour.
Maybe my mouse sensitivity is set too high, maybe there's some HW fault, but all in all I doubt these explanations.
I love the framework & the new winforms space espcially, but there remain many such niggles. The SQL editor in autoCode relies on accurate MouseMove events (it displays floating ToolTip-style information in response to mouse and KB input), so I've had to add code to my MouseMove handler to do an early-out if the delta between the last reported mouse pos and the current MouseEventArgs-reported mouse pos is zero. Not a biggie workaround, but so trivial that I'm amazed that I'm still having to code things like this myself!
This blog is all about the trials & tribulations of developing autoCode.
So far I've been developing autoCode for well over a year. It's intended to be a developer's tool which facilitates the best practices of database and distributed application development: stuff which I want and need to do my job as a developer - IntelliSense & AutoComplete for SQL, Code Generation, Dependency Visualization, all that kind of cool and labour-saving stuff.
In other words, I use this app myself to do my day job, and I add to it in the evenings and weekends: it's a labour of love, it's (hopefully) useful, but more than these two things -- it's a learning experience.
It's a relatively big-ish app and it's written using the relatively new .net framework. These two factors of being both big and new make for interesting coding...
This blog is also a response to the tons of cool and interesting stuff that's out there in the .net blogging arena; after having read and been stimulated by the blogs of some of MS' staff and users, here's my take on the subject. This is will all be real world stuff: driven by the development of a real world app: warts 'n' all.