Monday, December 7, 2009
Monday, November 23, 2009
This could easily be extended to include other iconography standards.
Saturday, November 14, 2009
We have created a proof of concept here using XAMPP and AWS:
Saturday, November 7, 2009
Urban EcoMap San Francisco is a great site that lets you explore emissions by zip code on a color-coded map:
Sadly, however, the link it not accessible!
Where is the URL for this data? It's hidden behind a Flash control.
Sunday, October 25, 2009
You can query for all crimes going back to January 1, 2006 (why only that far back?) up to the present day. But you can look at exactly 15 results at a time.
Shortcomings notwithstanding, here's what Pilot reporters can do right now for free:
Compile and publish Google spreadsheets with charts:
Wow, who knew that
72% of all crime in Virginia Beach> occurs at the Oceanfront?
Update: HUGE, HUGE ERROR in my reporting of this stat. The pie chart above does not show all crime in Virginia Beach. It shows only the top 5 neighborhoods.
This chart, below, is the correct chart. It shows that, while still a standout piece of the pie, 4% of all crime happens at the Oceanfront.
I'm feeling really dense right now, but in a way I'm glad this happened. This is a perfect illustration of a fundamental in data viz (and reporting).
Saturday, October 10, 2009
- Publish events in iCal format
- Publish electronic police reports as XML
- Publish 311 data (as XML)
- Geocode public works projects
- Implement short, guessable URLs
- Use a free mapping service
- Update the Transportation Data Management System
- Add a "Web-Friendly" link next to "Printer-Friendly"
- Create a data catalog
- Get a .gov address
Wednesday, September 30, 2009
There has been some criticism that Gov 2.0 is:
- Just another buzz word
- Just people talking about stuff, no one doing stuff
- Brian Sobel, InnovationGeo, Are You Safe, iLive.at
- Dmitry Kachaev, D.C. OCTO R&D
- Philip Ashlock, Open Planning Project, Open 311
- Josh Tauberer, GovTrack.us
- Jim Gilliam, act.ly, GovLuv.org, TweetProgress.us, WhiteHouse2.org, and NationBuilder.com
- Andrew Turner, GeoCommons, FortiusOne
- Everyone at Sunlight Labs
- Carl Malamud, public.resource.org
- Jen Pahlka, Code for America
- Leonard Lin, Code for America
- Steve Ressler, GovLoop
- Noel Hidalgo, New York State Office of the CIO
- Raymond Yee, UC Berkeley
- Peter Corbett, iStrategy Labs, Apps for Democracy
- Kevin Merritt, Socrata.com
- Hillary Hartley, NICUSA, Citizen Space
- Guy Martin, Forge.mil
- Silona Bonewald, League of Technical Voters, citability.org
- Kevin Connor, LittleSis.org
- Greg Elin, United Cerebral Palsy
- Noel Dickover, DoD Office of the CIO, DoDTechipedia.mil
- Jon Udell, Microsoft, ElmCity
- Kim Patrick Kobza, Neighborhood America
- Jay Nath, City of San Francisco
- Wayne Moses Burke, Open Forum Foundation
- Micah Sifry, Personal Democracy Forum
- George Thomas, GSA
- Alan Silberberg, You2Gov.org
- Steve Lunceford, GovTwit.com
- Joseph Porcelli, Neighbors for Neighbors
- Luke Fretwell, GovFresh
- Chris Rasmussen, Intellipedia, NGO
- Pam Broviak, MuniGov 2.0
- Bill Greeves, MuniGov 2.0, Roanoke County, VA
- Jeff Levy, EPA Web Manager, Federal Web Managers Council
- Adrian Holovaty, Everyblock, chicagocrime.org
Thursday, August 27, 2009
Tuesday, August 25, 2009
Friday, August 14, 2009
Wednesday, July 29, 2009
Friday, June 12, 2009
This is a re-post from a journal entry I originally wrote over on Slashdot in 2004. I've made some minor changes and updates for this entry.
Lessons on how to train a junior programmer:
Let's call him Danielsan.
Mr. Miyagi was a very wise and clever sensei. His methodology, loosely translated, is perfect for any small software company that is bringing new developers into the system. The reason Mr. Miyagi's method works so well is because it provides intense, immersive exposure to the most important lessons while demanding relatively few additional resources from the instructor(s). Think about it. While Danielsan was busy painting the fence and sanding the deck, Mr. Miyagi was out having the time of his life!
The length of each lesson is to be determined on a case by case basis.
Lesson 1: Write SDK Documentation
Even the best developers can be notorious for not adequately commenting their code. Good documentation of an software includes both programmer's notes and comments for automated documentation (e.g., doxygen). This oft neglected task is perfect for Danielsan. An excellent way for him to learn the software from a developer's perspective is to write the documentation that explains how it all works.
Listen carefully when Danielsan asks questions about the existing code base. Discourage him from asking too many questions, except regarding complex concepts. It is important that Danielsan develop his own understanding of algorithms, relationships, dependencies, etc.
Lesson 2: Build Company Demos
Documenting the code shows Danielsan how the software developer sees things. Danielsan also needs to see the software from users' perspectives. "Users" include programmers who develop applications from the software and end users of the applications that are developed. Ideally, these would be two separate lessons. Knowing that time and money are always issues, these lessons can be condensed into one by having Danielsan build the company demos.
Architects and senior engineers loathe building company demos. While they are often happy to write test apps for in-house use, company demos bring with them a mountain of maintenance headaches and customer support issues. Whether or not your company is big enough to have it's own department(s) for maintenance and support, it's worth putting Danielsan to work on company demos so he can get his hands a little dirty and see first hand the challenges facing maintenance and support team(s).
Lesson 3: Clean House
Many companies have coding standards that must be followed by all code writers. These standards help everyone to write clean, consistent code that everyone can understand. Unless you work at a sterlized laboratory, it's a safe bet that your house always needs cleaning. A great way for Danielsan to learn this important lesson and also develop habits that are consistent with the team is to set him to work checking for adherence to company coding standards, leaks, potential security issues and the like. It's also a convenient way for you to get your code checked by a fresh pair of eyes.
The Successful Sensei
The successful sensei will know that these lessons are not opportunities for him to relax his own standards or to set Danielsan to work unguided. The successful sensei practices what he preaches. He knows which lessons Danielson must learn on his own and which require guidance. Naturally, Danielsan may occasionally bemoan his instruction. Perhaps he will consider that his training is too rote or mundane. Since you can't just throw a bunch of karate maneuvers in his face to show him what he's learned, it's important to sometimes let Danielsan work on things he finds interesting and fun. Ask him to write stand-alone utility apps that your company might need. Give Danielsan isolated new tasks within the SDK, perhaps something that requires he work with others to design interface requirements, resource requirements, etc.
to be cont'd.
Axiom 1: Tooltips are better left on.
If you leave your tooltips on, chances are better that you will learn something new each time you use your application(s). For Danielsan, tooltips are especially useful when they instruct him about fundamental principles of programming, those that transcend applications.
Axiom 1a: Some tooltips are better than others.
Monday, May 18, 2009
I want visualization to be less a part of a specific application that I go to and to be more of a natural extension to the computer itself, available from everywhere. I want visualization to an ambient experience. When I encounter any table of data in any document container I'd like to be able to quickly view it as a column chart without starting up a chart-making or data processing application, without shuffling around through copy & paste. I just want to select rows and columns an pop a "window" with a chart in it in one easy step. If I can recognize with my eyes that a table contains place names or lat/lon pairs then a computer ought to be able to map it with minimal intervention on the part of the user. I should also be able to put my selected, obviously geospatial data on a virtual Earth model. With just a little more imagination I can see turning lists and tables into nodes and edges, viewable with graph layouts. Think Enso for visualization. I might want to do more than just look at my chart, map/Earth model, and graph. I might want to start to interact with these views (assume independently for now). It starts to seem like I need an application to do that, but I'm not ready to jump the gun. This is still in the realm of a capability and not necessarily an application. Applications start to assume containers and domain-specific use cases. Most visualization techniques have standard, "off-the-shelf" things you can do with them given basic commands or input devices. Charts can be sorted and transformed into different layouts. One can pan, zoom, and rotate maps and terrain. The technique of "drill-down" and "roll-up", which can be applied to any visualization technique, is nothing more than navigation of linked data at multiple levels of detail and sometimes across multiple view contexts. At what point do is a specialized application needed more than a capability? We may be overly conditioned to assume the application model when we think of software as having utility. This is changing rapidly on the web. (It was always thus on the Unix command line, yes?) Visualization ought to change with it. Leave the application building up to subject matter experts with an application domain, not to software programmers. Ah but wait, lest too much be read into a passing editorial remark. Obviously software programmers play a key role here. The tendency among programmers who attempt to answer that call is to build an "application building framework." Again, the assumption is that subject-matter experts always need an app to make use of viz. I wonder why visualization software shouldn't be a part of an operating system; a core capability for any application or purpose. There have been wonderful advances made through web browser extensions, but even here visualization is at best an after thought applied to a mostly universal application. (I say "mostly" b/c there are no less than 3 different web browsers installed on my one operating system.) What happens when someone emails me some data in a flat file that I open in a text editor? Instead what is need are document object models for visualization techniques and runtime software that can parse viz documents on the fly. The runtime is optimized for robust interaction and attribute manipulation of high level visual artifacts, not application-specific tasks. This runtime can be invoked from a background process or "embedded" (contained in, called from) an application runtime. Devices having different display and user interfaces can choose how to represent what are otherwise well understood visual metaphors. Data can be more easily passed around and visualized simply by passing text documents describing interactive, dynamically updatable (or not) views. (This seems inherently more secure, too.) Only this way is ambient visualization possible; something that is available everywhere on my computer, no matter what kind of computer/device/hardware platform I am using.
Monday, March 9, 2009
Sunday, February 15, 2009
Tuesday, January 27, 2009
Update 12.28.09: I just had to record for posterity the flames from some folks who tagged my previous post in Reddit. (So much for polite, constructive discourse.) In truth, I would like to have this conversation with some of these folks. Even the harshest ones. But I don't want to have to register for a service I don't use and I don't want to get into flame wars over comment threads. I get the frustration. I've experienced it. I too have been and remain rather skeptical of the hype. Some level of hype gets things noticed and forces conversations that need to happen but aren't. Some of what I said was written and/or read poorly. For example, Mac/Office is about culture, not interoperability. I know that Google came before Web 2.0. That was expressed poorly. My company also was doing a lot of this stuff before we ever heard of Web 2.0. I can't speak for Tim O'Reilly, but I feel confident he realizes he didn't invent something. He made salient observations about the Internet and human behavior and how the two have, do, and perhaps ought to work together. Many of these concepts go back decades to the roots of computer science and the Internet. I've been in workshops with Senior Technical Fellows, having extremely well-qualified CVs, who said, "we proposed all this in the beginning." My response was, "Exactly. Isn't it past time we got back to that?"
submitted 4 days ago by candlejac