If, like me, you've been using Mozilla's mouse gestures feature for a while you're probably hooked. The good news it that they are available for Phoenix as well:
Unfortunately there is no menu option to trigger them with the right mouse button (they default to being activated by the left button). If you want them on the right mouse button you will have to edit your prefs.js file. On Windows (depending on what version you are running) this can be found in C:\Windows\Application Data\Phoenix\Profiles\???\???\prefs.js
Before editing the prefs.js file you will need to install the gestures XPI, then restart your browser and shut it down again (this will create the default mouse gesture preferences in the prefs.js file). Now open the file in a text editor and look for the following line:
user_pref("mozgest.mousebutton", 0);
Change the number to 2 for right mouse button (or 1 for middle mouse button) and you're done.
There are some excellent accessible, standards compliant scripts now for creating trees / drop down menus from HTML nested lists - browsers without javascript see the list, while browsers with javascript get a nice expanding tree. Two examples:
Shock horror! Browser released in 1996 fails to support latest web standards!
If you want to bash Netscape, aim at Netscape 6 or 7 (both of which have superb standards compliance thanks to the Mozilla project). Netscape 4 simply isn't relevant any more, and hasn't been for several years. It's only big companies and institutions who don't want the hassle of upgrading their site-wide PCs that are keeping it alive, and with any luck even they will give it up soon.
Good question. The only way I can think of is to grab the output of microtime() every time an API call is made and record that time in a database (or on the filesystem, but a database would be preferable for performance reasons). Then you can check this "last queried" time before making a request, and if one has been made in the last second you can use usleep() to temporarily delay your next request. You would probably have to code in some kind of method of spotting when you are getting really high traffic (continuously getting several hits a second) and have some clients die with an error message, rather than wait for potentially quite a long time before their turn to send an API request comes.
Caching the results of requests could help greatly of course...
I agree - this is a superb book for anyone looking to learn Java. It's huge but covers a great deal of ground in enough detail for even programming beginners to take it all in, without leaving experienced programmers annoyed due to a slow pace.
A good review of Beginning Java 2 can be found here: http://www.webmasterbase.com/article/300
"Learning Python" better than "Programming Python"
on
General IT Books?
·
· Score: 4, Informative
I would recommend "Learning Python" over "Programming Python" for anyone with little or no experience of the language. I have both, and while Programming Python is an excellent book it is not at all suitable for beginners. Unlike "Programming Perl" (which is a classic text book no matter what level you are) "Programming Python" is more of a cook book - it discusses several more complex areas of Python in depth such as GUI coding and network / web server stuff but does not have much of use to language newbies. "Learning Python" on the other hand covers the whole basic language and does it in a very complete way - it's probably the best learn-a-language book in my collection.
Your point is fine in theory, but you have to remember two things. Firstly, the vast majority of internet users don't even know that they can change their default font size (let alone how to do it). Secondly, the default font size on most browsers looks plain ugly. I would imagine that any users who want larger fonts have set their font size so that sites which use "font-size: small" are readable for them, as that will be a very common size for text on the web.
I imagine the Web Standards site design team had to make a tricky compromise, between the theoretically correct step of sticking to the default browser font size and the more design friendly choice of using "font-size: small". At the end of the day the point of the project is to convince designers that they should be using web standards, and as such it is important that the site looks good. Had they used the default font size I imagine many designers would have been put off the site by the ugly size of the text.
OK, I know that security through obscurity sucks but is anyone else worried that right now thousands of script kiddies and black hat crackers are hard at work making the suggestions from that document a reality? I know if I was a worm author I would be treating the information in that document as a gold mine - it describes in pretty comprehensive terms some very effective ways of writing worms that can quickly grab a large number of hosts.
...each monument will be inscribed with "messages in seven languages: the six official United Nations languages (English, French, Spanish, Chinese, Russian, and Arabic) and Navajo."
My understanding is that the reason Navajo was used to transmit "encrypted" radio messages during the second world war is that the language is completely unrelated to ANY other language on the planet. As the article points out, there are only 250,000 Navajo speakers left on the planet. What possible benefit could it be to include this language in the inscriptions? Surely they should be concentrating on languages that are related to many other langauges, as those will be the most likely to survive long in to the future.
Here's an idea. Get a bunch of friendly lawyers (or pay some unfriendly ones). Get a good Perl programmer. Put them in a room together and ask them to come up with a EULA translation script - something that can have an EULA pasted in to it, parse it (as best it can) and churn out a nice, short, readable summary that ditches all the standard rubbish and tells you in plain English what your rights are when you install the software.
Obviously this thing would not be infallable so it would need a friendly disclaimer somewhere saying "if in doubt read the damn thing yourself" but I would love a tool which can spot the nasty bits of a EULA and display them in a readable form. Stuff like spyware installation, "all your personal data are belong to us" and that kind of thing.
OK it's probably not a practical idea, but I can dream:)
Having read through the information on their site, I think that's probably the best subscription model I've seen launched so far. The balance between "what you'll get for free" and "what you'll have to pay for" seems pretty much spot on, and by keeping ALL of their new content (with the exception of downloads and video streams) free to view for seven days there will still be plenty of reasons to visit their site without a subscription (and for new subscribers to see why they should sign up).
The price is right too - $25 a year or $5 a month allows dedicated fans to make a big saving but still lets new users try things out for a month or two before making a bigger commitment.
Provided they get their payment model right (there need to be alternatives to paying my credit card) I reckon they could be on to a winner. That said, I probably won't be signing up but that's because I hardly ever visit gamespot as it is. Hopefully GameSpot fans will react differently.
You may not send automated queries of any sort to Google's system without express permission in advance from Google. Note that "sending automated queries" includes, among other things:
using any software which sends queries to Google to determine how a website or webpage "ranks" on Google for various queries;
"meta-searching" Google; and
performing "offline" searches on Google.
It also stops your scripts from breaking every time Google redesign their results page.
No, it means posting on Google Groups through the web interface (which already requires an account) will be possible using your single Google account as opposed to a seperate one for Google Groups and the web API.
2. Does Google have any plans to sell Google Web APIs as a service?
Not at this time.
Which seems very strange seeing as this could be a huge money spinner. Surely a license system which allows commercial users to subscribe to a certain number of queries a day, or just buy queries in bulk would generate a lot of income for Google and provide a valuable service to the internet business community at large.
At the time of posting languages catered for were for AppleScript, Frontier/Radio, Perl, Python and Visual Basic. I've written a basic implementation in PHP which has yet to be added to the list - you can find it here:
A joke's a joke, but what's with turning off anonymous postings? It doesn't enhance the joke at all (come on, there's not a chance anyone's going to fall for this story) and as others have pointed out on this thread it's a pretty important part of slashdot. Maybe turning it off for just this one story, but for the whole site?
When did Slashdot's OS X section get that lovely makeover? Very nice (subtle as well) - makes a change from the slightly drab standard header graphic at any rate:)
I stand corrected - how embaressing:) I just re-checked and the page I was quoting had "Apache 1.3.23" at the top. I did a ctrl+refresh and the page changed to show the release notes for 1.3.24. Looks like either my browser was caching the old announcement page or I got caught out by my University's proxy. Not sure why the Apache project use the same URL for all of these announcements though.
If, like me, you've been using Mozilla's mouse gestures feature for a while you're probably hooked. The good news it that they are available for Phoenix as well:
http://texturizer.net/phoenix/extensions.html#gest ures
Unfortunately there is no menu option to trigger them with the right mouse button (they default to being activated by the left button). If you want them on the right mouse button you will have to edit your prefs.js file. On Windows (depending on what version you are running) this can be found in C:\Windows\Application Data\Phoenix\Profiles\???\???\prefs.js
Before editing the prefs.js file you will need to install the gestures XPI, then restart your browser and shut it down again (this will create the default mouse gesture preferences in the prefs.js file). Now open the file in a text editor and look for the following line:
user_pref("mozgest.mousebutton", 0);
Change the number to 2 for right mouse button (or 1 for middle mouse button) and you're done.
There are some excellent accessible, standards compliant scripts now for creating trees / drop down menus from HTML nested lists - browsers without javascript see the list, while browsers with javascript get a nice expanding tree. Two examples:
Shock horror! Browser released in 1996 fails to support latest web standards!
If you want to bash Netscape, aim at Netscape 6 or 7 (both of which have superb standards compliance thanks to the Mozilla project). Netscape 4 simply isn't relevant any more, and hasn't been for several years. It's only big companies and institutions who don't want the hassle of upgrading their site-wide PCs that are keeping it alive, and with any luck even they will give it up soon.
And of course, CSS is just another way to make sites full of drab screens with paragraph after paragraph of text...
Good question. The only way I can think of is to grab the output of microtime() every time an API call is made and record that time in a database (or on the filesystem, but a database would be preferable for performance reasons). Then you can check this "last queried" time before making a request, and if one has been made in the last second you can use usleep() to temporarily delay your next request. You would probably have to code in some kind of method of spotting when you are getting really high traffic (continuously getting several hits a second) and have some clients die with an error message, rather than wait for potentially quite a long time before their turn to send an API request comes.
Caching the results of requests could help greatly of course...
On a related note to this story, I compiled a list of free technical books from a slashdot thread a few weeks ago:
http://www.bath.ac.uk/~cs1spw/blog/archive/2002/06 / 9/#freeBooks
Sorry, that should be Dive Into Python.
Let's turn this topic around a bit and collect links to free books that can be found on the net. My favourites are:
- Dive Into Python - an excellent Python book aimed at experienced programmers
- Thinking in Java - concentrates on OOP principles. Check out Thinking in Python/C++/C# on the same site
- Secure Programming for Linux and Unix HOWTO - calls itself a HOWTO but it's practically a book
- Linux From Scratch - build your own linux distribution
There have to be more out there - post links below.I agree - this is a superb book for anyone looking to learn Java. It's huge but covers a great deal of ground in enough detail for even programming beginners to take it all in, without leaving experienced programmers annoyed due to a slow pace.
A good review of Beginning Java 2 can be found here: http://www.webmasterbase.com/article/300
I would recommend "Learning Python" over "Programming Python" for anyone with little or no experience of the language. I have both, and while Programming Python is an excellent book it is not at all suitable for beginners. Unlike "Programming Perl" (which is a classic text book no matter what level you are) "Programming Python" is more of a cook book - it discusses several more complex areas of Python in depth such as GUI coding and network / web server stuff but does not have much of use to language newbies. "Learning Python" on the other hand covers the whole basic language and does it in a very complete way - it's probably the best learn-a-language book in my collection.
WaSP is an advocacy organisation. They do a pretty good job of it as well :)
Your point is fine in theory, but you have to remember two things. Firstly, the vast majority of internet users don't even know that they can change their default font size (let alone how to do it). Secondly, the default font size on most browsers looks plain ugly. I would imagine that any users who want larger fonts have set their font size so that sites which use "font-size: small" are readable for them, as that will be a very common size for text on the web.
I imagine the Web Standards site design team had to make a tricky compromise, between the theoretically correct step of sticking to the default browser font size and the more design friendly choice of using "font-size: small". At the end of the day the point of the project is to convince designers that they should be using web standards, and as such it is important that the site looks good. Had they used the default font size I imagine many designers would have been put off the site by the ugly size of the text.
OK, I know that security through obscurity sucks but is anyone else worried that right now thousands of script kiddies and black hat crackers are hard at work making the suggestions from that document a reality? I know if I was a worm author I would be treating the information in that document as a gold mine - it describes in pretty comprehensive terms some very effective ways of writing worms that can quickly grab a large number of hosts.
Here's an idea. Get a bunch of friendly lawyers (or pay some unfriendly ones). Get a good Perl programmer. Put them in a room together and ask them to come up with a EULA translation script - something that can have an EULA pasted in to it, parse it (as best it can) and churn out a nice, short, readable summary that ditches all the standard rubbish and tells you in plain English what your rights are when you install the software.
:)
Obviously this thing would not be infallable so it would need a friendly disclaimer somewhere saying "if in doubt read the damn thing yourself" but I would love a tool which can spot the nasty bits of a EULA and display them in a readable form. Stuff like spyware installation, "all your personal data are belong to us" and that kind of thing.
OK it's probably not a practical idea, but I can dream
Having read through the information on their site, I think that's probably the best subscription model I've seen launched so far. The balance between "what you'll get for free" and "what you'll have to pay for" seems pretty much spot on, and by keeping ALL of their new content (with the exception of downloads and video streams) free to view for seven days there will still be plenty of reasons to visit their site without a subscription (and for new subscribers to see why they should sign up).
The price is right too - $25 a year or $5 a month allows dedicated fans to make a big saving but still lets new users try things out for a month or two before making a bigger commitment.
Provided they get their payment model right (there need to be alternatives to paying my credit card) I reckon they could be on to a winner. That said, I probably won't be signing up but that's because I hardly ever visit gamespot as it is. Hopefully GameSpot fans will react differently.
Same performance, better security. Which is the better web server?
No, it means posting on Google Groups through the web interface (which already requires an account) will be possible using your single Google account as opposed to a seperate one for Google Groups and the web API.
http://www.soapware.org/directory/4/services/googl eApi/implementations
At the time of posting languages catered for were for AppleScript, Frontier/Radio, Perl, Python and Visual Basic. I've written a basic implementation in PHP which has yet to be added to the list - you can find it here:
http://toys.incutio.com/php/php-google-web-api.htm l
This is a very cool toy.
A joke's a joke, but what's with turning off anonymous postings? It doesn't enhance the joke at all (come on, there's not a chance anyone's going to fall for this story) and as others have pointed out on this thread it's a pretty important part of slashdot. Maybe turning it off for just this one story, but for the whole site?
When did Slashdot's OS X section get that lovely makeover? Very nice (subtle as well) - makes a change from the slightly drab standard header graphic at any rate :)
I stand corrected - how embaressing :) I just re-checked and the page I was quoting had "Apache 1.3.23" at the top. I did a ctrl+refresh and the page changed to show the release notes for 1.3.24. Looks like either my browser was caching the old announcement page or I got caught out by my University's proxy. Not sure why the Apache project use the same URL for all of these announcements though.