Zulu JRE from Azul Systems is a hidden gem

http://www.azulsystems.com/products/zulu Azul Systems, the company that Cliff Click works for, builds their own openjdk version.

If you don’t recall Cliff Click, I was first introduced to him via this awesome video: https://www.youtube.com/watch?v=agH7Cz5FSxY

If I have to run on the JVM, then this is how I want to run on the JVM.

Zulu isn’t Zing, and yet it is a hidden gem. No more stupid prompts from Oracle. No more being associated with the company that forces you to install the Ask toolbar and other spywear.

The download page is here: http://www.azulsystems.com/products/zulu/downloads

It is the best (only?) way to get openjdk onto your OSX mac.

Better still is the package install on Ubuntu.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0x219BD9C9
sudo apt-add-repository "deb http://repos.azulsystems.com/ubuntu stable main"
sudo apt-get update 
sudo apt-get install zulu-8

Zulu includes something called the CCK which says

The Commercial Compatibility Kit (CCK) for Zulu contains additional functionality that is not included in in the OpenJDK source, but which will help ensure compatibility in applications that take advantage of specific additional features that Oracle bundles into HotSpot.

curl -O http://cdn.azulsystems.com/zcck/2014-08-8-bin/zcck8-
sudo dpkg -i zcck8-

Do better Java on Ubuntu.

golang goals

When discussing the Go programming language, I find it useful to always reference the goals of the language. Discussion tends to devolve into a comparison of features of other programming languages which Go lacks. Without the context of these goals, the discussion ceases being useful.

Stolen from a Google tech talk that Rob Pike did back in 2009:


  • The efficiency of a statically-typed compiled language with the ease of programming of a dynamic language.
  • Safety: type-safe and memory-safe.
  • Good support for concurrency and communication.
  • Efficient, latency-free garbage collection.
  • High-speed compilation.

Watch the Go at Google video or read the article and you will get the impression that these goals are NOT in their order of importance. I suggest that the last item, High-speed compilation, trumps all the others.

Here is a short, 1:15 video demonstrating the speed of the go compiler: https://www.youtube.com/watch?v=wwoWei-GAPo

The first comment, over 2 years ago, at Lambda the Ultimate, about that Go at Google video, sums it up even better. It is a snapshot of another slide. This time instead of Go goals, the slide is “What makes large-scale development hard with C++ or Java (at least):”

  • slow builds
  • uncontrolled dependencies
  • each programmer using a different subset of the language
  • poor program understanding (documentation, etc.)
  • duplication of effort
  • cost of updates
  • version skew
  • difficulty of automation (auto rewriters etc.): tooling
  • cross-language builds

* Language features don’t usually address these.


It took me quite a while to keep these above things in mind when thinking about Go. In fact, I still tend to compare Go to my favorite programming languages, probably because I often forget some of those above drawbacks to C++/Java (read C# for me).

I’ll try to remember. I beg others to try to remember too.

ctags for golang and vim; just the right things with godeps

I use vim.

I like to press ctrl-] to go to a tag and ctrl-t to pop up that tag stack.

I use ctags from homebrew to generate my tags file which vim reads. The OSX version of ctags is inadequate.

I often invoke ctags with -R . and a list of directory names to the libraries which I am using. When using ctags with python or C this works reasonably well, but I have to maintain the list of directories somewhere.

Go lets me handle this case slightly better.

godeps is a tool which does two things, in this case I only care about the first. godeps prints the source dependencies of named packages.

Combining godeps output and sending it to ctags means my tags file automatically has tokens from all of my dependent packages. I name this shell function goctags.

goctags () { godeps ./… | awk -v GOPATH=$GOPATH ‘{print GOPATH”/src/”$1}’ | xargs ctags -R .; }

I added it to my .bashrc.

Book Review: BeagleBone Robotics Projects

I was asked by Packt Publishing if I would read and review this book. I’ve owned a BeagleBoneBlack for a little while now. My use case was not robotics. This book might shed some new light on my old Black, so I agreed to review it.

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.

When Reversing the Interview Process becomes How Would You Do Fun Things in C

My boss’s boss’s pals wrote this: http://blog.exodusintel.com/2012/09/18/reversing-the-interview-process/

Its a story about how someone was asked a crazy fun C question in an interview and how the new team decided to try it.

