Thursday, July 05, 2018

China: A Political Meritocracy

In China’s political meritocracy versus Western democracy (published June 12, 2018 in The Economist), Daniel Bell, professor at the Tsinghua University, one of the top academic institutions in China, describes the Chinese political system as a political meritocracy.

Clearly China isn't a democracy; but should it be? We are, in the West, maybe too quick to assume it should, in part because we value democracy and may fear that a large non-democratic country can be a force against democracy in the world. Daniel Bell argues that China is allied with the West on a number of liberal values (like basic human rights and equality before the law), that China isn't trying to export its political system, and that political meritocracy may be a better system for China, given its size and history.

Friday, November 03, 2017

A Modeling Language for Thought

For maybe 20 years now, I've been searching for a way to create diagrams that help me clarify my thoughts, thus making it easier to focus on a given topic for longer, and have deeper thoughts about that topic. This could be especially useful for people like me, who seem to have worse than average memory, and thus could gain the most from serializing one's thoughts.

Argument maps are in line with what I'm looking for, but are not general enough (this by design, as their objective is specifically to create a visual representation for arguments). Unable to find a ready-made language, at different times I have played with the idea of creating my own, of which you can see a simple attempt on the left.

In addition to the lack of an existing language, an even more significant problem with a visual language is its reliance on a diagramming tool: so far, the choice of which tool to use isn't clear, existing tools are harder to use on mobile, and most actions must be made with a mouse or other pointing device instead of the keyboard, which makes them slow to use. This might also be the reason why we've yet to see a visual programming language attain an even modest level of success. This leads me to think that text, with its sentences organized in paragraphs, occasional bullet lists, and if long enough some headings, is still, regrettably, our best option for modeling thought.

Tuesday, September 12, 2017

Very Bad Wizards Discussion on IQ and Race

In episode 123 of the Very Bad Wizards podcast, David Pizarro talks about the sensitive topic of IQ and race, and in a segment, starting about 67 minutes into the podcast, he more specifically goes into the question of whether observed differences in average IQ between races are likely to have a genetic underpinning.

He first notes that the race classifications we make are mostly derived from sensory constraints of our species. He doesn't deny that, say, black/white exist as categories and have a genetic underpinning. However, it seems extremely unlikely that those differences are good trackers of the genetic diversity. Thus, he continues, it is implausible that complex traits, such as intelligence, would cluster exactly in what gives rise to the observable differences between races, and so equally implausible that differences in IQ can even be in part explained by genetic differences.

Let me try to make David's argument clearer with a car analogy. Say the Betas, an extraterrestrial species, were to land on Earth, knowing nothing about cars or mechanic, but having very good eye sight, were to classify cars based on their color. Say the Betas had evidence that black cars have more accidents than white cars, and wondered whether the difference was explained by the underlying mechanic of black vs. white cars (in humans, what we would call "genetic factors"), or due to something else (in humans, what we would call "environmental factors").

David could explain to the Betas how car color is a very bad tracker for mechanical differences between cars, unlike, say, horsepower, MPG, torque, etc. David would tell the Betas that knowing color is a very bad tracker for mechanical differences is enough for them to conclude that the difference in accident rate they observe doesn't come from mechanical differences, but rather from "environmental factors". This sits well with our intuition: if black cars indeed have on average more accidents than white cars, it most likely isn't because they are made in an inferior way, but because they have human drivers, and maybe humans don't see black cars as well at night, or humans who are on average prone to take more risk (men?), like black cars better than white cars, or some other "environmental factor".

After having done my best at steel-manning David's argument, hopefully in Daniel Dennett fashion, I'll have to admit I'm not convinced by it. Continuing on the car analogy, say another extraterrestrial species were to arrive on earth: the Alphas. The Alphas were as clueless on cars or mechanics as the Betas, but they classified cars on geographic provenance. They arrived in the 1980s, and noticed that Japanese cars were more reliable than American cars. In this case too, geographic provenance is a poor tracker of mechanical diversity, however in this case, David's argument wouldn't hold, as we know that the difference in reliability was explained by differences in American vs. Japanese car manufacturing processes. As it turns out, for cars, geographic provenance was strongly correlated with factors that had an influence on the way cars were made. And this was true, even though geographical provenance was far from being a perfect tracker of mechanical diversity; for instance, there were significantly more reliable cars made in the US in a lean manufacturing factory.

