Serving as a mental note, and as a service to dear readers who hadn't been bitten by this yet.

javascript's parseInt method is not the same as .NET's int.Parse.

there's this 'radix' argument which is meant to tell the parseInt method whether we want to treat the string we parse as binary, octal, decimal, hexadecimal or whatever.

Now the naive programmer (a.k.a. myself) would think that the default is always base 10, so parseInt(x) === parseInt(x, 10) for every x.

Apparently parseInt tries to outsmart us, and it's actually guessing the radix if not set. so if x begins with 0x, it would guess hexadecimal, and if x begins with 0 it would guess it's octal.

so, parseInt('010') === parseInt('010', 8) === 8

ok, I can live with that maybe.

however it would also 'guess' that 09 is octal (even though 9 is not an octal digit !) thus parseInt('09') === 0

I found this by chance, when a Date.parse method I have was parsing "09/07/2008" into a date-info object with day==0, causing it to fall back into today's date

So, the lessons we've learned today:

1. javascript is not c#
2. always set the radix when using parseInt - parseInt(x, 10)
3. don't let your cat spill a glass of soda on your desk as it would ruin your earphones, and unless the laptop was on an elevated stand it would have ruin it also
   

Over two year ago, I have posted about the un-orthodox box model that IE6 is using. 

Yesterday I saw that Ohad Aston (an Israeli Web developer who blogs in Hebrew at the Israeli MSDN blogs site) has written a Hebrew explanation to the same phenomena, so if you do web, especially using ASP.NET and can read Hebrew, I recommend that you take a peek. And if you're there, subscribe to his RSS. I did.

Another quote:

Please don't use table even though they work fine,
when it comes to indexing they give searches a hard time

and also

Check in all browsers, I do it directly,
You got to make sure that it renders correctly

This should be in the curriculum for any webmasters 101 course

I have a html tag (image input) with id that looks like "delete-party-image".

On click, it should call XHR-ly to a server action, named DeletePartyImage.

Naively I did

var action = btn.id.replace('-', '');

which of course returned "deleteparty-image", because, as opposed to .NET's String object's Replace() method, this one (javascript's String.replace) only replaces the first occurrence.

Yeah, I already knew that, but have forgot it just when I needed it.

So for next time's sake - the way to do it in javascript is using a regex with global modifier:

var action = btn.id.replace(/-/g, '');

There's this cool little site that LOL-ify any web page.

This is how my blog would've looked like had I been a kitten. It would also most probably be written in LOLCODE.NET

Now, the interesting part.

I got that through Roy Osherove's blog. That's how his blog looks like when LOL-fied.

Can you see the difference?

When designing my blog's markup, I paid good attention to the fact that the actual content (posts) should come before the side-bar with links, archive, blogroll, ads or whatever.

The more 'legacy' kind of web design (usually with tables, but can also be "achieved" with div/css) is to box everything around the content, and having the ViewContents (or ContentPlaceholder) as the last thing on the Layout (or MasterPage).

So when my blog is being read by a machine (that parses html), the important things is first.

You might say - I don't give a crap about LOL sites, and my site is for humans, not machines.

But what about the blind who 'reads' helped by a machine that reads the page and say it out loud? must they get the whole links part on every page before they get to the content?

What about search index bots? we should help them get to the content.

The title say it all.

I really hope that IE6 would be obsolete as soon as possible. It would make writing decent markup much easier, not needing to look out for weird IE6 quirks. Also, won't need to hack my way into look at pages in IE6 (since my machine has IE7 for some time now)

Last month's IE visitors to my site (according to google analytics):

1. IE7 - 64.46%
2. IE6 - 35.47%
3. IE5.01- 0.06% (WTF? who uses that?)

I really hope that soon enough IE6 would join IE5 in the not-important area.

btw, IE visitors in total are 45.51%, so IE6 visitors are only 16%. wow. that's good, especially since the DotNetKick widget does not render well on IE6 and I never found time to fix that. I guess I'm not going to ...

My personal preference in javascript framework is prototype + YUI.

I take the language enhancements of prototype (enumerable/array, extend, $/$$), and the richness of widgets and event handling of YUI. One might say that prototype is my Javascript2, and YUI is the BCL.

These days I'm with YUI 2.4.1 and prototype 1.6.0

This week I needed to put floating color pickers on a few screens in a system.

Usually, the easiest thing would be to copy a pre-existing demo fro YUI docs. However, the color picker in dialog demo there was about the dialog posting to the server it's results, while I needed just to save the value into form fields.

The sample also uses a preexisting markup, which was not good in this scenario.

Plus, since the said system have a very complicated (and fragile) styling and scripts happening on many pages, strange things have happened to the dialog if ran more than once on the same page, so I've added a "destroy" method that would cause the dialog to be rebuilt each time. It's lightning fast, and has no visible effects on the user experience.

Another major change I've made to the sample, is the use of methods on a 'global' static object (CP) instead creating an instance of a function() and add the methods there (like the guys at YUI likes). The latter is nice in it's increased encapsulation, however the need to deal with the scoping issues is making event registration and event handlers too awkward imo.

Anyway - that's the code, you can use it as you will. Just remember it's "as-is", "no-warrenty" BSD thing.

YAHOO.ColorPicker = {};
// alias
var CP = YAHOO.ColorPicker;
CP.dialog = null; 
 
// creates the dialog with a color picker inside
CP.createPicker = function() {
    CP.dialog = new YAHOO.widget.Dialog("yui-picker-panel", {
        width                : '500px',
        close                : false,
        fixedcenter          : true,
        visible              : false, 
        draggable            : false, 
        modal                : true,
        constraintoviewport  : true,
        effect               : {
            effect               : YAHOO.widget.ContainerEffect.FADE, 
            duration             : 0.2
        },
        buttons              : [     
            { text:"Done",   handler:this.handleOk, isDefault:true },
            { text:"Cancel", handler:this.handleCancel } 
        ]
    });
 
    // dialog markup:
    CP.dialog.setHeader('Pick a color:');
    // placeholder for the color picker
    CP.dialog.setBody('<div id="yui-picker" class="yui-picker"></div>');
    CP.dialog.render(document.body);
    $(CP.dialog.element).addClassName('yui-picker-panel'); 
 
    // create the picker
    CP.picker = new YAHOO.widget.ColorPicker("yui-picker", {
        showhexcontrols   : true,
        showhexsummary    : false,
        images            : {
            PICKER_THUMB  : "/common/javascript/yui/colorpicker/assets/picker_thumb.png", 
            HUE_THUMB        : "/common/javascript/yui/colorpicker/assets/hue_thumb.png" 
        }
    });
} 
 
// in here I have used prototype to get the hex data. you can of course use
// YUI's getElementsByClassName, jQuery, or your own method.
CP.handleOk = function() {
    var hexField = $(CP.dialog.element).down('.yui-picker-hex');
    var hex = hexField.value;
    $(CP.targetId).value = '#' + hex;
    CP.dialog.hide();
    setTimeout(CP.destroy, 300);
} 
 
// removes the dialog completely
CP.destroy = function() {
    CP.dialog.destroy();
    CP.dialog = null;
} 
 
CP.handleCancel = function() {
    CP.dialog.cancel();
    setTimeout(CP.destroy, 300);
} 
 
// create the picker if needed, set it's value, and show
 
 
CP.showPicker = function(ev) { 
    if (CP.dialog === null) {
        CP.createPicker();
    } 
    var target = ev.target || ev.srcElement;
    CP.targetId = target.id;
    var val = target.value;
    if (val.match(/#?[a-fA-F0-9]{6}/)) {
        if (val.indexOf('#') === 0 && val.length > 1)
            val = val.substring(1);
        CP.picker.setValue(YAHOO.util.Color.hex2rgb(val));
    }
    CP.dialog.show();
} 
 
// registering the pickers on our color fields
YAHOO.util.Event.onDOMReady(function() {
    var fields = YAHOO.util.Dom.getElementsByClassName('color-picked');
    YAHOO.util.Event.on(fields, "click", CP.showPicker);
});

You can try to clean the CP.destroy method and see if it works for your scenario.

hmm, ofcourse, needed YUI files are:

• utilities/utilities.js
• container/container-min.js
• slider/slider-min.js
• yui/colorpicker/colorpicker-beta.js
• fonts/fonts-min.css
• container/assets/container.css
• container/assets/skins/sam/container.css
• colorpicker/assets/skins/sam/colorpicker.css

After reading the challenge on Dror's blog (Hebrew) I decided to post my answer here.

In short, for non hebrew readers, Dror is asking for a markup+css solution for the next layout:

no javascript allowed for layout purposes.

Oh, and the center column can be long, so the left and right columns should stretch with it.

I have added another prequisite: the center content must come before the side contents (for accessibility).

That's my simplistic answer:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional-dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Dror Engel's blog rocks</title>
    <style type='text/css'>
    div, body {padding:0, margin:0}
    #right-column
    {
        background-color:#FFA
    } 
    #left-column
    {
        float:left;
        width: 500px;
        background-color:#FAF
    } 
    #center-column
    {
        float:right;
        width:400px;
        background-color:#AFF
    }
    div.break
    {
        clear:left;
    } 
    </style>
    <script type='text/javascript'>
    function stretchCenter() {
        var center = document.getElementById('center-column');
        center.innerHTML += '<br /> Blah blah blah';
    }
    </script>
</head>
<body>
    <div id='right-column'>
        <div id='left-column'>
            <div id='center-column'>
            <button onclick='stretchCenter();'>Streach Center</button> <br />
            Center <br />
            Center <br />
            Center <br />
            </div>
            Left
        </div>
        right <br />
        <div class='break'></div>
    </div>
</body>
</html>
 

demo is here.

Reading David Heinemeier's post, it got me thinking.

In short (my words):

Since the meaning is what important, it doesn't matter whether you use Curse Words or their 'polite' euphemisms. The saying 'What the fuck is that' represents an honest question, while saying 'We should exile all those socially challenged foreigners'. Using Politically-Correct words in an outrageous sentence is much worse than a naive 'It's fucking great'.

Favorite quote from David's post:

...fake euphemisms that are actually much worse than the honest words they're trying to put a fig leave to.

Anyway, while thinking about that, a (bit far fetched) analogy came to my mind.

Many developers refer to 'HTML', 'DHTML' and 'Javascript' as curse words.

So they come up with euphemisms like Script#, RJS, WebForms and others, and by that, applying badly leaking abstractions on top of simple things. (HTML and Javascript are quite simple. you can see 13 year old kids that master those, but much less 13 years old master server OO languages).

Funny anecdote:

Writing this post on Windows Live Writer, the spell-checker is pointing out that 'fuck' is a misspelled word. One of the fix suggestions though is 'suck' ...  Ha Ha.

That's a great news for everyone who build websites and web applications.

IE7 would be installable even to XP users without the Genuine Check.

That means that in short time, the IE7 adoption rate would increase so much, that hopefully the annoying IE6 would become as obsolete as Netscape 4 and IE 5.5 ...

No more dirty CSS hacks (or at least, a lot less)

No more buggy box-model

Finally we can use input[type=text] and the likes

I've kept IE6 on my box for so long only to be able to test what I write. Even though I use Firefox for day-to-day browsing, I still need IE for some crappy israeli sites that would just not work on non IE (and by not work - I mean that you get an alert box saying:

For people who knows not Hebrew:

"This site supports IE browsers, from version 5.5 and up. Support to other browsers is planned for next release"

Ha Ha.

This message is there for at least a year.

And it's not even dependant on ActiveX or other IE magic. It's only some laziness regarding JS and CSS compatibility.

Well, it depends who you're asking.

It also depends on how good you look, apparently.

If you'd ask John Bristowe he'd say YES.

If you'd ask a good-looking software consultant such as Justice Gray, he'd just get angry at John.

Now, seriously, my view on that:

Javascript is a GREAT language.

It's VERY easy to work with(*) (and I mean, to do DHTML, not to write a WorkFlow engine or an OR/M).

You can O.O with Javascript, you can get functional, you're a dynamic as you can get, and it's THE most cross-platform thing today. It'd work exactly the same on every PC and MAC operating system from the last two three five years.

Of course, lousy developers can write javascript code that would work only on FireFox, or only on IE6 and a XP machine without SP2 that was installed on a full moon Thursday evening.

But note that these kind of developers won't be able to code a fizz-buzz in C/Java/C#.

And that's what so great about javascript.

It works even for idiots.

(*) It is. Just throw prototype.js (or any other) and you're a king. You say "it's not fair"? well, that's the whole point. Extending javascript from a "regular" one to a "prototype.js" one is possible, and even not that hard. Now try to do that for Java/C#/Whatever.

(**) The answer is No. If you haven't guessed that by now, then forget about Javascript. Hell, forget about programming all together.

So you say "Hey Ken, that's not fair. Ranting about the bad performance tips isn't good enough. We want GOOD tips".

I won't say that those are necessarily GOOD tips, however they are probably BETTER.

without further ado, I'll quickly pull out of my hat my somewhat better tips:

1. Learn to use caching, both for dynamic and static content.

2. TURN OFF ViewState (and ControlState). Find better solutions. Really. You do not need the viewstate to get txtName.Text. Just use the damn Form["txtName"], or write TypeSafe wrapper around the Form (or Request.Items) collection.

3. Learn SQL.

4. Use caching.

5. ADD Client-side validation to the Server side validation. DO NOT remove server side validation, as every javascript beginner can bypass client-side stuff.

6. Avoid SELECT+N.

7. Cache responses where appropriate.

8. Have as least external files as you can. Join all .js to one file. join all .css to one file. It takes a LOT more time for the browser to open a connection to the server, that to actually get those lousy extra 5k. And out-of-the-box, browsers can have a maximum of 2 connections to the server at once.

9. Cache DB queries when appropriate

10. Enable GZip on IIS

11. Use the "COUNT" keyword in SQL, rather than the "Count" or "Length" .NET properties

12. Did I mention caching?

13. Avoid Page where it can be replaced with an IHttpHandler. That code is BAD:

public class SomePage : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Response.Clear();
        Response.Write(something);
    }
}

Wow.

Take a look at that tip sheet.

Are these guys serious?

Best quotes:

3. Avoid Server-Side Validation
Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth.

huh?

12. Caching is Possibly the number one tip!
Use Quick Page Caching and the ASP.net Cache API!  Lots to learn, its not as simple as you might think.  There is a lot of strategy involved here.  When do you cache?  what do you cache?

if it's no. one tip (and it is), why is it numbered 12?

20. Option Strict and Option Explicit
This is an oldy, and not so much a strictly ASP.net tip, but a .net tip in general.  Make sure you turn BOTH on.  you should never trust .net or any compiler to perform conversions for you.  That's just shady programming, and low quality code anyway.  If you have never turned both on, go turn them on right now and try and compile.  Fix all your errors.

what's that has to do with performance?

I just can't believe that CodeProject has linked to that article.

Today I wanted to subscribe to the feed of Scott McMaster's blog (an excellent one, and a must read for WebForms developers).

Crappily enough, I found no visible feed/rss/whatever link on the page.

Luckily enough I'm using FF2 and I get the tiny feed icon on the address bar, so I could click it. Not lucky to all the poor fellows that still use IE6 and the likes (hey - get a valid copy of windows, or sack the IT guy who is afraid of upgrade, whatever's keeping you in the evil grip of the quircky browser)

