A friend discovered a small interest in learning to program computers. She tried an online course but she didn’t get far before losing interest. She may have had other reasons for giving it up but by watching her and asking questions I did locate one significant hurdle: she was trying to read code through the lens of algebra.
I have seen this before. A student encounters a word, symbol, or pattern they recognize from some other context. Believing they have sufficient information to understand it in the new context, they push ahead. Soon their mental model fills with contradictions and the entire subject becomes intractable. This state of affairs causes people to quit their studies.
I’ve been there. Fortunately I learned the solution:
Find what word or symbol was misunderstood.
Learn the correct meaning.
Re-study the material from the first occurrence.
The hardest part is completing the first step. This is especially true of students who already know a great deal and who are confident in their knowledge. Preconceptions hide themselves well but they surrender easily once found. Most people will be eager to complete the remaining steps after they have identified a real misunderstanding.
In this article I will expose some common preconceptions which can cause students of programming to quit. Teachers of beginner programming classes and writers of books would do well to treat these handicaps before setting students to code. Continue reading Programming is not Algebra
Okay, okay, it’s hard to find a use case for this when it’s so obvious that the correct way to handle one-to-many is with JOIN. But if you’re already committed to your schema and you decide you need to append serialized PHP data to a row atomically, you can cons serialized values with this query:
INSERT INTO tbl
serialized = "i:1;"
ON DUPLICATE KEY UPDATE
serialized = CONCAT(
After you have performed this three times with the serialized values 1, 2, and 3, the row contains this:
One day you set aside a shoebox to store newspaper clippings. Suddenly you are trapped under an avalanche of whole newspapers and wondering how long your body will lie there before anyone misses you.
That is what kept happening to my Erlang apps. They would store obsolete binary data in memory until memory filled up. Then they would go into swap and become unresponsive and unrecoverable. Eventually somebody would notice the smell and restart the server.
The problem seems to be related to Erlang’s memory management optimizations. Sometimes an optimization becomes pathological. If you store a piece of binary data for a while (a newspaper clipping) Erlang “optimizes” by remembering the whole binary (the newspaper). When you remove all references to that data (toss the clipping) Erlang sometimes fails to purge the data (lets the newspapers pile up everywhere). If nobody shows up to collect the garbage, Erlang dies an embarrassing death.
The first step to recovery is to monitor the app’s memory footprint and log in every so often to sweep out the detritus. It can be tricky to find the PIDs that need attention and tragic if you arrive too late. The permanent solution is to build periodic garbage collection into the app. It’s not hard to do. The only hazard is doing it too often since it incurs some CPU overhead.
Each time I have found an app doing this, I’ve had to locate the offending module and install explicit garbage collection. If there is a periodic event, such as a timeout that happens every second, I’ll use it to call something like this:
case Tick rem 60 of
0 -> erlang:garbage_collect(self());
_ -> ok
Today I installed this simple code and here is the result:
For the cost of 5% of one CPU core I stopped the cycle of swap and restart. I would like to learn why my binaries are not being garbage collected automatically. The processes involved queue the binaries in lists for a short time, then send them to socket loops which dispose of them via gen_tcp:send/2. Setting fullsweep_after to 0 had no effect. I’ll be interested in any theories. However, I’m not looking for a new solution since mine is satisfactory. I hope other Erlang hackers find it useful.
The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 46,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 17 sold-out performances for that many people to see it.
We often fail to realize how little we know about a thing until we attempt to simulate it on a computer.
Donald E. Knuth The Art of Computer Programming, Volume 1, Third Edition
Section 2.2.5, Exercise 10 (p. 298)
Now that Jane’s announcement has made it official, I need to prepare for my talk at WordCamp San Francisco. The working title is “Deep Voodoo: How the innermost innards of WordPress work” and the working content is nil.
This is where you come in. As a core contributor or plugin developer, you are aware of areas in WordPress code that scare you. I’ve been there and back again. I’ve digested, debugged and patched some of the most labyrinthine logic. I’ve even written some of the worst of it. On Saturday, August 13, I will try to make sense of it for everyone.
Please take a minute to recall something in the core code of WordPress that really stumps you. Ask me about it. I will try to work all of your comments into my talk, provided that I can’t answer it with a quick reply, a link to the Codex or a Google search.
If this gambit of asking for questions beforehand fails, maybe I’ll just give a tour of my personal favorite fork of WordPress in which every function block is shaped like a pony. (Please don’t let that happen.)