Wednesday, February 23, 2005

Programmer Vs Developer Vs Engineer etc...

 Originally posted on:

A few days ago I read the post by Eric Sinc You need Developers, not Programmers and I was rminded of a few past moments. Let me just say I agree with what he writes, but I personaly don't mind being called programmer, even though I am a developer - programming is my main job after all.

I have had a few encounters that convinced me to say that I am either Developer/Engineer (I try to avoid engineer as it actually is based on a diploma which I don't have).

I was once in the Palo Alto area, for a short work visit, and went out with someone who worked there, he asked what I did, I said I was a programmer who does this and that and likes integrating applications... He said, "Well, for your own benefit, never introduce yourself as a programmer. Always Engineer, in your case it's best you say I'm an Integration Engineer". I thought he was right, first it does sound better, and secondly he seemed like a smart person, but I couldn't bring myself to do it. Eventually my company solved this dillema for me, and printed on my business card “Senior Software Engineer“ - don't ask me why, I didn't ask for it, and I don't complain. When people ask me what I do, it depends who asks. If a non-techie type asks me, I say I'm a programmer - it's easy for them to understand and relate to that, If I say I'm a developer, they sometimes ask me if I'm a real estate developer :-) If the person is a techie-type, or works at a tech company I ususally say I'm a developer...

A year or so ago, I met this girl who works in Amdocs in HR, she asked me what I did, and I gave her the standard answer, I'm a programmer... She gave me a disapproving face - I thought she meant that programmer=geek (a standard observation here in Israel), but she was cute :-) so I asked her what she meant - not wanting to lose face I guess. She said “Well at Amdocs programmers aren't really regarded as important”, The I made a face, and she continued “Developers are the real deal” - So I said “Oh! in that case I'm a Developer!”...

The Google Toolbar Auto-Link controversy

 Originally posted on:

A variaty of people (tons of them actually) have published some comment on this feature... You can finc them on any search engine by now, and among them...

A few threads on Google pulling Smart Tags Caper with Toolbar

Dan Gilmore: Google Emulates Microsoft, Uh Oh

And DG:  Brand Loyalty and Google

Anyway, I think the feature is great - well almost...

I had a slightly different experience with it than most people seem to have have, AND I have a feeling that if this was how Google implemented it, most of the controversy would have been avoided.

Let me say just this before, I don't like smart tags. And I agree with the people who think this is the correct way for Google to go, IF they want to lose me as a customer.

