http://activeden.net/item/advanced-simplified-xml-css-flex-image-gallery/70592

This is the first time I saw something worth looking at flashden (in terms of flex components)

This component is AS2, but its design is cool:

http://activeden.net/item/xml-gallery-v80/70857

Also flexden.net has some good components too.

Update:

This guy has a lot of flex components too: http://activeden.net/user/loziosecchi

http://apdevblog.com/as3-open-source-videoplayer-out-now/

and the module framework

http://jvalentino.blogspot.com/2009/05/command-module-framework.html

I forgot another framework with decent support for module. If someone can think of one, please let me know.

应聘职位：产品经理

问题：如果让你清洗西雅图市所有的窗户，你会对此索价多少？

应聘职位：产品经理

问题：在一个重男轻女的国家里，每家每户都想生男孩。若一户人家生了一个女孩，便会再生一个，直到生下的是男孩为止。请问这个国家的男女比例是多少？

应聘职位：产品经理

问题：全世界共有多少位钢琴调音师？

应聘职位：产品经理

问题：下水道井盖为什么是圆的？

应聘职位：软件工程师

问题：为旧金山市设计一个紧急疏散方案。

应聘职位：产品经理

问题：时钟的指针一天内总共会重合多少次？

应聘职位：产品经理

问题：阐释“死牛肉”的意义所在。

应聘职位：软件工程师

问题：一个人开车来到旅馆，变得一无所有。究竟发生了什么事情？

应聘职位：软件工程师

问题：你想知道好友鲍勃是否有你正确的电话号码，但又不能直接问他。你必须在卡片上留言，让伊芙将卡片较交给鲍勃。除了问题以外，你还应该在卡片上写什么，才能既确保鲍勃能看懂留言，又使伊芙看不出卡片上写有你的电话号码。

应聘职位：软件工程师

问题：你是一艘海盗船的船长，你的船员要投票决定如何平分金条。如果与你意见一致的船员数量少于一半，你将被杀死。你应该如何提议分配金条，才能既分得较多赃物，又能活下来？

应聘职位：工程经理

问题：你有8个大小一样的球，其中7个重量相同，只有一个略重一些。给你一个天平，而且只准称两次，如何找出重量不同的那个球？

应聘职位：产品经理

问题：你在一幢100层高的大楼中，给了你两个鸡蛋。鸡蛋有时非常易碎，有时又异常坚韧。这意味着，如果在第1层扔下鸡蛋，鸡蛋或许会碎裂，而如果是从第100层扔下鸡蛋，鸡蛋或许安然无恙。这两只鸡蛋一模一样。你需要计算出，最高从哪层楼扔下时，鸡蛋不会碎。问题是，你需要扔多少次鸡蛋才能算出该楼层。整个过程中，你只允许打碎两个鸡蛋。

应聘职位：产品经理

问题：向你8岁的侄子或外甥解释什么是数据库，只能用三个句子。

应聘职位：产品经理

问题：你缩小到只有一枚五分硬币那么高，你的质量也成比例缩小以保持原有密度不变。随后你被扔到一个空的玻璃搅拌器里，搅拌刀片将在60秒后开始运转，你该怎么办？

应聘职位：产品经理

http://www.smartagile.com/2007/10/agile-project-planning.html

I have this page bookmarked for reference

1. Property Injector
   

   Using this when a manager needs an object from another manager, and should be updated automatically when it changes.

   Set the registerTarget attribute to true when creating the receiving manager (by default it is true so this is not necessary), and create a Injectors that sets up a binding. The receiving manager will be updated just like a view or presentation model object would.

   <EventHandlers type="{FlexEvent.PREINITIALIZE}">
     <ObjectBuilder
            generator="{ApplicationManager}"
       registerTarget="true"/>
   </EventHandlers>
   
   <Injectors target="{ApplicationManager}">
     <PropertyInjector
       targetKey="saveNeeded"
          source="{DocumentManager}"
       sourceKey="documentDirty"/>
   </Injectors>

