NFC for Access Cards

Why not, indeed ? My phone is pretty much my life. I should be able to use that to swipe in to office.

Read More

iPhone 5

A lot has been written about the iPhone 5; more than that can be justified from the features introduced. Very few people, though, have provided any insightful comments on the new Lightning adapter. So I’m going to speculate.

Why did apple feel the need to introduce the new adapter?
The stated explanation is that it enables the new lighter and slimmer hardware. This is arguable, but I find it hard to believe that Apple would make such a drastic change solely to produce the slimmer version. The cynical explanation is that the $29 adapter is pure, unadulterated revenue for APPLE Inc. , given the minimal cost of the hardware and even amortizing the R&D costs.
Both of the above explanations do not sit well with me and can only be considered as secondary benefits.
Speculation
An alternate explanation that occurs to me is that there is a new product in R&D phase that requires the much smaller, reversible connector. If the primary purpose was to make a smaller connector, then the reversibility aspect would not play and it would be more efficient to design a single sided connector. This means that reversibility is an integral part of the design.
What kind of a device would require a reversible connector ? A head-less device is one option.
Anyways – as I mentioned, more than is deserving has already been written about the new iPhone. ‘nuff said. literally.

EDIT: http://techcrunch.com/2012/09/16/nice-phone-apple-but-whats-the-deal-with-the-29-lightning-to-30-pin-adapter/

With micro USB compatibility, the scynical explanation is looking more likely.

Read More

stumbling over the EntLib blocks

just when i had thought that 1.1 to 2.0 migration was going to be done within a week, I stumble upon the Enterprise Library application blocks migration from the June 2005 (.Net 1.1) to January 2006 (2.0).

The first approach i took was to replace all the assemblies with their 2006 version ans get rid of any obsolete ones ( e.g Configuration.dll ) - This completely wrecked the build. So now, I'm going to take up the migration assembly by assembly... slooow and careful, just as recommended

Microsoft.Practices.EnterpriseLibrary.Common
replaced the 1.1 version with the 2.0 version, Cleaned solution, Re-built;

Errors-
The name 'ArgumentValidation' does not exist in the current context

Fire up Lutz's reflector and notice that not only ArgumentValidation, but thenamespace it used to reide is gone in this release.




Fine, i'm not going to do any argumentvalidation. It was a sort of "nice to have" in any case . No complaints. Just commented out the offending statements. Build succeeded.

Microsoft.Practices.EnterpriseLibrary.Data.dll
replaced the 1.1 version with the 2.0 version, Cleaned solution, Re-built;

Errors -
The type or namespace name 'DBCommandWrapper' could not be found (are you missing a using directive or an assembly reference?

Ahh, so thats gone too ?

As per documentation, the replacement for this is System.Data.Common.DbCommand. And here is the example

Original Code

Database db = DatabaseFactory.CreateDatabase();
DBCommandWrapper dbCommand = db.GetStoredProcCommandWrapper("GetProductsByCategory");
dbCommand.AddInParameter("CategoryID", DbType.Int32, Category);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

Modify to

Database db = DatabaseFactory.CreateDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory");
db.AddInParameter(dbCommand , "CategoryID", DbType.Int32, Category);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

Take a close look - yes, you got it - Now to add in parameters you require both Database + DbCommand. So it is not going to be a straightforward replacement.

The application i'm migrating has literally thousands of calls to DbCommandWrapper.AddInParamater. Worse still these calls are made through another static Helper class, that does some business validations before actually calling AddInParameter on the DbcommandWrapper. And obviously, the Database object is not passed into it.

A typical signature for the helper function looks like

public static void AddStringInParameter( DBCommandWrapper cw, string parameterName, string parameterValue)
{
if ( null == cw )
return;

cw.AddInParameter( parameterName, DbType.String);

if ( null != parameterValue && parameterValue.Length>0 && NotAvailable.sNA != parameterValue)
cw.SetParameterValue( parameterName, parameterValue);
}

So this is a huge problem now. With this static helper class being used liberally all through the application, method parameter modification is not feasible. Manually repairing the code to pass in the Database object into such functions is also not an options just beacuse of the sheer number of times it is used ( >5K calls ).

At this point i realize that my basic need to Add parameters without needing Database object is essential to a painless migration.

Luckily, the internal implementation of DbCommand still allows the addition of parameters using the Parameters collection and without the need for a Database object. In addtion  DbCommandWrapper was very useful in hiding the complexity of CreatePararamter and Parameters.Add() by exposing the AddInParameter function family.

Now the functionality is exposed on the Database class; which is puzzling; as it could have been very easily implemented in the DbCommand class. Maybe a question for Tom.

So anyway, I decided to nick the code for DbCommandWrapper from the original Entlib (1.1) code. This would solve 3 problems- 1) obviously it would re-instate the class and make all the references valid again; 2) It would allow me to add parameters the way i was used to - without the database object. 3) at the same time keep the migration issues internal to the Wrapper class.

