Ticket #130 (closed planned_task: obsolete)

Opened 14 years ago

Last modified 13 years ago

PRO_LIB_CORE_TUTORIAL_R1

Reported by: Astea Owned by: peko
Priority: 3 Milestone: M04_PRE4
Component: PRO_LIB_CORE Version: 2.0
Keywords: Cc: gogov
Category: CORE Effort: 3
Importance: 0 Ticket_group:
Estimated Number of Hours: Add Hours to Ticket:
Billable?: Total Hours:
Analysis_owners: gogov, gogov Design_owners:
Imp._owners: gogov, gogov, peko Test_owners:
Analysis_reviewers: boyan, deyan Changelog:
Design_reviewers: meddle Imp._reviewers: pap, kyli
Test_reviewers: Analysis_score: 4.5
Design_score: 3.5 Imp._score: 3.5
Test_score: 0

Description

wiki page: PRO_LIB_CORE_TUTORIAL_R1 - effort: 3d

Change History

comment:1 Changed 14 years ago by gogov

  • Status changed from new to s1a_analysis_started
  • Analysis_score set to 0
  • Test_score set to 0
  • Design_score set to 0
  • Owner changed from Astea to gogov
  • Imp._score set to 0

comment:2 Changed 14 years ago by gogov

  • Status changed from s1a_analysis_started to s1b_analysis_finished

comment:3 Changed 14 years ago by gogov

  • Analysis_owners set to gogov

comment:4 Changed 14 years ago by boyan

  • Status changed from s1b_analysis_finished to s1c_analysis_ok
  • Analysis_score changed from 0 to 4.5

The analysis is really well written and provides sufficient and detailed information.

comment:5 Changed 14 years ago by boyan

  • Analysis_reviewers set to boyan

forgot to fill my name in the reviewers field

comment:6 Changed 13 years ago by gogov

  • Status changed from s1c_analysis_ok to new

comment:7 Changed 13 years ago by gogov

  • Status changed from new to s1a_analysis_started

comment:8 Changed 13 years ago by gogov

  • Status changed from s1a_analysis_started to s1b_analysis_finished

comment:9 Changed 13 years ago by gogov

  • Analysis_owners changed from gogov to gogov, gogov

comment:10 Changed 13 years ago by deyan

  • Status changed from s1b_analysis_finished to s1c_analysis_ok
  • Analysis_reviewers changed from boyan to boyan, deyan

comment:11 Changed 13 years ago by gogov

  • Status changed from s1c_analysis_ok to s2a_design_started

comment:12 Changed 13 years ago by gogov

  • Status changed from s2a_design_started to s2b_design_finished

comment:13 Changed 13 years ago by meddle

  • Status changed from s2b_design_finished to s2c_design_ok
  • Design_score changed from 0 to 3.5
  • Design_reviewers set to meddle
  • Ummm "Let's say we've got lots of object which we're using in our application. These object depends on each other in a sense that: "... lots of object??
  • In the implementation phase you can provide some revisions with your images containing the diagrams for the tutorial. We can merge them to the trunk and fix the links in the tutorial to point to the trunk images.
  • The @Const AutoProperties rarely depend on anything, they are "bottom" properties that can canculate themselves by themselves only once. The greatest example for such an AutoProperty is:
    	@Const
    	public Prop<Link> link() {
    		class link extends AutoProperty<Link> {	
    
    			@Override
    			protected Link compute() {
    				assert getLastValue() == null;
    				return new FrameLink(getChangeManager());
    			}
    		}
    		return getBean().makeProp(link.class);
    	}
    
  • May be you should mention that the calling order of the @Setup methods is not defined.
  • But ProObjects that are in Properties annotated with @Own are not obligated to define a ParentProperty, you should mention that.
  • "It should contain cycles, otherwise we can never initialize this graph.", may be shouldn't?
  • You should describe in more details how the ProLib works... The Registry, the ProListeners and most importantly the AutoTracker. How the AutoProperties update is something that only 2-3 people know.
  • Add a section how to use the eclipse templates for the ProLib.

3.5p (90m)

comment:14 Changed 13 years ago by gogov

  • Status changed from s2c_design_ok to s3a_implementation_started

comment:15 Changed 13 years ago by gogov

  • Status changed from s3a_implementation_started to s3b_implementation_finished

Nothing new, just moving to im_fi

comment:16 Changed 13 years ago by gogov

ok, added some more comments

comment:17 Changed 13 years ago by pap

  • Cc gogov added
  • Status changed from s3b_implementation_finished to s2c_design_ok
  • Imp._score changed from 0 to 2.5
  • Imp._reviewers set to pap
  • The tutorial provided is quite nice and understandable. It is much better than what was before. But there are things that I think should be corrected
  • First a small note that I think the RwListProp should be green and not red
  • I think that it will be nice to mention that ProLib is Sophie independant. So you can use it for any application you like.
  • I find the explanation of the doSet() for AutoProperties wierd and hard to understand. I think this method can be used when for example the AutoProperty computes a complex object of several simpler ones but also can decompose one such object ot its parts. I.e. ImmRect <-> (ImmPoint, ImmSize).
  • The next things is about Meddle and his holy Jesus-like nature. I understand that you like each other very much and don't really mind if you include things like
    • " I also add this one by His Holy Meddleness request"
    • "Gogov 1:0 Meddle" etc

