Well if you read the presentation carefully you will see that one of their reasons to use PHP was clarity of code.
I.E. Perl may take "less code" but less is not always better - especially if you have a MULTIPLE developer environment. I have never seen a large scale Perl application that was easy for multiple developers to maintain and manage - the differences in coding style are too great, and the ease of obfuscation too high.
PHP on the other hand is a very clear language, and while yes, the OOP pieces are not primary, the language itself is very well designed for developing web-applications.
My experience with PHP is that of owning a software company whose products are entirely PHP based. These include near-realtime AI applications. PHP has been a very powerful component in our development process - allowing us to write applications that are clear, easy to understand, well documented, and still fast and scalable.
While it is certain that we could have done much of this in Perl, it is also very likely that it would have taken us longer to code, and that ongoing code reviews would have been more difficult - further PHP's simplicity is a large part of the value.
Our code is anything but simple - we have code that is auto-generated (on the basis of data we have code that writes itself), our code manipulates multi-dimensional arrays, we do file, web, and database access - all in a very compact amount of code.
In an enterprise development environment performance speed is NOT the only criteria, ongoing development and maintanence issues are also very crucial.
Fast code, that is impossible to debug, maintain, update, or correct when something has to change rapidly costs more than the costs of adding slightly more hardware/bandwidth/memory to support the software.
Indeed, in supporting developers the largest advantage of a migration from a complex (but powerful) language to a more simple language is the increased clarity of the code (C++ to Java; Perl to PHP). While you can argue till you are blue in the face about the relative merits of each language - a language that encourages clean code and facilitates rapid development and intra-developer communication is a very very good thing.
Additionally, there are many people who might indeed know HTML, but for the purpose of writing quick comments on a site they are looking at do not want to bother with FTP, edit, upload and manually updating links etc, just to add a note like "remember to check out this site..."
I for one use the "Blogthis" bookmarklet a lot - very useful when I want to jot a few notes about a site.
Since my current bookmarks file is over 1000 sites and growing, just adding a bookmark is rarely sufficient - now when I encounter a site that I am interested in I usually add an entry to my blog - takes a few seconds and then it is stored on a remote server.
I also use the blogspot hosting features of Blogger - in large part to AVOID having to have FTP access set up on a remotely hosted service - someday soon I'll probably pay for Blogger Pro and the adfree blogspot hosting service.
One of the major risks with cookies is in tracking - i.e. the seemingly all pervasive "doubleclick" cookies - which can be used to track you doing who knows what...
i.e. cookies used to pass information on to a third-party OTHER than the organization whose site you are browsing - all it takes is one little gif (the "bug") put on a webpage to allow the third-party to send or request your cookie when you load a site.
This in turn builds up a log file that could be tracking all sorts of things - useful from a advertiser's perspective, but also a real privary and potentially security concern (why should a third-party who do not intend to visit have an ability to log both the sites you visit, potentially your actions on those sites, and your route(s) to them).
The security concern being if this path/action/route information exposes you in some way (for example - connecting your private accounts to work accounts, or revealing other identifiable information - not to mention just something as simple as revealing what you have been searching on..)
Most big services, such as Doubleclick, claim that such information is used only in the aggregate - but with no scrutiny who is to know?)
And don't forget that your browser tends to be a fairly chatty piece of software, gladly showing your IP address, what version it is, what page you just came from, etc - all of which might be captured as part of such a log process.
Generalizing somewhat, there are FOUR options for a company currently in "high tech".
One - Sell hardware. Generally billed once, though often financed and perhaps with a "support package" attached
Two - Sell "software". Usually licensed with an annual "maintance" agreement in addition (speaking of enterprise software - in consumer terms this is the annual or bi-annual upgrades/updates that you have to pay for)
Three - Sell a "service" (think ASP's, telcos, ISPs - generally billed on a periodic basis - often monthly, but also quarterly or yearly plans exist).
Four - sell "consulting" or services. This is further subdivided into "project work" or "outsourcing". Projects are generally of a limited duration and for a specific purpose, outsourcing usually involves the takeing over a company's IT staff, equipment, and processes - and is generally of a very long term duration.
There are, of course, variations to all of the above - but these are a basic choices that a company today faces - and all of these are driven in tandem by corporate needs.
New software usually meant new hardware, plenty of services needs, and lots of projects and outsource contracts to go around.
However, we are still suffering from the combination of Y2K, the "dotcom bust", and diminishing returns on technology investment (or at least the PERCEPTION of diminishing returns).
Y2K caused many large corporations to move up spending - which they had planned to do in the past two-three years, to 1999 so as to put new software and systems in place in advance of Y2K. In the course of doing this major corporations also steamlined and simplified their internal systems - often reducing by 50% or more the number of applications they supported internally.
Further, many corporations standardized on fewer platforms - and reduced variation within their corporations.
In 2000 it appeared that perhaps the "Internet boom" would be the driver of future investment in a post-y2k world - and indeed many corporations spent a lot of money on Internet/e-commerce projects - however though a lot of money was spent on these projects, and some companies did see big gains - far less money was spent on Internet projects than had been spent on ERP or other similar enterprise wide projects.
Further, as a new field - most of this money was spent on consultants and projects. Some was spent on services (hosting packages, additional T1s etc) - but less spent on software packages or additional hardware.
Software companies and hardware companies alike have not, in general, offered compelling new systems that provide powerful reasons for additional investment - corporations look at the desktops and servers that they have, note that most of their systems are underutilized, and see little reason to return to regular upgrade cycles - rather they see little to be gained from expensive upgrades - and much to be said for focusing their resources on using what they already own.
So, this in turn, means that corporate internal resources are increasingly available for internal projects - reducing still further the need for outside consultants on a project basis.
What then is the solution?
First - technology is driven by providing VALUE - i.e. providing systems that help people make money (by saving them money or making people more productive). Software vendors should focus on what their tools "really" need to do - and make compelling enhancements in those areas.
Second - We may be seeing a transition from a mostly growth industry to one that will be more stable - there is still money to be made, but annual growth rates of 30+% are probably a thing of the past.
Third - companies should focus on building long term value added relationships with their customers - if you make your client money on an ongoing basis, that is generally a recipe for continued and mutually profitable business - in the "internet boom" many service/consulting firms forgot this - they made money, but their clients just lost money - now those clients are often reluctant to spend further funds with those firms (if the firms are even still around).
So what do I suggest - focus on value added, focus on building systems that customers want, and offer them in a model that both you and your customers gain value (i.e. don't price in such a manner than it is impossible for your client to make money, or conversely don't price your products, services, software, or consulting below what you need to make profit - neither route leads to long term success.
As the president and founder of a software and consulting firm started in 2000 I have observed this up close and personally - at present, my firm is focused on out consulting practice - looking at how we can continually add value to our clients - and still make money doing so.
I recall reading about a case (I believe during WWII) where "One time pads" were broken.
Some because a "one time" pad was reused (a no-no clearly) - but more because someone (the English I believe) figured out how the one time pads were being generated - which then led to being able to break the code.
The point being that a large number of "one time pads" (i.e. most normal use cases of them) requires some method of generating (and then sharing) the pads - if this method is discovered then it is possible to break them.
Re:Practical but... - One Solution (more complex)
on
Perl & LWP
·
· Score: 1
I agree.
So, my company developed software that uses AI-like techniques to avoid this problem - not a trivial problem to solve, but valueable when you do.
What we've done (using PHP not Perl but the techniques and languages are very similar for this piece) is do a series of extraction steps - some structural and others data related - the structural steps employ AI-like techniques to detect the structure of the page and then use it to pass the "right" sections on to the data extraction portions.
This employs some modified versions of HTML parsers, but not a full object/tree representation (too expensive from a memory and performance standpoint for our purposes) - rather we normalize the page (to reduce variability) and then build up a data structure that represents the tree structure, but does not fully contain it.
In simpler terms - this stuff can be very complex, but if you need to there are companies (such as mine) who can offer solutions that are resistant to changing content sources and/or are able to rapidly handle new sources (in near realtime).
If you are interested feel free to contact me off Slashdot for more information and/or a product demo. www.jigzaw.com
Given the complexity of the licensing costs of Windows XP and Office XP, as well as the server load, one option to look at would be Apple hardware running Office 10 (Which Microsoft themselves have said is the best version of Office they have ever written - better than anything on Windows).
OS X is a full fledged Unix - so porting applications to it generaly involves just a recompile.
As servers for File sharing, Mail, etc either expand your current Sun system, look at using a Linux server, or perhaps look at an Apple as well.
Generally networking Macs is very simple and quite robust, so support should be easier than you might expect.
As a further benefit you gain some protection from the constant security patching cycle on Windows.
Finally you also get physically attractive systems (new iMacs for example), at reasonable price points, and with hardware that your CFO should be pleased with as well (retains value longer than typical PC hardware).
For your laptop users, the Apple laptops are some of the nicest on the market, and offer the full array of wireless networking, dvd etc that your users may demand.
Well if you look a bit more carefully they differentiate their sources into "subscription" and non-subscription documents. They provide a list to the subscription document sources - which since they range from such compelling documents as "10 Tips to Healthy Eating" to "Zinc" and include such best sellers as "Young People With Cancer: A Handbook For Parents" and "Waste Treatment Technology News" to pick just a few samples.
It looks as if the subscription documents include mostly sources for which Northern Lights (and now Yahoo!) have minimal if any costs to provide.
Most results I found for some test searchs I did were from sites not included in the subsciption.
So, while the subsciption is a good deal if the sources you need access to are included, in practice I think most users will tend to find results that are not free.
Some, but not all of the sources that they charge for are also available elsewhere on the web for free (some magazines) - however this does require additional searchs - if you are doing research for work, the ease of access might well be worth the few dollars - particularly if the billing is handled in a smooth and simple fashion.
"What you don't seem to realize is that HCI studies are all a complete load of bollocks; HCI is the "social policy" of Computer Science. (Thinking in degree terms). "
Well... perhaps the studies that you describe - but in the course of researching the software my company is developing I have read a number of serious HCI research papers and dissertations. The really good researchers observe real users in their REAL environments.
This research then looks a many different environments, for example multiple large corporate environments as well as other large scale computer users such as government labs. In observing how different groups solve the same basic set of tasks using different software products the researchers can learn a great deal about the influence of user interface and other design decisions on actual real use, productivity, and effect (and well as effectiveness) of software packages.
From this research it seems generally accepted that around 80% of ALL users of ALL computer software do not change the defaults - so the defaults that a software company or corporation sets for the software they use or sell is critical.
For the one of the specific researchers I am speaking of look at her website at: LeysiaPalen Home Page.
To relate a funny story along these lines - a friend of mine (admitedly one who was studying a rather obscure piece of early English writing) encountered a word in the book she was reading that she did not recognize.
So like the good scholar that she is, she turned to the library's copy of the OED.
And, to her amusement (and slight annoyance) the OED's only citation (and only definition) was the very work she was reading...
so - it does go to show that just citations may not always answer the question of just what the word means... (but then in this case perhaps no one really knows).
Fact One - ALL products start off as "non-working" designs - and get evolved into what can actually work - on a TV show, film, novel, or short story perhaps more hand waving happens - but the process is not too disimilar to what "real" product develoment is.
Fact Two - There are very few items that we "can't" build today - particularly electronic devices the actual "working" parts and components have shrunk to nearly nothing - the designer of ALL of Nokia's cell phones was recently quoted in an article (see Business 2.0 Dec edition) as saying that now "Battery size vs. duration is no longer a design issue" - i.e. they can build it any size or shape they want.
Fact Three - Most inventions come about by someone taking an idea or concept, ignoring conventional wisdom that "it can't be done", and just setting off to do it.
So, as an inventor myself (developing very complex software products built on cutting edge AI research) - most of what I build could easily be seen as being "impossible" - it is my job to figure out what that is not so...
Also, think about all the technology that has been developed simply to fool us into to thinking that something works - i.e. the Special Effects industry, CGI graphics, etc.
Another place to look and consider - a bit off the beaten track - Dick Tracy - certainly inspired the cell phone concept to a degree, as well as the comics and radio dramas of the 1930s onward - perhaps no direct "inventions" but a lot of "impossible" ideas explored in ways that certainly inspired the "real" world creators of those items years later.
(see stuff like the actual working "rocket belt" used by Las Vegas special effects people - it really does work - and it was clearly inspired by comic books)
Very few inventors I have met were uninfluenced by the ideas of science fiction - from at least some medium (radio, tv, film, short stories, or novels). I often read novels and consider whether I could "actually" do any of the items suggested.
I am also an author myself - writing fiction and science fiction, indeed when I started my own company I went through an exercise of writing a "story" about how my technology could be used - this definitely is a part of how I think though the "story" of my company and our products - as a firm inventing something not yet in mass commercial use we have to be able to envision the impact and uses of our technology - and then tell the story well enough to make it true.
What is the sales process of any new technology but that of telling a story? If instead of telling the story completely on my own I could point to a TV show and say "thats what our firms' devices will be like..." it clearly helps (though it also could invalidate a patent...*grin*)
Well this was a few years back, the early 1990's, I was supporting my college dorm's network, including the shared Apple Laserprinter at the front desk.
It was 2:00am on a cold early winter night when I was awoken by a phone call.
"Uhmm there's something wrong with the printer"
"What?" as I struggled to awake.
"Well for the past two hours its been printing the same pages over and over."
"I'll be right down."
Sure enough, it had been printing page one of some unfortunate student's final paper hundreds of times, though it had briefly alternated by printing hundreds of copies of page two.
After about an hour of futzing, and some swearing at the *#$#$#% print spooler software, I had the printer back online and working. In the process I deleted 7 print jobs that had been sent after the one corrupted print job that had been causing all the problems. In the course of my solution I had to disconnect and powerdown the print spooler and the printer and ensure that their memory caches were flushed.
With the printer fixed, I managed a few hours of sleep before my classes the next day.
And so the stoy remained for the rest of that week. But, seven days later, now comes the part that I can't explain.
I returned to the dorms after my classes that winter afternoon, nothing appeared out of the ordinary, but I stopped at the front desk to see how the printer was doing.
"Well we have these 7 printouts that no one has claimed"
Sure enough, seven days later the 7 print jobs I had deleted had been reprinted, the banner pages showing print dates from 7 days previously.
To this day I still can't explain it... ghosts in the machine sums it up best.
Security is extremely tough to get right - if you are working on an insecure environment it is much harder to get right.
For a linux person - would you really want an application with every script and executable SUID to root?
Or would as a general rule of thumb it be better that the app is developed to be run as a user (not as root)?
Similarly Windows apps intended to be run by "regular" users in a corporate environment should be developed on a platform and as a non-admin user.
Either on Unix, Linux or Windows apps that run as administrator can easily have unforseen consquences ("hey we need to escape to a shell in this app.." guess what that means for SUID application....)
What I am referring to is NOT a "particularly severe" form of beaucracy - it is adhering to a policy that is designed to avoid unintentional (and intentional) problems that all the management in the world can't avoid.
If you have the ability to just "get in there and fix it" - you may or may not tell anyone that you did so - and you may not remember that you did it (or what exactly you had to do) when it comes time to building the application "for real".
The challenge of an organization is to put in place controls that are effective - they exist for very good reasons - if applications are being used by the business, but can not be recovered/rebuilt/patched because the developer who built them leaves - the entire company is at risk.
If you as a developer return to an application that you build 6 months ago to fix problems with it - you are setting yourself up for a nightmare potentially if your code is impacted by other changes to your applications, OS, or build tools in the 6 mths since.
In the company I am referring to the developer's themselves were the people making the decisions with regards to items such as "powerbuilder" vs. VB (using both for different purposes) - again though it was decisions made at the scale of the entire organization - just becuase you personally preferred a particular old version of FoxPro - that might not be the best tool for the organization as a whole to standardize on - and if you are the only developer in 1000 to know that tool - you are limiting your future at the firm as well (who really wants to only maintain an application they wrote 5 years ago - most developers prefer to be able to work on new applications as well)
If the developers have to wait for weeks to get their systems fixed the solution is also to make the development organization a much much higher priority than it appears to have been at your firm - management in general should be clear about who needs rapid responce - if developers who are highly paid can not work they should be put back to work quickly.
The point of the system I am describing was to make the development teams aware of each change they made to their systems - this was not intended to make change impossible - rather it was intended to make it just painful enough to remember to document and test the processs.
In the environment I am decsribing we also had systems in place to bounce back to the development teams their code if they were using pre-release/beta compilers or external libraries - this could easily result in delays to deploying their applications and all sorts of other nightmares (and more long days and nights for everyone) - there is a role for using beta/pre-release applications - but that role is not in supporting the business - it is reading the future development for upcoming changes - once stable then you can switch over.
While I agree that a test environment is important (indeed it was my role there) and that many of the issues can indeed be solved by good management, my fundemental is that in all environments casual Admin access is not a good thing - not due to whether or not the developers are "good" or not - it is simply due to how people opperate.
If you have certain rights on a machine - it is harder to catch when you are doing something that requires those specific rights (for example writing to a restricted directory) - it is not maliciousness or poor developers that do this - it is not using the security systems and structures correctly.
Further, I think you may misinterpert what I mean by "production" - while I am a strong Linux/Unix advocate for Internet systems (indeed I am Sun certified) - for corporate systems with very skilled developers NT systems serve important and indeed production roles. The NT developers at the company I am referring to were highly skilled COM developers building production financial trading floor applications which ran on WindowsNT workstations internal to the corporation - the NT systems and their workstations while not immune to problems - were when well managed and well run (which this firm did do - albiet at an extremely high cost) - they served a valuable role.
It was not a "production site" in the sense of a website - rather these are hardcore financial applications.
Also in terms of test sites and change management - there is a constant and ongoing battle between the business needs and "best practices" - when a change means the literally millions of dollers an hour - the process should be highly controlled but also highly efficient and rapid.
One means to ensure rapid migration from the development environment (perhaps through a test/build environment) to production is to keep the THREE environments in synch with each other. I.E this means ensuring that the developers are building using the same tools, patch levels, and build systems as the eventual test and production enviroments.
Since developers are not usually also people who want to admins - while they may know enough to install patches and new apps - they probably do not want to document every step and/or follow highly documented and tracked procedures - they want to get back to coding as quickly as possible - it is a compromise on both sides - I agree - but in a large scale corporate environment that is vital to keeping the entire system running smoothly (which translates in the long run to a more profitable company, stable jobs, and good pay.)
The company I worked for was NOT at all a nightmare of a place to work for - it was one of the best run (and highest paying) firms around - developers were engaged in very interesting, cutting edge development of very cool apps (one of the first Marimba application deployments for example) - generally there was a compromise with the developers which very much related to the stage of their application - as they approached releasing it to end users and as they supported released applications they had to endure a more restricted and locked down development environment.
To counter this the development teams themselves were the people within the organization who controlled the pursestrings for development application - and a committee of the technical leaders of the development groups set the corporate standards with regards to build tools, languages, application versions, and policies and procedures.
While there were still individual developers who might chafe at times - generally they saw the value to the overall process after it saved them significent time (and money) when it came to keeping their end users happy - being able to move a change from development to production when needed in a 24hr period to get trading centers back up and running - but still adhering to documented processes and tested environments was the proof of the pudding.
Something to consider about "locked down" vs. "developers with admin rights".
There are some extremely valid reasons to insist that developers have to take some pains to have admin rights to their NT machines.
1. Developers can easily "assume" admin rights when developing their software - and then blithely write software that requires write permission to an admin only area for example.
This could have easily resulted in a very expensive problem had I not caught this during building of the application for that development team at a very large (top 5 in world) finacial instituation I once worked at. Since the developers had admin rights they wrote a Java application that stored all config details in the Windows directory - very bad, but very subtle.
2. Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
When the time comes to build the applications they are developing this can result in subtle errors and problems - both in interim development builds between members of the same team (who have differently built NT workstations) and when the code moves from development to production - during which it would likely be built on "standard" build servers - the wrong set of patches to a compiler or different shared libraries and the resulting code will differ considerably.
Note further that such issues are not usually solved by standard source code administration practices (CVS, MS SourceSafe, ClearCase, MKS Source Itegrity etc) all of which usually do not track the installations, builds, and patches of the OS, compilors, and shared libraries.
3. Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production... not a good thing at all.
Corporate development is a tradeoff between developers and the requirement of running the business - if you are developing on the fringes - or in a research lab environment that it is one thing, but when you are developing applications for the business's production environment (or to be shipped to clients or made available for sale) then rigorous and documented processes should be followed with regards to the machines that are used to develop and build the applications, if you don't you will eventually get burned.
I speak from the experience of working with over 1000 developers building and supporting over 650 internally written applications.
There is in fact an Internet Draft called Calendar Access Protocal (CAP). When completed CAP is designed to be a standardized means of accessing a calendar server.
More information can be found at the website for the Calendaring and Scheduling Working Group (www.calsch.org) which is responsible for CAP as well as RFC 2445 (iCal), 2446 (iTIP), and 2447 (iMIP).
I am very active in the working group and am helping edit the iCalendar RFC.
In dealing with my representative - while talking to him at a local town hall he noted that when his personal email address had been made public he recieved over 10,000 emails in ONE DAY! As a result he no longer checks that address (surprise surprise)
So, he recommended that I contact his local office manager here in town (who gave me his email address and contact information) - he could directly help me in many matters - and could relay my feedback the Representative in other cases.
When I get some free time (right...) I plan on offering to help provide technology information, feedback, and comments to the Representative - as the President and CEO of a software company based in his district I hope he will at least listen to what I have to offer - my goal is to offer technically well grounded information on options he may not know about.
One specific example being some suggestions about low-cost methods of providing high value training to local residents - our district includes the richest and poorest parts of Chicago - it is my view that initiatives that encouraged the use of Unix systems in job training and educational programs in the district would offer a very strong value to the students and for the government.
Anyway, more for Rep. Davis when I have more time.
Some suggestions and alternatives
on
GOVNET In the Works
·
· Score: 3, Interesting
As is often the case this sounds like people who only know a bit about the technology and options making very expensive suggestions.
A few alternatives to consider:
The government expanding the network already in place for the "Internet 2" initiative (high bandwith application testing) which currently exists between a network of universities, is already in place, and already has the fiber allocated and lit.
The government buying (or leasing in some form) some of the thousands of miles of dark fiber strung recently in the massive network infrastructure buildout.
Then, a second more practical and imporant suggestion. The government's goals are to ensure secure communication, ensure access to critical government data (not so much websites but FBI photo files, salelite imagary, even census data), and ensure critical command infrastructures.
Look at how non-goverment agencies accomplish very similar tasks - Banks use a web of network providers (usually at least two, often three) providing basic network connectivity to data centers; they often layer this with dedicated encryption (so that any traffic across public switched networks is encrypted); sometimes there are networks with-in networks (VPN tunnels etc); and there is extensive (and expensive) redundancy of all systems (and usually key people).
This redundancy would be rather expensive and difficult for most government agencies - but it is likely required. This includes physical as well as technical redundancy (i.e. serious data centers have power from multiple power grids entering the building at multiple locations; similarly they have data leaving the data center in multiple ways.
Now the good news - the government could probably pick up seriously redundant data centers, servers, networking equipment, fiber (dark or lit but already in the ground) for a very reduced price with the recent consolidation and collapse of hosting providers and network equipment vendors.
Rather than using this to build an entirely seperate network - if the government took the appropriate steps to secure and protect the system if could overlay the existing Internet without much difficulty.
(I would recommend of course that the government look at using the appropriate equipment for this job - i.e. secure and reliable OS's runing on physically secured machines)
Hope someone reads this and expands on my suggestions.
- some disclusures - I do not currently work for the government - my company is a software and consulting firm that may in the future do business with the government.
Don't forget that the Code Red and Nimba worms are spread by many vectors - which means that through email or web surfing they can penetrate into internal networks that are otherwise removed and cut off from the Internet as a whole. I imagine that many internal IIS servers at the government and at corporations were infected via web surfing from internal Windows clients.
Chess can be taught to anyone at almost any age - it does take patience to master - but it can be learned very easily.
I was taught Chess by my grandfather at age FOUR - one of the best legacies he could have ever given me.
Here in Chicago one of the great aspects of playing chess is that it is an activity that is open and available to anyone of any race, sex, or age - go to any of the public chess pavilions (actually this is true around the world for the most part) and you will find a group of people who would unlikely talk to each other in other circumstances playing a game for hours at a time.
I have seen traders from the board of trade playing homeless men - and often lossing.
There are hundreds of books and courses for how to teach chess - books and techniques tailored to any age - learning chess is a very powerful experience, it is fundementally a simple game - much simplier than most PC games - what makes it so difficult and so rewarding is how a very simple set of rules (7 types of pieces, two "special rules with pawns, one special move with King and rook, some special rules with one piece the king - that's really it) can create amazing complexity.
Books I would strongly recommend is anything by a Lasker (either Emanuel Lasker or Edward Lasker). Emanuel Lasker's books are on my short list of the most influential books I have EVER read - they teach a great about how to think - not just how to think about chess.
Both books teach chess backwards.
They start by teaching how to move the pieces, then how to win in the endgame with only a few pieces on the board, then common ideas/elements of the middlegame, and then and only then do they talk about the opening - and here rather than teach specific opening lines they concentrate on understanding WHY certain moves are made.
After understanding all this, not only do you play fairly decent chess, but you also begin to have a good feeling about how understanding something can help you make decisions, how small decisions can lead to bigger things in the end - all important lessons in life.
Play chess is also a great chance for students in any situation to get exposed to the world - they can play each other, over the computer they can play online against people of similar skill levels across the globe, they can even participate in tournements - either in person or online.
One of the joys of my life is the fact that in any city, nearly anywhere in the world, if I find a place where chess players meet, I can find a place where I can meet friendly people in that city - I have played chess all over the world - one of the best times being playing in the Luxumbourg gardens in Paris against an Englishman who lived in Paris - as an American tourist how else would you get to randomly meet people who live in that city.
So, I have to disagree with Garcia on the subject of chess - go ahead and teach your students chess - there are many great computer programs to help, and many great online resources for them to explore - it will give them a skill and an entre into a world that they might not otherwise enter.
Some real examples of this - through playing chess I have met millionaires, russian imigrants, hispanics, african americans, and many other people of as diverse a range of backgrounds, educational levels, and jobs as you could find. I have friends ranging from Business school professors, cab drivers, traders at the board of trade, city workers, to retired former "special assistants to Mayor Daley (Sr.) 75+ year old retires play 14 year teenagers. Through playing a common game we share a common passion (some would say madness) and over chess either in a public square, a local coffeeshop, or a local chess club we have a chance to meet, talk, and get to know each other.
This occurs in a manner very rare in American - your students would seem very likely to benefit from learning and playing chess.
Ask around - I suspect that there are local chess clubs, chess teachers, and probably even a grandmaster or two who would be very willing to help teach chess to your students - chess is a passion and most serious players love to share it.
Slashdot Mirror
Well if you read the presentation carefully you will see that one of their reasons to use PHP was clarity of code.
I.E. Perl may take "less code" but less is not always better - especially if you have a MULTIPLE developer environment. I have never seen a large scale Perl application that was easy for multiple developers to maintain and manage - the differences in coding style are too great, and the ease of obfuscation too high.
PHP on the other hand is a very clear language, and while yes, the OOP pieces are not primary, the language itself is very well designed for developing web-applications.
My experience with PHP is that of owning a software company whose products are entirely PHP based. These include near-realtime AI applications. PHP has been a very powerful component in our development process - allowing us to write applications that are clear, easy to understand, well documented, and still fast and scalable.
While it is certain that we could have done much of this in Perl, it is also very likely that it would have taken us longer to code, and that ongoing code reviews would have been more difficult - further PHP's simplicity is a large part of the value.
Our code is anything but simple - we have code that is auto-generated (on the basis of data we have code that writes itself), our code manipulates multi-dimensional arrays, we do file, web, and database access - all in a very compact amount of code.
In an enterprise development environment performance speed is NOT the only criteria, ongoing development and maintanence issues are also very crucial.
Fast code, that is impossible to debug, maintain, update, or correct when something has to change rapidly costs more than the costs of adding slightly more hardware/bandwidth/memory to support the software.
Indeed, in supporting developers the largest advantage of a migration from a complex (but powerful) language to a more simple language is the increased clarity of the code (C++ to Java; Perl to PHP). While you can argue till you are blue in the face about the relative merits of each language - a language that encourages clean code and facilitates rapid development and intra-developer communication is a very very good thing.
Additionally, there are many people who might indeed know HTML, but for the purpose of writing quick comments on a site they are looking at do not want to bother with FTP, edit, upload and manually updating links etc, just to add a note like "remember to check out this site..."
I for one use the "Blogthis" bookmarklet a lot - very useful when I want to jot a few notes about a site.
Since my current bookmarks file is over 1000 sites and growing, just adding a bookmark is rarely sufficient - now when I encounter a site that I am interested in I usually add an entry to my blog - takes a few seconds and then it is stored on a remote server.
I also use the blogspot hosting features of Blogger - in large part to AVOID having to have FTP access set up on a remotely hosted service - someday soon I'll probably pay for Blogger Pro and the adfree blogspot hosting service.
Or another simple (and real example):
.*
chown
Very dumb thing to do in retrospect... especially as root...
One of the major risks with cookies is in tracking - i.e. the seemingly all pervasive "doubleclick" cookies - which can be used to track you doing who knows what...
i.e. cookies used to pass information on to a third-party OTHER than the organization whose site you are browsing - all it takes is one little gif (the "bug") put on a webpage to allow the third-party to send or request your cookie when you load a site.
This in turn builds up a log file that could be tracking all sorts of things - useful from a advertiser's perspective, but also a real privary and potentially security concern (why should a third-party who do not intend to visit have an ability to log both the sites you visit, potentially your actions on those sites, and your route(s) to them).
The security concern being if this path/action/route information exposes you in some way (for example - connecting your private accounts to work accounts, or revealing other identifiable information - not to mention just something as simple as revealing what you have been searching on..)
Most big services, such as Doubleclick, claim that such information is used only in the aggregate - but with no scrutiny who is to know?)
And don't forget that your browser tends to be a fairly chatty piece of software, gladly showing your IP address, what version it is, what page you just came from, etc - all of which might be captured as part of such a log process.
Generalizing somewhat, there are FOUR options for a company currently in "high tech".
One - Sell hardware. Generally billed once, though often financed and perhaps with a "support package" attached
Two - Sell "software". Usually licensed with an annual "maintance" agreement in addition (speaking of enterprise software - in consumer terms this is the annual or bi-annual upgrades/updates that you have to pay for)
Three - Sell a "service" (think ASP's, telcos, ISPs - generally billed on a periodic basis - often monthly, but also quarterly or yearly plans exist).
Four - sell "consulting" or services. This is further subdivided into "project work" or "outsourcing". Projects are generally of a limited duration and for a specific purpose, outsourcing usually involves the takeing over a company's IT staff, equipment, and processes - and is generally of a very long term duration.
There are, of course, variations to all of the above - but these are a basic choices that a company today faces - and all of these are driven in tandem by corporate needs.
New software usually meant new hardware, plenty of services needs, and lots of projects and outsource contracts to go around.
However, we are still suffering from the combination of Y2K, the "dotcom bust", and diminishing returns on technology investment (or at least the PERCEPTION of diminishing returns).
Y2K caused many large corporations to move up spending - which they had planned to do in the past two-three years, to 1999 so as to put new software and systems in place in advance of Y2K. In the course of doing this major corporations also steamlined and simplified their internal systems - often reducing by 50% or more the number of applications they supported internally.
Further, many corporations standardized on fewer platforms - and reduced variation within their corporations.
In 2000 it appeared that perhaps the "Internet boom" would be the driver of future investment in a post-y2k world - and indeed many corporations spent a lot of money on Internet/e-commerce projects - however though a lot of money was spent on these projects, and some companies did see big gains - far less money was spent on Internet projects than had been spent on ERP or other similar enterprise wide projects.
Further, as a new field - most of this money was spent on consultants and projects. Some was spent on services (hosting packages, additional T1s etc) - but less spent on software packages or additional hardware.
Software companies and hardware companies alike have not, in general, offered compelling new systems that provide powerful reasons for additional investment - corporations look at the desktops and servers that they have, note that most of their systems are underutilized, and see little reason to return to regular upgrade cycles - rather they see little to be gained from expensive upgrades - and much to be said for focusing their resources on using what they already own.
So, this in turn, means that corporate internal resources are increasingly available for internal projects - reducing still further the need for outside consultants on a project basis.
What then is the solution?
First - technology is driven by providing VALUE - i.e. providing systems that help people make money (by saving them money or making people more productive). Software vendors should focus on what their tools "really" need to do - and make compelling enhancements in those areas.
Second - We may be seeing a transition from a mostly growth industry to one that will be more stable - there is still money to be made, but annual growth rates of 30+% are probably a thing of the past.
Third - companies should focus on building long term value added relationships with their customers - if you make your client money on an ongoing basis, that is generally a recipe for continued and mutually profitable business - in the "internet boom" many service/consulting firms forgot this - they made money, but their clients just lost money - now those clients are often reluctant to spend further funds with those firms (if the firms are even still around).
So what do I suggest - focus on value added, focus on building systems that customers want, and offer them in a model that both you and your customers gain value (i.e. don't price in such a manner than it is impossible for your client to make money, or conversely don't price your products, services, software, or consulting below what you need to make profit - neither route leads to long term success.
As the president and founder of a software and consulting firm started in 2000 I have observed this up close and personally - at present, my firm is focused on out consulting practice - looking at how we can continually add value to our clients - and still make money doing so.
I recall reading about a case (I believe during WWII) where "One time pads" were broken.
Some because a "one time" pad was reused (a no-no clearly) - but more because someone (the English I believe) figured out how the one time pads were being generated - which then led to being able to break the code.
The point being that a large number of "one time pads" (i.e. most normal use cases of them) requires some method of generating (and then sharing) the pads - if this method is discovered then it is possible to break them.
I agree.
So, my company developed software that uses AI-like techniques to avoid this problem - not a trivial problem to solve, but valueable when you do.
What we've done (using PHP not Perl but the techniques and languages are very similar for this piece) is do a series of extraction steps - some structural and others data related - the structural steps employ AI-like techniques to detect the structure of the page and then use it to pass the "right" sections on to the data extraction portions.
This employs some modified versions of HTML parsers, but not a full object/tree representation (too expensive from a memory and performance standpoint for our purposes) - rather we normalize the page (to reduce variability) and then build up a data structure that represents the tree structure, but does not fully contain it.
In simpler terms - this stuff can be very complex, but if you need to there are companies (such as mine) who can offer solutions that are resistant to changing content sources and/or are able to rapidly handle new sources (in near realtime).
If you are interested feel free to contact me off Slashdot for more information and/or a product demo. www.jigzaw.com
Given the complexity of the licensing costs of Windows XP and Office XP, as well as the server load, one option to look at would be Apple hardware running Office 10 (Which Microsoft themselves have said is the best version of Office they have ever written - better than anything on Windows).
OS X is a full fledged Unix - so porting applications to it generaly involves just a recompile.
As servers for File sharing, Mail, etc either expand your current Sun system, look at using a Linux server, or perhaps look at an Apple as well.
Generally networking Macs is very simple and quite robust, so support should be easier than you might expect.
As a further benefit you gain some protection from the constant security patching cycle on Windows.
Finally you also get physically attractive systems (new iMacs for example), at reasonable price points, and with hardware that your CFO should be pleased with as well (retains value longer than typical PC hardware).
For your laptop users, the Apple laptops are some of the nicest on the market, and offer the full array of wireless networking, dvd etc that your users may demand.
Well if you look a bit more carefully they differentiate their sources into "subscription" and non-subscription documents. They provide a list to the subscription document sources - which since they range from such compelling documents as "10 Tips to Healthy Eating" to "Zinc" and include such best sellers as "Young People With Cancer: A Handbook For Parents" and "Waste Treatment Technology News" to pick just a few samples.
It looks as if the subscription documents include mostly sources for which Northern Lights (and now Yahoo!) have minimal if any costs to provide.
Most results I found for some test searchs I did were from sites not included in the subsciption.
So, while the subsciption is a good deal if the sources you need access to are included, in practice I think most users will tend to find results that are not free.
Some, but not all of the sources that they charge for are also available elsewhere on the web for free (some magazines) - however this does require additional searchs - if you are doing research for work, the ease of access might well be worth the few dollars - particularly if the billing is handled in a smooth and simple fashion.
"What you don't seem to realize is that HCI studies are all a complete load of bollocks; HCI is the "social policy" of Computer Science. (Thinking in degree terms). "
Well... perhaps the studies that you describe - but in the course of researching the software my company is developing I have read a number of serious HCI research papers and dissertations. The really good researchers observe real users in their REAL environments.
This research then looks a many different environments, for example multiple large corporate environments as well as other large scale computer users such as government labs. In observing how different groups solve the same basic set of tasks using different software products the researchers can learn a great deal about the influence of user interface and other design decisions on actual real use, productivity, and effect (and well as effectiveness) of software packages.
From this research it seems generally accepted that around 80% of ALL users of ALL computer software do not change the defaults - so the defaults that a software company or corporation sets for the software they use or sell is critical.
For the one of the specific researchers I am speaking of look at her website at: Leysia Palen Home Page.
For perhaps the best researcher on presenting information, look at: The Work of Edward Tufte and Graphics Press
To relate a funny story along these lines - a friend of mine (admitedly one who was studying a rather obscure piece of early English writing) encountered a word in the book she was reading that she did not recognize.
So like the good scholar that she is, she turned to the library's copy of the OED.
And, to her amusement (and slight annoyance) the OED's only citation (and only definition) was the very work she was reading...
so - it does go to show that just citations may not always answer the question of just what the word means... (but then in this case perhaps no one really knows).
But you forget a few very very important facts.
Fact One - ALL products start off as "non-working" designs - and get evolved into what can actually work - on a TV show, film, novel, or short story perhaps more hand waving happens - but the process is not too disimilar to what "real" product develoment is.
Fact Two - There are very few items that we "can't" build today - particularly electronic devices the actual "working" parts and components have shrunk to nearly nothing - the designer of ALL of Nokia's cell phones was recently quoted in an article (see Business 2.0 Dec edition) as saying that now "Battery size vs. duration is no longer a design issue" - i.e. they can build it any size or shape they want.
Fact Three - Most inventions come about by someone taking an idea or concept, ignoring conventional wisdom that "it can't be done", and just setting off to do it.
So, as an inventor myself (developing very complex software products built on cutting edge AI research) - most of what I build could easily be seen as being "impossible" - it is my job to figure out what that is not so...
Also, think about all the technology that has been developed simply to fool us into to thinking that something works - i.e. the Special Effects industry, CGI graphics, etc.
Another place to look and consider - a bit off the beaten track - Dick Tracy - certainly inspired the cell phone concept to a degree, as well as the comics and radio dramas of the 1930s onward - perhaps no direct "inventions" but a lot of "impossible" ideas explored in ways that certainly inspired the "real" world creators of those items years later.
(see stuff like the actual working "rocket belt" used by Las Vegas special effects people - it really does work - and it was clearly inspired by comic books)
Very few inventors I have met were uninfluenced by the ideas of science fiction - from at least some medium (radio, tv, film, short stories, or novels). I often read novels and consider whether I could "actually" do any of the items suggested.
I am also an author myself - writing fiction and science fiction, indeed when I started my own company I went through an exercise of writing a "story" about how my technology could be used - this definitely is a part of how I think though the "story" of my company and our products - as a firm inventing something not yet in mass commercial use we have to be able to envision the impact and uses of our technology - and then tell the story well enough to make it true.
What is the sales process of any new technology but that of telling a story? If instead of telling the story completely on my own I could point to a TV show and say "thats what our firms' devices will be like..." it clearly helps (though it also could invalidate a patent...*grin*)
Shannon
Well this was a few years back, the early 1990's, I was supporting my college dorm's network, including the shared Apple Laserprinter at the front desk.
It was 2:00am on a cold early winter night when I was awoken by a phone call.
"Uhmm there's something wrong with the printer"
"What?" as I struggled to awake.
"Well for the past two hours its been printing the same pages over and over."
"I'll be right down."
Sure enough, it had been printing page one of some unfortunate student's final paper hundreds of times, though it had briefly alternated by printing hundreds of copies of page two.
After about an hour of futzing, and some swearing at the *#$#$#% print spooler software, I had the printer back online and working. In the process I deleted 7 print jobs that had been sent after the one corrupted print job that had been causing all the problems. In the course of my solution I had to disconnect and powerdown the print spooler and the printer and ensure that their memory caches were flushed.
With the printer fixed, I managed a few hours of sleep before my classes the next day.
And so the stoy remained for the rest of that week. But, seven days later, now comes the part that I can't explain.
I returned to the dorms after my classes that winter afternoon, nothing appeared out of the ordinary, but I stopped at the front desk to see how the printer was doing.
"Well we have these 7 printouts that no one has claimed"
Sure enough, seven days later the 7 print jobs I had deleted had been reprinted, the banner pages showing print dates from 7 days previously.
To this day I still can't explain it... ghosts in the machine sums it up best.
Well in Netscape 6.1 (haven't moved to the recently released 6.2 yet) it all appears to render correctly - and quickly.
Reload does not change anything.
So some bugs are fixed....
Very true.
Security is extremely tough to get right - if you are working on an insecure environment it is much harder to get right.
For a linux person - would you really want an application with every script and executable SUID to root?
Or would as a general rule of thumb it be better that the app is developed to be run as a user (not as root)?
Similarly Windows apps intended to be run by "regular" users in a corporate environment should be developed on a platform and as a non-admin user.
Either on Unix, Linux or Windows apps that run as administrator can easily have unforseen consquences ("hey we need to escape to a shell in this app.." guess what that means for SUID application....)
What I am referring to is NOT a "particularly severe" form of beaucracy - it is adhering to a policy that is designed to avoid unintentional (and intentional) problems that all the management in the world can't avoid.
If you have the ability to just "get in there and fix it" - you may or may not tell anyone that you did so - and you may not remember that you did it (or what exactly you had to do) when it comes time to building the application "for real".
The challenge of an organization is to put in place controls that are effective - they exist for very good reasons - if applications are being used by the business, but can not be recovered/rebuilt/patched because the developer who built them leaves - the entire company is at risk.
If you as a developer return to an application that you build 6 months ago to fix problems with it - you are setting yourself up for a nightmare potentially if your code is impacted by other changes to your applications, OS, or build tools in the 6 mths since.
In the company I am referring to the developer's themselves were the people making the decisions with regards to items such as "powerbuilder" vs. VB (using both for different purposes) - again though it was decisions made at the scale of the entire organization - just becuase you personally preferred a particular old version of FoxPro - that might not be the best tool for the organization as a whole to standardize on - and if you are the only developer in 1000 to know that tool - you are limiting your future at the firm as well (who really wants to only maintain an application they wrote 5 years ago - most developers prefer to be able to work on new applications as well)
If the developers have to wait for weeks to get their systems fixed the solution is also to make the development organization a much much higher priority than it appears to have been at your firm - management in general should be clear about who needs rapid responce - if developers who are highly paid can not work they should be put back to work quickly.
The point of the system I am describing was to make the development teams aware of each change they made to their systems - this was not intended to make change impossible - rather it was intended to make it just painful enough to remember to document and test the processs.
In the environment I am decsribing we also had systems in place to bounce back to the development teams their code if they were using pre-release/beta compilers or external libraries - this could easily result in delays to deploying their applications and all sorts of other nightmares (and more long days and nights for everyone) - there is a role for using beta/pre-release applications - but that role is not in supporting the business - it is reading the future development for upcoming changes - once stable then you can switch over.
While I agree that a test environment is important (indeed it was my role there) and that many of the issues can indeed be solved by good management, my fundemental is that in all environments casual Admin access is not a good thing - not due to whether or not the developers are "good" or not - it is simply due to how people opperate.
If you have certain rights on a machine - it is harder to catch when you are doing something that requires those specific rights (for example writing to a restricted directory) - it is not maliciousness or poor developers that do this - it is not using the security systems and structures correctly.
Further, I think you may misinterpert what I mean by "production" - while I am a strong Linux/Unix advocate for Internet systems (indeed I am Sun certified) - for corporate systems with very skilled developers NT systems serve important and indeed production roles. The NT developers at the company I am referring to were highly skilled COM developers building production financial trading floor applications which ran on WindowsNT workstations internal to the corporation - the NT systems and their workstations while not immune to problems - were when well managed and well run (which this firm did do - albiet at an extremely high cost) - they served a valuable role.
It was not a "production site" in the sense of a website - rather these are hardcore financial applications.
Also in terms of test sites and change management - there is a constant and ongoing battle between the business needs and "best practices" - when a change means the literally millions of dollers an hour - the process should be highly controlled but also highly efficient and rapid.
One means to ensure rapid migration from the development environment (perhaps through a test/build environment) to production is to keep the THREE environments in synch with each other. I.E this means ensuring that the developers are building using the same tools, patch levels, and build systems as the eventual test and production enviroments.
Since developers are not usually also people who want to admins - while they may know enough to install patches and new apps - they probably do not want to document every step and/or follow highly documented and tracked procedures - they want to get back to coding as quickly as possible - it is a compromise on both sides - I agree - but in a large scale corporate environment that is vital to keeping the entire system running smoothly (which translates in the long run to a more profitable company, stable jobs, and good pay.)
The company I worked for was NOT at all a nightmare of a place to work for - it was one of the best run (and highest paying) firms around - developers were engaged in very interesting, cutting edge development of very cool apps (one of the first Marimba application deployments for example) - generally there was a compromise with the developers which very much related to the stage of their application - as they approached releasing it to end users and as they supported released applications they had to endure a more restricted and locked down development environment.
To counter this the development teams themselves were the people within the organization who controlled the pursestrings for development application - and a committee of the technical leaders of the development groups set the corporate standards with regards to build tools, languages, application versions, and policies and procedures.
While there were still individual developers who might chafe at times - generally they saw the value to the overall process after it saved them significent time (and money) when it came to keeping their end users happy - being able to move a change from development to production when needed in a 24hr period to get trading centers back up and running - but still adhering to documented processes and tested environments was the proof of the pudding.
Something to consider about "locked down" vs. "developers with admin rights".
... not a good thing at all.
There are some extremely valid reasons to insist that developers have to take some pains to have admin rights to their NT machines.
1. Developers can easily "assume" admin rights when developing their software - and then blithely write software that requires write permission to an admin only area for example.
This could have easily resulted in a very expensive problem had I not caught this during building of the application for that development team at a very large (top 5 in world) finacial instituation I once worked at. Since the developers had admin rights they wrote a Java application that stored all config details in the Windows directory - very bad, but very subtle.
2. Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
When the time comes to build the applications they are developing this can result in subtle errors and problems - both in interim development builds between members of the same team (who have differently built NT workstations) and when the code moves from development to production - during which it would likely be built on "standard" build servers - the wrong set of patches to a compiler or different shared libraries and the resulting code will differ considerably.
Note further that such issues are not usually solved by standard source code administration practices (CVS, MS SourceSafe, ClearCase, MKS Source Itegrity etc) all of which usually do not track the installations, builds, and patches of the OS, compilors, and shared libraries.
3. Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production
Corporate development is a tradeoff between developers and the requirement of running the business - if you are developing on the fringes - or in a research lab environment that it is one thing, but when you are developing applications for the business's production environment (or to be shipped to clients or made available for sale) then rigorous and documented processes should be followed with regards to the machines that are used to develop and build the applications, if you don't you will eventually get burned.
I speak from the experience of working with over 1000 developers building and supporting over 650 internally written applications.
There is in fact an Internet Draft called Calendar Access Protocal (CAP). When completed CAP is designed to be a standardized means of accessing a calendar server.
More information can be found at the website for the Calendaring and Scheduling Working Group (www.calsch.org) which is responsible for CAP as well as RFC 2445 (iCal), 2446 (iTIP), and 2447 (iMIP).
I am very active in the working group and am helping edit the iCalendar RFC.
In dealing with my representative - while talking to him at a local town hall he noted that when his personal email address had been made public he recieved over 10,000 emails in ONE DAY! As a result he no longer checks that address (surprise surprise)
So, he recommended that I contact his local office manager here in town (who gave me his email address and contact information) - he could directly help me in many matters - and could relay my feedback the Representative in other cases.
When I get some free time (right...) I plan on offering to help provide technology information, feedback, and comments to the Representative - as the President and CEO of a software company based in his district I hope he will at least listen to what I have to offer - my goal is to offer technically well grounded information on options he may not know about.
One specific example being some suggestions about low-cost methods of providing high value training to local residents - our district includes the richest and poorest parts of Chicago - it is my view that initiatives that encouraged the use of Unix systems in job training and educational programs in the district would offer a very strong value to the students and for the government.
Anyway, more for Rep. Davis when I have more time.
As is often the case this sounds like people who only know a bit about the technology and options making very expensive suggestions.
A few alternatives to consider:
The government expanding the network already in place for the "Internet 2" initiative (high bandwith application testing) which currently exists between a network of universities, is already in place, and already has the fiber allocated and lit.
The government buying (or leasing in some form) some of the thousands of miles of dark fiber strung recently in the massive network infrastructure buildout.
Then, a second more practical and imporant suggestion. The government's goals are to ensure secure communication, ensure access to critical government data (not so much websites but FBI photo files, salelite imagary, even census data), and ensure critical command infrastructures.
Look at how non-goverment agencies accomplish very similar tasks - Banks use a web of network providers (usually at least two, often three) providing basic network connectivity to data centers; they often layer this with dedicated encryption (so that any traffic across public switched networks is encrypted); sometimes there are networks with-in networks (VPN tunnels etc); and there is extensive (and expensive) redundancy of all systems (and usually key people).
This redundancy would be rather expensive and difficult for most government agencies - but it is likely required. This includes physical as well as technical redundancy (i.e. serious data centers have power from multiple power grids entering the building at multiple locations; similarly they have data leaving the data center in multiple ways.
Now the good news - the government could probably pick up seriously redundant data centers, servers, networking equipment, fiber (dark or lit but already in the ground) for a very reduced price with the recent consolidation and collapse of hosting providers and network equipment vendors.
Rather than using this to build an entirely seperate network - if the government took the appropriate steps to secure and protect the system if could overlay the existing Internet without much difficulty.
(I would recommend of course that the government look at using the appropriate equipment for this job - i.e. secure and reliable OS's runing on physically secured machines)
Hope someone reads this and expands on my suggestions.
- some disclusures - I do not currently work for the government - my company is a software and consulting firm that may in the future do business with the government.
Don't forget that the Code Red and Nimba worms are spread by many vectors - which means that through email or web surfing they can penetrate into internal networks that are otherwise removed and cut off from the Internet as a whole. I imagine that many internal IIS servers at the government and at corporations were infected via web surfing from internal Windows clients.
The rumor about Akamai's co-founder appears to have been true - here is a link to their press release on the subject. Akamai Press release
Chess can be taught to anyone at almost any age - it does take patience to master - but it can be learned very easily.
I was taught Chess by my grandfather at age FOUR - one of the best legacies he could have ever given me.
Here in Chicago one of the great aspects of playing chess is that it is an activity that is open and available to anyone of any race, sex, or age - go to any of the public chess pavilions (actually this is true around the world for the most part) and you will find a group of people who would unlikely talk to each other in other circumstances playing a game for hours at a time.
I have seen traders from the board of trade playing homeless men - and often lossing.
There are hundreds of books and courses for how to teach chess - books and techniques tailored to any age - learning chess is a very powerful experience, it is fundementally a simple game - much simplier than most PC games - what makes it so difficult and so rewarding is how a very simple set of rules (7 types of pieces, two "special rules with pawns, one special move with King and rook, some special rules with one piece the king - that's really it) can create amazing complexity.
Books I would strongly recommend is anything by a Lasker (either Emanuel Lasker or Edward Lasker). Emanuel Lasker's books are on my short list of the most influential books I have EVER read - they teach a great about how to think - not just how to think about chess.
Both books teach chess backwards.
They start by teaching how to move the pieces, then how to win in the endgame with only a few pieces on the board, then common ideas/elements of the middlegame, and then and only then do they talk about the opening - and here rather than teach specific opening lines they concentrate on understanding WHY certain moves are made.
After understanding all this, not only do you play fairly decent chess, but you also begin to have a good feeling about how understanding something can help you make decisions, how small decisions can lead to bigger things in the end - all important lessons in life.
Play chess is also a great chance for students in any situation to get exposed to the world - they can play each other, over the computer they can play online against people of similar skill levels across the globe, they can even participate in tournements - either in person or online.
One of the joys of my life is the fact that in any city, nearly anywhere in the world, if I find a place where chess players meet, I can find a place where I can meet friendly people in that city - I have played chess all over the world - one of the best times being playing in the Luxumbourg gardens in Paris against an Englishman who lived in Paris - as an American tourist how else would you get to randomly meet people who live in that city.
So, I have to disagree with Garcia on the subject of chess - go ahead and teach your students chess - there are many great computer programs to help, and many great online resources for them to explore - it will give them a skill and an entre into a world that they might not otherwise enter.
Some real examples of this - through playing chess I have met millionaires, russian imigrants, hispanics, african americans, and many other people of as diverse a range of backgrounds, educational levels, and jobs as you could find. I have friends ranging from Business school professors, cab drivers, traders at the board of trade, city workers, to retired former "special assistants to Mayor Daley (Sr.) 75+ year old retires play 14 year teenagers. Through playing a common game we share a common passion (some would say madness) and over chess either in a public square, a local coffeeshop, or a local chess club we have a chance to meet, talk, and get to know each other.
This occurs in a manner very rare in American - your students would seem very likely to benefit from learning and playing chess.
Ask around - I suspect that there are local chess clubs, chess teachers, and probably even a grandmaster or two who would be very willing to help teach chess to your students - chess is a passion and most serious players love to share it.
Shannon
Acedemic studies have shown that 80% of people do not change ANY defaults to ANY software - whether this is a browser or a web server.
Scary isn't it.
Goes to show how important selecting secure and useful defaults is - something MS does a very bad job of.