Homepage

This is mostly a note to myself but I hope it will help others.

I was recently setupping a server (Win2008, IIS 7 and MS FTP 7). I spent a lot of time wondering why I wasn't able to logon using a FTP account. I was sure permissions and configuration were correct but I couldn't login anyway. I was going to pull all of my hair out when, all of sudden, a magical idea: check if my FTP user had the same name of my server. Which was true!

The crazy thing is I was able to logon but then it was like my user was loosing its status once I did that. Basically, allowing all users to access my folder was working but once I removed permission to all and only allowing my user, it looked like that user wasn't being recognized by my server while still allowing to logon.

I don't know if this is by design or if an account using the same name machine is using has some kind of special meaning. Anyway, remember to never call a FTP user the same way you called its hosting server. Just crazy... !

I'm still here working on Rainbow while I wait for ThePlanet to repair one of their datacenters which blew up tonight. Now that Rainbow becomes viable again, it's worth to waste some times to understand which kind of technologies can be nailed into this beast to improve it. Having .NET v3.5 available (which basically means speed improvements, an huge class library, LINQ and so on) is already good thing even if we cannot have MS AJAX compatibility as of now.

This is basically because of Rainbow using RewritePath functionalities (which aren't compatible with UpdatePanels now) and Rainbow page-flows registering controls (and hence, extenders) before PreRender event, which is not supported by MS AJAX. Bad luck, uh? :-|

Anyway, there are many AJAX frameworks which can be probably nailed in though MS AJAX was great because of UpdatePanels and having the ability to turn standard controls into AJAXed ones. Anyway, I won't go into newer Rainbow versions, that is the ones community (well, if you can call a few developers a community...) is working on. They didn't document their changes and so it's very dangerous to use that version as that's not a stable version, plus without people documenting changes you actually don't know what changed, what could be wrong and so on.

Rather, I will start from this version (1881e for .NET v2.0/3.5) to apply my changes. As I wrote yesterday, I will probably use this as a basis for a new CMS which I will release and that my company will use as its basic framework for portals.

There is MUCH work to do about Rainbow, though this application itself is pretty solid and has proved to be stable during past years and that's why I'd like to start from this version instead of foggy unstable versions.

Most-needed changes:

• integration with .NET 2.0 system services like Membership, Roles, Sitemap, Profiles and so on. This would require to develop a few providers and I'm aware such providers already exists from the new version (community driven). Could evaluate to include them as this is really a tedious job, not a very specialized one;
• migration of data-aware functionalities a new centalized way to access database and support data to be stored as XML files instead of inside database (a la MWPSK). This looks to be a very difficult job as legacy modules should survive;
• migration of multiple theming system delivered by Rainbow as of now and integration with ASP.NET Master-pages and theming system. Theming system is the weakest one in Rainbow now. Multiple engines are supported (ZEN and standard ones), they're difficult to implement and hard to administer, plus, while they're stable, they tend to be a problem for new features. Integration with ASP.NET theming system while still retainig ability to apply skins to single modules, that's my goal.

Those are changes I'd like to do as soon as possible. Re-engineering Rainbow (or new CMS to be born from it) to support multiple databases could be an idea though not a priority. However, if any LINQ will be throwed in (not sure yet... there are other entities libraries which could be very useful to speed up data access, like CoolStorage), LINQ providers could guarantee support for multiple storage types. But I don't think this is a top-priority as ASP.NET developers mostly work on Windows / IIS / SQL Server now and most hosters (like us) support free SQL Server Express.

My idea is to get what it's done and merge it (MembershipProviders and so on, for example). The main portal, though under a different name and (perhaps) license, will still be open-sourced of course but I'd like to have more control on things. To play it in a fair way, I will post my final project on CodePlex: that will be easier to mantain than SVN plus CodePlex emerged as a very big community for .NET Developers.

So stay tuned for more news ;-)

