You might also enjoy my browser-based searchpad (click on "Search Pad.") It's like all of those windows programs, but it's browser-based. That means it works on any holy OS:)
I find that testing "code with side-effects" (ie: database inserts) is the hardest type of code to test, and I haven't yet found a solution that satisfies me.
On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc.
As the XP mailing list talks about, you can always create mock objects and test their state, etc, but it's still not quite legitimate. You end up building these massive meta-models that themselves might have issues. Perhaps the best solution I found was to have a "test" instance of your database that would always contain an appropriate seed of test data. If you keep your "side-effect code" and "test the side-effect code" inside of a transaction that you roll-back, you're pretty well off. Unit tests can start taking a long time, though.
Things get worse when you look at Ron Jeffries' Adventures in C# where he starts on the slippery slope of re-implementing the textbox class as a mock object.
Not much of a point here, more of a "me, too" response.
Poster did not ping slashdot.org:) Poster pinged other hosts, but wanted to make things a bit more relevant to this site. However, I don't see how that's a troll.
The blog describes the full HTTP transaction process as:
Client: SYN Server: ACK Server: SYN Client: ACK Client: HTTP Request
Which IE (allegedly) "hacks" and the transaction really goes like:
Client: HTTP Request
If this is true, then IE saves 2 round trips per connection. Clients generally open 4 connections per server, and keep them open (alive) until they've downloaded the page and all supporting files. So IE possibly saves 8 round trips per page with this (alleged) hack.
For domestic dialup connections, the average round-trip latency is 60ms. DSL is around 40, while cable is around 20. Ping slashdot.org to find out the latency of your connection.
So, for a domestic dialup user connecting to an IIS server, a straight request (with no handshake) would save 8*0.06s = 0.48s. The page mentions combining SYN/ACK packets, so this may even be less of a savings.
An 0.48s cheat in page load times hardly makes IE "impossibly fast" when page load times over a modem typically run > 20s.
Also, don't forget that this blog also talks about non-IIS servers balking at this non-standard connection setup with with an RST packet. That adds 4*0.06 = 0.24s to page load times on, say, Apache servers. If true, that doesn't make IE "ridiculously slow," either.
this page talks about some other interesting scientific events that have their anniversary today:
1986 - First non-stop, non-refuelled flight around the world
1967 - Announcement of first synthesis of biologically active DNA
1962 - Mariner transmits information from first-ever rendezvous with Venus
I didn't take your comment as an attack on Pocket PC, and I tried very hard to make my comment not attack Palm OS. What I found questionable was your statement that the Pocket PC OS loads the program into memory while the PalmOS does not.
When I loaded my 2.45MB WinHack image, you'd expect memory usage to jump fairly high. You'd expect this because WinHack loads its run-time data structures (which do not exist in any compiled program,) and Pocket PC also has to allocate memory for all of the services to support it.
I simply cannot believe that PalmOS doesn't allocate additional memory when you load a program. I'd like to see _ANY_ OS let you create runtime data structures without allocating memory to them.
However, let's say the 320k that the Pocket PC used to load WinHack was because of program loading differences. That doesn't explain the _need_ for 64mb of RAM. I'll say it again -- the 64mb is a feature. It's to hold voice recordings, MP3s, etc -- the same reasons you want a 64mb SD card on a Palm.
Anyways, if you have links to some more technical evidence, I'd love to read it.
As for the "Windows CE programs are bloated" comment, I think you just fell for a troll:) But, it started friendly debate, so perhaps the troll backfired.
True, it probably takes a massive machine to make the itty-bitty data storage. Until they can miniaturize that equipment, though, I'm sure there will still be a good market for massive ROMs. Lots of read-only storage in a little container. Of course, the access device has to be small enough, but I can see a middle-ground.
Industrial CD-pressing machines are pretty huge, but the read-only data they create is incredibly mobile.
Well, I poked Google pretty hard to verify your claims but couldn't find anything to corroborate it. However, I have the feeling that you're just pushing a line that somebody told you.
1) "Windows CE works much like any other version of windows"
True, that was its design goal
2) "Files are loaded off of disk"
Not implied by #1, but let's go with that.
I'm looking at my iPAQ right now. It's got 5.54 MB of memory used for currently running programs. I navigate over to my WinHack image, 2.45 MB of goodness. I run it, and now my iPAQ shows 5.86 MB of memory used for currently running programs. Loading WinHack used 320k.
Now, I've not taken the Pocket PC OS through a kernel debugger, but my results seem to contradict the broad, sweeping "+1, Interesting" statement you made.
3) "Palm OS... designed for PDAs"
The
Pocket PC faq can help clear up some misconceptions.:
Q: What is Pocket PC?
A: Pocket PC is software for personal digital assistants (PDAs)....
Q: Is the Pocket PC OS the same as Windows CE?
A: No. The Pocket PC OS is a custom version of Windows CE...
Pocket PCs don't need these enormous RAM banks because of the reasons you give. They need them to support multitasking, voice recording, and the storage space that your MP3s require. They need them for the same reasons that Palm V users slap 64mb SD cards into their PDA.
Re:Wow, they get to reinvent the wheel
on
TMDC5
·
· Score: 2
Errm. Yet the invitation demo uses "TextFX4 and CFL3 libs," "Microsoft DirectX 8.1 SDK d3dx8 lib for math routines," "FMOD for sound." (Oops, I said Microsoft.)
The rules don't seem to disallow libraries, but the main page makes it sound like that.
Wow, they get to reinvent the wheel
on
TMDC5
·
· Score: 3, Interesting
Additionally the demo authors will not have any hardware-assisted rendering, forcing them to do their own rasterization methods
Well, I can certainly imagine the thrill (not) of implementing all the fundamentals from scratch.
There's certainly the point that this will make people write smart algorithms, but there are certain things that everybody will do anyways. Bresenham line drawing. Cohen-Sutherland Line-Clipping algorithm. Crack open your CG textbook and find many more.
Doesn't the ascii demo scene have any libraries to put the emphasis on smart implementation of ART, rather than the art coming second to a smart implementation of pixel pushing?
and what the several word processors available can't do (what, 3 or four things that word can?)
Seriously, we all know Linux is great. We all know freedom is great. We also know that no Open Source word processor can touch the feature count of MS Word. In terms of the most commonly used features, your point (while still wrong) starts to make sense, but don't fool youself.
You can make a great point for Linux while sticking to the facts -- don't dillute things by making up statistics.
Refactoring is often about injecting the last good idea you had into working code.
I've got to disagree with you on this one. Refactoring isn't about injecting good ideas into working code, it's about making sure that those new requirements you got last week didn't create spaghetti code. In a development world were you design from a static set of requirements, Refactoring really doesn't have much of a place. In that world, you have a valid point: if a developer can't do it right the firt time, round two won't be much better.
However, that's not the world I live in, and it's not the world that anybody I know lives in. Then again, I don't have friends at NASA. We live in a more realistic development world that changes reqirements after we've designed our framework. We live in a development world where the evolving system makes the customer reconsider their original decisions. Since you didn't design the system with these new requirements in mind, you're usually patching functionality on top of what you got.
Refactoring is about reviewing this patch-work to make sure that the code is written as though it were designed that way from the beginning.
Certain agile methodologies (especially XP) treat refactoring as a tenet. Customers never give you a complete spec, and you never want one. They give you "stories" that you implement quickly and minimally. You don't over-engineer to support infinite extensibility via Web Services and a plugin architecture (etc,) unless the story asks for it.
When your latest minimal implementation starts looking ugly or hacky (ie: 4 page switch statement) then you refactor until the code properly "expresses its intention."
You had some good points, but I think you are a little mistaken about when refactoring comes into play.
I've got to agree with you that Google has some room to grow, but our religious reverence comes from the fact that Google simply kills its competition. Before Google, I was a huge fan of Altavista. I could write some complex searches, and generally tease good results out of them. However, even as a programmer, I too often felt the bite of an insufficient query, or an insufficient database -- you never know. Now imagine the frustration of those not as technically adept as us.
Since I've started using Google, I've _never_ failed at a search and had another "generic" engine succeed. This obviously doesn't include results that sit behind specialized search engines like whois information.
Regarding some of your frustrations, you might be glad to know that Google does indeed support them. Recursive searching? Just add your words to the end of your original query. Memetic histography? Check out the Google Zeitgeist. ISO Syntax? Google's strength is that you don't have to program your searches. A simple query, combined with their ranking algorithms really sets you free.
Don't mistake this for blind adoration. As a search engine, nothing even approaches Google. As I've enjoyed their recent innovations (news and others,) I continue to look forward to more.
You can actually see sunspots (it'll look kinda like this, but in grayscale) any time you want by projecting the sun onto paper. Binoculars work well, a telescope works even better.
Aim your binoculars at the sun, without looking into them. If you look into them, you'll only see the steam rise from your eyes as they cook. Put a piece of white paper about 2m away from your binoculars. Cover a lense so only 1 circle shows on the paper. Finally, focus your binoculars to make the remaining circle as crisp as possible. This is easiest when you mount your binoculars on a tripod, but still works by hand.
Slashdot Mirror
I love Opera, I just fell in love with it a week ago
Let me tell you something that all of us geeks should remember for future encounters with women: it's not love after a week, it's lust :)
You might also enjoy my browser-based searchpad (click on "Search Pad.") It's like all of those windows programs, but it's browser-based. That means it works on any holy OS :)
Yes, as my third paragraph points out :) Don't karma whore from my own reply!
I find that testing "code with side-effects" (ie: database inserts) is the hardest type of code to test, and I haven't yet found a solution that satisfies me.
On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc.
As the XP mailing list talks about, you can always create mock objects and test their state, etc, but it's still not quite legitimate. You end up building these massive meta-models that themselves might have issues. Perhaps the best solution I found was to have a "test" instance of your database that would always contain an appropriate seed of test data. If you keep your "side-effect code" and "test the side-effect code" inside of a transaction that you roll-back, you're pretty well off. Unit tests can start taking a long time, though.
Things get worse when you look at Ron Jeffries' Adventures in C# where he starts on the slippery slope of re-implementing the textbox class as a mock object.
Not much of a point here, more of a "me, too" response.
Poster did not ping slashdot.org :) Poster pinged other hosts, but wanted to make things a bit more relevant to this site. However, I don't see how that's a troll.
The blog describes the full HTTP transaction process as:
Which IE (allegedly) "hacks" and the transaction really goes like:
If this is true, then IE saves 2 round trips per connection. Clients generally open 4 connections per server, and keep them open (alive) until they've downloaded the page and all supporting files. So IE possibly saves 8 round trips per page with this (alleged) hack.
For domestic dialup connections, the average round-trip latency is 60ms. DSL is around 40, while cable is around 20. Ping slashdot.org to find out the latency of your connection.
So, for a domestic dialup user connecting to an IIS server, a straight request (with no handshake) would save 8*0.06s = 0.48s. The page mentions combining SYN/ACK packets, so this may even be less of a savings.
An 0.48s cheat in page load times hardly makes IE "impossibly fast" when page load times over a modem typically run > 20s.
Also, don't forget that this blog also talks about non-IIS servers balking at this non-standard connection setup with with an RST packet. That adds 4*0.06 = 0.24s to page load times on, say, Apache servers. If true, that doesn't make IE "ridiculously slow," either.
Don't mean to be a grammar nazi, but... from the don't-lost-your-watch dept
Is that poor grammar, or just hedging their bets? The alternative is to misspell "lose" as "loose," which is definite grammar nazi fodder :)
this page talks about some other interesting scientific events that have their anniversary today:
1986 - First non-stop, non-refuelled flight around the world
1967 - Announcement of first synthesis of biologically active DNA
1962 - Mariner transmits information from first-ever rendezvous with Venus
At least we can figure out how the hell they came up with it.
it has every port i could ever want
You must be one of the lucky few here with a girlfriend. I believe the /. term for a person like you is "temporary visitor." :)
Did you notice the great suggestive sell partway down that Amazon page?
"Customers who wear clothes also shop for:"
Dude, if my girl's thong is as big as her t-shirt, I don't think I want to see her in it :)
But then again, telling a potential employer that you read a lot of slashdot might not be a good thing :)
Especially when your cover letter starts off, "Dear M$"
Thank you for an intelligent reply.
I didn't take your comment as an attack on Pocket PC, and I tried very hard to make my comment not attack Palm OS. What I found questionable was your statement that the Pocket PC OS loads the program into memory while the PalmOS does not.
When I loaded my 2.45MB WinHack image, you'd expect memory usage to jump fairly high. You'd expect this because WinHack loads its run-time data structures (which do not exist in any compiled program,) and Pocket PC also has to allocate memory for all of the services to support it.
I simply cannot believe that PalmOS doesn't allocate additional memory when you load a program. I'd like to see _ANY_ OS let you create runtime data structures without allocating memory to them.
However, let's say the 320k that the Pocket PC used to load WinHack was because of program loading differences. That doesn't explain the _need_ for 64mb of RAM. I'll say it again -- the 64mb is a feature. It's to hold voice recordings, MP3s, etc -- the same reasons you want a 64mb SD card on a Palm.
Anyways, if you have links to some more technical evidence, I'd love to read it.
As for the "Windows CE programs are bloated" comment, I think you just fell for a troll :) But, it started friendly debate, so perhaps the troll backfired.
True, it probably takes a massive machine to make the itty-bitty data storage. Until they can miniaturize that equipment, though, I'm sure there will still be a good market for massive ROMs. Lots of read-only storage in a little container. Of course, the access device has to be small enough, but I can see a middle-ground.
Industrial CD-pressing machines are pretty huge, but the read-only data they create is incredibly mobile.
Well, I poked Google pretty hard to verify your claims but couldn't find anything to corroborate it. However, I have the feeling that you're just pushing a line that somebody told you.
I'm looking at my iPAQ right now. It's got 5.54 MB of memory used for currently running programs. I navigate over to my WinHack image, 2.45 MB of goodness. I run it, and now my iPAQ shows 5.86 MB of memory used for currently running programs. Loading WinHack used 320k.
Now, I've not taken the Pocket PC OS through a kernel debugger, but my results seem to contradict the broad, sweeping "+1, Interesting" statement you made.
Pocket PCs don't need these enormous RAM banks because of the reasons you give. They need them to support multitasking, voice recording, and the storage space that your MP3s require. They need them for the same reasons that Palm V users slap 64mb SD cards into their PDA.
Errm. Yet the invitation demo uses "TextFX4 and CFL3 libs," "Microsoft DirectX 8.1 SDK d3dx8 lib for math routines," "FMOD for sound." (Oops, I said Microsoft.)
The rules don't seem to disallow libraries, but the main page makes it sound like that.
Additionally the demo authors will not have any hardware-assisted rendering, forcing them to do their own rasterization methods
Well, I can certainly imagine the thrill (not) of implementing all the fundamentals from scratch.
There's certainly the point that this will make people write smart algorithms, but there are certain things that everybody will do anyways. Bresenham line drawing. Cohen-Sutherland Line-Clipping algorithm. Crack open your CG textbook and find many more.
Doesn't the ascii demo scene have any libraries to put the emphasis on smart implementation of ART, rather than the art coming second to a smart implementation of pixel pushing?
Oh, it's nerdy. Wormholes and stuff. Tell me when they animate ascii porn!
I believe it would be more nerd-friendly as
"You had me at EHLO."
I know it's an extension, but truly more nerdy!
and what the several word processors available can't do (what, 3 or four things that word can?)
Seriously, we all know Linux is great. We all know freedom is great. We also know that no Open Source word processor can touch the feature count of MS Word. In terms of the most commonly used features, your point (while still wrong) starts to make sense, but don't fool youself.
You can make a great point for Linux while sticking to the facts -- don't dillute things by making up statistics.
Refactoring is often about injecting the last good idea you had into working code.
I've got to disagree with you on this one. Refactoring isn't about injecting good ideas into working code, it's about making sure that those new requirements you got last week didn't create spaghetti code. In a development world were you design from a static set of requirements, Refactoring really doesn't have much of a place. In that world, you have a valid point: if a developer can't do it right the firt time, round two won't be much better.
However, that's not the world I live in, and it's not the world that anybody I know lives in. Then again, I don't have friends at NASA. We live in a more realistic development world that changes reqirements after we've designed our framework. We live in a development world where the evolving system makes the customer reconsider their original decisions. Since you didn't design the system with these new requirements in mind, you're usually patching functionality on top of what you got.
Refactoring is about reviewing this patch-work to make sure that the code is written as though it were designed that way from the beginning.
Certain agile methodologies (especially XP) treat refactoring as a tenet. Customers never give you a complete spec, and you never want one. They give you "stories" that you implement quickly and minimally. You don't over-engineer to support infinite extensibility via Web Services and a plugin architecture (etc,) unless the story asks for it.
When your latest minimal implementation starts looking ugly or hacky (ie: 4 page switch statement) then you refactor until the code properly "expresses its intention."
You had some good points, but I think you are a little mistaken about when refactoring comes into play.
I've got to agree with you that Google has some room to grow, but our religious reverence comes from the fact that Google simply kills its competition. Before Google, I was a huge fan of Altavista. I could write some complex searches, and generally tease good results out of them. However, even as a programmer, I too often felt the bite of an insufficient query, or an insufficient database -- you never know. Now imagine the frustration of those not as technically adept as us.
Since I've started using Google, I've _never_ failed at a search and had another "generic" engine succeed. This obviously doesn't include results that sit behind specialized search engines like whois information.
Regarding some of your frustrations, you might be glad to know that Google does indeed support them. Recursive searching? Just add your words to the end of your original query. Memetic histography? Check out the Google Zeitgeist. ISO Syntax? Google's strength is that you don't have to program your searches. A simple query, combined with their ranking algorithms really sets you free.
Don't mistake this for blind adoration. As a search engine, nothing even approaches Google. As I've enjoyed their recent innovations (news and others,) I continue to look forward to more.
You can actually see sunspots (it'll look kinda like this, but in grayscale) any time you want by projecting the sun onto paper. Binoculars work well, a telescope works even better.
Aim your binoculars at the sun, without looking into them. If you look into them, you'll only see the steam rise from your eyes as they cook. Put a piece of white paper about 2m away from your binoculars. Cover a lense so only 1 circle shows on the paper. Finally, focus your binoculars to make the remaining circle as crisp as possible. This is easiest when you mount your binoculars on a tripod, but still works by hand.
If you look closely, you'll see the sunspots.
I was going to make a slick joke about the mysterious lack of interest for a meetup in Redmond, Washington...
BUT...
I was wrong.