2. Events
   When a manager must be able to notify the application of something.

   Inject a dispatcher into the manager when it is created. The manager can use this dispatcher to dispatch events that can be heard in the event map.

   <EventHandlers type="{FlexEvent.PREINITIALIZE}">
     <ObjectBuilder generator="{ApplicationManager}">
       <Properties dispatcher="{scope.dispatcher}"/>
     </ObjectBuilder>
   </EventHandlers>
   
   <EventHandlers type="{ApplicationEvent.EXIT}">
     <MethodInvoker
       generator="{NavigationManager}"
          method="navigate"
       arguments="{[NavigationManager.EXIT]}"/>
   </EventHandlers>

   In ApplicationManager:

   dispatcher.dispatchEvent(new ApplicationEvent(ApplicationEvent.EXIT

3. DataCopierWhen a property on a manager is needed as an argument in a method call.Use a DataCopier to place the object temporarily on the data object, for easy access in the arguments attribute of a MethodInvoker tag.

   <DataCopier
        destination="data"
     destinationKey="user"
             source="{UserManager}"
          sourceKey="user"/>
   
   <MethodInvoker
     generator="{NavigationManager}"
        method="navigate"
     arguments="{[NavigationManager.USER_PAGE, data.user]}"/>

http://mate.asfusion.com/forums/topic.php?id=217, here is the diagram:

http://blog.wrench.com.au/wp-content/uploads/2008/12/presentation_model_flow_diagram_mk_4d.png

Especially this part is interesting:

From this example, it seems that, in general, best practice would be to divide each big component into 6 parts

Not quite. If every view mapped right to a model entity, then perhaps, but otherwise I don’t think that it’s a good description. Let me go though the parts you list and explain them one by one, and then put them against each other.

• Model object (for example Document): This is the representation of the data in your application.
• Manager (for example DocumentManager): A manager keeps track of model objects and provides a transactional interface for working with the model. It’s not quite as simple as one manager for each kind of model object, in some situations there might be managers that don’t handle model objects at all (for example a NavigationManager), or two managers handling objects of the same kind, it depends.
• Application controller (event maps in Mate): Controllers map actions (events) to methods on managers, and wires the application together by setting up bindings between managers and views. Local event maps can be used to create subcontrollers that act as mini-applications within a larger application.
• Actions a.k.a. User Gestures (events): These represent the actions the user (or application) can perform. Actions map more or less 1:1 to methods on managers (there are exceptions where more than one method on a manager needs to be called, or methods on several managers, but these are more rare, but also not bad in any way). Actions carry any data needed to identify in which context to perform the action, and with which data (for exampe by passing along the object that should be manipulated, as well as the objects that should be passed as arguments).
• View and Presentation Model: Presentation models act as mediators between the application and the view and contain all view logic. They insulate the view from the specifics of the application by presenting a simple, view-centric interface of the model to the view. For example, if a view should display the details of an employee, instead of handing the Employee object directly to the view the presentation model presents an interface containing the properties name, phone and email. Behind the scenes the name property is created by concatenating the firstName and lastName properties of the Employee object. The view call methods on the presentation model, and the presentation model translates these method calls into actions that the application understands.

Now, what goes where?

• Model object vs. Manager: Model objects contain all the code for manipulating their own state. The manager only provides an interface for calling methods on model objects in a safe way.Many times a manager will have methods that have the same name and the same parameters as the model object. The manager may check the parameters before calling the model object, or it may register that the action has been perform (for example to provide undo-capabilities).A manager may also have methods that acts on the current item of some kind, without the caller having to have a reference to the object representing the current item — but it is still the model object that does the work.Model objects should not have a mutable interface, i.e. they should not have public methods that change their internal state. Instead any methods that change state should be hidden so that only managers can call these (you can always get around this, but it’s a conceptual kind of hiding, more like marking the methods so that it’s obvious that they should not be called willy-nilly).
• Manager vs. Presentation Model: Managers are the model, they keep track of model objects, modify them and move them around. Presentation models adapt the model for views. In some ways managers and presentation models are similar, they keep track of objects and present an interface for working with these objects — and to the view, it’s presentation model is the model. It doesn’t know anything beyond.You ask specifically why we can’t ditch the managers and do all the things managers do in our presentation models instead. One reason is that each view class has it’s own presentation model class, so there would be code duplication. Managers provide a single interface for manipulating the model, leaving no room for errors that occur when different parts of the application do the same thing slightly differently. By having a single interface we can also add side-effects to some actions/user gestures; side-effects like saving only when it is needed or keeping an undo history.
• Manager vs. Event Map: Event maps should be kept as simple as possible, essentially only mapping events to method calls, or remote calls (besides creating managers and setting up injectors). Event maps only wire things together, they should not contain any logic more complex than moving some data around and wating for the response of a remote call. Event maps should be stateless (they act the same regardless of when an even arrives) — managers, however are stateful and do what is relevant for the situation.
• Presentation Model vs. View: everything that is not display object related can go in the presentation model. The view should bind to properties and call methods on the presentation model, and it should avoid to do things like concatenating properties or filtering lists by itself. The idea is to make the view code as simple as possible, and all the view logic testable.The idea of using presentation models is to fool the view into thinking that the interface that the presentation model presents is the whole application. That way it becomes simple, reusable and it will contain so little logic that it doesn’t even need to be tested.

• The default strategy is to select a class to have its fields persisted in the table of the base class. There is only one table per inheritance hierarchy. In JPA1 this is known as SINGLE_TABLE. Hibernate call this ‘Table per class hierarchy’.

“SINGLE_TABLE” strategy is where the root class has a table and all subclasses are also persisted into that table. This corresponds to JDO2s “new-table” for the root class and “superclass-table” for all subclasses. This has the advantage that retrieval of an object is a single SQL call to a single table. It also has the disadvantage that the single table can have a very large number of columns, and database readability and performance can suffer, and additionally that a discriminator column is required. In many cases, this mapping is a winner in terms of both performance and simplicity. it is the best-performing way to represent polymorphism. Schema evolution is straightforward. There is one major problem: Columns for properties declared by subclasses must be declared to be nullable.

• The next way is to have a table for each class in the inheritance hierarchy, and for each table to only hold columns for the fields of that class. Fields of superclasses are persisted into the table of the superclass. Consequently to get all field values for a subclass object a join is made of all tables of superclasses. In JPA1 this is referred to as JOINED. Hibernate call this  ‘Table per subclass’
  

“JOINED” strategy means that each table in the inheritance hierarchy has its own table and that the table of each class only contains columns for that class. Inherited fields are persisted into the tables of the superclass(es). This corresponds to JDO2s “new-table” (for all classes in the inheritance hierarchy). This has the advantage of being the most normalised data definition. It also has the disadvantage of being slower in performance since multiple tables will need to be accessed to retrieve an object of a sub-type.

• The third way is what Hibernate called “Table per concret class with implicit polymorphism”

This is the simplest solution, you don’t have to do anthing special in Hibernate/JPA to enable polymorphic behaviour. The mapping of  subclasses are straightforward, each in its own entity <class> element, as we  have done alreadyfor classes without a superclass (or persistence interfaces). Hibernate still knows about the superclass because it scans the persistent classes on startup. The main problem with this approach is that it does not support polymorphic associates very well (no foreign key). Polymorphic queries are also problematic. A query against the superclass must be executed as several SQL selects. We recommend this approach only for top level of your class hierarchy where polymorphism isn’t usually required, and when modification of the superclass in the future is unlikely. Also  the java persistence interfaces don’t support full polymorphic queries, only mapped enitityes can be officially part of a Java Persistence query. If you’re relying on this implicit polymophism, you map concrete classes with @Entity, as usual. However you also have to duplicate the properties of the superclass to map them to all concrete class tables. By default, properties of the superclass are ignored and not persistent. You need to annotate the superclass to enable embedding of its properties in the concrete subclass tables (using @MappedSuperclass)

• The fourth way is like JOINED except that each table will also contain columns for all inherited fields. In JPA1 this is referred to as TABLE_PER_CLASS
  

In Hibernate it is called ‘Table per concrete class with unions’. This strategy is like “JOINED” except that in addition to each class having its own table, the table also holds columns for all inherited fields. The first advantage you may notice with this strategy is the shared declaration of superclass (or interface)  properties.  another much more important advantage is the ability to handle polymorphic associations (by using union).

sh configure_insoshi_local.sh <GitHub account name>

I got the following error:
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: failed to push to 'git@github.com:windhood/stage.git'

To solve this error, you need do as following:

$ cd ~/.ssh
$ ssh-add id_rsa
id_rsa is the public key name file you used for your github