Another way to start silverlight now

Anotehr way to start silverlight now:

Port Silverlight to plain WPF when porting to ajax takes too long!
(see my previous blog)

Because it easier to develop WPF in VS 2005, so, in practice, it is more likely the following:
(a) Develop WPF with silverlight in mind (it is a learning curve, the first step is to avoid using build-in databinding and grid – I know, it is pain, but it is worth it!),
(b) Then, port the WPF to silverlight (takes some time),
(c) Then, port it back to WPF (a few minutes).

http://blogs.msdn.com/usisvde/archive/2007/05/16/porting-wpf-to-silverlight-1-1-1st-of-a-series.aspx


http://blogs.msdn.com/usisvde/archive/2007/05/19/porting-wpf-to-silverlight-1-1-2nd-of-a-series.aspx

http://blogs.msdn.com/usisvde/archive/2007/05/19/porting-wpf-to-silverlight-3rd-of-a-series.aspx

http://blogs.msdn.com/usisvde/archive/2007/05/20/porting-wpf-to-silverlight-4th-of-a-series.aspx

http://blogs.msdn.com/usisvde/archive/2007/05/22/porting-wpf-to-silverlight-5th-of-a-series.aspx


-----------------
http://blogs.msdn.com/ebooth/archive/2007/05/19/view-source-reflector-tool-for-net-silverlight-sites.aspx

-----------------
Why silverlight now? Now download of the runtime! So, first demo the silverelight, users will want it, and then, say, OK, either we use alpha version, or, we need to download the runtime.

-----------------
Finally we can do web with similar productivity and features as winform. Also, finally, we .Net developer can do Linux programming now … As a matter of fact, it is very likely that silverlight can be outside the browser, and it will take over Linux desktop very quickly – .Net will beat Java on Linux just like that!

Use silverlight1.1 as a prototype version for ajax

Use silverlight1.1 as a prototype version for ajax

I cannot wait for using silverlight, a way to use silverlight1.1 now is to use it as a prototype tool for ajax, because silverlight can be faster to development, because all validation is in C#.

It is true that silverlight controls are still primitive; however, prototype does not need to be that fancy.

In fact, the core of silverlight is very mature (it is .Net 3.0!); so, it is NOT like other alpha stuff. As a result, if it acceptable (big if, of course), we can borrow the “internet tradition”, use alpha in production! At least, when it is beta, we definitely can use it in production.

I bet this will be a strategic technique for all “progressive” or “cutting edge” shops or development teams.

----On the one hand, I bet this will be a strategic technique for all “progressive” or “cutting edge” shops or development teams.

----On the other hand, I believe not that many teams can use this technique. For two reasons: (a) most winform based teams are not “progressive”, they are basically still in VB6 world; (b) most web teams are still busy with Ajax, they already accepted that fact that they have to duplicate validation-entity logic in javascript -- I always hear that life is not perfect, just deal with it. To come up with this simple technique, you must do both winform and web, and refuse to compartmentalize them and refuse to accept the “fact’ – the everlasting truth of AOP is more powerful than the ugly, temporary “fact”.


A note: as I indicated in my previous blog, silverlight is in the sandbox, so, we must use javascript and very-thin-activeX-communication-ports to glue things together. Right, life is not perfect, after all.

You may say, why not WPF? Downloads – it is not just downloads; it means all those bureaucratic processes. Note that it is not just 3.0; 3.5 is coming; and who knows what is after that! I want to be always on the cutting-edge, automatically – the key word is “automatically”: I just begin to use the new technology, no paperwork is needed, no manager talk is needed -- even I love our managers!

I want to emphasize it again, it is crucial that it is a “automatic” process. Even it is “just” a little bit “manual”, then, the spirit of internet “continuous beta forever” (i.e., “continuous innovation forever”!) is gone forever. You cannot blame managers – in a sense, sometimes it is part of managers’ job to cool things down …

Is Spring.net too complex for small projects?

Is Spring.net too complex for small projects?

My answer is: No! It is good for every project.


(a) On the one hand, “small projects” are not THAT innocent at all! Any small projects are part of bigger system. To be a good citizen, you got to be reliable for those “cross-cut concerns”, and to be reliable means you got to do it AOP way – everybody makes mistakes, doing it manually is simply not acceptable!
(b) On the other hand, Spring.net is not THAT complex at all. Yes, its concepts are counter-intuitive for beginners. That is especially true because even the inventors do not really know how to categorize its essence (OK, here is the shameless self-promotion: that is why my blog is valuable – I know its essence – it is AOP, not IoC. IoC really is just a simple technique to centralize all those factories for AOP -- yes, by categorizing it this way, it means you always, at least potentially, want to use AOP everywhere – which is indeed very true!). However, the code is really lightweight. A decently experienced programmer can maintain it for sure – I am not crazy, I am serious and telling the truth, notice that I am saying “maintain”, not “develop it from scratch” (the reason? Because spring.net is designed this way; it is a beauty; a beauty is always easy to maintain!). Also, I do not want to warrantee that for Nhibernate – so, ya, you could say Nhibernate is a potential maintenance risk, and I would agree to a certain degree (but if it is extremely popular, and it is easy to switch to another package, then, I would say that the potential risk is limited, and it is worth it – it is – then, we should do it). However, the point here is that for Nhibernate, it is an argument about quantity; for spring.net, it is an argument about quality – there is absolutely no risk at all. The key is, of course, to understand AOP; once you understand AOP and accept it as the new pivotal concept of the new paradigm (ya, I know, it sounds like converting to a cult; but it is actually converting to the beginning of a new mainstream), you will see how simple, easy, elegant, and beautiful spring.net is. I am regret that I did not get that a while ago, because I dislike XML, until asp 2.0 makes me -- with harsh force -- to get used to it – sometimes being too pragmatic is not good, you got to have an open and soft mind, to give something beautiful a chance to steal your heart. I know it is still not too late – partially because I have a relatively open mind  but lesson learned, I will be more open-minded in the future … wait, with one exception, not to M$ -- I am too gullible to their propaganda! I know I may miss something beautiful from M$ -- sigh, not easy to do … “experiences” or “bias”, it is a fine line …

