The Helicopter story

I just read a nice article (check this link), it spoke about the principle of orthogonality in software design. Without further ado, here's the helicopter story.

A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.

It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you're constantly dancing on all the controls to keep the helicopter stable.

That's kind of similar to code. We've all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you'll always get that kind of distributed bug fixing.

The funny thing about the helicopter story is that I'm not a helicopter pilot. When I wrote the helicopter story, I wanted to make sure it was accurate. I knew of a USENET group on helicopters, so I posted the helicopter story saying, "This is what I'm intending to write about how helicopter controls work. Is it correct? A helicopter pilot emailed me and said, "I read what you wrote about controlling helicopters. I didn't sleep all night."

Add index to your table to speed up queries

I'm not a database expert here and I just learned this tip today.

If you have a large table and one or more columns are often used in the where clause, you might want to consider setting up index for those columns.
But one thing to note, in oracle (maybe for other database also), if you're doing a calculation on the column in the where clause, your index isn't used by the optimizer.
e.g. where column * 12 > 1000

My friend today was trying to optimize a query, by introducing an index, the result was awesome, instead of doing a full table scan (the size around 60 something mb), the optimizer use the index thereby reducing the cost and the time consumed.

One other option that was set is to allow the database engine to execute parallel queries on the table.

But if we setup too many indices, will that make inserting record to the table much slower?

Beans that you could access from your dashlet in alfresco

If you're developing a custom dashlet or any jsf page for any purpose in alfresco, you could use the beans listed in (alfresco\WEB-INF\faces-config-beans.xml).

Here's the list :

• MultilingualManageDialog (The bean for the Delete Category screen)
  
• ManagePermissionsDialog (The bean for the Manage Permissions)
  
• MakeMultilingualDialog (The bean that make a document multilingual)
• EditMLContainerDialog (The bean that edit the multilinguals properties of a document)
• AddTranslationWithoutContentDialog (The bean that add a new translation without content)
• AddTranslationDialog (The bean that add a translation with a content)
• LoginBean (The bean that backs up the Login screen)
• NavigationBean (The bean that holds navigation state)
• BrowseBean (The bean that holds folder browse state)
• AboutBean (Bean that provides information for the About page)
• DialogManager (Bean that manages the dialog framework)
• WizardManager (Bean that manages the wizard framework)
• CreateSpaceDialog (The bean that backs up the Create Space Dialog)
• CreateSpaceWizard (The bean that backs up the Create Space Wizard)
• DeleteSpaceDialog (The bean that backs up the Delete Space Dialog)
• ClipboardBean (The bean that manages a users Clipboard state)
• RecentSpacesBean (The bean that manages the state for the Recent Spaces Shelf component)
• UserShortcutsBean (The bean that manages the state for the User Shortcuts Shelf component)
• SearchProperties (The bean that holds a state for the Advanced Search screen)
• AdvancedSearchDialog (The bean that holds a state for the Advanced Search screen)
• UsersBeanProperties (The bean that holds state for the Users screen)
• UsersDialog (The bean that holds state for the User Management screens)
• GroupsDialog (The bean that holds state for the Groups Management screens)
• CategoriesProperties (The bean that holds state for the Category Management screens)
• CategoriesDialog (The bean that holds state for the Category Management screens)
• EditSpaceDialog (The bean that backs up the Edit Space Dialog)
• AddContentDialog (The bean that backs up the Add Content Dialog)
• CreateContentWizard (The bean that backs up the Create Content Wizard)
• EditContentWizard (The bean that backs up the Edit Content Wizard)
• ViewContentPropertiesDialog (The bean that backs up the View Content Properties Dialog)
• SetContentPropertiesDialog (The bean that backs up the Set Content Properties Dialog)
• ..........
• WorkflowBean
• and a lot more....

I can't believe that the list is so long that it even make me think to create a small program to load the xml file and parse it just to get this list :)
Anyway, bottom line is these beans might help you, knowing that they're exist already a help.

Alfresco tips

The tips that I will write here might seem silly but it works for me and I do hope it will help someone else and... I think I'll continue to add more items on this list someday.

Should we start now? :)

1. Always read the wiki thoroughly, sometimes one page won't help you, other pages might contain the information you might need (sometimes I feel they're scattered and I just have to gather them pieces by pieces).
2. Read the existing code/example, it will certainly help you. For example, if you're creating a dashlet, look at the other dashlets already available.
3. In case you need to go deep (read : debugging alfresco), you could try to download the code, build it and run it :)
4. In case the above is too difficult, you could try to at least get the source and put it in a project in eclipse (or any IDE) and remotely debug alfresco (see my post) .
5. If you need to debug the workflow, get jBPM source code and do the same thing as no 4.
   
6. Do yourself a favour by writing down all the changes you've done in alfresco in case you need to revisit it later, I can assure you that you won't be able to remember it for long (unless you're playing with alfresco everyday :).
   
7. If you're creating a custom workflow and at some point in your workflow you need to make a branch based on some properties value, use a decision node.
8. If you're creating a custom workflow, you might need to consider reading jbpm's documentation, especially on the jpdl chapter
   
9. Use jpdl designer (free!!) to build your workflow, it will do you a favour later when you come back to your workflow. Go to http://www.eclipse.org or download jBPM GPD.

This is it for the moment, more to come later.