Archive for the ‘ Best practices ’ Category

Swarming for dummies

Posted in Best practices, Programming Philosophy, Swarming on October 13th, 2012 by sinica – Be the first to comment

Intuition about SwarmESBhttp://salboaie.github.com/

Really, wtf  is swarming?
  1. abstraction build over asynchronous messages…. yes you can repeat this but it is not very useful.
  2. you put your APIs (functions, calls to web services, basic building blocks of logic,etc) in nodes and  you compose all these in a special language that get executed by jumping from node to node.  Makes sense to you?

Why is called swarming?

  1. because I like organic metaphors
  2. because jumping  from node to node  (using the network) of a set of values can be seen as sending messages but can be seen also as a swarming of some mysterious bees that care the honey (values :) ) . After a  swarm reaches a node, it can swarm again and again and you can describe and understand in a single place all the related swarming activities started in a node . What can be cooler than that?

It is not somehow similar to SOA?

Yes it is.  It is trying to solve similar concerns and actually it can work well in a SOA environment.

SwarmESB is really an ESB?

ESB have many meanings but basically, by swarming we are targeting the orchestration and loose coupling issues that all ESB are trying to address.

What are we trying to sell?

Posted in Best practices, Business thoughts, Future, Opinions, Programming Philosophy on October 5th, 2010 by sinica – Be the first to comment Tags:

“Elegance is not a dispensable luxury but a factor that decides between success and failure.” Edsger Dijkstra

We had a discussion today in a meeting and we had an strong insight: we don’t try to create/sell just another RAD framework but we are trying to sell: an environment that will enforce code discipline,an architecture that respects the experience of the industry (like MDA), best practices.

Really! We even decided to sacrifice from the programmer’s immediate convenience in order to deliver what we promise: reduced  maintenance costs for the final applications. That could annoy some users if we fail to communicate what we are really selling: DISCIPLINE in PROGRAMMING with  MVC,  good practices and environment that will inhibit programmers  to do clever tricks. Only at the end we should say that we sell  a simpler programming framework! Sure, we are also targeting Excel users (at least the most sophisticated ones and only for simple things like CRUDs,simple forms) but it just happens that doing a “visual editor for MVC” led us near possible alternatives to spreadsheets space of tools. It is risky,very risky for a business to educate his customers but we are trying our best to do it in a easy and rewarding way.

Yes, a good education is required to appreciate elegance but usually the most elegant solution is the one that is more simple and efficient (almost by definition of the elegance) and we are thriving to achieve just that!

By best practices we mean things like:

  • loose object coupling [1]
  • real MVC architecture (and as simple as possible)
  • MDA
  • don’t mix many technologies and APIs in the same place (or like mixing view with controller as in many pseudo MVC frameworks)
  • Don’t re-invent the wheel [2] (we have reinvented it for you ;) )
  • Keep things as simple as possible but not simpler. [2]
  • Learn from others mistakes, not your own. [2]
  • Begin with an end in mind [2]
  • If it’s not broken, don’t fix it. [2]
  • others…[]

References:

[1] http://en.wikipedia.org/wiki/Loose_coupling
[2] http://social.msdn.microsoft.com/Forums/en/Vsexpressvb/thread/78f6a9ba-05eb-45b7-88d5-8bcfcf0643cc

Format the text inside a Spark RichEditableText control

Posted in Best practices, Flex on August 26th, 2010 by bogdan – 5 Comments Tags: , , , , , , , , , , ,

Lately I’ve been working on a code editor, based on Flex 4.1, that should be similar to a modern
editor with the so needed syntax highlighting feature. In order to highlight reserved words, strings
and comments, the text is transformed into tokens, which contain useful information for coloring
such as its position in text, length and the type, used to decide which color should be used to
highlight the token.

Everything went well until formatting RichEditableText to highlight the tokens, which was tricky.
My first implementation was something like the code below :

	for (var i:int = 0; i < tokens.length; i++)
	{
		var tlf:TextLayoutFormat = new TextLayoutFormat();
		tlf.color = tokens[i].color;
		richEditableText.setFormatOfRange(tlf,
			tokens[i].beginIndex, tokens[i].endIndex);
	}

This implementation was way too slow: if I pasted a text with around 125 of words to be colored, it would take up to 19 seconds. That was unbelievable, so I started searching about the performance of setFormatOfRange method. By reading some forums and the source code for RichEditableText class, I noticed that this method triggers update on all the elements of textFlow, which happened for each of those 125 words and dropped so much the speed of formatting and displaying the text.

