The book starts off very accessible. Chapter 1 covers just about everything I did with my BBB when I first received it, hooking it up like a PC, replacing the default distro, making sure I could SSH to it were all in there. The author, Richard Grimmett, goes a step further and installs XFCE gui and vncserver and walks through connecting from a Windows PC using vncclient. All in all, chapter 1 is a great super basic tour.

Chapter 2 dives into programming on the thing and introduces Python. It does it in a really weird (to me) way. It has the reader running emacs in a putty window remote connected to the device. This must just feel weird to me because I do a lot of remote programming and its never with emacs (I’m a vim guy) and its rarely remote. For a new user, it seems to me like it would have been simpler and more friendly to say “use an editor of your choice” and “here is notepad2 or sublime” along with “here is how you copy files to and from the device.” I think this is mostly my background causing me to see things differently. The emacs in putty walk-through is very adequate.

Its not a programming book, so this is really a nit pick, but technically some of the descriptions of python aren’t really true. For example, if __name__==”__main__”: does not “tell the program to begin its execution at this point.” Again I’m nit picking, but I do feel like a different phrase that isn’t so very false to someone who knows python could have been found. Still, its not a programming book. The beginning of the chapter does list many resources for learning python.

Ugh, and then the book moves on to C++ and has quotes like this, “C++ is the original language of Linux” I’ve used Linux for almost as long as I’ve programmed C, and I am very (perhaps overly?) sensitive to the difference between C and C++.

OMG what do you mean Speech Input and Output? Really?  Chapter 3 tackles it. Really. For real. Speech Input and Output on that tiny little board. I can make my own Siri! This is a really cool topic; espeek is something I’ve only played with a little bit prior to reading this. It looks fun.

Speech recognition is done with software I’ve never used before called PocketSphinx. It isn’t packaged and so one has to compile it. Pretty sweet BBB being able to compile stuff like that. (I’m thinking of iOS and Android where I’ve not seen a compiler run on device.) The demo walks through limiting the grammar of speech input so that you don’t have to train the recognizer.

I’m a programmer, so I’m going to nitpick programmer things. I really wish authors wouldn’t do this, “I like to make a copy of the current file into continuous.c.old, so I can always get back to the starting program if it is required.” I really do wish authors would just say “go read about version control systems.”

Whew, speech is fun. Next step is video. Hook up a webcam and let’s do some image recognition. The book walks through OpenCV and it is as this point that we are forced to do a bunch of Linux sysadmin stuff to make our SD have enough free space to have a dev environment. This really could have gone anywhere in the book. I kind of like that it put it off until it was necessary.

The python image tracking example using OpenCV looks pretty cool. It is a complete example without going too deep or going off in the weeds.

Making the Unit Mobile introduced me to mobile platforms. The Magician Chassis that the book shows first, I found online for under $20! I knew that this stuff was accessible, but this is downright cheap. I feel almost guilty NOT getting one and trying it out.

The motor controller tutorial looks very straightforward. I already have ideas for code changes. Immediately after the simple time based tutorial it goes into speech controlled movement, which is pretty sweet.

After the wheeled robot tutorial is a walking robot example. The author makes a compelling argument for this type of robot, and the Pulse Width Modulation servo motors are cool, but I have to admit, this type of robot just doesn’t excite me. The book also punts on the PWM, using a controller which interprets serial USB commands into the PWM for the servos. For beginners, this is certainly the right choice.

Incidentally, the –help output from UscCmd includes Version, Culture, PublicKeyToken values like a Mono program might. I wonder if it is written in C# and running via Mono. I’m going to assume it is. That is pretty sweet. Indeed the linked download page mentions C#. http://www.pololu.com/docs/0J40/3.b

The sonar sensors section is a straightforward and great introduction to the use of them. I never knew how those things worked or what kind of value they returned. Now I do. Mounting the sensor to a survo makes for a nice subsystem on the bot.

Next, a fully remote control system is built. I don’t know if I like the choice of using an LCD monitor. It seems like overkill, but depending on the particular robotic application it would be a good choice. For the applications I have in mind, I think I’ll skip it. A wireless usb keyboard and mouse makes for an obvious choice. At this point, I just keep thinking about bluetooth and using an extra Wiimote, mostly because I think it would be a more fun control.

Oh, a GPS receiver! This could be necessary for when I lose my robot in a parking lot or the woods. As with the LCD Monitor and KB chapter, I kind of feel like I know how to do this since I’ve looked into it before. It is great coverage and good intro to the topic.

Much of my day job is what would traditionally be called Systems Programming so Chapter 10 is kind of a duh to me. I’d have started there, but that is just how I think about coding these days. Its great to have this in a chapter to tie some things together. In other words, read this chapter!

Using the BBB in sea, air and submarine applications is an interesting idea. I don’t think it is for me yet, but the book gives introduction to some ideas on the topic. The introduction to feedback control is very welcome.

