Archives
-
Dopewars for the BlackBerry
Huh? Dopewars? BlackBerry? That's not SharePoint. That's not Agile. Am I reading the right blog? Yup. You are. Really.
It's been awhile since I blogged here as I've been wrapped up in Baby 1.0 and a slight vacation off the grid in British Columbia (with 300 photos to pull off the camera and sift through). However I thought I would post this here as it is development related, just not my normal train of incoherent thoughts and creations.
A couple of months ago I got a new cell phone and decided on the BlackBerry Curve for a variety of reasons. Constant connection, compact, cheaper than the iPhone, etc. It was a toss up between the BlackBerry and an HTC Windows Mobile phone. Of course the Windows Mobile would be nice since I'm a bit of a Microsoft guy, but the BlackBerry won out in features and reliability. Of course, what's the first thing you do when you get a SmartPhone? Why, hunt for games silly rabbit.
There I was combing the BlackBerry archives looking for something good and came across DopeWars by Mark Sohm. I installed it and was immediately taken back to my BBS days when I ranked high in the echelons of the digital drug dealer world. The game was fun and would let me kill the hour ride on the train to work. The game was well done, easy to play, and adhered fairly true to the original although with it's own conversion to the UI constraints imposed by the BlackBerry. Still, it's fun and IMHO a good app.
Anyway, the development bug got to me and I discovered that BlackBerry apps were Java based. Not a horrible language (beats the heck out of C and the PalmOS that I played with years ago) so I set out to create my development environment and try my hand at building BlackBerry apps (still trying to build a CCTray for the BlackBerry). The SDK documentation was pretty good and contained a wealth of examples but for me, I really need a good example to pull all the bits together.
That was a bigger challenge, as anything out there in the open source land was pretty sad (from the Java/BlackBerry perspective). Lots of samples, but nothing that either a) worked or b) was a good example to understand how to glue things together. Most samples were sparse and the ones that were quite involved were so convoluted they looked like a poor mans attempt at converting Visual Basic code to C to Java (or some such silly thing).
Then I thought about DopeWars. Maybe it was another fish in a sea of crap code, but then again maybe not. I hunted down the files but couldn't find the source anywhere. So a little Internet detective work and I tracked down the author, Mark Sohm, who just happened to work for Research In Motion (the makers of the BlackBerry). Someone who works for the company writing a game? Why not. Mark had put the app together in his spare time and after a few emails I nudged him into releasing the source code as an example of writing a Java game for the BlackBerry.
A few weeks later and yet another new SourceForge site is born. You can download the binaries for DopeWars for your BlackBerry Curve (well, any Java enabled BlackBerry with colour capabilities) from here. The source code is up there and available via anonymous SVN access (instructions here). I will be putting together a source code zip file for those that don't have (or don't want to) install a Subversion client. Note that there was already a "DopeWars for BlackBerry" site on SourceForge but it consisted of C++ code that doesn't seem to compile and doesn't have a binary release so I considered it abandoned and just made another one.
I won't be doing too much development on the project (I barely have time for my current projects), but being open source (released under the MIT license) anyone can contribute to it. Feel free to fix bugs or add enhancements. Via SourceForge you can post suggestions in the forums or use the tracker (bugs, suggestions, etc.) or email me if you would like developer access to the project (just include a note about what your plans are for the code). There is one bug that bugs me and that's when you finish the game. You end up finishing when the day turns 31 rather than at the end of the 31st day. Personally I think it should let you finish any transaction on the 31st day then end. Otherwise, it's quite stable code and well separated (for a BlackBerry Java app) in terms of responsibility and separation of concerns.
So give it a look see if you have a BlackBerry, are interested in what a BB app might look like, or just want to poke around. Who knows, you might like it.
-
Problem with if block using interfaces
We came up with a weird error that I've never seen before today. Here's a customer class and an interface to a strategy class (ICustomerStrategy) with two concrete implementations (GoodCustomer, BadCustomer):
1: public class Customer
2: {
3: private readonly int _creditLimit;
4:
5: public Customer(int creditLimit)
6: {
7: _creditLimit = creditLimit;
8: }
9:
10: public int CreditLimit
11: {
12: get { return _creditLimit; }
13: }
14: }
15:
16: public interface ICustomerStrategy
17: {
18: }
19:
20: internal class BadCustomer : ICustomerStrategy
21: {
22: }
23:
24: internal class GoodCustomer : ICustomerStrategy
25: {
26: }
In the consumer class we have a method called GetStrategy that returns an ICustomerStrategy object.
This statement using an if-block works fine:
1: public class Strategy
2: {
3: public ICustomerStrategy GetStrategy(Customer customer)
4: {
5: if (hasGoodCredit(customer))
6: {
7: return new GoodCustomer();
8: }
9:
10: return new BadCustomer();
11: }
12:
13: private static bool hasGoodCredit(Customer customer)
14: {
15: return customer.CreditLimit > 1000;
16: }
17: }
However this statement using the conditional operator doesn't:
1: public class Strategy
2: {
3: public ICustomerStrategy GetStrategy(Customer customer)
4: {
5: return hasGoodCredit(customer) ? new GoodCustomer() : new BadCustomer();
6: }
7:
8: private static bool hasGoodCredit(Customer customer)
9: {
10: return customer.CreditLimit > 1000;
11: }
12: }
The only way to make it work (thanks ReSharper for the tip!) is to cast the first object to the interface like so:
1: public ICustomerStrategy GetStrategy(Customer customer)
2: {
3: return hasGoodCredit(customer) ? (ICustomerStrategy) new GoodCustomer() : new BadCustomer();
4: }
You can also make it work by using a base abstract class rather than an interface, but I prefer the interface driven approach.
So the question on my noodle is... why?
-
The Death of a Community?
When I started SharePointKicks a little over a year ago, I thought we were starting a good thing. Gavin Joyce had created a small community around DotNetKicks and we started building up sister sites to it, which included SharePointKicks. The idea was solid. Community driven content, allowing you dear reader the ability to bump up the stories you thought were worthy so they were there at the top, waiting to be read by others who were looking for the good stuff. Lots of signal, less noise.
As with any community, it had to start somewhere. It was me posting various stories from the SharePoint blog-o-sphere and getting the word out. However it's not something anyone should do full time. Do you think Kevin Rose feeds digg with all of it's stories these days? I'm not comparing SPK to digg on the level of popularity but rather concept, since they're both the same, although SharePointKicks is more specialized for the IT crowd.
After a month or two I felt the site had gathered up enough momentum and people would drive. Guess I was wrong. Back in May I posted a note about how the community had fell a little by the wayside and was suffering for it. At that time I thought there was still enough interest to keep the site going, however today it doesn't seem like that's been the case.
So here we are looking into the chasm. The last popular post was submitted over a month ago on the site. There are a few people that post and the items trickle in, but that's it. They trickle. Like a dried up well with little life and less interest. And most of the entries are spam these days, which I've been cleaning out but it's a time-consuming job for which I don't have the time to do.
From the looks of it, the SharePoint community (that would be you guys, myself included) doesn't seem to want to keep this beast alive. Or do you? Like the infamous Andy Kaufman vote on Saturday Night Live in the 80s, I have to ask the question. If there isn't going to be an overwhelming "oh, don't take our SharePoint kicks away!" from a large number of people who are committed to seeing the site grow and flourish, I'm going to shut down the site. We'll redirect the domain name to DotNetKicks, which continues to move along nicely, but ultimately shut the site itself down. It's a shame as I thought the site would make a difference for those wading through SharePoint information out there but I don't see that it is. I know there's plenty of news stories, but I can't keep up the pace of posting them all myself so if the users of a community can't drive a community site like this then I don't see the point in keeping it around.
Let me know what you think via comments on this post or through email if that's your thing.