So what should you do if you are that poor fellow?

view the page's source (that's "right-click + View Source), and look for a link tag within the <head> that sais

<link rel="alternate" type="application/rss+xml" title="THE SPACE'S TITLE" href="THE FEED LINK" />

now, if you've looked for the exact string written here you're hopeless, and should read a html book  / w3schools site before you start 'hacking' html.

Ok, I hope I'm not falling for a fruitless debate here, but after reading Scott's post about the impending death of HTML, and giving my notes on that, I've read his another post, now about "why you should only do windows development".

First of all - his blog is very good and interesting, and it's on my favorite feed reader now. Try and guess which one I use based on what you read here.

Regarding Scott's post, I'd like to mention two noticeable quotes:

It's amazing how much time and energy are put forth by people (yours truly included) trying to make the browser user experience more like what you could achieve with Visual Basic circa 1994, let alone Windows Forms or Swing circa 2007

and

Which begs the question of why folks are producing so many new browser-oriented applications in the first place.  But that's another post for another day.

Well, I concur. You should not try to imitate VB apps in DHTML. I can't see a possible for a decent Visual Studio replacement purely in the browser.

However, there are WEB applications, that a light-speed, no-install-needed, runs-on-every-machine-exactly-the-same website (gmail?) would beat any desktop app (Outlook? Thunderbird?) easily enough.

Let's think of another true WEB application. Blogging.
Let's say you were using a blog-engine with no HTML front. you'd assume your readers are running SilverLight/Flash/whatever, or have ClickOnce enabled with the appropriate .NET framework installed, or rather enough user-rights to make it work, or mac? or Java? 

So, okay. Let's say you'd go with Flash - EVERYONE RUNS FLASH, right?  well, almost everyone. But, come-on, tell all those c#/Java/Ruby guys that the need to switch to ActionScript? (or flex or any other flavour)? good luck with that.

Silverlight? promising, however in early Alpha.

ClickOnce - How many web sites using that do you know of? Even in Intranet environment you get IT people who are not willing to allow it.

Java? well it is on almost any machine today. Silver Bullet? Well, it doesn't take a Ruby developer to avoid Java. you can't get more static-typed than that, plus most java IDEs (but eclipse) suck big-time. I'd really rather use a text editor (even Edit.exe) over the OC4J bundle for example.

But, let's assume that VisualStudio for J2ME is out,(with R# 4), and everyone WANTS to write applets.

So you now have a "blog applet" and all most some of your readers can actually read your blog.

Wait a minute, you want to change the font face font color layout of the blog. How do you do that in Java? and how would you have done it if your blog's layout was dependant on a simple CSS file (the ultimate DSL imho)?

My point is - Web development is web development. It's as widespread as it gets. everyone can easily embed a html rendering engine into an application to make plugin support easy (all those vista/google/yahoo kawagadgets? html within the media players? custom buttons in WindowsLiveWriter), so the HTML/CSS/Javascript stack is: a. Everywhere and b. Easy to customize.   Sounds like Web to me.

Think that every 10 year old geek who have wanted to customize his cool myspace facebook whatever page should have learned swing/WinForms/Programming to do that?

In short: 
Writing desktop apps using DHTML is stupid
Writing Web apps using java/winforms/etc. is stupid.

No silver bullet, they both have their ups and downs.

Photoshop? Win

Blog/Forum? Web

Any other? Contextual

Oh, and it's Google Reader, if you've had any doubt.

Ok, so I've read Scott McMaster's post where he made some comparison between HTML and Assembly.

My first reaction had been: "Must be another of those HTML frightened guys". I know I have been one in the past.

But then I've read the small debate that evolved around that post, over at Ayende's blog, and I understand Scott's point better (even though I totally disagree, for the reason so beautifully written by Faisel).

Now I'd like to refer to the "Need of abstraction" for all those "I'm scared of HTML" guys.

HTML is easy.

Really.

Ask any 12 year who've read a "Build your webpage" book.

Ask any decent web designer who can hack together flying menus and 3d buttons without knowing the difference between 'for' and 'while'.

Browser compatibility issues? You kid me? w3schools + quircksmode, and thanks to FF+Safari+IE7 it's becoming less of an issue by the day.

Css? that's really a bright idea. Very intuitive and meaningful. The ultimate DSL.

The only 'problem' is Javascript, that wasn't maturing fast enough in terms of a standard library, but thanks to prototype and the likes, and since Steve-Yegge announced that NBL is Javascript 2.0, hopefully the browsers soon would implement some stuff to make Javascript the great language it should be in a standardized way.

Building a html/css combination to comply with a crazy designer's psd is a child's play. Adding an advanced "sort the grid, and do some async web calls" is easier than writing your own Data Access code correctly. I saw a lot more of a bad data access code than bad DHTML code, and since most Data-Access code is private while most DHTML code is wide open in the wild, I must conclude that it must be easier to make a website's UI work than to have connections open-late and close-early.

Remember, I was a web-scared guy for a long time, and Asp.NET 1.0 with it's ViewState and int.TryParse(txtAge.Text, out age) was the entry point to the browser for me. It took a lot for me to understand that I must learn HTTP, HTML and Javascript, and shockingly enough I realized that it's a far simpler model than the so-called "abstraction" of WebForms.

And in the future?

Silverlight/Flex/whatever could have been the future, but it surly ain't the near one. It's a matter of standards. xhtml 1.1, CSS 2, Javascript 1.2, those are standard. The differences between Safari, FF2 and IE7 are minimal nowadays. It would take a lot of time (imho) until most web-sites would run purely on a browser runtime thing. Not to mention that XHTML is cross platform down to almost any device these days. and that the textual nature of XHTML makes it very fast, and supportive of the "Let's index all knowledge over the WWW" thing that some small start-up companies (like Google) are pushing.

That was one of the strangest rants I've ever done.

Actually, it's not much of a challenge, but it is a catchy title.

Or is it?

Anyway, that's the details:

I'd kindly ask all of you ASP.NET Ajax wiz guys (and gals), to supply me with a simple UpdatePanel thing.

What should it do?

I want to have a webpage, based on this template, that on dropdown change, will go to the server with the selected value in the dropdown, and update the data (table) with some crap, based on the sent value.

You can leave the actual data retrieval to a simple method returning an array of string array, or you can go and implement a CodeSmith/DAAB/Whatever based supercool data access code. I would ignore it anyway. I want the Ajax stuff.

Now, to the why.

I am doing that MonoRail presentation at Microsoft's Israel IVCUG (Israel Visual C(#/++) User Group) next week. I might be showing some demos, and I want to be fare when I show a comparison to WebForms stuff, and not come up with a crappy code and say "ha ha", but show something that one of you, my-dear-readers-who-actually-uses-asp-net-ajax-for-living, wrote, and is considered a good example.

Also, I'm lazy. Seriously. Creating a presentation takes a LOT of time and effort, and I do not have much of the first, and rather avoid much of the later.

So, please do send me that code, to my-first-name at that-blog's-hostname.

thanks.

Regarding my last post on the matter, Justin has commented with:

Javascript debugging has been around since VS2003.
It's not the most obvious or straight forward as in VS2008, but it's pretty easy.
The "Script explorer" window in VS2005 lets you see all the files downloaded for a certain browser process Visual Studio is currently attached to. From those files you can set a break point.
So yes, it wasn't easy, but it isn't ground breaking either.

Josh took it one step further mentioning Visual InterDev.

I consider myself a rather sophisticated user, especially when it comes to IDE of any kind.

However, I did not use Javascript Debugging in VS2005 and VS2003, for the simple reason that it was not easy enough, and did not give me enough knowledge of the runtime vars etc. while using it.

When I started .NET-ing, I've had no VisualStudio license, and no idea about SharpDevelop. So I used notepad + csc.exe + WinDbg.exe . It's workable, but it sucks. Just like JS debugging in VS.

Since javascript runs in the client, on the generated markup files, and not on the server's templates (aspx, whatever), it's not as useful as FireBug's ability to set a breakpoint on a proper client html file.

Now, quoting from ScottGu's post:

f you add/remove/update the breakpoint locations in the running HTML document, VS 2008 is also now smart enough to perform the reverse mapping and update the breakpoint in the original .aspx or .master source file on the server.  This makes it much easier to get into a nice edit/debug/edit/debug flow as you are iterating on your applications

As I said - my main reason to move to VS2008 is it's multi-target support, and js intellisense. Sure, I can get js intellisense with a lot of cool non-MS tools, but I want to have a single IDE window per solution.

The easier js debugging IS ground breaking for me, as it seams that I'll be able to use it for debugging js in IE, a thing I'm not currently doing with VS since I don't like it so much.

This is why I'll be switching to VS2008, if That was not enough.

As Scott keeps reminding us, it (VS2008) will be able to target multiple runtimes, so we can keep using that against .NET 2.0 and .NET 3.0, no need to adapt 3.5 yet. (I wonder about targeting Mono from VS 2008 ...)

Until now, the JS debugging in VS was not too nice. Sure, I can use FireBug, and thanks to PrototypeJs I have almost no browser compatibility issues. However, sometime IE behaves strange, and I havn't found any decent way to breakpoint into js in IE.

Checkout the latest post of Scott Guthrie.

Is the long awaited JS IDE will be VS2008?

Now it's a matter of adding ///<summery> tags to prototype.js and maybe people would really stop being afraid of developing javascript code.

Now that's a good reason to switch to VS2008, combined with the fact than you can hold to your current .NET distribution.

Wow.

Another great tool from Google.

http://gears.google.com/

Works on Win/Mac/Linux, for IE and FF.

In a few words - it can give you offline browsing, plus local storage using SQLite (so you can run SQL queries strait from your javascript to query the local store)