Overall this is a great book. It really gave me a lot of ideas. It also showed me how easy it is to get started, something which I’d been a little hesitant to do. I’m actually a little excited to dive in now. I’ll be doing a bunch of this stuff with my 6yo over the next few years.

 1 using System;
 2 using System.Xml;
 3 
 4 public class Program {
 5     public static int Main(string[] args) {
 6         var  doc = new XmlDocument();
 7         doc.Load(args[0]);
 8         foreach (XmlElement n in doc.SelectNodes(args[1])) {
 9             Console.WriteLine(n.InnerXml);
10         }
11         return 0;
12     }
13 }

I liked it a lot. I jotted down some notes as I read it. My learning processed amused me as I went from WTF… to Hrm… to Oh I see… in a period of about 15 minutes or so.

It went something like this:

> My first thought on skimming the first 3 pages…
>
> Ok, no offense… but… Dude! Really?!?
>
> PM> Install-Package NotifyPropertyWeaver
>
> and my "viewmodel" can be class MovieVieModelCSharp { public string Name
> {get;set;} public string Genre { get;set;} public int Rating {get;set;}
> public MovieVieModelCSharp(Movie movie) { Name=movie.Name;
> Genre=movie.Genre; if(OptionModule.IsSome(movie.Rating)
> Rating=movie.Rating.Value; else Rating=0;} }
>
> But then I realize that isn’t the point of that part of the article.
>
> Everything looks cool. I’m wondering if NotifyPropertyWeaver would work
> with the Dummy F# view model in Figure 7.
>
> Then I see in Figure 9 you use the ViewModelBase. That is cool I guess,
> but I think NPW might allow for writing WAY less code.
>
> …
> OK… i spent some time exploring these idea and realized I’m clueless.
> F# has no concept of autoproperites (WART!) and its A LOT of code to
> write a mutable property (warts!). NPW sure isn’t going to work with
> non-autoproperties (it picks up on C#/VB autoproperty naming convention
> of the compiler IIRC).
>
> So all that said… I think your article is great.
>
> It challenged me to investigate some things. It shows me that F# really
> sucks for WPF. It makes me really appreciate C# autoproperties and NPW.
> Damn that is some ugly ass code in that last "all F#" section.

Now some interesting parts to this is that NotifyPropertyWeaver apparently DOES support weaving PropertyChanged into non-autoproperties. That is pretty cool, but even with that, I think that this is a case where C# is actually more appropriate than F#.

public BetterDataGrid : DataGrid {…}

But when I did, data binding only worked against my initial view model. In my case a file load operation replaced the original view model and binding did not happen against the new view model.

I had to explicitly include Mode=TwoWay on the Binding, when using <this:BetterDataGrid … but this was not necessary when using <toolkit:Datagrid.

Just a warning, if you are going to extend DataGrid, be sure to explicitly set your binding mode.

I get an error that says
—————————
Error
—————————
Test Provider ‘NUnit25’ can’t find required assemblies in this path
—————————
OK  
—————————
I finally tried C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0\lib and it worked.

I didn’t see this documented anywhere. It is now. (here)

I vaguely recalled something about WCF async and I suggested this person look into that. I even looked up the AsyncPattern=true property and value for the OperationContract attribute, but the person didn’t want to break the contract. I was pretty sure that this change was only a server side change and that it wouldn’t break any contract, but I wasn’t 100% sure.

Today I confirmed that I was right. The generated WSDL does not change when you change your contract from something like this:

[ServiceContract]

public interface IOrderService

{

[OperationContract]

Order[] GetOrders(int numOrders);

}

To something like this:

[ServiceContract]

public interface IOrderService

{

[OperationContract(AsyncPattern=true)]

IAsyncResult BeginGetOrders(int numOrders, AsyncCallback callback, object state);

Order[] EndGetOrders(IAsyncResult result);

}

If you want to convert existing WCF services to server-side async style, you can do so without your clients ever knowing. (There may be a caveat when using a ChannelFactory, see the docs.)

The MSDN docs are pretty good. An overview here http://msdn.microsoft.com/en-us/library/ms730059.aspx some better details here http://msdn.microsoft.com/en-us/library/ms731177.aspx

Dan Rigsby had some blog posts from when these features were rolled out, but beware his examples, he keeps a sync version and an async version, which is not strictly required. http://www.danrigsby.com/blog/index.php/2008/03/26/async-operations-in-wcf-iasyncresult-model-server-side/

Finally, Wenlong Dong’s blog gives great reasons why you would want this and even goes as far as suggesting using the async version of the datareader for async database access. http://blogs.msdn.com/b/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx

Rob has a great post where he lists 4 cases where he likes Ruby and compares to the same thing in C#. Case 1 Expressiveness: Rob likes the unless statement and the post expression if statement. Case 2: Rob likes Gems. Case 3: Rob likes simple things. Case 4: Rob likes sending messages, open classes and method missing.

Python and Perl already did all this, so why Ruby?

Case 1 and 3 were true in python when i started writing it in 1996 and case 1, 2 and 3 were true in perl when i started writing it in 2000. I’m sure case4 is true in both python and perl too, but I never went that deep into either of them. Much like in Ruby, you don’t have to go that deep to get things done.

I am of the opinion that if you have never seen a dynamic typed language before, or maybe a dynamic typed language other that BASIC or VB before, that Ruby has all of the appeal which you tout. However, there are some of us who write C# because we actually like it, we write desktop applications, and find it to be the best static and strong typed language around. We came to C# and were super impressed because the weak typing of C wasn’t there. The rough edges of C++ wasn’t there and for nearly all applications there is no performance difference and sometimes the GC and managed environment actually gives a boost in performance over some of the bad C++ we were writing before.

So should someone who has never written in Perl, Python, Pike and PHP go try out Ruby… absolutely… get the exposure.

Alternatively, if you have done some Perl or Python and now you are a C# guy. Ruby might not seem so impressive. In fact, it looks more like the same thing with a new coat. I can’t tell what the hype is about. There isn’t much new and different.

All that said, after years of Perl, learning C# was a challenge, especially since I was using it to solve many of the same problems for which I had been using Perl. WHY? was I doing it that way? Well I wanted Windows Forms UI front ends on my Perl versions of programs there were ultimately just sed/awk/grep and some ldapsearch/ldapadd/ldapmodify commands. Not commands really, but calls to libraries.

There is a good reason that the “simple things” aren’t AS simple.

What I learned was that there is a damned good reason that Case 3 “The Simple Things” were a little more complex in C#. The separation of stream and textreader abstract types in C# make huge sense once you realize that doing the same thing in perl or python (or ruby) can be a bit of a hassle. The organization of decorator streams in the .NET BCL just makes sense. Want to compress? Decorate with the stream compressing class. Want to encrypted? Decorate with the stream encrypting class. Want to do both? In either order? Decorate appropriately.

I do share Rob’s opinion. It is a little prettier in Ruby. I’ve already gone on record as saying that “var” in C# should be optional. In VB6 the Let statement was optional. In VB.NET the Let statement is no supported. IMO C#’s var isn’t much different than VB.NET’s Let and Dim. Sure would be nice if it were optional.

I’ve also requested static imports so that we could do things like just call the open method instead of saying File.Open. When you are in a nice tiny singly responsible file, it just makes sense.

These things don’t change my ability to write code.

On .NET’s lack of a CPAN, Cheeseshop, Gem equivalent: YES! YES! YES WE NEED IT NOW!

I can’t say anything other than .net needs CNAN (comprehensive .net archive network) or maybe CCAN (comprehensive CIL archive network). I can’t decide which name I like better.

As for metaprogramming, I think that Python, Perl and Ruby’s ability for runtime metaprogramming will continue to be far beyond anything you see in the C# world. That is not say that metaprogramming is not possible in C#. Its just very different. Its typically compile time metaprogramming. Thanks to the addition of T4 in VS2008 and 2010, metaprogramming in C# is readily available and powerful.

I could go on and insert above about how I learned to love the .NET RegularExpression API after having it blow my mind in comparison to perl’s. Or about how poorly documented the System.DirectoryServices API is, but that once I got it I loved it so much more than Net::LDAP. Or about the extreme pain in building CPAN modules on a Sun Sparc and how installing Mono and using Visual Studio and C# was actually easier than making Perl work properly.

But rather than elaborate on those things, I’ll end by saying, yes, Ruby is awesome, if you have never seen any of the things which make it awesome before.

When he showed Default<T>, I immediately thought it was just an variation of Option<T> or F#’s option type, but with added default value logic. Its cool.

He was asking for compiler support so that things like this would be possible.

Default<int> a = 1;

Well, I thought, you don’t need compiler support for that, just add an implicit type converter to your definition of Default<T>

        public static implicit operator Default<T>(T value)
        {
            return new Default<T>(value);
        }

No worries, right?

Oh I was so wrong. While this will work for the regular above statement, it won’t work as a default parameter value.

     class Things { public Things(Default<int> a = 5) { } }

This provides a wonderfully descriptive error (I love this compiler) which says “a value of type ‘int’ cannot be used as a default parameter because there are no standard conversions to the type ‘Default<int>’”

Now I’m crying? Why the limit? Instead of Jon’s request for awesome Default<T> support in C# 5, I request considering implicit type converters on optional parameter default values.

http://wlanchannelinfo.codeplex.com/

I finally updated it to use a .NET release instead of a .NET 4 beta, but when I did, I decided that I didn’t need .NET 4. I just stuck to using 3.5 so that this app will run out of the box on Windows 7. No need to get .NET 4 to run this. I figure my parents might have windows 7 but probably won’t have .NET 4 installed just yet. Maybe someone else’s parents would have the same issue, and since the download is only 19KB… yes, 19KB… since the app is dead simple and does nothing but use existing WPF controls and p/invoke into the WLAN api (via the ManagedWifi.dll also on codeplex) its *TINY*.

Let me know if you find this useful.

public static Uri AsUri(this string uri) { return new Uri(uri); }

This way I can just add a AsUri() when I forgot that I was supposed to pass a Uri instead of a string.

webclient.DownloadFileAsync( “http://blah.com”, filename );

doesn’t compile and so I can scratch my head once again and replace it.

webclient.DownloadFileAsync( “http://blah.com”.AsUri(), filename );

I like trivial things