resharper 3.0, XML in the WPF/ASP2.0 age, AOP is the king, IoC is just implementation details for AOP

I have just bought resharper 3.0, out of my own pocket -- I do not want the company to decide what tool I use ;-) -- actually, perhaps I will get it reimbursed -- or not -- the point is, if not, it is still worth it -- I need its XML help for the spring!

Spring is so nice; I did not touch spring for a while, and suddenly it turns out to be a full-featured AOP framework! It is so nice -- and the java smell, smells so good!

Because nowadays XML support is so good, especially after those heavy duty exercises in WPF/XAML and ASP 2.0 (both encourage XML typing, of course, with intellisense), the XML from spring is really a piece of cake. I have to admit that springframework have figured it all out, and it is many steps ahead of us. XML is the way to go. Yes, I am now officially withdrawing my anti-XML stand; I am now a fan of XML. Long live XML! SQL, C#, and XML – the three layer is also a triad.

Regardless, I am glad that I choose spring as the “default” architecture for my work. Everything now is build around spring.

However, I has been always right on one thing: the key is AOP, not IoC. IoC is really just a necessary tool for AOP, because non-build-in AOP cannot use “new”, it must use factories. So, forget about IoC, it is just “implementation details”, the meat is AOP.

I also like spring's non-OR data handling. I love OR mapping. However, spring's non-OR data is so elegant.

I am an absolute fan of spring now. It is the time for jumping into spring now.

spring is in -- I know, it is summer now

http://www.infoq.com/articles/SpringDotNET-QnA

Note that java spring is extremely popular, which means powerful. It certainly has some hype saying that spring.net can leverage that power; however, I do see the strong possibility, and I am willing to bet my money on it – I will invest my time and my credibility on it now – there is always some risk in vesting technology, we all do that all the time. Before, CSLA is my half-hearted focus, I just “borrow” something here and there from spring and castle. From now on, spring is my focus, and since spring is so beautiful, I will not be half-hearted anymore. I will let it to steal my heart!

--------------------
--------------------long quote from the above, I hope it is reasonable use:

As for commercial adoption, we are seeing quite a bit of interest from large companies on Wall Street, as well as from some of the well-known Oil&Gas companies in Europe and the US. Some of these companies are existing Spring users that are looking to cross-train developers. This makes a Spring/Spring.NET combination very interesting due to the fact the programming model is preserved across the platforms. Others are .NET shops looking to simplify their development, period. We've been contacted by a Spring.NET user from a well-known international Oil&Gas company telling us that they are using Spring.NET as a foundation of their enterprise-wide development platform. This really gets us jazzed.

Oracle Consulting is using the Spring.NET data access framework on their projects, and there was some interest both from them and a few other consulting companies for Spring.NET training.

Useful high level talk used for façade and command pattern

Useful high level talk used for façade and command pattern:

There are two approaches to deal with services and other cross-cut concerns, one is top-down approach, and another is bottom-up approach. We need both approaches.

By using top-down and bottom up, we do not need to get into details, and we implies (correctly) there are only two, and we need both of them for different situations (we all know that we have larger projects and smaller projects).

WPF, WCF, WF, LINQ and entity framework

High level insights – useful when you talk to your CTO/CIO etc)

