Our reality is less interesting than the story I will tell.
Friday, October 23rd, 2009 | Nick Bugajski | No Comments
This talk from TED sums up exactly my hesitation on focusing on photo documenting my experiences. The fact of the matter is that you just aren’t there. You are a journalist, behind a camera, disengaged from the situation at hand.
Contrast that with a recent experience I had going on a family vacation. One person did 99% of the documenting of the entire 5 day trip, shooting video, taking pictures, not all the time, but enough to capture the feel of the trip. Nobody else did much of any documentation. This person published the definitive account of the trip in DVD form, and gave it out to everybody who was on the trip. Were we all better off in this situation? I think so.
As a side-note, the concept of crafting one’s identity reminds me of the media feedback loop described on FRONTLINE some years ago. Have we only made things worse since then? What would flickr or facebook look like if they didn’t encourage this kind of behavior?
Update:
Paul Carr from TechCrunch makes a similar point in a recent post.
Not Just The Defaults
Monday, April 27th, 2009 | Nick Bugajski | 1 Comment
Now that Rails 2.3 is out, I am looking forward to the Rails 3 changes, some of which are already starting to land on the development branch.
The biggest change coming is the work to decouple the various components from each other. This should allow, without great pains, swapping out of the various components that make up rails. Don’t like Prototype? Swap in jQuery. ActiveRecord causing too much pain? Try out Data Mapper.
My enthusiasm here is not necessarily that I need to change from these defaults, but more that I often find myself wanting to experiment with alternatives. Having to switch to an entirely new web application framework just to try out a new ORM library is not an effective use of my time. Most of my work on rails applications is constrained severely by time and I just do not have enough of it to justify spending many hours trying to get productive in a new framework just to see if one part of it has better characteristics for my needs.
I still like my framework opinionated, but if I can get that and have the ability to choose alternatives to the defaults, well count me in.
Improving with Age
Thursday, April 2nd, 2009 | Nick Bugajski | No Comments
When I design an application, one of the easier traps to fall into, is the idea that there is only one consumer of the database. This is the luxury of building a brand new web application that has no legacy integration requirements! But, it is a false promise, because it only lasts for a short period of time. Even if you never integrate with another application, the application itself becomes a “legacy” component. Eventually, there will develop a mismatch between the database and the application.
The database is something that needs to be refactored over time, just like the application. The job of a data service is to provide the view of the data that the application requires. If the applications requirements change, then so to should the database change.
With Ruby on Rails applications, I think developers are not strongly encouraged enough to think about the database this way. That almost certainly is a result of the creator’s opinion that a database is nothing more than a glorified hash map. The result is that a lot of the busy work of maintaining data is pushed into the application, increasing the cost of changing the schema. In particular you can look at the lack of support for database views. While they are treated as tables in the application, there is nothing that marks them as being views. That results in testing them being a little strange as you are forced to write fixtures for views when they should be calculated from other fixtures.
I hope I have time in the future to help improve that part of Rails, because I think working on those types of issues will bring about another round of “surplus” to the community. And this surplus will come for groups that might otherwise be tempted to scrap an application and start over, making the advantage even greater than the alternative.
The Data Model That Nearly Killed Me
Tuesday, March 17th, 2009 | Joe Bugajski | 76 Comments
On February 17, 2009, President Barack Obama signed into law the economic stimulus package that appropriated about $20 billion for heath information technology (”Technology Gets a Piece of Stimulus“, New York Times, January 25, 2009. The American Recovery and Reinvestment Act of 2009, Subtitle A—Promotion of Health Information Technology, details the epically massive government program to digitize and network health information.) The law makes a job for yet another bureaucrat to oversee the vast program – is this change we can believe in? It defines rules for health information standards by designating a new standards board – everyone desires more data standards and standards groups. The law also explains how to test systems built with federal money but it does not explain how to measure semantic validity of information – garbage in garbage out! Good luck with all of that Mr. President.
During the last week of January 2009 a faulty electronic, networked, health information data model nearly killed me despite its vaunted status as a component of two state-of-the-art, health information systems at two of the world’s most advanced medical facilities. This will come as no surprise to healthcare IT experts because health information is inherently complex, medical science develops extraordinarily rapidly, patient interactions are intensely personal, and the number of data types and sheer volumes of healthcare data explode prodigiously with new tests, instruments, and treatments. (Prof. Anne Armstrong-Coben, M.D., entitled, “The Computer Will See You Now“, New York Times, March 5, 2009 describes one physicians concerns about computerized medicine.)
While President Obama’s vision of a national health information network appeals to many politicos and pundits, that vision may prove more fantastic than practical given the complexities involved in designing, developing, implementing, and maintaining such a complicated network, together with new inventions required for data models and software architecture. (The National Institutes of Health [NIH] investigated the issues surrounding a National Health Information Network [NHIN]. See the NIH report, “Summary of Nationwide Health Information Network [HNIN] Request for Information Responses“, June 2005.) My near-death experience at one of the best tertiary medical centers in the world, with modern electronic health information systems, illuminates the chasm between the President’s NHIN vision and its reality.
Treatment Saga
My ordeal began on Sunday January 25, 2009. I returned from church, ate breakfast, and sat in my favorite chair to read the paper. Within an hour, my lungs were causing so much pain that I had to lie down. Two hours – a 104 degree fever, a not-working-so-well emergency asthma treatment regimen, and a tortured conversation with my then very concerned allergist – later, and I was on my way to urgent care. My wife reluctantly agreed to drive me to the clinic attached to my allergist’s office rather than a closer-by clinic, because, I entreated, the farther-away, attached clinic would enter the attending doctor’s report and any test results into my electronic health record for my allergist to review on Monday morning. (OK – low blood oxygen was messing with my brain but it seemed a good idea.) Thus, day one of a near death experience began.
Urgent Care
The nurse who escorts me into urgent care asks me for my doctor’s name. I tell her my allergist’s name. The nurse argues that she wants to know the name of my primary care physician. Of course, that information is in my electronic medical record that she can readily access. The nurse next requests me to relate my medical history – which information is available in the electronic record. Next, an attending physician asks for my doctor’s name, no, not my allergist, my internist, and please relate my medical history. Never mind that (a) I provided this information to the nurse only moments ago, (b) I can barely breath, (c) I have horrible pain in my lungs, (d) I have a high fever, and (e) the requested data already is in my electronic health record. Perhaps, I think, these professionals must verify my data – regardless of whether or not my brain wants more oxygen. I explain to the nurse and doctor that my allergist (who is a specialist in allergy and immunology, and who also has a Ph.D. in pulmonary medicine) wanted me to receive certain treatments. The attending physician at urgent care says that I may have pneumonia. I say that I also have severe asthma. She smiles politely and walks away.
By-and-by the attending physician requests an X-ray and blood test. I ask for pain relief medication (the correct prescription is in my electronic health record). The doctor prescribes two Tylenol tablets that did nothing for the pain. Hours go by. The X-ray shows no pneumonia, says a radiologist. The attending doctor orders an intravenous antibiotic to help me deal with the infection, and asks if I feel better. I say, no, not really. Do I want a breathing treatment? Yes, that would be good. I am sent home.
During my visit to urgent care, starting about 1pm and continuing until 7pm, my respiration rate was double to triple its normal rate. My lungs are bags of pain that trap CO2. I have a high fever. I want to die. Despite the existence of a well maintained, electronic health information network, I am not treated for asthma aggravated by a lung infection as my medical history clearly and unambiguously indicates I should have been.
Doctor’s Office
I cannot sleep during the night following the visit to urgent care. I am unable to breathe without intense pain. My respiration rate remains much higher than normal. But, my fever broke. First thing in the morning, I call my allergist’s office. My allergist’s nurse returns my call around 2pm. She says the doctor wants to see me at 4:30pm. He believes that I am still in serious trouble. My wife collects my medications (bless her, because these would keep me alive later) and drives me to my doctor’s office.
My allergist and his nurse do not take my medical history. I lie on a gurney in an examination room where I am hooked to monitors and given supplemental oxygen. My doctor listens to my lungs as I labor and cough my way through a few breaths. He observes my respiration rate. He waits awhile. He repeats these observations thrice. Around 5:30pm, my allergist says that I am too sick and must be admitted to hospital for continuous observation. I object. He replies that I may die if I go home. His nurse calls for an ambulance (no, my wife cannot drive me 1.5 miles to the hospital – the doctor said this would be too dangerous).
90 minutes pass before the ambulance arrives. My allergist spends the intervening time preparing a four page memorandum giving my medical history, my current condition, and a treatment plan. He also telephones the admitting physician at the emergency room (ER) where I am to be taken to discuss the medical issues. My allergist then entrusts this information to the ambulance attendant.
ER and ICU
Once in the ambulance, the attendant asks me to give medical history, allergies, and medications. This information he enters into a multipart form. When we arrive in ER at the medical center affiliated with a world renowned university, I am called “asthma” by someone behind a desk who tells the ambulance attendant to park me in a hallway. The attendant delivers his report, oral, and written, to the triage nurse who by then is examining me. The attendant tells the triage nurse that he brought a written report from my physician for the admitting doctor to read. The nurse instructs the attendant to deliver his reports to a person behind a nearby desk. She said it will be put into my chart.
I was in ER for 20 hours before being admitted to the intensive care unit (ICU) where I spent another 28 hours. Throughout my stay, I was hooked to network attached monitors that incessantly sounded alarms to which no one responded. I was asked 11 times to repeat my medical history, medication, and allergies to as many different medical professionals. I was seen by seven doctors each of whom asked me similar questions. Five doctors were never to be seen again. All doctors mumbled something about putting their findings into the hospital’s electronic records system – most did not according to ICU nurses. No one read my allergist’s detailed report about my condition and health history.
As I moved from ER, to an ER holding room for admitted patients, back to ER, and to and fro other departments for tests, and finally to ICU, I was visited by nurses and technicians who pushed laptops mounted on wheeled sticks. They checked my vitals; asked me questions about my history, medications, and allergies; and entered findings into the hospital’s electronic medical record using the laptops mounted on wheeled sticks.
I asked every nurse and doctor who met me, and I was told that I would receive medication to relieve the intense pain from my lungs. Each claimed they would note this in my electronic medical record. No one did until about 14 hours later, during the middle of the night, when one thoughtful ER nurse finally found a doctor to authorize giving me the oft approved but never delivered pain relief medication.
No one in ER or ICU knew, nor could they find, my allergist’s memorandum describing my medical history, current medications, and treatment plan. My wife eventually called the allergist’s to obtain a fax copy for ICU. No one ever mentioned reading the fax copy although an ICU nurse confirmed its receipt. The list of persons who denied knowledge of the memorandum included the on-site doctor who represented the same clinic as my allergist. That person could view my electronic health records on-line from the hospital but she ignored this rich source of vital information about my condition preferring instead to come to (an unbiased?) conclusion.
One heroic medical professional, the first nurse I met in ICU, worked to create a consistent record of my condition, allergies, and medications in the hospital’s electronic health information system. She spent over one hour searching for previously entered data, correcting errors, and moving or reentering data. She argued with one doctor whose concurrent access to the hospital’s system blocked my nurse’s access to my information. She called the hospital’s pharmacy repeatedly to get my medications delivered. She met and called doctors several times. She even convinced one doctor and a pharmacist to come to my room to resolve data errors in person. Despite these heroic efforts, I never received correct medications during my stay. Indeed, my wife snuck one of my inhalers into my room. After I used it, I finally began to recover.
At one point during my battle with illness and electronic healthcare data, the only asthma medication that had kept me alive began to wear-off. I knew that if I did not receive the right dose within an hour or so, my condition would deteriorate rapidly and I would die. This critical information I had repeated 9 times to doctors and nurses who recorded it in my electronic health record. They promised that I would receive the medicine when it was time. That time came and went. My lungs began to scream with pain. My respiration rate accelerated. My breathing became more labored. I was crashing. I begged the doctor who next stopped to check my condition for her help. She said she would authorize the prescription. The heroic ICU nurse stopped by my room, checked my electronic records, but she could not find the prescription. She then ran to find a doctor to authorize my medicine. She succeeded. I received the medicine. I lived.
Figure 1: Asthma-Pneumonia Episode Chronology
During the time I was hospitalized, I forced myself to remain coherent so that I could correct errors whenever medical professionals provided “prescribed medications” or they came to run tests (Figure 1 illustrates my experience). I twice received food to which I was allergic, both times after a doctor “recorded” a list of my food allergies.
Needless to say, I was exhausted from labored breathing, a lung infection, pain, tests, effort expended to correct data model errors, energy wasted giving my medical history, and lack of sleep. Several times I stopped fighting. I relaxed. I was able thereby to slow respiration to my normal rate. This made my blood O2 saturation rate drop precipitously which in turn triggered monitor alarms – to which no one responded. (I learned later from a nurse’s assistant, that alarms always sounded in ER and ICU so no one paid attention to them.)
I finally understood the problem everyone was having when the heroic ICU nurse explained what she was doing while working with the hospital’s electronic health records system. It explained why so many caring, competent, knowledgeable, and talented medical professionals behaved so strangely when interacting with patients. It was because they were fighting a horrible data model. It was that data model that nearly killed me.
Electronic Health Information Systems
Medical personnel at urgent care and the hospital who interacted with me all used a version of the same electronic health information system (the “system”). It became clear that everyone was fighting that system. Indeed, they wasted between 40% and 60% of their time making the system do something useful for them. The system kept everyone from fulfilling their duties – the health information system did not help medical professionals perform their duties.
Since my hospital stay, I confirmed that electronic health information systems are mostly broken. I interviewed medical professionals, healthcare IT experts, and my allergist. They confirmed my sickbed analysis. Indeed, several experts said that they longed for handwritten charts once more hanging from the foot of every patient’s bed. (Again, please read Prof. Dr. Armstrong-Coben’s Op-Ed article.) My analysis argues for careful analysis of strengths, weaknesses, opportunities, and threats (SWOT) associated with building a national health information network. If the nation simply accepts the President’s vision while healthcare IT vendors collect some of the $20 billion stimulus bounty, individuals and businesses will pay higher medical costs, patients will receive inferior care, and medical professionals will lose precious time fighting IT systems instead of delivering better care.
Killer Data Model
Poor data model design deters medical professionals from delivering quality care. Conceptual data models capture information requirements from medical practitioners’ perspectives but IT professionals only vaguely understand medicine (see, Scot M. Silverstein, M.D., “Essential Value of Medical Informatics Expertise in High-Risk Areas: an Invasive Cardiology Example“, Drexel University, 2007). Logical data models express information requirements from a technical design perspective (e.g., schema for relational database management system [RDBMS], schema for extensible mark-up language [XML] documents, or formats for health insurance claims [a message model]). Logical data models fail if conceptual models are wrong, if errors occur in transformation of the conceptual model into the logical model (forward engineering), or if logical design is faulty (see Shahid N. Shah’s post, “Repeat after me: healthcare data models matter“. (For more information about data models and data modeling, see Joe Maguire’s paper, Burton Group, Data Management Strategies, “Mind Your Business: Serving Business with Data Models that Focus Exclusively on Data“.)
The root of the problem I experienced with health information systems is a very bad data model. Evidence supporting my claim includes these observations:
- Incoherent database design isolates patient information from one department to the next and from one organization to the next. This wastes time and increases errors because medical personnel must enter patient information into a unique view of the system that corresponded to user identity and department – this prevents one medical professional from seeing patient information input by another medical professional.
- Patient information is easily lost inside the electronic records system
- Hard copy patient information becomes dissociated with the electronic record
- A healthcare professional’s work pattern is not reflected in either the system design or data model – people spent considerable time searching and data reentry
- No master data management (MDM) in evidence – Production of a consistent record of me as a patient required the ICU nurse to copy data from multiple database views into the in-patient record
- Admitted in-patient records are treated differently by the system than out-patient or ER record only patients – no information about my medical history gathered during a prior visit to ER was available to my doctors or nurses.
- Nurses and doctors do not have ready access to listings of pharmaceuticals which wasted much time while they searched for information about my daily medications – lists of medications in the system are limited to those at the hospital pharmacy.
- No support existed for recording allergies differently than to ambient source and foods – Lists of allergies were not in drop down menus although these are well known by allergists and drug companies.
The root cause of these problems is the failure by information technology (IT) system architects to correctly capture business requirements. There also is evidence that no one ever produced a reliable conceptual data model. The problem commonly occurs. Too often, system architects simply gather lists of requirements then they ask their favorite vendors to quote a product. This is non-architecture and system non-design. Rarely do architects request information architecture.
Fault also rests with independent software vendors (ISVs) whose products fail to support end- user requirements – real doctors, nurses, technicians, and pharmacists. Rather they build products to a marketer’s or a developer’s best guess about end-users’ requirements. It is easier to rush a product to market that “looks good” to IT people but horrifies end-users. This seems to have been the case with the electronic health information system used by the clinic and hospital that treated me.
Another common problem is that useful conceptual data modeling tools do not exist. This broad challenge to the industry makes the best data modeler’s task more difficult as they work to create conceptual models then validate those models with end-users. Without good tools, information architects and data modelers often use technical elements to represent business concepts. This leads to problems with forward engineering because healthcare (business) concepts are mixed with data design technology artifacts. (See the article by T. J. Eggebraaten, et al, “A health-care data model based on the HL7 Reference Information Model“; IBM Systems Journal, Vol-46, No.1 2007.)
IT information security professionals in the medical industry appear to be reluctant to deploy document authentication and encryption for users. Many commercial health information systems can produce Adobe Acrobat versions of doctor’s reports. These reports could be authenticated using Adobe technology and transmitted to another physician using email encryption programs. The patient might even certify such transmission of their information using electronic systems. This simple practice might have enabled admitting doctors to see my allergist’s memorandum in their in-box instead of requiring paper copies to pass from one person to the next.
Clearly, the most important problem is the lack of a consistent data model across departments and providers. This wastes time and increases error rates.
Unreliable Information
Poorly articulated data models engender disbelief in system data among end-users who see data inconsistencies in competing entries about a person, their symptoms, their illnesses, and data entered by different physicians and nurses who cared for the patient. This problem was amply evidenced by 11 full histories taken by every medical professional who checked my condition.
If externally generated information history is difficult to integrate, particularly if that information is not in the form used most frequently by medical professionals in the receiving organization then there is a propensity to misplace that information. Witness the lost memorandum from my allergist. That document was misplaced shortly after its confirmed delivery to ER. Its loss dramatically reduced the quality and effectiveness of my care.
Other problems arise when doctors can arbitrarily block nurses or other doctors from completing data entry tasks. Such issues delayed provision of medications appropriate to treating my ailment (e.g., pain relief medication). Because information was not shared between departments or between the hospital and the clinic, each doctor felt obliged to build a diagnosis and each nurse had to gather my data anew.
Bad Systems
Clearly, the networked monitors with alarms sounding so frequently no one believed they meant anything is a serious design problem. Operating inconsistencies among systems and apparatus that increases the rate of false positive alarms leads to errors in patient care management, some of which are possibly fatal.
Clearly there was no attempt by IT to provide a proper event driven messaging technology to deliver data and manage workflow for doctors and nurses who need to review this information. Too much time was lost in tracing test results and gathering information about medications that used as much as 50% of staffs’ available time and dramatically increased error rates that lower patient care quality.
Recommendations
A national health information network, while a laudable vision, will require massive data integration engineering at a scale never before undertaken by the IT industry. (For challenges surrounding data integration, see the Burton Group, Data Management Strategies overview, written by me entitled, “Data Integration: Fantasies and Facts“.)
The only way to achieve the President’s vision reliably will require narrowing the scope of work to a demonstrable and doable task that executes in finite time. Mr. President, don’t be fooled by IT vendors telling (false) tales of munificent and magnificent skills with their heath information system development. Rather, ask them to depart immediately. Instead call upon our nation’s best system and data architects to report for duty. Send these people to meet with doctors, nurses, test technicians, pharmacists, hospital, and clinic administrators. Have them learn what practicing medicine really means. Tell them to do these things:
- Build a business (medical information system) requirements model.
- Create conceptual data model and information architecture.
- Validate these models in a public forum like those used by open standards organizations (e.g., OASIS, OMG, W3C, and others).
- After the models are validated, the architects can create formal requests for information (RFIs) for vendors.
- Heath information technology vendors can respond to the RFI to see whose system matches those requirements.
- Seek hospital and clinic volunteers to trial the new systems.
- Find the best matches to requirements and submit to the winning vendors a request for proposal (RFP) to build and install the first systems at the volunteer’s facilities.
- Narrow down the list of vendors and send them a request for quote (RFP) to decide who will win the initial integration trial between two medical institutions and between two departments in each of those institutions.
- Establish success criteria and measure vendors’ achievements relative to that target not one of their making.
- Be sure the vendors work for the volunteers and not for the government. We need a health information system that meets their unique needs.
- Integrate the systems. Pay the winning vendors a bonus for early completion.
Conclusion
The national health information network envisioned by President Barak Obama is a pipedream. That is, unless and until information technology (IT) professionals learn how to build systems and data models that meet end-user requirements (read, useful to medical professionals). My recent experience with an urgent care clinic and a major tertiary care hospital convinced me that the United States will require a long time before there is a consistent data model capable of recording a patient’s health information, let alone a data model capable of accurately and reliably transmitting that information from one healthcare institution to another. Much of the groundwork required to achieve the vision needs to be done. The $20 billion allocated by the American Recovery and Reinvestment Act for a health information network will be squandered by IT vendors and hospital administrators long before the nation has a viable network unless and until the administration acts rationally to establish a program of development that is free of vendor and administrative greed. Take it from a guy who recently found breathing very difficult, do not hold your breath waiting for a national health information network to appear.
__________________________________
- Conceptual data models would describe the information that an ICU nurse requires to fulfill his responsibilities, or that an ER attending physician must have and must obtain to treat her patients. The same is similarly true for radiology, cardiology, oncology, psychiatry, admissions, billing, pharmacy, and many others.
- Health Level 7 (HL7) is an open standards group chartered by the American National Standards Institute (ANSI) to develop health information standards. One such standard is the HL7 Reference Information Model (RIM), a conceptual data model for health care data.
The State of Things
Sunday, October 5th, 2008 | Nick Bugajski | No Comments
I know I’ve made a mistake in the design of a REST style application if it can’t handle the same user logging on from two places at the same time. It is easy to assume that there is no good reason for a user to do such a thing and therefore dismiss the hard work of fixing any related problems. But that problem is just a good way to test how your application behaves over an unreliable network (heretofore called “The Web”). Just as easy as ignoring that mean user with his two simultaneous sessions, is ignoring the fact that The Web is unreliable. Any good web application design should account for that. The problems associated with this problem mostly have to do with separation of application state from resource state.
As an example consider a blog where users must be logged in to comment. In this system there is a create comment page. This page adds the comment, when submitted, to the article that the user was viewing before he went to the create comment page.
If application state was managed on the server, there might be a variable stored in the user account that identifies the post that that user last viewed. This variable would be referenced when the user submits a comment, with the comment being added to whichever article that variable contains.
Now, how can that go wrong? Say a user, let’s call him Steve, logs in to the blog. Steve reads an article that he would like to comment on, so Steve goes to the create comment page. While composing his comment, Steve remembers another post that was related that he would like to quote. So Steve opens a new tab and navigates to that post. Steve then goes back to the tab with the comment form, finishes it and clicks the submit button.
In this scenario, the comment, since it relied on the server side variable to determine which article the comment was for, would end up on the second article, the one Steve was viewing in the second tab, because that was the last viewed article, not the one he was actually trying to comment on.
In a better design, the article that a comment was meant for would be manged on the client side, it being application state, possibly as an item in the comment form.
Obviously this is a simple example, but generally the ways in which this problem arise can be reduced to such a simple scenario. They generally involve many more steps and much more complicated interactions, but they all involve requiring the server to know the current state of the client.
See also: State in Web application design
The Hypertext Constraint
Friday, September 5th, 2008 | Nick Bugajski | No Comments
I have spent quite a bit of time recently designing a system in the REST style. Two main observations from that process:
- Web search is still pretty terrible once you need something more than a company’s homepage or a wikipedia entry. There is a vast wealth of information dispensed by experts everyday in venues that don’t attract large numbers of links. Finding that information is way more painful that it needs to be.
- 99% of people writing about the REST style seem to have totally missed the most important constraint: Hypermedia as the engine of application state (HATEOAS). If that concept was better understood by more people we might finally make some progress on things other than how to make pretty URLs. It took a significant amount of time to discover just how important that constraint is for the REST style (very, by the way, like, it’s everything, no HATEOAS, no REST, not even close), and that really slowed down the design process for me.
Here is some HATEOAS link love so as to do my part to improve the state of knowledge on REST in those link counting search engines
Minister of Information
Wednesday, June 20th, 2007 | Justin Bugajski | No Comments
New York Magazine has a good profile of Dr. Edward Tufte. If you are not familiar with his work, you should be. Dr. Tufte is an expert and pioneer in the field of visual communication of information and this is a nice introduction to read before you buy your copies of his fantastic books.
He keeps going on the road, selling steadily, a few gigs a month, year after year. That may be why there are 1.4 million copies of his titles in print—a staggering figure for self-publishing. (The top seller, The Visual Display of Quantitative Information, has been a reliable mover since 1983.) And at these six-and-a-half-hour presentations, the audience starts cheering when he hits the floor, clamors for their books to be signed, buys posters at the table out front. As soon as the applause stops, Tufte bolts backstage, enthusiastically draining a Corona.
Don’t Forget About The Bots!
Tuesday, May 15th, 2007 | Nick Bugajski | No Comments
It is occasionally necessary for us to take down one of our customer web sites in order to perform maintenance tasks. Most of the time this doesn’t last more than a few minutes, but if things go wrong, it could take much more than that. These days we use Capistrano for deployment, which has built in functionality to help easily disable a web site (disable_web). That provides reasonable feedback to users coming to the site, so they know what is happening. What it doesn’t cover are the machines accessing the site. Chances are those programs can’t tell that the site is down from the maintenance page.
Turns out that this problem was easy to fix, all that was needed was to get the web server to return the correct HTTP status code. As it was, it was returning code 200: “OK”, when the more appropriate code would be a 503: “Service Temporarily Unavailable.”
All our customer sites run with an Apache server sitting in front of the Rails sites. This allowed us to make the maintenance page a script rather than just a static HTML page.
- To start, we implemented the custom maintenance pages described by Mike Clark.
- Next we replaced the HTML version of the maintenance page with a PHP page.
- And last was to add in a couple of custom headers into the PHP page so that it returned the correct information.
<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Retry-After: 300");
?>
We included a Retry-After header of 5 minutes, assuming that the site will probably be back up soon.
And that’s it, a couple of changes and now our sites speak proper HTTP even when disabled, great!
Agriculture Department Exposes SSNs
Friday, April 20th, 2007 | Justin Bugajski | No Comments
Came across an article in the New York Times describing the latest occurrence in the growing trend of private consumer information being inadvertently or purposely exposed on the internet. Now, due to obvious concerns about identity theft, millions of government dollars will have to be spent to monitor all these folks’ credit reports. Even worse than that though, is how many places this database has been copied which are completely outside of the agency’s control.
The Agriculture Department said that its review of the database shows that between 100,000 and 150,000 people could be at risk.
Privacy advocates say the actions by the agencies may not be enough. The database is more than two decades old, and is used by many federal and state agencies, by researchers, by journalists and by other private citizens to track government spending. Thousands of copies of the database exist.
Information Rich Web Design
Saturday, April 14th, 2007 | Justin Bugajski | No Comments
Dr. Tufte has posted on his blog a letter he wrote to the Executive Editor of the Washington Post, following their site’s recent redesign. In short, he delivers the Editor the following excellent instructions to be handed off to their web designer:
Make our webpage straightforward, and if possible elegant–and, no matter what, increase the amount of news available within the immediate eyespan of the viewer on the homepage. We want more of what we do well immediately visible. People come to our website for the news, not for the interface.
Edward Tufte
March 29 2007
Sage advice any site designer should heed. Click over to Dr. Tufte’s site to join in the discussion about the Post’s redesign.