The way I tested AutoLink is by going to a web site with an address (I first tested on my company website and then instead of looking at what it did with the address on the bottom (I didn't even notice that it re-wrote the HTML) I looked at the options opened up when I clicked the down arrow in the toolbar itself. That gave me an option to lookup a map to the address (I already wrote about that here)... Now that in my eyes is a very usefull feature and also not too invasive or problematic... The toolbar informs you that it found something that might be of use for you (or not) and allows you a quick link to it - from the toolbar menu itself. That's what I liked about it - User controll. Google, disable the autolinking on the page.... That sucks!

Tuesday, February 22, 2005

Great Post by Scot Hanselman - Interview Questions for .NET Developers

 Originally posted on:

Go Here to read the questions:

It's interesting, as I've mentioned my team is slowly gearing up to the move to .NET - currently in more outer channels - a little hiring and some consulting to be able to establish time lines... I'm very eager for this move, and am always on the lookout for more .NET knowledge.

Its hard to learn new technology without the hands-n experience, I've got no shortage of tools, only shortage of time - no time to experiment, last time I've built a .NET project was two years ago (some web services in C#), I loved it, although it gave me a hard time (interoping with an old Java SOAP engine) - plumbing and formatting, but the programming itself was such a good experience, and because of the problems encountered which were to do with how .NET was receiving/generating the XML I got to understand some internal stuff, and to deal with the serializer a bit, from which I learned a lot. Nowadays I am swamped with work on work hours, and try to spend as much time as possible with my girlfriend and friends - who aren't really into computers at all, so we don't do pet projects for fun. besides whenever I think of something I need, someone already did it before me... So why do it again.

Anyway, the reasons I'm printing Scott's list right now, are:
a. I want to know the answers, so I can see here were I need to focus my learning
b. We are hiring and looking in particular for ASP.NET developers (preferably with some experience in VB and classic ASP) - since we don't know .NET that good, we can ask pointed questions based on the list (which means my manager is getting a copy :-) so that he can get us good people...). Oh, if you are a good .NET developer, Live Israel and looking for a job, you can send your resume to me...

Sunday, February 20, 2005

Continuing With UDTs...

 Originally posted on:

Back to my work woes...

Thanks to very helpfull people here (My friend from afar - Thanks!) and in SQLServerCentral (milzs) and some SQL Profiling... I found out the solution to this issue.

It all depends on how you actually call the stored procedure. Up until now we used to do first create the full command object (with the append method), and only then connect to the db for executing. In this method you have to specify data about your parameters including type (which was the problem). However, if you connect to the DB (assign connection string value to the ActiveConnection property) with the name of the SP already set. The Command object performs the following SP on the DB

exec [dbo]..sp_procedure_params_rowset N'isp_TestUpdateUserZip', 1, NULL, NULL

Which returns back a rowset detailing the exact parameters and data type of them, from theat point on - there is no need to specify explicitly any additional info besides the Parameter name and value. This behavior can be explicitly invoked by using the cmd.Parameters.refresh

Another interesting point is where you get the error (in case parameters don't fit the spec), In the first scenario - only when you execute the command, in the second - when you try to set the bad value.

After knowing what to look for MSDN offers this helpful article which also explains about the round trip, and the additional issues that this approach helps resolve. So now I have a complete answer and possible solution to a nagging issue. The only problem remaining with this solution, which is not that serious is that in order to modify a type you need to drop it first, and you can't drop it before droping all dependant objects........ Actually this is a serious issue, meaning that complex (but possible) scripts need to be built for each such occasion - maybe this is a good point why not to use this solution in the first place...

This restriction is very sensible, for example think of what would happen if you change a UDT  iudt_xxx nvarchar(4000)  to int? this can't be done, without rebulding any table using that User-Defined Type (not to mention indexes and functions relying on the type). Probably should have thought about this before... ;-(

Thursday, February 17, 2005

My 2 cents about SOAP Vs. REST (Cont.)

 Originally posted on:

After reading a comment here on my blog, (thank you stephen o'grady for actually commenting here, I really appriciate people that read). I though a little more on the subject. I remain basically at my previously stated opinion but would like to add a small exception, which of course for most of you is actually the main issue - so you would think I agree with you.

I think it is a vendors obligation to support the tools he provides. For a small vendor that would be supplying documentation amd bug fixes, for larger vendors, supply some code snippets and tools to use. This to a large extent is whats happening in this case. MS (and IBM, though I'm not really famailiar with what they provide) supply the REST developer with many tools.

You can use VS (also .NET) to develop any rest application you want, You can use WinHTTP (or XMLHTTPRequest) to test it in various ways (not to mention IE). Actually I believe that today more main stream automated QA tools support REST only, and do not even know how to deal with SOAP.

Code examples? Just take a look at older MSDN and other related stuff. It is practically full of it. How do you think I learned how to do it. See this for example.

The problem is, MS is not doing this anymore, hardly (if any) code examples of the old methods, certainly no articles in any magazine. No demos of exciting options, no Best practices or design patterns.

As a programmet who still uses these on a day to day basis, or as a system architect thinking of using such method, I would have liked to have this info from the source - i.e. Microsoft. Someone who is cerified to tell me what is better POST or GET, Key+Value, CSV? XML? I don't expect a framework because the whole beauty of REST is that you can do it anyway you want - IMHO that's the most powerfull feature, but some more info would be welcomed. I suspect that during the .NET development and through years of supporting these methods, Microsoft has more info than we can swallow - so please share with us. We would really appriciate it.

On the other hand, I understand MS has vested interest, so, to conclude, I don't want (I do but I can give up on) fancy dev events, and free CD's and toys. But a few Webcasts [* I work for Interwise we have some stake in webcasting - but I really think that it's a good tool for learning] or even better documentation on MSDN would be most welcomed.

The new Google Toolbar (V3) - Beta (what else)

 Originally posted on:

This is probably all over the net by now, but I just stumbled on the Google Blog (actually I look at it every day)

Google Toolbar 3 Beta was just released

  • SpellCheck: Whenever users type into a web form (including web-based email, discussion forums, and intranet web applications), SpellCheck instantly reviews and suggests corrections. The AutoFix option enables users to automatically check and correct all the text they're entering with one click.

  • AutoLink: Whenever users see a U.S. address on a web page, one click on AutoLink automatically links the address to an online map. For example, if users are reading a review of a new restaurant, clicking on AutoLink will turn its address into a link to a map, complete with directions. AutoLink also links package tracking numbers to pages displaying that package's delivery status and other useful information, such as Vehicle Identification Numbers (VIN) and Publication ISBN numbers.

  • WordTranslator: This feature translates words from English web pages into one of 8 other languages. Hover the cursor over a word and Google Toolbar's WordTranslator feature displays the word in French, Italian, German, Spanish, Chinese (simplified and traditional), Japanese, or Korean.

International verison coming soon.

What can I say, out of these three I personally will only use the spell checker, and even that in very limited places (I only write long text in this blog, and ieSpell is quite good when I do use it), all the other new features are only usefull for I18N types, or people who live in the US (again, not me).

I am dissapointed that there is no integration with gmail (incorporation of the notifier code, can't be to hard...). Of course I installed, it looks to be a better version in any case - supports all the old functions and behaves nicer, UI is also a little nicer...

[Small Update] The AutoLink feature may not be usefull for me, but it is unbelieveable, and works like a charm, you can for example go to and search for pizza stores (why do I always search for pizza) in New York city, and just watch the Autolink button fill up with map options. Just an excellent way of taking business away from the Yellow pages into Google hands - who needs yellow pages anyway? Just use local search for the same thing, looks much nicer on Google! Actually it seems like the Local Search/Maps are highly integrated with the Toolbar, while GMail is kept as a totally seperate product, no links from the Google main page and no integration to the toolbar. Seems to me that regardless of their statements, Google does not view GMail as a prime product, or maybe just not part of their search product. Maybe the Google religion, as a way of life to do things? Oohh I coined a new google phrase, lets see how long before it is adopted by the mases, and reaches 1st place on google for that specific search :-)

Wednesday, February 16, 2005

My day at work

 Originally posted on:

This is becoming a ranting blog, but actually today eventually turned out good.

Begin of day
1. Engineer at clients site reports a problem with installation, we start trying to reproduce - no luck, a little later a re-installation of the patch resolved the issue... Important client, good thing we didn't fail there..
2. Team leader assigns a new issue to me. Apparently a tool that we outsourced to a different company to develop was not behaving well. The tool does all kinds of IIS chores for us - defines new VDs etc... One of the chores is set NTFS permissions on the application folders. At some points it took over two hours to finish the process. Outsourcing company reply: “There were a lot of files.” Doing the exact same things from Windows UI took under a minute (not including navigating the UI which took two more minutes...) - Team leader to me: “Well, we have the source code of the tool, go fix it...”.

Makes you wonder why we outsourced it in the first place ;-)

Anyway, I look at the code, looks pretty straight forward - read the config XML file, for each folder apply settings. Using ADSI objects. I looked deeper into the code, and saw many deleting and setting. and decided that I'm not that proficient with the object and issues to optimize it and still be sure it performs the same. On to search for alternate options...

What I found after a little googling was fileacl.exe which I'm sure some of you already know. This is even distributed by MS link is to there. Unfortunately couldn't find authors' site to look up more information (only on google cache). Tested it for a while from the command line, after understanding saw that it worked exactly as I needed it, and much faster...

Opened up the source code of the utility again, this time modified it to call the exe instead of executing with the other (slow) method, a little more work to convert the data from the XML to the correct switches for fileAcl - and were done.

First test, realised I was doing something wrong with the Full Control permission, fixed - DONE a two hour run now takes under a minute. Thank you Guillaume Bordier .

Also thank you ShellExecuteEx always trusty from MS.

Another day finished.

My 2 cents about SOAP Vs. REST

 Originally posted on:

Well in the past few days I've been reading some posts, which seem to bring back some close by history, James Governor is bored by SOAP and more to the point doesn't understand why vendors don't support REST.  Mike Champion doesn't understand what all the fuss is about.

These are only two articles out of many. Mike kind of makes the point I want to make, and I agree with him completley. This is an old argument, that isn't really an argument at all. Basically everybody agrees on the issue, it just seems that the first side doesn't want to admit it.

Let's examine this: On one side (supposedly) we have REST, a simple way of calling a service through HTTP and getting an answer, in olden days this was some text, today it is usually an XML reply. This is undoubtably very simple to use, and too tell the truth is what I mostly use when developing Web based APIs. On the other hand we have SOAP together with all those WS-* and WSDL and the list goes on... This is a by far more complicated and cumbersome for developers, who rightly claim they don't want to learn this - who does?

The point is that these are actually two complementary solutions, they don't negate each other and can easily live together in the same application. However, they ARE different in a very essential way, as they are similar.

They are similar since both are used to call remote services through the network, actually invoke some function at a remote location (whatever that function may be).

They are different because of obvious reasons,
1. first they don't look the same. SOAP has much more gibberish (to human eyes) than REST. Basically the Calling syntax in REST is more simple than the one in SOAP (though the return can be baffling in both)
2. SOAP supports more methods of network transfer, while rest is very much attached to HTTP (not totally but still)
3. SOAP has a more strict way of making sure the message is OK, does anyone still remember those ugly exploits of IIS, just because of its support of REST (executing some system executable by reaching it through the URL)
4. SOAP supports (through those extensions) a wide array of authentication and encryption, and more... This might not seem as something that you can't do with REST (through SSL and IIS authentication for example). but in the SOAP case it is part of the protocol, and is implemeneted at the Service level, instead of the specific application (it follows a spec). Also SOAP + Extensions support this in more than just request/reponse model. which brings me to the next point.
5. SOAP isn't request response. HTTP is. This allows for just sending status notifications to many delegates without actually knowing them or caring.

I could go on and on, but the conclsion is the same, They are both here to use, use them when they apply, not for show.

One more thing, people are complaining about lack of tools for REST, well first there are many. Each normal webserver supports them by default. No normal CGI/* application server that deals with web ignores them. It is very easy to do it, all you need is a web browser, or some sort of HTTP control to manage the connection. Why do you need more tools than that. SOAP does need advanced tools. It is a complex thing that I can not work without some smart tool to tell me I'm doing it right.

Hope this makes sense to you...

Monday, February 14, 2005

Finally have some time to do long needed tasks

 Originally posted on:

For the last two months I have been in such a load of tasks to do, that I never even had time to take advantage of the fact that I got a new work computer.

For the last three years I have been working on a P3 600MHz workstation, I'm not complaining, it was an excellent machine and did quite well. The big plus was that I managed to get a memory upgrade for it so it was 256MB RAM instead of 128 - which was the main reason it lasted so long.

So a couple of months ago, one of my team-mates left our company for another job, since he came in later, he had a newer computer (they buy them on a need basis), a P4 2.8 500 MB RAM. I put in a request for it (I asked my boss if I can have it) and it was approved, since in any case we were expected to begin developing on Win2003/.NET environment - so more power was needed. However from that time untill today I didn't have time to create a working environment on that machine. Creating a working environment is a hard job here, especially in my team, because we each have the Web application installed on the machine and work on it. Since we work on many versions (we need to maintain back and forward versions in addition to the main version) this can cause issues, since actually the application can not co-exist with itself - there can't be more than one active installation on a single machine. Thinking about that limit. it is a little stupid, since it is not an application limit, but a limit caused by the application registry structure and some windows services that use them - TODO - research this (sometimes talking aloud makes me understand things better, and writing them down - helps me remember  them :-))

Anyway back to business, I'm almost done, a few more tweaks to do, some more productivity boosting utilities to install (I will post a list sometime of what I use, mostly freeware, and mostly mentioned in other places). And I will have a new lean mean working machine. Only problem is it doesn't have hebrew - I don't know why - but I will find out... Any of you Israelis/MS employees/just anyone can give me a hint on how to have Hebrew as an Input/Read language on Win2003 server?

[UPDATE] This question is no longer relevant, apparently there is a small check box in the regional settings area that when checked adds all those from left languages, an additional one allows for asian languages. Our helpdesk was very helpful this time - they usually are when you ask such questions.

Sunday, February 13, 2005

Technical Problem with UDT (User Defined Types) in SQL

 Originally posted on:

Can anyone help me with this? no prizes will be awarded...

SQL Server 2000 allows you to define user types based on the exiting types (excluding CURSOR). This is then supported throughout SQL Server and T-SQL, so that you can use this to define Fields, Parameters in SPs and more. Enterprise manager supports this as well, by loading these custom types into the design view of tables.

What do I need UDTs for? well in our application we have many database tables and fields, we have found more than once a need to change some field definition, causing a cascading change in all relevant tables/views/functions/stored procedures, and of course the functions in the VB 6 data layer that we use to invoke these objects.

Recently we thought using UDTs is a good solution, since (as far as we can figure out) you would only need to change the defintion at the basic type level, and the change will bubble up (assuming you wrote your code to use it, i.e. wrote your SP to accept this type by type name).

All the basic tests on the database level look good, however we are stumped by one major (to us) issue: How do we make this work from the VB layer? we use all over the command object to interact with our stored procedures (we try to do most everything with SP), however the command parameter object only accepts members of the Type Enum of the ADO which obviously does not support my custom type.

Looking around the net I have been unable to find a solution, I suppose the only way to do it, is to change it in both places, both the DB and VB layers (maybe using constants to limit the amount of work to do).

Does anyone have an idea of how to accomplish this? is there maybe some other way to do this? is using UDTs even a good idea - or are we missing the whole point?


Tuesday, February 8, 2005

Pheeewwwww! Back to my old application maintenance

 Originally posted on:

Didn't write here for the longest time, I hope I can write about what I've been doing for the last month or so soon (once the contract is signed, probably or maybe never :-()

However today I'm kind of over that, since I delivered my last build and barring all kinds of bugs that might be returning my way from testing, I'm done, or am I?

Decided to tackle a bug that was assigned to me some time ago with hopes that I could find time to look at it, so I did. The bug describes a situation when a configuration option in the application is set so that middle names of users are displayed all around the site (this is a web site application, but not located at a single point, i.e. not an ebay but sharepoint).

The bug described a situation where long first middle and last names were used, that was my first clue. The other clue was the error returned by the application - 3421, at first I thought this was an Internal code, but quickly decided against it, since a quick search on code (well not that quick) revealed, that at no point this number is event used (just to clarify, searched code includes ASP files, VB files, and even the DB source code Table and SP scripts). So I decided that this is probably some windows/external component error. Quick search on google gave me the following reply - “3421 - Application uses a value of the wrong type for the current operation. “

This data combined the two bugs together, this looked like I was probably sending a too long string into some function that interacts with the DB.

Running through the re-construction/production of the bug, pointed me finally to a specific function storing the User data in one of the database tables, still even though the data sent was long, it wasn't too long. The data described by the tester, was less than 40 chars per field which is what it should be, so why the error?

And there was my answer, the display parameter for middle name, is an addon to the original application, before that Middle name was stored as part of the user details, but never displayed at all anywhere else besides user management. At one point in the life of the product, someone decided (or some client demanded) that it be displayed, and the long work begun. Finding each and every place that first name and last name is displayed and making sure that if so required middle name be displayed along with it.

Now this was done as it should be, except in one place, there is one client application that works with our web site application (actually more than one, but never mind) this application receives from the web site the user data. And one of the requirements was that it too would display the middle name. However, at this point apparently no dev power was to be wasted, so it was decided that no modifications will be done on the client side, but instead, when giving the information over to the client, the web site will combine the First name and the middle name and send them both as first name (the client handles this somehow by trimming off the extra chars it cant display in the length allowed).

However at some remote point in the system, in some obscure table, that holds data, with some function that insert this, this effect was missed, and when storing the data to be sent to the client, it was stored as FName+MName instead of splitting it, and was given the limit of the First Name only (40 characters) so that when a slightly longer than normal name+middle name was sent - it failed...

One more bug off the list (I don't know maybe 1500 to go????)

BTW I forgot to mention, the error wasn't there originally, however at some point an additional feature was added that forced the application to keep track of certain activities (hence the new table)...

I know this sounds like a rant, and indeed it is. But there is a lesson. Sometimes the quickest solution isn't the cheapest :-)