In conclusion, even if we grant that race is a bad tracker of genetic difference between individuals, it seems to me that David's argument alone does not provide us with enough of a justification to rule out that part of the observed difference in average IQ between races does have a genetic underpinning.

Friday, June 23, 2017

Is Your Time Really Well Spent?

If you're anything like me, you think somewhat despairingly of people who spend a lot of time, say more than 1 hour a day, on Facebook. You could speak of how this doesn't make them happy in the long run, and how they are the victims of algorithms perfectly tuned to feed them what they are attracted to.

But aren't you, if you're spending also north of 1 hour a day reading articles or listening to podcasts doing something very similar? Unlike Facebook, behind articles and podcasts there typically isn't a master algorithm as finely tuned to fit your preferences as Facebook's algorithm is said to be. However, the publications that “survive,”  both in term of being popular enough to still be around, and being the ones you keep reading and listening to, are often exquisitely tuned to your likings. So, effectively, the end result is the same.

And it might even be worse for you if, like me, you enjoy, say, spending an hour listening to an interview of Condoleezza Rice at the Stanford Hoover Institute, because it isn’t obvious that this isn’t time well spent. At least, not as obvious as if you had spent that time watching funny cat videos and reading comments on Imgur.

So, think about it: is your time well spent?

Tuesday, June 20, 2017

The Problem with “Does Parenting Matter?”

A recent Twitter exchange with Olivier Bruchez, reminded me of the unease I feel about discussions on the importance of parenting, or the lack thereof. To that question, such discussions often give answers of the form “parenting doesn’t matter as much as you think”, or on the contrary, “in fact, all you read is wrong, it does matter a lot”.

By “parenting”, let’s say we mean “everything parents decide to do in relationship to their children”. Let’s take “reading” as an example. Does the fact that parents read more have an effect on their children, say, level of academic achievement?

If you are doing a study on this topic, you want to disentangle this from the parents’ own level of academic achievement, as you don't consider one's own level of academic achievement to be a parenting decision. So in your study you control for that. Also, you might find that amongst people with a similar level of academic achievement, people with a higher IQ tend to read more, but since you don't take the parents’ IQ to be a “parenting decision”, you decide to control for that as well. Next, you find that some cultural aspect influence the amount of reading: say you find that parents born in the Jewish faith read more, even controlling for level of academic achievement and IQ. So again, you control for that again, as you don't take being born in a particular faith to be part of a parenting decision.

In the end, if you’re doing this enough, you’ll find no observable effect to parenting. But this is to be expected, as any of our behaviors, parenting decisions included, comes from a combination of our genes and our environment. So it is no surprise that trying to control for anything that could come from our genes or our environment, you find no effect to parenting. By wanting to disentangle parenting decisions from genes and environment, you're wiping parenting decisions out of existence. To me, such studies that concludes that "parenting decision don't matter" aren't showing anything about parenting, and only show the authors' confusion about the meaning of "decision".

Saturday, May 28, 2016

The Problem of Evil

The problem of evil, quoting from the Wikipedia article on the topic, "refers to the question of how to reconcile the existence of evil with an omnipotent, omniscient, and omnibenevolent God".

For Christian theologians, notably starting with St Augustine (AD 354–430), God created a perfect world, but gave Adam and Eve the power to deviate from His chosen path. In that view, God didn't create evil, and instead that evil is the deviation or privation of goodness. The existence of evil, they say, is the price we pay for being able to make free moral choices, and a world in which Man is able to make such choices is better than one were Man isn't, and thus God created a perfect world. This became Catholic doctrine, and this concept is often referred to as all is for the best in the best of all possible worlds, an idea which Voltaire (1694–1778) satirizes to great effect in Candide (1759).

Luther and Calvin stronger belief in predestination leads them to conclude that the fall of man was part of God's plan, and that, ultimately, we might just not be able to understand God's plan.

Monday, April 18, 2016

Waiting for the 2016 MacBook

