An Open Letter

For too long Google, Facebook, and Twitter have defined the marketable social experience on the Internet.  Like the highways of Brazil, they have lined as much of the Internet that they can with clickable billboards; pushing products and services they think are most likely to grab an errant click.  With the blessings and adulation of so called "thought leaders," they have attempted to rule over us as so many peasants.  In fact, peasants is too kind of a term.  They see us as their property, their cattle; mechanically picking apart our preferences, our relationships, and even our private thoughts, in order to maintain their increases.  A corrupt politician would be proud of their methods, deviously misdirecting all inquiry, while carefully preserving the facade of "Do no evil."  Even further evidence has shown that they are pursing their goals with a sinister delight, believing in no privacy but their own.

Factually, the list of grievances is almost innumerable.  How many breaches of privacy have there been?  How many rogue employees watching us in secret?  How many archives that have secretly leaked to advertisers?  How many people censored?  How many client businesses have they killed?  In the end, how many times have they sold us?  Millions?  Billions?  Trillions?

Enough!  We shall be slaves no longer!  While the Internet is still a free network, there is another way.  There is another land on which we may build the future.  A land where we are not cattle, but customers.  A land where we own our data, and our privacy is sacrosanct.  A new frontier, being blazed by sites and services such as App.net, DuckDuckGo, and Fastmail.  We are being calling to join them in building a new world.  A world, where for the price of a fancy coffee per month we can be secure in the fact that we no longer need to suffer information abuse.  A world where we can be sure that our information is our own, and we can do with it what we will, including delete it permanently.

Therefore, today I am going Galt; deleting my Twitter account, shortly deleting my Facebook account, and declaring my independence.  I also issue the call to you.  If you are tired of Twitter, if you are Facebook's huddled masses, and if Google has you yearning to be free, then pick up your data and join me.

We the people of the Internet are revolting, and the revolution will be live-blogged... on App.net.

RapptorMods and My App.net Dreams

My Dream

I had a dream, a dream that I could build something amazing.  If given the opportunity, I could create something that could change the way we look a the world around us; something that could, maybe, just maybe, touch everyone's lives a little bit.  It was a big dream, and particularly difficult considering my biggest creative talent seems to be development for large corporations.  Yet still I dreamt on, about building, about creating, about that something just over the horizon.

Time passed, and I continued to dream. Then came App.net, a simple idea that seemed to spit in the face of the Internet as we have come to know it.  An idea that dared to ask the question "What if?".  What if we treated people as customers rather than cattle?  What if we respected creativity rather than try to own it?  What if we gave people a platform on which to dream their dreams, and share them with others?  To me, it is a simple idea, but one that cries "Renaissance, and Revolution!"  An idea on which I could build dreams.

So that is exactly what I set out to do.  I put my fingers to the keyboard, and neglected almost all else.  I drove on furiously, encouraging others to build their digital homesteads on this brave new frontier.  In the process, I began imagining how the dreams of others could become a digital reality on App.net.

I decided to start with making it easier for others to make their digital creations in the only way I knew how.  Building C# libraries that would make interacting with App.net much easier for those who could write programs in .Net.  Yet as I coded questions still haunted me, dogging at almost all my thoughts.  What would it take to make something new here? What does "new" look like? How can we go beyond what has been done before?

Then it hit me, App.net is the Minecraft of social networks.  It is a network where literally anything could be built.  With the right tools you could create modifications of App.net, just like there are modifications of Minecraft.

With App.net Mods you could build the digital equivalent of airplanes and spaceships, while the other social networks were in the process of tearing down the digital horse-trails that connected them.  With App.net Mods you could make social mountains; you could even change the shape and behavior of social fabric itself, just like Minecraft Mods have done.  With App.net Mods you could do almost anything...  All you would need are the tools to build Mods for App.net, and I had the tools!

So once again I began to code furiously, listening to the imaginations and dreams of those around me.  I needed to prove to myself that this was the way forward; that App.net Mods could work as I had imagined.  It was excruciatingly difficult work.  I was a times frustrated, exhausted, aggravated, confused, and ultimately drained.  Yet here I stand, a little less than a week since I started working, with the proof I was seeking.

RapptorMods - Tagging

It is my pleasure to announce RapptorMods.  RapptorMods is a collection of Modifications to the App.net API, starting with Tagging.  Tagging is a live API for third-party developers that allows any user to tag any post with any text string up to 50 characters.  It isn't complicated, and in a very Alpha state (so please be careful), however I plan on updating frequently over the coming weeks, though at a much slower pace than I've been working lately.  It is my hope that RapptorMods will continue to provide some amazing functionality on-top of App.net, and stand as an example for future App.net Mods to expand the platform.  Most importantly though, I hope RapptorMods shows everyone, developers, and non-developers alike, what amazing things can be done when you put your mind and heart into creating something.