To use WPF (including WPF/E or, silverlight), use MVP; turn it around, WPF is the time to use MVP
To use WCF, use Façade; turn it around, WCF is the time to use façade
----Also, WCF is the time to centralize cross-cut concerns (from “requirement” point of view – although we are talking mostly about technologies
To use WF, use command; turn it around, WF is the time to use command


The key: The three major technologies in .net 3.0 are the two layers. For the third layer, we need to wait 3.5 or later – the entity framework will be later than 3.5 etc. Its corresponding pattern? -- OR mapping, of course. OR mapping is a pattern that is not emphasized enough in the past, now, it it time to change it, at least it is as important as MVP.

do not forget the simplest AOP: the command pattern

Just to balance out my recent framework craziness: do not forget the simplest AOP: the command pattern. Windows workflow foundation shows it every well. CSLA is the framework represents that.

Also, MVC encourages “actions” from controllers. So, it is really very nice fit.

Further, in .Net, you can put more classes in one file, which is nice for those command classes.

Command pattern will always be the elegant architecture, it does not require any framework – sorry, CSLA, because of command pattern is in the low end, I will always use CSLA, but will always only its pieces.

I will use it when do maintenance development and I cannot introduce springframework or castle – or any situations that I cannot use springframework or castle.

You may ask, why choose springframework over the command pattern? The core reason is that command pattern is only for very-light weight thing. A result of that is that all good framework must use façade, command is not right (again, sorry, CSLA). A command pattern based “framework” can only be very light weight, and only “educational”. As a result, either you choose no framework, or, you got to choose a façade based framework.

You may ask why façade is a better fit for “framework”, because façade is more intuitive, easier to use. That is it, simple. Another deeper reason is that command pattern has no future or depth in AOP: it cannot get to the fine-grained entity methods.

So, it boils down why we need a framework. We do not really need it. However, a framework have all the stuff you need, you do not need to recreate things. So, as long as it is a large enough project, it is definitely worth it. I want to emphasize that the “design” time of the “things you need” are especially important. “architecture paralysis” is a very bad thing, it leads to “architecture chaos”. A good framework shut up all “discussions” about architecture: it is here, just learn to use it, and make it work. It devalues “architecture”, and promote business-value work, while at the same time, gracefully getting the architecture work done and done right!

In short, a framework has a lot of stuff you can get for free, and without painful uncertainty and perplexing thinking. You can just play and have fun!

Really, I love good teachers/coaches. A good teacher/coach always has strict rules and at the same time having fun in teaching and make it fun for learning. Only when you have a strict structure, then, you can boldly do things and push the limits, knowing that you are safe, the real hard and necessary limits will never be broken, and therefore you can have fun.

Strict rules, if they are the good ones, are all about pushing the limits of creativity, i.e., having fun!

AOP is in; but we need a structure, and simple-UP and springframework are the structure

This is a summary of all my recent blogs:

1. TDD is AOP (“separation of concerns”, “do not repeat”), they are the same thing in different languages, process language and technical language. AOP is the way to go.

2. In .Net world, most programmers need a new solid and firm structure (process and technical) in order to function, otherwise, they will use old VB6 structure, which is a very bad structure. There are two causes of this phenomenon: (a) M$ keeps providing tempting bad technologies, e.g., dataset etc; (b) most programmers are from VB6).

TDD and pure AOP inherently has a very good structure, however, the structure is dynamic. As a result, the structure is inevitably perceived not solid and firm. Further, software is soft, reality in software development is mostly determined by “perception”.

3. Hence the dilemma.

4. Solution: use simple UP which will lead to TDD; Use springframework (with the help of mentioning EntLib 3.0), which is AOP, and will lead to more AOP.

5. In short, we need a structure, and simple-UP and springframework are the structure.

6. The above are the high-level reason; however, sometimes, you need the "technical requirements". Here are those “requirements”: we need AOP, because we need centralized security, centralized web services, centralized transactions, centralized operation support logging, and automated unit testing to ensure quality.

MVP and MVC etc

--------------------------mvc and unix (actually, should also be web: cgi was just an extension of unix automation tools, that is where perl coming from also)

>>>quote from http://www.martinfowler.com/eaaDev/uiArchs.html

>>>At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously. This approach was also an important part of the Unix culture, and continues today allowing many applications to be manipulated through both a graphical and command-line interface.

-----------Also see this interesting thread:

http://www.ayende.com/Blog/archive/2007/02/03/Why-seperating-the-View--Controller-is-important.aspx

--------------------------why databinding is not THAT easy
>>>quote from http://www.martinfowler.com/eaaDev/uiArchs.html

>>>In general data binding gets tricky because if you have to avoid cycles where a change to the control, changes the record set, which updates the control, which updates the record set.... The flow of usage helps avoid these - we load from the session state to the screen when the screen is opened, after that any changes to the screen state propagate back to the session state. It's unusual for the session state to be updated directly once the screen is up. As a result data binding might not be entirely bi-directional - just confined to initial upload and then propagating changes from the controls to the session state.

-----------------------------------------
-----------------------------------------
-----------------------------------------

