I consider that to be akin to treating your employees like slaves.
It is pretty clear that you've either lost your grip on reality or history. Most likely both.
Of course a company isn't going to advertise all the great things individual members have done to other companies! What benefit is there in that? While you work for the company, you stand as a team, and that should be sufficient. When you're applying for a job, drinking beer with your friends, it's then that you can insert the missing "I" into team, but to expect the company to? You're off your rocker.
Now granted the company handled this pretty poorly -- a better decision may have been to not include a picture, etc. at all -- but that is far from a company holding an employee back.
Stop expecting your company to be your recruiter, and get off your ass and do it yourself (or retain one). Stop being an idiot. Cliff, stop posting idiot stories.
I don't think there is enough evidence to be conclusive. How do know if people won't tollerate 200 ms because it's too slow for them to use, or because there are faster (i.e., lower ping) servers available? I would imagine most people can find a server with a ping time at least under 150, so why would they chose a slower server if they don't have to?
If Yahoo moves from indexing everything, to only things fitting the 'closed wall' approach, that's a pretty big change to their buisness model. What will happen will depend upon what the demand for each approach is.
If there is a demand for one more closed wall approach, they'll thrive. If there's not, the fighting will become more intense for the eyeballs that make up that market. More than likely, one of them would change their approach back to the index-everything one.
Either way, if there truely is a market for an index-everything site, someone else will come up and take yahoo's shoes. Either way, I'm not worried.
>Christ, imagine what it would be like to have the >likes of Leonardo DaVinchi on the web, in his own >words, pictures and creations! (I wonder if Leo >would have dug Java or PHP3?).
Java or PHP3? Are you nuts? That man was all over the place. Did everything. Make simple things simple, and hard things possible. Did the same thing different ways.
The page is more than likely a bad Perl program. The localtime function (what most people use to get the date), returns a list with the hour, minute, day, month, etc. It returns the year as the number of years since 1900, hence in 1999 it would have returned 99 and now it would 100.
Some Perl programmers (use the last part loosely), have been concatingating "19" to the front of the year instead of adding 1900. I wonder if Perl will get a bad wrap as these programs start to break and die. I hope not; I Perl.
You'll find that radical shifts are often resisted in the buisness world. A phased implementation might be the best way to go & would easy to do.
You're on the right path... Perl can certainly do what you. In fact, most of the difficult code that you would need is already written: DBI & DBD::ODBC. What you'd want to do is establish an ODBC connection to your Access database & do all your data manipulation that way.
Using this, you can move the dynamic component of your site to Perl based CGIs running on your existing NT servers. (Take care to avoid anything platform specific, and avoid ASP/Perl-script. That will only furhter anchor you to NT.) Not a radical shift, and one that should both help your current situtation and increase everyone's confidence in what you're doing.
Next, on the side, implement you linux box running mysql. Write a Perl script using DBI, DBD::ODBC, and DBD::Mysql to periodically refresh the mysql database from the Access table. This will be the trickest part. I recommend keeping the mysql data model the same as the Access data model to keep things simple. Unfortunetly, there isn't an easy/inexpensive way to read Access files on a linux box, but that's not a big obstacle. You can use DBD::Proxy. Alternatively, have two Perl scripts: one on the NT box to export data to a tab-delimited flat file, and another script on the Linux side to import the file. With some smart scripting, the use of Net::FTP & NET::Telnet, you could integrate this into one file. (Simpler, but less cool, just do some intelligent automated scheduling on both sides via NT's scheduler & Linux's cron.)
Now, through mod_perl into the mix. Present each solution side by side to your superiours. Explain the performance difference, the scalability, the cost difference, the seemless integration, and the added functionality of the Linux/Apache/Perl/mod_perl/Mysql solution, and *presto* you have your solution (and you look like a superstar.:)
Perl does what the majority of CGIs need, and does it really well. In the most common cases, CGI data is pased in, the data is parsed, manipulated, formated into other text, and then other text is returned to the user. When it comes to text manipulation, you won't find a better language than Perl. Period.
Perl also has a lot of code already developed that is easily re-used. Two prime examples: CGI.pm & DBI.pm. Granted I don't do a lot of C development, but I haven't heard of C libraries that come close to functionationaly & flexibilty. (Granted you're less likely to see it in C, since it doesn't support OOP, but you might in C++.) If this is what you're looking for, Perl is a damn good answer.
Keep in mind the way a CGI works is data is submitted, processed, and returned. CGI isn't really appropiate if you want to do constant, real-time updating of some sort data. You could the page constantly reload, but that's a cheap hack at best.
Applications, on the other hand, do a lot of other things. Not that I would say all over them are entirely optimized, otherwise 4GL languages, like PowerBuilder & Visual Basic, would not be nearly as popular. However, some of these other languages are stronger at supporting other other actions, most notably GUI interaction & a WYSIWYG-ish development enviroment.
C/C++ are really strong at processing things quickly. If you really need to scale at a cheap rate, you may want to take a look at them. From what I understand, Altavista and a few of the other larger site use it instead of CGIs and Perl (or any other language). Most of the time, for most of the applications, that's not needed.
In fact, I think you could safely say, develop in Perl, and then tune to C when you need to. But the best thing to keep in mind is that if all you know how to use is a hammer, then everything looks like a nail. Every development language or process, is a tool, and each developer simply needs to understand which tools he should have in his box and how to use them.
Hmmm... why not have a non-propriety protocol established and set it down in an RFC? Correct me if I'm wrong, but that seems to have worked in the past.
The added advantage is anyone could develop their own app, perl script, what-have-you, to use it as well.
IBM is a commericial, for-profit company, but is that so bad? Yes, IBM will have it's own interests at heart. However, every company has it's own interests at heart whenever it forms partnerships with other for-profit companies as well, and yet, it's possible for them to both away better off than how they started. Just becuase something is open-source does not mean it's any less true.
Slashdot Mirror
I consider that to be akin to treating your employees like slaves.
It is pretty clear that you've either lost your grip on reality or history. Most likely both.
Of course a company isn't going to advertise all the great things individual members have done to other companies! What benefit is there in that? While you work for the company, you stand as a team, and that should be sufficient. When you're applying for a job, drinking beer with your friends, it's then that you can insert the missing "I" into team, but to expect the company to? You're off your rocker.
Now granted the company handled this pretty poorly -- a better decision may have been to not include a picture, etc. at all -- but that is far from a company holding an employee back.
Stop expecting your company to be your recruiter, and get off your ass and do it yourself (or retain one). Stop being an idiot. Cliff, stop posting idiot stories.
Humbly,
-Bill
I don't think there is enough evidence to be conclusive. How do know if people won't tollerate 200 ms because it's too slow for them to use, or because there are faster (i.e., lower ping) servers available? I would imagine most people can find a server with a ping time at least under 150, so why would they chose a slower server if they don't have to?
If Yahoo moves from indexing everything, to only things fitting the 'closed wall' approach, that's a pretty big change to their buisness model. What will happen will depend upon what the demand for each approach is.
:)
If there is a demand for one more closed wall approach, they'll thrive. If there's not, the fighting will become more intense for the eyeballs that make up that market. More than likely, one of them would change their approach back to the index-everything one.
Either way, if there truely is a market for an index-everything site, someone else will come up and take yahoo's shoes. Either way, I'm not worried.
Gotta love free markets.
-Bill
How are they the first? Akamai's had this service for somet time now:
http://www.akamai.com/html/sv/edse.html
-Bill
Is it me, or does Lars *really* like the word 'obviously'?
Geez, a quick perl script shows he used it more than metallica.
-Bill
>Christ, imagine what it would be like to have the
>likes of Leonardo DaVinchi on the web, in his own
>words, pictures and creations! (I wonder if Leo
>would have dug Java or PHP3?).
Java or PHP3? Are you nuts? That man was all over the place. Did everything. Make simple things simple, and hard things possible. Did the same thing different ways.
DaVinchi has Perl written all over him.
-Bill
The page is more than likely a bad Perl program. The localtime function (what most people use to get the date), returns a list with the hour, minute, day, month, etc. It returns the year as the number of years since 1900, hence in 1999 it would have returned 99 and now it would 100.
Some Perl programmers (use the last part loosely), have been concatingating "19" to the front of the year instead of adding 1900. I wonder if Perl will get a bad wrap as these programs start to break and die. I hope not; I Perl.
Why is this on Slashdot?
Just wondering...
-Bill
You'll find that radical shifts are often resisted in the buisness world. A phased implementation might be the best way to go & would easy to do.
:)
You're on the right path... Perl can certainly do what you. In fact, most of the difficult code that you would need is already written: DBI & DBD::ODBC. What you'd want to do is establish an ODBC connection to your Access database & do all your data manipulation that way.
Using this, you can move the dynamic component of your site to Perl based CGIs running on your existing NT servers. (Take care to avoid anything platform specific, and avoid ASP/Perl-script. That will only furhter anchor you to NT.) Not a radical shift, and one that should both help your current situtation and increase everyone's confidence in what you're doing.
Next, on the side, implement you linux box running mysql. Write a Perl script using DBI, DBD::ODBC, and DBD::Mysql to periodically refresh the mysql database from the Access table. This will be the trickest part. I recommend keeping the mysql data model the same as the Access data model to keep things simple. Unfortunetly, there isn't an easy/inexpensive way to read Access files on a linux box, but that's not a big obstacle. You can use DBD::Proxy. Alternatively, have two Perl scripts: one on the NT box to export data to a tab-delimited flat file, and another script on the Linux side to import the file. With some smart scripting, the use of Net::FTP & NET::Telnet, you could integrate this into one file. (Simpler, but less cool, just do some intelligent automated scheduling on both sides via NT's scheduler & Linux's cron.)
Now, through mod_perl into the mix. Present each solution side by side to your superiours. Explain the performance difference, the scalability, the cost difference, the seemless integration, and the added functionality of the Linux/Apache/Perl/mod_perl/Mysql solution, and *presto* you have your solution (and you look like a superstar.
-Bill
Perl does what the majority of CGIs need, and does it really well. In the most common cases, CGI data is pased in, the data is parsed, manipulated, formated into other text, and then other text is returned to the user. When it comes to text manipulation, you won't find a better language than Perl. Period.
Perl also has a lot of code already developed that is easily re-used. Two prime examples: CGI.pm & DBI.pm. Granted I don't do a lot of C development, but I haven't heard of C libraries that come close to functionationaly & flexibilty. (Granted you're less likely to see it in C, since it doesn't support OOP, but you might in C++.) If this is what you're looking for, Perl is a damn good answer.
Keep in mind the way a CGI works is data is submitted, processed, and returned. CGI isn't really appropiate if you want to do constant, real-time updating of some sort data. You could the page constantly reload, but that's a cheap hack at best.
Applications, on the other hand, do a lot of other things. Not that I would say all over them are entirely optimized, otherwise 4GL languages, like PowerBuilder & Visual Basic, would not be nearly as popular. However, some of these other languages are stronger at supporting other other actions, most notably GUI interaction & a WYSIWYG-ish development enviroment.
C/C++ are really strong at processing things quickly. If you really need to scale at a cheap rate, you may want to take a look at them. From what I understand, Altavista and a few of the other larger site use it instead of CGIs and Perl (or any other language). Most of the time, for most of the applications, that's not needed.
In fact, I think you could safely say, develop in Perl, and then tune to C when you need to. But the best thing to keep in mind is that if all you know how to use is a hammer, then everything looks like a nail. Every development language or process, is a tool, and each developer simply needs to understand which tools he should have in his box and how to use them.
-Bill
>"In a global context, nothing on the Internet --
>not even Slashdot -- is important enough to be
>worth a glance."
I would disagree, but then again, I'm one of those crazy types who thought the printing press was important too. Information, schmormation.
-Bill
An explanation of SQL Navigator would be useful...
-Bill
Hmmm... why not have a non-propriety protocol established and set it down in an RFC? Correct me if I'm wrong, but that seems to have worked in the past.
The added advantage is anyone could develop their own app, perl script, what-have-you, to use it as well.
-Bill
IBM is a commericial, for-profit company, but is that so bad? Yes, IBM will have it's own interests at heart. However, every company has it's own interests at heart whenever it forms partnerships with other for-profit companies as well, and yet, it's possible for them to both away better off than how they started. Just becuase something is open-source does not mean it's any less true.
Wow! Do you think a boat will sink in the next one too?