For some technical details, RapptorMods is currently hosted as an Azure website, with an Azure Sql database.  The API documents, and client-side .Net wrapper code, tests, and examples can be found at the RapptorMods GitHub.  There will also be a NuGet package for the .Net developers to use once the API gets a little more stable.  Please don't hesitate to contact me if you have any questions, or need help getting your client code to connect.

A Few Words on Costs

I want to continue to do amazing things on the App.net platform, and I have the ability to host the API for a short time for free.  However, in reality hosting will likely become very expensive very quickly.  Also, I love build things like this, and making them even better over time, but the time commitment with such a short deadline is simply unsustainable for me by myself.  So I am reaching out to the community.  Please tell me if you have any suggestions on how to make RapptorMods a financially sustainable operation, so that it can continue to benefit the App.net community far into the future.

Finally

I want to first of all thank my Lord and Savior Jesus Christ.

I want to also thank all of the wonderful people on App.net who have inspired me, believed in me, and encouraged me throughout this process.  It has not been easy, and you all have been wonderful.

Lastly, this project is dedicated to my daughter Catherine, and all those who dare to dream.  Don't ever give up looking over the horizon, and imagining what may be.

WCF REST IIS Hosting 404 Issue - RESOLVED!

Recently I've been mucking about in the WCF-REST arena and ran into an infuriating problem that kept me busy for almost three days.  Essentially I had created a small WCF REST service, and it worked fine when accessing it from VS2010 debugging, however why I tried to access the version I had published in IIS (IIS7 or IIS7.5) it would show me a 404 error, or the annoying "directory browsing not enabled" error.  Now you'd expect this on the old .NET 3.5 implementations of WCF REST, but in the newer environments you can do a .svc-less implementation of your service that is much cleaner and leads to a very straight-forward code to URL implementation.  I finally found a solution to my problem, and though it was one of those  embarrassingly obvious solutions, I could have gotten three days of my life back if someone would have mentioned their mistake.

Now if you do a Google search on "wcf rest iis hosting" you'll see that quite a few people have been having these issues, and there are answers out there ranging from making sure the AppPool user has the right permissions to ensuring that ASP.NET had been properly installed on IIS.  None of these suggestions worked for me, leading to quite a bit of frustration.  There was one small hint tucked away that eventually tipped me off to the real solution, however I didn't think to check it until today.  On Christopher Deweese's blog he has a great post discussing how to "do" WCF REST in .NET 4.0 and in the comments he mentions "You should not have a virtual folder set up for your paths. You should just deploy the service and let the routes be determined by the application (not at the IIS level)."  This is the key, in your  global ASAX file you'll have a line of code that looks like this: RouteTable.Routes.Add(new ServiceRoute("MyServiceName", new WebServiceHostFactory(), typeof(MyServiceType)));

Now, when you access this from the debugger you'll end up doing so from a URL similar to "http://localhost:[port]/MyServiceName/...", however once you publish your service to it's own IIS application under the Default Web Site you'll get the 404's starting to pop up again trying to access the URL "http://localhost/MyServiceName/..."  The answer to the problem becomes obvious when you notice that "http://localhost/MyServiceName/MyServiceName/..." works.  The "MyServiceName" string within your ServiceRoute(...) is being appended to the root of your application to determine the route to your service.  So to fix this you can simply publish your service to the root of its own site, or make your RouteTable declaration look like this:  RouteTable.Routes.Add(new ServiceRoute("", new WebServiceHostFactory(), typeof(MyServiceType)));

I hope this saves you a good bit of time in the future when trying to publish WCF REST to IIS7/7.5 and good luck with your future coding!

LINQ to SQL – Dead as a …

LINQ to SQL is dead, long live LINQ to SQL.  No, it’s not “coming back” or pining for the fjords, it’s really truly dead.

At least that is the consensus coming from those both inside and outside Microsoft.  L2S is being deprecated in order to make way for the “One true ORM”tm a.k.a., Entity Framework (EF).  Not that this is entirely surprising considering L2S was transferred to the SQL Data programmability team back in July.  Hopefully, as many people at Kaizen Conf were discussing, EF2 will be much less heavy, and have true Persistence Ignorance.  I’ll keep an eye out, but I’m not entirely holding my breath.

My new rally cry

"I am a PC and I sell fish!"