Woah! I finally solved my problem with Rainbow v2.0 which was preventing me from upgrading all my Rainbow-based portals to framework v2.0/3.5. Had to band my head into debugging Rainbow and Esperantus for a couple of days but then I succeded! You're just reading this on my Rainbow v2 compiled using .NET framework v3.5.

I will perform a few tests, including letting this website run for a couple of weeks to check if everything goes smoothly but this basically means I can convert my main websites, including corporate portal for my company, to framework v3.5, which is really HOT ! We won't need to switch portal system and this means not loosing search indexes references to existing pages, while still being able to incorporate new features (like AJAX, LINQ and so on). That's basically an hot news for us!

This means that, if our tests with AJAX and a couple of other technologies will go fine, we can consider Rainbow v2 as basis for our future websites and portals, something I wasn't so sure of just a few weeks ago.

Sure, Rainbow needs much work as most of its parts are quite convoluted and outdated, it doesn't support many of new features (like providers for Membership, Roles and so on) but basically we could work on that while still keeping original websites based on Rainbow v1.x active and running and convert them to v2.

This can be done because Rainbow is out-of-the-box very fast (check this website as a reference) and versions compiled for new frameworks (v3.5, for example) look benefiting from this upgrade. Newer .NET versions look much faster than old v1.1 even for code which doesn't use many of the new features introduced since v2.0.

In next 2-3 days I will try to perform local upgrades for our main corporate websites and tests for AJAX modules. If I can nail AJAX modules inside Rainbow, I will probably use v2 (the one released as stable / production) as the basis for a new CMS. While Rainbow roots must be acknowledged, it's time to have an in-house solution which heads towards newer version of the framework. And since newer code has been released using Apache 2.0 license, it looks like there will soon be a Diavolo (or Diablo or Diabolo) CMS published on CodePlex ;-)

There's always been a debate about advantages of OpenSource development. Among supposed advantages, there's a widespread (at least among OSS fanboys) that OSS speeds innovation, something I was thinking about lately. There's no doubt that many people contributing to a single project is something which speeds up development and, in theory, could reduce bugs in software. The latter is not an axyom as you can easily check in real life by looking at current OSS projects, many of which sports many many bugs, often more than the average in closed-source projects. So keep in mind that life could be much different than marketing promos.

But let's just get back to innovation. While it could seem easy for an "innovative concept" to enter an OSS project, its way to main code is usually not so straightforward, expecially when dealing with larger projects, where stability is worth much more than innovation but other problems lie in OSS development model itself as that model helps small contributions and also definitely helps porting code to multiple platforms. For example, how many versions of PHP have been ported to other systems? I was thinking about while reading about this story about GRUB 2 and PHP 5 being ported to Syllable and I was thinking how OSS simplifies porting software but I was also thinking about how Syllable had to be tweaked and changed to make it Linux-compatible, almost.

Now I think that it's great to be able to port code to your platform, expecially for an OS that, like Syllable, has tiny audience. Being PHP-compatible could led to more people paying attention to your project and, maybe, deciding to use it more but on the other side of the coin, your limiting innovation because you have to implement a common background, a common foundation to ease porting of other existing code. Now my question is: why would strive to be able to stay "Linux-compatible" (source code, not binary level) and forster changes you could implement inside your newly-created OS just because you need to re-use code?

Of course I admit I don't know how much Syllable needed to be tweaked and changed in order to be able to incorporate as much code as possible (and I'm not using it) but I'm hearing that many applications are being ported to it (e.g. Firefox, to name one) and I believe this has a price.

Now, I don't want you to believe I have problems with Syllable because I haven't any and I'm just taking that example as a path to other projects. My question is: if you want to write a "better Linux than Linux", just stay 100% compatible and start a new implementation of that system (for example, take ReactOS and Windows... after all compatibility has a value); if you start an original (and supposedly "innovative") project, why shaking foundations of your idea so much in order to keep others' code? In the end, that limits your ability to innovate because you need to keep up with existing codebase.

