Thursday, December 17, 2009

My new Android blog

I decided to start a separate blog fully dedicated to Android usage and development. You're very welcome to visit Wonderful Android: Using and Developing.

Tuesday, November 03, 2009

How to install missing LaserJet 4MPlus driver on Windows 7

 

I found on HP forum site the following advice:

The Laserjet 4M drivers (and many others)  are actually available through the Windows Update process.  Try the following:  go to the Printers folder, select Add a Printer, select the appropriate port, then when the "Chose a Printer Model" dialog comes up select "Windows Update". 

Unfortunately, there was one strange Windows feature or probably a bug... as it always happens with Windows. A first bug I discovered in Windows 7, which is actually much better than its predecessors.

When I tried to installed my LaserJet 4MPlus network printer on Win 7 64 bit by clicking Add Printer, as you described above, there was NO Windows Update button visible. Finally, I selected an incorrect printer model and installed that printer driver. After doing it, I right-clicked on a printer, chose Printer Properties => Advanced => New Driver and ... what a miracle: Windows Update button suddenly appeared!

If you ask me how did I find this way, I would answer: a long practice working with a buggy Windows software.

Tuesday, June 02, 2009

Classic ASP.NET: improper abstractions and ruined REST

http://herdingcode.com/?p=183

1. No one ever anywhere answered the simple question: how to avoid POST operations in a classic ASP.NET when GET operations should be used instead according to a common sense and REST.
POST - for changing data, GET - for reading. No one found any decent way to avoid "Web page was expired"  messages resulting from improper usage of POST. No way to PRG.

To me, this fact alone makes “classic” ASP.NET’s Web Forms approach inappropriate.

2. Yes you can find a workaround for anything, but you’re ending up battling against a framework rather than using it most of the time. And maybe even worse: you’re battling against MS tutorials and books which teach you that ASP.NET-in-24-hours-dataset-no-custom-code-monolithic development.

3. It’s pretty obvious to me, that event-driven model moved from Windows desktop development to Web does not correspond to Request/Response nature of Web and makes programming much more complicated, than even with a plain old ASP. I’d be pretty happy to have lain ASP + C# 3.5 + Intellisense, and believe me, my code would be at the same time more user-friendly and better structured than monstrous code-behind of those ugly master/detail ASP.NET pages.

4. I have nothing against Http Modules, Handlers, etc. They are powerful tools.
But I personally hate Web Forms so much, I think that all those words about Web Forms better in one situations and MVC in another is just a precaution: people understand that MVC is better but are afraid to talk.

Finally, everything is already said in this article and all the comments below.

Monday, June 01, 2009

“Mega” menu? Is it like almost unusable Office 2007 menu?

Usability guru Jakob Nielsen thinks that “mega” menus are good. But is it something similar to Office 2007’s “ribbon” menu?

Office 2007 menu is awful. It's a major step back from a standard and simple Office 2003 menu. Really hard to find what you need, you never sure which main menu bar link to click. My daughter told me to uninstall Office 2007 from her machine because she cannot find anything. If "mega" menu is something like that, I strongly disagree with Jakob Nielsen. The less pictures and other unnecessary graphical elements are in a menu - the better it is.

Wednesday, May 06, 2009

Rob Conery: I Suppose I’ll Just Say It: You Should Learn MVC

http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should-learn-mvc/

Comments under this article are as interesting as article itself.
I only hope I’ll be allowed to write my next ASP.NET project in ASP.NET MVC. I already bought Rob’s book.

Wednesday, February 11, 2009

Write deep Clone(). Forget about ICloneable.

I was chatting with my co-worker about implementing Clone() method for our hierarchy of classes. It's not easy to implement interfaces (think about ICloneable) for class hierarchies. Some tips might be found in Implementing Interfaces at C# Online.NET article, in Implementing Interfaces: ICloneable and IComparable article, and in Advantages of ICloneable? discussion.
As Zach said, it's easier just to implement a virtual Clone() method in a base class and to override it in derived classes as necessary.

I started to look for information about ICloneable and found the following quite unequivocal guidelines:

Caution. Avoid implementing ICloneable. As alarming as that sounds, Microsoft is actually making this recommendation. The problem stems from the fact that the contract doesn’t specify whether the copy should be deep or shallow. In fact, as noted in Krzysztof Cwalina and Brad Abrams’ Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Boston, MA: Addison-Wesley Professional, 2005), Cwalina searched the entire code base of the .NET Framework and couldn’t find any code that uses ICloneable. Had the Framework designers and developers been using this interface, they probably would have stumbled across the omission in the ICloneable specification and fixed it.
However, this recommendation is not to say that you shouldn’t implement a Clone method if you need one. If your class needs a clone method, you can still implement one on the public contract of the class without actually implementing ICloneable.

Accelerated C# 2008

Because the contract of ICloneable does not specify the type of clone implementation required to satisfy the contract, different classes have different implementations of the interface. Consumers cannot rely on ICloneable to let them know whether an object is deep-copied or not. Therefore, we recommend that ICloneable not be implemented.
The moral of the story is that you should never ship an interface if you don't have both implementations and consumers of the interface. In the case of ICloneable, we did not have consumers when we shipped it. I searched the Framework sources and could not find even one place where we take ICloneable as a parameter.
x DO NOT implement ICloneable.
x DO NOT use ICloneable in public APIs.
x CONSIDER defining the Clone method on types that need a cloning mechanism. Ensure that the documentation clearly states whether it is a deep- or shallow-copy.

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries