Bill C61 notes

So I have a great personal distrust and disgust in the way copyright law has continually degraded and been abused by large corporations over the past 30 or 40 years . (Thanks Mickey!) I cringe at the idea of the RIAA sueing people to protect their broken business model and laugh my ass off when bands like Metallica (2) and Kiss make total asses of themselves while those artists that are still relevant embrace new ways of engaging their fans. Anyway, that's the context for this post. I am legitimately interested in seeing how Canada will follow other countries in protecting artists, content producers and consumers.

As much as I abhor the record industry I do think the law should reflect the reality of the new digital landscape. Content creators need to be protected, and consumers should get their money's worth when buying or consuming copyrighted material.

Anyway I watched these videos about the new Bill C61, and as painful as it is to listen to Jim Prentice repeat the same meaningless quip over and over in response to these questions, I did find it interesting. I've been really concerned about Canada following in the steps of the DMCA, and I imagine that under the covers this is largely similar, particularly where "digital locks" are concerned but I've so far not heard anything really terrible.


http://www.digital-copyright.ca/node/4761  (videos)

Some highlights from the videos

• Need for international cooperation, if it lets me watch more movies online for cheaper then going to the video store then yeah let's go. How long has that been possible in the US?
  
• "and of course new technologies such as mp3 players and memory sticks" I just included that because it struck me as funny.
  
• Time shifting and format shifting is preserved
• BUT "digital locks" which are chosen by businesses (ie stopping format shifting) will be legally enforceable and will allow those time shifting and format shifting rights to be circumvented
• Having personally already rented videos on iTunes I can see some benefit to these locks and some of the new models they enable (death to blockbuster)
  
• Also though owning a bunch of iTunes tracks I can't use on other devices makes me hate the locks. But ultimately this is my decision on what to buy so I can't complain too much. It's important to let the market decide on some of these issues I think. Although how much of a market is it really when there are only a handful of really big labels and studios producing all the content?
  
• no liabilities for ISP's is great I think
  
• New limits on the liability for "personal use" of copyrighted material to $500 PER INFRINGED WORK  (they kept playing up $500 limit as a good thing for consumers but it sounds like downloading 4 movies is still a $2000 hit)We all know how quickly this would completely sink most households.  In Prentice's example this goes from five videos at $20,000 each  = $100,000 to $500 total... he didn't seem to really have that part down and I'm still not sure if it's $500 per work or per incident or whatever?
• Not that that matters as this is totally unenforceable, the law will enable companies to more confidently invest in delivery mechanisms that rely on locks and have a clearer understanding of rights, but none of it will help anyone actually enforce it. (Unless the companies do it themselves ala the RIAA sueings)
  
• This whole bill was rammed through right at the end of summer with little consultation, seems ugly
  
• When timshifting you can't store those as a library of recordings, again very vague and would seemingly limit PVR software quite a bit.
  
• You can't import devices into Canada that enable bypassing locks (vague, could encompass a lot of devices )
  
• Teenagers seem to be the "they" in all these videos. Makes the questioners and the lawmakers seem out of touch. I understand teenagers are big offenders but they are by far not the only ones.
• What are the whitewood treaties Mr Prentice brings up? I'm assuming I didn't hear him because I didn't see anything on my initial Googling of it.

The business network video is the best video of the bunch, if you want a summary just scroll down and watch that one.

One of the things I was most surprised to hear was from Mr. Sookman saying that time shifting and format shifting is currently NOT legal? Really? I had always been under the impression that this was actually legal in Canada.

Check out this website for more information on Bill C61
http://www.digital-copyright.ca/

Enough rope to hang yourself (C# Extension Methods)

So I ran into an interesting "gotchya" with C# extension methods tonight. And of course it happens at the 11th hour on a project that is being demoed at 9:00am tomorrow morning. Of course.

Extension Methods

Extension methods are a really cool new feature of C# that were introduced in version 3.0 of the language. Essentially they are static methods that act like instance methods, allowing you to extend objects you don't own. Ok, seeing those words on screen makes me think this is a terrible idea, but it really does have it's place. (LINQ relies heavily on it)

When I first saw these I got quite excited because we had a number of scenarios where they would make our code much much cleaner and easier to maintain. I can name a couple examples in our own project where this has the potential to make the API cleaner.

Example 1: Helper/Utility/Static Methods

Try as they might, the .NET framework guys will not anticipate every piece of code that ends up repeated hundreds of times across your project to get around a common case. Before the framework added String.IsNullOrEmpty() in 2.0 we had StringHelper.IsNullOrEmpty(string arg)in our code base along with about half a dozen other methods. Now string may not be the best example, because in my mind I think it's a bad idea to write extensions to framework types, but it does illustrate the problem well.

In our project we have maybe a dozen of these Helper classes full of static methods (utility pattern). They are useful, but the biggest problem is the team's ability to consistently discover those methods. Emails and other forms of communication helps, code review helps but ultimately you end up with repeated code fragments where helpers could have been used or even worse you end up with competing helpers in different namespaces that need to be consolidated once discovered.

Example 2: Enhancing Functionality Based on Context

Another useful place for extension methods in our project is to have our domain model be extended differently based on the area of the application and what rights the users executing that code have. Essentially what we have is two sets of functionality that are implemented very differently based on the context. For example in one context our object model is mapped using an ORM to the database directly, where as in another context that same object model is used with pre-populated data sets that are cached and completely scriptable by our end users. We still have code that needs to understand these objects across this context however, leading us to create interfaces for every single object in that domain that needs to work across these two contexts. I'm a fan of interfaces, but I think in this scenario we've clearly lost something in terms of the DRY principle and code readability.

I've yet to really map out what this will look like for our project, but I see what's been done with Linq and am excited about how simple it could be for example to include the ".Scripting" namespace to attach methods to our domain model that are exposed to end users. Similarly an ".API" namespace for our internal privileged code base with everyone sharing the same core objects.

The Gotchya that kept me at work an extra hour

Symptoms

• Your extension method is no longer ever being executed

• Intellisense shows the correct method signature, reports no problems
  

• Right click "go to definition" takes you to the method you think will be hit

• Stepping through the code shows you never reach your extension method

I've created some fake code to illustrate the problem. Imagine we have a simple factory class providing some useful functions like so :

namespace ExtensionMethodsTest
{
public class FactoryA
{
public ObjectA GetInstance()
{
return new ObjectA("empty object", -1);
}

public ObjectA GetInstance(string name)
{
return new ObjectA(name, 0);
}
}
}

But then we decide that we actually need to grab instances of ObjectA using an int id, so we add that using an extension method like so :

using ExtensionMethodsTest;

namespace MyExtendingNamespace
{
// a container for my extensions
public static class ExtendFactoryA
{
// Extend our factory to look objects up by id
public static ObjectA GetInstance(this FactoryA factory, int id)
{
return new ObjectA("got by id", id);
}
}
}

Blamo! Now anytime we're using the "MyExtendingNamespace" our FactoryA includes the third way to grab an instance of ObjectA.

Here is how I am calling both of these :

private void ByIdButton_Click(object sender, EventArgs e)
{
FactoryA fa = new FactoryA();
ObjectA a = fa.GetInstance(42); // call extension method with int
this.label1.Text = a.ToString();
}

private void ByNameButton_Click(object sender, EventArgs e)
{
FactoryA fa = new FactoryA();
ObjectA a = fa.GetInstance("gotten by name"); // call instance method with string
this.label1.Text = a.ToString();
}

This seems ok, our calls to GetInstance are consistent and we have everything working. Now transplant yourself a couple months into the future when the original owner of the FactoryA class has a need to alter the behavior to allow for more scenarios for retrieving instances of ObjectA.

public ObjectA GetInstance(object proxyObj)
{
return new ObjectA(proxyObj.GetType().Name, 0);
}

Now from the calling code everything still appears to work fine, intellisense continues to show the "int" signature that you think you are calling, and in fact if you right click the GetInstance call and say "Go to Definition" it takes you to the MyExtendingNamespace version of GetInstance.

At runtime however the CLR looks first for something that matches your call to fa.GetInstance(42); within the main namespace/class before looking at any extensions. Because our int gets automatically boxed we actually match "object proxyObject" and will never reach the extension method. Depending on the specific implementation in your code this can be a particularly insidious error or it may fail outright. Either way on a large project it can be a real annoyance to track down.

To me there are a few mistakes here. 1) Why use an extension method here at all? 2) In general I think extension methods as overrides make little sense given how the CLR matches these and 3) GetInstance(object proxyObject) should probably be something more specific like ProxyBase or something else that is not an object. (Akin to catching System.Exception, bad... be specific)

Fixing this issue is as simple as renaming the extension method to GetInstanceById, or moving the method onto the Factory itself, or fixing the factory method to not use object. Personally I say drop the extension method.
My example is over simplified, and in our scenario at work there was a little more justification for not changing the class that defined the original functionality. To me though this seems like the tip of an iceberg of problems.

• Why negotiate with a module maintainer when I can just add functionality right here right now from my own code?
  
• Why stop to understand that class and how it's been constructed when I can just impose my view of how it should work overtop?
• Intellisense makes it easy to find the method, so I don't have to worry about how I organize this code.
  

Terrifying.

here here - use var sparingly

When I first read Jeff Atwood's latest post on his love of C#'s new "var" keyword I was deeply bothered that my co-workers would find the article and latch on to the argument as a justification for laziness. While I do understand his point of view I was bothered by the idea of var statements littered throughout the code base making things more difficult to read for the next developer.

Saving key strokes is never justification for obscuring the code base. If you want to save keystrokes improve your environment, don't sacrifice your code.

I came across this post on reddit tonight that very nicely counter's the post on coding horror. Thanks Richard for a voice of reason.

http://richarddingwall.name/2008/06/21/csharps-var- keyword-jeff-atwood-gets-it-all-wrong

Dynamic vs Static... no wait make that DBC!

I need to blog this basically to toss it in my archive. There have been some interesting posts on the religious debate of static vs dynamic languages. I don't know why I always get drawn into these lines of thought, but I do. (in fact I just added a "versus" label)

I say drawn in because my underlying philosophy in all of these things is to choose the right tool for the job and leave it at that. I know, hardly original thinking, but despite the mantra and the collective nod that this is true we still get very heated on issues that are not actually at odds with each other.

I'm NOT arguing that with you. I'm not arguing that with YOU. I'm not ARGUING that with you. I'm not ARGUING that with you Harry! Harry... Harry... Yeah Harry... but can he DO the job. I know he can GET the job but can he do the job?

Mr. Waturi, Joe vs the Volcano

Still there is fun to be had in the whole exercise. For the record I tend towards the static languages. Despite my recent fun with Python I have spent the last four years neck deep in C# and really am loving it. Our application uses over 75,000 lines of JavaScript, and every opportunity I have to decrease that number I will take. (Part of my excitement about Silverlight is just not having to write as much JavaScript anymore) I see the power in dynamic, I've done some really cool things with JavaScript and I've really enjoyed working in Python again.... but I believe there is less of a ceiling for static languages then there is for dynamic in terms of tool set, performance and the ability to handle large projects with large teams.

Anyway, Mat Podwsocki presents a great summary of the debate with links to a few bloggers here :

http://codebetter.com/blogs/matthew.podwysocki/archive/2008/05/28/static-versus-dynamic-languages-attack-of-the-clones.aspx


The original Steve Yegge presentation is here :

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html


And the response that I enjoyed the most is here :

http://codebetter.com/blogs/gregyoung/archive/2008/05/18/revenge-of-the-statically-typed-languages.aspx


I enjoyed Greg's response because it just really got me thinking. I honestly know nothing about the design by contract research that's going on, but it just feels like something that makes sense. I got excited just imagining seeing errors like the ones described showing up in our project at compile time. I believe that if we were using such a system we would see a real improvement in quality. I can see how some would see this as an unnecessary burden on the developer, but these are probably the same crowd not writing their unit tests.

Design by contract is really a great example of what I mean when I'm thinking about the potential for statically typed languages in tool sets.

Gadgets in Blogger

So I've actually started my blogquotes project which was intended as a widget style provider for random quotes (from a personal library) to appear somewhere on my site. I'm using the new Google app engine for this project and so far I have to say it's pretty damn easy. From barely knowing python to having a django templated, gql driven tiny quote engine. Granted it's the "hello world" of web apps, but still considering I have an application running on Google, with built-in authentication and datastore .... I'm pretty impressed.

I've played with ruby on rails before, but so far I'm far more comfortable with what I'm building here than I ever was with Ruby. (I don't think I'll start detailing that here and now as this post is more about my gadget plans and I don't care)

So I have my application, and I have the beginnings of the backend for my quote providers. I just went to draft.blogger.com where google tests out new features and clicked "add gadget" from the layout view of the blog. I actually thought that what I was looking at was a mistake. 43,000 page elements and gadgets? How is that useful to anyone? How am I not just making the problem worse by adding another one that no one will find and no one but me will use? This is just insane.

I did a search for quote on that page and it returned 13, thankfully none of them are what I have in mind. They are all basically syndication style "[fill in topic] quote of the day" style widgets. There actually seem to be a surprising number of gadgets like that. Things that just don't really allow the user to add anything meaningful or contextual to the web. I suppose a lot of people use their blogs as their home page, but for me having the weather and a stock ticker on my blog just doesn't make sense. My Google home page sure, but on millions of public blogs not so much.

There also seems to be too many thinly disguised marketing devices and cheap looking ad-style nothing widgets. Personally I would like to see more of the types of gadgets that Google themselves are creating, where user generated content is the focus (my youtube videos, my picasa albums, my google docs etc) as opposed to content that is one size fits all for millions of blogs. At least it gives me some hope that what I'm doing is not a complete right off.

The data won't stick, but if you have a google account you can log in and add a quote to the pre-alpha-hello-world-version of blog quotes at http://blogquotes.appspot.com

Google's changing the rules again (appspot)

I am super excited about Google's recent foray into cloud computing, the app engine. They are not first, I realize Amazon has been doing some pretty cool things with the S3 services and their computing services but the ability to simply and easily have an application that can leverage BigTable and GQL, google account authentication, image manipulation, memcache and having that all live within the seemingly infinite scalability of the google platform is extremely exciting for me. In fact it's the whole reason for my recent resurgent interest in python. App engine out of the gate is a python runtime environment which is robust enough even to run frameworks like Django for your web apps.

ArsTechnica had some good comments on the service and one of their cheif concerns was being locked into the platform. I think this is not an invalid concern, but that the tools will be written to make migration from one platform to another a relatively trivial matter. From what I understand of GQL it is a subset of normal SQL with limitations like no joins which should make data/code migration easy, but scalability and hosting maybe not so much. There are open source implementations such as HyperTable which is modeled after Google's data platform, but ultimately the article is right. Personally I don't see myself writing large scale applications on this platform though, I see this much more as a utility model for small useful services.

I registered for the preview of app engine on the same day it was announced but not early enough to be one of the lucky first 10,000. When I did get my invite a couple weeks ago I immediately started to create applications. It's clear this is exactly what everyone else did and I'm glad Google has capped usage at three applications per developer. Already it's almost as bad as trying to register a domain. For each of my three applications I had to try a series of names before getting a clear one. In other words none of my ideas are at all unique. :-) On a positive note when I checked the names I was looking for there were also no uploaded applications for any of them. I predict Google may have to have an expiry date on these - I can see myself taking weeks or months to finally get anything uploaded.

http://silitrader.appspot.com (silverlight port of the old game OilBaron)
http://wherediditallgo.appspot.com (personal spending tracker)
http://blogquotes.appspot.com