Hopefully, this would work with a few well-aimed hacks. And it did - just beautifully.

I copied the class code files exactly as they were into my namespace. This got rid of the original DbcommandWrapper not found errors. I then applied a few hacks on these Wrappers -

• The original OracleCommandWrapper (OCW) is a concrete implementation of the (abstract) DbCommandWrapper (DbCW) ; In addition DbCW has a private mustoverride member IDbCommand, which OCW overrrides with OracleCommand . Changed IDbCommandrresponding DbCommand in System.Data 2.0.

• Created a new constructor that accepted DbCommand, and got rid of the other constructors. This means that the new wrappers now are "Real" wrappers, in the sense that they don't have ability to create the DbCommand internally. Retaining the code to create the command, would have meant pulling in more source from the EntLib. I decided to avoid this.

so far so good - The DbcommandWrapper has re-incarnated and the AddParamter family of references are also now available. The code fit back into the jigsaw again.

unfortunately, I could not protect all of my code, but at least the further changes could be done by intelligent search and replace operations

• System.Data.Database in the 2.0 versions replaces the EntLib.Database and it has no awareness of a DbCommandWrapper. So all the references to Database.Get[]Wrapper functions are no longer valid. These are all Database.Get[]Command functions now. Well, with what i consider a stroke of pre-science, we had decided to wrap the Database class with a custom DatabaseWrapper class that would hide (almost) all functionality of the Database class. Facading paid off ! In fact, the code broke exactly where we had been to lazy to facade some workings of the EntLib - Lesson learnt.
• All the IDbConnection, IDbTransaction, and IDbCommand reference had to be updated to the new classes from System.Data.Common namespace equivalents - DbConnection, DbTransaction, DbCommand.i>
• Database.GetConnection() has been replaced by Database.CreateConnection() . Search and replace.
  

The search and replace operation took about 15 mins.
>
Ahhh - no compile errors . The code is fitting in snug and tight -no ugly patches required. Life is good again .


... to be continued. Next migrating the Configuration block

Read More

Head Hunt

This summary is not available. Please click here to view the post.

Read More

the nokia 5500

As most of you know, I lost 2 mobiles within the space of a week - Since then, I worked out the theory that I subconsciously wanted to lose them because there was my true handset lying in wait for me - And surprisingly enough, the very week I lost these phones, the Nokia 5500 was released in India. Hallelujah - Its fate; karma; and its sporty !!


It has all the features of a N-72, but nokia spared the ugliness. AND its cheaper by a bit. Here are some reviews

Pope uses Nokia 5500 to solve middle-east crisis
Nokia 5500 makes man stallion in bed

and it goes on. Worth the 15k ?

Read More

.Net 2.0 migration - continued

and we're off to do some migration.

Got my first look at VS2005 - nothing radically new. Of course, its been cutified a lot more - nice colorful icons and all that jazz you can expect from MS :-/