So while OSS definitely encourages code reuse and, by opening main codebase, encourages to be part of a collective effort, sometimes that limits your ability to innovate because your encouraged to stick with original ideas and incrementally build upon them. That reminds me all thoughts about Rainbow Portal I had lately: build upon an old codebase and have to stick there or change product and incorporate new features?

I'm a few days far from starting to debug Rainbow 2.0 version and Esperantus library in order to understand why a couple of nasty bugs in RP 2.0 are surfacing. There are a few more bugs but a couple of them are show-stopper as they prevent important functionalities like registrations and user editing. Bugs occurr in Esperantus library which is responsible for providing multi-language functionalities for RP.

I will do that as a service to Rainbow community but, to be honest, even as a service to myself as I have to understand if I can fix those bugs and consider RP 2.0 as dependable framework to build upon. Other developers has restarted work to upgrade RP to .NET 3.5 (or at least .NET 2.0) and add up some changes. However, I'm concerned that time is up for Rainbow.

Let me first say that I have loved RP. I've been using it since 2004 and I still believe it's one of best CMS around for .NET in its 1.6 incarnation, which targets aging .NET 1.1. The fact I'm writing this on a RP installation means something, I guess. However, my concern is Rainbow is moving too slow and too late. I've been checking what RP community is doing now and it looks like they're basically rewriting the internals of RP, adding up things like LINQ, providers instead of monolithic code to handle many other area and so on. Which is good but could be too late.

As I wrote in other post here, main RP problem has been lack of a good amount of high-quality modules, to which you can add the fact RP doesn't work in medium-trust environments. These were most important problems for RP community and they prevented framework to gain traction in past. Plus, original developers abandoned this project long ago (perhaps, I'm one of the few of the old community still buzzing around Rainbow...).

So now you have to options: start to upgrade Rainbow to new code, by rewriting internals and so on; use another framework as a base for other improvements.

Option #1 aims to preserve compatibility (I guess) while upgrading RP to new features. It's a good goal for sure but only if it provides 100% compatibility with RP 1.6. As a great part of RP internals will be rewritten, I'm not so sure compatibility will be assured. If you break up compatibility, then is RP 2.0 (or 1.6) a good base to start from? I'm not so sure about it. There's a lot of legacy stuff in that code and you could say it's very bloated, even if it still is blazing fast when compared to other software.

So if you decide to break compatibility, it's perhaps not useful to start from Rainbow Portal codebase as there are newer products which have a more polished codebase to start upon. So I'm very concerned that the great efforts current RP developers are performing could not be useful after all. I'm not sure if they decided to break compatibility or not but I'm thinking about Rainbow and if it's really worth investing into it. Not to mention that name itself ("Rainbow") doesn't belong to someone actively partecipating into community right now...

I finally had to give up. A few weeks ago I started to suspect that cool ODX library I was using in my latest project was the cause of huge amount of memory consumption of my web application. Decided to investigate further as memory usage was far above any acceptable average, topping to 1.4GB and thus restarting application many times per day.

I registered for a 14-day trial of JetBrains dotTrace to profile my web application in order to understand where such huge memory usage happened. As a side note, dotTrace is a very good product which I'm planning to buy soon. Very easy to use and well-designed to let you access most-wanted info in a very easy way, unlike other memory profilers which were very cryptic and hard to use, at least to me.

As I suspected, I found out that ODX was the source of that high memory usage as library apparently allocates memory which cannot be reclaimed so easily by system. Moreover, despite its internal cache claims (probably based on WeakReference objects), it looks like ODX cannot detect when a new session is trying to access same data as a previous one, which is expected as sessions don't share caches. However, problem lies in the fact that disposing Sessions (for ex. by setting them to null/Nothing) doesn't actually dispose memory which stays allocated, and cannot be shared.

