Eat your own dog food

Wednesday, October 27, 2010 Pablo Santos news , solaris 2 Comments

Yeah, that's what we're doing, eating our own dog food.

We just migrated our Plastic SCM internal server from an old Fedora Core 4 (yes, that oold... but is our server and we love it!) running on x86 hardware (Xeon) to a SPARC Solaris 10 box. A big endian 64 bits SPARC box!! :)



The previous configuration was running Mono + Bohem GC and Plastic storage was an external Oracle database (yes, separate Plastic and database servers, again, eating our own stuff), and now the configuration is as follows:

SPARC Solaris 10 server

Mono 2.8 + sgen (yes, sgen!!!)

Plastic SCM 3.0.7+ (internal build, not out yet)

SQL Server 2005 external database (yes, no make things even funnier we're using a little-endian db :P with a bigendian system, in fact we found a bug in our GUID conversion code while reusing the old db, something that wouldn't happen if you create your dbs with the bigendian server, would only happen if you plug 'old' databases created by littleendian boxes to it).

So far the old iron is behaving really well, it's only been one day in real production (after weeks of load testing and so on, of course) but no known issues yet. It's not as fast as our previous server but that's because we're not using very strong hardware. I'd like to see it working on a beat like this.

Although obviously SPARC hardware is not the most demanded at all, we're committed to support it since specially big customers tend to ask for at least a few servers running it... It's been supported for years already but now we're really about to have better packaging and so on, I expect to have an installer on the coming weeks (so far we installed manually).

Will let you know how it goes... :P

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

Mono 2.8 available for Solaris 10 SPARC and x86

Thursday, October 21, 2010 Pablo Santos mono , solaris 0 Comments

We've just released (thanks to Dick Porter, our resident mono hacker, who had to make some fixes on the sgen implementation to make it run on SPARC) the Mono 2.8 packages for Solaris 10 (x86 and SPARC) and OpenSolaris.

They're available to download here: http://www.go-mono.com/mono-downloads/download.html



Installing the packages is not hard, just a matter of playing with pkgadd after downloading them. It will warn you about missing dependencies and so on. I installed the SPARC ones yesterday on a clean box and there are the ones I had to download (from sunfreeware.com) and install:

libgcc-3.4.6-sol10-sparc-local

libiconv-1.13.1-sol10-sparc-local

libintl-3.4.0-sol10-sparc-local

And then I was able to install mono successfully.

Mono installs (by default) on /opt/mono so here's what I use to launch it: LD_LIBRARY_PATH=/opt/mono/lib /opt/mono/bin/mono

How did we test it?

We run our entire PNUnit test suite on Solaris to validate the build (and Plastic) and we also run load tests for days using a Solaris SPARC server (both with Boehm and sgen (MONO_GC_PARAMS=major=copying LD_LIBRARY_PATH=/opt/mono/lib /opt/mono/bin/mono --gc=sgen) with very good results.



As a side note, this Plastic server that you see up and running is using a... SQL Server database as backend... so, yes, the Mono SQL Server implementation works even using bigendian software!! :)

MWF is available too

We've included the libgdiplus library. It is stable on OpenSolaris but we weren't able to make it stable enough on Solaris yet. Just time to get some nice screenshots!

Future

We plan to continue building and supporting Mono on Solaris, both x86 and SPARC, since it is key for some important deployments.

Side notes

This 2.8 Mono release is the most "multi-platform" I've seen so far. I'm able to successfully run the entire Plastic testsuite under Solaris (x86 and SPARC), FreeBSD, OpenBSD (first time I'm able to do it!), Mac OS X (both PPC and x86). So... yes, expect some default packaging on OpenBSD in the coming months!! :)

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

Welcome crazy monkeys!! - Mono on Solaris SPARC!

Tuesday, October 19, 2010 Pablo Santos mono , solaris 0 Comments

Yeah, yeah, yeah... being able to develop super-cool Mac OS X applications with a modern programming framework thanks to MonoMac is great. So great. And I'll bet you'll be able to design really cool user interfaces without getting your hands dirty with ObjectiveC code... really great. And to be honest, I've to admit I'm eager to develop a Plastic SCM native GUI for Mac taking advantage of all that...

But, let's face it! Real hackers don't do that!! :D

No, you know what's really "hacker's style"?? Well, I'll tell you: the real thing to do is getting a 10 years old big-endian iron (yes, big endian is for real coders, whatever mainstream cpu you will easily find around your office doesn't make it, just that... :P), you know, something like a SPARC Blade 1000 box, log into it, feel the "agressive old fashioned Unix flavour" and then code on it using a very cool 21th century programming framework like... Mono!!! Yep, that's the thing: old counter-intuitive mix of operating system and hardware mixed together with great top class programming techniques...

Yes, everyone is doing the opposite: newest x86 based super multi-core processors running old-style C code cooked yesterday... but they're just simply wrong! All of them!!

So, that's why we've just released the latest and greatest Mono 2.8, including the new superb Generational Garbage Collerctor (sgen) for Solaris 10 SPARC!!! Welcome to the jungle of the Crazy Monkey people!!!!

(x86 version also available for weaker minds using off-the-shelf hardware)

And not happy with that... we've compiled and tested WinForms support too, and run our beautiful Plastic GUI on it... ok, did you ever think Plastic looked great on MacOS X??? Come on! Take a look at how it shines inside the CDE window manager and... cry!!!





Enjoy!!

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

Parallel development with Plastic SCM and Jira

Thursday, October 14, 2010 Pablo Santos integrations 2 Comments

Eons ago we published a short "how-to" explaining how to link Plastic with Jira.

Well, things are a lot easier now and instead of dealing with config files we've grown up to the "wizard age" (ok, if you're a hard-core hacker you can still play around with the files), and setting up the connection is... well, straightforward.



Setting up the connection is actually easier than explaining what's going on (which is not difficult either). Basically, what we do implement with "branch per task" is a workflow where:

every issue (or new feature) in Jira will be mapped to a branch in Plastic. This way the link is pretty easy to set up and you're free to embrace full parallel development using as many branches as you want. For a full explanation about why branch per task is better, just click here.

alternatively you can link every issue with a changeset (as you'd do with Subversion, for instance). We implemented this for the sake of completeness but honestly, I'd always go for pure branch per task.

There are many advantages on using branches instead of changesets to resolve issues:

better isolation

you're free to commit as often as you want because you're never touching other's branches

you keep the mainline pristine

it's fully compatible with distributed development

The branch explorer will decorate every branch with info coming directly from Jira, giving a "task oriented" view to the entire repository evolution.



Enough for an introduction, let's jump on the video which will give you a very quick overview of how it looks like (it's recorded in 1024x768 so better if you jump to full screen):

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.