If you ever see “Host error number XXX”, it means that this was the XXX’th error of the day that this Profile instance wrote to the logs. Get someone to look it up in the Profile logs.

Also, Calling mrpc ZWRAP with [925, 8864, ""44758220"", |!|] will fail if 8864 is not a valid profile userid (which is the case for me).

1. Launch PowerPoint (these instructions work for Office 2010).
2. Open the presentation to be fixed.
3. Go to the File menu, and select “Options”.
4. Select “Customize Ribbon”.
5. On the right-hand side of the complex dialog find the “Main Tabs” section. Check the checkbox next to the “Developer” tab.
6. Click “OK” and return. You should now have a “Developer” menu above the ribbon.
7. Select the “Developer” menu to display the developer ribbon.
8. On the ribbon, click the button labeled “Visual Basic”
9. In the upper-left-hand side of the screen there is something labeled “VBAProject” with sub-folders labeled “Modules” some of which have entries with names like “Module1″. You may have to expand the tree-view widget to see some of these.
10. For each module, double-clicking will open it. Those that are completely blank (all of them in my company’s template) are useless and can clearly be deleted.
11. Delete a module by closing it (if you had opened it), then right-clicking on the module and selecting “Remove Module1…”. It will offer to save, but you won’t need to do that.
12. After doing this for all unwanted modules, go to the “File” menu and select “Close and Return to Microsoft PowerPoint”.
13. Save your newly-changed document.

By the way, in case anyone couldn’t tell, after experience with it I really hate Microsoft’s “ribbon”. The old approach “Menus” required people to look around through lots of menus to find the commands they needed (although if they used a command frequently, they could read the menu to see what keyboard command would execute that). Power users could modify the menus if they wanted to (but hardly anyone did). In the new “Ribbon” interface, the commands that people use a lot are just one click away — as long as you know what arcane icon represents the action that you want to perform. If you need to find a new command you no longer have to look through the menus to find it… instead you simply perform a web search to find someone else who ran that command and follow the arcane set of clicks that they wrote in order to locate the mysterious and well-hidden button that performs the action. Power-users are people who know how to perform an action without looking it up on the web.

By the way, what’s the conversion rate on really small amounts? Because of rounding, if you withdraw 1 US cent, converted to euros, they would owe you 3/4 of a euro cent, and rounded to the nearest cent that would be 1 euro cent.

So you walk into the bank and deposit $10. You then tell the teller you would like to make a 1-euro-cent withdrawal. You pocket the euro cent and your balance is $9.99. Ask for another euro cent and your balance is $9.98. Keep going and eventually you’ll have 10.00 € (in euro pennies). Now deposit this and they’ll give you $12.50. You just made $2.50. Stand there all day repeating this and you could make some real money.

Of course, this would never work. The teller might smile and give you the first euro cent, but by the second or third she’ll know that something is up. She may not figure out your currency scheme instantly (although probably she will), but she’ll tell you to get out and stop wasting her time. But if you were working with a computer instead of a cashier, then it just might work!

The interesting thing to note here is that humans and computers have very different failure modes. There are some kinds of tricks that humans fall for easily, like those that involve distraction or appeal to authority. Whereas computers won’t fall for any trick they’ve been programmed to defend against, but if you find something they are not programmed to expect, then you can exploit it over and over.

That is why robust security mechanisms combine both computers and humans, to get the best of both worlds. Usually this means that the computers do the transaction (it’s cheaper to offer online deposits and withdrawals than it is to pay a teller to work in a branch on every street corner), but you don’t just rely on the computers to keep things legit. You also have a security team who monitor the transactions and look for anything out of the ordinary. They then investigate — usually it’s just a coincidence or an unusual day, but sometimes it is an attempt at fraud or two friends who made a bet about who could generate the longest bank statement for the month of July. Then the security department can step in.

To put it succinctly and steal a bit from Lincoln: Some of the time you can fool computers all of the time. You can fool all humans but only some of the time. Fooling both is much harder.