So to solve this issue, all the format operations should be wrapped into a single one to be executed, and when this is done, trigger the update only once.

Fortunately, the Text Layout Framework provides an API for doing just this through flashx.textLayout.operations package. So I wrapped each format operation into an ApplyFormatOperation, which was added to a CompositeOperation object and executed the latter one.
Below is a sample implementation for my improved solution :

	var compositeFormatOperation:CompositeOperation =
		new CompositeOperation();
	for (var i:int = 0; i < tokens.length; i++)
	{
		var operationState:SelectionState =
			new SelectionState(richEditableText.textFlow,
				tokens[i].beginIndex, tokens[i].endIndex);
		var leafFormat:TextLayoutFormat = new TextLayoutFormat();
		leafFormat.color = tokens[i].color;
		var formatOperation:ApplyFormatOperation =
			new ApplyFormatOperation(operationState,leafFormat,null);
		compositeFormatOperation.addOperation(formatOperation);
	}
	var success:Boolean = compositeFormatOperation.doOperation();
	if (success)
	{
		richEditableText.textFlow.flowComposer.updateAllControllers();
	}

Notice that after the composite operation is executed, I update the textFlow only once.
This improved solution dropped the time from 19 seconds to 0.3 seconds, an 63x improvement that makes
my code editor usable again.

I didn’t use an EditManager because it dispatches TextOperationEvent.CHANGE, which I listen only for text changes (insert, paste, cut, delete) on my RichEditableText. So if text changed, I would set color on some tokens by calling applyFormat on EditManager, which would send a new TextOperationEvent.CHANGE and I would ended up in a infinite loop.

I’m sure there might be better ways of doing this (I just haven’t discovered yet), so I’m open to new suggestions and I hope this post would serve as a starting point for others having similar task with the new text controls inside Flex Spark framework.

For more information on Text Layout Framework you may have a look at this PDF file

Models,Models?,Models!

Posted in Best practices, Programming Philosophy, Quark framework on August 15th, 2010 by sinica – Be the first to comment

The  model is the central part of any MVC application.  But what exactly the models are? Simplistically,one can see the model as  database schemas plus some data structures that reflect data from databases at runtime.

I have tried this “simple” approach in the past frameworks (even in Quark 1.0) and we used classes that mimics the usual OOP classes that languages as Java or Action Script provides by default.  In Quark 2.0 we have created a new XML based, OOP language that we call Quark Schema that is providing support for nice and useful models:

  • declaratively describe the persistence and the life of the objects
  • declaratively describe the constraints, validation and relations between model’s objects
  • describe class behavior
  • is fully editable using GUI tools that we are currently building

We found that we can discern 6 categories of objects (they are not orthogonal categories ):

  • transient objects – objects that exists only at runtime in one instance of the application and should not be saved in a persistent storage
  • globally persistent objects: objects with global identity (even for different users )
  • locally persistent objects : objects that have no global identity but have a local identity inside of a global or transient object
  • relational objects – objects that mimic the structure of relational tables
  • document objects – graph of objects that contain other objects
  • shadow objects -objects that doesn’t contain user data but inner information of the system.  Example of shadow objects : configurations and the structure of the view. Shadows get automatically generated and one  is doing customization by using visual tools organically embedded in the application but it doesn’t care much about shadow’s structure.

    Observations:
  • Global objects that contains other local objects (or are persistence roots for graph of objects as we call it ) should be seen as complex documents structured as graphs that can be used as configurations or data structures. Quark Framework allows you to describe models in the form of normal “relational” objects or in form of  ”document” objects.
  • Document objects can be seen as relational objects with fields that are root for trees containing local objects  serialized as XML strings.
  • Shadow documents are usually document objects.
  • Transient objects can be global or local
  • Members of classes can be declared  transient and will not be present in the database schema but their values get serialized depending of their declaration as  local,global( or created as transient objects or no)
  • We have discovered that local objects have an interesting property: when they are assigned to a member of a class member from a different persistence root (different persistence global root object) they should be automatically cloned.   Quark Schema is automatically doing just that and we discovered that is nice and useful in real cases.

Apparently all these rules and observations are a bit complex, fortunately the business user will use a simple UI to create such classes (models) and should not worry much about persistence aspects.  It will just communicate his intentions and the system will do “the magic”. Local objects are usually shadow objects and will be a concern for component creators and rarely for the business users (customers or consultants).

