Chris Cyvas

The Elusev™ UPS® Shipping Provider is now available at dashCommerce.com. This is our first vendor / developer product (there are a bunch more coming), so be sure to check it out. This provider gives you the ability to use UPS with your dashCommerce store!

From the product description:

The Elusev™ UPS® Shipping Provider extends the shipping options in a dashCommerce 3.0.X web site.  The provider allows your customers to select a UPS® service option and then calculates the shipping price based off current UPS® rates.  The provider is configurable through the administrator section of your dashCommerce site.   Users must have a UPS® shipper account. 

Today, we have released the Mettle Systems Authorize.Net Payment Provider! I know a lot of folks have been asking for this, so it is now available at dashCommerce.com.

In addition, we have released the Mettle System Order SubTotal Shipping Provider. This is another provider that has been repeatedly requested. This provider allows you to specify a shipping charge based on the order subtotal. In addition, you can offer different services for the same order subtotal range. For instance, you could configure the Order SubTotal Shipping Provider similar to the following:

In addition, we have pretty quietly released the Mettle Systems dashCommerce Currency Rate Web Service, which will provide your store with currency exchange rates. These rates are updated daily so you can be sure the rates are current and accurate. In addition, you don’t need to be running a dashCommerce store to use the dashCommerce Currency Rate Web Service!

Finally, we have lowered the price on the dashCommerce Tax Web Service, which @ $100.00 / year, is by far the cheapest thing you will find that will give you tax rates that are updated monthly. However, because of our licensing agreement, we are only allowed to offer this service to users of dashCommerce.

Finally, I know there are some other vendors that are working up some additonal providers. I know Naz has 4 that he is preparing for sale!

Thanks for checking in with us and visit dashCommerce.com for more information!

For anyone that follows the forums pretty closely, you’ve probably run across my trials, tribulations, and lamentations about SubSonic. The crux of that whole issue is tight coupling. Most of us have heard that tight coupling == BAD, loose coupling == GOOD. Tru Dat! And to be fair, it’s not just SubSonic that is tightly coupled. All of dashCommerce is. I knew this when I designed it because I didn’t want the community to have to suffer my ego – meaning, I wanted to get a product out that was functional and useful – not something that shows off what I can do but fails in execution. In addition, I didn’t think the community was demanding any of the Developer Kung Fu that gets introduced when writing a loosely coupled application. To be sure, it introduces a lot of indirection, and if you don’t know where to look or if you aren’t familiar with things like Dependency Injection or Inversion of Control, then you are going to get confused – and fast.

Com’on Baby, loosen up . . .

dashCommerce is growing – and fast. My version of dashCommerce is different than the released version – I am pretty much constantly working on both versions – and that growth is resulting in something that is becoming more and more difficult to manage. The determination is that dashCommerce has finally grown to a point where the tight coupling is proving to be a hinderance to the ongoing development of the project. So we are going to be taking a crowbar to dashCommerce and prying apart all the bits, then we’ll put them all back together using some Dependency Injection.

Oh Please, not another DI fanboy!

I’m not. In 2005, when I was at Intuit, I was on the architecture team that was developing the next generation platform for the product – a large commercial business application (900+ db tables fully installed – freakin’ huge). Our charge was to come up with a platform / architecture that could serve the products for the next 10 years. In addition, we had some pretty amazing requirements. Customers could change the db schema, they could customize forms, reports, etc. We had row-level security, both licensed and hosted environments – you name it, we were charged with figuring it all out. In addition, customers could customize parts of the software, swap out providers, etc. Oh, and we had a consulting group that wanted to be able to drop in custom components. We were building the framework ontop of which all of our products would be built. It was a huge responsibility – the business was counting on us to execute. In our quest to figure this all out, I came upon Spring.NET and read about Dependency Injection. At the time, I thought: “All right, let’s see what all this is about.” Expecting to be completely underwhelmed, I set about creating a small sample application. It took about an hour to work it up – muddling through the docs and not really grokking what the end result would be (which results in a lot of second guessing) – but when I got it working, I was giddy. And the impact was immediately apparent. And so off we went with it. But I haven’t had occaission to use it since.

Unity can only be manifested by the Binary. Unity itself and the idea of Unity are already two. -Buddha