On the down side the "Web Site" model compiles slower than molasses going up a slope. No, seriously - its at least 15 times slower than what the solution used to compile under VS2003.

I'm getting ahead of my self here. To even get to the compilation stage i had to first run the Conversion wizard. The conversion tool spits out a nice little XML document logging the results which show up in our VS2005 screen once the conversion is completed.

Going through the conversion log, I didn't find anything unexpected - some files that were not included in the project were shown up as warnings.

Before you start compiling, I'd suggest you clear out all existing binaries from the bin folder of your projects.

Compiling the solution straight aways threw up the following errors (some of these were because i had "treat warnings as errors" turned on) -

• ToString (IFormatProvider) is now obsolete - amazing how FxCop (MS tool) ALWAYS yelled at me for the exact opposite. I can't even count the number of substitutions i made less than a month to make FxCop complaining and now VS2005 complains. Bah!
• ConfigurationSettings is obsolete and to be replaced by ConfigurationManager - simple search and replace operation.
• The type 'xxx.yyy.zzz.Global' is ambiguous - got rid of this one by clearing out the binaries and compiling again.
• Few other random obsolete functions classes to replace - nothing too complicated.

It took me about 4 hours to get the solution to compile, primarily because VS2005 was being obnoxiously slow at compilations. Researching the problem threw up some helpful posts from ScottGu - whu else ? here and here again Scott tries to help people optimize the compilation speed, mostly laying the blame on referencing external binaries ( and possible version conflict ). This explanation doesn't wash - I had none of those issues- barely 5-6 external references without any version conflicts and still the web site build made me shave twice - unacceptable. I really do want to know why is it slower than VS2003.

Moreover, to frustrate me even further, VS2005 in Web site model, throws out compilation errors in batches. So just when i would manage to get rid of 10, another 10 would show up on recompile - unbelievable. Its almost like they took away functionality with the web site model.

These guys will describe what a web site model is and what it is good for ( its all lies - the web site model is a abominable regression)

VS 2005 Web Project System: What is it and why did we do it?

Apparently some developers wanted it easier - no compilations, no fixed files in project, just copy and paste. So that means we all miss ASP ?

Anyways - after the conversion, I end up with my perfectly functional web applications ripped apart and all non-code behind files moved some well know directory called App_Code ( remember the ever annoying _vti_ directories- ha ha ). So now my code looked like this




I realized that this Web site model was not going to work (at least for us )for the following reasons

• Only Buddha would have enough patience to compile the Web sites.

• Deployment was going to a major pain. Assemblies are randomly generated to support the web site. I'm sure there is a work around - but why bother ?

• In an enterprise environment, we want the strictness of explicit inclusion of files. The Web site model, it dawned upon me, is for - well, Web Sites- and not applications.

• VS2003 structuring of Web Application was perfectly sensible and usable - why change it ?

I found caught myself fondly remembering the days of VS2003 - where Web projects were real projects (with actual files to support their existence) and not weak-kneed references to directory or this new-fangled ftp.

Funnily enough, MS released the Web application model for VS2005 sometime after the world screamed in anguish. Now its a part of VS2005 SP 1. Scott Gu's link takes care of all you need to know about Web Application projects in VS2005 and how to migrate from Web Site model to Web Application model.

And the Web application model looks like this

Then i go get the Visual studio update and follow steps . Now instead of App_Code - I have Old_App_Code. Although it all compiles pretty well. I had some issues with Code behind refernces and Web References which did not take too long to sort out.

The Web application project is much better - and guess what - not only does the solution now compile faster than web site, its faster than VS2003 as well!

Testing the code had me puzzled for a while. I knew i was doing everything right. My machine was set to using only the .Net 2.0 framework, thanks to the big red switch. Yet IIS seemed to be having trouble with the situation. Finally i figured out that you must go to the Asp Net tab in inetmgr and manually update it to use the 2.0 thread (don't worry - it'll be obvious once you get to the tab).