After reading this and discussing it with coworkers, I decided to try it and of course the first thing that came to my mind was a way to use tail recursion to do it.

 1 #include <stdio.h>
 3 int c;
 4 //auto func0 = [&] () -> int { c++; _strlen(s+1);};
 5 //auto funcn = [&] () -> int { return c; };
 6 int rs(char* s);
 7 int go(char* s) { c++; return rs(s+1); }
 8 int ret(char* s) { return c; }
 9 int rs(char* s) {
10     int (*func[2]) (char *s) = {ret,go};
11     char i = (*s>>7 | *s>>6 | *s>>5 | *s>>4 | 
        *s>>3 | *s>>2 | *s>>1) & 1;
12     return func[i](s);
13 }
14 int _strlen(char* s) {
15     c = 0;
16     return rs(s);
17 }
19 int main(int argc, char* argv[]) {
20     printf("_strlen(%s): %d\n", argv[1], 
21     return 0;
22 }

After writing it, I went and looked at the other fella solutions for the second time. I should also mention that I haven’t written C on the job in 11 years, and when I did then, it was one tiny program which was quickly replaced with perl. I have never been anything other than an intro beginner C programmer.

Things I noticed after going back is that my solution is somewhat similar to Brandon and Zef’s solution, but I think both my use of function pointers and bit shifting are more elementary. I’m still not sure about how some parts of their solution works.

Storyboard Custom Segue For Custom PushViewController Animation

While there are a lot of google hits when searching for custom pushViewController Animation, I found nothing regarding use of a Custom Segue to make it reusable and I also found a lot of misinformation like “it can’t be done with the default UINavigationController.” It can.

From your Button, View, Gesture Recognizer or whatever, instead of dragging from Push, drag from Custom.

Then select the Segue that is created and type in a class name the custom Segue.

Now we can create the FromTopReplaceSegue class. Use Add File or however you like to create new classes in XCode.


#import <UIKit/UIKit.h>
@interface FromTopReplaceSegue : UIStoryboardSegue


#import “FromTopReplaceSegue.h”
@implementation FromTopReplaceSegue
UIViewController *dst = [self destinationViewController];
UIViewController *src = [self sourceViewController];
[dst viewWillAppear:NO];
[dst viewDidAppear:NO];

[src retain];

[src.view addSubview:dst.view];

CGRect original = dst.view.frame;

dst.view.frame = CGRectMake(dst.view.frame.origin.x, 0-dst.view.frame.size.height, dst.view.frame.size.width, dst.view.frame.size.height);

[UIView beginAnimations:nil context:nil];
dst.view.frame = CGRectMake(original.origin.x, original.origin.y, original.size.height, original.size.width);
[UIView commitAnimations];

[self performSelector:@selector(animationDone:) withObject:dst afterDelay:0.2f];
– (void)animationDone:(id)vc{
UIViewController *dst = (UIViewController*)vc;
UINavigationController *nav = [[self sourceViewController] navigationController];
[nav popViewControllerAnimated:NO];
[nav pushViewController:dst animated:NO];
[[self sourceViewController] release];

In this CustomSegue not only are we doing custom animation from Top to Bottom (just like the default push navigation of Right to Left) but instead of pushing, we are replacing the top view controller.

In my current project I have a nearly identical FromButtomReplaceSegue that does the replace but animates from Button. I hope for a library of these with varying animation transitions and Push/Replace variants of each. Then anytime you want to use a different animation you can simply use a Custom Segue instead of writing a bunch of code in ViewDidLoad or wherever. Hurray Storyboard!

  1. http://stackoverflow.com/questions/2215672/how-to-change-the-push-and-pop-animations-in-a-navigation-based-app
  2. http://stackoverflow.com/questions/5878732/how-to-create-uinavigationcontroller-animation-top-to-bottom
  3. http://dmunsie.wordpress.com/2009/08/07/custom-animations-between-uiviewcontrollers/

Build MVVM Applications in F#… or C#

Last month Chris Marinos had an article in MSDN Magazine titled “Build MVVM Applications in F#”

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#.

Where Windows Is Going

I’ve been stewing for about a day.

I did not go to Build Conference.

Once I figured out that WinRT is for Metro style apps and ONLY Metro style apps, and I tried to make a call from a .NET 4.5 app into a very simple “GetUserInfo” WinRT API and it threw an Access Denied Exception, I was upset.

Then I realized something.

This is not just a new way to program on Windows.

It is also not THE new way to program on Windows.

Microsoft is segregating their application types on purpose. Metro style apps and WinRT is not about “the next windows”. What was shown with the hybrid classic desktop and the new Metro UI is NOT the future vision that MSFT has for Windows. It is a transition.

Microsoft is posing Metro style and ONLY metro style to be the next development platform of a version of Windows that will not have the classic desktop. Some future version of Windows that won’t have Win32 and won’t have .NET. It will be WinRT on top of a Windows kernel and THAT IS ALL.

This is why that line between WinRT and .NET/Win32 has to stay thick and hard. There will be no hybrid apps. That ruins the vision.

win8-platform-and-tools Imagine a thick wall between the light blue and green.

Microsoft knows that it has to participate in a segregated market. They won’t be selling $100 Windows Professional licenses to OEMs of $300 tablet devices. The $10 license of Windows Started Edition is more like it. (I’m guessing at OEM costs.)

The operating system has to run fast on low power hardware. Any applications which run on it have to run on all the better and faster hardware, right on up to $5000 laptops. The Metro style along side classic desktop fits this mold.

I’m a little bit sad that they wouldn’t just come right out and say this. Come right out and say: “Hey! Our phones are going to run Windows 8! There will be 7”, 8”, 9”, 10”, 11”, 12” tablets all running Windows! But its not like any Windows that you’ve ever known!”


Talk about shaking things up! What if that were the first 3 sentences of the Build keynote?

I’m less angry about not being able to call WinRT from my .NET apps. But I’m a .NET developer. I’m not a Windows developer. I’m not a Silverlight developer. I’m not a WinRT developer.

I think in what I’m most disappointed is all that awesome stuff that WinRT makes easy, and out in .NET land, talking to a webcam for photos and video is still painful. Transcoding video is still painful. (Did you see how easy it is to transcode with WinRT? That is SWEET!)

Build Windows Day 2 From Afar: WTF is WinRT

Watching the developer reaction to Metro style and WinRT has been both depressing and comical. I suppose its like watching anyone else learn something from nothing. We can get it very wrong at first. It is part of our learning process.

I know I’ve not figured what the existence of WinRT means for .NET or what I can and cannot do between WinRT and.NET4.5. I’m also not sure what the difference is between Metro style and WinRT. It sure seems like there are some cool non-UI APIs in WinRT that I might want to use from .NET. I sure hope that I can.

At first glance it feels like Metro style apps aren’t .NET. At least not really. It feels like Metro style apps run in a different CLR. They feel like Silverlight on the desktop since they have no direct access to file system and the types available for use are limited.

I’ve read that it is not a different CLR. I’ve read that it is .NET but that the verifier and other tools in the chain of building a Metro style app enforce the restrictions. I’ll have to wait and see how the pieces fit together.

Missing the APIs can be a challenge: http://winmd.tumblr.com/post/10211942442/missing-net-apis

Looks like I can do the above when I say use some WinRT from .NET4.5. Cool, because those file pickers sure are pretty. http://ermau.com/using-winrt-from-net/

Doug Seven has an excellent post detailing what is being released and how it fits: http://dougseven.com/2011/09/14/i-know-what-youre-thinking-and-youre-wrong/

Take a look at this slide from the keynote:


I’d like to speculate about a couple things related to this picture.

  1. This is not in the scale of overall importance to all developers. It is in the scale of what is new.
  2. All of the things in blue are still there and still supported.

Consider an alternative pitch for Metro style apps. Metro style apps, like all apps, are all launched from the new “Start Screen”. The start screen replaces the start menu. Metro style apps keep the look and feel of the start screen. It is as if you are never leaving the start screen. Metro style apps are apps that you program into the start screen. Imagine being able to program apps into the start menu. It sounds crazy. Now that your start menu is full screen and interactive, those metro tiles (they have a different name) are programmable by you. I can think of another little square in windows that is programmable: Sidebar Widgets. When was the last time you wrote a sidebar widget? (Mike Ward, you are the only one I know.)

Considered from the point of view, very few of us Line of Business app developers will be writing Metro style apps. They are not meant to replace all desktop apps. You will not see Office apps like Word, Excel or Powerpoint built as Metro style apps. They will likely get some theming that is Metro influenced, but they will still run on the traditional Windows desktop and not in the Start Screen. That said, there might be augmentations in the Metro style apps. After all, Windows on a tablet is far more usable with Office. So I think you will see stripped down, touch optimized, Metro versions of Word, Excel and Powerpoint. The use case for these will be “when you aren’t at your desktop or laptop".

Believe it or not, there was actually announcements around Azure and ASP.NET yesterday. You’d never know it given all the focus on WinRT. I’m super excited about the new async support for controller actions in MVC4. I also think Azure’s replication story around tables and blobs is pretty sweet now.

So much more to come. Its an exciting time be a developer. Just try to remember that ships often look like they are sinking when you see them far off the horizon Smile

Thoughts after the Build Windows keynote: This changes nothing

Nothing has changed, and this is a good thing.

Here is what I took away from yesterdays keynote:

  • Everything I’m doing today with Windows desktop apps will work on Windows 8. No surprise there.
  • If I want to write these new WinRT apps I’ll have to leave Winforms or WPF behind and use what looks like some kind of desktop Silverlight UI control library which has been enhanced with some more controls. (The GridView was shown in the keynote.)
  • There is nothing else to say about the developer story. Everything else shown in the keynote was about consumer experience.

Watching my own twitter feed was rather comical. Everyone seemed to be hearing exactly what they wanted to hear. Sometimes it was the opposite of what I thought I just heard.

There are still lots of unanswered questions, but I’m sure that in the next few days these will all be answered via sessions and blog posts containing the content of the sessions. I’m surprised people aren’t more patient. I’m actually seeing a bit of FUD email and tweets asking questions that should be answered by the end of the week. Be patient.