I would think this would go without saying, but I just lost most of a day trying to figure out why a web service wasn’t working. One of the things I’d done was cleaned up some old code, including removing a hardcoded HTTP header value. The header it referenced wasn’t consumed anywhere in my code, and a quick smoke test indicated that, no matter what the value was set to, the client services behaved nicely. So I assumed (correctly, as it turns out) that the variable wasn’t used in locally or in any system in which we integrate, so I cut the reference out.

Rolled up the build, sent it off, moved on to other things.

QA failed the build, because one of the integration use cases was broken.

Turns out that unless that header is present, one of the methods in a client web service dies. It doesn’t matter what the value is, but it has to be there, or the web method chokes.

So, moral of the story: make sure that all your variables are really needed. Make sure they they mean something and cut out any variables which aren’t required. This is especially true with integration situations like those found in web methods.

I browsed to the folder specified and confirmed that the executable was there. I checked my path to the Android SDK and it was correct.

After futzing around for a little while I instructed Eclipse to clean all projects in the solution. As soon as I did that, my firewall (COMODO) popped up a warning that Eclipse was trying to access aapt.exe, which was an unknown executable. I selected “allow” and, after Eclipse cleaned and rebuilt the project, the errors went away.

So, if you run COMODO and you get funky errors from Eclipse about not finding SDK components, clean your solution. If that fails, check your firewall settings to make sure that those executables aren’t being blocked.

It’s definitely shaping up to be a great resource.

Article 0 – Intro

Article 1 – Hello, World

Hey, just wanted to post a quick follow up to my post on Sugru. Pete, in comments, points to the fact that it’s now on sale again. I will definitely be getting some. Hackers of all kinds and stripes should hie themselves to the Sugru site and do similarly.

The video’s good, but it takes as given one thing that programmers all take for granted, but that many other people don’t understand: a 5-minute interruption costs us way more than 5-minutes worth of productivity. It’s not simply that talking to someone for 5-minutes is 5-minutes less that we’re working, it’s that (and Giles mentioned this in passing at one point), it completely wrecks our train of thought, our focus, our motivation, our strategy, and our tactic. They all get completely obliterated. Building these back up takes time; often hours of it.

One other thing that he might have done well to mention is the fact that many of our interruptions (or at least mine) are interruptions that I generate myself. I am habitually self-distracting, especially if the work that need to get done is boring.

The video is excellent, though, and highly recommended. It’s a much-watch for anyone who is a programmer, works with programmers, manages programmers, etc.

This stuff looks crazy awesome. It’s called Sugru and it’s a moldable, putty-like substance that dries into a high-strength silicone. I love the idea, and I love that it’s being marketed precisely to people who like to hack things. Alas, it’s sold out at the moment, or I’d be buying some right now. I can think of at least a half dozen projects for which this would be perfect. (E.g. custom-fitted, cushy silicone recoil pad!)

Can’t wait for them to get more in stock.

I love that this product explicitly combines two of the things that I think are poised to help revolutionize our culture and our world: the hacker ethos and material science. Now maybe (read: definitely) this is starry-eyed utopianism on my part, but the more people who internalize the idea that they can and should hack their stuff, their world, and themselves, the better. I think that being a hacker speaks to one of the primal elements that makes us human. I think that a far better descriptor for us than “man the wise” (homo sapiens) is “man the hacker” (homo textor? Homo abetor?)

So now combine that hacker spirit with the fact that our fundamental understanding of how materials really work is just starting bear some really cool fruit, and the future begins to look pretty damned awesome. See, we, as a species, moved from the stage of using ambient materials we found around us (flint), to reproducing materials that we first created by serendipity (bronze), to fine-tuning those serendipitous materials (high-carbon steel). But it’s only recently that we’ve gotten to the point where we can actually design materials to achieve the properties we want. Sugru is one such designed material.

So human-designed materials that are explicitly targeted to the hacker soul in each of us. How awesome is that? Rhetorical question. The answer is, of course, “insanely”. Better (non-rhetorical) question: when can I get my hands on some?

N.B.: I performed the above steps with (I believe) a porter. Not sure what kind. Not sure if the variety of beer matters.

Also, this post is just one man’s method. My phone weathered it fine, but yours might not. This will probably void your warranty. It might destroy your phone. Hell, it might give you scabies or an unhealthy obsession with the Beta Band.

Whatever happens, you undertake the above steps at your own risk. I make no promises, guarantees, avowals, or assertions as to the safety and efficacy of the above method. If you mess up your phone, it’s on your head.

I will, however, say that my battery cover still stays in place quite nicely.

I do, however, have a few posts in the works about a variety of things; Quines and the CLR and hacker drama, oh my!