So, in looking over the selection of DI containers that have made their way into the .NET community, I knew I didn’t want to go with Spring.NET. Why? For no other reason than Spring.NET is an enormous application development platform and its HEAVY. That’s not a bad thing, but I don’t think it’s a good fit for an application that is going to be easing into and introducing DI. So Yitzchok and I started chatting about DI containers and which ones we wanted to look at using. Unfortunately, the decision was kind of made for us by our ongoing requirement to stay as Medium Trust compliant as possible. Asking folks to sacrifice security for our DI container choice wouldn’t pass the smell test IMHO. The only DI container that I found that expressly addresses Medium Trust in its documentation is Unity. So I played with it and it turns out that, so far, it’s working out nicely. It’s lightweight, it’s not trying to be more than what it is, and the API is friendly.

Programmtic Configuration vs. Configuration Files

There seems to be a trend in the .NET DI community to move away from configuration files and move toward programmatic configuration. IMHO, this is a mistake – you are sacrificing application flexibility for developer convenience. So, we will probably roll with configuration files, which makes sense to me, especially when considering our provider based model, and just as important, our budding vendor community. Being able to drop an assembly into the bin directory, changing a config file, and off you go – well that’s just precious.

So, if you aren’t sure about DI, or unsure as to what this means, grab Unity and work up a small sample. Do it with config files – it loses it’s impact if you do the configuration programtically – and let me know what you think.

I’ve been wanting to write this post for a LONG, LONG time and I figured that the only way it was going to happen was if I started it, so this is the start.

It hasn’t been what I would call smooth, but we got to 3.0. Not bad for a January release. But it’s out, and it’s done and now we can move on to new stuff.

Before we get to any discussions of new stuff I wanted to say thanks to several people, and some companies for helping the project:

First, Yitzchok and Naz have been instrumental in bringing some great functionality to dashCommerce. Please show them some gratitude. Other’s, listed on the home page, have offered up dashCommerce translations. Please show them some respect as well, and if you are from their country, or use their translation, please send them a word of thanks. In addition, MaximumASP provides hosting for our site, free of charge and I am very grateful for that.

Is dashCommerce a successful open source e-commerce platform?

This is one of those things that obviously concerns me a great deal, because at the end of the day, if people can’t use the product to sell stuff and make money then it’s all for naught. Some folks determine the success of a project by the number of downloads. To me, that’s a pretty misleading number. So how to determine the effectiveness of dashCommerce? Well, that’s pretty easy – who’s making money and how much?

This is where PayPal has been great in helping us out – getting some of the numbers together. When I took the project over in early 2007 I had no idea how successful this project had been, even though there was plenty of forum activity (not always a particularly good thing), there was no visibility into the numbers. So, when I took the project over, I asked PayPal if they could compile some sales numbers for me for 2006, 2007 and then, recently, I asked them for the 2008 numbers.

The good news is that dashCommerce is definitely moving in the right direction. In all of 2006, there were about $850,000 worth of transactions pumped through PayPal. All of 2007 saw steady growth and with the release of dC 2.0.1 and dC 2.2, there were considerable upticks. Now, with the release of dC 3.0 and dC 3.0.1 we are pumping through over $2 MILLION A QUARTER. That’ll work out to over $8 Million a year. So in the last year and half we have seen 10X+ growth. Also, keep in mind this is only PayPal transactions. For all the other payment providers out there that people use – well it stands to reason the numbers are considerably higher.

There are also other measures of success of the project, but they are more anecdotal and less concrete. Now that dashCommerce is localizable, there is an uptick in the international forums and there is a steady flow of translations coming in from community members (Polish is coming!). Also, community contributions are up and people are continually offering up patches. Patches are key to an open source project – you need that community involvement and we are getting great contributions from community members. I am actually behind in applying some of the patches, but they will get applied for the next rev. Also, there has been some activity in folks offering up partial patches for features that people would like to see. While these won’t get applied (because they are partial implementations), I think it is very positive that there are folks out there willing to help other community members by offering up partial patches – it definitely gives you a head start.

Finally, the long terms success of an open source project of this size depends on financial support from the community. Donations have not been a successful avenue (in general) for dashCommerce, so we started dashCommerce.com to offer hosting and additional products for the platform. These efforts have been more successful and the product offerings continue to grow. One thing I am particularly excited about is that we have 10 vendors that have signed up for offering add-ons and providers for dashCommerce. This is a key part of the dashCommerce strategy as we understand that if an open source project is going to seek a revenue model, then the project will be even that much more successful if we share that revenue model with the community. It just makes good sense that many could benefit from this model. With that in mind, I’d like to call your attention to the dashCommerce Tax Web Service and the new dashCommerce Currency Rate Web Service. Both of these products have their markets and they provide very important functionality in their respective markets for a great price.

So that’s were we are right now. Everything is moving in the right direction and there is always more to do!

For lovers of reggae, you should check out Damian Marley – Welcome to Jamrock. It’s a great blend of reggae, hip hop and soul. Good stuff!