Rants Tagged with “Programming”
<< < 1 2 3 4 5 6 > >> (Total Pages: 6/Total Results: 59)
In this new post on Mark Russinovich's blog, he walks though his experience with a new e-mail that installs a zombie attack. Interesting to watch his approach. Well worth the two minutes.
New Features Should Always Support Disabling
I use a Dish Network satellite dish for my TV. They pushed an update last week to all their subscribers. This new feature is a great idea: if an HD channel is available for a channgel (e.g. ESPN, Local Channels), tune the HD channel instead of the non-HD version. Normally that would be perfect...except...not all HD versions of channels have the same programming.
For example, Discovery channel ahs an HD version they call Discovery HD Theatre. They are actually two different channels with two different programming. For example, two of my favorite shows are not shown on Discovery HD because they aren't in HD (Discovery HD is completely HD, they never show non-HD shows (AFAIK)): Dirty Jobs and Mythbusters.
The way they implemented the feature is that in their guide it shows both channels and lets you pick which one you want. For most users of the dish this works fine. They can pick which channel they want.
For me I don't watch much live TV. I record most shows. When my PVR thinks its recording Mythbusters, it changes the channel on the dish to the channel #. But now the Dish changes to Discovery HD which has a completely different show on.
Dish Network acknowledged to me today that the feature should have a way to disable it but it doesn't. When I called them to find out how to fix it, they said that I couldn't...but if i'd give them a month to fix it, they'd credit me for a month of service.
The lesson here is that no matter how good a feature you think you are about to push out to customers, you should always have a way to revert the feature. As developers, we are usually nothing like our customer base so we often can't see the forest through the trees when it comes to new features. Its a lesson I have certainly learned before...
After reading this interesting article by Pablo Castro, I have to assume that the real purpose of using Async Execution is for specific use-cases when you need to fire off multiple concurrent queries in service situations (e.g. ASP.NET, Web Services or Windows Services).
There are several interesting observations in this article:
The first one i'd like to point out is in the "Keeping WinForms Applications Responsive" section. He states explicitly that the BackgroundWorker is a better solution than using Async. This means that you should avoid using it in UI-based apps (probably WinForms and WPF).
Another observation is detailed in this quote from the article (emphasis added):
"Note that if you know you'll use a given connection object with synchronous commands only, it's better not to include the async keyword in the connection string, or alternatively include it but set it to false. Execution of synchronous operations on connections that have asynchronous operations enabled will have noticeably increased resource utilization."
This leads me to two conclusions:
- Async connections won't be pooled with non-async (since they have different connection strings).
- You will need to weigh the higher resource utilization against the performance improvement of concurrent query execution to determine whether to use it.
Also, since you can manipulate a resultset from each concurrent query at the same time, it seems that the async keyword also turns on MARS on the connection, but I do not have any evidence of that...just a suspicion.
My advice? Take time and read (carefully) what Pablo Castro has to say in the article and only use the Async functionality when you have a very clear case of concurrent execution in a service environment (ASP.NET, Web Service or Windows Service).
Feedback is encouraged...
While this link has gone through many other sites already, I wanted to inlcude it here to make sure every dev in the world reads it! It is an excellent list of the types of influencers that have made me decide to quit being an independent in the past and try to be an employee again. If you are workign for someone else, print this out and leave it on their desk. Its important that non-dev's read this and understand it.
My newest DevSource article is live. It is about how to write Windows Live Messenger Addins with .NET. Check it out
I was helping a friend out this evening trying to get a simple GridView working with a HyperLinkField from a database result and we ran into an interesting security feature that people might run into:
If you add a HyperLinkField to a GridView's Columns to allow a hyperlink in a column (pretty standard), it will create hyperlinks unless the URL starts with something other than http:// and https://. In our case, his DB has an URL of:
FILE://\\somemachine\someshare\somefile.txt
Because it was a full URL but didn't start with http or https, it didn't show the link. Change it to:
\\somemachine\someshare\somefile.txt
If you're interested, there was a Bug Report filed and MS explained why they did it:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=0400b837-db21-4828-90c7-4df607795501
I am working on a project where I have separated the Typed DataSets into a separate Assembly. I nievely made the Typed DataSets use a named Connection String in this assembly. So when I attached to the Database when creating my DataSets, I saw that it was using a Connection String called "MyConnection".
In this assembly, the designer created an app.config and a Settings.setting object. All sounded good. So in my ASP.NET 2.0 project, I setup the connection string in the web.config and called it "MyConnection". This all worked until I deployed it to a server, when all hell broke loose. After deployment, my code that did *not* use Typed DataSets (mostly DataSources) worked fine with my new "MyConnection" connection string...but...
Everywhere I used the Typed DataSets it was failing to connect to the database. When I looked at it it seems that the Typed DataSets were using the connection string I used on my dev box...but no app.config to be seen. How was it getting that bad connection string? Well it seems that the connection string information is being embedded as the "default" connection string to use if it can't find the connection string in the configuration. Ok, this is bad...I'd hate for my assembly to actually have stuff like my password embedded in it, but I doubt that happens. I was using integrated security so I haven't tested the password embedding yet.
But what is strange is the connection string was in the web.config. What gives? Well the Typed DataSet satellite assembly named my connection string with namespace and setting prefixes. "MyConnection" became "MyApp.Properties.Settings.MyConnection" because the serialization of the name includes all of that. Yeech...
For now I added that as a connection string to my web.config and got over my initial issue, but I am still digging to find a better solution. I'll let you know what I find.
Usually I don't like to link to mailing list archives, but this is an excellent reply to a question on the Advanced .NET Mailing list. Ian explains this better that I have read before. He covers why you would choose one over the other for the security and perfomance implications of each. It's a must read IMHO.
I submitted a bug to Microsoft's ASP.NET team that objects added to the Component Surface (right-click and pick "View Component Designer") aren't visibile to controls thereby breaking 1.1 data binding. Here's the response I got: They closed it with:
Thank you for submitting this issue. At this stage in the Whidbey product cycle, we're taking very few changes into the product. We have evaluated this issue and will not be able to investigate it before release but we’ll reconsider it for the next version of the product at a future date. To help us better evaluate this issue, we would appreciate if you would send email to webntppb@microsoft.com with the FDBK ID of this issue in the subject line so we can contact you later, if necessary. For more information, please refer to the announcement on the MSDN Product Feedback center at http://lab.msdn.com/productfeedback.
Rich Ersek
The Web Platform & Tools Team
I resorted 1.x Binding because the DataSource data binding does not work much with legacy controls, so this just breaks 1.1 sites. That is just unacceptable. It is unaccepable to not even try to reproduce the problem, especially since it is a real problem for people migrating 1.x projects.
I would guess that means they want us to just stop putting in bug reports. I am disappointed...
As many of you might not know, I am not at the PDC, but am interestingly watching to see what comes out from it. Usually at the event times, everyone blogs too much about what they like and don't like. Everyone wants to be the first out the door with some news from a keynote. So I am layng low and letting all that happen without me. On the plus side, I can now talk about some things that I've had the opportunity to play with for some time (now that they are public knowledge and I am not hurting any NDA's):
- I've been playing with the WinFX PDC bits for a couple of weeks now and I think it is coming together nicely.
- The Expression designer is cool, though still a bit wonky for extended use.
- I like the ideas behind LINQ and C# 3.0, but like the C# 2.0, I think it will change a lot between what we see now and what will be used in production.
