Tag: Programming

Avoidance

I’m solving a variation of the Knight’s Tour Problem [1] with a little home coding project. I know the best way to solve this problem is a recursive function call. I also know the problem I’m trying to solve has three times the number of possibles at each stop. It’s a damn hairy recursive function.

So I spent several hours trying to solve it non-recursively.

You know what’s hairier than a hairy recursive function? Trying to avoid writing that hairy recursive function. A lesson I keep learning over and over.

[1] https://en.wikipedia.org/wiki/Knight%27s_tour

Linq fail

My favoritest thing about Linq is that no one around here writes it natively. It always ends up in the code base via Resharper translating a block foreach and if/else statements. It looks awesome and is totally terse. Unfortunately, whenever you need to refactor that Linq statement the first thing you end up doing is rewriting it as a block of foreach and if/else statements.

So, basically, it’s less than worthless as a paradigm. Unless you’re trying to impress people doing the code review…

Punt!

ESPN is locking down their public API effective December of this year. While I never did more than plonk against it, that was because the functionality was exceptionally limited. I understand that they’re sitting on a goldmine of stats and information but there is a whole mess of potentially awesome applications that could be developed if that information could be tapped for non-commercial usage. I had hoped that ESPN would see itself fit to broaden the functionality over time.

Instead, I got this via email today:

Dear ESPN API Developer,

Since the launch of the ESPN Developer Center in March 2012 the capabilities and direction of our API program have continued to evolve in order to serve sports fans in the best way possible.

As part of that evolution, we have made the difficult decision to discontinue our public APIs, which will enable us to better align engineering resources with the growing demand to develop core ESPN products on our API platform.

Effective today, we will no longer be issuing public API keys. Developers utilizing the ESPN API with a public API key may continue to do so until Monday, December 8, 2014, at which point the keys will no longer be active.

We want to thank you for supporting the ESPN API, and we hope you found value interacting with the service over the past two years.

Boo!

Developer mind

“OH HAI! The process to perform incremental testing is taking several minutes per iteration. This sucks! Automate this!”

“Automation totally rocks! The process to perform incremental testing is now only about a minute.”

[some period of time lapses]

“OH HAI! The process to perform incremental testing is taking a whole minute per iteration. This sucks! Tune the test harness!”

“Automation tuning totally rocks! The process to perform incremental testing is now a mere 30 seconds!”

[some period of time lapses]

“OH HAI! The process to perform incremental testing is taking a whole half a minute per iteration. This sucks!”

[…]

Lesson: If left to my own devices, I’ll spend more time tuning the testing process than developing the code being tested because it feels more wasteful to do otherwise.

Funner than it looks

A thing I’m working on is supposed to interact with a Scheduled Task [1] if it exists. Instead of writing out my own parser for this backwater of the Windows operating system I found something lying about at CodePlex [2]. As far as documentation goes, this one is pretty decent [3]…for a CodePlex project. Then again, that bar is pretty low.

So this afternoon has been brought to you by the method Console.WriteLine()

Don’t know what a thing does? Console.WriteLine( THING ) is great. If it’s a string, it’ll tell you what it represents. If it is something else, it’ll give you a clue as to how that method/object reference is employed. It’s nowhere near as cool or useful as Python's dir() [4] which is what I was really jonesing for this afternoon. Still, half an hour of iterating over Console.WriteLine( THING ), compile, run test executable made quick work of finding a solution.

Eventually I found Microsoft.Win32.TaskScheduler.Task.Definition.XmlText and this all the bait I need to make this an XML-based solution. Why use an object wrapper with moderately unhelpful documentation when you can just do a simple XPath operation? Pretty sure about half of the solutions I come up with eventually dump into XML and then leverage XPath. It is the very best hammer because it can turn virtually anything into a nail.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa383614%28v=vs.85%29.aspx
[2] http://taskscheduler.codeplex.com/
[3] http://taskscheduler.codeplex.com/documentation
[4] https://docs.python.org/3/library/functions.html?highlight=dir#dir