Realtime Deployment � Microsoft .Net and Smalltalk
I have recently been working with Gal Zsolt of CalmoSoft on improving several of the Vista Smalltalk tools.
As I have noted in previous blogs, almost all Smalltalk scripts have now been moved to the Vista Smalltalk Wiki, and load streams are generated dynamically from code contained in Wiki pages. Because of this change, it is now practical to do widely distributed code development. When CalmoSoft makes a change, I can test the code immediately - and vice versa.
The Wiki software has features like “access control lists”, “user account management”, and version control. It is also free, as are the Php programs that I have created for it.
And it is not only the Smalltalk code that can be developed in this way. All of the Xaml files used in Vst applications are also dynamically loaded from the Wiki. The Wiki technique should be ideal for graphic artists to participate in creating applications or games.
Vista Smalltalk is capable of distributed development and realtime deployment.
So I have been using DokuWiki for a good year and half and LOVE it for LOTS and LOTS of really good reasons such as those outlined above. Syvlain, Uche, and myself have been chatting on and off for much of that same time span about how much potential DokuWiki holds in regards to distributed application deployment, integrated distributed documentation deployment, etc… so when I read the above post from pfisk I thought “huh… Cool! It looks like another wiki engine has “seen the light.”
DokuWiki ROCKS! :D
NOTE: There are simply too many reasons why DokuWiki ROCKS!, and not enough time at the moment to list them. As soon as time allows I will try and update accordingly. In the mean time, here’s a large chunk from a related post** from a while back entitled,
I was first introduced to darcs by Bruce D’Arcus and, to be honest, my first impression was “Yeah, yeah, you just like it cuz’ it sounds like D’Arcus.” Of course I was being sarcastic, but it still took me several months to finally be convinced to look into what he continued to rave about…
Guess what?
Bruce was right…
darcs Kicks Source Code Control A$$. As such, here is my top five(5) list as to the reasons why:
Reason #5 : It’s built around the concept of Decentralization : Decentralization, a central(ironically) concept to Grid Computing, is something I personally believe to be a massive piece of our computing future. So why not start getting used to the idea by using the technologies available now that are built around these computing ideals instead of waiting until the future *IS* now and being forced to jump in head first just to get caught up.
Adding to this, any darcs repository can be a Master repository. So if I “get” (darcs is partially influenced by HTTP-based verbs [1]) a repository and “pull” down the patch updates from one repository I am not forever bound to that repository for any and all future updates. If a buddy and I want to work on a certain piece of a larger project over the weekend and we would rather get things working between the two of us first before updating the projects main repository, no problem. Just tell darcs to “pull” or “push” the patches from the a different location by appending it to the command line.
So instead of:
> darcs pull
You would type:
> darcs pull http://my.buddies.darcs/repo-location
or to push (via SSH, another reason Darcs Kicks Source Control A$$)
> darcs push http://my.buddies.darcs/repo-location
Of course, just because s/he “push”ed me changes doesn’t mean I have to accept them. But I’ll let you look into how and why this is important via the community wiki or manual, two well written and immensely helpful resources.
Reason #4 : It’s simple. simple, Simple, SIMPLE! : Another way to say it might be darcs KISSes A$$, but ummm… maybe thats not quite the term David Roundy (darcs Inventor) would prefer people using. I won’t go into the exact details as to what I mean as alluded to above, there is already fantastic documentation on the subject contained at the community wiki and in its manual. I highly recommend both as a good starting point for all things darcs.
Reason #3 : Numeral Versioning is GONE!. : Instead, versioning is based on the textual explanation as to whats different about it. In other words, when I create a new patch, instead of having the SCC engine take my text based explanation and attach it as a note, it uses what would be the note and makes that the focus. The internals of darcs will take care of knowing which patch was added and when, and you can certainly abstract that meta information if you so please, but what does a number tell me beyond “this one comes after that one?” At the command line (GUI Tools are beginning to be developed as well) darcs requires you to give each version a text-based description, and even allows for extended descriptions which it then attaches to the patch such that you can add an entire inventory of changes if there happens to be a significant number added since the last patch.
Now this doesn’t mean because number-based versioning isn’t a part of darcs that you can’t version your releases. But I don’t think I need to explain to anyone reading this blog why “released” software is different from “under-development” software. Obviously “Windows ‘This patch contains the fixes to … as well as all of these new features …’” is not something the marketing department is going to be buying into anytime soon.[2] But as I mentioned there is a big difference between “released” software and “under-development” software. I can probably leave you to fill in the rest.
Reason #2 : Built in software delivery mechanism and email updates : When you first initialize a darcs repository it asks you for your email address. The purpose? Because of the decentralized nature of darcs, David Roundy built into darcs the ability for people to email patches to the person who created the repository (or at least to an email address set aside as the proper address for updates to be sent for this particular repository.)
In regards to software delivery mechanism, you just have to start using it and you will begin to see what I mean. Againg, its simple, Simple, SIMPLE!
SIMPLE!!!
Reason #1 : darcs is built using Haskell : As many people are beginning to understand because of the Linq and XLinq technologies recently announced by Microsoft (which have an extensive amount of Haskell influence, Erik Meijer, one of the central designers of Linq and XLinq is also one of Haskells language designers. Obviously this had an influence in Haskell finding its way into Linq and XLinq.) As Kurt recently stated in an IM conversation “Haskell is a helluva language!” Another good friend of mine, Dimitre Novatchev, stated a while back “I have Haskell and XSLT, why do I need anything else?” In case you don’t already know, Dimitre’s FXSL Functional Language Extensions for XSLT 1.0 and 2.0 are DEEPLY rooted in Haskell. Of course, any platform that has a Haskell compiler means that darcs will run on that platform. Last time I checked, that was a lot of platforms. ;)
I don’t know about you, but when people like Dimitre, Erik Meijer, and Anders Hejlsberg spend as much time as they have building Haskell-like extensions into two of my top three favorite languages (Lisp, XSLT, C#, in that order :) I stop questioning and simply accept what they are telling me.
Now you might ask “If Dimitre, Erik, or Anders told you to go jump off a bridge, would you?” to which I would reply “Um, yeah…” with a “what are you, a ******* idiot”-based undertone to it.
‘Nuff said.
—
** How is the above related to DokuWiki? Beyond the fact that DokuWiki is available via a Darcs repository, there is a plugin manager in which you can manage plugins via the particular plugins Darcs based repository. So, in other words, whenever a new update is available in the plugins repository, the management console will make this known and you can immediatelly update the bits by simply clicking the “Update” button.
It’s a wonderful, WONDERFUL thing! :D