In Soviet Russia, Blog Posts You

Wisdom of the ages right here, wisdom of the ages ;). Oren is like Life Ceral's Mikey for Alt.NET.

WPF: Data-bind This!

I've been struggling to learn WPF while writing a small log reporting app and one of the hardest things for me to figure out so far has been the data binding logic. Unlike plain-old WinForms, the many ways to hook-up object data to your controls follow a vague syntax, are not designer drive, and seem to come together magically at runtime; the last part being very similar to the Web Site project in VS2005. Since I'm extremely new to WPF and unfamiliar with the binding syntax (though I'm catching up) it would have been nigh impossible for me to figure it out how get anything done without using some serious Google-fu. Unfortunately even the Google-fu failed me and I had to rely on a group of experts to point me in the right direction. After a few more hours of struggling I was able to figure most of it out and I figured it was a good idea to help somone else's Google-fu out on my blog.

What do you mean your Google-fu failed?

Well in this case almost all of the examples I was able to find out there dealt with binding to a pre-done static list of items created and populated within the XAML itself, binding to a list of objects populated in the default constructor of a container class that would be instantiated within the XAML itself (very confusing), binding a custom list class that was once again instantiated via a default constructor within the XAML, and binding to a DataSet. None of these use cases really hit what I would consider the basic use case (and the one forum question I did find asking about this basic case went unanswered): You have a non-static list of objects conforming to a known type or interface generated from within your domain and exposed via a controller/presenter/service class. So looking for this out there was no-dice, and the MSDN documentation was nearly impossible to read and pretty much covers the worst of the above examples. Eventually, and with much trial and error, I was able to figure it out.

So how does it all work?

Good question! I'm still trying to tease out all the details, on how this works, but in general I've got it. In the back-end domain we're still generating and exposing our objects as normal, none of this has really changed, but once we get to the code-behind it's a little different, and the XAML is entirely different. The first thing we have to know in this space is that we can only bind to controls that support dependence properties, and these are the properties we will actually be binding to data such as the Text="..." attribute of a TextBlock (i.e. myTextBlock.Text). Without these properties being available on our control we're out of luck when it comes to binding. Next we'll have to determine whether or not we're binding to a single object or a collection of objects (myTextBlock.Text to a string or myComboBox to a collection). If we're using a collection we'll also decide if we want to customize our view into the collection (more on this later). I should also mention that at this point I'm only talking about One-Way binding (read-only into the data), I haven't quite gotten Two-Way binding down pat yet, so that'll be the topic of another post.

Now once we've figured out what control we want to bind to what data, we'll need to take a moment in order to figure out where the best place to expose this data is. In the case of WPF's XAML implementation there are a couple of places we can do this. The first is using the DataContext, a sort of "catch-all" that most of these dependency objects (what I'll call the objects with dependence parameters) have for data. This can be bound to pretty much anything as it takes in an "object" type, so the simplest way to set the DataContext in code is by saying myControl.DataContext = myData. You can also set the DataContext as an attribute on the tag for your particular object. One nice but dangerous thing about the DataContext is that it is inherited down the XAML tree so it's possible to set the DataContext property/tag on any object that contains your object and have the object that you want to bind take advantage of it. Beatriz has a good post on the subject here.

Another option for exposing the data is to directly set the binding "source" for the property you want to bind your particular WPF control. This is a little confusing to do as it requires you to deal with WPF's binding syntax. Using the binding syntax without the "source" looks something like this:

<TextBlock Text="{Binding Path=MyProperty}"/>

As you can see we have the Text attribute set to a string containing the keyword "Binding" in curly braces, which identifies that you want to bind the Attribute/Property to something. The Path= (notice the lack of quotes) statement is where you tell WPF which property on your data you want to bind to. It's possible to write this statement as "{Binding}" or "{Binding .}" to say that you want to bind to everything on some inherited DataContext, but remember that depending on the property you set this way it may just call .ToString() when it gets to binding, so be careful. Now when you use the binding syntax there's also a Source keyword. The binding syntax that uses the Source keyword looks something like this:

<TextBlock Text="{Binding Source={StaticResource myDataObject}, Path=MyProperty}"/>