in the ticket comments or even in a tasks wiki page but this tutorial is several bits more important. And eventually this will only confuse readers that know neither Gogov nor meddle.

  • Next are several issues with const auto properties
    • Actually the thing with the AP returning a "new MyObject" is quite important as it is a common case and also people tend to use other pieces of code whre they should use that
    • The first example is also good but it is important to mention that the properties we depend on should also be const AP or final properties
    • It would be nice to mention somehow that the "assert getLastValue() == null;" is not just some convention. It is a must for const APs
    • It may be nice to mention again the difference between const APs and final properties. And it is that APs know how to compute themselves whereas final and value properties do not (they get their values from somewhere aout there).
  • Probably somewhere around here you could mention the use of Resource/Auto properties for synchroniztion purposes. Or maybe in a later part as this is not the most common use of such.
  • I think it is better if you first give examples for a certain property kind usage through the most common case. The reason is in the ValueListProperty example.
  • The example you give about the TrackingProList.filter.transform has one quite bad thing
    • The try/catch(NullPointerException) is a generally bad code example and I beleive such code should not exist in any kind of tutorial about programming (except if it points this is bad).
  • The issue with the @Own annotation on a ProObject without parent() property is something bad as it really was supposed to be as meddle have told you. Maybe you would like to fix it as a part of the task :) Or report it as a bug
  • Also it may be nice to mention that the parent() property of an object may be null if it is not yet attached to a parent object.
  • You haven't mentioned the default value ability of value properties and the fact it should be a constant.
  • The "Bad Code Examples" part is really short but I think that is not such an issue.
  • About the debugging it would be nice to mention log/print instead of just print. This way you will promote logging that eventually is better for these purposes than printing
  • Isn't there any wiki page about the Inspector you can provide a link to ?
  • Fill in custom fields. You are the implementation owner after all :)
  • You have placed the diagrams in some very strange place in the branch. These are documents and not test resources.

comment:18 Changed 13 years ago by gogov

  • Status changed from s2c_design_ok to s3a_implementation_started

comment:19 Changed 13 years ago by gogov

  • Status changed from s3a_implementation_started to s3b_implementation_finished
  • Imp._owners set to gogov

Ok, I'll fix some stuff but, this was meant to be a 3eff task!! I'll fail my current tasks because I think quality is more important, but I want to mention it.

  • First a small note that I think the RwListProp should be green and not red -- agreed
  • I think that it will be nice to mention that ProLib is Sophie independant. So you can use it for any application you like. -- though this was obvious, ok I'll add it as comment.
  • I find the explanation of the doSet() for AutoProperties wierd and hard to understand. I think this method can be used when for example the AutoProperty computes a complex object of several simpler ones but also can decompose one such object ot its parts. I.e. ImmRect <-> (ImmPoint, ImmSize) -- ok, that maybe is another use case, which doesn't cancel the ones I've provided. If you want, I can add it, though then you should elaborate in detail, because I'm not totally sure what do you mean.
  • The next things is about Meddle and his holy Jesus-like nature. I understand that you like each other very much and don't really mind if you include things like

o " I also add this one by His Holy Meddleness request"
o "Gogov 1:0 Meddle" etc

in the ticket comments or even in a tasks wiki page but this tutorial is several bits more important. And eventually this will only confuse readers that know neither Gogov nor meddle. --you integrator people don't have any sense of humor.. Ok, I'll remove these wake-up jokes but there's a danger the reader will fall asleep (:

  • Next are several issues with const auto properties

o Actually the thing with the AP returning a "new MyObject" is quite important as it is a common case and also people tend to use other pieces of code whre they should use that -- I'll emphasize this in the @Own & ParentProperty section because there is the right place.
o The first example is also good but it is important to mention that the properties we depend on should also be const AP or final properties -- ?, I don't agree with that. Please elaborate.
o It would be nice to mention somehow that the "assert getLastValue() == null;" is not just some convention. It is a must for const APs -- point taken, though I think this is too much going in details.
o It may be nice to mention again the difference between const APs and final properties. And it is that APs know how to compute themselves whereas final and value properties do not (they get their values from somewhere aout there). --ok.. will repeat..

  • Probably somewhere around here you could mention the use of Resource/Auto properties for synchroniztion purposes. Or maybe in a later part as this is not the most common use of such. --I've intentionally not put it here because people might think it's so cool and start using it, though as you know, this causes some design problems and I'd like to avoid it as much as possible.
  • I think it is better if you first give examples for a certain property kind usage through the most common case. The reason is in the ValueListProperty example. -- I think this is the most simple case and don't agree the most common should be used instead. I explain things from simple to not-so-simple. But if more people think as you do, I'll change it.
  • The example you give about the TrackingProList.filter.transform has one quite bad thing

