Slashdot Mirror

Search for "cuil sucks" or "cuil is just spam and it sucks" (without the quotes) in both Google and cuil.
(http://www.cornetdesign.com/googlevscuil.html)

Why are Google's results correct and Cuil's wrong?
If I search for Slashdot Wikipedia I would expect a slashdot article about wikipedia. If I search for Wikipedia Slashdot I would expect a wikipedia article about slashdot. Hell if you want to search for a wikipedia article, why dont you just go to wikipedia first?

Well actually it looks like they changed their search algorithm.
Google returns some good results from both wikipedia and slashdot. Cuil only returns 369 results, the first being the wiki article about the /. effect, and the rest are unrelated to /.
Check it out with http://www.cornetdesign.com/googlevscuil.html

If they return results that don't have anything to do with the first search term, they are pretty useless.

I put up a page to help compare the results:

http://www.cornetdesign.com/googlevscuil.html

Did the same thing for Live:

http://www.cornetdesign.com/livevscuil.html

I put up a page to help compare the results:

http://www.cornetdesign.com/googlevscuil.html

Did the same thing for Live:

http://www.cornetdesign.com/livevscuil.html

You mean like this?

I use it all the time. I think it does a /better/ job than Outlook at that aspect.

but I won't be using it anytime soon.

Wrong. It will be in the next version of VS. Right now, it is a pretty awful implementation for TDDers (very slow, but some cool integration features), but they are working on making that better.

Not that I agree with what is going on with Jamie. All he ever asked for was the clause he was violating and he would happily remove it. They haven't provided that yet.

Hahaha.

As an engineer who is right in the middle of helping our customers make the changes necessary for the DST fix, it is much more complicated than that.

First, you have all of the servers and clients which rely on one another. The biggest effect is on mail - Exchange/Outlook/OWA.

Second, you have to do it in the right order, at about the same time. If you update the server, then clients who schedule appointments will be off until they update.

Third, you've got software which calculates various things based on that date. Think financial transactions, etc.

I've blogged about the tool we have to help customers figure out what has to be done.

I wish it was as easy as just updating a script, but when you have to coordinate that change across 10s or 100s of thousands of servers, clients, etc, it's not an easy task.

And let's not forget Microsoft isn't the only one having to make changes. Lotus Notes, Groupwise, Blackberries - they all have changes that have to be made. I'll personally be glad when this is all done. Ugh.

I view XP as a methodology to solve a major problem I've seen in software - communication.

Why do we build software? It's to provide value for our customer, whether that customer be a marketing department, a gamer, or ourselves. And if we don't keep in touch with what it is that they want (recognizing that people generally don't know what they want until they see it), we probably won't provide the value we could.

To that end, XP encourages constant communication by using frequent releases of the stories (read: features) the customer thinks are most valuable. The customer gets a working version every week, or month, or 2 months, or whatever cycle seems to work for the team.

From the development side, XP encourages the code to always be potentially shippable by having a suite of Unit and Acceptance tests (the former written by the developer /before/ the code is written, the latter written by the customer(!)). We continually run them using a Continuous Integration server which monitors the code repository and checks out the latest version, notifying the team of any conflicts.

It also encourages things like Collective Ownership, where, in theory, any developer can sit down and work on any part of the system. This is achieved partly through the unit test suite, and partly through pair programming with frequent swapping (we swap pairs generally twice a day, in the morning and at lunch, but some teams do more, and some do less).

But, regardless of all the practices (and there's more than I'm listing above), the end goal is /not/ to be "XP", it's to deliver value to the customer. And if your current practices are doing that, then that's what is important.

As far as TDD, I have a series I recently did which shows how TDD works here (part 1) and here (part 2).

I view XP as a methodology to solve a major problem I've seen in software - communication.

Why do we build software? It's to provide value for our customer, whether that customer be a marketing department, a gamer, or ourselves. And if we don't keep in touch with what it is that they want (recognizing that people generally don't know what they want until they see it), we probably won't provide the value we could.

To that end, XP encourages constant communication by using frequent releases of the stories (read: features) the customer thinks are most valuable. The customer gets a working version every week, or month, or 2 months, or whatever cycle seems to work for the team.

From the development side, XP encourages the code to always be potentially shippable by having a suite of Unit and Acceptance tests (the former written by the developer /before/ the code is written, the latter written by the customer(!)). We continually run them using a Continuous Integration server which monitors the code repository and checks out the latest version, notifying the team of any conflicts.

It also encourages things like Collective Ownership, where, in theory, any developer can sit down and work on any part of the system. This is achieved partly through the unit test suite, and partly through pair programming with frequent swapping (we swap pairs generally twice a day, in the morning and at lunch, but some teams do more, and some do less).

But, regardless of all the practices (and there's more than I'm listing above), the end goal is /not/ to be "XP", it's to deliver value to the customer. And if your current practices are doing that, then that's what is important.

As far as TDD, I have a series I recently did which shows how TDD works here (part 1) and here (part 2).

I use Monowall here at home, and it does a good job of managing the PPTP connections. Since you have a PPTP client built into the other Windows machines, just use something like DynDNS and point them to connecting to you.

I wrote a simple tutorial on getting PPTP running with Monowall. I run it on a small solid-state linux box, and it works just great.

Ahem. I'd like to take that point out.

As with any technology, you get people who have no idea what they are doing who shouldn't be doing it. As an earlier poster pointed out, taking HTML created by Frontpage and doing anything meaningful with it is a nightmare. If you start with the standards all along, then conforming to them is a lot easier.

But Flash is more than just a pretty image viewer. Actionscript can be a powerful tool not only for manipulating frames, but for XML parsing, server to client communication, and lots of other uses. Take for example a prototype at http://www.cornetdesign.com/e2xml.asp. Nothing flashy about it, it's primary job is to take a dynamically generated XML document from Everything and convert it to a format for people using Pocket PC's. Is it the best for the platform? Maybe, maybe not. Another group of developers is working on a native platform viewer.

So please spare me the argument that because lousy designers do lousy stuff with a product, that the product sucks. I'm sure I could build a C++ application that would really suck. But that does not mean that the language sucks, only that I didn't know the proper methods.

This also falls into the long load times. It does not cause long load times when it is streamed properly. But if you get some lazy developer who does not feel like using that, then you get long load times. Again, a developer issue.

And Flash might be proprietary (though my spidey sense reminds me of a open-source viewer and builder I have seen somewhere), but what it is built on - SVG - is not.

>For website viewers who do not want to run Flash and other Macromedia software, or cannot, web sites using it are broken.

Unless the website designers have taken the time to develop a version that is accessible to all. But there are some things that, in order to do the things the customer wants, require you to exclude certain browser users. This is not (actually should not) be because of the developer, but because of what the client wants most of the time. I have fought many a battle for our site to keep it from being taken over by DHTML and the like. The day I see "Best viewed by" at the bottom of the site is the day I know I have lost.

So again, please don't let the crappy developers, or the lazy developers, or the ones who have been instructed to do what they have done or lose their job detracted from the things that can be done with Flash when done properly.