I am very interested to what Apple will do with the new MacBook, also known as 12" MacBook or Retina MacBook, as it might tell us something about where their laptop lineup is moving. As of this writing, the new MacBook is expected to:
  • Be released by the end of April, which, would be in the next 2 weeks.
  • Come with newer CPUs, compared to the 2015 MacBooks. Those new CPUs have already been launched by Intel in Q3 2015, and are expected to be:
    • For the low-end model: Core m3-6Y30, succeeding the Core M-5Y31.
    • For the mid-range model: Core m5-6Y54, succeeding the Core M-5Y51.
    • For the high-end model: Core m7-6Y75, succeeding the Core M-5Y71.
  • Be about 25% faster, judging from the single-core Geekbench score, comparing the old high-end to the new high-end CPUs. Those scores look good (maybe too good), and would make the new high-end CPU just 5-10% slower than a 2013 Core i7 MacBook Pro.
When Apple introduced the 12" MacBook in 2015, it was in the ultra-portable category: it was a designed to be light and small, but compromising on performance, the availability of ports, and the price. And this is fine, because ultra-portables aren't designed to be entry-level machines; they are not expected to be used by, say, high-school students. Instead, ultra-portables are laptops typically used in addition to another machine, either a desktop or a more powerful but also more bulky laptop. The ultra-portable is the laptop you take with you when go to a coffeeshop, to a meetup, to a conference, on your vacation, on a business trip, or your couch at home, when you don't need anything more powerful.

In short, the 2015 12" MacBook was an ultra-portable, and not a replacement for the MacBook Air. But I have reasons to think that Apple has plans to expand the role of the MacBook, and have it progressively take the place of the MacBook Air as their new entry-level laptop:
  • The name – In 2015, Apple didn't call it the MacBook Something, with Something wisely chosen to evoke "ultra-portable". Instead, Apple just called it MacBook. This makes sense if you have in mind a lineup where you have the MacBook (for entry-level users), and the MacBook Pro (for power-users).
  • The small size of the market (pun intended) – The ultra-portable category exists because there is a market for it, but it is a small market, compared to entry-level and professional laptops. (For PCs, there is a fourth category: gaming laptops, also a smaller market.) I think that in 2015 Apple introduced an ultra-portable not to enter into a new category but as a way to develop more expertise in building lighter and thinner machines, with the idea that this technology would then be used on its entry-level and pro laptops. And isn't this exactly what they did with the MacBook Air? Remember how, when it was introduced, the MacBook Air was so expensive and slow, but so thin?
  • The shrinking size of the market – The new MacBook Pro is expected to be announced this summer, and to be much thinner. This will make the MacBook less appealing to MacBook Pro owners, as more of them will will consider their new MacBook Pro to be small enough.
Will Apple reposition its 2016 MacBook as more of an entry-level laptop? Here are some signs I'll be watching for:
  • A lower entry price – The 2015 MacBook started at $1,299. There is no way Apple will lower the price all the way to $899, the level of its least expensive MacBook Air. But they could move in that direction. (This also tells me that the MacBook Air will stay, at least for one more year, so they can keep a product at this price point.)
  • An additional USB-C port – One port is fine for a machine you mostly use away from your desk, but a second USB-C port, on the other side of the machine, like on Google's Pixel, would allow it to better compete as an entry-level laptop.
Will Apple do anything to move the MacBook towards being more of an entry-level laptop? Or do nothing special, and keep the MacBook firmly in the ultra-portable category, for at least one more year? Or do something completely different? We'll see. Hopefuly, very soon.

Thursday, April 14, 2016

Google Has A Language Problem

Apple had a language problem, which it solved in 2014 with Swift. It is now Google's turn to be in a situation not unlike Apple's, before the introduction of Swift: Google has a language problem.

The problem is Java, which is used to develop apps on Android, and internally at Google to create many of their own apps. The issue with Java is that it is controlled by Oracle, a company Google is fighting in court, and as a 20-year language that evolves very slowly, it is now just plain obsolete. To solve this problem, Google needs a new language, and I see 3 possible contenders, Kotlin, Swift, and Scala:

Kotlin Swift Scala
Benefits compared to Java High High Very high
Controversial Low Medium High
Difficulty to target Android Low Hard Medium
Difficulty to target iOS Hard Low Medium
Difficulty to target the Web Medium High Low

