start.com is pretty cool. Also, it's a bit similar to one idea I've been thinking about.

(There are one or two similar sites I've seen are also cool, I don't remember the addresses now)

Of course, it's very beautifully executed(as most things Microsoft are).

But currently it's not very usable.

As an RSS reader - it's nice, but there are other online readers that are a little better. (like Google's)

As a  way to view all my important stuff at once, a portal - hmm, it doesn't feel right. I can handle a few extra clicks for the benefit of seeing what I want in a full browser window and not in a small part of it. I may be wrong on this one.

The real benefit will come, IMO, when the portal will begin doing some clever manipulation on the data it displays from various sources (which is what my idea does). Then these sites will become successfull. Maybe.

Currently, start.com is just a great demo of several techniques(which is exactly how they want it right now).

Online Poker has been a huge hit on the internet for the last couple of years, but I only discovered it a week ago. I tried once before and didn't like it at all (well, probably because I quickly lost all my dough). Turns out I wasn't playing the right game.

The big thing in the world of poker right now (offline and online) is Texas Hold'em Tournaments. That's a game of Texas Hold'em (obviously), in which you pay a certain amount of money to get into a table (usually 6 or 10 players), everyone receives an equal amount of chips, and you play until all players but one lose all their chips. The winner or winners (the people who where the last ones playing on the table) split all the money.

Let me tell you - it's one great game, not at all what I thought.

There's also a "multi table" version, where you have much more players (100 up to 600) that play on many tables and as some get eliminated, players are moved to other tables until the total number of tables decreases and eventually, again, only one player remains in the game. In the multi table tournaments usually the players that placed in the top 5 (up to the top 50, depending on the initial number of players) split all the dough.

I've been a bit hooked for the past week.

Here's why it's so attractive:

(1) The game is very positionally sophisticated - the strength of your current position ("hand") is affected by many factors - your chip count, other player's chip counts, stage of the game, size of current pot, the order in which cards were dealt and bets were made, number of other players currently in the game. And I'm not even mentioning the actual cards you hold (that matters), the cards the other players hold (matters as much) and psychology.

(2) And still it's very simple too. You can teach the rules to a five-year-old. Monkey that is.

(3) It's very exciting. Because you're up against other actual people (not A*-driven aimated shapes, you bloody geeks), you're always pretty close to being eleminated, and every decision you make is very weighty - it's a real adrenaline rush.

Sad thing is, I cannot make money playing it. I can just barely even out. And that's probably true for you too, if you care to know.

But it's a lot of fun, so try it.

There are tons of sites that offer the game, most are very similar. Thousands of people play at every given moment. I play at Betfair, which is very good.

Went to the Dead Sea for some grilled meat and camping with Dani and Or. Was windy but fun.

The ones I read now.

(a) South American Handbook 2005. (Wonderful antidepressant)

(b) Steppenwolf. (Great)

(c) The Now Habit. (Don't know)

(d) The 100 People Who Are Screwing Up America. (Funny, not always right, doesn't prove the point)

This is what I plan right now:(even though I know it's all bound to change)

A map.

Fly to Buenos Aires(probably on 30/12). Spend 2-3 weeks there, work on the Espanol. Fly to Ushuaia, Tierra del Fuego. Do the "must" hikes(like this). Slowly climb north (on buses) to the Lake District of Chile/Argentina. Spend some time there. Then north via Santiago to north-western Argentina and North Chile (Mendoza, Salta, Tucuman...). Then south, back to Buenos Aires via Cordoba. This should be March. Then to Souh Brazil via Uruguay. Probably stay in Florianopolis for two weeks to start on the Portuguese. Then North to Rio. Stay there for a while. Maybe relatively short trips to Sao Paolo, Brasilia and other places in central Brazil. Then North to Salvador and the surroundings. Then Belem and the Amazon region to Manaus. From there to Bolivia. From Bolivia to Peru.

After that I'm really not sure, but maybe Equador, Colombia, Mexico and home.

Wow, I just checked and it turns out I didn't post at all here for a month and a half.

The reasons are, in case you wondered: (a) Laziness, pure, unadulterated; (b) Shifting interests, slightly.

(It's funny how I keep forgetting the spelling of certain relatively-simple words. "Wonder" - I always forget which one is "Wonder" and which one is "Wander". And also "Difference" - never get it right. Funny.)

Anyway.

I'm going to South-America for a long time in two months, and that's all I think about anyway, so I feel stupid posting about stuff like Atlas and the like, though it's all very interesting, even to me, now. But still.

On the other hand, I'm not used to posting massive amounts of small-size-personal-issue-posts here. I mean, what moral ground do I have for that? Why would anyone read that crap? Guess it's a self-confidence issue basically. Gotta have moral ground.

But today I decided I want to write a little bit, just for the fun.

You're not expected to be any smarter or sligtly entertained after reading this post, just you'll maybe understand better where the posts from now on come from.

Yours truly.

Okay boys and girls, read my post about the little kinky control I'm doing here first.

Today I decided to have a go at fixing problem #2, which looked like it could lead to solving #1 and #3. One may say it's a problem-solving problem-solution. Right. So.

As you remember, I didn't like having a regular ASP.NET page acting as my HTTP handler. That's because it's not (1)deployable, (2)general, probably not (3)too-well-performing, and well (4) smells.

So I thought I'll implement it as a proper ASP.NET HTTP Handler.

Here's how you do it:

1. Write a class that implements System.Web.IHttpHandler.
   Here I already have a feeling how I'm going to solve the deployment issue: I put my IHttpHandler implementation in the same assembly the WebControl lives in. Now they're deployed together.
2. All you really care about here is to implement the method ProcessRequest. You are given an HttpContext context parameter, and that parameter can give you everything the Page gives you, like Request, Response and so on. Notice that the Page class itself implements IHttpHandler. Basically what you're expected to do here is look at the HTTP request you got and output some HTTP response. Fun.
3. My initial solution did that in the Page_Load of the handler Page. So all I had to do is move all my code to the ProcessRequest of my IHttpHandler implementation and add context. to all the Response, Request and Session uses I had inside the code. 
4. If you need to access the Session, like me, mark your IHttpHandler with System.Web.SessionState.IRequiresSessionState marker interface.
5. Register the handler with the web.config of the application:
   I added <add verb="*" path="*.mspx" type="HandlerClassName, AssemblyName" /> in the <httpHandlers> section of <system.web>.
   The verb is what HTTP verbs you want your handler to catch (POST, GET, PUT...).
   path - requests for what resources you want the handler to catch (I chose to catch all files with an .mspx extension, I'll probably change that to something more specific). Notice you don't really need a specific file like "TheBitz.mspx" to exist on your server. You won't get a 404.
   type - that's the pointer to your IHttpHandler implementation.
6. Register the handler with IIS. This one is just a little bit tricky:
   Go to the IIS MMC -> right-click the wanted web site -> Properties -> Home Directory -> Configuration... -> Add. Now point the wanted extension (in my example ".mspx") to the ASP.NET dll. (Just copy it's path from the .aspx line)

Now I replaced the URL in the client-side XMLHTTP request to some URL on the web site with an .mspx extension and the request went to the newly created custom HTTP handler. Pretty easy.

But here's an annoying issue I'm having:

I'm calling an old COM component (VB6) from that handler. Remember that .NET and COM threading models don't match (MTA vs. STA). Now if you wanted to call COM components from an ASP.NET page you marked it with an ASPCOMPAT=true attribute in the @Page directive. That forced the page to be handled on an STA thread. But I have no clue as to how to force my custom hadler to run in an STA thread. I tried:

1. Marking the ProcessRequest method with and STAThreadAttribute.
2. Calling Thread.CurrentThread.ApartmentState = ApartmentState.STA.

Both don't work. The damn model stays MTA. And that's logical, why should I expect to change the threading model after the Thread started? That was just plain idiocy of me I guess.

So I'm pretty unhappy right now.

If you have any tips, do write. Thanks.

Troubling Thought #1 - "AJAX-enabled", is that a word??

On we go.

At work, we have us a nice Web Control. Currently I'm adding to it some functionality that will get data from the server without posting-back the whole page.

So I started with implementing this stuff in the most straightforward and naive way possible, because I wanted to see it work. Here's how:

1. I added some custom javascript to the control's behavior file. That javascript catches some client-side events, creates and XMLHTTP object, builds a custom request in XML format, sends it to the server, gets an XML response back, decodes it and displays the data to the user.

2. On the server I wrote me a simple asp.net page(that's ver. 1.1).

In that page's Page_Load I call Request.BinaryRead to get the request XML, then I decode the request, get the needed data, build an XML out of it and then Response.Write it back to the client.

And the amazing part is - it works.

So now I'm just left not too happy with the implementation. Here are the issues I see:

1. I don't like to see that custom handling of XML encoding/decoding and XMLHTTP-related code in the javascript. Ideally, I want some framework that will handle that for me. What I want is to call a client-side function and have some server-side method get (magically) called for me.

This is exactly what the cool ajax.net framework does, but it does so for Pages. Your server-side method has to reside in some specific Page. And me, I have a web control, not a specific page.

2. Using a standard asp.net Page as an HTTP handler doesn't smell right. And probably performance-wise it's not best either. I probably should implement some IHttpHandler or something (at least that's what I think they're called). I read once that's as easy as getting porn on the internet. But I never actually did it. (The former, that is)

3. On the same note, how am I to deploy the web control now? Telling the users to put a specially designated .aspx file at a fixed location in their web app isn't all that classy, is it?

That's it for the real stinking stuff I guess.

I'd appreciate your take on the three issues, and some additional suggestions while you're at it, if you have them.

Thanks.

I'm looking for a new monitor for the home PC. It should be an 17inch LCD.

I think I'll get the BenQ FP17G+.

If you have that one or have another suggestion - please drop me a line.

Setup:

1. You have a page with a data-bound DataGrid.

2. The page makes multiple post-backs (for example, the DataGrid is editable).

3. There are template-columns in the DataGrid.

Here's the tip:

Make the ID of the DataGrid and the ID of the controls inside the template controls shorter.

See, the DataGrid control renders all the HTML elements it needs to display your data, and assigns them id's based on the ID of the grid itself and the ID of the controls they represent.

Have shorter ID's and the eventual HTML page that travels to the user will be much lighter. How much? We recently saved between 20% to 30% in a page that used to weigh in at around 500KB, and that's a lot.

Consider the following simple example:

I have a grid with two data-bound columns. The ID of the grid is "CitrusFruitData". Each column is a template-column. The item template of both contains just one control - an asp:label with and ID of
"Label1".

If I bind 100 records to it, the output page is 36343 bytes long.

View source, and you'll see the something like the following (about 200 times...):

<span id="CitrusFruitData__ctl7_Label1">... 

Now if I shorten the ID's of the grid (to "Cf"), and the two labels in the item template of the two columns (to "L1"), the resulting output shrinks to 32930, which is an easy 9% improvement.

And when you have more columns, and more controls in the columns, and more rows in the grid – the improvements will be more dramatic.

But wait, crazy man! What about readability?

True, your code will be less readable, but this is one case when I will prefer the performance over readability. And the readability can be easily contained, if you're smart about it.

Good luck.