The 2007 Virginia DOT study showed that there was an overall increase in total crashes of 23% and an injury crash increase of 17% after the installation of RLCs at intersections. The study concludes that: "the cameras are associated with a net increase in comprehensive crash costs".
The 2005 FHWA study that you keep citing uses data from over a decade ago, and also showed a 10% increase in the fatality rate after red light cameras were installed. The data that the FHWA used was also anonymous, so there is no possibility of verifying the data or analysis by a third party.
The IIHS study you cite in Philadelphia was for only 2 intersections, it was for a very limited time period, and they don't mention it in the study but crashes went up after installation of red light cameras. It is another in a long line of invalid and unprofessional studies that the IIHS has done on red light cameras.
The 2007 Virginia DOT red light camera study is one of the most comprehensive studies done on the subject, and it also found crashes went up after cameras were installed.
Since they started dumping money into political campaigns and hired their own lobbying group about ten years ago Microsoft has become one of the most generous contributors to politicians in the country:
We don't actually use Asterisk built-in ACD/queues features. We wroteour own and released them as GPL http://astguiclient.sourceforge.net/vicidial.html. We have stats out the wazoo, everything the agent does is logged on every call to a database, we can analyze time per call, wrapup time, customer wait time and many other reports as part of our VICIDIAL system.
A large portion of our business is actually inbound, but yes we do predictive outbound calling as well, mostly to current account holders and cutstomers. We do fully comply with the national and few dozen state DNC lists and other regulations.
It's also important to mention that there are now well over 100,000,000 phone numbers in the national do-not-call list(and still growing by millions a month) making it less and less profitable to do bulk predictive dialing every month which is one reason why we don't do it ourselves.
last three years. We now have over 250 phones installed at 4 locations(including a call center). We started switching to Asterisk three years ago and grew the system to the point where everythign is Asterisk and we do all inter-office calls over VOIP(IAX trunks). The cost savings in licensing costs alone more than justifies 2 full-time IT staffers salaries.
If you have some time to get comfortable with it, you will be very happy with the control you have over the system and the tremendous choice in phone hardware you can use with Asterisk. And if your company is anything like ours, they will love the cost savings.
Thanks for the critique, this was the first non-trivial large project I've done in PHP in about 4 years so I do admit that my PHP and Javascript were a little rusty going into this.
I usually do a lot of separate print or echo lines while developing and for ease of commenting out parts at times, just a preference of mine.
I found through writing this AJAX code that writing linearly is your friend. Yes, there is a TON of duplication in the code, but every time I started heavily using functions in Javascript, things started not working right, and nesting functions and calling functions within functions several levels deep will not always execute as expected, but the same code written in a more linear fashion will execute much more reliably in Javascript(NOTE: the only AJAX code in the project is in the 'agc' folder of the package)
Thanks for recommending switch, wish I'd known about that earlier, but I've been out of active daily development in PHP for years. I do plan on using that in future projects.
Consistent HTML case has always been a weakness of mine.
I'm actually not even using XML formatting for the passing back to the main script of the data from the XMLHTTPRequest scripts. I just use pipe-separated or one element of data per line output and parse the data differently for each type of request. The AJAX code in the project is confined to the 'agc' direcotry, I do have a lot of other PHP and Perl code in the rest of the package that has nothing to do with AJAX.
Thanks again, It's rare that you get good constructive feedback on coding if it's not a very widely distributed package.
I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.
I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.
I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.
These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.
We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.
In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
astGUIclient project page
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot sort a row of size 8469, which is greater than the allowable maximum of 8094./buylist.asp, line 612
The basic technology and systems already exist for this. If you have digital cable from companies like AOL/Time Warner, AT&T, Comcast..., the digital content will only play on their designated hardware and only if they have the serial number programmed into their network. No one has cracked it so far, so I'd say it's working rather well for them. Of course you can always capture analog output but no digital.
Slashdot Mirror
The 2007 Virginia DOT study showed that there was an overall increase in total crashes of 23% and an injury crash increase of 17% after the installation of RLCs at intersections. The study concludes that: "the cameras are associated with a net increase in comprehensive crash costs".
The 2005 FHWA study that you keep citing uses data from over a decade ago, and also showed a 10% increase in the fatality rate after red light cameras were installed. The data that the FHWA used was also anonymous, so there is no possibility of verifying the data or analysis by a third party.
The IIHS study you cite in Philadelphia was for only 2 intersections, it was for a very limited time period, and they don't mention it in the study but crashes went up after installation of red light cameras. It is another in a long line of invalid and unprofessional studies that the IIHS has done on red light cameras. The 2007 Virginia DOT red light camera study is one of the most comprehensive studies done on the subject, and it also found crashes went up after cameras were installed.
Since they started dumping money into political campaigns and hired their own lobbying group about ten years ago Microsoft has become one of the most generous contributors to politicians in the country:
h tml
s _microsoft.php
s _microsoft.php
n g.html
i alsID=440
s p
t m
1 1.callahan.think.html
LXer: How Microsoft wastes its money on anything but software
http://lxer.com/module/newswire/view/55497/index.
Election 2004: How to Excel in DC
http://www.seattleweekly.com/news/0438/040922_new
A Bug in Windows GOP (Seattle Weekly)
http://www.seattleweekly.com/news/0522/050601_new
Microsoft And The G.O.P.: Antitrust Insurance?
http://www.time.com/time/reports/gatesbook/lobbyi
Microsoft's lobbying efforts eclipse Enron
http://news.zdnet.com/2100-3513_22-835267.html
Redmond | Feature Article: Following Microsoft's Money
http://redmondmag.com/features/article.asp?Editor
News Alert 9/6/01: Microsoft
http://www.opensecrets.org/alerts/v6/alertv6_26.a
Commentary: It's Back to Charm School for Microsoft
http://www.businessweek.com/1999/99_45/b3654183.h
"The Think Tank As Flack" by David Callahan
http://www.washingtonmonthly.com/features/1999/99
http://www.microsoft.com/technet/security/bulletin /ms06-001.mspx
We don't actually use Asterisk built-in ACD/queues features. We wroteour own and released them as GPL http://astguiclient.sourceforge.net/vicidial.html. We have stats out the wazoo, everything the agent does is logged on every call to a database, we can analyze time per call, wrapup time, customer wait time and many other reports as part of our VICIDIAL system.
A large portion of our business is actually inbound, but yes we do predictive outbound calling as well, mostly to current account holders and cutstomers. We do fully comply with the national and few dozen state DNC lists and other regulations.
It's also important to mention that there are now well over 100,000,000 phone numbers in the national do-not-call list(and still growing by millions a month) making it less and less profitable to do bulk predictive dialing every month which is one reason why we don't do it ourselves.
last three years. We now have over 250 phones installed at 4 locations(including a call center). We started switching to Asterisk three years ago and grew the system to the point where everythign is Asterisk and we do all inter-office calls over VOIP(IAX trunks). The cost savings in licensing costs alone more than justifies 2 full-time IT staffers salaries.
/ Florell_astricon_2005.html
If you have some time to get comfortable with it, you will be very happy with the control you have over the system and the tremendous choice in phone hardware you can use with Asterisk. And if your company is anything like ours, they will love the cost savings.
Here's a link to a case study presentation I gave at Astricon 2005 last month:
http://astguiclient.sourceforge.net/astricon_2005
Thanks for the critique, this was the first non-trivial large project I've done in PHP in about 4 years so I do admit that my PHP and Javascript were a little rusty going into this.
I usually do a lot of separate print or echo lines while developing and for ease of commenting out parts at times, just a preference of mine.
I found through writing this AJAX code that writing linearly is your friend. Yes, there is a TON of duplication in the code, but every time I started heavily using functions in Javascript, things started not working right, and nesting functions and calling functions within functions several levels deep will not always execute as expected, but the same code written in a more linear fashion will execute much more reliably in Javascript(NOTE: the only AJAX code in the project is in the 'agc' folder of the package)
Thanks for recommending switch, wish I'd known about that earlier, but I've been out of active daily development in PHP for years. I do plan on using that in future projects.
Consistent HTML case has always been a weakness of mine.
I'm actually not even using XML formatting for the passing back to the main script of the data from the XMLHTTPRequest scripts. I just use pipe-separated or one element of data per line output and parse the data differently for each type of request. The AJAX code in the project is confined to the 'agc' direcotry, I do have a lot of other PHP and Perl code in the rest of the package that has nothing to do with AJAX.
Thanks again, It's rare that you get good constructive feedback on coding if it's not a very widely distributed package.
I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.
I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.
I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.
These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.
We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.
In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
astGUIclient project page
MATT---
protection on this site. I tried to search(soundbuzz.com) for a song and got:
/buylist.asp, line 612
Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot sort a row of size 8469, which is greater than the allowable maximum of 8094.
Guess they need to test the site, huh
The basic technology and systems already exist for this. If you have digital cable from companies like AOL/Time Warner, AT&T, Comcast..., the digital content will only play on their designated hardware and only if they have the serial number programmed into their network. No one has cracked it so far, so I'd say it's working rather well for them. Of course you can always capture analog output but no digital.