The reason of this? Because Windows update the view, not the model, so, we have two directions: view to model (user change), and model to view (code change). It could be (real smalltalk-MVC) that the window update the model (of course, this means that we always need a model behind a view – this leads more “complexity”, and since M$ traditionally only focuses on dummies, so, they do not want that – however, on the web, there is really no other way (http protocol makes smalltalk-MVC impossible), so, M$ is actually good: it makes the web and windows that same. As a result, the following solution applies to both windows and web.

To correct the problem, we can use databinding (to simulate that it always reached the model), and also, the model always automatically raise the event to update view (there is a bug here in 2005: it does not update the originating field – I guess the bug is a misplaced intent to prevent possible forever loop, however, the intent is misplaced, because the forever loop can be prevented by compare the value – if there is not difference, then, no update – and the rules is already there. The solution of the bug is to force a update. For details see: http://www.lhotka.net/weblog/WindowsFormsDataBindingIssueConclusion.aspx).

OK, back to the corrections for Windows or Web: another correction is to have a local-controller, and then, hands it to a global-controller. This is MVP (i.e., view has more – it has the UI events; but it is still humble

Combine the two corrections: yes, view is smarter: it can “bind” model, and it intercept controller. However, view is still humble view. The “local controller” within the view can handle a lot of things, and it passes the “big” events to “global-controller”. For the ASP, the “global-controller”, we can use a utility class to contain all the logic. The working separation of “local” and “global” is that whether the “global” should be able tested without UI (web container) – but it must know the interface of the view.

MVP gives ASP a good name. Pure MVC requires give up ASP all together (but look at castle igloo: http://www.ayende.com/Blog/archive/2007/01/26/6918.aspx ). However, considering JSF is still trying to mimic ASP, you have to hesitate to throw the baby away just because of the dirty water.

MVP is the evolutionary approach: basically, it does not introduce anything special, just use asp the right way.

http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx

http://www.codeproject.com/useritems/ModelViewPresenter.asp :
---- this article has all the details! It is very interesting to see it that if you always wrap everything in a user control, then, the page is only flow-definition-mechanism. So, the real thing are in user controls, pages are for flow-definition (and master pages are for layout, cool).

http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

After reading his articals, I read other blogs from Billy:

http://devlicio.us/blogs/billy_mccafferty/archive/2006/10/05/_2800_My_2900_-Default-ASP.NET-Architecture.aspx

Springframework is the best tool to lead VB6-ers to AOP (with IOC) world

I guess my previous two or three blogs make it clear already; just in case, for my boss, I still choose springframework as the first try.

I do not choose EntLib 3.0 -- I will mention it as a reference, and at the same time saying that springframework is much more mature and reliable; and although EntLib 3.0 means that IOC and AOP is definitely the way to go, using EntLib 3.0 is likely to lead to problems.

I do not choose Castle for the first try for former VB6-ers or M$-only people, because they can get distracted and frustrated very easily by Castle-- even its AOP is the most advanced and most mature (can do virtual methods, instead of just interfaces -- springframework can do it only recently).Springframework is the choice, for the following reasons:

(a) It has a very "authoritative" look and feel;
(b) The tone of its documentation is systematic, and, again, "authoritative". It is even better than MSDN.
(c) It has many pragmatic features that are useful directly for VB6-ers:

(i) Portable logging wrapping;
(ii) Lightweight ado wrapping (in addition to Nhibernate);
(iii) Centralized transactions;
(iv) Centralized remoting/services;
(v) Centralized logging
(vi) With all AOP examples, it is easy to add centralized security also.
(vii) Validation framework, ASP support, WPF etc.
(viii) Unit testing, large examples to show how to unit testing and how to design the system to enable unite testing (i.e. put all logic outside UI layer – sounds simple, but requires many techniques and instincts). Again, all of those are clearly and prominently in the “build-in” documentation. Just to be fair to Castle, I noticed that Castle has a good tutorial, but it is not “build-in”: http://www.codeproject.com/aspnet/NHibernateBestPractices.asp ).

Perhaps you have noticed that those eight items are exact those items in my “8 core techniques” (see my other blogs) – at least, I am consistent.


As a result, I believe that springframework it is the best tool to lead used-to-be-VB6-ers (most programmers in M$ were VB6-ers) to the new AOP with IOC world. This is exact the same approach as using UP to lead used-to-be-VB6-ers to TDD, in the sense that Castle is more AOP-IOC, but you cannot use it for now, just as you cannot use TDD directly for a team that does not have the stomach yet.

OK, time to switch back to castle. use "AOP" as a better synonym to "TDD"

I guess you can argue that EntLib 3.0 and Springframework are M$ and Java, and Castle is the golden middle.

However, in may aspects, the two extremes (M$/Java) have common styles, and castle is different because it is closer to Ruby or AOP style.

I know some may say TDD style. I agree, I believe the number one rule of TDD is actually pragmatic AOP ("you shall not repeat"). However, I do not believe many people realize that yet, including most TDD top guys/gals. So, I prefer saying AOP, instead of TDD. Also, I say "pragmatic AOP", to emphasize that AOP is not just about cross-cut concerns -- just like OOP is not just about inheritance. Further, real world AOP always builds up OOP, so, AOP contains OOP. In short, I am determined to use AOP as a better synonym to TDD.

The key? Castle has a better taste (aop taste), even just a little better, see my blogs in the past year. That is all. However, again, switch back and forth.

Why springframework is better than castle

Why springframework is better than castle

OK, after some thinking (yes, recently I did a lot of thinking on architecture -- we have so many new technologies and new changes, it is time to revisit architectures), I changed my mind. I prefer springframework now.

Why? In short, because springframework is more mature -- I know its aop is not as mature is castle’s; however, as a whole, springframework has higher quality and better documentation, better community.

My guess it is the result of a big-brother java community – when you are young, it is for your own good that you have a big brother.

Castle is more dynamic, for example, it introduced things from Ruby, etc.

I will switch between them back and forth. However, for now, I would recommend springframework to my boss – he/she will feel safer when he/she see springframework, and increase the chance of success for adoption.

Also, you may say it is not important, technically. However, it can be the most important factor in general: that fact that springframework is directly from java can make the point more obvious: we must do it the java way. As a matter of fact, to me, this is the determining factor for me to choose it as the first choice. We need to make everybody know, java way is the way.

Important note: I still like Castle. We need more than one!

returning to to my original blog castle, only now we have silverlight

OK, let’s step back a little. After sleeping on it for a few nights, I changed my mind! (a) I’ve just got into big trouble because of M$'s dataset; (b) the last version of EntLib, I got into trouble because of it -- it needs system admin power for everything that uses the EntLib. I will not use M$ application framework technologies without inspecting every line of code! So, I will NOT really use the EntLib 3.X -- I agree it has finally created a conceptual reference for everything; however, when you actually do it, go to Castle and/or Springframework!

Also, simplified CSLA as the command pattern one will also be used.

I still want to emphasize that I believe EntLib3.X marks a historical moment in .net history! Together with silverlight, on May 2007, .Net finally graduated from high school, which means we can finally do java development without using java!

You may say, Castle and Spring are there for so long, why May 2007? You need to know, .net is M$’s platform! Only EntLib 3.X can give you the political power to use Castle and springframework (and simplified CSLA as an elegant alternative) everywhere! EntLib 3.X brings people’s attention to Castle and Spring. For example, in the following link, I do not believe Sam’s interest in Castle has nothing to do with Entlib 3.X. If I should be stand corrected, then, it also means it is the time now -- still my point.

http://codebetter.com/blogs/sam.gentile/archive/2007/05/29/castle-microkernel-windsor-resources.aspx


The major thing I need to test is: can castle or springframework be run within silverlight. The key thing is the reflection emit. And I did see that in silverlight. http://www.scottgu.com/blogposts/silverlighteurope/namespaces1.jpg , so, it should be fine.

Also, which one to use, springframework or castle? Spring’s AOP is not as mature as Castle; also, castle has non-asp Rails, and I like it (who need the leaking asp!). However, they are close. I really suggest we use both. Do not use EntLib. Use simplified CSLA (as I suggested in my previous blogs) only when you have to refactor old code piece by piece. Otherwise, always use Castle or Spring.


I feel I am returning to to my first blog, only now we have silverlight, and everything else is not “weird java thinking” anymore, they are now “pragmatic C# thinking” -- this history proved that to be “pragmatic” in C#, you got to learn java thinking.

I hope people will understand this soon. May 2007 will mark the end of that VB6 era. Yes, C# programmers, actually most C# programmers are from VB6. They just use C# as if they were VB6, even they say they are using OO. However, it is not about OO, it is about AO (apect oriented). Yes, silverlight means more market for browser based applications. However, the key is that we are not totally on the web (and still fast and “rich”)! Web is very different from window development: you always keep cutting edge (because there is not way to stop you from doing it other than yourself, or your tech lead – and if a tech lead cannot keep cutting edge, he/she will not be a tech lead soon!). The so-called difference between “morts” and “alpha” actually is the difference between “windows” and “web”. So, both PIAB and silverlight marks the end of an era. VB6 is totally over, finally.

silverlight and ActiveX: the new architecture ready to go

I want to use silverlight to access serial ports. The reason: I actually do need it; also, it makes a point: if you can do this, you can do everything on web applications.

I was hoping I can use AIR/Apollo to talk to serial ports; I was so disappointed. Here is my solution: use ActiveX.

Note that it must be a pure classic ActiveX (in C++ or VB), so that we do not need to install .Net on the machine (preferably C++; but as long as it works, most machines can run VB anyway, and as long as we do not need to install versions of .Net. Hey, that is the very point of silverlight -- I do not really care Unix or Mac, or do IJ -- I am very pragmatic).

Also, the ActiveX must not have any business logic. We can use MSCOMM, write our own (again, in C++ or classic VB, no .Net here!), or, buy one. I do not really care – as long as all logic is written in C# (again, this is the very point of silverlight!).

http://www.activexperts.com/activcomport/


Because of the security model, Silverlight cannot call ActiveX directly, but we can use javascript to trick it.


http://weblogs.asp.net/mschwarz/archive/2007/06/01/call-scribtable-methods-from-javascript-with-silverlight.aspx

http://blogs.msdn.com/devdave/archive/2007/05/21/calling-javascript-from-c.aspx

http://msmvps.com/blogs/luisabreu/archive/2007/05/17/calling-javascript-methods-from-your-silverligh-app.aspx

http://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx

OK, finally the new architecture is ready, now, let’s have fun with the ActiveX v2, oops, Silverlight, with PIAB.

Mac and Silverlight

http://www.oreillynet.com/windows/blog/2007/05/silverlight_will_sell_a_lot_of.html

Silverlight from a distance of 12 or 13 years, and Ajax, and doing java development without using java

Silverlight from a distance of 12 or 13 years, and Ajax


I know, Silverlight is a response to Flash’s huge success, and its more recent challenge (AIR/Apollo). Also, there is google’s offline Google Gear (see my previous blogs). However, let’s face it, those things are fundamentally inferior technologies. They are nothing. They are just javascripts. The real thing? Of course, Java! Finally .Net is catching up with Java’s applet.

Yes, Silverlight is better: it is better looking (very important for business!), and it is better functional (much lighter than Java, so that it can combine both the app and the runtime – for users’ perspective, of course). Both features come from Flash. Note that Flash itself is just a genius-but-still-hack-style response to applet, nothing more. As a result, I would say that Silverlight is better than applet just in the same sense that .Net is better than java (OK, I am biased) – it is just some minor incremental improvements (OK, I am biased again!).

So, what is silverlight? It is just M$’s applet. Ya, it took M$ 12 or 13 years. Note ActiveX stuff does not count, they are not even portable, which is the major and core claim of Applet.

It sounds like M$ bashing, it is just the opposite (come on, I am pragmatic): because it is a genuine applet-improved, let’s use it. Forget about Ajax! Down with javascript (and java), long live C# (and Ruby). Further, we do not even need to mention Flash -- that is just a toy.

Seriously, for new projects, I will use Silverlight, instead of Ajax; just like I used applet many years ago. Silverlight and PIAB, it is now all come back and complete: doing java development without using java! Have fun!

This is our new architecture.


P.S. Why, why Silverlight is better than clickonce and ajax?

1. Clickonce need the .net runtime deployed, it is a huge headache. It can never really solved, and as result, it prevents developers from using new technologies. As a result, every competent developer should dislike it. It is our number one enemy.

2. Ajax: you have to duplicate the validation logic in javascript. I remember I commented it long time ago. I was surprised that people are just quiet about it! I cannot believe it! This is the real reason that I am so eager to jump on silverlight. Writing duplicate code is an insult, hence, it is the number two enemy.

Time to use EntLib because of PIAB, but with Nunit

Time to use EntLib because of PIAB, but with Nunit

Just to balance to anti-M$ theme in my recent blogs (M$ exit strategy), I want to emphasize the point I have made: it is time to use EnLib because of PIAB.

However, let’s use it with Nunit, because VSTS sucks.

The key benefit of EntLib is that you can play “it is from M$” card, and shut down the whole architecture discussion. The good thing is that it is actually also an honest argument. EnLib is mature now -- we can aop façade pattern because of PIAB.

The whole stack of EnLib realize my “core 8 techniques” very nicely.

Of course, databinding, clickonce, ajax asp, web service-remoting: all those are also “it is from M$”, with all honesty.

This is my new “default architecture”, i.e., “architecture standard”. In addition to that, the entlib is the example of the coding guidelines.

The only addition to use entlib as an “architecture standard” is the following:

It is basically to call for the heavy use of PIAB and VAB: You must put all logic after the façades (PIAB) and within the entity classes (VAB), they should not be in UI.

(a) One derivative is: No dataset, absolute rule. Even this means for the time being you have to educate users to sacrifice some features, or, you have to put a lot of custom UI code, until you learn how to do databinding right, whatever, just do not use dataset!

----Derivative’s derivative: on Winform, use databinding.

SilverLight, ClickOnce, and AIR, Google Gear, DOJO

SilverLight, ClickOnce, and AIR, Google Gear, DOJO


Why clickOnce is not enough? It is not cool, first of all – it will limit our applications on Windows. The more practical considerations is that the framework itself is 20M, further, it takes 20 min to install, and it needs administrator privilege. We want to synced with technology changes, we do not want to use .net 1.1, simply because our client machines are not easy to upgrade to .net 2.0 – this is an extremely critical thing for developers, obviously, but it is also so, if not more so, for a healthy IT.

Why I need to use it outside browser? Because I need extra privileges, offline features, and near-real time reaction time (robot, machine control). Actually there is a “workaround” for the last one, put a web server there, etc. However, the thing is that all those must be zero-administration, just like a web in-browser application. Think about it, the last one is not really necessary: the embedded part is embedded, and if you need to access database, it cannot be “real-time” already. So, the real thing is privileges for socket (or, serial ports etc) and offline features (i.e. privileges to files and some added features).

I know I must look for it from mono. Why, because SilverLight is great for mono. Now, mono (do not forget, mono is the ultimate runtime – it combines java and .net) can have a decent “face” (UI). However, to do that we need to run it outside browser (for privileges etc.) – i.e., it is a just like Adobe’s AIR (Apollo).

All we need is to have a generic, small (do can be downloaded fast), “unsafe” host (webtop host, or, let’s call it “browser2”). This browser2 should have sockets API, so that SliverLight can use it. In a sense, the browser2 will give back all the power of a full .Net runtime – only the really useful ones though, so, the size can be much smaller also. It is, of course, the AIR, Google Gear, DOJO (http://dojotoolkit.org/offline) -- of course, those things must be done in C, and they must be platform specific.


http://ttlnews.blogspot.com/2007/05/test_22.html
http://labs.adobe.com/wiki/index.php/Flex:Open_Source

http://weblogs.asp.net/jezell/archive/2007/05/03/silverlight-vs-flash-the-developer-story.aspx

http://ectropic.com/wordpress/?p=3

AIR, Google Gear, SilverLight, and Javascript/actionscript/Flash, ruby, and JavaFX

AIR, Google Gear, SilverLight, and Javascript/actionscript/Flash, ruby, and JavaFX

I hope new flash runtime or AIR will add ruby support (I believe ADOBE or Mozilla will have to do that, because of the healthy competition!). Further, I hope IE and firefox will support Ruby as DHTML language and w3c will standardize it.

JavaFX will revive java applet. It is only fair! Java applet is the source of all those after all. However, I would not touch it for a while ;0(

Adobe’s AIR (Apollo) is even more aggressive. It is basically a “smart client” (click once), but with the same lightweight runtime (only 6 M).

SilverLight will be less “platform-like” (webtop, RIA – rich internet application). However, you can always use it in a style that M$ does not want to see.

------------------For .net programmers:

Keeping doing ajax, user a little bit flash to beat winform/WPF for now (this is pretty safe politically, because flash is just UI, it is not another language/platform), learn more “low level” javascript.

Also, learn a little AIR, a little Google Gear, a little ruby (by yourself, or as a utility tool), learn SilverLight, use ruby with SilverLight (it is safe politically, because it is just a scripting tool) and with Google Gear. When it comes, you will be ready.

Also, always keep an eye on AIR – it is the new model that M$ will have to fight and follow, just like netscape/IE competition.

Another thing to think about is that in order to be prepared for SilverLight, google-gear, or AIR design, smart clients must also be thin. This should be the case anyway.

http://labs.adobe.com/downloads/apolloruntime.html
http://www.adobe.com/devnet/flash/

http://www.asp101.com/articles/flash/
http://www.asp101.com/articles/flash2/index.asp


http://www.smartwebby.com/Flash_and_ASP/default.asp

http://www.entheosweb.com/Flash/default.asp

http://www.dmxzone.com/ShowDetail.asp?NewsId=2002

http://www.15seconds.com/issue/010605.htm

http://www.devshed.com/c/a/Flash/Building-DataDriven-Flash-Movies/

http://www.bizwerk.net/asp20tutorial/flash_multiple_fields.htm

http://www.smartwebby.com/Flash/external_data.asp

http://www.amazon.com/exec/obidos/ASIN/1904344089/bizwerk-20

http://www.aspin.com/home/tutorial/graphics/flash

http://www.download.com/Macromedia-Flash-Professional/3000-6676_4-10227159.html
http://www.adobe.com/products/flash/

-----------------------------------------
http://www.thefreecountry.com/webmaster/flash.shtml

http://flashkit.com/tutorials/

http://www.creatingonline.com/webmaster/flash.htm

http://www.flashberry.com/

M$ exit strategy: OS X, ALT.NET, aop, PIAB, facade/command patterns, use more web (esp. castle) get ready for ironruby. Ajax and Google Gear

http://vikasnetdev.blogspot.com/2007/06/perfect-storm.html

Vikas never fails me to “force” me to look at something wonderful! I followed the links. I have to admit that I abandoned non-M$ for a while – for too long! I almost lose my perspective, I am almost lost! M$-only is not good for your vision for enterprise computing – I guess we all know that already, this is just another example! Be careful when you are M$-only.

The following are items of my notes. The basic ideas is to get a vision or perspective so that not get stuck with M$-only, i.e. M$-only exit strategy or risk-free strategy, for both individual developer's career and company's sustainable IT service.

http://www.marketwatch.com/News/Story/Story.aspx?guid=%7B629B28CD-9E0E-48CA-8E8B-243AA6E2CB92%7D

http://www.paulgraham.com/microsoft.html

Now, let's get to the technical part. The key is aop. Why ruby is good? because it is not only oop (which is ordinary nowadays) it is aop, pragmatic aop!

To reach ruby in corporate culture, you need either JRuby (available now) or IronRuby (not yet). Further, at least for a while, it has to be, mostly, web. So, to get ready for Ruby:

(a) Understand OOP-AOP by using command pattern (CSLA-simplified), facade pattern by PIAB, castle, springframwork.

(b) You need transform all windows to web (with ajax, Google Gears, flash99/silverlight that is not that a big deal anymore!!!) Note that you need to do it anyway. For ordinary business application (i.e., if not weird stuff), always use Web. The de fault is web, anything else must be carefully scrutinized and specially arranged. Saying Web is crap is wrong, simply wrong. Smart winform or WPF, does not matter, they are fat, and fat is out, thin is in, even deep in the heart of business workflow. Intranet is now deep in the "IN". period.



--------------------------------------------os x
http://www.martinfowler.com/bliki/RubyMicrosoft.html


http://www.martinfowler.com/bliki/AlphaGeek.html


http://www.oreillynet.com/pub/a/network/2002/04/09/future.html


OS X combines Linux (guilty-free computing, yes, I am using cygwin; I want to use unix, because it’s open source, well, most of them) and ipod!

http://www.linuxdevcenter.com/pub/a/mac/2002/05/14/oreilly_wwdc_keynote.html?page=2


Hardware: Apple makes it clear that although open-hardware is a good thing, however, it is less important than open-source-software. The reality is that for now it is not easy to get both (but it is possible though, like linux or Solaris for PC; however, they are not consumer-feature oriented – the reason, money, of course – so, it is difficult to do that, let’s face it) we cannot get both, so, if we have to make choice, we should choose close-hardware-and-open-software, instead of the other way around (which leads to M$). Apple or PC-M$ -- that is the question.



----------------------------- stacks and frameworks, DRY, ALT.NET, AOP, Ruby as perl-relive
You may say that perl started the internet booming; let’s hope ruby can do that again!

I guess that is the reason I begin to dislike using frameworks “as is”. They tend to encourage developers to get into warming water and be cooked like frogs. I want to get the ideas, and remove all those artificial stuff, or, non-DRY (Don't Repeat Yourself. Take a look of CSLA, it is so not DRY! I am not biting my feeding hand; I just love the truth more ;-)

http://weblogs.asp.net/rosherove/archive/2007/06/04/alt-net-alternative-tools-and-approaches-to-mainstream-net.aspx


ALT.NET: just like lightweight Java, ALT.NET is cool, and also lightweight. The key of it is AOP – aspect oriented programming, and that leads to castle and ruby directly) – neither heavyweight Java nor VB6 style (or M$ mainstream) has it.


Also, M$ now has the PIAB. It requires interface, so, it cannot be used for entity properties, so, it is less useful (and much slower) than castle's -- perhaps I should work on borrowinng castle into PIAB. Still, it can be used for many things already. For example, we can use it to avoid CSLA's command pattern (on the forth hand, CSLA's command pattern will be always be an option, for its simplicity). In other words, I guess becuause of PIAB, the facade pattern is now officially has a upper hand toward command pattern! This is a historical moment. My prediction that .Net will take a different path from Java's may turn out to be incorrect. Command pattern sucks, anyway, even it is simpler.

---------------------------------ALT.NET: the following are related with the 8 core techniques
---------------------------------the core of the core is marked by "****" (aop)
---------------------------------it is amazing that those 8 core techniques are now covered by
---------------------------------Elib! the PIAB is the aop.

NHibernate Entity Framework or application block
Windsor Container ObjectBuilder
Aspect# ****Policy Injection Application Block or Use entity-command pattern
CruiseControl.NET Visual Studio Team Build
SharpDevelop Visual Studio + resharp
MonoRail Web Forms with ajax (subsonic)
NUnit/MBUnit MSTest
Scrum MSF Agile
NAnt MSBuild
log4net Logging Application Block
Silverlight Flash
Smartcode CODESMITH
Google Gears
(offline web) Smart client databinding


---------------------------------ruby: web/ajax is important: windows sucks, because you cannot try new technologies almost-freely.

-----------------------------------ruby: new wave:
Quote from Martin: “We're already seeing signs of this at ThoughtWorks - 40% of our new business this year in the US is Ruby work”


----------------------------------I read Martin Fowler’s blog, I have to say that I feel I should start read more his work now regularly. I stopped reading his blogs regularly because of the Enterprise Patterns (I know it is very popular; but I felt it just did some renaming).

Argument against UML: UML are just presentation drawing tool (Power Point Plus), even class diagram is the same category

Argument against UML: UML are just presentation drawing tool (Power Point Plus), even class diagram is in the same category


I have been feeling that way for a long time, except class diagrams or ER diagrams.

Then, there are two things:

(1) Users cannot really understand class diagrams. It is much easier to list those table names, and put columns there, and (most importantly) put some example data. In other words, simply put the output (including the heading) of the “select * form XXXtable where rownum <5”. Of course, if the table is too wide, you have to cut it a few times, so that the width of the document is printable (details, details, I know).

You may say: you can train users. Yes, however, the key part of it is that UML does not give you a way to list example data. That is fatal.

(2) The document must be readable to users. “Design only” or “Developer only” document is not that useful (I would say actually harmful!) for most projects, even large project. My stand is that, if the document is developer-only, then, I would quote legendary XP: the code is the documentation – so, we do not need the document!

As a result, from now on, to me, my stand is that even class diagram is just a nice-to-have beautiful drawing tool. The bottom-line thing is, the code (and some reverse engineering capability to generate beautiful diagram from the code), and the listing of “select * form XXXtable where rownum <5” (including heading).

So, the core document is all plain text based, summary use cases, use case scenarios, and a “glossary” which contains listings of “select * form XXXtable where rownum <5” (including heading).


OK, the title is misleading or intentionally provoking ;-), UML is useful, you need to know it. The key point is, if you really know it, then, you would not need to show-off. It is just a presentation tool – note that you need presentation tool even when there is only yourself or one another person.


Also, do not get me wrong -- in the document, you can put in a lot of UML diagrams – the document should certainly be ready for “presentation”. However, the core part of the document should be “Mom, look, no diagrams!”

As a matter of fact, this applies to even mockups. I am the first one to emphasize the importance of mockups. However, mockups are, well, just mockups. As a result, in the document, we need to keep the ad hoc nature of those mockups. They should be ad hoc, ugly, and even “unprofessional” – the “unprofessional” look of those mockups means that you are indeed a very knowledgeable professional! The key thing here is to make them fast – you must be very responsive to users, and you must invite users to participate in the drawing, be transparent to them. Then, users will “forgive” the ugliness, and even appreciate the ad hoc-ness of your mockups – after all, they are theirs’ baby also!

Put it in more tangible terms: in the beginning, we need to be able to draw electronic mockups, without using IDE and screenshot. I understand that there are many drawying tools. However, to enable users to participate in the drawing, we need to be able to draw screen design using Word, and be able to do that very quickly.

My trick? Using tables, nested tables: it is simple and fast. Users can immediately “get it” and participate.

Of course, very soon, you will update the ugly tables with real screenshots -- but in random order and still with a lot of ad hoc style – ya, intentionally keep it sloppy, until the last final version – it is almost a mind game, but it is important to let users know that UI is less important than business rules – users will always pay attention to UI, and we need always to remind them that UI is just the skin, and the muscle and the bone are more important than skin, even it is the face skin! Sometimes, during the process, periodically, you can “leak” a few business rule bug to users, to get users’ attention back to business rules, and remind them that those bugs are more important than “where to put the button”! The last version should be accurate, so that it looks as a user manual. However, unless you have a technical writer, do not try to “enhance” the screenshots. For example, except for very busy screens, do not try to split the screen in the document – it does not worth it. It prevent you from updating it continuously and therefore hurts the product or the accuracy of the very document!.

The key thing is, UI is NOT the focus – mockups are not VB6’s UI driven approach! Ya, I know, I just cannot help mentioning VB6ers recently. Think about it, all those arguments again visual pictures are to correct VB6-ers’ terrible instinct to be attracted by visual things. To such an extent, I even have to say that the “visually” in “design visually” is not that important than the fact that you must do “design” – do not let the “visually” hurt the “design” – right, that is the exact point I have been trying to make in this blog -- UML and mockups, they are visual, so, VB6-ers will twist them into something that can hurt the essence of design, I see through it now! I guess very soon I will be an expert of mentoring a VB6 team to “get it”.