This article is long enough so I will not present  any syntax but I want to mention only that for Quark 2.0 we have got all these aspects working and well tested with unit testing.  Drop me an email for any questions.

At the end, take a look at this picture that is saying: “the model should be fat but it should be constructed with skinny,elegant and nicely shaped classes”:

Creating  above picture piece by piece is  a laborious process. For me, it took 1 minute to create using Google search for images and a screenshot. Similarly, our goal is to create a tool that  will allow  creation of a working business application in minutes and we believe that we are not far from it! A new direction I’m contemplating now is to have  Quark Framework  as a tool for creation of mashup applications [1] with data from multiple business applications. It is a logical use of Quark and fortunately it results from our design,without much supplementary programming work.

References:

[1] http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

What will save the “save button”?

Posted in Best practices, Programming Philosophy, Quark framework, UI design on August 11th, 2010 by admin – Be the first to comment Tags:

In the quest for eliminating all unnecessary barriers in having ultra rapid application development we realized that the save button is sometimes quite Evil. For web applications the Save button is somehow inefficient and could lead to confusion and loose of data because of browser crushes,network errors,user mistakes. The save button is also increasing the complexity of the system. Many hardcore programmers will say that it is not much but our framework wants to allow even non-programmers to create working applications with an effort equivalent with that of creating a spreadsheet.  We think that the approach of periodic auto-saving is the way to go in Quark for  almost all cases.

If the framework provides cheap (or free)  undo,redo operations for all operations that users can do,naturally that we can have nice applications without the “save button”.

What “save button” provides and “workarounds” could be required:

  • the biggest issue: workflow and integration with process management capabilities. If a user is just playing with data in UI,could trigger workflow changes unintentionally. Business application that have workflows are normally used by serios people that will not just click randomly and press keys,but still, this could be a problem.
  • protection for “cat” operations – if a user is just playing with his keyboard or a cat is walking on it,bad data could find a way to the database
  • implementation of atomic changes:provide consistent persistent storage.  In some cases,changes in a part of an object without changing other parts will lead to an invalid states of the object. This problem will be avoided with a validation, Quark Framework will not auto-save invalid objects.
  • implementing transactional operation for graph of objects will require additional,a bit more complex validation

I think that cases that will require a higher level of validation,could have a standard “validate change” button or “apply” button in the UI and the “auto-save” will not save those objects that are not manually validated.

Quark framework 2.0  provides for free (almost) undo,redo and auto-save. These features were not present in Quark 1.0.   So,what do you think?  Do you really need to put users pressing the “save button” after each important change ?

What is wrong with MVC?

Posted in Best practices, Opinions, Programming Philosophy on August 7th, 2010 by sinica – Be the first to comment

Nothing is wrong! MVC is the most famous design pattern after singleton but people have very diverse opinions and there are quite a lot of misunderstandings about this powerful design pattern.

MVC design pattern is  illustrated by this figure (from wikipedia [1] ):

Mode view controller

Even if those dashed and solid lines are looking a bit dubious, in many existing MVC implementations  the reality is even more complex than this, look at the next  image from [2]:

Simple? No? Necessarly complex? There is no final answer yet, but in Quark 2.0 we have a simpler and elegant communication  paradigm between Models,View and Controllers.

In Quark, the controller is controlling the model and the view is strictly rendering the Model while triggering the controller when the user is asking for something. Also, as you can see in the picture, we are fans of fat models [3] ,  skinny controllers and dummy,auto-generated views like in Naked Objects , MDA,DDD [4] .

We know that some programmers do not have the capacity to understand that a “Model” is not just a wrapper of a database table but our approach that we call “Quark Schema”   should make things easier for anybody: advanced programmer or clueless user. Even non professional programmers could do the right things without worrying much about philosophical and technical details of MVC.  Our goal is to make a tool and a programming framework that will look and be simple like doing things in  Excel but resulting in nicely growed Organic Programs.

References:

[1]  MVC in Wikipedia: http://en.wikipedia.org/wiki/Model–view–controller

[2] Pure MVC page on Wikipedia http://en.wikipedia.org/wiki/PureMVC

[3] Links about Fat and skinny Models and controllers, anemic domain model,etc

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

http://nuts-and-bolts-of-cakephp.com/2009/01/06/another-way-to-think-about-mvc/

[4] Naked Objects, About MDA and DDD : http://en.wikipedia.org/wiki/Naked_objects

And just for fun (and profit for some): About Fat Models