Peer Advertising College - introducing
Status: Beta
Brought to you by:
mark-jj
Menu
▾
▴
#20 Peer Advertising College - introducing
Possible conceptual breakthrough that's been haunting me for the past 2 days and nights...
I have just begun typing up and formalizing this new idea that I call Peer Advertising College. The first version of the document is attached: PeerAdvertisingCollege-V1.pdf. However, please do make sure that you check for the latest revisions of the document. I will be editing and updating it with additional analysis and more detailed requirements.
I am assigning this task to Adam directly, because I believe that it needs to be done as a relatively high priority task. (At least, it needs to be worked with little delay.)
Adam, for now, it is not yet ready for your time estimate.
Peer Advertising College - V1, my very first look at the possible Use Cases. Need to elaborate further.
Logged In: YES
user_id=1691791
Originator: YES
File Added: PeerAdvertisingCollege-V1.pdf
Logged In: YES
user_id=1691791
Originator: YES
Adam, I have just beguan working on the PAC use cases using StarUML program. I know that there are so many UML tools on the market, but I really like this one (StarUML), so please download it (http://staruml.sourceforge.net/en/). It is a very simple tool to use. When you open the attached UML file, you will see there that PAC is a stand-alone subsystem. This is in fact the beginning of GreatCOW re-architecting that I am discussing in [ 1671606 ] "Review high-level system architecture and modularity".
I also opened up to you 3 UC specifications on http://docs.google.com/a/greatcow.com/. These UC's are only beginning, I will be elaborating further. You have been invited with your gmail address so you can read the details there. (Come to think about it, I should open it to everybody on GreatCOW. Hmm..... I wonder if I can do that.)
StarUML file which will show you the updated use case diagram.
Logged In: YES
user_id=1691791
Originator: YES
File Added: GreatCOW-Modularization.uml
Logged In: YES
user_id=1691791
Originator: YES
I am attaching the Use Cases which are very close to the final and complete definition of the business logic for this feature. See the file: PAC Use Cases.zip. The zip folder contains the use case diagram and 5 separate files describing the flow of events for each one. I think to begin the PAC subsystem, we can keep it rather simple.
I think I would ask you to start reading these documents on Monday morning and start estimating. (As usual, estimate your time for reading and analyzing first.) Also, when I'm back, we should discuss and clarify a few yellow highlighted issues.
This particular task, I would like to do differently. We should work a little bit more formally, especially since we are also planning to modularize our application into subsystems. PAC, as we decided, is its own subsystem, and should follow all interfacing rules that we established. To work formally, let's first find and name new classes. Then, let's do some interaction diagrams (sequence diagrams), and then let's work on interactions between classes (class diagrams).
I have not yet started working on the presentation (user interface) for this feature. But I will, soon. So at this point, we will be only working on and estimating the business layer.
Logged In: YES
user_id=1691791
Originator: YES
File Added: PAC-Use-Cases.zip
Second version of the PAC Use Cases. Disregard anything that was done before.
Logged In: YES
user_id=1691791
Originator: YES
File Added: PAC-Use-Cases-v2.zip
Logged In: YES
user_id=1691791
Originator: YES
I am attaching the version 2 of use cases which relates to our review we have had early today. All the important changes in version 2 have been typed in bold dark red color. There are still a few issues that we need to talk about. I highlighted them in light yellow color.
I was not able today to review your UML diagrams. I will do it tomorrow morning. In the meantime, please read the red changes and also the yellow highlights.
Remember that all the old specifications and docs for this task are no longer valid after this latest submission.
Logged In: YES
user_id=1691791
Originator: YES
File Added: PAC-Use-Cases-v3.zip
Third version of the PAC Use Cases. Disregard all previous attachments.
Logged In: YES
user_id=1691791
Originator: YES
The third version of PAC Use Cases / Flow of Events documents changes following our most recent review and discussion. Changes are shown in dark bold red color.
Disregard any and all previously added files.
Logged In: YES
user_id=1691791
Originator: YES
Before you start your day on Wednesday (3/14/07), you should get the latest DesignAndArchitecture.uml StarUML file from CVS. I've done some changes this evening and committed them back.
I thought more about dependencies between subsystems. Conceptually, it can be cleaned up even further. I believe that we can remove dependencies if there are 2 central watchdog (or gateway) subsystems: Authentication In/Out (authi) and Member Account (maccu). If authi and maccu hold all the necessary relevant information and notify the respective customers (by "customers", I mean subsystems) of any important events, then no other dependencies will be needed. If we can design and implement this architecture, then we would expose only minimum knowledge of one subsystem to another subsystem. We could accomplish very clear modular design with absolutely minimum necessary dependencies. It is challenging, but I think it is possible. It could be a great design. We just need to shift our mindsets. Exposure is bad. Hiding is good. That's good architecture.
I was finally able to figure out XWiki (after learning Velocity, Groovy and XWiki API), so I know now what to do and how to use their PanelWizard tool. With XWiki, the biggest problem (common to OS projects) is the desperate lack of documentation. Once you figure out (on your own) how to do the stuff you need to do, then you are amazed how simple it is... But you are on your own discovering all that magic. OS hate to write documentation. They love to write code :).
Logged In: YES
user_id=1691791
Originator: YES
I am beginning to think (out loud) if the IoC pattern, which we had so successfully implemented to separate Business from View in the current GreatCOW -- could be also applied here, with our new proposed architecture. After all, the main purpose of "dependency injection" is exactly what we want to accomplish: to decouple objects. Let's think about it some more.
Logged In: YES
user_id=1691791
Originator: YES
Here's a good article to read: http://martinfowler.com/articles/injection.html
Logged In: YES
user_id=1717523
Originator: NO
Hello,
why we need site admin module?, what does it do?
In case of PAC, PacScheduler is part of PAC but methods should be performed by admin (that is way I was thinking it should go to Site Admin).
Checking if logged in member is admin or not is done by Authentication In/Out and still has nothing to do with Site Admin (checking if user has admin priviliges may be functionality of Site Admin but it is ok, we have connection from Authentication to Site Admin).
So PacScheduler is in PAC module and uses only its connection to the Authi.
What we do with view layer then?
In my idea, the view layer for Site Admin is only the left navigation on the admin panel, layout and styles for pages on admin panel, nothing more.
Ok, may be we will find some administartive tasks which are not assigned to any other module and they will go to Site Admin, but for now there are no such tasks...
Layout and styles is not a problem, I guess.
Question is how do we build left navigation?
And here is place for dependency injection or some kind of plugins, but without any dependency. Site Admin asks Authentication In/Out for pages which requires admin priviliges and based on this it builds navigation.
I assume we have central configuration for authentication, where we describe every path on the server by name and requried privileges (and probably something more, like it is now - i.e. additional rules, checking if proper protocol is used).
In general, for every action in every module we (owner of such module) can decide that it requires admin rights. And this will be enough to make it accessible from admin panel eventhough it is not a part of Site Admin and there is no connection between two of them.
From the bunch of such links Site Admin will build left navigation and that's all.
Cheers,
Adam
Logged In: YES
user_id=1691791
Originator: YES
Complete set of requirements for the PAC have now been posted on our wiki at:
http://www.greatcow.org/xwiki/bin/view/Requirements/
(scroll to the bottom of the page for the latest stuff.)
Logged In: YES
user_id=1717523
Originator: NO
Hi,
I have tried some movie conversions and it seems to be easy to convert various movie formats into flv. I tried mencoder (http://www.mplayerhg.hu) and ffmpeg (http://ffmpeg.org). Second one seems to be faster. I tried with mov and avi, works fine.
Also it is easy to take snapshot and create thumbnail. Following two commands do all we need (more about them found here: http://luar.com.hk/blog/?p=670\)
ffmpeg -i input.avi -ar 22050 -ab 32 -f flv -s 320x240 video.flv
ffmpeg -i video.flv -an -ss 00:01:30 -t 00:00:01 -r 1 -y -s 320x240 video%d.jpg
I think we can find some open source flv player, I have already found two:
http://www.jeroenwijering.com/?item=Flash_Video_Player (but not free for commercial use)
http://flowplayer.sourceforge.net/index.html (open source, not tested yet)
Cheers,
Adam
Logged In: YES
user_id=1717523
Originator: NO
Hi,
below, there are my estimate for implementation of PAC.
UC1
create/edit PAC event:
view (actions, forms, tiles controllers, JSPs) 12h
bus (model, finders, creator, thumbs creation) 12h
delete PAC event
(action, tiles controller, JSP) 6 h
UC2
business 8h
view (tiles controller, JSP, filter) 8h
UC3
business (file conversion, thumbs creation, model) 10h
view (GWT, action) 10h
UC4
business 4h
view (GWT) 7h
UC5
business 6h
view (GWT) 7h
TOTAL
90h
Cheers,
Adam