Other alternatives exist, but seem less realistic, at least in the short term:
  • A new Google language - Apple created its own language: Swift. So, couldn't Google come up with their own language as well? This would be a major undertaking. It isn't something outside of Google's league, but if such a large project was underway and getting even remotely close to something they could release, Google being a fairly open company, we would by now have heard about it.
  • An existing Google language - That would be: Go or Dart:
    • Go is designed for system programming, not application programming. It doesn't compete with languages like Kotlin, Swift, or Scala, because it wasn't designed to.
    • It would be all too easy to criticize Dart as a programming language, or describe how much of a failure Dart has been as far as its adoption goes, both within and outside Google. But there is no need to go there given the question that interests us. It suffices to say that Dart, maybe even more so than Go, hasn't been designed to compete with languages like Kotlin, Swift, or Scala, but rather in an attempt to be attractive to JavaScript developers reluctant to use strongly typed languages (ultimately a market it lost to TypeScript).
Getting back to our 3 contenders, no clear winner emerges from the above table:
  • Swift has a lot going for it, but a large amount of work would be needed to make it a viable first-class programming language for Android (think: IDE, APIs, interop with existing code). And maybe even more importantly, how wise would it be for Google to bet on a language designed and controlled by one its competitors?
  • Scala is the best technical solution, both for the capabilities of the language itself, its IDE support (JetBrains' own IntelliJ, Eclipse, and through ENSIME in Emacs, Vim, and Atom), a rich library ecosystem, its ability to target the web through the production-ready Scala.js, and a project underway to create a LLVM backend, which would enable it to target iOS. But the complexity of the language, both real and perceived, is a big hurdle to overcome.
  • Kotlin can be seen as a lesser-Scala: from a technical perspective, it might not be as strong as Scala, but it is strong-enough, and it is less controversial than Scala, and thus easier to sell to Java developers.
If I were Google's language tzar, that is, in the unique position to decide on Google's language strategy, I could see myself go with Scala. If instead, I had to bet on what option Google would go for, assuming it goes for one, I would put my money on them adopting Kotlin.

JetBrains is, to their credit, a fiercely independent company, so I'd be surprised if Google were to acquire JetBrains, but I can see Google announce they will support Kotlin as a first-class language for Android development, along Java. And maybe even will work with JetBrains to improve their JavaScript backend, and together work a on an  LLVM backend, ultimately allowing the same code to be compiled for Android, iOS, and the web.

Sunday, November 10, 2013

Votation populaire du 24 novembre 2013


  1. Acceptez-vous l'initiative populaire "1:12 - Pour des salaires équitables"? In the US, income inequality has been consistently going up since the 70s. Too much income inequality creates a society in which I feel less comfortable living, but imposing a maximum ratio between the lowest and highest salary within a company looks to me like a flawed approach to alleviate this problem. Using a company as a unit is problematic; it opens the door to inequalities and workarounds. Say, a dental surgeon who has her own independent practice isn't too happy paying her cleaning lady 1/12 of her salary? Then she can just outsource cleaning and bypass that constraint. It is also not clear to me that the law would take into account stock given to executives (and increasingly other employees as well). Instead, if the goal is to reduce income equality, I'd rather look at the policies of countries with a low Gini coefficient and a healthy economy, like many of the Scandinavian countries. My vote: no. Expected: no. Result: n/a.
  2. Acceptez-vous l'initiative populaire "Initiative pour les familles: déductions fiscales aussi pour les parents qui gardent eux-mêmes leurs enfants"? This is a hard one, but I'll go with a yes, mostly because the arguments of the federal council are logically flawed. If the primary goal is to help families with children, why only provide this help to those who pay someone to take care of their children? Imagine you wanted to provide an incentive for people not to use their car going to work; if you were to do so by making public transportation costs deductible, you'd be discriminating against people who carpool, bike, or walk to work. (Using a deduction for such an encouragements feels flawed to me, as it disproportionately benefits people with higher salaries who are also those who need the help the least, but this is a different question.) My vote: yes. Expected: no. Result: n/a.
  3. Acceptez-vous la modification du 22 mars 2013 de la loi fédérale concernant la redevance pour l'utilisation des routes nationales (Loi sur la vignette autorouotière, LVA)? The suggested amount (CHF 100.-) doesn't seem unreasonable, and since this is a rather technical issue, I'm comfortable following the recommendation of the federal council and parliament.

Monday, October 21, 2013

Predicting the late-2013 MacBook Pro Retina performance

Some wouldn't be surprised if new MacBook Pro Retina were to be announced at tomorrow's Apple event. Whether they are indeed announced tomorrow, or in the following months, I for one wonder what their performance will be.

I'll focus on the Geekbench 3 score, because it is the most widely used, and in particular on its single-core, 64-bit score, as I think this is the number that best reflects the experience I have using the computer as a developer. Let's look at two other lines that made the move to Haswell processors over the last year:
  • The iMac, from late 2012 (3542) to late 2013 (3935), saw an 11% improvement.
  • The MacBook Air, from mid-2012 (2863) to mid-2013 (3143), saw a 10% improvement. 
I'll predicate my prediction on the MacBook Pro Retina seeing a similar relative improvement. The MacBook Pro Retina from early 2013 scored 3395, so I predict the new "late 2013" MacBook Pro Retina will score at about 3393*1.1 = 3732.

This would make the iMac only just over 5% faster than the MacBook Pro Retina, which would make it hard to for me to choose between the latest MacBook Pro Retina and latest iMac.

Update (2013-10-22): The most high-end CPU we can get on the MacBook Pro like is described as a 2.6GHz Quad-core Intel Core i7 with Turbo Boost up to 3.8GHz, which according to Wikipedia is a i7-4960HQ with  6 MB on-chip L3 cache. The high-end late-2013 iMac comes with a i7-4771, still according to Wikipedia. Based on the specs, the iMac CPU more cache (8 MB vs. 6 MB) but the memory bandwidth MacBook Pro CPU is higher (76.8 GB/s vs. 25.6 GB/s). However, at this point we don't yet have published performance scores for the i7-4960HQ on Geekbench.

Update (2013-10-23): CPU World has a useful comparison of the MacBook Pro's i7-4960HQ (left) with the iMac's i7-4771 (right). Of interest, this comparison mentioned the F16C additional instructions of the iMac's i7-4771, which provide support for doing half-precision to and from single-precision floating-point conversions, but it isn't clear that the availability of those instructions would improve the performance of tasks typically performed by developers.

Also, a few 32-bit scores for the i7-4960HQ started showing up. There are too few to draw any conclusion, and we'd like to look at 64-bit scores, but taking a value of 3405 for the 32-bit MacBook Pro's i7-4960HQ scores and of 3584 for the 32-bit i7-4771 scores, the iMac would indeed be just 5% faster.

Wednesday, April 10, 2013

Requirements for a GTD system

For a while, I've been occasionally updating a list of requirements for a software I would be able to comfortably use to manage my GTD system. So without further ado:
  • actions
    • actions are always in a context, and some actions are also tied to a project (my primary way to look at lists of actions is by context)
    • dates
      • start date (i.e. schedule a task to become current at a future date)
      • recurring tasks (e.g. every weekday, every Monday, every first Tuesday of the month…)
      • due date not important; making the task red once it passed the due date is useless to me; maybe another implementation could make this information useful
    • email
      • quick way to create an action from an email (otherwise I am more likely to leave emails in my inbox rather than create tasks)
      • quickly find email related to an action
      • special but important case of a start date: create action from an email that become current at a future date (i.e. "if no answer in 7 days, do this")
  • projects
    • lists of current projects
    • in each project
      • next actions for that project
      • reference material: notes (typically indented lists), files (PDF, screenshots)
    • ability to archive projects
  • access
    • desktop
      • web based or OS X app
    • mobile
      • Android support (bonus for also working on iOS)
      • fast read access to specific "list" (e.g. context, project)
      • editing lists from a mobile is not a priority (just having read-only access, while not ideal, would suffice)
      • offline on mobile (ideally with background sync so the offline version is used even when online for speed)
    • proven stability of the system's cloud-based component

Wednesday, December 05, 2012

Improve your web app design


There is out there a wealth of resources you can use, often for free, to improve your web app design:

Wednesday, November 28, 2012

Importing the scott schema in Oracle on Amazon RDS

Oracle Amazon RDS doesn't allow you to connect as sysdba, and you don't have access to the local file system, so you can't run the rdbms/admin/scott.sql script, as you would otherwise do. Instead:
  1. Download the demo scripts
  2. As master user:
    1. Change password of the scott user1: alter user scott identified by password ;
    2. Grant some rights to scott:
      1. grant connect to scott;
      2. grant create table to scott;
      3. grant execute any type to scott;
      4. grant unlimited tablespace to scott;
      5. grant create any trigger to scott;
  3. Connect as scott/password
  4. Run SQL in scott.sql

1 The scott user exists by default in Oracle RDS instances, but I am not sure what the password is out of the box. (It isn't tiger.)

Friday, November 09, 2012

Glassfish 3.1

  • Starting the server
    • cd glassfish
    • ./bin/asadmin start-domain --verbose
  • Changing JVM options
    • Edit domains/domain1/config/domain.xml
    • For instance, add <jvm-options>-verbose:class</jvm-options>
    • (Just adding an command line parameters to the java started in bin/startserv doesn't to the trick; I suspect this is just a loader, which then starts the real VM that will host the server)
  • Glassfish key store password
    • By default, Glassfish sets the javax.net.ssl.keyStore property (in domain.xml) to point to its own key store, in config/keystore.jks
    • That key store has a password set on it, which is the same as the Glassfish master password, by default changeit
    • However, the default domain.xml doesn't set the javax.net.ssl.keyStorePassword property
    • As a result, when establishing an SSL connection, Java fails to key store, resulting in a java.security.UnrecoverableKeyException with the message Password must not be null
    • One way to solve this is to add a <jvm-options>-Djavax.net.ssl.keyStorePassword=changeit</jvm-options> in domain.xml

Thursday, November 08, 2012

Propos sur le bonheur, Alain (1928)

A few selected quotes:
  • Je voudrais dire de la mauvaise humeur, qu’elle n’est pas moins cause qu’effet.
  • La colère est à proprement parler une sorte de maladie, tout à fait comme est la toux.
  • Le chapelet est une invention admirable qui occupe la pensée et le doigts ensemble à compter.
  • Réagir contre l’humeur, ce n’est point l’affaire du jugement; il n’y peut rien; mais il faut changer l’attitude et se donner le mouvement convenable; car nos muscles moteurs sont la seule partie de nous même sur laquelle nous ayons prise.
  • Tout religion renferme une prodigieuse sagesse pratique.
  • […] il faudrait toujours se dire: «ce n’est pas parce que j’ai réussi que je suis content, mais parce que je suis content que j’ai réussi»
  • Il y a deux espèces d’hommes, ceux qui s’habituent au bruit, et ceux qui essaient de faire taire les autres.
  • L’art de vivre consiste d’abord, il me semble, à ne point quereller soi-même sur la parti qu’on a pris ni sur le métier qu’on fait. Non pas, mais le faire bien.
  • La pensée est une espèce de jeu qui n’est pas toujours très sain. Communément, on tourne sans avancer. [...] Percevoir et agir, voilà les vrais remèdes.
  • La vrai richesse des spectacles est dans le détail. Voir, c'est parcourir les détails, s'arrêter un peu à chacun, et, de nouveau saisir l'ensemble d'un coup d'œil.
  • [...] l'intelligence à des pointes aussi pour nous piquer.
  • Ce qui nous blesse  dans des pensées inextricables, ce ne sont pas les pensées inextricables, c'est plutôt une espèce lutte et résistance contre cela même, ou, si vous voulez, un désir que les choses ne soient pas comme elles sont. 
  • La tristesse n'est jamais ni noble, ni belle, ni utile.
  • Un auteur ancien à dit que tout événement à deux anses, et qu'il n'est pas sage de choisir pour le porter celle qui blesse la main.
On doing:
  • On veut agir, on ne veut pas subir. Aussitôt que je me donne librement de la peine, me voilà content.
  • L'enfant se moque de nos jardins, il se fait un beau jardin, avec des tas de sable, et des brins de paille.
  • Tous les métiers plaisent autant que l'on gouverne, et déplaisent autant que l'on y obéit.
  • Ne demandez pas à celui qui ne sait point jouer s'il aime le jeu. La politique n'ennuie point dès que l'on sait le jeu; mais il faut apprendre; il faut apprendre à être heureux.
  • Le travail est la meilleure et la pire des choses; la meilleure, s'il est libre, lapide, s'il est serf.
  • Celui qui met toute son attention sur un acte difficile, celui-là est parfaitement heureux.
Dans la grande prairie must be read in full. Alin recounts part of Palto’s myth of Er, where after death people arrive in a large meadow, where they can choose what they want (and will get) in their next life, and so often pick exactly the oposite of what they need. Alain doesn't believe in an afterlife, and sees us making those bad choices every day.

Wednesday, November 07, 2012

iPhone 5 vs. Nexus 4: The Specs


iPhone5 Nexus 4
Price for 16 GB $700 $350
RAM 1 GB 2 GB
CPU 1.3 GHz dual core 1.5GHz quad-core
Display size 4in 4.7in
Display resolution 1136x640 1280x768
Display PPI 326 320
Front camera 1.2 MP 1.3 MP
Back camera 8 MP 8 MP
Data LTE HSPA+
Battery 1400 mAh 2100 mAh
Weight 112 g 139 g

Tuesday, November 06, 2012

MySQL

  • Administration
    • Startup on OS X: sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
    • Shutdown: sudo mysqladmin shutdown
    • Listing the content of the database in XML: mysqldump -X --user=orbeon --password=orbeon orbeon orbeon_form_data | less
    • Connecting to the database from the command line as user orbeon: mysql --user=orbeon --password=orbeon orbeon
  • DDL and testing
    • Employees test database
      • Removed from the beginning of employees.sql the lines that create the employees database
      • Import with mysql --user=orbeon --password=orbeon orbeon < employees.sql
  • XML functions
    • ExtractValue(xml, '/path/to/value')
    • UpdateXML(xml, '/path/to/node', '<new-node/>')
      • Replaces <node> by <new-node> (not the content of <node>)
    • load_file('/path/to/file')
      • Need to grant file permission
        • mysql --user=root mysql
        • grant file on *.* to 'orbeon'@'localhost';
      • File needs to be in a place where MySQL can read
        • sudo -u _mysql cat /tmp/BidForm.xml
  • Issues
    • "To deep XML"
      • Bug        
      • Verified with 5.1.15
      • On the bug thread, someone had this with 5.5.9


Thursday, November 10, 2011

The Ideal Programming Language


My requirements for the ideal programming language, roughly sorted by order of importance:

  1. Can be used equally well for code that will run on the server-side (most likely targeting the JVM) and on the client-side (for now, this means compiling to JavaScript). This is key for people to be able to use the language. Nowadays, a language that also comes with its own environment is unlikely to be adopted. [Unlike Haskell; like Dart]
  2. Strongly typed, with type inference across compilation units, i.e. not to force type declarations on "public APIs" (even if having them, most of the time, might be a good idea). [Unlike Scala; like Haskell]
  3. Provide rich constructs, like case classes, traits, partial functions, continuations… The world is complex, and our programs try to model it, and the right constructs make the programmer's job easier, and the code simpler. (See the simple vs. easy distinction made by Rich Hickey.) [Like Scala]
  4. Adhere to the off-side rule. Because syntax matters. [Like Python, Haskell, CoffeeScript, F#; unlike Scala, Dart…]
  5. Provide a rich data type library. [Like Scala; unlike JavaScript]
  6. Compilation should be fast enough that developers don't feel compiling/building as an additional, lengthy step that needs to happen before they can run code. I.e. when writing code running in the browser, programmers should be able to make a change in their editor, cmd-tab to the browser, reload the page, and see the change. [Unlike Scala]
  7. Don't force "object oriented" paradigms on programmers. E.g. the standard way to write a program shouldn't necessarily be to start defining a class. [Unlike Java, Scala]

Wednesday, August 17, 2011

Is "free will" a fallacy? (Hint: the fallacy is in its definition)

It is irrelevant how brilliant your demonstration is: if you start with an incorrect hypothesis, your conclusion has no value.

Take Daniel Miessler article concluding free will is an illusion, also mentioned by Sam Harris. His hypothesis is that "true (free) influence on the world"—whatever that "true (free)" designation means—requires the ability to change the previous state of the world or to change the laws that govern the universe.

This is very much at odd with the common understanding of the word influence. Say you fail to see a banana peel on the curb, slip on it, and fail. Wouldn't you say that the banana peel influenced your fall? You would, as without it, most likely, you wouldn't have fallen. And I assure you that the banana peel neither changed the previous state of the world nor changed the laws that govern the universe.

Unfortunately, bending the meaning of words, or even worse, completely omitting definitions, too often plagues discussions on free will.

Friday, November 26, 2010

Autocomplete and JavaScript Change Event

Different Sorts of Autocomplete

When it comes to autocomplete in browsers, you need to make distinction between autocomplete for:

  • Username/password — Once you have a username and password saved for a certain login form, the browser will pre-fill the username and password fields with the saved values.
  • General form fields — Most browsers, including Firefox, IE, and Chrome, provides a similar autocomplete interface for form fields: as you start typing in a field, the browser will provide a list of suggestions. If you select one, the value you select will be used to populate the field. (Chrome might, based on the choice you made, also populate other related fields.)

Typical autocomplete UI

The HTML Specification

When it comes to DOM event, and in particular the change event, there is a significant difference between those two cases: username/password fields are auto-filled immediately when the page is shown; for other fields, you explicitly select a value from a list and tab to another field. This is important in the context of the HTML specification. The HTML 4.01 specification says:

The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.

My interpretation is that browsers should dispatch the change event when users select a value from a list of suggestions, but not when browsers pre-fill the username and password fields, as in that case the username and password fields don't gain and loose the focus. HTML 5 is more abstract (emphasis mine):

When the change event applies, if the element does not have an activation behavior defined but uses a user interface that involves an explicit commit action, then any time the user commits a change to the element's value or list of selected files, the user agent must queue a task to fire a simple event that bubbles named change at the input element, then broadcast formchange events at the input element's form owner.

HTML 4.01 talks about dispatching the change event when the form field looses the focus, which makes sense for text fields, but doesn't for file selection fields (<input type="file">): in that case it make more sense to dispatch the change event when the file has been selected, rather than wait for users to change the focus to another field. This is most likely why HTML5 talks about "users commiting the change" rather than "the control loosing the focus".

Even with this HTML5 definition of the change event, for the case of the username/password fields pre-filled by browsers as the page is loaded, I find it hard to argue that users "committed a change" by just loading the page. So based on my interpretation of the HTML 4.01 and HTML 5 specifications, I would expect browsers to:

  • Dispatch the change event when users select a suggested value and tab to another field.
  • Not dispatch the change event to fields they pre-filled without users tabbing through the fields, such as the username/password fields.

The Real World

Expectations are rarely in line with reality, especially when it comes to browser behavior:

  • For username/password fields:

    • Firefox 4, IE 7, and IE 8 don't dispatch the change event.
    • Safari 5 and Chrome 9 do dispatch the change event.
  • For other form fields:

    • IE 7 and IE 8 don't dispatch the change event.
    • Firefox 4 does dispatch the change change event when users select a value from a list of suggestions and tab out of the field.
    • Chrome 9 does not dispatch the change event.
    • Safari 5 does dispatch the change event.

You can test this by:

  • For username/password fields, load the login test case. Enter a username/password, submit the form, tell the browser to remember the login, reload the form. On Firefox, Chrome, and Safari the password field comes pre-filled, but the change event is dispatched only by Chrome and Safari. On IE, the password will be pre-filled only after you enter the username, but even as you tab through the password field, no change event is dispatched.
  • For other form fields, use this test case.

Workarounds

The bottom line is that your JavaScript code can't rely on the change event. If your code needs to know when the value of a field changes, you have two choices:

  1. Have some JavaScript code that runs at a regular interval, checks the value of all the fields, and calls your change handler when it notices that a value has changed.
  2. Disable autocomplete by adding autocomplete="off" on the <form> element. This technique has been supported by browsers since IE 5 (March 1999) and Netscape 6.2 (October 2001), and now made its way into HTML5.