Han vuelto a jugar Karpov-Kasparov http://www.clarin.com/diario/2009/09/24/um/m-02005604.htm
Cuando jugaron por el campeonato mundial, yo tenia 9 años y me fascinaba el ajedrez. Mi preferido era Karpov, sin entender mucho por que. Luego de entender más del juego me dí cuenta de la monstruosa superioridad de Kasparov y lo empecé a respetar.
Ya ahora con 34 años vuelvo a preferir a Karpov antes que a Kasparov ya que siempre me dio la sensación que se dejo perder contra la computadora por plata.
Además estudiando un poco el juego de Karpov, de viejo me gusta más el juego cerrado donde vences al contrario sin que este se de cuenta donde se equivoco.
Esa dualidad de juego abierto de Kasparov y cerrado de Karpov la mantengo en mi juego, abriendo siempre de Dama jugando de blancas y siempre Siciliana con negras.
En fin, locuras de cada uno.
Friday, September 25, 2009
Sobre la idea de "Connecting de Dots" de Steve Jobs, en la historia de Ricahrd Feynman de wikipedia ( http://en.wikipedia.org/wiki/Richard_Feynman ) dice lo siguiente:
"During a temporary depression following the destruction of Hiroshima by the bomb produced by the Manhattan Project, he focused on complex physics problems, not for utility, but for self-satisfaction. One of these was analyzing the physics of a twirling, nutating dish as it is moving through the air. His work during this period, which used equations of rotation to express various spinning speeds, would soon prove important to his Nobel Prize winning work."
Connecting the Dots funciona, aunque primero tenes que plantar muchos Dots.
"During a temporary depression following the destruction of Hiroshima by the bomb produced by the Manhattan Project, he focused on complex physics problems, not for utility, but for self-satisfaction. One of these was analyzing the physics of a twirling, nutating dish as it is moving through the air. His work during this period, which used equations of rotation to express various spinning speeds, would soon prove important to his Nobel Prize winning work."
Connecting the Dots funciona, aunque primero tenes que plantar muchos Dots.
Una linda forma de manejar versionamiento de documentos online:
Slashdot is hardly the right venue to get a good answer to this question (how the hell did it end up in the Hardware category?), but I've dealt with this a zillion times, so I'll give a pointer to what is very likely the correct answer: optimistic locking [wikipedia.org].
Hard locks are probably not what you want in a stateless web app. (E.g. What happens if someone locks a record and then is hit by a bus?) Instead, here's how it works:
1. User X fetches version 1 of Record A.
2. User Y fetches version 1 of Record A.
3. User X modifies her copy of Record A and attempts to save the change.
4. System checks whether incoming version (1) matches database version (1). It does, so the save proceeds and the version number on the record is updated to 2.
5. User Y modifies his copy of Record A and attempts to save the change.
6. System checks whether incoming version (1) matches database version (2). It does not, so User Y is notified that he cannot save his changes.
7. User Y fetches version 2 of Record A and tries again.
This is also known in the vernacular as "second save loses". It may sound too harsh, but it is much better than "first save loses and user isn't notified", which is what you get if you have no currency checking at all. And it's also much more web friendly that your old desktop app (which uses an approach that is technically called "pessimistic locking").
--
"We all assume the worst the best we can." - Iron & Wine
Slashdot is hardly the right venue to get a good answer to this question (how the hell did it end up in the Hardware category?), but I've dealt with this a zillion times, so I'll give a pointer to what is very likely the correct answer: optimistic locking [wikipedia.org].
Hard locks are probably not what you want in a stateless web app. (E.g. What happens if someone locks a record and then is hit by a bus?) Instead, here's how it works:
1. User X fetches version 1 of Record A.
2. User Y fetches version 1 of Record A.
3. User X modifies her copy of Record A and attempts to save the change.
4. System checks whether incoming version (1) matches database version (1). It does, so the save proceeds and the version number on the record is updated to 2.
5. User Y modifies his copy of Record A and attempts to save the change.
6. System checks whether incoming version (1) matches database version (2). It does not, so User Y is notified that he cannot save his changes.
7. User Y fetches version 2 of Record A and tries again.
This is also known in the vernacular as "second save loses". It may sound too harsh, but it is much better than "first save loses and user isn't notified", which is what you get if you have no currency checking at all. And it's also much more web friendly that your old desktop app (which uses an approach that is technically called "pessimistic locking").
--
"We all assume the worst the best we can." - Iron & Wine
Subscribe to:
Posts (Atom)