Okay, so this is going to be a very short pot... 'cause I don't have that much to say... except that everyday I use JavaScript, I like it more! Sure there are lots of drawbacks to it such as cross browser/os compatibility, and cross server insecurities... but you can do a lot to mitigate those issues, especially if you work with a good framework such as jQuery or YUI...
So what's the point of this whole post? Earlier today I created a js file that records metric information about website visitors... a pretty simple script... gather information such as screen resolution, user agent, color depth, ip address, session id, login id, etc and send it to a server side script to record the data.
So, one of the pieces I wanted to collect was the querystring. I wanted a clean one line solution to gathering that string.
I knew that window.location.href would give me the string version of the url currently in the browser so I thought I could split on the "?" resulting in "window.location.href.split('?')" Which in turn gave me an array containing 2 elements, the host string and the querystring... I am only interested in the query string... knowing that JS now treats the result as an array, I can grab the array element 1 (which is 2 in most programming languages...) like this: "window.location.href.split('?')[1]"... and there I have it!
Wednesday, April 23, 2008
Wednesday, April 16, 2008
Speed up your website
The creators at Yahoo have done it once again! What started as 13 rules became 14, the 23, and now 34 best practices for speeding up your website. This is a GREAT article and a MUST READ for any web developer. These 34 items are sorted into 7 categories. Some are pretty advanced and require changes in your server configuration, but many of them are simple changes in your practices that can have a profound change on the the speed of your website, or at least the perceived speed, which is just as important.
Labels:
best practaces,
Programming,
Speed,
Website,
Yahoo
Wednesday, April 9, 2008
Google is once again pushing the limits...
Google has recently released in limited beta a SDK/App Engine/Framework called the Google App Engine, to which you can develop web based applications using the same infrastructure that software like GMail, Google Calendar, and the other Google Apps have been created on, and then host them on the Google servers... their SDK/API is pre-built to handle scaling and heavy traffic loads (up to 5M pageviews/mo with a free account) and increasing storage needs (500mb on free account)... also they give direct access to Google mail API, Google file storage, Google "Datastore" (their db system) and plan on taping into others like calendar... Also, you can use your own custom domain names to point to your apps... Finally, Google is allowing you to use their authentication system for authenticating your users! No more asking users to create yet another login for yet another web application!
Now I'm not saying this is better than hosting your own server, but it is pretty stink'en cool!
One downside is that it currently supports only Python... I might be learning a new programming language! =)
Now I'm not saying this is better than hosting your own server, but it is pretty stink'en cool!
One downside is that it currently supports only Python... I might be learning a new programming language! =)
Friday, March 7, 2008
Wez gotz da hookupz

I am pretty excited about this... We have finally been able to order some new audio hardware for "The Block", our kid's church! Hurray!!!
We are getting hooked up with Sure's new PG1288/PG30/PG58 wireless microphone system. It comes with a PG58 Wireless Handheld, a PG30 Wireless Headset and a dual channel PG1288 wireless receiver!
A BIG thanks to my awesome big brother, Jeff Fogg in Pro Audio with Guitar Center Tucson, 520-358-7751... He hooked us up with a PHAT deal... With the whole order, he saved us almost $50 over the cheapest online competitor!
Now, the only thing left to do, is to hurry up and wait for UPS to deliver!
Wednesday, March 5, 2008
Upper limits of the query string...
So I ran into a problem recently where information was not correctly being passed from one remote page to another... It took quite a bit of digging to finally find the root of this issue. It turns out, that in addition to having to deal with issues with cross-browser compatibility regarding JavaScript, we also have to deal with it regarding the querystring!
Now I know what you are thinking... who in their right mind passes so much information in the querystring that it would reach the upper limits??? I agree with you, but it is currently out of my hands.
Building "widgets" and "plugins" for commercial sites that expect to be able to "remote authenticate" can be quite tricky... especially if they are built on 4th party CMS's that decided to build their own proprietary server side scripting language (that remotely resembles classic asp)...
Okay, long story short, I am passing variables to the remote authenticator via POST variables... that software is then authenticating the users and moving all of those POST variables to the querystring as GET variables to return the user back to the clients CMS where we then process their data... I know, I know, it's an incredibly complex mess, but until the CMS is able to provide us with methods to read and write cookies, we are stuck with it.
So, it turns out that although this specific case works fine with FireFox and even Safari, it breaks in Internet Explorer (what a surprise =). Because of this I did some testing... and here are the results:
Now I know what you are thinking... who in their right mind passes so much information in the querystring that it would reach the upper limits??? I agree with you, but it is currently out of my hands.
Building "widgets" and "plugins" for commercial sites that expect to be able to "remote authenticate" can be quite tricky... especially if they are built on 4th party CMS's that decided to build their own proprietary server side scripting language (that remotely resembles classic asp)...
Okay, long story short, I am passing variables to the remote authenticator via POST variables... that software is then authenticating the users and moving all of those POST variables to the querystring as GET variables to return the user back to the clients CMS where we then process their data... I know, I know, it's an incredibly complex mess, but until the CMS is able to provide us with methods to read and write cookies, we are stuck with it.
So, it turns out that although this specific case works fine with FireFox and even Safari, it breaks in Internet Explorer (what a surprise =). Because of this I did some testing... and here are the results:
Browser version querystring upper limit
FireFox 2.0.0.5 8182
Safari 2.0 8184
IE 7.0 2047
Labels:
browser,
cross browser compatibility,
querystring
Subscribe to:
Posts (Atom)