More a short rant today than anything else. If you are writing a DAL most of it can be generated and be completely boilerplate. Everything looks the same, acts the same, is called the same way.very beautiful.
There’s always exceptions, however. Sometimes you just NEED to do something more complicated. Inserting into multiple tables at once, possibly across different databases.
The project I’m working on has a very consistent way of putting database operations in transactions. I’ve been troubleshooting a number of problems in the app where the app will crash after trying to save some records. The proc seemed to be working, it was returning a new id and everything was happy. Why couldn’t the app find these records?
Because the stored procedures fall under the exceptions to the rule above and the developer of them thought it would be best to do transaction handling inside the stored procedure.
Two problems, one the transactions across the linked server didn’t work because of configuration issues. Secondly, the stored proc did a try . catch . rollback without calling RAISERROR.
I certainly think that transactions inside the stored procedure can clean up some of the client code, and help in situations when the stored procedure can be called in many different places and always needs to be transactional. Just keep in mind that unless we let the calling client know something went wrong it’s just as bad as swallowing exceptions in C# or VB. Fail fast and hard, as always.
Virtualization in WPF is amazing when you get it, annoying when you lose it. I’m working on a form where the user can dynamically filter and sort a ListBox. I’m using a DataTemplate to give a nice card-like view to each object, which makes it take up a lot of space on the screen. To fix this I used the WrapPanel as the ListBox’s ItemsPanel.
WrapPanel is not virtualized, I can’t find one that is and don’t have any time to write one myself. So I came up with a work around to give the user a fixed number of column view using the standard panel for a ListBox. This got me virtualization back. Then I wanted to smoothly scroll so I turned ScrollViewer.CanContentScroll to false. Smooth scrolling, no virtualization. Because this box may have thousands of records in it, performance is much more important than smooth scrolling.
The moral of the story is, if you’re working on something in WPF and performance is important and you might have a large dataset coming in. Double check your changes to controls to make sure you’re maintaining virtualization. If anybody has a good list of what disables virtualization (grouping, custom panels, smooth scrolling), I’d like to see it.
Last night I was fighting with repairing my MythTV box, the final remaining linux PC in my house. My video card went down and trying to replacing it the nVidia that was in there with the ATI replacement I picked up turned out to be too frustrating. Steps I went through
- Backup/Restore of KnoppMyth
- #2 caused a bad xorg.conf to be used, and install crashed
- Un-tarred the backup, replaced bad xorg.conf with a failsafe xorg.conf, re-tarred
- Repeat #2
- Video card works, KnoppMyth installation crashes
- Powered through, MythTV up and running, can’t talk to backend
- Reconfigure backend, can see recordings, can’t watch them
- Networking doesn’t work
- TV-Out doesn’t work
- Give Up
- Try to pull recordings onto portable hard drive (NTFS formatted, ha, good try)
- Download Knoppix w/ NTFS write support
- Run LiveCD
- Copy files to portable hard drive
- Wipe linux
- Install Windows
- Install GB-PVR
Before I started working at Magenic none of my computers booted into Windows by default. My laptop ran VectorLinux (based off Slackware) and my main PC ran Fedora, Ubuntu, etc based on what I wanted to try that week.
The MythTV box was running rock-solid for years, and I loved it. It was the last bastion of my free-spirited geekiness in my increasingly Microsoft focused world. Now, it has but hours left to live. Maybe I’ll put Ubuntu on my laptop for old time’s sake at some point. Who knows?
Speaking of, Windows 7 RC is out now to MSDN. THAT is going on my laptop immediately tonight. I think I’ve been fully assimilated. Even Winston eventually saw the light and learned to love Big Brother.
Encapsulation is one of the major tenets of object orient programming. The ability to not worry about how things work behind the scenes and just use a component is lovely.
Recently, I’ve had to be a on a project where a lot of UserControls have been created and tons of them reference their parent property internally to get some bit of data that they need for this or that.
First of all, not only have you completely broken encapsulation by doing that, but now you can’t use that UserControl on any other form.
My favorite part of encapsulation is easy refactoring. We all make mistakes and wish we would have written something differently, and if we have the time to correct those mistakes we should. Recently, a developer wanted to give the UI a bit more user-friendliness so he threw a bunch of splitter panels on a form with some grids and UserControls to let the user customize the form a bit.
The problem is one of the UserControls referenced it’s Parent property. So now instead of ((parentForm)this.Parent).SomeProp I had to go back and fix the bug he introduced by doing this ((parentForm)this.Parent.Parent.Parent.Parent.Parent).SomeProp just get it to run. I realize shortcuts can save a ton of time in some cases, but why is Control.Parent allowed to exists when it makes it so easy to break encapsulation and lead to big problems with refactoring down the road.