Everything worked after that. Well I had deployed and got working a solution with 30 projects with 5 of them being web projects in under 3 days. Not bad.

Special thanks to ScottGu, without whom many of us would still be struggling with migration. He has with relentlessly scoured the web to help out people with migration pains. Cheers Scott!

Read More

.Net 2.0 migration

I'm onto a new project with a very clear goal - migrate .net 1.1 code to .net 2.0. Now this would not be so interesting for small projects. But hear this - while we are emigrating to 2.0, another team will be migrating some components from c++ / COM to .Net 1.1 - that should make things really interesting. Plus throw in the facts that the back-end is Oracle, Apache server is used for reports; 3rd party tools used charts; some of the code dates back to the 90's; AND the team is is distributed across bangalore and US - you will see some really nasty situations and how I (hopefully) get out of them.

Watch this space.

Meanwhile here is a compilation of links to getting started on migration.

As a by-thought, my reflexive Microsoft-hating muscle seems to be shrivelling. Ever since .Net MS have become developer friendly. What has really helped is their collection of talented individuals who have now being given the freedom to frank, nay - even critical , of MS technologies. MSDN of course is MSDN and everything must be taken with a truck of salt, pepper and your favorite spices. The real meat is from the MS techies and their fairly unbiased blogs.

MSDN links -

Microsoft .NET Framework 1.1 and 2.0 Compatibility
handy guide to defining your approach towards migration. The most useful information is the table for application load mechanisms. Also has links to other MSDN resources for migration

ASP.NET 2.0 Migration Overview
very brief outline on the why of migration

Migrating from ASP.NET 1.x to ASP.NET 2.0
Code behind concept has changed and this tells you how. Be afraid. Be very very afraid.
Also we no longer have project files - well known directories will do the job ( I smell unix - i do i do). Complement this with Rick Strahl's Understanding Page Inheritance in ASP.NET 2.0

Breaking Changes in .NET Framework 2.0
Just glance through these - I doubt many people will be affected by these. Keep it for reference and impressing interviewers.

.NET Framework V2.0 Obsolete API List
You don't just want to make your solutions compile - right ? Treating "warnings" as "Errors" in your compilation has just made life painful. But don't be lazy and upgrade propahly by getting rid of obsolete function calls

Side-by-Side Execution of the .NET Framework
Most enterprise applications will have to go through a phase of side-by-side execution. I suspect its not going to be as straightforward and deterministic as this article suggests. But thats just me being cynical on the outset of ANY project.

Common Web Project Conversion Issues and Solutions
the title says it all

Microsoft .NET Pet Shop 4: Migrating an ASP.NET 1.1 Application to 2.0
Microsoft's case study using their idea of an ideal application which of course uses only MS products ;)

One the most trusted sources on .Net, ScottGu, has a bunch of extremely helpful articles. Do take the time to also go through the comments on the articles. Read these in order.

why the VS 2005 Web Project
Insightful and honest. Pulls no punches in explaining the drawbacks of VS2003. you are not required to agree with everything, but will definitely understand the reasoning behind the changes

Using IIS with VS 2005 and the new Web Project system
Equally useful as practical information on IIS and .Net as it is on the differences in VS2005

Some techniques for better managing files in VS 2005 Web Projects
when he says virtual directory - he means virtual directory that is also configured as *application*. I spent a few minutes getting confused (then a comment on the post cleared it up).

Building Re-Usable ASP.NET User Control and Page Libraries with VS 2005



don't just take Microsoft's word for it( who does? ) . Check out other people's experiences. Note that ScottGu is all over the place helping out everyone (who matters). He deserved a huge bonus last year.

Ricks Strahl comes up scratch

Eric Bowen has resource problems in VB 2.0

Andru does things right and removes obsolete calls ( see .NET Framework V2.0 Obsolete API List )

ScottGu bails someone out again - toolbar control issue

DotNetNuke.com has migration pains


Hope this helps and happy migrating.

Read More