o The try/catch(NullPointerException) is a generally bad code example and I beleive such code should not exist in any kind of tutorial about programming (except if it points this is bad). -- point taken.

  • The issue with the @Own annotation on a ProObject without parent() property is something bad as it really was supposed to be as meddle have told you. Maybe you would like to fix it as a part of the task :) Or report it as a bug -- yeah, sure, I'll fix it.
  • Also it may be nice to mention that the parent() property of an object may be null if it is not yet attached to a parent object. -- point taken
  • You haven't mentioned the default value ability of value properties and the fact it should be a constant. -- point taken.
  • The "Bad Code Examples" part is really short but I think that is not such an issue. -- effort 3... give me effort 6 and I'll write 20 bad code practices.
  • About the debugging it would be nice to mention log/print instead of just print. This way you will promote logging that eventually is better for these purposes than printing. --don't fully agree but I'll add a comment.
  • Isn't there any wiki page about the Inspector you can provide a link to ? --sure.
  • Fill in custom fields. You are the implementation owner after all :) -- ok, ok..
  • You have placed the diagrams in some very strange place in the branch. These are documents and not test resources. -- the previous diagrams were there, so I put them there. I don't mind moving them though we should agree on a place.

comment:20 follow-up: ↓ 22 Changed 13 years ago by gogov

I think this bureaucracy is killing our performance.. We shouldn't write so much bullcrap here but should just talk and fix directly.. For the time you wrote your comments and I wrote mine, we could've finished all of this and more.

comment:21 Changed 13 years ago by gogov

  • Imp._owners changed from gogov to gogov, gogov

comment:22 in reply to: ↑ 20 Changed 13 years ago by pap

Replying to gogov:

I think this bureaucracy is killing our performance.. We shouldn't write so much bullcrap here but should just talk and fix directly.. For the time you wrote your comments and I wrote mine, we could've finished all of this and more.

So it may be, but actually I lost most of the time reading the tutorial and writing the bullcrap actually helped me concentrate my thoughts and write something sensible. If I told you that inplace it would be some kind of humming. Probably its my personal problem that I am not inteligent enough to get things right and well and respond in seconds. Also you are not oblidged to write your comments. Actually you could've talked with me on the points you say need elaboration. Also if I had nothing to say we wouldn't waste any time but probably that wouldn't help us improve ourselves or the product. And last but not least there should be reasons for failing a task - that's my job and I have to document somehow why I wasted so much time. Again I am slow and certainly not as good as meddle or you.


comment:23 Changed 13 years ago by gogov

  • Status changed from s3b_implementation_finished to s2c_design_ok

Ok, sorry about the "bullcrap" term used. Actually I meant mostly the stuff I wrote because it was replaying to your stuff which happened because you weren't in the office.. I wrote it to respond and keep track of what's done according to your detailed reply..
And as you see, I agree with most of the stuff you proposed..
So I guess I'm also good enough to finish this task and I'll hand it to Peko, who has to work on core with me this week, so I hope I won't cause more trouble with this task..
Again, sorry about using "bullcrap".. It's like Meddle's "shit".. It's just a way to say stuff..

I'll fail my im myself.

comment:24 Changed 13 years ago by gogov

  • Owner changed from gogov to peko

comment:25 Changed 13 years ago by peko

I think that the tutorial is quite full, descriptive and doesn't lack anything. I do like the tone with which it is written although it does not seem so formal this way. In addition some of the things mentioned are not added. As I read the tutotial, I think what should be changed is:

  • More bad examples should be added indeed. This is also stated in the todo section.
  • Code templates for properties should also be added. They should be put in two separated files as proposed by pap - one for single values and one for lists.
  • Phrases like "(:", "stuff", "junk" and "His Holy" will be removed not because they are inconsistent but for formality issues.

comment:26 Changed 13 years ago by peko

  • Status changed from s2c_design_ok to s3a_implementation_started
  • Imp._owners changed from gogov, gogov to gogov, gogov, peko

comment:27 Changed 13 years ago by peko

  • Status changed from s3a_implementation_started to s3b_implementation_finished

comment:28 Changed 13 years ago by peko

  • A uml diagram added, as requested...

comment:29 Changed 13 years ago by kyli

  • Status changed from s3b_implementation_finished to s3c_implementation_ok
  • Imp._score changed from 2.5 to 3.5
  • Imp._reviewers changed from pap to pap, kyli

Spending so much time in arguing is sick.

comment:30 Changed 13 years ago by deyan

  • Status changed from s3c_implementation_ok to closed
  • Resolution set to obsolete

Batch update from file query-obsoleted.csv

Note: See TracTickets for help on using tickets.