An easy way to get back into biking/walking and save your soul (and our planet). Pick a one (1) mile trip, once a week, and bike or walk it instead of driving. Your car is least efficient on those short routes and you need the exercise anyways. win-win! What a great idea. As you get into the hang of it, you can add more trips via bike and extend to a few miles.
nearly half of all trips in the United States are three miles or less; more than a quarter are less than a mile.
Also, if you do the exercise and realize you have no destinations within 1 mile of home, why do you live there? move. seriously.
What if there was something you could do to improve your health and fitness, save money, reduce our dependence on foreign oil, improve air quality, and reduce your carbon footprint, all at the same time—would you do it?
Maybe that’s a bit of preaching to the choir here, but that’s the idea behind The 1-Mile Solution. As Andy Cline explains,
The idea is simple: Find your home on a map…Draw a circle with a 1-mile radius around your home. Try to replace one car trip per week within that circle by riding a bicycle or walking. At an easy riding pace you can travel one mile on a bicycle in about seven minutes. Walking takes about 20 minutes at an easy pace.
Another DB company from database guy Mike Stonebreaker (Postgres, Ingres, etc). Sounds fast and encourages the use of stored procedures and lets you write them in Java. Crazy. Anyone heard of this? tested it? using it?
Under the leadership of Postgres and Ingres co-founder, Mike Stonebraker, VoltDB has been developed as a next-generation, open-source DBMS that has been shown to process millions of transactions per second on inexpensive clusters of off-the-shelf servers. It has outperformed traditional OLTP database systems by a factor of 45 on a single server, and unlike NoSQL key-value stores, VoltDB can be accessed using SQL and ensures transactional data integrity (ACID). VoltDB is ideal for developers of ad serving, gaming, software as a service (SaaS), financial trading, on-line businesses and other systems with large, fast-growing transaction volumes because VoltDB scales out easily on low-cost servers while providing automatic high availability for 24x7 operation.
We had a lovely talk last month at LA Perl Mongers on Cassandra, a highly distributed, eventually correct key-value store with just a touch of metadata. This is just one of the current crop of key-value stores discussed as "NOSQL" (what a terrible moniker, but interesting ideas in the distributed key-value space).
I'm exciting to see an ACID compliant fast db. I do wonder what has been skipped to make it speedy. Can it persist to disk? snapshot to disk? Or do I just have to maintain enough of my live servers to keep the data up?
What project can I test this out with?
Postgres and Ingres father Michael Stonebraker is answering NoSQL with a variant of his relational baby for web-scale data — and it breaks some of the rules he helped pioneer.
On Tuesday, Stonebraker’s VoltDB company is due to release its eponymous open-source OLTP in-memory database. It ditches just enough DBMS staples to be faster than NoSQL while staying on the right side of the critical ACID database compliance benchmark for atomicity, consistency, isolation and durability of data.
Another question: how do I interact with the DB? I don't see a DBD::Volt namespace yet, and the db *really* wants to be called via stored procedures. From the FAQ:
3.4. Why doesn't VoltDB support ODBC/JDBC?
The primary interaction with a VoltDB database is through stored procedures, and the stored procedure interface (callProcedure) is easy to understand and interpret for those who are familiar with procedure calls through ODBC.
More importantly, although it is possible to perform occasional ad hoc queries on a live VoltDB database, you cannot modify the schema or perform other arbitrary actions through interactive SQL statements. Therefore a generic database connector is not useful when dealing with VoltDB.
Some comparisons also from the FAQ:
2.2. How does VoltDB differ from MySQL used with memcached?
Memcached is a distributed in-memory cache. It provides none of the reliability or consistency of an ACID-compliant SQL database. Memcached is often used as a cache in front of MySQL to improve performance of frequent transactions. But this requires the client application to manage the hash algorithms for both memcached and MySQL, as well as all of the transactional consistency and reliability between the two systems and across the cluster.
VoltDB automates all of these functions with none of the penalties, while providing similar or better performance. In addition, caching can help improve read performance for products such as MySQL, but does not help scale write performance. VoltDB scales linearly for both read and write performance.
2.3. How does VoltDB differ from a Key-Value Store (such as Cassandra)?
Key-Value stores are a mechanism for storing arbitrary data (i.e. values) based on individual keys. Distributing Key-Value stores is simple, since there is only one key. However, there is no structure within the data store and no transactional reliability provided by the system.
VoltDB provides the ability to store either structured or unstructured data, while at the same time providing full transactional consistency, reliability, and standard data access syntax through ANSI SQL. VoltDB can even define a transaction that includes reads and writes across multiple keys. Finally, VoltDB provides comparable or better performance in terms of throughput.
The Perl Survey 2010 is now live. Its purpose is to better understand
the demographics and opinions of the Perl community. You can complete
the survey at http://survey.perlfoundation.org - it should take about
10 to 15 minutes.
Once you've done that, please let your relevant friends and colleagues know about the survey so they can complete it as well. My aim is to get a response of over 1000 individuals, and to run the survey (lightly adapted) every two or three years so we can see how the community changes over time. The official announcement of
the survey is here:
Odds are, you didn't read about the 5.12 release outside of Ryan Paul's overview on Ars Technica. You see, Perl not being dead and just continuing business as usual doesn't make for compelling news. Also, let's admit, the Perl community has a great deal of competence in producing software, but couldn't market its way out of a soaking wet paper bag.
Interesting read over at ostatic.com, a guest piece by Jeff Hobbs. This topic is a proverbial discussion point in the perl community and has heated up quite a bit over the past year or two, "how to better market the awesomeness of perl?" It's hard to evangelize when we're busy getting stuff done. This article provides a nice collection of the arguments why 'perl is still relevant.'
Disclosure: ActiveState produces a professionally packaged perl for windows, so they are of course a bit biased into the pro-perl camp. (And they may be feeling some pressure from Vanilla perl now shipping a "normal" perl for windows).
Charlie Munger spoke for three hours at the Wesco financial meeting yesterday. Charlie is a wise old man. I played hooky from work yesterday to attend my third yearly meeting. The 1500 of us in the room don't get much in the way of money investment advice but instead lots of advice on time and wisdom investment. He is a big fan of mental models (of behavior) and checklists.
He speaks in frequent double-negatives. I believe this is a consequence of his mental patterns. Instead of "I do X," he'll say, "I avoid doing not-X." This is not insignificant. He has checklists in his head of behaviors to watch out for. These are his mental Unit Tests, he ticks through them to make ensure he's avoiding these (self-)destructive traps.
These checklists are based on years of watching people succeed and make mistakes. Mistakes are easier to notice and analyze and turn into rules of things to avoid, but only if looked at full on without sugar coating. These are the edges of the human veil of rationality, places where we still think we are rational but we are not. This is where damage and failure happen.
He watches for systemic failure of incentives: incentives that are misaligned with behavior that is good for society; systemic failures of the human rationality. Examples include selection bias, "I'm doing it so it's right", "I did well so I must have done the right thing", "it's tied to what I do for work, so it is ok."
You can see a great example of this in his interview this week with CNN Money and last week with CNBC about Lehman Brothers. When asked about why Lehman's Fuld was defective, he runs down a list of reasons. It's like he's reading off of a testing report. His first answer is so obvious to him, that he doesn't expand on it here. If your system is set to bring out the worst in people, you will get the worst in people, 100% of the time.
The system was all wrong. It wasn't that the people were so bad. The systems were all wrong. The systems brought out the worst in people instead of the best.
Q: What characteristic is it in Dick Fuld [...] that is defective?
A: Hard to name a defect he didn't have. [...] Yeah really.
Dick Fuld would not be, for me, an exemplar of the best that can exist in investment banking.
[...]
Q: Worse than Bear Stearns?
A: Yes.
Q: Why?
A: Meglomania.
Envy Driven.
Poor Cognition.
Isolation.
And of course, its an interesting example of corporate governance. 'Cause You didn't have to be very wise to see that the place had the wrong leaders and they had a board that did exactly nothing to fix their problem.
Looking at this interview with an adware author (Thanks for the forward, J^K), I see that interviewee has learned one of these models, the power of gradualism. He inadvertently shows that he is unaware of another, the tendency to dehumanize the other end of a business transaction to make it easier emotionally to take advantage of them. It doesn't sound like he's aware that he's marginalizing his target: first they're less-savvy, then they're apathetic or ignorant. This first model is helpful to him to feel better about his reprehensible actions while the second helped him to take those actions. Which model and associated tests will be more effective in your mental toolbox?
It was funny. It really showed me the power of gradualism. It’s hard to get people to do something bad all in one big jump, but if you can cut it up into small enough pieces, you can get people to do almost anything.
Most adware targets Internet Explorer (IE) users because obviously they’re the biggest share of the market. In addition, they tend to be the less-savvy chunk of the market. If you’re using IE, then either you don’t care or you don’t know about all the vulnerabilities that IE has.
You'll hear echos of these sentiments from all of the bankers being interviewed on Capital Hill. They are too close to the problem to be aware of their model deficiencies. The brief period where our anger can trigger change is slipping away. How shall we find the root problems and re-engineer the incentive system to keep them from reoccurring?
