Monday, October 29, 2007

Requiem for Acropolis; Fanfare for CAB +

“I didn’t attend the funeral but I sent a nice letter saying I approved of it.” – Mark Twain

The official Acropolis obituary is long over due (see http://windowsclient.net/Acropolis/ ). With Acropolis out of the way, Microsoft patterns & practices can rejuvenate its composite application development support. That is why I am celebrating.

I’m not dancing on the grave. Acropolis is noble in conception. The Acropolis team is rich in talent and ideas - ideas that should find their way into the .NET platform some day. Sadly they seemed unable to set realistic goals and execute on them. That in itself is no crime; if it were, I’d be doing ten-to-twenty. But Acropolis’ shortcomings effectively paralyzed the .NET composite smart client application development space by promising too much and stifling alternatives.

The Java folks are way ahead of us in experience with composite applications. They’ve been living with dependency injection since 2000 and there are several DI frameworks competing for their attention. For Microsoft-oriented .NET developers, the Composite UI Application Block (CAB) from patterns & practices was the only comparable game in town. It has been galling to watch our community lag farther behind.

A number of my customers have built large, modular business applications in CAB. The latest release of CAB dates from 2005. That’s an eon ago in technology time. Customers wondered where CAB was going. P&P couldn’t say. Finally, Acropolis went public last summer with its ambitions and first bits; P&P closed the CAB shop.

Suddenly the enterprise application developer faced awful choices: wait for Acropolis to mature, experiment with early Acropolis CTPs, go with an off-brand platform such as Spring.NET, or build on a terminal CAB that had one or two years to live. Choice is good when the choices are good. Well the choices were not good.

Nobody knew what Acropolis was going to be. It was clear to many of us that whatever Acropolis ultimately offered would not arrive for at least two years, probably longer, quite possibly never. Meanwhile, CAB, as good as it was, needs an overhaul and no technology survives without continuing investment – investment it would never receive while Acropolis lived. The Spring (http://www.springframework.net/) route leads away from Microsoft and many shops simply will not stake their futures on an open-source venture.

Microsoft Patterns & Practices Takes Over

With Acropolis out of the picture, Microsoft’s patterns & practices group can rejuvenate the space. That’s not how it should have been – it would be far better to have a composite application development framework in .NET itself. But it’s time to move on. Besides there’s a lot to like in what’s coming and reason to believe we’ll have our hands on a viable framework in a year to eighteen months.

Start by reading Glenn Block’s blog on the transition (http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx) . Glenn should know: he’s the “Product Planner” for patterns & practices.
Here’s my first take on the announcement and what it means to enterprise application project managers who must decide which composite app pony to ride.

CAB & Windows Forms

I continue to recommend CAB WinForms clients, even for new development.

We’re making terrific progress with our WPF initiatives at my company and I’m bullish on the new breed of WPF applications that should emerge in late 2008. WPF’s superior data binding architecture alone will transform how we construct our UIs.

But let’s get real. WPF development is much harder today than WinForms development. The poverty of WPF design tools and the steep learning curve are going to kill developer productivity for the next year at least. If you intend to deliver a large application in reasonable time, you should think twice before leaving WinForms.

The apparent danger is that you will be left behind. Some wags will chirp that your application will be “legacy” before it is even released. Well you tell them “at least I have a release!” Time to market counts for a lot with everyone, not just software product vendors.

You can build a very slick, modern looking WinForms application that does its job well. While you are delivering, the other guys will be stumbling with glitzy WPF-front ends that crash alot. There’s plenty of talk about how WPF enables the “differentiated UI”. Differentiating the UI may make sense for a public facing application where you have to make a splash to win business. Differentiation for its own sake has no value for the inward facing, productivity applications that are the majority of line of business (LOB) apps. You should be able to “differentiate” on the merits, not the cosmetics.

Don’t get me wrong. I am utterly convinced that a compelling user experience is essential. The question is not “should I invest in the UI?” but “is a WPF UI better than a WinForms UI for LOB apps?” The answer will be “yes” some day. But not today and not in the next year or two.

I have yet to meet the data-driven, LOB application that puts WPF to good use. I immediately discount any UI with white type on shiny black, image reflections, and big animations. I’m as dazzled as the next guy the first time I see my form rotate on a carousel. It gets old around the tenth time. Around the 100th time I’m annoyed and impatient; I want the UI to stop preening and give me the damn form.

I am starting to see some simple WPF effects that matter. An effect matters if it improves the user’s productivity. It should help him or her see an important event or important relationship more quickly and more clearly. It should help the user make better choices faster.

Such effects tend to be subtle. The other day I saw an image that expanded just 5% in order to draw attention to an important application event. It catches your eye without jarring your attention. That’s great. I could use that effect to let the user know a “save” completed successfully; I could avoid the typical, annoying interruption of a popup “Save Completed” dialog box. We’ll invent more of these effects in time and they will enter the lexicon of everyday idioms that we all use to build effective UIs. However, those idioms do not exist right now and even the above average developer is ill-suited to inventing them. Until we have that lexicon, there is little visual advantage to WPF for the LOB developer.

Playing it Safe with CAB 2005

CAB 2005 (plus SCSF) remains the best bet for pure WinForms development. It is stable and reliable. There is a solid community of CAB experience to which you can turn for advice and hired talent. We’ve seen more and better training materials in recent months. The online forum is healthy.

The CAB API is not going to change. That’s good news for those who favor stability and tough news for folks who want to see it grow. The p & p folks have committed to making CAB work on Visual Studio 2008.

CAB for WPF Today

P & P announced a new WPF-only initiative called “WPF Composite Client” (WPFCC). Right now it’s little more than an idea – an idea I’ll talk about below.

If you have to code a WPF composite application today, you’ll want to pick one of the two existing alternative described in Glenn’s blog:

  1. SCSF 2007 – The CAB/SCSF combination that supports islands of WPF inside a WinForms application. Use this to embed a WPF part within your CAB app. It’s almost as simple as adding a few dlls. While SCSF 2007 targets existing CAB applications, you might consider it for new development that is mostly WinForms-based when all you need is a few, well-chosen WPF accents.

  2. WPFCAB – This is the route to take if you want to write a pure WPF app right now. Kent Boogaart (with help from Matias Woloski of Southworks) has adapted CAB and its UI components to work with WPF. The APIs are the same as CAB 2005 so if you know (or have read about) CAB for WinForms, you know how to develop in WPFCAB.
WPF Composite Client (WPFCC)

We’re going to need a better name! My poor memory refuses to retain the difference between WPFCC and WPFCAB. A couple more doses of Ginkgo biloba and I’ll be fine.

WPFCC is not CAB. Patterns & practices desperately wants you to know this. There will be no way to automate migration to WPFCC from your CAB 2005, SCSF 2007 or WPFCAB application. Is that clear? Good.

This is absolutely the right decision. We need a new composite application development platform that is fully committed to .NET 3.5 and WPF. If that means leaving CAB behind – and it does – so be it. In my view, an attempt to preserve backward compatibility would be a disaster.

  1. We need a dependable, working version of WPFCC “soon” – within a year. To achieve that goal, it must be spare and clean and of reasonable scope. Every feature counts.

  2. CAB never got the traction it deserved in large part because it was too hard to learn and had too many quirks. A new WPFCC, unencumbered by the past, can strive for simplicity and devote more energy to flattening the learning curve.

  3. Supporting WPF will be a challenge. The APIs will have to change. We can’t expect to hide everything under the hood. Yes Kent did a nice job of translating CAB WinForms components into WPF components. However, the WPF architecture is so different that simple translation will not do. Mere translation would prevent the developer from exploiting WPF fully and impose WinForms constraints that hamper performance and foster ill-advised designs. There really is an impedance mismatch between the two that runs deeper than the visual differences familiar to everyone.

  4. WPF isn’t the only new technology at issue. The language enhancements in .NET 3.5 – especially LINQ, lambda expressions, and extension methods – will change our programming style dramatically. WPFCC APIs should demonstrate the best practices of that new style just as they should promote the best practices of WPF development.

  5. CAB is missing some valuable capabilities found in rival composite UI frameworks. The Aspect Oriented Programming (AOP) features of Spring come to mind. The Acropolis people weren’t sitting on their hands the last two years. They’ve been cooking up new stuff and torture testing code under arduous WPF conditions for some time. This is a great opportunity to harvest the best of their efforts and avoid their mistakes. And I’m really looking forward to integrating WCF and WF into the framework rather than bolting them on as we do today.

  6. As with any software, there are a number of false starts and blind alleys in CAB. Let’s get rid of them.

  7. Preserving backward compatibility is hard. P&P is a small team. If we demand backward compatibility, we will lose something we value more – some thing important among the basket of goodies I mentioned above. That’s my intuition anyway.
Will They Deliver?

I have a lot of confidence in the patterns & practices team. These folks have a great track record of saying what they will do and doing what they say. The shop is committed to agile practices and they’ve been living those practices for several years. Rapid iterations are the norm. Code that works is the norm. They are organized to collect feedback and are accustomed to listening to it. I’m consistently impressed.

They also know this space pretty well. After all, they’ve built CAB and they’ve been maintaining it. Not everyone is still around but the new blood know the score and play their instruments well. With luck, we may see some of the Acropolis people join them.

Finally, the WPFCC project will not be caught in the Visual Studio designers trap. The Acropolis team poured their hearts into rich, extensible visual design tools that would give the developer that nifty drag-and-drop development experience. What a nightmare. It may be possible but I think we can all guess how hard this must be. If it were easy, we’d have great WPF design tools in Visual Studio today.

The WPFCC design is wide open at this point but I’m virtually certain that visual designers have been ruled out. I will not fail to remind P & P how much they’ve been burned by the guidance automation tools should they even consider the vastly more difficult challenge of building anything but the simplest designers.

What About the Installed CAB Base?

So you’ve made a huge commitment to CAB and now you learn that WPFCC won’t look like CAB. How can they do that to you?

I’d like to think you got over it earlier this year when you learned about Acropolis. Acropolis was never going to look like CAB. It wasn’t going to be anything like CAB. In fact, we had no idea how much CAB would find its way into Acropolis. So you’ve had months to get used to the idea that there would be no automated migration path to CAB’s successor. Nothing has changed.

Here’s the great news. Until today, you had no idea which CAB concepts would survive in Acropolis. Now you know (because Glenn said so) that critical architectural constructs like modularity, dependency injection, Event Broker, and services will be there. Unit testing was a prominent theme in CAB development (as it seemed not to be in Acropolis); I’m confident we’ll see even more energy devoted to enabling the test-first developer.

There is good reason to believe that a CAB application will port to WPFCC with relative ease. “Relative” to what? Relative to an application built without CAB for sure. The common heritage is going to make a huge difference. The familiarity with the concepts, the decoupled modules, the pub/sub eventing – all of this is going to make the transition surprisingly easy. It just won’t be automated.

For the last year, people have been asking me “should I build in CAB or wait for Acropolis”. I always told them, “build in CAB today because it is the best way to prepare for Acropolis. The leap from CAB to Acropolis will be a hop across a stream; the leap from standard application architectures to Acropolis will be like jumping a river. If you have a choice, it’s better to get going now.”

I’m singing the same song today with just a few changes to the lyrics: “build in CAB 2005 today because it is the best way to prepare for WPFCC”. Now I’m singing it with full-throated conviction.

14 comments:

Unknown said...

Okay I'm going to reply to this rant with another rant...

CAB is absolutely the worst of all of the frameworks I have worked with... why... because it trys to be all things to all people. It is bloatware at it's finest. It does the job when it comes to seperating out UI elements but the framework itself is very convelutated and bulky. We saw a large decreases in performance with our applications. All of these just because of the framework itself, so much so that we were regretting using it and have considered using spring.net to provide a thinner framework and help improve performance. The thing that really burns me about CAB is it's insistence on AOP programming. While yes CAB does give you a limited set of AOP functionality... it is at best 1/4 of what spring.net already does (and spring.net is less buggy). AOP is great but... the biggest problem I see with it is using it appropriately (just because you can doesn't mean you should). The AOP stuff comes at a large cost and is inferior in everyway to spring. Don't believe me... take a look at spring. It is a complete product w/documentation (something that CAB is very much laking in). Let's face it... the whole abstraction with the extension points medafore is extremely broken. To get the performance you need in a professional app you will have to sync up your GUI controls accross all of your modules and reference them directly (adapters not only are bulky, but very difficult to abstract). Of course doing that really creates another dependancy and it begs the question why... I thought the idea of dependancy injection was to decrease dependancy. For example let's say I create my main menu using the Infragistics control... to place items on it I get to create an adapter so now all my modules will have to know that I am using this particular Infragistics menu control. If I upgrade... guess what... have to do it everywhere. It gets worse if heaven forbid there is a breaking change...
What about presenters... have you seen a presenter that is not tied to the view? Maybe in labs and none real world apps do you see it... but in most application's use case == screen.

Acropolis gave me hope that maybe at somepoint we would get a composite GUI framework that didn't suck or cause my app to move like a tank in a parking lot. Most people don't need the mammoth framework known as CAB. They just need it to do it's main job... and do it well. Maybe the P&P team will get it right the next time (honestly though history is against them). Rather than celebrating this news I dreed the revival of CAB and pray that something better comes along quickly.

Anonymous said...

To me the important thing Acropolis was going to provide was the WFP controls, not a complete "CAB" like framework. Using Acropolis as an excuse for not continuing to develop CAB and no release since 2005 is bogus. If CAB was as good as Spring.Net and did not have resource/performance issues it would be more popular. Suggestion: Get rid of the blot as the previous poster suggested and make it easier to use. The fact that CAB still does not compare to Spring.Net is on the CAB development teams shoulders and using Acropolis as a excuse is really sad.

Ward Bell said...

It's great to see that no one is holding back here :-)

While I disagree overall with the previous two comments, there are nuggets of truth and these opinions deserve comment. I'm not sure I can do justice to them but I shall make a start.

Before I continue, I want to be very clear about a few things. These fellows are comparing CAB to Spring and so I am obliged to make some comments about Spring. I am not knocking Spring. Please repeat that to yourself several times.

Second, I admit up front that I don't know much about Spring - probably less than these guys know about CAB. But I have nuzzled up to it a few times and spoken to people who use and like it (mostly Java developers); while my ignorance is profound, it is not total.

My objective here is not to knock Spring or say CAB is better. I just want to dispell myths about CAB and to encourage developers to take CAB seriously. I have had great success with CAB as have many others. Look at Spring by all means. But be wary of comments like "worst of all of the frameworks."

And on that note, I proceed.

I don't know if I'd call CAB bloatware. What's the metric? The three essential dll's weigh in at 321K. Is that too much? Not in any WinForms app I'm used to. "Spring.core.dll" alone is 553K; is that too much?

The CAB dlls are reasonably well factored. The API is indeed large and suffers for lack of documentation. I can't agree that Spring.Net's documentation is significantly better; it's APIs are pretty darn big too.

I use what I want in the CAB API and ignore the rest. This works out fine. So, while I guess anything that I ignore is "bloat" to me, I find my self saying "so what". I imagine I'd feel the same way about the parts of Spring that I didn't want to use (including nHibernate).

BTW, this concern about API complexity is one of the reasons I mentioned for freeing WPFCC from its CAB past. It seems P&P agrees with you, Mathew, although none of us are quite as overheated about it.

Is Spring "less buggy?" I honestly don't know. What I know is that CAB has been steady as a rock. I have found some infelicities but it's reliability has been outstanding. Anything I don't like I can change. So being "less buggy" than CAB is meaningless to me.

I hasten to add that CAB's behavior can be "mysterious" -- to put it mildly. It was pretty frustrating at first and, until you develop your CAB chops, you'll get stuck in some maddening dark alleys early and often. I hope Spring is much better in this respect because the CAB learning curve was awful. P&P absolutely must avoid this mistake in WPFCC.

On the other hand, after you pick up some debugging techniques, start using a little instrumentation, and get the hang of how CAB works, the experience improves dramatically.

[Aside: I have little kind to say about the GAT/GAX which I have removed from my machine. These "rapid development" facilities are not intrinsic to CAB and have no parallel in Spring so I think it fair to omit them from the comparison.]

I'd be reluctant to describe CAB as AOP. CAB mostly uses attributes (annotations) as markers to help the ObjectBuilder (the CAB injector) identify classes, constructors, properties, and methods of interest. That's well short of AOP in my view.

However, I feel strongly (and others in the Java space agree) that attributes are a much kinder way to mark injection points than the separate XML file which, as I recall, is the Spring approach. In CAB I can see immediately what will be injected by looking at the attributed code; I don't have to root around in a separate, huge XML file. I've asked many Spring fans about this and they all describe this exercise as extremely painful.

Don't agree? Fix it yourself. One thing I really like about the ObjectBuilder (the CAB injector) is that it is guided by Strategies and Policies that you can change. So if you preferred to use an XML file, you could write a strategy that looked there instead of (or in addition to) inspecting the code for attributes. Do you wish that the ObjectBuilder did less reflection? Modify the strategies in the pipeline to cache the prior type analysis. It ain't that hard. I don't know if it is this easy to change Spring's DI behavior.

I agree that Spring has real AOP; I agree also that AOP is challenging to use "appropriately." Folks are justly concerned about too much magic in dependency injection; well AOP elevates magic to a new level. The friends of Spring in my informal survey are divided on the value of AOP. They use it sparingly. I'm sure the designers of WPFCC will consider carefully whether or not to burden it with AOP.

Mathew said "the AOP stuff comes at a large cost". Assuming he means CAB's use of attributes, I wish he had expanded upon what he thinks that cost is and how that cost is avoided in Spring. Absent specifics, it's just a wild charge.

Mathew loses me entirely at the point in his commentary that begins "To get the performance you need in a professional app you will have to sync up your GUI controls across all of your modules and reference them directly." I don't know what performance he's talking about. I don't know what "sync up" he's talking about. I don't do any such syncing, I don't have UI performance problems, and I certainly don't re-introduce the dependencies he claims are required. Do I use adapters? Of course. This is .NET 2.0, not .NET 3.5. To abstract .NET or 3rd party classes that lack interfaces you pretty much have to adapt them. In any case, the adapters perform well in the wild, are not bulky, and are not difficult to abstract.

He is simply wrong when he writes: "let's say I create my main menu using the Infragistics control... to place items on it I get to create an adapter so now all my modules will have to know that I am using this particular Infragistics menu control." The whole point of the adapters is that they free client code from knowing anything about the menu control. I don't love the CAB UIExtensionSites but they do not suffer from this problem. Most of us populate menus and toolbars by means of a CAB service which completely abstracts the concrete control suite from the service clients. What is wrong with that?

Both Mathew and "Anonymous" make unsubstantiated claims that CAB performs badly. That simply has not been my CAB experience nor the experience of my customers. Not with SmartClients anyway.

I don't doubt for a second that there are parts of CAB that could and should be rewritten to perform better than they do. I've found a few suspects myself. Are you telling us that you can't find similar code in Spring? In any case, what we see here is a big rhetorical leap from "needs to improve" to "tank in a parking lot". How about some evidence?

Is anyone else sick of the performance scare tactic? Every time a technology comes along, someone dismisses it as "non-performant." I think we have to stop BS'ing about performance. You got something? Prove it. Give us a unit test, profile it, and show us the numbers. Anything less is a disservice to our community.

In sum, I agree with Mathew and "Anonymous" that Spring deserves serious consideration. But their dismissive characterization of CAB is misguided, uninformed, and far off the mark. CAB deserves at least equal consideration. The .NET community is fortunate to have two worthy contenders and we should be thrilled that Microsoft P&P are ramping up to deliver a WPF-based CAB successor in reasonable time. Let's encourage them.

Anonymous said...

Ward,

You said you unistalled GAT/GAX. Does this mean you are not using SCSF?

I'm just trying to consider pure CAB vs. CAB with SCSF. Any thoughts?

Kent Boogaart said...

Like Ward, I'm a long-time user of CAB (mainly with WPF). I agree with Ward's comments but want to add some of my own:

1. CAB is like any other framework. If you don't learn how it works, you won't be able to leverage it effectively. This is true of CAB, Spring, and .NET itself. It sounds kind of obvious, but I see a lot of CAB criticism that comes out of ignorance rather than fact.

2. Like Ward said, use services to abstract stuff out. If your module developers are worrying about how to add menu items in the right place (and if they have to deal with the specific class implementing the menu item), how to have the status bar updated correctly etcetera, then you are doing something wrong. The shell should be providing services that module developers can leverage to void this pain and free your modules from any dependencies on a particular UI toolkit.

3. CAB isn't perfect, but neither is Spring or any other framework. Turn any negative CAB energy you have into something useful: provide feedback to the P&P team and they will incorporate it into their thinking going forwards with WPFCC.

My 2c,
Kent

Anonymous said...

I have done an evaluation about CAB/SCSF and Spring .NET for the company OMICRON.
The evaluation is public. Maybe you find it useful: http://www.berchtel.com/archive/diplomathesis

Anonymous said...

Hello. This post is likeable, and your blog is very interesting, congratulations :-). I will add in my blogroll =). If possible gives a last there on my site, it is about the CresceNet, I hope you enjoy. The address is http://www.provedorcrescenet.com . A hug.

Tariq Salah said...

I’m afraid to tell that Microsoft did not yet finish its development strategy as a ready to use product up tell now. Borland RAD was very easy and powerful. I know the bugs of Delphi and I did so many work abounds to avoid MIDAS bugs in the past Borland Delphi. But at least I used Borland Delphi easily to create great real ERP solutions with a very less effort compare to its huge size. I was using sockets and some old techniques from Delphi.
When Borland RAD is dead, I decided to move to what is available in the market shelves. It was that Visual Studio. I discontinued Java Development because the developer team has been reduced in my company.
Since two years, I search here and there for best practices and 3RD parties to collect the tools to build more powerful user friendly applications.
Every tier of the enterprise solution still needs may features to be settled and has several choices. That is nice but not for LOB. To build a LOB, you need a strong RAD. Most of the Visual Studio RAD is not a real RAD, but it needs a significant manual coding here and there.
I think that Visual Studio is a framework over the .net framework that needs a framework over it, and then you need a RAD over all to be really what is called “Visual Studio”.
So, I have to purchase one of each tool for each piece of each tier. To get the correct decision, I have to study the infrastructure and compare the features of each 3RD party product (e.g. DevForce, LLBLGen, EF, ... or even XAF with XPO). Oh, I forget to tell you that I tried SCSF which is free of charge.
Finally, do you know what I did? I build a very simple decoupled User interface with some nice Developer Express controls (e.g. Ribbon, … TreeList). I’m using only windows forms and only ADO.Net with WCF and the bulky DataSet in C#.
Every while, I go to see what is new in the market, nothing is completed and nothing is interesting.
I like what is new, but it is not effective to develop what I like. I should develop a solution for the market that hundreds of users will interface with it. Therefore, it should not buggy, dummy (e.g. no data Grid in WPF~!!!), but it may be little slow with ADO. Who cares? I wish Microsoft.
I’m sorry for my bad English.

Tariq Salah said...

I’m afraid to tell that Microsoft did not yet finish its development strategy as a ready to use product up tell now. Borland RAD was very easy and powerful. I know the bugs of Delphi and I did so many work abounds to avoid MIDAS bugs in the past Borland Delphi. But at least I used Borland Delphi easily to create great real ERP solutions with a very less effort compare to its huge size. I was using sockets and some old techniques from Delphi.
When Borland RAD is dead, I decided to move to what is available in the market shelves. It was that Visual Studio. I discontinued Java Development because the developer team has been reduced in my company.
Since two years, I search here and there for best practices and 3RD parties to collect the tools to build more powerful user friendly applications.
Every tier of the enterprise solution still needs may features to be settled and has several choices. That is nice but not for LOB. To build a LOB, you need a strong RAD. Most of the Visual Studio RAD is not a real RAD, but it needs a significant manual coding here and there.
I think that Visual Studio is a framework over the .net framework that needs a framework over it, and then you need a RAD over all to be really what is called “Visual Studio”.
So, I have to purchase one of each tool for each piece of each tier. To get the correct decision, I have to study the infrastructure and compare the features of each 3RD party product (e.g. DevForce, LLBLGen, EF, ... or even XAF with XPO). Oh, I forget to tell you that I tried SCSF which is free of charge.
Finally, do you know what I did? I build a very simple decoupled User interface with some nice Developer Express controls (e.g. Ribbon, … TreeList). I’m using only windows forms and only ADO.Net with WCF and the bulky DataSet in C#.
Every while, I go to see what is new in the market, nothing is completed and nothing is interesting.
I like what is new, but it is not effective to develop what I like. I should develop a solution for the market that hundreds of users will interface with it. Therefore, it should not buggy, dummy (e.g. no data Grid in WPF~!!!), but it may be little slow with ADO. Who cares? I wish Microsoft.
I’m sorry for my bad English.

Anonymous said...

Hello !.
You re, I guess , probably curious to know how one can collect a huge starting capital .
There is no initial capital needed You may start to get income with as small sum of money as 20-100 dollars.

AimTrust is what you haven`t ever dreamt of such a chance to become rich
The company represents an offshore structure with advanced asset management technologies in production and delivery of pipes for oil and gas.

It is based in Panama with offices everywhere: In USA, Canada, Cyprus.
Do you want to become really rich in short time?
That`s your chance That`s what you desire!

I`m happy and lucky, I started to take up income with the help of this company,
and I invite you to do the same. It`s all about how to choose a correct companion who uses your funds in a right way - that`s AimTrust!.
I earn US$2,000 per day, and what I started with was a funny sum of 500 bucks!
It`s easy to join , just click this link http://exyqysane.wtcsites.com/utybev.html
and lucky you`re! Let`s take our chance together to get rid of nastiness of the life

Anonymous said...

Hi !.
You may , perhaps curious to know how one can reach 2000 per day of income .
There is no need to invest much at first. You may start earning with as small sum of money as 20-100 dollars.

AimTrust is what you haven`t ever dreamt of such a chance to become rich
AimTrust represents an offshore structure with advanced asset management technologies in production and delivery of pipes for oil and gas.

It is based in Panama with structures everywhere: In USA, Canada, Cyprus.
Do you want to become really rich in short time?
That`s your chance That`s what you really need!

I feel good, I started to take up real money with the help of this company,
and I invite you to do the same. If it gets down to choose a correct companion who uses your funds in a right way - that`s it!.
I take now up to 2G every day, and my first investment was 500 dollars only!
It`s easy to join , just click this link http://jidatagug.uvoweb.net/vucode.html
and lucky you`re! Let`s take this option together to feel the smell of real money

Anonymous said...

Hi!
You may probably be very curious to know how one can make real money on investments.
There is no initial capital needed.
You may begin to get income with a sum that usually is spent
on daily food, that's 20-100 dollars.
I have been participating in one project for several years,
and I'll be glad to let you know my secrets at my blog.

Please visit my pages and send me private message to get the info.

P.S. I earn 1000-2000 per daily now.

http://theinvestblog.com [url=http://theinvestblog.com]Online Investment Blog[/url]

Anonymous said...

very useful article. I would love to follow you on twitter. By the way, did you know that some chinese hacker had busted twitter yesterday again.

Anonymous said...

great article. I would love to follow you on twitter. By the way, did anyone hear that some chinese hacker had hacked twitter yesterday again.