I wonder what secutiry issues can come up. However, it looks very cool, and can help bring power to existing DHTML/Ajax apps.

Makes me think. Now that you do SQL from javascript, isn't it time for JsHibernate? and what about an ActiveRecord inplementation in javascript?

So, in the Flex/Silverlight war, it seams that Google is gonna win again ...

(from Scott Hanselman's Blog)

I am considering WPF-ing a new component for one of are in-house projects. So I've done some reading, and to be sincere, I am not too excited.

Let's refine the last statement. I am very excited with the technology. However, I find the examples out there very annoying.

It all seams to be "Hey it's so cool !! I can do stuff IN THE MARKUP - woosh, god save XAML".

So I came across this post.

It is just great!! it shows how I can easily use only 13 lines of XML to show a grind ONLY if the source is not null.

Sure a lot more expressive and easy than, say:

if (source != null)
   mySuperCoolGrid.DataBind();

I have just tried to do a xhtml validation on a site I'm working on (@ http://validator.w3.org), and I got some pretty wierd errors. It turned out the the DTD was not accurate, since the PUBLIC section contained lowercase characters.

So the right DTD for XHTML 1.1 is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/tr/xhtml11/Dtd/xhtml11.dtd">  

Now it passes the validation.

I've posted an article to CodeProject about building my Google Ajax Search Enabled Homepage.

So, go there, read it, comment it, vote for it, tell your friends about it, print it and glue it to your forehead, whatever you think is appropriate.

Unless you didn't like it. In that case, you shouldn't do anything. why bother ? :)

I have loaded a new homepage, and used a little of the Google AJAX Search API to make it interesting. Actually, I'm using it now as my browser's default homepage, instead of google.com

Not only that, but I have documented the process of making it, and have sent it to codeproject, to be published, as my first contribution there, in hope for more to come.

So, please leave your impressions, eiether here or in the codeproject article (I'll post the addresss once it will be up).

I've been off the radar lately, due to some extensive work I do on a website for my employer.

It is still in early stages and I cannot talk about the site itself, but I can talk a little about the technology that drives it.

In one word: Castle.

In a few more words:

Data Access and OR/m: Castle's ActiveRecord over NHibernate

Web UI Engine: Castle's MonoRail

ViewEngine: AspView (by yours truely, inspired by Ayende's Brail). All my spare time from work goes there.

Client Side Javascript stuff: Prototype and Scriptaculous.

I really believe in the efforts made by Castle group, and I hope the the site I'm working on will be successful, as to serve for yet another prove of concept.

One more thing I'm doing last month, is that I've decided to finally end the thing with my Bachelor's degree. I needed to retake Linear Algebra I (yep, that one the all the  non-bullet-time Matrixes ...   I H-A-T-E adjoined matrixes. yuck) so that's actually why AspView doesn't progress as I'd want it too (and as some of my readers want, too).

There is a nice post about naming the Atlas package, at
http://aspadvice.com/blogs/ssmith/archive/2006/08/16/Atlas_Naming_Game.aspx

There are some funny comments there, so do not miss.

And that is my comment:

"I think that too descriptive names suck.

I'd go with any non-descriptive name, such as the ones MS uses as codenames (I loved Avalon and so on).
I believe that from the marketing point of view, non-descriptive catchy names ar far better than the others.
It's like dice.com and monster.com doesn't include "job" in their name.

But since MS are determined to use descriptive names, at least they should concentrate on the "what" and not on the "how".
so "Async XmlHttp Enabled Web Apps" (AXEWA ?) is bad, while "Dynamic Web Browsing" is better."

<html>
            <head>
                        <style type="text/css">
            <!--
                                div
                                {
                                     width: 100px;
                                     height: 100px;
                                     background-color: aquamarine;
                                     border: 10px black solid;
                                }
                                #div1
                                {
                                     padding: 10px 10px 10px 10px;
                                }
                                #div2
                                {
                                     margin: 10px 10px 10px 10px;
                                }
                                #div3
                                {
                                     border-width: 0px;
                                }
           -->
                         </style>
            </head>
            <body>
                        <div id="div1">div1</div>
                        <div id="div2">div2</div>
                        <div id="div3">div3</div>
           </body>
</html>

content edge or inner edge
The content edge surrounds the rectangle given by the width and height of the box ...