In lieu of my past complaining about Reflector’s new owners you might expect some outrage about the announcement today that redgate will be charging $35 for this product starting in March. Your current free version will stop working shortly thereafter forcing you to buy the upgrade or find another tool. I can’t say, however, that I’m all that surprised. The .net ecosystem is a place where tools cost money. Visual Studio costs money. SQL Server costs money. Sure there are ways to write C# code in notepad++ and run the compiler on the command line, but I don’t know too many developers who operate like that. And $35 is small fries compared to what I pay for a control set like DevExpress. I say vote with your wallet. If you find value in the tool at that price – great! Otherwise, find an alternative or build your own. As for me, I’m holding out for this - especially since I’m already a customer and love what they put out.
Why do programmers love to climb? Actually, I don’t think it is specifically constrained to programmers, but anyone in a math, science or engineering role. This is by no means a scientific survey but more just my personal observation of how a love for solving problems in the abstract relates to the skills and mentality required to love climbing rocks.
Rock climbing (and especially bouldering which is what I do the most of) involves solving problems and this, I think, is at the root of the correlation. You might think that at the end of a day of writing code, the last thing you’d want to be faced with is another set of problems to solve. But there is something very refreshing about the mental and physical challenges associated with climbing that compliment a day job lived in the abstract. The rock is real, the goal is fixed. You need a combination of mental awareness, physical strength, dexterity, technique and lots of plain old perseverance to get up a rock face. There is also a individual/collaborate dichotomy to climbing similar to the world of math, science, and programming. At the end of the day, it is you the individual that must solve the problem and climb the route. No one is there to help you and it comes down to how well you execute the sequence of movements required to accomplish the climb. However, in the background there is a constant community of collaboration going on. Beta is exchanged. Technique is discussed. Methods of training or recovery debated. Different movements are tried over and over again with subtle variation and the results are communicated to the group.
If you get your thumb fully engaged and pinch while you are crimping off the top of that left hand you can gain enough pull to make that high move. But you have to keep that right toe on or it is all over.
Beta often doesn’t work for everyone though. Height, ape index and a variety of other physical factors determine how you go about climbing a particular problem and in many cases a friend’s method will be of no help to you. One of my peers is tall enough that I almost always have to come up with a different set of beta for climbing the same problems because I just can’t reach the holds and keep my feet where he does. Another friend is so much stronger than I that he doesn’t worry about his feet too much and is very adept at jumping for holds and then catching and stabilizing his swing. I’m a much more cerebral and technique based climber. I’m not overly strong, so I rely on body position, using my feet, maximum efficiency of movement and subtle leverage points to get up the rock. One of things I’m trying to learn now as I have progressed to harder climbs is actually how to move very dynamically on the rock by jumping and pogo-ing to catch holds while using my core to contain swing and stay put after I come back in contact with the rock again.
As a developer moving from the abstract world of 1′s and 0′s to the physical world of rock, sweat and sometimes blood it seems there is endless entertainment in the realm of conquering boulders and cliffs. The same way I sometimes wake up in the morning with the solution to a programming challenge appearing in my head, I will often dream about a particular bouldering problem I’m working on. Or I’ll be driving to work, visualizing the movements in my head of a particularly hard climb, my hands sweating on the steering wheel. When I come back to that problem the next day things click that weren’t working the day before and I’ll find myself sending what previously felt impossible.
I’ve taken a few of my fellow developers climbing and have been fascinated by the reaction to the sport. For someone who has never climbing before (and especially if they are particularly strong or adept at another sport) climbing for the first time can be a very frustrating activity. Traditional strength does you nothing in climbing until you learn how to use it. And often it is forearm and contact strength that matters way more than your ability to bench press. You legs also matter much more than your arms do and some of the most common climbing advise heard is to climb with your legs, not your arms. One of these developers in particular impressed me. Not necessarily with his climbing ability, but with his persistence in solving the problems. I think he spent the entire night on a single bouldering problem. He worked every move. He listened intently to any guidance that I offered and then was back at it with renewed vigor. And by the end of the night he made it all the way up! What is really interesting is that over the years of working with this guy, I’ve noticed that this is the same way he tackles programming problems: with quiet persistence and a never die attitude. I learned it is equally important to check in on him and make sure he has what he needs to be productive or give some piece of guidance, but at the end of the day he delivers.
I think software engineering is much like this situation where you are constantly being thrown at problems that you don’t know enough about. You are continually learning new things and being asked to communicate where you are in solving the problem and when it will be done. You need a combination of a love for what you are doing, maybe some base talent, the ability to learn new skills on the fly, and a whole lot of persistence. Your attitude as you approach the inevitable road blocks and set backs matters more than anything else. That is why programmers love climbing. Because they thrive off those situations of solving hard problems, dealing with set backs and ultimately accomplishing great things. It isn’t burdensome to us, it is drives us forward and onto the next challenge. We thrive off it.
I just finished releasing updates to the mobile 311 application into the iPhone App Store and Windows Phone Marketplace and felt inclined to write a bit about my experiences.
To give some brief background: Advanced Mobile 311 is a new product for Blue Dot that is providing the ability for citizens to easily report issues in their communities. 311 is a phone number set aside in the US for reporting non-emergency problems and our applications take this concept into the hands of smart phone users allowing them to mark the location of problems on a map (possibly using GPS), take a picture and submit a specific service request to their city or municipality. We certainly aren’t the only one doing this and some US cities like San Fransisco and New York have already implemented and been running crowd sourcing 311 solutions for a while now. City Sourced is working hard at this same problem with limited partnerships around the US. Much more can be said around the business models and players in the Gov 2.0 movement, but for now I’m more interested in the process of writing and delivering consumer applications which is something very new for me.
While it will take a week or so for the application updates I just submitted to make it through the review process in their respective store, you can check out the existing apps both in the iPhone App Store and the Windows Marketplace (requires Zune unfortunately). Both are free of charge so feel free to try them out! By in large it has been a positive experience developing both applications.
Prior to this, I had no real experience developing applications on a mac, using Xcode or writing Objective-c. Once I got over the C# to Objective-c transition and understood the basic paradigms of the development framework I was quite productive in creating the iPhone version of the application. I have been a mac user for a long time (really since I was a kid) so the OS is familiar to me and I intuitively understand the UX. The API and maturity of the iOS SDK is really very impressive and the 311 application fit very well into what the platform was designed to do. I actually created the iPhone app first (as Windows Phone 7 was just a rumor at this time) so it was a good exercise to have to think in another language. I think the one thing that I struggled with the most was memory management specifically around the didReceiveMemoryWarning and viewDidUnload paradigm. Debugging programs and understanding errors in Xcode is kinda like taking a step back in time when you are used to Visual Studio and .net development. The maturity of the iOS platform also means that you have to deal with supporting multiple devices and multiple versions of the operating system along with new devices like the iPad which have a different form factor and require a different set of graphics. All that said, it was quite pleasurable developing on my mac and the speed of the iPhone simulator is a breath of fresh air after using the WM emulator. The tools felt lightweight, high performing and easy to work with. I even dove in and did some of the graphic design for the internal menu icons and status bubbles.
Submitting to the App Store was really no big deal. Instructions to properly build and sign your application were straightforward. The only thing that bites me each time is that I chose to have a space in my application’s name “Mobile 311″ and this seems to be a continued source of problems when uploading to the Store (there are workarounds – comment if you are interested).
On the Windows Phone side of things we were lucky enough to be on the white list for applications that came out with the release of the physical phone. The Microsoft stack is really where Blue Dot feels at home and the development experience on the Windows Phone was very impressive (especially since I was basically working on a pre-release tool set and a version 1.0 product with limited access to real devices and all the other interesting things that come with being an early adopter). I must say that Microsoft was very supportive in this process, even providing consulting resources when necessary (although most of my issues were resolved by waiting for the next release of the tools). Development for Windows Phone applications is done in Visual Studio 2010 and in C# & Silverlight. I had never done any WPF or Silverlight development before, but the ramp up was pretty easy and I must say that it is a huge improvement over WinForms development. Visual Studio is a truly first class development environment and VS 2010 only raises the bar. The new wp7 emulator is fantastic (MS obviously took a page from Apple’s book here) – it loads very quickly and makes it easy to develop and debug your application. I struggled a little bit with things like the camera functionality (which does not work on the emulator) and understanding how the Task system works. It is really nice not to have to worry about memory management and the debugging tools are far superior to those in Xcode. Overall, it was very fun to re-create this application in another tool set/environment. I tried to make the app feel like a windows phone app and not an iPhone port and was pretty happy with how things turned out.
Submitting to the Marketplace was a very similar process to App Store submittal. The only thing that annoys me here is that the Marketplace holds all sorts of other stuff (not just phone apps) and you can only view things in the store you have Zune installed.
We are considering creating apps for the other leading smartphone operating systems, but until that happens I also created a mobile optimized web site that is reachable by any browser for submitting service request. Obviously there is no way to use things like GPS, but you can still submit requests to the system.
Finally, all of the server components are now up and running in Windows Azure, which is Microsoft’s cloud OS. Our server is architect-ed in a way that it can run both in a traditional hosted model and on Azure. The difference between our 311 system and some of the other offerings right now is that we are pre-integrated into some of the major ERP systems that cities already use to mange service requests. And by having our infrastructure in Azure we can offer a data stream to anyone without them having to purchase and provision servers or worry about physically infrastructure.
Reflector has gone south.
Lutz Roeder recently passed ownership of this free Utility to Red Gate Software and the new Reflector under Red Gate’s direction sucks big time. The first annoyance is that the auto update feature forces you to go get Red Gate’s version. You run reflector and it says:
This version of .NET Reflector is out of date. Do you want to update automatically?
It used to be if you said ‘No’ you’d just get to run the version you already have. Now the program just quits. No Reflector for you! If you say ‘Yes’ you are alerted that Reflector cannot be automatically updated and that you need to go to the Red Gate site to download the new version. Brilliant, now I’ve completely lost the context of what i was using Reflector for in the first place, the auto update appears to be purposely broken, and I need to do a manual install of the new version to even be able to use Reflector again. And because I’m running reflector via TDD.NET’s VS plugin I have to go searching my hard drive for where the actually reflector exe is located (C:\Users\<username>\AppData\Roaming\Mutant Design\TestDriven.NET 2.0\Reflector if you are interested).
And that’s not the end of it. Once you do get the new version installed you get dragged into a trial of the ‘Pro’ version which has VS integration and all sorts of fancy features. The problem with this we realized a few days later and after a lot of hair pulling is that it massively slows down .NET CF builds. Once you open a visual designer in a .NET CF project the new ‘Pro Reflector’ is doing something crazy in the background that takes a long time (30-40 seconds) causing your build times to sky rocket and the hallway sword fights to commence. Thanks to my friend AB for figuring all that out after disabling each of his VS plugins one by one to sort out the issue.
I used to recommend this tool to everyone, but with Red Gate at the wheel, I’m not so sure anymore. Anyone know of some alternatives? I miss Lutz’s version.
Seems like I’m not the only one with this gripe:
I’ve been reading through Armstrong’s book about Erlang as I mentioned last week, and decided to actually get my hands dirty and write some code. One the suggested exercises in the book is to write a ring benchmark program where you create a ring of N process and pass a message around that ring M times. The program should accept different values of N and M to vary both the number of processes in the ring and the number of times the message is passed around the ring. I decided I was going to do this both in Erlang and then in C# (which I’m much more experienced in) and compare both the code and some performance metrics.
I started writing the erlang program first because I wanted to try and solve the problem from an Erlang perspective and I though it would be interesting to try and think in a new language. Now, no laughing at my code, this is literally the first Erlang program I’ve ever written and I’m sure there are ways to improve this. Here is what the code looks like: (link to gist)
About 39 lines of code including white space and a couple of commented out lines. Next, I attempted to solve this same problem in C# and here is where I need to give some disclaimers and caveats. I knew going into this that there was no way that directly creating threads in C# was going to compete with the lightweight erlang processes. However, creating a solution that overcame this hurdle was a bit outside what I was trying to accomplish here so my end implementation in C# actually creates a thread for each node and uses and AutoResetEvent to provide a locking mechanism that allows the very basic passing of a message from one node to the next. I am sure there are issues with this, but here’s what I came up with. Actually the program is so much larger that it is hard to capture in a screen shot so here is a link to the gist if you want to see it in a better format. All in all it is about 140 lines including whitespace and my default C# formatting that I have setup with my Reshaper profile.
Now for some metrics! I’ll just present the basics here and you can run things on your own if you are curious. Just for the record, I took all these measurements on my Dell desktop (Windows 7 64bit, Xeon dual core 2.0 GHz, 8 GB RAM) although I did actually develop the erlang program on my mac (which was even faster than what I’m showing below).
Just a few words of explanation here. For the Erlang program, I wasn’t even able to measure a time in milliseconds until I got above 500 nodes in the process ring which is why there are no values there. The times for 10-100 nodes are in the microsecond range and aren’t worth showing on these graphs. For the C# program I started get OutOfMemory Exceptions when I got above 1000 nodes which is obviously due to the overhead of having 1 thread / node. Because of this there is no data beyond 1000 nodes. You can see that there is a massive difference between these two implementations even at the levels where the data does cross over. Creating 1000 processes in Erlang and passing a message around all 1000 processes 10 times took about 16 ms. Doing the same thing with threads in C# took almost 25 seconds.
If I were to spend more time with the C# program I could move to using the thread pool instead of discrete threads, and doing a better job of simulating message passing. However, the point is that Erlang has these ideas of concurrency built into the language constructs whereas in C# I’d have to create my own infrastructure to support similar features.
My last word on all this is about the difference between writing programs in the two languages. I uses Visual Studio and C# day in and day out, so writing that program wasn’t particularly difficult (plus I did it after solving the problem already once in Erlang). I do feel like programming in C# is often like writing a novel. The tools and intellisense are nice, but there is SO much typing that you have to do to get things done. Lots of files, lots of classes, many lines of codes. Even with intellisense, I often feel like my thoughts race ahead of what my fingers (and especially visual studio) are capable of doing. As much as I like VS, I do wait on it a lot.
I wrote my Erlang program in Emacs, which is a completely new editor for me (and fun to learn new key bindings after knowing vi, textmate and VS bindings) and it felt more like writing a piece of poetry than a novel. I though hard about the problem and the code I was writing, but did very little typing. Part of my slowness is obviously a lack of experience with the language, but in the end I felt like the language itself led me to solving the problem in a very koan like way.
If you don’t already know about Blacktonic you should check it out. They just got invited to Google I/O 2010 and have some pretty cool stuff to show off. These guys have built a very nice SaaS web presentation product (no browser plugins!), but what is really interesting to me is the real time web broadcasting technology they have created. Think: having the ability to broadcast stuff into any number of user’s web browsers all at the same time. This is not like everyone watching the same video on YouTube at once. The term floating around is the ‘real time web’ and I think these guys are riding the wave of the first real time web technologies and applications. Should be exciting to see what happens.
Google I/O Developer Sandbox: http://code.google.com/events/io/2010/sandbox.html
So I must confess this Monday morning to having spent the weekend very much infatuated with Erlang. I do not know how long this phase will last, but we might as well talk about it while its fresh. I’ve always had an interest in building distributed systems and writing software with concurrency. Some of my first explorations in these areas happened while working on the robots and laser where I built multi-threaded, multi-process and multi-node software systems to control a variety of robotic equipment while taking input from various sensor and human sources. I did this at a very low level: connecting DSPs running assembly and C to motor controllers and dedicated feedback loop processors to ‘high level’ general purpose CPUs running hard RTOSes with C++ as my language of choice. I learning about IPC and multi-threaded designed, wrote my own low level protocols and did a lot of bit shifting and binary arithmetic. Even in the applications I build today in C#, I’m always exploring the different aspects of concurrency and distributed processing. Snap sync is architected from the ground up to scale across multiple nodes and has a unique asynchronous processing model where the number of sync workers is not equal to the number of threads. Even after all this experience I still feel like writing multi-threaded, multi-processes, scalable code is very hard. There is so much that can go wrong and so much work to do in object orient languages to make sure you are using the proper locks and sync objects.
Erlang, however is specifically designed to be used for creating concurrent distributed systems with high availability. The capabilities to do this are built directly into the language constructs itself . It has been very exciting to approach the language from the perspective of having spent a lot of time building custom distributed, concurrent systems of my own. The simplicity and beauty of Erlang code to solve these problems is quite amazing. Now before I gush on let me say that Erlang is a tool for a very specific problem. There are many different programming tasks that i would not choose Erlang for like creating a rich client UI or to do front end web development. In the same vien, starting to learn Erlang has made me wonder about the places I’ve been using the wrong tool for the job.
I’ve really only just begun to learn the language. I’ve been walking through some tutorials, built a few small programs, etc. I went ahead a bought Joe Armstrong’s book and screen casts from the pragmatic programmer and would highly recommended them to anyone interested. You can download Erlang here. This is a very interesting article showing how a web server written in Erlang (Yaws) compares to Apache in handling concurrent requests. The net net of the metrics is that Apache (running on a single server) dies at about 4,000 concurrent sessions. Yaws on the other hand (same server) is still kicking at 80,000 concurrent sessions. Impressive.
Maybe snap sync could use a little Erlang love? …