InputStream does not represent a valid SOAP 1.1 Message

check the namespace of the SOAP envelope

SOAP 1.1: http://schemas.xmlsoap.org/soap/envelope/

SOAP 1.2: http://www.w3.org/2003/05/soap-envelope/

What I found most interesting was something that David Pollak (the post’s author) alluded to but did not emphasize: an example of a language that has solved this problem. Surprisingly, it is the much-maligned Java. (And perhaps this feature is one of the reasons for Java’s success in “the enterprise”, where backward compatibility to old or unmaintained libraries is often a very big deal.) The Java solution is to provide an incredibly strong amount of backward compatibility at the binary level (not just the source). As far as I know, essentially all code written under Java 1.0 (16 years ago) will still compile under the most recent Java release, and code compiled by that Java 1.0 compiler will still run under the most recent JVM. The price paid is some real ugliness in the name of backward compatibility like old APIs that still return Hashtable or ArrayList instead of Map or List, and type erasure that makes typed collection less powerful than they could be). But however much you may scoff at Java for poor language design, this feat of backward compatibility is something quite impressive.

My endorsements in Bold.

Retention of Judge, Pennsylvania Supreme Court (retain or not):

J. Michael Eakin

NO, do not retain! — In 2006, The PA State Legislature voted itself a pay raise in direct violation of the plain wording of the state constitution which states. Judge Eakin was one of the Supreme Court judges who found this to be constitutional. In my mind, this makes him unfit for office, and I will vote NOT to retain him.

Pennsylvania Superior Court Judge (vote for 1):

David Wecht (D)

• http://www.wecht2011.com/
• “Highly Recommended” by PA Bar association
• Lots of academic and scholarly law work

Vic Stabile (R)

• http://www.stabileforjudge.com/about.php
• Former deputy attorney general; former judicial clerk
• “Recommended” by PA Bar association

Better qualified in several ways, I endorse David Wecht.

Retention of Judge, Pennsylvania Superior Court (retain or not):

Mary Jane Bowes

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

John T. Bender

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Pennsylvania Commonwealth Court Judge (vote for 1):

Anne Covey (R)

• http://www.coveyforjudge.com/
• Bar says “Recommended”

Kathryn Boockvar (D)

• http://www.boockvar.com/
• Bar says “Recommended”

Everything I could read paints both as decent, qualified candidates. I may cast my own vote based on party endorsement, but I cannot independently endorse either candidate.

Retention of Judge, Pennsylvania Commonwealth Court (retain or not):

Robert E. Simpson, Jr.

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Renee Cohn Jubelirer

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Mary Hannah Leavitt

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Pennsylvania Court of Common Pleas Judge (vote for 5):

Nathaniel C. Nichols (R,D)

• Endorsed by both major parties, that’s good enough for me!

Christine Fizzano Cannon (R,D)

• Endorsed by both major parties, that’s good enough for me!

G. Lawrence Demarco (D)

Sally Ann Heckert Bikin (D)

Michael F. Schleigh (D)

Spiros E. Angelos (R)

John P. Capuzzi, Sr. (R)

G. Michael Green (R)

By the time I had reached these, I had run out of energy to do my research. I really don’t know much about them and so I can’t make any recommendations except to vote for the two who were endorsed by both parties.

Delaware County Council Member (vote for 3):

Jayne Young (D)

• http://haverford.patch.com/info_page/council-member-candidate-jayne-young
• Background: Mayor of Landsdowne
• Came to speak on non-discrimination bill in Haverford.
• Issues: economic revitalization. Health department. Visit each municipal council. Transparent government.

John McBlain (R)

• http://haverford.patch.com/info_page/council-member-candidate-john-mcblain
• Background: City solicitor
• Issues: Job creation via property tax abatement for new development

Lin Axamethy Floyd (D)