So this way library is not letting you use a global cache to share data but then there is no point in using different Sessions as well as this way you will just increase your memory usage, which is what is happening to me. I suspect this is just a bug or maybe I could deactivate Entities cache based on WeakReference collections but I don't want to dig into library too much as I did in past weeks. In past 2 months I spent some time fixing a few bugs, adding support for SQL CE 3.5 and VistaDB 3.x but it ended up in nothing since now I have to strip library off in order to solve these memory problems. Such a pity!

The concept behind the library itself is powerful but there's probably something wrong in its implementation. Maybe I will take some times to fix it in coming weeks but only after this project has been finished as I'm already late.

I've been taunted by a problem with ASP.NET ListBox webcontrol and even if I believe this is a bug, I'm surprised I didn't find any reference to it. That led me to believe that behaviour is by design but still this is first time I experience it. Be aware I'm talking about .NET 3.5 and Visual Studio 2008.

Problem arises when you add many ListItems to your ListBox (like 50, 70, 100 and so on). Now suppose, as in my page, that some of this items need to include some data for their "Value" property while you don't care about which values others get. In my page, to be sure "Value" won't be empty, I just assign 0 to them, while other items get a specific value.

Now when you select an Item which has no value (so in my case, 0 or better 0 as string) and you postback to server, something weird will happen: first item with same value will be selected, not the one you selected. So it looks like that ASP.NET will look for an item with same value as the one you selected but it doesn't care if Text property matches or not. This looks a bug to me.

Of course, if you select an item which has an unique value (in my case, non "0"), everything works as expected. To fix this, once I understood what the problem was, I simply needed to assign an unique value to ANY item so I just assign a random value stating with "0" to have the same effect. However, I don't think that behaviour is legitimate as 2 items with same value but different Text property aren't the same.

However, I'm posting this to help any other ASP.NET developer which might experience same problem.

Lots of blogging these days... isn't it ?

I'm hearing lots of buzzing about virtualization since at least 2 years, maybe more. I've never been so much excited about it as, contrary to what media report (media are always driven by marketing staff, unfortunately) virtualization is not everywhere, that's not the next BIG one, won't be the key for any success and won't save this planet. Virtualization is useful, expecially in testing, integration, development and consolidation (I use serveral virtual machines based on Virtual PC 2007, expecially for development) but while PR war-machines want you to believe that's anything special, it isn't.

