I had been thinking that it would be nice if the navigation on our pages did not affect the overall ranking in search engines. Particularly the AAAS search engine, which doesn't do so well when the search terms include words from the navigation. Some kind of container tag or attribute that could be used to say "don't look at this" to the search engine spiders.
Supposedly a method was floated a few years ago, but nothing came of it. In all likelihood the major search engines have already come up with methods of decreasing the weight of content that is reapeated often on an individual domain.
To put a final nail in the coffin of this idea, AAAS updated their search engine this year and it appears to do a much better job than it used to.
Wednesday, June 21, 2006
Tuesday, June 20, 2006
IERI R3: On PEAR and Code Separation
PEAR Components
I was trying to decide if I should utilize some of the components available via the PEAR library. Some of these components are under constant development and so would provide a significant source of well-written and debugged code. Specifically, there's a authentication/permission module that might integrate nicely with the utility. Upon further thought I decided that for now I'm going to try and do a lot of the coding myself (except for the occasional module). This is my first major PHP application and I feel the best way to familiarize myself with language is to do the programming as much on my own as possible. By taking my time to develop the code myself I should be better able to evaluate third-party code in the future.
If future revisions of the utility are created it may be benefitial to look at incorporating PEAR components where possible.
Code Separation
On another note, I was thinking about the separation of processing code and user display. The more separate the two aspects of an application the easier it is to update either one. IERI is one of the more complex applications I've developed and it's a bit difficult to determine how to best achieve the separation. I've not gotten very far in the current development (authentication completed) but I can already see how even something so simple as authentication could be utilized as a separate component from the user interface for user login (allowing authentication via JavaScript, for example).
I do plan on attempting to separate the code from the display as much as possible in anticipation of AJAX-oriented development down the road. I guess one of the questions I have right now is how much extra time will be required to rewrite an integrated page into a separated one. I'm hoping that any pages I develop singularly will be fairly easy to upgrade if I utilize function calls and other methods of extracting the logic from the normal processing flow.
I was trying to decide if I should utilize some of the components available via the PEAR library. Some of these components are under constant development and so would provide a significant source of well-written and debugged code. Specifically, there's a authentication/permission module that might integrate nicely with the utility. Upon further thought I decided that for now I'm going to try and do a lot of the coding myself (except for the occasional module). This is my first major PHP application and I feel the best way to familiarize myself with language is to do the programming as much on my own as possible. By taking my time to develop the code myself I should be better able to evaluate third-party code in the future.
If future revisions of the utility are created it may be benefitial to look at incorporating PEAR components where possible.
Code Separation
On another note, I was thinking about the separation of processing code and user display. The more separate the two aspects of an application the easier it is to update either one. IERI is one of the more complex applications I've developed and it's a bit difficult to determine how to best achieve the separation. I've not gotten very far in the current development (authentication completed) but I can already see how even something so simple as authentication could be utilized as a separate component from the user interface for user login (allowing authentication via JavaScript, for example).
I do plan on attempting to separate the code from the display as much as possible in anticipation of AJAX-oriented development down the road. I guess one of the questions I have right now is how much extra time will be required to rewrite an integrated page into a separated one. I'm hoping that any pages I develop singularly will be fairly easy to upgrade if I utilize function calls and other methods of extracting the logic from the normal processing flow.
Web Site: Spanish Content Update
I made a relatively minor update to the Spanish content on the site ... added a lang attribute to identify the content as being in Spanish. I don't expect it will make much of a difference to users of the site, but it's good web etiquette. My one hope is that search engines will find it useful.
I should spend a little time making sure any English text in the Spanish documents is appropriately identified.
I should spend a little time making sure any English text in the Spanish documents is appropriately identified.
Wednesday, June 14, 2006
Webtrends irregularity
Webtrends died again on some log entries ... see below.
2006-05-24 17:07:19 W3SVC48143651 WIZZLE 198.151.218.130 GET /publications/articles/psl/pdf/fgs_sacramento.pdf - 80 - 206.15.252.158 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+yie6;+.NET+CLR+1.1.4322) - http://search.yahoo.com/search?p=Teens-Sacramento%2C+CA-Science+programs&sm=Yahoo%21+Search&fr=FP-tab-web-t&toggle=1&cop=&ei=UTF-8&vm=r www.project2061.org 200 0 64 262401 587 6734
2006-05-24 17:07:24 W3SVC48143651 WIZZLE 198.151.218.130 GET /publications/articles/psl/pdf/fgs_sacramento.pdf - 80 - 206.15.252.158 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+yie6;+.NET+CLR+1.1.4322) - http://search.yahoo.com/search?p=Teens-Sacramento%2C+CA-Science+programs&sm=Yahoo%21+Search&fr=FP-tab-web-t&toggle=1&cop=&ei=UTF-8&vm=r www.project2061.org 200 0 64 327937 587 4750
2006-05-24 17:07:27 W3SVC48143651 WIZZLE 198.151.218.130 GET /publications/articles/psl/pdf/fgs_sacramento.pdf - 80 - 206.15.252.158 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+yie6;+.NET+CLR+1.1.4322) - http://search.yahoo.com/search?p=Teens-Sacramento%2C+CA-Science+programs&sm=Yahoo%21+Search&fr=FP-tab-web-t&toggle=1&cop=&ei=UTF-8&vm=r www.project2061.org 206 0 0 161566 695 3390
Friday, June 09, 2006
Mass Mailing: 2061 Connections - May/June 2006
The May/June 2006 issue of 2061 Connections went out on 9 June 2006 at 4:20 PM to 3910 recipients.
Subscribe to:
Posts (Atom)