IIRC, a terabyte is 1000 gigabytes. 100 GB drives are available, so terabyte array really is not very big.
Make sure you know how the price compares with a new solution to the problem you have... just because it's a fraction of its original price doesn't mean it's a good deal.
[Living in South Florida for my entire life, I can say without a doubt that the greatest night skies I have ever seen were observed from a boat anchored a few miles from shore.]
Warning: I'm familiar with lakes, not oceans.
Was it lawful to have your lights off at night to enjoy these skies?
The password-to-unsub technique provides no additional security over sending each person a link or email address that can unsub without a password, and is inconvenient for users. I hate having yet more passwords I don't care about; why should I inflict that on my users?
Yes, SSL is a *huge* hole in the idea that a firewall can statefully inspect everything going through and place strong limits on what can be send. To allow SSL, you have to allow arbitrary binary data on port 443.
The only way to stop it is to block SSL / HTTPS. Ah, that's a fantastic way to increase security;-)
It's not about security, it's about the adminstrative effort of getting a firewall configuration change made in a large organization. In short, it's really hard to do.
Here's a purposely oversimplified and perhaps harsh explanation:
Simplisting firewall adminstrators don't care what you send over the network, as long as it's on port 80. More sophisticated adminstrators also insist that it's HTTP. Even more sophisticated ones inspect in more detail, such as checking to see if files transferred have viruses in them.
It's only a matter of time before firewall adminstrators notice that SOAP requests are really RPC calls, and block them by default - then we will all be back to having to get specific configuration changes done to let apps work over the firewall. We won't want to do that for the same reasons we don't want to try to convince someone that it's OK to open a port.
I predict that there will therefore be a way developed to wrap SOAP not only in HTTP, but in HTML. The XML SOAP request could sit inside of simple HTML wrapper tags; this would let it go through the likely block-by-default of SOAP traffic.
Qmail is great... but not as great as it easily could be. There are too many pieces which need to be downloaded, compiled, and installed separately. It would be much nicer if all of the commmonly needed pieces were "in the box", including ezmlm, virtual domain support (vpopmail), that relay patch, the autoresponder, etc.
Blame the author and his license. If it was one of the common open source licenses, someone would put together all the pieces and made an RPM available.
I agree completely, and touched on this in an earlier post. I believe a better solution is to customize each message with a URL that is specific to the recipient, which lets them adjust or unsubscribe themeselves *without* any further steps. Of course the usual reply-with-'unsubscribe' should also work.
Mailman has a number of weaknesses / missing features which make unsuitable for some uses. Here are a few.
* No direct support for announce-only lists.
* It insists on having users use a password to unsubscribe / etc. I've found that most people don't want another password, and they don't need one with other mailing list systems.
* It has no ability to email out a "click here to unsubcribe" link, but rather a link to the above mentioned password system.
Of course it's probably idea for some uses, and I don't mean to disparage it in general, just to say that it's no the ultimate mailing list manager.
It seems that the meaning of "selective" is simple; the criteria is simply
Age>=18 AND Sex='Male'
Perhaps it should be called the not-very-selective service?
Re:Java IDEs
on
Java IDEs?
·
· Score: 4, Interesting
I am surprised at how few comments IntelliJ IDEA is getting here. It is very good. The refactoring features (hence the Fowler connection) are so useful that I think it's likely that most major IDEs will copy them in the new few years.
I've also had good results with JBuilder, with VisualAge (for projects where I have no need for source code in files, which is not many of them...), and with plain old text editing.
Take, for example, the much-hyped NASA space shuttle software project. It is apparently completely free of bugs, among other merits.
But building software the way they are building it takes an enormous amount of time relative to the features delivered. If you tried to create commercial software that way, you would be done years or decades after the market for your product passed.
Most projects don't need a way to deliver perfect software at monstrous cost; they need a way to deliver very good software, at reasonable cost, soon.
[agile development process to fixed cost contracts]
I work with the customer to divide the project up in to phases / steps / iterations / releases / whatever. Group the most vital core pieces together and do them first, at a fixed cost. As requirement change, these changes either go in to future fixed cost releases, or they are done hourly if requested. Thus, the overall project is not fixed, but at each stage the customer knows what they are buying at what price, and does not have the worry of the "meter running".
There is some related explanation (not a sales pitch) about it on my web site:
I was referring to using a partially transparent image (hence PNG alpha channel support) to create the same see-through look that TV stations use. Yes, Geocities has had the idea a long time, but has had to keep the thing small and way in the corner because it's opaque.
Indeed, you're right. At least it's not overlapping the main content area of the screen, though.
Hmmm... if IE had good alpha channel support for PNG graphics, then it would be easy with a bit of CSS to build web sites with a "bug" over the corner of every page, in spite of scrolling, overlapping actual content.
Prediciton: If/when IE gets such support, the free-web-space hosting companies will do this.
2-3 times is a pretty high multiplier, but there is a lot of merit to your comment. Here's a related hyptothetical question. You have a 5-month project. How do you spend months 1 and 2?
A) Detailed requirements and design work. Endless meetings. Lots of documents. Little or no code.
B) identify key requirements (highest value to customer) and implement them; provide working version 1 of the system, with modest documentation and simple code.
I've done some of each in various roles I have worked in. Nowadays I do a fair amount of work for my own clients, who seem to prefer option B.
The value of option B is especially obvious in an outsourcing situation. It's much easier to snow a client with an almighty thud of documentation than with working code. Therefore, with option B you know much sooner if your outsourcer is incompetant, so you can fire them if needed.
I and everyone else would obviously choose B. But that wasn't the questions I asked; my question and point were about the idea that increasing the estimatability of a project may come at a severe price in increasing the absolute cost of the project, and that is a tradeoff which organizations must address, either implicity or explicity.
Note that a side-effect may also be that hard-to-estimate project may be cancelled or skipped entirely, even though they could delivery great business value.
[Just imagine that you had to do a while-loop according to an ISO standard]
You could make software development more predictable, but it would probably come at the cost of *enormously* increased total resources spend. Would you rather have:
(A) A project estimate at $1,000,000, which might blow the budget and csot $2,000,000.
(B) The same project estimate at $10,000,000 and come in on budget?
[Anyone know how to build a Director Xtra C/C++.dll to]
NO, and more importantly I would not bother to estimate the time to build it until I understood how.:-) Once I understood, I could estimate it pretty well.
This is the key insight, and the one that the "software engineering is a science, you hackers should go away" crowd ignores. There is no one answer to how well software development can be planned / estimated, it depends *enormously* on the kind of project.
I once has a person stand up and tell me that his organization could estimate sizable projects with great accuracy. After some questions, it turned at that the projects were essentially the same thing again and again. Duh.
On the other hand, I usually do a pretty good job of estimating costs and schedules, even when there are some significant unknowns. So perhaps the situation is not as had as some people are making it sound, either.
This approach applies, more or less, sometimes MUCH less, depending on how well understood the problem domain is, how many times you have done it before.
If you're building your 57th e-commerce web site, which works roughly like the 56 you build before, you can estimate very, very well, and you can reduce coding to nearly data entry.
If you're solving a problem of unknown scope, which your team has not solved before, which the solution is not clear to, and analysis has revealed some but not all of the details, etc., then you are not very right.
If the XML processing is in a separate layer of the application from the "real work", you could have multiple implementation of the data representation mechanism... an XML implementation for full buzzword compliance, and a more native implementation for maximum performance.
On the other hand, if you've let the XML-aware code permeate all parts of the system, it's going to be a lot of work to strip it out.
Slashdot Mirror
IIRC, a terabyte is 1000 gigabytes. 100 GB drives are available, so terabyte array really is not very big.
Make sure you know how the price compares with a new solution to the problem you have... just because it's a fraction of its original price doesn't mean it's a good deal.
[Living in South Florida for my entire life, I can say without a doubt that the greatest night skies I have ever seen were observed from a boat anchored a few miles from shore.]
Warning: I'm familiar with lakes, not oceans.
Was it lawful to have your lights off at night to enjoy these skies?
My specific need is for an announce-only list. Traffic is low, bits are cheap.
The password-to-unsub technique provides no additional security over sending each person a link or email address that can unsub without a password, and is inconvenient for users. I hate having yet more passwords I don't care about; why should I inflict that on my users?
Yes, SSL is a *huge* hole in the idea that a firewall can statefully inspect everything going through and place strong limits on what can be send. To allow SSL, you have to allow arbitrary binary data on port 443.
;-)
The only way to stop it is to block SSL / HTTPS. Ah, that's a fantastic way to increase security
It's not about security, it's about the adminstrative effort of getting a firewall configuration change made in a large organization. In short, it's really hard to do.
Here's a purposely oversimplified and perhaps harsh explanation:
Simplisting firewall adminstrators don't care what you send over the network, as long as it's on port 80. More sophisticated adminstrators also insist that it's HTTP. Even more sophisticated ones inspect in more detail, such as checking to see if files transferred have viruses in them.
It's only a matter of time before firewall adminstrators notice that SOAP requests are really RPC calls, and block them by default - then we will all be back to having to get specific configuration changes done to let apps work over the firewall. We won't want to do that for the same reasons we don't want to try to convince someone that it's OK to open a port.
I predict that there will therefore be a way developed to wrap SOAP not only in HTTP, but in HTML. The XML SOAP request could sit inside of simple HTML wrapper tags; this would let it go through the likely block-by-default of SOAP traffic.
Qmail is great... but not as great as it easily could be. There are too many pieces which need to be downloaded, compiled, and installed separately. It would be much nicer if all of the commmonly needed pieces were "in the box", including ezmlm, virtual domain support (vpopmail), that relay patch, the autoresponder, etc.
Blame the author and his license. If it was one of the common open source licenses, someone would put together all the pieces and made an RPM available.
I agree completely, and touched on this in an earlier post. I believe a better solution is to customize each message with a URL that is specific to the recipient, which lets them adjust or unsubscribe themeselves *without* any further steps. Of course the usual reply-with-'unsubscribe' should also work.
Mailman has a number of weaknesses / missing features which make unsuitable for some uses. Here are a few.
* No direct support for announce-only lists.
* It insists on having users use a password to unsubscribe / etc. I've found that most people don't want another password, and they don't need one with other mailing list systems.
* It has no ability to email out a "click here to unsubcribe" link, but rather a link to the above mentioned password system.
Of course it's probably idea for some uses, and I don't mean to disparage it in general, just to say that it's no the ultimate mailing list manager.
It seems that the meaning of "selective" is simple; the criteria is simply
Age>=18 AND Sex='Male'
Perhaps it should be called the not-very-selective service?
I am surprised at how few comments IntelliJ IDEA is getting here. It is very good. The refactoring features (hence the Fowler connection) are so useful that I think it's likely that most major IDEs will copy them in the new few years.
I've also had good results with JBuilder, with VisualAge (for projects where I have no need for source code in files, which is not many of them...), and with plain old text editing.
Take, for example, the much-hyped NASA space shuttle software project. It is apparently completely free of bugs, among other merits.
But building software the way they are building it takes an enormous amount of time relative to the features delivered. If you tried to create commercial software that way, you would be done years or decades after the market for your product passed.
Most projects don't need a way to deliver perfect software at monstrous cost; they need a way to deliver very good software, at reasonable cost, soon.
[agile development process to fixed cost contracts]
n g.html
I work with the customer to divide the project up in to phases / steps / iterations / releases / whatever. Group the most vital core pieces together and do them first, at a fixed cost. As requirement change, these changes either go in to future fixed cost releases, or they are done hourly if requested. Thus, the overall project is not fixed, but at each stage the customer knows what they are buying at what price, and does not have the worry of the "meter running".
There is some related explanation (not a sales pitch) about it on my web site:
http://kylecordes.com/story-182-shared-risk-prici
I was referring to using a partially transparent image (hence PNG alpha channel support) to create the same see-through look that TV stations use. Yes, Geocities has had the idea a long time, but has had to keep the thing small and way in the corner because it's opaque.
Indeed, you're right. At least it's not overlapping the main content area of the screen, though.
Hmmm... if IE had good alpha channel support for PNG graphics, then it would be easy with a bit of CSS to build web sites with a "bug" over the corner of every page, in spite of scrolling, overlapping actual content.
Prediciton: If/when IE gets such support, the free-web-space hosting companies will do this.
2-3 times is a pretty high multiplier, but there is a lot of merit to your comment. Here's a related hyptothetical question. You have a 5-month project. How do you spend months 1 and 2?
A) Detailed requirements and design work. Endless meetings. Lots of documents. Little or no code.
B) identify key requirements (highest value to customer) and implement them; provide working version 1 of the system, with modest documentation and simple code.
I've done some of each in various roles I have worked in. Nowadays I do a fair amount of work for my own clients, who seem to prefer option B.
The value of option B is especially obvious in an outsourcing situation. It's much easier to snow a client with an almighty thud of documentation than with working code. Therefore, with option B you know much sooner if your outsourcer is incompetant, so you can fire them if needed.
[MS logo doesn't cover the bottom right-hand corner]
Shhh! Don't give anyone (MS or otherwise) any ideas!
Given your choices:
A) estimate $5M, actual $45M, FAILURE
B) estimate $10M, actual $10M, SUCCESS
I and everyone else would obviously choose B. But that wasn't the questions I asked; my question and point were about the idea that increasing the estimatability of a project may come at a severe price in increasing the absolute cost of the project, and that is a tradeoff which organizations must address, either implicity or explicity.
Note that a side-effect may also be that hard-to-estimate project may be cancelled or skipped entirely, even though they could delivery great business value.
[Just imagine that you had to do a while-loop according to an ISO standard]
You could make software development more predictable, but it would probably come at the cost of *enormously* increased total resources spend. Would you rather have:
(A) A project estimate at $1,000,000, which might blow the budget and csot $2,000,000.
(B) The same project estimate at $10,000,000 and come in on budget?
[Anyone know how to build a Director Xtra C/C++ .dll to]
:-) Once I understood, I could estimate it pretty well.
NO, and more importantly I would not bother to estimate the time to build it until I understood how.
My firm also does some work on a fixed-cost basis, with similar good results. I also borrow many ideas from XP.
A key to fixed-cost is that it takes practice. Try it on a small scale before you commit to it on a larger scale, to avoid large-scale failure...
This is the key insight, and the one that the "software engineering is a science, you hackers should go away" crowd ignores. There is no one answer to how well software development can be planned / estimated, it depends *enormously* on the kind of project.
I once has a person stand up and tell me that his organization could estimate sizable projects with great accuracy. After some questions, it turned at that the projects were essentially the same thing again and again. Duh.
On the other hand, I usually do a pretty good job of estimating costs and schedules, even when there are some significant unknowns. So perhaps the situation is not as had as some people are making it sound, either.
Note that many of the kinds of projects you mentioned also sometimes have cost and time overruns of remarkable size.
Note also the enormous difference between building the first 747 / skyscaper / nuclear submarine and the 15th or 1500th of each.
This approach applies, more or less, sometimes MUCH less, depending on how well understood the problem domain is, how many times you have done it before.
If you're building your 57th e-commerce web site, which works roughly like the 56 you build before, you can estimate very, very well, and you can reduce coding to nearly data entry.
If you're solving a problem of unknown scope, which your team has not solved before, which the solution is not clear to, and analysis has revealed some but not all of the details, etc., then you are not very right.
If the XML processing is in a separate layer of the application from the "real work", you could have multiple implementation of the data representation mechanism... an XML implementation for full buzzword compliance, and a more native implementation for maximum performance.
On the other hand, if you've let the XML-aware code permeate all parts of the system, it's going to be a lot of work to strip it out.