Microsoft has cut a few features from Viridian (or Microsoft Virtualization, or... I-don't-know-what-the-actual-name-is ! ) in order to meet its promise to deliver it 180 days after Windows Server 2008. Those features looked hot, actually, and axing features is surely part of a bad timing/planning. However, I think Microsoft simply understood that while such features can be interesting for some, there isn't a very high demand of virtualization right now.

Sure, there are many big companies and corporations which would benefit from a good virtualized environment because of consolidation and because of by creating big virtualized environments, you can simplify many tasks and provide better fail-over and recovery (not to mention the ability to upgrade all of your v-machines by simply upgrading your host), but that's a widespread requirements as many seem to think.

While all software and hardware companies are trying to position themselves in virtualization market, this is more a long-term goal, not a short or medium-term one. That is, you can't stay behind in this market but yet that's not something which will be so relevant for a couple (maybe 3-4 years more).

Fact is when you talk to someone about different topics, he/she will start talking to you about virtualization. Companies which don't need virtualization at all, they want to virtualize "something". I ask "Why you need this?". They don't know! They just know they want to have something "virtual"...

If that's not an hype... I don't know what an hype is!

I'm not posting this to pose as the one to know what he's talking about. Managing a complex project like Rainbow Portal is (or better, was) is not easy. However, there haven't been many good news for Rainbow fans lately. Community is lagging off and while there's some buzzing, not much is going on. There has been a release of RP, namely this 2.0 production-ready version, following some harsh comments on RP forums. This new version has been converted to .NET 2.0 / 3.5, switching to Membership and Role providers, and according to what I can see, it's been a good job. And I mean really, because Rainbow was already a great product.

So in the end, December release of Rainbow was kind of milestone as this great CMS is now a full-featured citizen of .NET 2+, including most awaited integration with Profile, Sitemap, Membership and Role providers. As of now, to my knowledge, the only feature which haven't been integrated into Rainbow is theme and skinning functionalities but this is not a critical problem as Rainbow theming is quite flexible. To be honest, Rainbow has a lot of legacy code which we could consider as "unuseful", but that would be a real concern if application was slow, which is not the case for RP. So this extra legacy code is not dragging the whole product down.  

So the real problem is about the community itself. There has been some talking about how to restart development, which features to integrate and so on. Unfortunately, it doesn't look that the whole thing is shaping up the way it should. For a project like Rainbow, which has a very small community and a very small number of active developers, development should be agile, that is much more coding than talking.

One of most important RP problem is modules: there are many standard (core) modules. Of them, just a few can be considered full-featured modules and most of them are good but they're not polished nor they look "finished". Sure, RP code (including modules) is quite stable but most modules cannot be compared to quality of modules of other CMSes. Anyway, RP can catch up because of its very good design so even if modules aren't the best you could find, a RP portal is generally a good one.

I spent a few days checking community messages and there's something going on since there is some people talking about restarting development, integrating new technologies and so on. However, it looks like there is no agreement about what to do and where to start, except for a few ideas which are not focused on more functionalities but rather on non-critical changes. For example, there's someone willing to have LINQ inside Rainbow which would be great but I don't think that would be urgent since it's just a matter of taste about technology to use. Nothing much.

I have to say I never tried myself at core in past years. At least, not that much. That was because I thought that core was somewhat stable and rather complete. Rainbow needed more modules and better ones and that's why I welcomed original developers decision to spin modules code off of core in order to encourage development of new modules. That was the right choice even if then Rainbow community started to loose developers.

However, Rainbow still has that problem. There should be a great effort to produce more modules while I fail to forecast which innovations could be introduced into core. Sure, rewriting DAL could be a good thing but current one is performing very well. So why taking the risk to break it now?

There are some other functionalities which could be introduced inside core code but none of them look critical and we really need more people to start using Rainbow to build their websites and applications and until we will have that, we won't have more users and thus, more developers.

There's unfortunately a great concern over unimportant stuff like mailing lists, forums and so on. Now they setupped something like 5 mailing lists for different stuff but there's no more of 6-7 developers actively working on RP so why wasting our times with that? In my opinion, the few active developers should concentrate on modules to produce something like 10-15 very good modules. That would attract users and fuel more development. Then, we could think about what more we could want in core which already includes many functionalities.

Among critical functionalities which core must grant to developers, there should definitely be AJAX support. My past attempts to play with AJAX on Rainbow 2 were not successful. Might be my problem but same code added to other applications work without glitches.

I finished updating this website to Rainbow Portal v2.0 a few minutes ago. Upgrade was a bit tricky as I switched data to a new database in order to be able to quickly restore v1.6.xx if upgrade went wrong. Had to migrate data but also had to switch tables and SPs to other db user to preserve original database. After doing this, setup procedure correctly recognized database version but upgrade was failing because of unspecified error but since there was no db script to run to upgrade from 1880 to 1881, I simply modified rb_Versions table to reflect changes. I already did an upgrade of a database so I'm pretty sure the problem was related to switching username and database name. Anyway, website is up an running now.

In the end, I decided to switch to old database and perform upgrade to that one. Reason I did this is my data migration wasn't perfect (lots of table missing primary keys definition, default values and so on) so I was having problems and I was needing to manually modify many tables to restore application.

You know I'm lazy so I decided to switch to old database a try to upgrade that one. Everything was fine and in a couple of seconds website was ready and upgraded.

My reason to do this is to start checking Rainbow v2.0 in order to decide if and when to upgrade my other websites, expecially VaiSulWeb corporate website. So I will monitor my homepage for a week or so to understand if anything is wrong with it.

My first impression: v2.0 is faster than v1.6 (which is way faster than any other CMS I tried).