• http://haverford.patch.com/info_page/h-questions-council-member-candidate-lin-axamethy-floyd
• Background: Habitat for Humanity & others. DuPont
• Issues: transparent government

Keith Collins (D)

• http://haverford.patch.com/info_page/patch-questions-council-member-candidate-keith-collins
• Background: Army, Police, Minister, Community College Prof
• Issues: transparent government

Thomas McGarrigle (R)

• http://haverford.patch.com/info_page/council-member-candidate-tom-mcgarrigle
• Issues: Economic Biz Development

Colleen P. Morrone (R)

• http://haverford.patch.com/info_page/council-member-candidate-colleen-morrone
• Works at Goodwill
• Economic Biz Development

I have seen Jayne Young “in action” and I was impressed. She was fair, articulate, and wise. I endorse her. The others I know much less about. Based on a combination of biography/background and issues, I am happy to support Lin Floyd, Keith Collins, and Colleen Morrone — and that’s one more than I’m allowed to vote for.

Delaware County District Attorney (vote for 1):

Jack Whelan (R)

• http://jackwhelan4da.com/
• Background: County Council Chair, Assistant DA

M. Kendall Brown (D)

• http://www.kendallbrownforda.com/
• Background: Lawyer, Victims Rights Organizer

Kendall Brown is simply not as well qualified for the post. She does not hold an active law license at the moment (says it’s a paperwork issue and will be sorted out). Meanwhile, Jack Whelan is competent and qualified. This endorsement of Jack Whelan is from the Delaware county democrats.

Haverford Township School Director, “School Board” (vote for 5):

Lawrence A. Feinberg (R,D)
Maxine Murdoch (R,D)
Joseph P. Martin (R,D)
Coleen Bennett (R,D)
Patricia Giambuzzi (R,D)

We have a tradition in our township of non-partisan school board elections. All 5 candidates running are excellent, and I endorse them all. Larry Feinberg in particular has done an excellent job and I believe he will continue to do so.

There really isn’t much benefit to putting in lots of hours developing a detailed estimate if the project isn’t going to proceed according to plan anyway (and it rarely does). This is why most agile development approaches — including Scrum — use a less-precise but also less time-consuming approach. By going with rough requirements, and a simple imprecise estimation process a team can produce rough estimates in a surprisingly short amount of time. The time saved writing requirement documents and producing estimates can be used to build something useful instead.

The process that I have found to be most useful starts out with requirements that are simple: just a paragraph or two written down for a feature and a few minutes discussion to make sure everyone understands it. The team meets, making sure to include someone from the “business side” who can answer questions about what is needed, the developers, QA, DBAs, and whatever other specialists are needed. The business person explains what is needed; the team talks through how they will code and how it will be tested. Then we’re ready to estimate.

Everyone just says how long they think it will take. To avoid “groupthink” where everyone just agrees with the first person to speak, it’s good to have each person come up with their idea independently before comparing: selecting cards and all revealing at the same time is one way to do this. Everyone estimates: yes, that means the DBA may estimate a Java coding task, but that’s OK. To avoid long useless debates over whether it’s 23.2 or 23.4 we usually limit the estimated sizes to some discrete values: 1, 2, 3, 5, 8, 13, 20, and “more” are a widely used set of values (the values chosen to make it easy to split a task). If, after hearing what was said we all agree on the size then we’re done (this is where we all discount the DBA’s estimate of the Java task); if not then we discuss for a few more minutes: maybe someone realized an extra step the others missed or knows where to find test data without having to enter it. If we still disagree after that, just take the larger estimate.

That’s it! It takes only a few minutes to produce estimates this way. Of course, the estimates are worth what you put into them: the business MUST realize that these are only rough numbers. A common way to do that is to estimate in “Story Points” instead of “hours” or “days”. Speaking in terms of a unit that is less concrete seems to help remind everyone that this is only a rough value. But it is a rough value that did NOT take weeks of preparation, and thus well worth it.

