671 karma · joined September 4, 2010
Email: todd at reflect.run
CouchDB supports ad-hoc queries in the form of 'temporary views'. The downside (and I think a difference compared with MongoDB) is that temporary views can't be used in production since they are not indexed and thus are much slower than permanent views.
I'm developing my application in Python, which has great support for CouchDB in the form of CouchDB-Python (http://packages.python.org/CouchDB/) and CouchDBKit (http://couchdbkit.org/). Using CouchDBKit, it was pretty easy to set up CouchDB artifacts (map functions, reduce functions, design documents) into a nice file/folder hierarchy and write the simple Python glue code to deploy updates to CouchDB via a single shell command.
"In this case efficiency often means that oxymoron bureaucrafic efficiency. When something was needed fast at IBM they used to be able to fill out the paperwork and hand carry it to the group, eventually finding someone who could handle the problem on the spot. Now all requests go into a big queue in the sky and nobody knows who will handle it, or from what country."
1) I'm pretty sure a multi-national corporation with 400,000 employees considers hand-carrying paperwork to be an operational deficiency. This is the 21st century, why create an unnecessary paper-trail when your company builds products to specifically handle this type of use-case?
2) Is the author talking about some sort of routine process (Level 1 Support needs to escalate the issue to someone in L2) or some sort of special case (A client is experience a major outage and we need to find an expert who can fix it)? If it's the former, then this should be a documented repeatable process that is done many times a day, and thus why would it matter if the L1 and L2 are in different buildings/countries/whatever.. If it's the latter, then the chances of the right expert working in the same building as person seeking her out is going to be pretty low. Telecommuting does come into play in either of these scenarios.
3) The author seems to be correlating telecommuting with increased bureaucracy. I'd argue that reducing telecommuting will not decrease bureaucracy; it will still take 4-6 approvals to make that purchase, and the tools to expedite the approval process (contacting the right people directly, escalating to managers) will still be the same.
My first pass is really about proving out the idea, learning about the domain, and finding any gotchas. The second pass is about using my experience from the first pass to create a clean, maintainable base.. something that I can come back to in a month and be able to maintain, enhance, and deploy without having to relearn everything again.
In my experience, BoltBus and Megabus have extremely poor customer service. I've had multiple bad experiences with them and as a result I refuse to use their services any more.
Last month I waited an hour and a half in 40 degree weather for the Megabus from NYC to Philadelphia. Throughout that time, none of the staff on site had any idea of what was going on, or if they did no one told us what the problem was and when we could expect the next bus to arrive. We heard later that both buses scheduled during that time had broken down.
There seems to be a trend towards consolidation for major e-commerce players recently, with IBM purchasing Coremetrics and Sterling, and Adobe purchasing Omniture.
For large companies, it is a multi-million dollar investment to build a warehouse management system capable of showing near real-time levels of inventory. Besides the capital costs, companies can have very specific workflows for managing inventory levels. Also things like drop-ship vendors and sourcing items from multiple sources can make it extremely difficult to calculate or predict inventory levels prior to a sale.
The expressiveness of SQL and performance of a mature DBMS beats the pants off of the GAE Datastore at the moment. Obviously scalability is the major benefit of App Engine, but I'm not so sure the trade-offs are worth it.
The rest of my savings goes to an online savings account.
Thanks for the link to Sunlight Labs, I'll check it out.
The search functionality makes a call out to Geonames.org to get location data, and unfortunately I hit the quota for more free account. I'm going to purchase premium service with a higher quota, but in the meantime I modified the search to only accept zipcodes, which will not require a call to geonames.
I'm going to look into purchasing their paid service, but in the meantime I modified the code to only accept zipcodes and bypass the geonames web service call.
You can view details on how I calculate each position by clicking on the position's 'check' or 'x' image. Doing so will open a modal dialog provide that displays detailed information in both a graph and table view.
Getting additional position data is one of my top priorities in the next week or so. The first additional subset of data I plan on using is the Political Courage Tests from Project Votesmart (http://www.votesmart.org/npat_about.php). With this data, I should be able to provide positional information on 40-50% of all Congressional candidates, including Independents.
Finding this same data for regional candidates will be tougher. I am thinking of providing some alternate information for these candidates, such as a Twitter feed or RSS feed.
Also thanks for reporting the error. I will look into it today.
I will address this issue tonight.
In addition to providing basic candidate bio information, when possible I also provide details on what issues a candidate supports or opposes. I calculate each position programatically using the following data:
- Special Interest Group ratings for this particular candidate. i.e. the NRA may give a candidate a score of 90 out of 100 in the year 2007 for the candidate's position on gun rights issues.
- The bias of the Special Interest Group i.e. the NRA strongly supports issues related to the preserving of Second Amendment privledges.
These ratings are then weighted by year (more recent ratings have greater weight) and run through an algorithm to determine a candidate's calculated "position" for each issue.