So stay tuned. But while you’re staying tuned, here’s an intersting quandary:

So the game Flood-It (to which I’m fair addicted) has recently been proved NP-Hard. The game is fairly simple. From the abstract of the linked article:

“In this game the player is given an n by n board of tiles where each tile is allocated one of c colours. The goal is to make the colours of all tiles equal via the shortest possible sequence of flooding operations. In the standard version, a flooding operation consists of the player choosing a colour k, which then changes the colour of all the tiles in the monochromatic region connected to the top left tile to k. After this operation has been performed, neighbouring regions which are already of the chosen colour k will then also become connected, thereby extending the monochromatic region of the board.”

So my question: what constraint of the above problem, other than finding the shortest sequence, could one relax or eliminate to move this problem from NP into P? I strongly suspect that, were a player allowed to choose their starting square after having seen the initial board coloring, that all board configurations would be solvable in P. I haven’t proved this yet, though, so I may very well be wrong.

Thoughts?

a(n) will not grow larger than 5 for any number which can be written in the physical universe.

An example of an algorithm that demonstrates this is Chazelle’s algorithm for minimum spanning trees [pdf], which is O(e*a(e,v)) where e is the number of edges in the graph and v is the number of vertices. So it’s functionally O(e), but not quite.

Interesting, if useless.

The eval method is a staple of scripting languages.  It takes a string and executes it as code.  This is useful when, e.g., you need to modify the value of one of several text fields on a page.  The name of the text field can be dynamically passed into the eval argument.

So C#, being a compiled language, doesn’t have an eval method. What it does have, however, is great support for programmatic compilation of code. This can be used to hack together something that’s kind of like an eval. Take, for instance, the following method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

        public static void FauxEval(string codeToEval)
        {
            //Create compiler objects
            CSharpCodeProvider Compiler = new CSharpCodeProvider();
            CompilerParameters Params = new CompilerParameters();
            CompilerResults Results;
 
            Params.GenerateExecutable = true;
            Params.OutputAssembly = "eval.exe";
 
            //We could check this Results object, but this is naught but an example
            Results = Compiler.CompileAssemblyFromSource(Params, codeToEval);
 
            //Execute the eval-ed code
            Process evalledExecutable = new Process();
            evalledExecutable.StartInfo.FileName = "eval.exe";
            evalledExecutable.Start();
            evalledExecutable.WaitForExit();
        }

This method takes the C# source of an executable as its argument. It compiles the source and executes it. Now this is kind of like an eval. It’s more structured than that found in a scripting language, since it can only eval code that compiles into a valid C# program. The heavy lifting is done by the CSharpCodeProvider class, which handles the compilation of the source. This class also contains a lot of handy methods to generate code from various CodeDOM objects, making it your one-stop shop for C# metaprogramming. (N.B. There’s a comparable class for Visual Basic called VBCodeProvider. This is exceptionally handy if, for whatever reason, you want to use C# to emit Visual Basic code.)

So the above FauxEval method can be used simply by assembling a string that will compile into an executable. The strength of eval-like methods, of course, is that this string can be constructed dynamically at run time. As a completely trivial example, here’s a program that uses the above eval to generate a Hello World-like program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

 
        static void Main(string[] args)
        {
            string programMessage = "Hello, world!";
            if (args.Length > 0)
            {
                programMessage = args[0];
            }
            string programCode = "";
            programCode += "using System;";
            programCode += "using System.Text;";
            programCode += "namespace GeneratedCode";
            programCode += "{";
            programCode += "class GeneratedProgram";
            programCode += "{";
            programCode += "static void Main(string[] args)";
            programCode += "{";
            programCode += "Console.WriteLine(\"" + programMessage + "\");";
            programCode += "Console.WriteLine(\"Press any key to continue...\");";
            programCode += "Console.ReadKey(true);";
            programCode += "}";
            programCode += "}";
            programCode += "}";
 
            FauxEval(programCode);
        }

The generated program will simply print the first command line argument to the console. If no argument is provided, the executable is built to be a default “Hello, World”.

The results:

(Click to embiggen)

So that’s a super-simple C# eval. This provides the ability to execute code that’s been dynamically created at run time, provided the code can be compiled into an executable. There’s a lot of room to expand on the method and make it more flexible and general, but there really is only so much you can do with this strategy of code evaluation, since the code always has to be able to be compiled into an assembly. Still, it’s a damn sight better than nothing.

Update 2010.3.30: I removed some random debugging code from the Eval method above. It was a classic case of YAGNI. I thought I might want to dump eval string contents to a file. I ended up not needing to, but then forgot to pull the debugging code.