I actually created that last application as I was trying to find a simple means of having a rotating list of hand picked quotes show up in the header of my blog. Back when somatose.com was hosted with LunarPages this would have been trivial, throw the quotes into a textfile, write a script to randomly choose and insert one as I was building the page. I moved from a hosted environment to using blogger so that I would stop tinkering and focus on actual content. I spent most of tonight tinkering though, building up to actually building blogquotes. (By the way I am sure there are other blog quote like tools out there, but this is a rare case where I don't mind reinventing the wheel somewhat)

Now the nature of the tinkering has just changed. Rather than write a small shell script that spits out random lines I will actually build something of a small application/service. The quotes will be stored using the datastore api (GQL), and will be publicly visible. Other users will be able to authenticate and store their quotes in a similar manner. A widget will be built and hosted from that application that enables anyone to paste in a snippet of html to add random quotes from their personal db. I as a user can subscribe to my friend's quotes. It's remarkable really, the differences and yet familiarity of this new ecosystem. And while I do miss the control of simply writing a little shell script I have to say I love the idea of the internet being populated by these little widgets of functionality. The emergence of ajax and increasing power on the client means that millions of non-technical users who blog on platforms like blogger and wordpress can very easily use my quote engine. How cool is that?

Google's API's (and Amazon's) are proving to be the next Win32. Massively widespread and base functionality that anyone can build on. The plumbing is there for us to be able to chain together these small tools/widgets in much the same way a clever unix user could within their shell. And once the honeymoon wears off and I actually give some though to hosting data in the US and dealing with popularity should one of my apps get hammered and I end up having to pay Google usage fees... well until all those little issues I can just be excited again about the changing landscape.

Moving to the interior

The promise of the electronic office has been so damn close for so damn long now. I know there are thousands and thousands of people out there who now work primarily from home, but I remain on the outside looking in. (or inside looking out?) Visions of a city like Nelson or maybe Prince Rupert dance in my head, with me in my large solitary office overlooking the lake, hardwood everywhere, the distant sound of my daughter playing outside. <deep virtual breath> My neural implants connect me to the office at "ludicrous speed" and my Neo-like abilities make distance immaterial.

Reading reddit too much can make you paranoid (and slightly dysfunctional, and unproductive, and slightly dumber) and these days I'm thinking too much about the impending collapse of our society and my desire to get the hell out of dodge before it happens. Preferably a nice small mountain town on a lake here in BC. Somewhere I can grow and fish/hunt food if the shit hits the fan. Somewhere where I'm not spending 40% of my income on housing. Of course, the idea of me hunting is almost enough to make me cry with laughter... I am so not a hunter.

Anyway, this post is about robots not the apocalypse. There are a few robots now intended to make the awkward ritual of sitting around in a board room and talking to a TV a little more awkward by having the TV come see you! Wonderful wonderful idea, and I'm sure extremely fun for the remote worker. A little less fun for the nervous employee constantly watching their backs for this thing to roll up behind them.

I can't imagine this thing not having kick-me signs and other paraphernalia hanging from it within minutes in mockery of the whole process. I also can't imagine being the remote worker and resisting the urge to roll around the office all day looking for interesting things to see. I think an episode of the office where Michael gets one of these would be brilliant and the comedic geniuses on that show could have some fun.

This isn't what I normally consider a robot because it's not autonomous, but it's still cool, and if it helps me unplug from the city while staying connected to work I love it.

Giraffe video conferencing robot to weird employees out - Engadget

HeadThere - the maker of the Giraffe

Do I really need to embrace C++?

My internal debate rages on... I have some C++ courses in the pipeline so I will definitely learn more than the basic understanding/grasp I have now...

Still though. Currently I associate C++ proponents with old-school attitudes on the need for absolute control and a fear of newer levels of abstraction that are allowing increasing complex and large projects. Garbage collection, the .NET framework etc, are all grouped together into a category of tools that only "weak" programmers need. I recoil pretty hard from this line of thinking and associate it with a dangerous cowboy like attitude towards engineering.

There is a lure there, to join the elite, to be one of those cowboys who don't need frameworks or garbage collection and who's code can scream past yours with sheer force of will by the programmer. So I'm constantly torn between mockery and envy. I will say that I think it's important to learn and think in C++ because the deeper our understanding of the systems we develop for the better off we are. I'd say the same thing about assembly though and would be just inclined to write large systems in C++ as I would in assembly.

My own line of thinking is that these abstraction layers we've invented are more akin to compilers and file systems and OS API's. Why should we all re-invent the wheel (and poorly) when these problems can be solved in a generic way?

Anyway C/C++ are probably not going anywhere and have their niche, but I thought I would post this article to preserve it in my memory bank.

http://www.mistybeach.com/articles/WhyIDontLikeCPlusPlusForLargeProjects.html

Power Consumption

I'm a graphing junkie, I have to admit it. So I was pretty pleased to discover that my power company (BC Hydro ) provides some interesting consumption graphs for month to month kilowatts per hour usage. I'm pretty sure my meter is only read every two months so some of the resolution is lost in this, but still it's helpful.

One of the more striking trends I've seen in the data has been the birth of my daughter. Late nights, tons more laundry, cooking and heating bottles and leaving fans on so she can sleep. Power consciousness kinda goes out the window while we're dealing with an unhappy Maggie.

Summer should see the trend reverse and then I think we'll have to get creative in terms of keeping it down.

Some Not So Initial Python Impressions

Years ago I tried Python and instantly rejected it based on the imposed syntax rules of how whitespace was treated. To me this was a terrible idea and didn’t actually mesh at all with my sense of how my code should look. At the time I was doing a lot of Perl hacking and had a vested interest in what I had already invested in that platform.

Then I guess about a year ago I looked again at Python, this time with a new appreciation for the readability and perceived robustness of the language (not to mention a surging community). Having at this point spent time managing projects with multiple team members I had a new found respect for Python’s goal of having one obvious way to do something as opposed to the freeform nature of Perl or JavaScript (which I had a lot of experience with). I dabbled but still had no real work to do and so my foray didn’t go a lot further than to install PyDev for eclipse and create a few small test programs.

Third time’s the charm and this time around I’ve decided to make Python the back end for my new Silverlight application which I hope will assist in hosting it on Google’s app engine platform. [link to my own article]

I lost an hour or so dealing with Python terminology with “Module” vs “Package” vs “Class” so I thought I would write my thoughts. I was approaching my code thinking of classes as 1 per file where the filename and the class name match.

So I had the following structure for some initial classes:

Once I figured out how the __init__.py files worked and how to import properly then I had the following in my “__init__.py” of the GameEngine package:

__version__ = '0.0.1'

__all__ = ["Board","BoardPiece","BoardPosition","Player"]

Then in my test driver I had :

import os

import sys

from optparse import OptionParser

from SiliconTrader.GameEngine import *

#(OR)

#from SiliconTrader.GameEngine import Board

def main():

parser = OptionParser(usage="""

Testing program for the GameEngine classes, basically a throw away class for

learning some python....

Usage: %prog [options]

""")

board = Board()

board.helloBoard()

if __name__ == '__main__':

main()

And no matter what I tried in this case creating a new “Board” instance was always failing with the following error:

File "TestDriver.py", line 15, in main

board = Board()

TypeError: 'module' object is not callable

Being new to Python and without an internet connection (on holidays) I assumed my class was improperly defined, and then I assumed it was something to with reference paths. It was easy to prove the reference paths were fine as that will produce an entirely different error message. I played around with various incarnations of my class, including adding an __all__ = [‘Board’] to my Board.py file all to no effect.

Eventually I realized that I had created a module named Board and a class named Board and this is what was causing the error. Simply adding another “Board” to the reference in the above main statement fixes the problem (like so):

board = Board.Board()

board.helloBoard()

But that sucks for obvious reasons, so I re-ordered my packages and created modules that contained more than a single class so that I didn’t have to reference classes by a module name that matched the class.

So here’s an attempt to be more Python like:

Note that those green C icons are classes defined within the modules. This is a feature of the PyDev eclipse plugin and these the classes within “Model” above are all just in one text file. This isn’t terrible but it’s not ideal either, I can’t say I really like having all these classes defined in the same file, but the IDE makes things easy to navigate so until I see something easier this is how it will be. The import and creation code now looks like this by the way:

from SiliconTrader.Core import Model

from SiliconTrader.Core import Engine

#....

board = Model.Board()

board.helloBoard()

#....

I could have easily retained the * import but this is generally frowned upon and now that I am actually importing a set of classes with each line it’s much more inline with how I would want this to work.

Anyway, this is probably not something most people will get caught on, but coming from my daily C# existence I found this all a bit weird. Still easier than dealing with ruby classpaths though.