Log in

No account? Create an account
It's fascinating when you can catch your mind playing tricks on you.… - Silicon Rose [entries|archive|friends|userinfo]
Silicon Rose

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Dec. 29th, 2008|01:22 pm]
Silicon Rose
[Current Mood |dorkydorky]

It's fascinating when you can catch your mind playing tricks on you.

For those of you that don't know, I am indubitably a middleware/system software developer. I've maintained a file system filter driver and a Windows service. I've written and maintained COM classes. I've done P/Invoke and COM interop. I've written msil. I've debugged driver failures. I've worked with SQL, XML, and XSLT. I hesitate to call myself functional in ASP.NET, because while I've worked with it quite a bit now, it's entirely been with service level software, and that's really not what people think of when they say "ASP.NET". (I think they think of that funny <% %> syntax that makes my head hurt.)

The only really "UI" thing I wrote was a system tray application that monitored a branch of the registry for status that could be summed up in a single string, and to which you could issue requests to change said branch. That required the sum total of a system tray icon, a tool-tip, and a context menu. Not exactly rocket science, and definitely not interesting UI layout or complicated data display.

Despite never being much for it (unlike most programmers I know), I've started writing little applications to help me get things done. The closest I'd ever come to this before was writing a perl script to scrub my NaNo submission. I guess part of it is that I know C# reasonably well now, and it's a good language for just getting shit done in. I'm not sure whether I mentioned this here before, but with the addition of LINQ in C# 3.5, it's now an imperative language with the ability to drop into functional or relational syntax in several of the cases where it makes sense. I can't describe the joy I felt when I realized that C# now allowed me to stitch SQL data from queries executed across seperate servers together with code that more or less looked like SQL, and which was almost as natural as SQL. C and C++ are great languages, and quite efficient when well-written, but the level you had to go to in order to simply get something done always pissed me off. Note: I'm aware this is probably due to the fact I never got comfortable with the STL. The sordid story of 'why' starts in my first college programming class, where my introduction to the STL was blemished by frequent encounters with five to eight line error messages which made no damned sense at all and sent you off on goose chases through your code just to find out it actually meant you forgot a semi-colon or you couldn't template that type like that. Anyways, I digress. Back to my mind playing tricks on me.

I have occasion to write something that should probably be a persistent application that delivers notification and has a UI to provide a general status overview when required.

It's amazing how I was (offline) whining about working with HTTP just a handful of days ago, but now my mind keeps asking me whether I could go back there and just do that data download, and maybe put a console frontend on it, and do I really need to do a UI, really, really, huh? Ooh, look, you should do that data processing part first! Who needs a UI when you've got a debugger! ...etc. In other words:

Dear mind,

I know it hurts, but you are going to sit down, shut up, and learn WPF. 'Kay?

[User Picture]From: ketsugami
2008-12-30 04:23 am (UTC)
Lemme know if you need to bounce some WPF ideas around or need help or whatever. I went through a lot of that when I was first hired and thought I'd be doing WPF projects. ^^;;
(Reply) (Thread)
[User Picture]From: siliconrose
2008-12-30 05:08 am (UTC)
Lessons I learned today:

When writing a wrapper class using Dispatcher in order to transparently use an ObservableCollection on a non-UI thread, do not use BeginInvoke, even if the example you're using uses it. If your background thread is enumerating through items to add to the collection and calling Insert on successive numbers, you may get an ArgumentOutOfRange exception because, while you think you've put an object in there already, it hasn't made it through to the object yet, and thus you may be calling Insert(1, x) when Count still equals 0. Call Invoke instead. Hell, it's not like it matters if you block the background thread, does it? (<-- it doesn't in my case)

Like, multithreading is hard enough, but when you combine it with the magic of WPF it becomes black voodoo death magic.
(Reply) (Parent) (Thread)
[User Picture]From: ketsugami
2009-01-01 06:46 am (UTC)
Yes, that makes sense -- when you use BeginInvoke to do asynchronous calls you don't get a guarantee of in-order processing. However, the correct way to do it is not to block the background thread but rather to pass the whole collection into BeginInvoke and do the additions all at once I think? Generally I know the pattern is when you have a big block that requires in-order, you glom it all into one dispatch.
(Reply) (Parent) (Thread)
[User Picture]From: siliconrose
2009-01-01 08:35 pm (UTC)
Yeah, makes sense. Ugh.
(Reply) (Parent) (Thread)