Look, this really shouldn’t surprise anyone who has ever done any actual science. Karl Popper had a really simple and idealistic concept of how science works: you make a theory, use it to make a prediction, run some experiments to verify the prediction, then if the theory keeps getting it right then there’s probably something to it.

Beautiful theory, but in the REAL world any experimenter spends 90% of their time trying to get the experiment to give the right results. It is actually quite challenging to figure out where the boundary is between getting your apparatus to work properly and just fiddling with it until you get the result you expected. A good experimentalist understands that boundary and spends a lot of time worrying about possible sources of errors.

That is why I think the paper that started all this furor was a GOOD paper to publish. Not because I seriously believe that neutrinos go faster than light… and I doubt that the authors of the paper actually think that either. But because it is a very surprising result, and something unexpected is going wrong here. Are our measurements of position from GPS less accurate than we think? How about the time measurements? These are the things that the paper focuses on, because they are the most important part. Not to publish this just to avoid looking foolish — that would be a real loss (and biased). So the media will just have to have their field day.

You really only have to do it for data that is not read-only. I would for example say that it’s pretty rare for classes to change after they have been set up for the first time (presumably before any threads are even started), making the class basically read-only, which could be safely shared across threads.

I wanted to give a detailed response with why this approach is nieve. Actually, it has been tried before and failed. It may work OK with certain kinds of languages (mostly “functional” languages), but fails with other kinds of languages, and Python is an extreme example of the kind of language where it won’t work.

For an example, consider Java. The JVM (Java Virtual Machine) has special features that were added to support exactly this behavior, but in practice few programmers use them. Let’s take a really simple example: suppose you create some data structure and a function to initialize it. In thread A you create the object, then initialize it, then pass it off to existing threads B and C. Threads B and C simultaneously read stuff from the data structure in ways that WOULD be dangerous except that the data structure is immutable after initialization.

The problem is that the guarantees provided in threading are MUCH weaker than you think. It’s not just that there are different threads all working at the same time and reading and writing from the same memory locations, the architecture of modern CPUs makes that impossible. You see, it takes hundreds of times longer to read something from memory or write it to memory as it takes to process something in the registers. So to execute “X = Y + 1″, the computer COULD spend 100 cycles reading Y, then 1 cycle adding 1 then 100 cycles writing X for a total of 201 cycles to execute. But that would be unbearably slow. Instead, it takes 100 cycles to do a bulk read of the whole memory area around where Y is stored into high-speed caches. It takes another 100 cycles to do a bulk read of the whole memory area aroudn where X is stored. It takes 1 cycle to add, then takes 100 cycles to do a bulk write of the memory area containing X. That’s 301 cycles… which sounds even worse.