This will tell the binding to find the Path property using the given data object within the source declaration. Again myDataObject can be declared either in your XAML or within your code-behind, however it's important to reference your code-behind clr-namespace at the top of your XAML file (see here (MSDN link, Sorry!). If you do this you would reference namespaceAlias:myDataObject, where namespaceAlias is whatever alias you've setup at the top of the XAML file. Using the source property is useful in some cases including debugging (again see Beatriz's article), but I'm not sure about all the details that surround the StaticResource keyword. Any comments to clarify that keyword would be appreciated.

You can also directly set the binding on a given object via code, however I've had some trouble getting the source to change as it kept its reference to the original object, but again it will be the topic for another post.

The final way to expose data to your binding is particular to binding to collections. If your control supports binding to a collection (Grid, ListView, ListBox, ComboBox, TreeView, etc.) then you can bind its ItemsSource Property/Attribute (I'm going to start calling them "propttributes" soon!) to your data, which will then allow the attributes and children of any template items (used in a DataTemplate or a HierarchicalDataTemplate, which you can find further information on here (MSDN link, sorry!)) to bind directly to properties on object instances within your collection.

This is all the "setup" we need to understand getting our controls bound to data (finally!) so all that's left to do is actually wiring up our binding to our attributes. Again this uses the binding syntax above, and I think I've covered how to write those, however feel free to ask if you have any questions or get confused. Anyways I think I've at least covered the basics, however I'll have to write some future posts on collections and the CollectionView for grouping, sorting, and formatting as well as getting data to refresh.

WPF: Adventures in Formatting

Problem: I needed to have a really long string text in a bound WPF ListView column wrap instead of running on until the end of the text.

Solution: After doing quite a bit of searching around I was unable to find a good concrete example that worked in my particular case. The closest example I found looked something like this:

<ListView Height="Auto" Name="lsvErrorSummary2" ScrollViewer.CanContentScroll="False">

 <ListView.View>

  <GridView>

   <GridViewColumn Header="Message" Width="200" DisplayMemberBinding="{Binding Path=Property}">

    <GridViewColumn.CellTemplate>

     <DataTemplate>

      <TextBlock TextWrapping="Wrap" Text="{Binding}" />

     </DataTemplate>

    </GridViewColumn.CellTemplate>

   </GridViewColumn>

  </GridView>

 </ListView.View>

</ListView>

Maddeningly enough this doesn't work as I spent at least an hour trying to find some magical combination of properties that would get it to work. The reason this doesn't work seems to be the fact that when we use the "DisplayMemberBinding" to bind the column WPF is using the binding for both the data and how to display the data, or at the very least WPF is just using the default for displaying the bound data. That being said I was able to solve it by making some changes.

The first thing I did was to remove the DataTemplate out into a Resources area (Window.Resources would work) and make sure to give it an x:Key="" attribute. After doing that I pulled out the GridViewColumn.CellTemplate tags as well. All that's left to do is to set the Text attribute of your DataTemplate's TextBlock equal to your real binding property (i.e. Text="{Binding Path=Message}" and point the CellTemplate attribute to the DataTemplate's x:Key (i.e. CellTemplate="{StaticResource CustomListViewItems}"). The end result should look similar to below:

<Window.Resources>
 <DataTemplate x:Key="CustomListViewItems">
  <TextBlock TextWrapping="Wrap" Text="{Binding Path=Message}" />
 </DataTemplate>
</Window.Resources>

<ListView Height="Auto" Name="lsvErrorSummary" Width="511" ScrollViewer.CanContentScroll="False">
 <ListView.View>
  <GridView>
   <GridViewColumn Header="Message" Width="200" CellTemplate="{StaticResource CustomListViewItems}">
    </GridViewColumn>
  </GridView>
 </ListView.View>
</ListView>

So far so good, now here's the hard part: this only works well when the column has a fixed width, but the TextWrapping setting will fail to take effect otherwise. In order to have it work with a flexible width a little bit of hacking is required. The easiest way to do this is using the ActualWidth property on the GridViewColumn you're wrapping. The following code shows doing this with two columns in the ListView:

((GridView)myListView.View).Columns[1].Width =
    myListView.ActualWidth - ((GridView)myListView.View).Columns[0].ActualWidth - 5

With this code I'm using Columns[1] as the column that wraps and I am determining the width with a little padding on the end (hence the "- 5"). There may be a more effecient way of doing this, but the math is pretty straight forward and you can run this code whenever the ListView would resize in order to maintain the text wrapping.

She's Here!

Catherine Celeste Scolamiero was born at 8:11pm 1/14/2008, weighing exactly 7 lbs. and 20 in. of length. Everyone remarked at her long and beautiful dark hair. She is doing very well.

Stefanie is also doing well and currently recovering.

Chasing Chad

Chad Myers and his wife recently had a baby, and we're following them right up with one of our own. My wife is currently in labor with our baby and we're blogging to notify our friends and family with updates. The internet is a wonderful thing!