But it’s NOT worse if the compiler cheats. Instead, it spends 100 cycles reading Y and 100 cycles reading X. Then it executes the +1 for one cycle. Then, BEFORE writing out X it does some OTHER calculations on the chunks of memory that have been read in. If the program has good cache locality (active objects are near each other in memory) it may get 75 cycles of useful work done before it needs to spend 100 cycles to “flush the cache out” (write X and the other things that were updated. That would be a total of 375 cycles to do 75 bits of work, or just 5 cycles per line — a LOT better than 201!

But in order to do this, the compiler has the “cheat”. It has to execute bits of work out of order, although it can take special precautions to make sure that it gets the same answer as if it executed them in the order written. As seen by THIS thread. But as seen by a DIFFERENT thread, the steps may appear to happen in a very different order. The other thread won’t see the effects until they get flushed to main memory, and that won’t happen after every computation (unless it is running 100x too slow!!!).

WHEW!! Big wall of text there, but the story should explain why one thread in a program may see the computations by another thread happen in a different order. So imagine this:

“In thread you A create the object, then initialize it, then pass it off to existing threads B and C.”

But imagine that from thread C’s point of view, A created it, then passed it off, and only initializes it LATER. In fact, perhaps C will start using it at the same time that A is initializing it — so it’s not really immutable, and terrible errors result. This is NOT just a theoretical risk: I have written real code that exhibited this behavior when running on a multi-core machine.

In order to help protect against this, the Java langage added a special exception to the Java threading model. Despite all other threading rules, if a class is declared “final” (immutable) and then all code executed within the constructor is guaranteed to be occur before the constructor ends EVEN AS SEEN BY OTHER THREADS. In theory, this is a great tool for creating data structures ahead of time and then reading them after initialization from other threads.

But in practice it isn’t so good. Initializing everything within the constructor of an immutable object turns out to be a real pain. Often you really want to use a hashtable (not immutable), or use Spring injection to populate your objects after the constructor, or slew of other choices that make it hard to stuff all your setup code inside of constructors. Some languages support this better: Scala and Closure are examples of languages on the JVM that use this feature well, but in Java it is awkward because there’s no little special support for working with immutable objects. Python, as a language, is even worse: there are NO immutable objects in Python! So while it might be possible to do as you suggest (create special locks and use them around every __init__ method, then carefully make sure nothing is modified outside of __init__), the resulting language wouldn’t really read like Python.

There are a few really good reasons for wrapping a library. The most important of these, is in order to add functionality or simplify use of the library. For instance, in a recent project we used Spring’s library for web service calls in order to make calls to our own company’s collection of web services. But when calling our web services, there are a bunch of things that would be nice to do. We always want the same value for the address to connect to, the timeout for the calls, and the set of headers to provide. We want additional special handling for errors wrapped around every call. Adding these features in a wrapper makes the wrapper less powerful (now it’s good only for calling our services whereas Spring’s original library could call any web service), but at the same time makes it much more useful for that one specific purpose.

I have also seen cases where the existing library had a terrible interface (API), and the wrapper attempts to make it palatable. The “Slick” library is a Python[ed] Java wrapper around LWJGL adding no real functionality but making it decent enough to use. This is a rare use case: most libraries that have a terrible interface also have lousy features and you’re better off finding a different library instead.

The most common argument that I hear is neither of these cases: the most common argument that I hear is that we should wrap the library so we can easily switch to a different library. In fact, I most often hear this from people developing in a language with strong typing, such as Java. I find this argument completely unpersuasive, for two reasons. First of all, when you switch libraries, the new library typically does not have exactly the same API. For example, when we switched to SLF4J for logging one of the reasons for doing so was that it offered a better API that allowed functionality not possible with the previous API. Secondly, if you DO switch to a library with an API that is equivalent, in a strongly-typed language you can use standard refactoring tools to perform the switch without any risk of introducing bugs. (If the APIs are close enough a simple search-and-replace for an import statement may do it.)

There are advantages to using a library directly. Developers who have encountered the library elsewhere may already be familiar with it. The documentation for the library is likely to be far more extensive than the documentation for your wrapper. It is often safe to assume that the designers of the library are better at designing an API for this feature than you are. As the library is upgraded, newer features will automatically be available. Most of all, having one fewer layers means there is simply less to learn to understand the system.

There are still a few advantages to wrapping without extra features. It gives you a place to add some logging code, or timers around an external call (for profiling), or validation checks. And there are some cases where you want to be able to use different libraries with the same codebase — then a wrapper is indispensable. Commons Logging is an example of this: it allows a library to use different logging frameworks depending on what application it has been embedded in.

So my approach to the “wrap or not to wrap” question goes like this. First of all, will I add functionality with my wrappers or will removing functionality but thereby simplify the interface? If so, then wrapping makes sense. Secondly, if I haven’t yet chosen which library to use or if I want to switch back and forth between libraries, then a wrapper will be required. If neither of these applies, then I begin with a strong presumption that I should use the library on its own, and only a real need to add logging, monitoring, or other wrapped behavior will persuade me otherwise.