Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> Harbs:
 Feel free to do what you want to SonarQube now, but don’t make any changes 
 based on the reports.

I think you would agree that it doesn’t matter what tool you use to find issues 
and a blanket statement like that is like saying you must use a particular IDE 
to edit your code. Sonar cube is a tool that can find bugs and issue in code - 
why not use it to do that?

>>> You are free to review any commits and I make and veto any them on their 
>>> technical merits. You are not free to revert any changes without discussion 
>>> or a veto. Everyone is free to scratch their own itch here and the tools 
>>> you use to find any issues should be irrelevant.

Harbs has recently on several occasions has reverted my commits (usually under 
another check in message) without discussion or a valid veto. I was just 
reminding him that's not the way to do things.

>> Here we have the catch. Apache projects also operate by consensus and as 
>> volunteers. If one individual works against consensus and also takes peoples 
>> time away then problems arise with the community dynamic. RTC has been 
>> suggested precisely because it is one way to solve this issue. There are 
>> other ways.
>> 
>> Consensus is very important please work on that aspect of this discussion.

In this case consensus may not be required on exactly how Sonar Cube is 
configured given most of the rules are minor violations then you can choose to 
ignore them if you please. What would be useful to to have consensus around the 
critical and blocking rules and as you say this may take a little time.

> Think about “other ways”. The project does not appear interested in following 
> RTC.

Which I am. For instance it looks like there wasn’t full consensus on using 
hard coded string vs constants for event names so I suggested having a vote on 
it.

Thanks,
Justin

Re: [FlexJS] technical debt

[Dave Fisher]

Justin -

You seem to pick the part of the conversation that you are interested in and 
edit out the rest of the context. It makes it difficult to have a conversation 
about the best way to move forward in this project.

Harbs:
>>> Feel free to do what you want to SonarQube now, but don’t make any changes 
>>> based on the reports.
>> 

Justin:
>> You are free to review any commits and I make and veto any them on their 
>> technical merits. You are not free to revert any changes without discussion 
>> or a veto. Everyone is free to scratch their own itch here and the tools you 
>> use to find any issues should be irrelevant.

Dave:
> Here we have the catch. Apache projects also operate by consensus and as 
> volunteers. If one individual works against consensus and also takes peoples 
> time away then problems arise with the community dynamic. RTC has been 
> suggested precisely because it is one way to solve this issue. There are 
> other ways.
> 
> Consensus is very important please work on that aspect of this discussion.

My whole statement worked together and I would appreciate it if you would think 
about this in its whole. Think about other times when you and Harbs have had 
this dynamic.

Think about “other ways”. The project does not appear interested in following 
RTC.

Ahh there went 10 minutes to try to explain it again. (Sigh)

Regards,
Dave


> 
> Thank you,
> Dave
> 



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> The exercise with the Wiki was essentially for you to present a proposed set 
> of Sonar rules. You did this, thank you.
> 
> It was not intended by me as [LAZY CONSENSUS]. Clearly there is healthy 
> disagreement and consensus is not yet achieved.

Nor is it intended to be. I created a new rule set so people can see the 
results of what is documented on that wiki page. People are welcome to provide 
further feedback.

> You can see that a lot ion Flex Developers do not agree. Which ones is a good 
> question, but keep in mind this will take time, and should not be forced. I 
> think that the burden should be a discussion of a specific case.

Which is what we're doing the the cloneEvent method.

> RTC has been suggested precisely because it is one way to solve this issue.

Which I would be in favour of.  

Thanks,
Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> Also, in FlexJS, we want very few if any custom events to bubble.
> Bubbling was overused in regular Flex and was, IMO, a bad practice because
> it breaks encapsulation.

Events provide encapsulation by allowing application to respond to changes 
outside of the object. IMO it’s also a good practice because it encourages 
loose coupling.

If we shouldn't be using bubbling in FlexJS why does just about event Event (30 
odd) have a bubbling attribute and more than 3/4 have a cloneEvent method? 
Either we shod be fixing the broken one or removing the methods on the existing 
event classes - which is it?

Thanks,
Justin

Re: [FlexJS] technical debt

[Dave Fisher]

Hi Justin,

The exercise with the Wiki was essentially for you to present a proposed set of 
Sonar rules. You did this, thank you.

It was not intended by me as [LAZY CONSENSUS]. Clearly there is healthy 
disagreement and consensus is not yet achieved.

> On Jul 17, 2017, at 11:22 PM, Justin Mclean  wrote:



> 
> Would you not agree that some (if not all) of these need fixing?
> 
>> A lot of the rules fly in the face to current convention in the SDK.
> 
> Which ones in particular?

You can see that a lot ion Flex Developers do not agree. Which ones is a good 
question, but keep in mind this will take time, and should not be forced. I 
think that the burden should be a discussion of a specific case.

> 
>> Some (such as returning from a constructor) are actually enforced by the 
>> compiler so the rule is not needed.
> 
> If that the case there no harm in having them on as there should be no 
> violations right?

The harm can come as seen bellow.

> 
>> Feel free to do what you want to SonarQube now, but don’t make any changes 
>> based on the reports.
> 
> You are free to review any commits and I make and veto any them on their 
> technical merits. You are not free to revert any changes without discussion 
> or a veto. Everyone is free to scratch their own itch here and the tools you 
> use to find any issues should be irrelevant.


Here we have the catch. Apache projects also operate by consensus and as 
volunteers. If one individual works against consensus and also takes peoples 
time away then problems arise with the community dynamic. RTC has been 
suggested precisely because it is one way to solve this issue. There are other 
ways.

Consensus is very important please work on that aspect of this discussion.

Thank you,
Dave



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Josh Tynjala]

Additionally, the cloning results in extra objects that need to be garbage
collected, which can hurt performance and make effects/animations look bad.
Good call on avoiding it!

- Josh

On Tue, Jul 18, 2017 at 8:23 AM, Alex Harui 
wrote:

> +1 to what Harbs said.
>
> Also, in FlexJS, we want very few if any custom events to bubble.
> Bubbling was overused in regular Flex and was, IMO, a bad practice because
> it breaks encapsulation.
>
> Bubbling was intended to allow an object in the DOM to monitor inputs to
> its children without having to attach listeners to the entire tree.  It
> was not meant as a way for a component to shout to the world "Hey, I just
> changed a property, does anybody care?"
>
> -Alex
>
> On 7/17/17, 11:05 PM, "Harbs"  wrote:
>
> >event.clone() is wrong for FlexJS. It’s event.cloneEvent()
> >
> >There was other feedback on the dev list. That seemed to have been
> >ignored.
> >
> >A lot of the rules fly in the face to current convention in the SDK. Some
> >(such as returning from a constructor) are actually enforced by the
> >compiler so the rule is not needed. I don’t have time right now to get
> >involved in a long protracted discussion, but please don’t take the lack
> >of input as consensus.
> >
> >Feel free to do what you want to SonarQube now, but don’t make any
> >changes based on the reports. If anyone else takes an interest in it,
> >please expect some rules to be changed.
> >
> >Thanks,
> >Harbs
> >
> >> On Jul 18, 2017, at 8:50 AM, Justin Mclean 
> >>wrote:
> >>
> >> Hi,
> >>
> >> So more than a week has gone by and I’ve received little feedback on
> >>[1]. Given that I’ll gone ahead and implement the rules as discussed in
> >>the document so people can see the changes.
> >>
> >> The new results are up:
> >> - First off the header rules is overly strict and expects a copyright
> >>line not just a header. ASF policy to not to have copyright lines so
> >>this is a false positive. I’ll disable the rule. We have other means to
> >>check headers. This will be fixed in the next run.
> >> - The ASDocs rule is picking a lot of public methods and properties
> >>that don’t have ASDocs. I think we should keep this to remind us at some
> >>point it needs to be fixed / people can fix as they make edits.
> >> - Is easier to see if issues that do need to be fixed. For instance I
> >>can see that there are a couple of event.clone issues that are likely
> >>bugs.
> >>
> >> Thanks,
> >> Justin
> >>
> >> 1.
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fcwiki.ap
> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FSonar%
> 2BCube%2BFlex%2BRules
> >>=02%7C01%7C%7C9be74a7882374975005208d4cda30749%
> 7Cfa7b1b5a7b34438794aed2c1
> >>78decee1%7C0%7C0%7C636359547464506542=
> cPs4sqimu5YFG%2B08ymZNtb9HMWC
> >>WFGixhtyGrP0burM%3D=0
> >> https%3A%2F%2Fcwiki.a
> >>pache.org%2Fconfluence%2Fdisplay%2FFLEX%2FSonar%
> 2BCube%2BFlex%2BRules
> >>a=02%7C01%7C%7C9be74a7882374975005208d4cda3
> 0749%7Cfa7b1b5a7b34438794aed2c
> >>178decee1%7C0%7C0%7C636359547464506542=
> cPs4sqimu5YFG%2B08ymZNtb9HMW
> >>CWFGixhtyGrP0burM%3D=0>
> >
>
>

Re: [FlexJS] technical debt

[Alex Harui]

+1 to what Harbs said.

Also, in FlexJS, we want very few if any custom events to bubble.
Bubbling was overused in regular Flex and was, IMO, a bad practice because
it breaks encapsulation.

Bubbling was intended to allow an object in the DOM to monitor inputs to
its children without having to attach listeners to the entire tree.  It
was not meant as a way for a component to shout to the world "Hey, I just
changed a property, does anybody care?"

-Alex

On 7/17/17, 11:05 PM, "Harbs"  wrote:

>event.clone() is wrong for FlexJS. It’s event.cloneEvent()
>
>There was other feedback on the dev list. That seemed to have been
>ignored.
>
>A lot of the rules fly in the face to current convention in the SDK. Some
>(such as returning from a constructor) are actually enforced by the
>compiler so the rule is not needed. I don’t have time right now to get
>involved in a long protracted discussion, but please don’t take the lack
>of input as consensus.
>
>Feel free to do what you want to SonarQube now, but don’t make any
>changes based on the reports. If anyone else takes an interest in it,
>please expect some rules to be changed.
>
>Thanks,
>Harbs
>
>> On Jul 18, 2017, at 8:50 AM, Justin Mclean 
>>wrote:
>> 
>> Hi,
>> 
>> So more than a week has gone by and I’ve received little feedback on
>>[1]. Given that I’ll gone ahead and implement the rules as discussed in
>>the document so people can see the changes.
>> 
>> The new results are up:
>> - First off the header rules is overly strict and expects a copyright
>>line not just a header. ASF policy to not to have copyright lines so
>>this is a false positive. I’ll disable the rule. We have other means to
>>check headers. This will be fixed in the next run.
>> - The ASDocs rule is picking a lot of public methods and properties
>>that don’t have ASDocs. I think we should keep this to remind us at some
>>point it needs to be fixed / people can fix as they make edits.
>> - Is easier to see if issues that do need to be fixed. For instance I
>>can see that there are a couple of event.clone issues that are likely
>>bugs.
>> 
>> Thanks,
>> Justin
>> 
>> 1.  
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FSonar%2BCube%2BFlex%2BRules
>>=02%7C01%7C%7C9be74a7882374975005208d4cda30749%7Cfa7b1b5a7b34438794aed2c1
>>78decee1%7C0%7C0%7C636359547464506542=cPs4sqimu5YFG%2B08ymZNtb9HMWC
>>WFGixhtyGrP0burM%3D=0
>>>pache.org%2Fconfluence%2Fdisplay%2FFLEX%2FSonar%2BCube%2BFlex%2BRules
>>a=02%7C01%7C%7C9be74a7882374975005208d4cda30749%7Cfa7b1b5a7b34438794aed2c
>>178decee1%7C0%7C0%7C636359547464506542=cPs4sqimu5YFG%2B08ymZNtb9HMW
>>CWFGixhtyGrP0burM%3D=0>
>

Re: [FlexJS] technical debt

[Harbs]

Sure. But for which events? You seem to have missed my point.

> On Jul 18, 2017, at 10:35 AM, Justin Mclean  wrote:
> 
>> How often is clone really used?
> 
> I’ve used it in just about every single application I've ever written in Flex 
> and I assume most applications will need it.

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I’m actually not convinced that we should enforce use of cloneEvent on all 
> events.

Again in the wiki doc I did put that it may not be required in every case.

If you have bubbles as a parameter it would be reasonable to assume that a 
cloneEvent method is needed, where bubble isn’t a parameter the intent is 
unclear but it’s probably the case you don’t want events to bubble. 6 out of 8 
issues of those have bubbles as a parameter. While the intent in not entirely 
clear in those other 2 cases it may be that they don’t need cloneEvent method.

> How often is clone really used?

I’ve used it in just about every single application I've ever written in Flex 
and I assume most applications will need it.

Thanks,
Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> How are you going to get rid of that rule if we are using different name of
> method in FlexJS ? Rule can be changed itself ?

Rule can be changed and you can create your own rules.

Given this isn't going to come up often (new events are not added that 
frequently) and it easy to see compliance. I’m not sure it's worth the effort 
of creating a new rule.

Thanks,
Justin

Re: [FlexJS] technical debt

[Harbs]

I’m actually not convinced that we should enforce use of cloneEvent on all 
events.

How often is clone really used? I just checked my app and with the exception of 
ValueEvent and composition events, every use of cloneEvent was my own events.

If cloneEvent is not used, it’s code being carried around for no reason.

Thanks,
Harbs

> On Jul 18, 2017, at 9:09 AM, piotrz <piotrzarzyck...@gmail.com> wrote:
> 
> Hi Justin,
> 
> Do you mean by this one 
> 
> "It looks to me that FielEventError, FileEvent, ContextMenuEvent and Focus
> event are missing close methods and probably require them" 
> 
> that those events are missing their own cloneEvent ? 
> 
> Thanks,
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63382.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[piotrz]

Just didn't understand you. Thanks.

How are you going to get rid of that rule if we are using different name of
method in FlexJS ? Rule can be changed itself ?

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63385.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> "It looks to me that FielEventError, FileEvent, ContextMenuEvent and Focus
> event are missing close methods and probably require them" 
> 
> that those events are missing their own cloneEvent ? 

Yes see [1]

Thanks,
Justin

1. 
https://builds.apache.org/analysis/component_issues?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#resolved=false|types=BUG

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I think it was reasonable to switch off rule [1]. That's something which we
> shouldn't be forced to do by the sonar.

Sonar is not forcing anyone to do anything. You’ll note at the top of the 
document I put:

Rule violations:
• that are critical or blocker generally indicate bugs and should be 
fixed as soon possible.
• that are major may point to areas where issues can occur and care 
should be taken. You may want to fix these.
• that are minor can be generally ignored but you may want to comply 
with them when writing new code.

So only critical / blocker issue are things you need to look into. That rule 
isn’t a critical or blocking issue.

Thanks,
Justin

Re: [FlexJS] technical debt

[piotrz]

Hi Justin,

Do you mean by this one 

"It looks to me that FielEventError, FileEvent, ContextMenuEvent and Focus
event are missing close methods and probably require them" 

that those events are missing their own cloneEvent ? 

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63382.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> event.clone() is wrong for FlexJS. It’s event.cloneEvent()

Which if you actually looked none of those 8 examples include a cloneEvent 
method either.

It looks to me that FielEventError, FileEvent, ContextMenuEvent and Focus event 
are missing close methods and probably require them. TodoListEvent should also 
probably have one. Intent wise it not clear if ProductFilterEvent (both of 
them) need it but I'd say this code in ProductListEvent certainly needs one:

   //making the default bubbles behavior of the event to true since we want
   //it to bubble out of the ProductListItem and beyond
   public function ProductListEvent(type:String, bubbles:Boolean=true, 
cancelable:Boolean=false)
   {
   super(type, bubbles, cancelable);
   }

Note the comment, the default of bubbles to true but no cloneEvent method.

Would you not agree that some (if not all) of these need fixing?

> A lot of the rules fly in the face to current convention in the SDK.

Which ones in particular?

> Some (such as returning from a constructor) are actually enforced by the 
> compiler so the rule is not needed.

If that the case there no harm in having them on as there should be no 
violations right?

> Feel free to do what you want to SonarQube now, but don’t make any changes 
> based on the reports.

You are free to review any commits and I make and veto any them on their 
technical merits. You are not free to revert any changes without discussion or 
a veto. Everyone is free to scratch their own itch here and the tools you use 
to find any issues should be irrelevant.

Thanks,
Justin

Re: [FlexJS] technical debt

[piotrz]

Hi,

I think it was reasonable to switch off rule [1]. That's something which we
shouldn't be forced to do by the sonar.

[1] https://builds.apache.org/analysis/coding_rules#rule_key=flex%3AS1440

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63376.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Harbs]

event.clone() is wrong for FlexJS. It’s event.cloneEvent()

There was other feedback on the dev list. That seemed to have been ignored.

A lot of the rules fly in the face to current convention in the SDK. Some (such 
as returning from a constructor) are actually enforced by the compiler so the 
rule is not needed. I don’t have time right now to get involved in a long 
protracted discussion, but please don’t take the lack of input as consensus.

Feel free to do what you want to SonarQube now, but don’t make any changes 
based on the reports. If anyone else takes an interest in it, please expect 
some rules to be changed.

Thanks,
Harbs

> On Jul 18, 2017, at 8:50 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> So more than a week has gone by and I’ve received little feedback on [1]. 
> Given that I’ll gone ahead and implement the rules as discussed in the 
> document so people can see the changes.
> 
> The new results are up:
> - First off the header rules is overly strict and expects a copyright line 
> not just a header. ASF policy to not to have copyright lines so this is a 
> false positive. I’ll disable the rule. We have other means to check headers. 
> This will be fixed in the next run.
> - The ASDocs rule is picking a lot of public methods and properties that 
> don’t have ASDocs. I think we should keep this to remind us at some point it 
> needs to be fixed / people can fix as they make edits.
> - Is easier to see if issues that do need to be fixed. For instance I can see 
> that there are a couple of event.clone issues that are likely bugs.
> 
> Thanks,
> Justin
> 
> 1.  https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules 
> 

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

So more than a week has gone by and I’ve received little feedback on [1]. Given 
that I’ll gone ahead and implement the rules as discussed in the document so 
people can see the changes.

The new results are up:
- First off the header rules is overly strict and expects a copyright line not 
just a header. ASF policy to not to have copyright lines so this is a false 
positive. I’ll disable the rule. We have other means to check headers. This 
will be fixed in the next run.
- The ASDocs rule is picking a lot of public methods and properties that don’t 
have ASDocs. I think we should keep this to remind us at some point it needs to 
be fixed / people can fix as they make edits.
- Is easier to see if issues that do need to be fixed. For instance I can see 
that there are a couple of event.clone issues that are likely bugs.

Thanks,
Justin

1.  https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules 

Re: [FlexJS] technical debt

[Harbs]

How can you use filtering to change what the dashboard shows?

> On Jul 10, 2017, at 2:02 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I was trying to set up an alternate set because it’s easier to have two sets 
>> to compare rather than having long drawn-out discussion.
> 
> As opposed to using the filtering that exists in the web interface? That 
> seems an easier way to do to comparisons but I guess sit depends on your 
> exact aims.
> 
>> I don’t think there’s any harm in having two sets to compare. I tried 
>> playing with my set using inheritance, but I just messed it up.
> 
> You may be best to set up another project with an alternative quality profile 
> set rather than change the existing project but again it depends on what you 
> are trying to do.
> 
> Thanks,
> Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I was trying to set up an alternate set because it’s easier to have two sets 
> to compare rather than having long drawn-out discussion.

As opposed to using the filtering that exists in the web interface? That seems 
an easier way to do to comparisons but I guess sit depends on your exact aims.

> I don’t think there’s any harm in having two sets to compare. I tried playing 
> with my set using inheritance, but I just messed it up.

You may be best to set up another project with an alternative quality profile 
set rather than change the existing project but again it depends on what you 
are trying to do.

Thanks,
Justin

Re: [FlexJS] technical debt

[Harbs]

That’s a good idea, and I will probably do so next time I’m inclined to spend 
time on this.

> On Jul 10, 2017, at 10:43 AM, Justin Mclean  wrote:
> 
> If you are trying things out rather than experimenting on the live server you 
> can run Sonar Cube locally.

Re: [FlexJS] technical debt

[Harbs]

I was trying to set up an alternate set because it’s easier to have two sets to 
compare rather than having long drawn-out discussion.

I don’t think there’s any harm in having two sets to compare. I tried playing 
with my set using inheritance, but I just messed it up.

I really don’t have the time for this now so I’m going to just leave this alone 
for the time being.

Thanks,
Harbs

> On Jul 10, 2017, at 10:43 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> I have permissions to edit profiles, but I don’t seem to have permissions to 
>> assign profiles.
> 
> You do have permissions you’re just doing it in the wrong place. Also I won’t 
> recommend hard coding a set of rules as you have done. It’s better to define 
> the rule set as a delta of the default so your quality profile is updated 
> when rules are updated.
> 
> If you are trying things out rather than experimenting on the live server you 
> can run Sonar Cube locally. It’s extremely easy to run locally and you don’t 
> need to set up a DB if you just want to try it out. It’s as simple are 
> running a start script and then running the Sonar Cube flex scanner. You may 
> have to edit a config to change the port number depending on what you have 
> running on you dev box.
> 
> As discussed please inform the list what changes you are going to make before 
> you make them please. Some feedback on the wiki documentation would also be 
> helpful.
> 
> Thanks,
> Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I have permissions to edit profiles, but I don’t seem to have permissions to 
> assign profiles.

You do have permissions you’re just doing it in the wrong place. Also I won’t 
recommend hard coding a set of rules as you have done. It’s better to define 
the rule set as a delta of the default so your quality profile is updated when 
rules are updated.

If you are trying things out rather than experimenting on the live server you 
can run Sonar Cube locally. It’s extremely easy to run locally and you don’t 
need to set up a DB if you just want to try it out. It’s as simple are running 
a start script and then running the Sonar Cube flex scanner. You may have to 
edit a config to change the port number depending on what you have running on 
you dev box.

As discussed please inform the list what changes you are going to make before 
you make them please. Some feedback on the wiki documentation would also be 
helpful.

Thanks,
Justin

Re: [FlexJS] technical debt

[Harbs]

I have permissions to edit profiles, but I don’t seem to have permissions to 
assign profiles.

I created another profile and I’m waiting for INFRA to look at my permissions 
again.

> On Jul 10, 2017, at 9:28 AM, piotrz <piotrzarzyck...@gmail.com> wrote:
> 
> Hi Justin,
> 
> Thank you.
> 
> Harbs,
> 
> Can you take a look whether you can edit it ? It seems that I don't have
> some permission to change that profile.
> 
> Thanks,
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63016.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[piotrz]

Hi Justin,

Thank you.

Harbs,

Can you take a look whether you can edit it ? It seems that I don't have
some permission to change that profile.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p63016.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

I reset the default rules back to the way they were and created a "FlexJS 
Framework” quality profile we can make the changes there.

Thanks,
Justin

Re: [FlexJS] technical debt

[Josh Tynjala]

While I personally use === and !==, the vast, VAST majority of ActionScript
developers do not. I think it makes sense to turn that off for the default
profile. It's not considered best practice in the ActionScript community.
Probably because we encounter undefined significantly less than JS
developers do.

- Josh


On Jul 9, 2017 1:13 AM, "Justin Mclean"  wrote:

Hi,

> I made two changes on Friday.

Can I ask why you didn’t email the list saying you had done this and what
the purpose of disabling those rules were? Or disabling rules when I
suggested that you should make a custom profile instead?

> It’s important to note that these changes were only to the “Flex”
language. Considering that we’re the only project using this language at
all, it does not effect anyone else.

How did you know we are the only project using that profile when you
disabled those rules? Several other projects do use Actionscript and at
least one I know has used Flex. What do you think would of happened if you
had changed the Java default profile which we also use?

> Additionally, as best as I can tell, the language was first defined in
the end of December.

Sonar cube has been running against the FlexJS framework and compiler for
more than a year (probably two). In December Apache updated to a new
version of Sonar Cube. Going way back it was first suggested to be set up
in 2013 and Chris had it running externally for a bit before it was set it
up at Apache. There have been several discussions about it on thd list over
that time and no one has suggested disabling rules that I can recall.

> Considering we “own” the language, it seems reasonable that we should
define sane defaults in case any other project DOES use the language.

I have Sonar Cube running locally and use it to track TD on a current
project and I don’t disable those rules, in fact I turn on several more.

> "===" and "!==" should be used instead of "==" and "!=“ is simply
incorrect for ActionScript. I flies in the face of accepted coding
practices for the language, and should be removed completely.

Which is an opinion not held by all JavaScript and ActionScript developers,
in fact a large number of them consider it harmful to use “==“ and “!=". I
use “===“ and “!===“ most of the time in my AS code and I know (for
instance) Josh does as well. It may not made sense to use it everywhere in
the Flex JS SDK, but there is a fair amount of use off === and !== in the
existing FlexJS SDK (around a 1000 occurrances from a quick search) so it
seems that it’s not incorrect to use it even in our own framework.

Rather than turning off the rule I have suggested in my wiki document to
make it a minor issue. You are free to ignore any minor issues you want.
Sonar Cube also has good filtering tools to help you do that.

> "public static" fields should be constant is not something that Flex ever
enforced. I don’t really see the value for this rule, but I could go either
way.

Others may have differing options. It would would be best to discuss it on
list/wiki first before turning any rules off.

> Feel free to revert my changes, but the discussion should be about
defaults for the language, and not just about a custom rule set.

Different projects may have a different set of rules. I think it better to
go with the defaults as they are provided and have each project tune it.
Framework code is often different to application code so having one default
for both sorts of projects may not make sense.

Thanks,
Justin

Re: [FlexJS] technical debt

[piotrz]

Justin,

Let us know when you make the changes.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p62980.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Harbs]

Actually I did not miss that.

The Flex code is an external project:
https://code.google.com/archive/p/jsf-flex/ 


I’ll be happy to communicate.

Thanks,
Harbs

> On Jul 9, 2017, at 1:39 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Of the remaining 16 projects, it’s very easy to see that none of them are 
>> using the Flex language.
> 
> 
> The first link relies on projects meta data and may not be accurate. None of 
> the links you provide show what profile(s) the projects use.
> 
> You missed that MyFaces uses Sonar Type and it contains Flex code [1] but it 
> looks like their sonar project only uses the Java profile.
> 
> Please just take a little more care next time and communicate on list before 
> you make any changes.
> 
> Thanks,
> Justin
> 
> 1. https://wiki.apache.org/myfaces/JSF_Flex

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

>  Of the remaining 16 projects, it’s very easy to see that none of them are 
> using the Flex language.


The first link relies on projects meta data and may not be accurate. None of 
the links you provide show what profile(s) the projects use.

You missed that MyFaces uses Sonar Type and it contains Flex code [1] but it 
looks like their sonar project only uses the Java profile.

Please just take a little more care next time and communicate on list before 
you make any changes.

Thanks,
Justin

1. https://wiki.apache.org/myfaces/JSF_Flex

Re: [FlexJS] technical debt

[Harbs]

> On Jul 9, 2017, at 11:53 AM, Justin Mclean  wrote:
> 
>> O really! - There are other projects which using AS3 in Apache? Could you
>> send a links?
> 
> Off top of my head MyFaces, Thrift and a couple of others. Maxim works on one 
> of them but I think they may of moved to a JS front end. None that I know use 
> AS as the main language but given the 300+ projects including incubating ones 
> it’s often hard to know everything that is going on. 

It’s actually quite easy.[1]

The only project other than Flex which is listed as using ActionScript is 
Thrift. You can see the source code here.[2]

As you can see on the SonarQube dashboard[3], there are a total of 21 projects 
using SonarQube. 5 of those are Flex projects. Of the remaining 16 projects, 
it’s very easy to see that none of them are using the Flex language.

Thanks,
Harbs

[1]https://projects.apache.org/projects.html?language#ActionScript 

[2]https://github.com/apache/thrift/tree/master/lib/as3/src/org/apache/thrift 

[3]https://builds.apache.org/analysis/dashboard/index 

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> O really! - There are other projects which using AS3 in Apache? Could you
> send a links?

Off top of my head MyFaces, Thrift and a couple of others. Maxim works on one 
of them but I think they may of moved to a JS front end. None that I know use 
AS as the main language but given the 300+ projects including incubating ones 
it’s often hard to know everything that is going on. 

> You did creat wiki with rules. Maybe let's creat this custom profile now,
> revert changes which Harbs made and apply them to that profile.
> 
> I think that's the solution. Could you make it or do you want me to try it? 

I can do that.

Thanks,
Justin

Re: [FlexJS] technical debt

[piotrz]

Hi Justin,

O really! - There are other projects which using AS3 in Apache? Could you
send a links?

You did creat wiki with rules. Maybe let's creat this custom profile now,
revert changes which Harbs made and apply them to that profile.

I think that's the solution. Could you make it or do you want me to try it? 

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p62975.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I made two changes on Friday.

Can I ask why you didn’t email the list saying you had done this and what the 
purpose of disabling those rules were? Or disabling rules when I suggested that 
you should make a custom profile instead?

> It’s important to note that these changes were only to the “Flex” language. 
> Considering that we’re the only project using this language at all, it does 
> not effect anyone else.

How did you know we are the only project using that profile when you disabled 
those rules? Several other projects do use Actionscript and at least one I know 
has used Flex. What do you think would of happened if you had changed the Java 
default profile which we also use?

> Additionally, as best as I can tell, the language was first defined in the 
> end of December.

Sonar cube has been running against the FlexJS framework and compiler for more 
than a year (probably two). In December Apache updated to a new version of 
Sonar Cube. Going way back it was first suggested to be set up in 2013 and 
Chris had it running externally for a bit before it was set it up at Apache. 
There have been several discussions about it on thd list over that time and no 
one has suggested disabling rules that I can recall.

> Considering we “own” the language, it seems reasonable that we should define 
> sane defaults in case any other project DOES use the language.

I have Sonar Cube running locally and use it to track TD on a current project 
and I don’t disable those rules, in fact I turn on several more.

> "===" and "!==" should be used instead of "==" and "!=“ is simply incorrect 
> for ActionScript. I flies in the face of accepted coding practices for the 
> language, and should be removed completely.

Which is an opinion not held by all JavaScript and ActionScript developers, in 
fact a large number of them consider it harmful to use “==“ and “!=". I use 
“===“ and “!===“ most of the time in my AS code and I know (for instance) Josh 
does as well. It may not made sense to use it everywhere in the Flex JS SDK, 
but there is a fair amount of use off === and !== in the existing FlexJS SDK 
(around a 1000 occurrances from a quick search) so it seems that it’s not 
incorrect to use it even in our own framework.

Rather than turning off the rule I have suggested in my wiki document to make 
it a minor issue. You are free to ignore any minor issues you want. Sonar Cube 
also has good filtering tools to help you do that.

> "public static" fields should be constant is not something that Flex ever 
> enforced. I don’t really see the value for this rule, but I could go either 
> way.

Others may have differing options. It would would be best to discuss it on 
list/wiki first before turning any rules off.

> Feel free to revert my changes, but the discussion should be about defaults 
> for the language, and not just about a custom rule set.

Different projects may have a different set of rules. I think it better to go 
with the defaults as they are provided and have each project tune it. Framework 
code is often different to application code so having one default for both 
sorts of projects may not make sense.

Thanks,
Justin

Re: [FlexJS] technical debt

[piotrz]

Hi Harbs,

Just realized that you are right that rule "===" -> "==" is wrong for AS. :) 

Thanks for noticing that. Maybe we should also remove it from confluence -
to do not make confusion.

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-technical-debt-tp62851p62973.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] technical debt

[Harbs]

I’m just catching up on email.

I made two changes on Friday. I deactivated the following two rules for the 
Flex language. (Please note that I only deactivated them. I did not delete 
them.) I wanted to see how much that would effect the score:
"===" and "!==" should be used instead of "==" and "!=“
and
"public static" fields should be constant

There are others that would be interesting to see how they effect the score as 
well.

It’s important to note that these changes were only to the “Flex” language. 
Considering that we’re the only project using this language at all, it does not 
effect anyone else. Additionally, as best as I can tell, the language was first 
defined in the end of December. Considering we “own” the language, it seems 
reasonable that we should define sane defaults in case any other project DOES 
use the language.

"===" and "!==" should be used instead of "==" and "!=“ is simply incorrect for 
ActionScript. I flies in the face of accepted coding practices for the 
language, and should be removed completely. It causes thousands of complaints.

"public static" fields should be constant is not something that Flex ever 
enforced. I don’t really see the value for this rule, but I could go either way.

There are some other rules which should be discussed, but we can do that on the 
wiki.

Feel free to revert my changes, but the discussion should be about defaults for 
the language, and not just about a custom rule set.

Thanks,
Harbs

> On Jul 8, 2017, at 6:41 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Before you accuse anyone (even if you expressed doubt) do you have a way to 
>> determine who made the change to the Sonar Cube configuration?
> 
> I can’t see anything in the interface no, but the changes are logged and 
> infra will be able to tell. If it wasn’t him I’ll appoligise.
> 
> Thanks,
> Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> Before you accuse anyone (even if you expressed doubt) do you have a way to 
> determine who made the change to the Sonar Cube configuration?

I can’t see anything in the interface no, but the changes are logged and infra 
will be able to tell. If it wasn’t him I’ll appoligise.

Thanks,
Justin

Re: [FlexJS] technical debt

[Dave Fisher]

OK got it.

Before you accuse anyone (even if you expressed doubt) do you have a way to 
determine who made the change to the Sonar Cube configuration? Does 
Infrastructure?

Did anyone on the Flex project make any changes?

Regards,
Dave

> On Jul 7, 2017, at 8:18 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> My discussion was around procedures related to technical debt.
> 
> And you would agree the Sonar Cube configuration relates to that?
> 
>> Keep in mind that this is all my opinion as part of the PMC. If others don't 
>> agree then there is not yet consensus.
> 
> Which is why as suggested I’m trying to document [1] and get consensus on 
> what we can do before changing the configuration.
> 
>> I'm not sure about the profile. Please take a look at the commits and you 
>> should question and discuss that change separately on TECHNICAL merits.
> 
> There are no commits (it's not under version control) but just options in the 
> Sonar web interface, there's was no discussion and no email to the list about 
> these changes.
> 
> Note that the changes effect ALL Apache projects using Sonar Cube (using that 
> default profile) not just the Flex project so that should be reason enough to 
> reset it back to the way it was. I did suggest to creating a new profile.
> 
> For a technical point of view there are a number of useful rules that have 
> been disabled i.e. rules that pick up issues like this: for (var i:int =0; i 
> < someArray.length; i++) where someArray.length should be defined outside the 
> loop for performance reasons.
> 
> So consider this a -1 (veto) with valid reason as stated above and unless 
> someone has a good technical reason why those all those rules were disabled 
> for all projects I suggest they be reverted.
> 
> Thanks,
> Justin
> 
> 1. https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules 
> 



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> My discussion was around procedures related to technical debt.

And you would agree the Sonar Cube configuration relates to that?

> Keep in mind that this is all my opinion as part of the PMC. If others don't 
> agree then there is not yet consensus.

Which is why as suggested I’m trying to document [1] and get consensus on what 
we can do before changing the configuration.

> I'm not sure about the profile. Please take a look at the commits and you 
> should question and discuss that change separately on TECHNICAL merits.

There are no commits (it's not under version control) but just options in the 
Sonar web interface, there's was no discussion and no email to the list about 
these changes.

Note that the changes effect ALL Apache projects using Sonar Cube (using that 
default profile) not just the Flex project so that should be reason enough to 
reset it back to the way it was. I did suggest to creating a new profile.

For a technical point of view there are a number of useful rules that have been 
disabled i.e. rules that pick up issues like this: for (var i:int =0; i < 
someArray.length; i++) where someArray.length should be defined outside the 
loop for performance reasons.

So consider this a -1 (veto) with valid reason as stated above and unless 
someone has a good technical reason why those all those rules were disabled for 
all projects I suggest they be reverted.

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules 

Re: [FlexJS] technical debt

[Dave Fisher]

Hi Justin,

My discussion was around procedures related to technical debt. Keep in mind 
that this is all my opinion as part of the PMC. If others don't agree then 
there is not yet consensus.

I'm not sure about the profile. Please take a look at the commits and you 
should question and discuss that change separately on TECHNICAL merits.

Otherwise you going to start yet another heated thread.

Regards,
Dave

Sent from my iPhone

> On Jul 7, 2017, at 5:39 PM, jus...@classsoftware.com wrote:
> 
> Hi,
> 
> Harbs I see you have gone ahead (or rather I assume it was you so apologies 
> if it wasn't) and modified the default Flex profile. As discussed in this 
> thread that was not the right way to do this and there needs to some 
> documentation and discussion around this before we make changes. As Dave 
> suggested I will document the changes to the rules in a wiki so we can 
> discuss (if needed) and implement.
> 
> Can you please revert the changes the to rules you have made. 
> 
> Thanks,
> Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

I’ve created a draft page here [1] and will do some more work on it over the 
weekend.

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/FLEX/Sonar+Cube+Flex+Rules

Re: [FlexJS] technical debt

[justin]

Hi,

Harbs I see you have gone ahead (or rather I assume it was you so apologies if 
it wasn't) and modified the default Flex profile. As discussed in this thread 
that was not the right way to do this and there needs to some documentation and 
discussion around this before we make changes. As Dave suggested I will 
document the changes to the rules in a wiki so we can discuss (if needed) and 
implement.

Can you please revert the changes the to rules you have made. 

Thanks,
Justin

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Josh Tynjala]

The TraceListener in the example code listens for events from the
TestRunner and prints to the console. Those same events could be used to
collect failures and do anything you want with them.

- Josh

On Fri, Jul 7, 2017 at 8:59 AM, Alex Harui  wrote:

> Hi Josh,
>
> That could be good.  I took a quick look and didn't understand how it
> reports errors that can be collected and reported.  How does that work?
> Would it interface with Selenium?
>
> Thanks,
> -Alex
>
> On 7/7/17, 8:23 AM, "Josh Tynjala"  wrote:
>
> >I wrote a simple test runner similar to FlexUnit for some of my projects.
> >I'm happy to donate this code to FlexJS or FlexUnit if it can help
> >bootstrap the testing efforts.
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.co
> >m%2FBowlerHatLLC%2Fnextgenas-test=02%7C01%7C%
> 7C68cc4baa25b34232470408
> >d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636350378641405029
> >=auA9oG3sSGDFlZ0CC40PZ1LpX6pl9vaFjBWav7SWf34%3D=0
> >
> >It supports [Test], [Before], and [After] metadata:
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.co
> >m%2FBowlerHatLLC%2Fnextgenas-test%2Fwiki%2FMetadata=
> 02%7C01%7C%7C68cc
> >4baa25b34232470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C
> >636350378641405029=81tT4SQse5BRp2LtJGCybnwsZLEP9P
> 8wDl9zrYpoOYo%3D
> >served=0
> >
> >- Josh
> >
> >
> >
> >On Fri, Jul 7, 2017 at 3:16 AM, Harbs  wrote:
> >
> >> The checkintests target currently fails. I’m guessing the build file was
> >> not updated for dual.
> >>
> >> Selenium has a JS API[1]. It seems like we should be able to write tests
> >> in MXML and AS and then use Node.js to run the results. I’m not sure how
> >> easy it would be to generalize tests so that the same tests could be
> >>run in
> >> both Flash and Selenium. It should be an interesting project to try.
> >>
> >> We should probably add FlexUnit tests even if they only run in SWF. I
> >>will
> >> make an attempt to do so myself. It seems like it should be possible to
> >>run
> >> the FlexUnit tests in JS using one of the JS unit testing frameworks or
> >> even rolling our own JS implementation. I don’t think the way it’s run
> >>is
> >> important, but it would be a very good idea to allow FlexUnit to run in
> >>JS
> >> unmodified.
> >>
> >> I never quite “got” how the meta tags in FlexUnit actually work.
> >>
> >>
> >>[1]https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.n
> >>pmjs.com%2Fpackage%2Fselenium-webdriver=02%
> 7C01%7C%7C68cc4baa25b3423
> >>2470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6363503786
> >>41405029=gfStLT52BXyKlgefzw63jD0M71L6UJklCCPe0kW2yjw%3D=0
> >><
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.npmj
> >>s.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%
> 7C68cc4baa25b3423247
> >>0408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6363503786414
> >>05029=gfStLT52BXyKlgefzw63jD0M71L6UJklCCPe0kW2yjw%3D=0>
> >>
> >> > On Jul 7, 2017, at 1:38 AM, Alex Harui 
> >>wrote:
> >> >
> >> > I have a subset of Mustella working on both platforms in the
> >>BasicTests
> >> > that run from the checkintests target in the Ant build.  There is a
> >> > writeup on Mustella in the wiki
> >> >
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fcwiki.ap
> >>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FMustella%
> 2BOverview=02%7C01
> >>%7C%7C68cc4baa25b34232470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178de
> cee1
> >>%7C0%7C0%7C636350378641405029=pEFm3JIcipgNSvZMjSglS16g%
> 2BHyuZK%2FhY
> >>lFRG4lBwdA%3D=0.  I
> >> > haven't gone through it to see how much does or doesn't apply to
> >>FlexJS.
> >> > The BasicTests are in the flex-asjs repo in
> >>mustella/tests/basicTests.  I
> >> > basically copied the Flex SDK's BasicTests and modified it a bit to
> >>run
> >> in
> >> > FlexJS and commented out most tests because back when I did it, we
> >>didn't
> >> > have many components.  It might be interesting to comment more tests
> >>back
> >> > in and see if they run.
> >> >
> >> > There are some FlexUnit tests that run as part of the Core.swc Ant
> >>build,
> >> > but only on SWF.
> >> >
> >> > The Maven build runs some Selenium tests that I think are written in
> >> Java,
> >> > and I think only test JS output.
> >> >
> >> > I haven't invested much time in test infrastructure or test creation
> >> since
> >> > there were some strong opinions about not liking Mustella and some
> >> > thoughts about how to make FlexUnit run on both platforms.
> >> >
> >> > My personal preference is that tests should be written in MXML and/or
> >>AS
> >> > and run on both platforms.  Bonus points if existing tests can be run
> >> > unmodified or mostly unmodified.
> >> >
> >> > -Alex
> >> >
> >> > On 7/6/17, 2:02 PM, "Harbs"  wrote:
> >> >
> >> >> Where are the 

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Alex Harui]

And you have a Core.swc in
/Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/libs?  What is in:

/Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/flex-config.xml


-Alex

On 7/7/17, 9:14 AM, "Harbs"  wrote:

>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FGcuj=02%7C01%7C%7C0e3a53510ea840b2ee3908d4c55354c8%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636350409091821954=EHi%2Bx3XzTM
>ftQRdEIaYOeKtFCDQr1XU3JggHreKemUk%3D=0
>ache.org%2FGcuj=02%7C01%7C%7C0e3a53510ea840b2ee3908d4c55354c8%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636350409091831959=XjG7DH2jIQK
>v%2BI%2F2BIUhEIDjI4vZv2JD0a7zkZkg28s%3D=0>
>
>> On Jul 7, 2017, at 6:55 PM, Alex Harui  wrote:
>> 
>> What error did you get?
>> 
>> The Ant build on the CI server runs checkintests and it is passing
>>there.
>> 
>> The FlexJS Mustella uses Selenium for the JS run, but some manual
>> intervention is currently required.
>> 
>> -Alex
>> 
>> On 7/7/17, 3:16 AM, "Harbs"  wrote:
>> 
>>> The checkintests target currently fails. I’m guessing the build file
>>>was
>>> not updated for dual.
>>> 
>>> Selenium has a JS API[1]. It seems like we should be able to write
>>>tests
>>> in MXML and AS and then use Node.js to run the results. I’m not sure
>>>how
>>> easy it would be to generalize tests so that the same tests could be
>>>run
>>> in both Flash and Selenium. It should be an interesting project to try.
>>> 
>>> We should probably add FlexUnit tests even if they only run in SWF. I
>>> will make an attempt to do so myself. It seems like it should be
>>>possible
>>> to run the FlexUnit tests in JS using one of the JS unit testing
>>> frameworks or even rolling our own JS implementation. I don’t think the
>>> way it’s run is important, but it would be a very good idea to allow
>>> FlexUnit to run in JS unmodified.
>>> 
>>> I never quite “got” how the meta tags in FlexUnit actually work.
>>> 
>>> 
>>>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>np
>>> 
>>>mjs.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db
>>>5f
>>> 
>>>ae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635019419
>>>32
>>> 82017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0
>>> 
>>>>>mj
>>> 
>>>s.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db5f
>>>ae
>>> 
>>>608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363501941932
>>>82
>>> 017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0>
>>> 
 On Jul 7, 2017, at 1:38 AM, Alex Harui 
wrote:
 
 I have a subset of Mustella working on both platforms in the
BasicTests
 that run from the checkintests target in the Ant build.  There is a
 writeup on Mustella in the wiki
 
 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.
ap
 
ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FMustella%2BOverview=02%7C
01
 
%7C%7C5851203659274db5fae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178dece
e1
 
%7C0%7C0%7C636350194193282017=0Pnb%2BdCvmgY9UVKOj4lELhkNa3VJBKnrg
OA
 WnOy2cvc%3D=0.  I
 haven't gone through it to see how much does or doesn't apply to
FlexJS.
 The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.
 I
 basically copied the Flex SDK's BasicTests and modified it a bit to
run
 in
 FlexJS and commented out most tests because back when I did it, we
 didn't
 have many components.  It might be interesting to comment more tests
 back
 in and see if they run.
 
 There are some FlexUnit tests that run as part of the Core.swc Ant
 build,
 but only on SWF.
 
 The Maven build runs some Selenium tests that I think are written in
 Java,
 and I think only test JS output.
 
 I haven't invested much time in test infrastructure or test creation
 since
 there were some strong opinions about not liking Mustella and some
 thoughts about how to make FlexUnit run on both platforms.
 
 My personal preference is that tests should be written in MXML and/or
AS
 and run on both platforms.  Bonus points if existing tests can be run
 unmodified or mostly unmodified.
 
 -Alex
 
 On 7/6/17, 2:02 PM, "Harbs"  wrote:
 
> Where are the instructions on how to use it? If I know how to write
> tests, I’d be much better about doing so…
> 
>> On Jul 6, 2017, at 11:53 PM, Alex Harui 
>> wrote:
>> 
>> I have put in place a test infrastructure
> 
 
>>> 
>> 
>

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Harbs]

https://paste.apache.org/Gcuj 

> On Jul 7, 2017, at 6:55 PM, Alex Harui  wrote:
> 
> What error did you get?
> 
> The Ant build on the CI server runs checkintests and it is passing there.
> 
> The FlexJS Mustella uses Selenium for the JS run, but some manual
> intervention is currently required.
> 
> -Alex
> 
> On 7/7/17, 3:16 AM, "Harbs"  wrote:
> 
>> The checkintests target currently fails. I’m guessing the build file was
>> not updated for dual.
>> 
>> Selenium has a JS API[1]. It seems like we should be able to write tests
>> in MXML and AS and then use Node.js to run the results. I’m not sure how
>> easy it would be to generalize tests so that the same tests could be run
>> in both Flash and Selenium. It should be an interesting project to try.
>> 
>> We should probably add FlexUnit tests even if they only run in SWF. I
>> will make an attempt to do so myself. It seems like it should be possible
>> to run the FlexUnit tests in JS using one of the JS unit testing
>> frameworks or even rolling our own JS implementation. I don’t think the
>> way it’s run is important, but it would be a very good idea to allow
>> FlexUnit to run in JS unmodified.
>> 
>> I never quite “got” how the meta tags in FlexUnit actually work.
>> 
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.np
>> mjs.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db5f
>> ae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363501941932
>> 82017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0
>> > s.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db5fae
>> 608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636350194193282
>> 017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0>
>> 
>>> On Jul 7, 2017, at 1:38 AM, Alex Harui  wrote:
>>> 
>>> I have a subset of Mustella working on both platforms in the BasicTests
>>> that run from the checkintests target in the Ant build.  There is a
>>> writeup on Mustella in the wiki
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>> ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FMustella%2BOverview=02%7C01
>>> %7C%7C5851203659274db5fae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1
>>> %7C0%7C0%7C636350194193282017=0Pnb%2BdCvmgY9UVKOj4lELhkNa3VJBKnrgOA
>>> WnOy2cvc%3D=0.  I
>>> haven't gone through it to see how much does or doesn't apply to FlexJS.
>>> The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.
>>> I
>>> basically copied the Flex SDK's BasicTests and modified it a bit to run
>>> in
>>> FlexJS and commented out most tests because back when I did it, we
>>> didn't
>>> have many components.  It might be interesting to comment more tests
>>> back
>>> in and see if they run.
>>> 
>>> There are some FlexUnit tests that run as part of the Core.swc Ant
>>> build,
>>> but only on SWF.
>>> 
>>> The Maven build runs some Selenium tests that I think are written in
>>> Java,
>>> and I think only test JS output.
>>> 
>>> I haven't invested much time in test infrastructure or test creation
>>> since
>>> there were some strong opinions about not liking Mustella and some
>>> thoughts about how to make FlexUnit run on both platforms.
>>> 
>>> My personal preference is that tests should be written in MXML and/or AS
>>> and run on both platforms.  Bonus points if existing tests can be run
>>> unmodified or mostly unmodified.
>>> 
>>> -Alex
>>> 
>>> On 7/6/17, 2:02 PM, "Harbs"  wrote:
>>> 
 Where are the instructions on how to use it? If I know how to write
 tests, I’d be much better about doing so…
 
> On Jul 6, 2017, at 11:53 PM, Alex Harui 
> wrote:
> 
> I have put in place a test infrastructure
 
>>> 
>> 
> 

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Alex Harui]

Hi Josh,

That could be good.  I took a quick look and didn't understand how it
reports errors that can be collected and reported.  How does that work?
Would it interface with Selenium?

Thanks,
-Alex

On 7/7/17, 8:23 AM, "Josh Tynjala"  wrote:

>I wrote a simple test runner similar to FlexUnit for some of my projects.
>I'm happy to donate this code to FlexJS or FlexUnit if it can help
>bootstrap the testing efforts.
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2FBowlerHatLLC%2Fnextgenas-test=02%7C01%7C%7C68cc4baa25b34232470408
>d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636350378641405029
>=auA9oG3sSGDFlZ0CC40PZ1LpX6pl9vaFjBWav7SWf34%3D=0
>
>It supports [Test], [Before], and [After] metadata:
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2FBowlerHatLLC%2Fnextgenas-test%2Fwiki%2FMetadata=02%7C01%7C%7C68cc
>4baa25b34232470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
>636350378641405029=81tT4SQse5BRp2LtJGCybnwsZLEP9P8wDl9zrYpoOYo%3D
>served=0
>
>- Josh
>
>
>
>On Fri, Jul 7, 2017 at 3:16 AM, Harbs  wrote:
>
>> The checkintests target currently fails. I’m guessing the build file was
>> not updated for dual.
>>
>> Selenium has a JS API[1]. It seems like we should be able to write tests
>> in MXML and AS and then use Node.js to run the results. I’m not sure how
>> easy it would be to generalize tests so that the same tests could be
>>run in
>> both Flash and Selenium. It should be an interesting project to try.
>>
>> We should probably add FlexUnit tests even if they only run in SWF. I
>>will
>> make an attempt to do so myself. It seems like it should be possible to
>>run
>> the FlexUnit tests in JS using one of the JS unit testing frameworks or
>> even rolling our own JS implementation. I don’t think the way it’s run
>>is
>> important, but it would be a very good idea to allow FlexUnit to run in
>>JS
>> unmodified.
>>
>> I never quite “got” how the meta tags in FlexUnit actually work.
>>
>> 
>>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n
>>pmjs.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C68cc4baa25b3423
>>2470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363503786
>>41405029=gfStLT52BXyKlgefzw63jD0M71L6UJklCCPe0kW2yjw%3D=0
>><
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.npmj
>>s.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C68cc4baa25b3423247
>>0408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363503786414
>>05029=gfStLT52BXyKlgefzw63jD0M71L6UJklCCPe0kW2yjw%3D=0>
>>
>> > On Jul 7, 2017, at 1:38 AM, Alex Harui 
>>wrote:
>> >
>> > I have a subset of Mustella working on both platforms in the
>>BasicTests
>> > that run from the checkintests target in the Ant build.  There is a
>> > writeup on Mustella in the wiki
>> > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FMustella%2BOverview=02%7C01
>>%7C%7C68cc4baa25b34232470408d4c54c3ded%7Cfa7b1b5a7b34438794aed2c178decee1
>>%7C0%7C0%7C636350378641405029=pEFm3JIcipgNSvZMjSglS16g%2BHyuZK%2FhY
>>lFRG4lBwdA%3D=0.  I
>> > haven't gone through it to see how much does or doesn't apply to
>>FlexJS.
>> > The BasicTests are in the flex-asjs repo in
>>mustella/tests/basicTests.  I
>> > basically copied the Flex SDK's BasicTests and modified it a bit to
>>run
>> in
>> > FlexJS and commented out most tests because back when I did it, we
>>didn't
>> > have many components.  It might be interesting to comment more tests
>>back
>> > in and see if they run.
>> >
>> > There are some FlexUnit tests that run as part of the Core.swc Ant
>>build,
>> > but only on SWF.
>> >
>> > The Maven build runs some Selenium tests that I think are written in
>> Java,
>> > and I think only test JS output.
>> >
>> > I haven't invested much time in test infrastructure or test creation
>> since
>> > there were some strong opinions about not liking Mustella and some
>> > thoughts about how to make FlexUnit run on both platforms.
>> >
>> > My personal preference is that tests should be written in MXML and/or
>>AS
>> > and run on both platforms.  Bonus points if existing tests can be run
>> > unmodified or mostly unmodified.
>> >
>> > -Alex
>> >
>> > On 7/6/17, 2:02 PM, "Harbs"  wrote:
>> >
>> >> Where are the instructions on how to use it? If I know how to write
>> >> tests, I’d be much better about doing so…
>> >>
>> >>> On Jul 6, 2017, at 11:53 PM, Alex Harui 
>> >>> wrote:
>> >>>
>> >>> I have put in place a test infrastructure
>> >>
>> >
>>
>>

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Alex Harui]

What error did you get?

The Ant build on the CI server runs checkintests and it is passing there.

The FlexJS Mustella uses Selenium for the JS run, but some manual
intervention is currently required.

-Alex

On 7/7/17, 3:16 AM, "Harbs"  wrote:

>The checkintests target currently fails. I’m guessing the build file was
>not updated for dual.
>
>Selenium has a JS API[1]. It seems like we should be able to write tests
>in MXML and AS and then use Node.js to run the results. I’m not sure how
>easy it would be to generalize tests so that the same tests could be run
>in both Flash and Selenium. It should be an interesting project to try.
>
>We should probably add FlexUnit tests even if they only run in SWF. I
>will make an attempt to do so myself. It seems like it should be possible
>to run the FlexUnit tests in JS using one of the JS unit testing
>frameworks or even rolling our own JS implementation. I don’t think the
>way it’s run is important, but it would be a very good idea to allow
>FlexUnit to run in JS unmodified.
>
>I never quite “got” how the meta tags in FlexUnit actually work.
>
>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.np
>mjs.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db5f
>ae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363501941932
>82017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0
>s.com%2Fpackage%2Fselenium-webdriver=02%7C01%7C%7C5851203659274db5fae
>608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636350194193282
>017=k0RGXQMJAf5YMPo4Cvq%2BXXtn6ELAqhf4USYcj0qdLag%3D=0>
>
>> On Jul 7, 2017, at 1:38 AM, Alex Harui  wrote:
>> 
>> I have a subset of Mustella working on both platforms in the BasicTests
>> that run from the checkintests target in the Ant build.  There is a
>> writeup on Mustella in the wiki
>> 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.ap
>>ache.org%2Fconfluence%2Fdisplay%2FFLEX%2FMustella%2BOverview=02%7C01
>>%7C%7C5851203659274db5fae608d4c5214b2a%7Cfa7b1b5a7b34438794aed2c178decee1
>>%7C0%7C0%7C636350194193282017=0Pnb%2BdCvmgY9UVKOj4lELhkNa3VJBKnrgOA
>>WnOy2cvc%3D=0.  I
>> haven't gone through it to see how much does or doesn't apply to FlexJS.
>> The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.
>>I
>> basically copied the Flex SDK's BasicTests and modified it a bit to run
>>in
>> FlexJS and commented out most tests because back when I did it, we
>>didn't
>> have many components.  It might be interesting to comment more tests
>>back
>> in and see if they run.
>> 
>> There are some FlexUnit tests that run as part of the Core.swc Ant
>>build,
>> but only on SWF.
>> 
>> The Maven build runs some Selenium tests that I think are written in
>>Java,
>> and I think only test JS output.
>> 
>> I haven't invested much time in test infrastructure or test creation
>>since
>> there were some strong opinions about not liking Mustella and some
>> thoughts about how to make FlexUnit run on both platforms.
>> 
>> My personal preference is that tests should be written in MXML and/or AS
>> and run on both platforms.  Bonus points if existing tests can be run
>> unmodified or mostly unmodified.
>> 
>> -Alex
>> 
>> On 7/6/17, 2:02 PM, "Harbs"  wrote:
>> 
>>> Where are the instructions on how to use it? If I know how to write
>>> tests, I’d be much better about doing so…
>>> 
 On Jul 6, 2017, at 11:53 PM, Alex Harui 
 wrote:
 
 I have put in place a test infrastructure
>>> 
>> 
>

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Josh Tynjala]

I wrote a simple test runner similar to FlexUnit for some of my projects.
I'm happy to donate this code to FlexJS or FlexUnit if it can help
bootstrap the testing efforts.

https://github.com/BowlerHatLLC/nextgenas-test

It supports [Test], [Before], and [After] metadata:

https://github.com/BowlerHatLLC/nextgenas-test/wiki/Metadata

- Josh



On Fri, Jul 7, 2017 at 3:16 AM, Harbs  wrote:

> The checkintests target currently fails. I’m guessing the build file was
> not updated for dual.
>
> Selenium has a JS API[1]. It seems like we should be able to write tests
> in MXML and AS and then use Node.js to run the results. I’m not sure how
> easy it would be to generalize tests so that the same tests could be run in
> both Flash and Selenium. It should be an interesting project to try.
>
> We should probably add FlexUnit tests even if they only run in SWF. I will
> make an attempt to do so myself. It seems like it should be possible to run
> the FlexUnit tests in JS using one of the JS unit testing frameworks or
> even rolling our own JS implementation. I don’t think the way it’s run is
> important, but it would be a very good idea to allow FlexUnit to run in JS
> unmodified.
>
> I never quite “got” how the meta tags in FlexUnit actually work.
>
> [1]https://www.npmjs.com/package/selenium-webdriver <
> https://www.npmjs.com/package/selenium-webdriver>
>
> > On Jul 7, 2017, at 1:38 AM, Alex Harui  wrote:
> >
> > I have a subset of Mustella working on both platforms in the BasicTests
> > that run from the checkintests target in the Ant build.  There is a
> > writeup on Mustella in the wiki
> > https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview.  I
> > haven't gone through it to see how much does or doesn't apply to FlexJS.
> > The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.  I
> > basically copied the Flex SDK's BasicTests and modified it a bit to run
> in
> > FlexJS and commented out most tests because back when I did it, we didn't
> > have many components.  It might be interesting to comment more tests back
> > in and see if they run.
> >
> > There are some FlexUnit tests that run as part of the Core.swc Ant build,
> > but only on SWF.
> >
> > The Maven build runs some Selenium tests that I think are written in
> Java,
> > and I think only test JS output.
> >
> > I haven't invested much time in test infrastructure or test creation
> since
> > there were some strong opinions about not liking Mustella and some
> > thoughts about how to make FlexUnit run on both platforms.
> >
> > My personal preference is that tests should be written in MXML and/or AS
> > and run on both platforms.  Bonus points if existing tests can be run
> > unmodified or mostly unmodified.
> >
> > -Alex
> >
> > On 7/6/17, 2:02 PM, "Harbs"  wrote:
> >
> >> Where are the instructions on how to use it? If I know how to write
> >> tests, I’d be much better about doing so…
> >>
> >>> On Jul 6, 2017, at 11:53 PM, Alex Harui 
> >>> wrote:
> >>>
> >>> I have put in place a test infrastructure
> >>
> >
>
>

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Harbs]

The checkintests target currently fails. I’m guessing the build file was not 
updated for dual.

Selenium has a JS API[1]. It seems like we should be able to write tests in 
MXML and AS and then use Node.js to run the results. I’m not sure how easy it 
would be to generalize tests so that the same tests could be run in both Flash 
and Selenium. It should be an interesting project to try.

We should probably add FlexUnit tests even if they only run in SWF. I will make 
an attempt to do so myself. It seems like it should be possible to run the 
FlexUnit tests in JS using one of the JS unit testing frameworks or even 
rolling our own JS implementation. I don’t think the way it’s run is important, 
but it would be a very good idea to allow FlexUnit to run in JS unmodified.

I never quite “got” how the meta tags in FlexUnit actually work.

[1]https://www.npmjs.com/package/selenium-webdriver 


> On Jul 7, 2017, at 1:38 AM, Alex Harui  wrote:
> 
> I have a subset of Mustella working on both platforms in the BasicTests
> that run from the checkintests target in the Ant build.  There is a
> writeup on Mustella in the wiki
> https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview.  I
> haven't gone through it to see how much does or doesn't apply to FlexJS.
> The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.  I
> basically copied the Flex SDK's BasicTests and modified it a bit to run in
> FlexJS and commented out most tests because back when I did it, we didn't
> have many components.  It might be interesting to comment more tests back
> in and see if they run.
> 
> There are some FlexUnit tests that run as part of the Core.swc Ant build,
> but only on SWF.
> 
> The Maven build runs some Selenium tests that I think are written in Java,
> and I think only test JS output.
> 
> I haven't invested much time in test infrastructure or test creation since
> there were some strong opinions about not liking Mustella and some
> thoughts about how to make FlexUnit run on both platforms.
> 
> My personal preference is that tests should be written in MXML and/or AS
> and run on both platforms.  Bonus points if existing tests can be run
> unmodified or mostly unmodified.
> 
> -Alex
> 
> On 7/6/17, 2:02 PM, "Harbs"  wrote:
> 
>> Where are the instructions on how to use it? If I know how to write
>> tests, I’d be much better about doing so…
>> 
>>> On Jul 6, 2017, at 11:53 PM, Alex Harui 
>>> wrote:
>>> 
>>> I have put in place a test infrastructure
>> 
> 

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> I don’t see any options like that (logged in using my Apache account). Does 
> someone need to add permissions?

If you can’t see them then yes you would need to ask infra.

Justin

Re: [FlexJS] technical debt

[Harbs]

I don’t see any options like that (logged in using my Apache account). Does 
someone need to add permissions?

> On Jul 7, 2017, at 10:49 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>>> and how do we change them?
> 
> In the sonar cube web interface (same url as before) under rules/quality 
> profile. It's best to set up a new quality profile rather than edit the 
> existing one as that may effect other projects.
> 
> I’ll put together a wiki page on making the rules more in the style of the 
> SDK and we’ll go from there.
> 
> Thanks,
> Justin
> 

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

>> and how do we change them?

In the sonar cube web interface (same url as before) under rules/quality 
profile. It's best to set up a new quality profile rather than edit the 
existing one as that may effect other projects.

I’ll put together a wiki page on making the rules more in the style of the SDK 
and we’ll go from there.

Thanks,
Justin

Re: [FlexJS] technical debt

[Harbs]

Considering you did not answer the most significant part of my question. I’m 
asking it again.

> On Jul 6, 2017, at 9:13 PM, Harbs  wrote:
> 
> and how do we change them?

Re: [FlexJS] technical debt

[Alex Harui]

IMO, it applies to anyone making changes to code paths that are probably
working.  As we've already seen, there is a cost to making a mistake in
what seems like a simple change that totally outweighs the value to the
technology.  Folks creating new features or fixing major bugs are really
"moving the needle" and adding new code paths and I am willing to take
risks around test coverage.  Until our consumers start making requests for
cleaning up technical debt, the minimal functional value gained is
currently not worth the risk.

My 2 cents,
-Alex

On 7/6/17, 5:22 PM, "Justin Mclean"  wrote:

>Hi,
>
>> If you make a change to fix technical debt then you should also assure
>>that both existing tests pass and if no tests exist then tests are added
>>and proper.
>
>I’m all for more tests. However should this apply to any changes anyone
>makes for any reason OR only changes I make?
>
>I asking because taken literally this could possible end up being a
>situation were any changes I make are vetoed due to low test coverage but
>other people can make changes and ignore test coverage.
>
>Thanks,
>Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> Think of it like this if someone makes a commit you would not revert without 
> giving them an opportunity to do it first.
> 
> So the suggestion from me is get approval for anything complex. It is the 
> social thing to do.

!00% agree.

> I see you asked directly about a standard else thread.

Yep let's see what other people think about the idea.

Thanks,
Justin

Re: [FlexJS] technical debt

[Dave Fisher]

Sent from my iPhone

> On Jul 6, 2017, at 5:22 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> If you make a change to fix technical debt then you should also assure that 
>> both existing tests pass and if no tests exist then tests are added and 
>> proper.
> 
> I’m all for more tests. However should this apply to any changes anyone makes 
> for any reason OR only changes I make?

It applies to making other than the most minimal changes due to a sonar report. 
Obviously trivial changes like the ; but not the === require discussion.

Think of it like this if someone makes a commit you would not revert without 
giving them an opportunity to do it first.

So the suggestion from me is get approval for anything complex. It is the 
social thing to do.

> 
> I asking because taken literally this could possible end up being a situation 
> were any changes I make are vetoed due to low test coverage but other people 
> can make changes and ignore test coverage.

I see you asked directly about a standard else thread.

Regards,
Dave


> 
> Thanks,
> Justin

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[justin]

Hi,

What do people feel about setting a code and branch coverage on all checkins? 
Say 80% coverage of changes made?

Thanks,
Justin

Re: [FlexJS] technical debt

[Greg Dove]

>> Well Object is always THE base class. It may not be known what the
actual base class should be and it is certainly not flexible to always
create a base class just to have a one to satisfy the rule.

>Nor would I suggest that. There are some cases where creating a new class
with properties is going to make sense, there other in where having the
flexibility of Object make sense. You may not be aware there a big
difference between Object and something that extends Object. Objects’s are
dynamic and properties (and methods) can be added at runtime but this comes
at a performance cost. Class that extend Object are not dynamic and you
can’t do this and as a result are faster.

>> Justin - If you have clear performance results then please document them
in the wiki.

>Other people have already researched this and it’s well known AFAIK. For
example here's an old article by Alex [1] where for accessing properties
there’s a 20x performance increase. Obviously there’s a little more to it
than just that but more recent article also have similar results. Object
can be useful but it does come at a performance cost.

I'm not sure if performance concern is a priority here or not, because
although it is important in AVM, it may not be relevant in the browser
where things are untyped in any case. I vaguely recall reading something in
another thread recently that left me with the impression that javascript
output was the priority (for performance, I think) and that the primary
objectives for swf were to achieve compatibility. I think this was in
relation to some view or layout code, but I do wonder if it is a general
'guidance' that would be relevant for things like this. If it is, it would
be good to document that as an explicit piece of guidance (if it is not
already stated somewhere).



On Fri, Jul 7, 2017 at 12:19 PM, Justin Mclean 
wrote:

> Hi,
>
> > That is the concern, but it may be that the developer was making a
> speculative change. If I were cleaning then I would do one of two actions.
> >
> > (a) Review the history of that change and see if the associated comments
> provide a reason.
> > (b) Ask the developer who made the change.
>
> Both are courses of action that I would take assuming the info in the VC
> comments and/or the developer is still about. Sometimes that may not be the
> case.
>
> > Well Object is always THE base class. It may not be known what the
> actual base class should be and it is certainly not flexible to always
> create a base class just to have a one to satisfy the rule.
>
> Nor would I suggest that. There are some cases where creating a new class
> with properties is going to make sense, there other in where having the
> flexibility of Object make sense. You may not be aware there a big
> difference between Object and something that extends Object. Objects’s are
> dynamic and properties (and methods) can be added at runtime but this comes
> at a performance cost. Class that extend Object are not dynamic and you
> can’t do this and as a result are faster.
>
> > Justin - If you have clear performance results then please document them
> in the wiki.
>
> Other people have already researched this and it’s well known AFAIK. For
> example here's an old article by Alex [1] where for accessing properties
> there’s a 20x performance increase. Obviously there’s a little more to it
> than just that but more recent article also have similar results. Object
> can be useful but it does come at a performance cost.
>
> > Thanks. Do you know how to deactivate useless rules?
>
> Yes.
>
> Thanks,
> Justin
>
> 1. http://blogs.adobe.com/aharui/2007/10/actionscript_
> readwrite_perform_1.html

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> If you make a change to fix technical debt then you should also assure that 
> both existing tests pass and if no tests exist then tests are added and 
> proper.

I’m all for more tests. However should this apply to any changes anyone makes 
for any reason OR only changes I make?

I asking because taken literally this could possible end up being a situation 
were any changes I make are vetoed due to low test coverage but other people 
can make changes and ignore test coverage.

Thanks,
Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> That is the concern, but it may be that the developer was making a 
> speculative change. If I were cleaning then I would do one of two actions.
> 
> (a) Review the history of that change and see if the associated comments 
> provide a reason.
> (b) Ask the developer who made the change.

Both are courses of action that I would take assuming the info in the VC 
comments and/or the developer is still about. Sometimes that may not be the 
case.

> Well Object is always THE base class. It may not be known what the actual 
> base class should be and it is certainly not flexible to always create a base 
> class just to have a one to satisfy the rule.

Nor would I suggest that. There are some cases where creating a new class with 
properties is going to make sense, there other in where having the flexibility 
of Object make sense. You may not be aware there a big difference between 
Object and something that extends Object. Objects’s are dynamic and properties 
(and methods) can be added at runtime but this comes at a performance cost. 
Class that extend Object are not dynamic and you can’t do this and as a result 
are faster.

> Justin - If you have clear performance results then please document them in 
> the wiki.

Other people have already researched this and it’s well known AFAIK. For 
example here's an old article by Alex [1] where for accessing properties 
there’s a 20x performance increase. Obviously there’s a little more to it than 
just that but more recent article also have similar results. Object can be 
useful but it does come at a performance cost.

> Thanks. Do you know how to deactivate useless rules?

Yes.

Thanks,
Justin

1. http://blogs.adobe.com/aharui/2007/10/actionscript_readwrite_perform_1.html

Re: [FlexJS] technical debt

[Dave Fisher]

> On Jul 6, 2017, at 4:22 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> - Do we care about code being commented out? I think not.
> 
> If we know why it was commented out sure. There’s always the concern is this 
> code possibly needed or not?

That is the concern, but it may be that the developer was making a speculative 
change. If I were cleaning then I would do one of two actions.

(a) Review the history of that change and see if the associated comments 
provide a reason.
(b) Ask the developer who made the change.

> 
>> - Does a semicolon matter?
> 
> It marked as a minor issue but it can cause issues when JS code is optimised 
> and/or minified. It’s easy and safe to fix.

While very likely safe I think that a question needs to be asked.

> 
>> - Is “:Object” really a critical issue?
> 
> Critical no (and it's not marked as such) and in some cases it’s quite 
> useful. Like all rules there are exceptions. Using a class with named 
> properties gives you type safety and performance benefits.

Well Object is always THE base class. It may not be known what the actual base 
class should be and it is certainly not flexible to always create a base class 
just to have a one to satisfy the rule. I think again it is a question that I 
think was already answered by Alex. IIRC he did not think these warranted a 
different approach.


Justin - If you have clear performance results then please document them in the 
wiki.

> 
>> - Is refactoring “complexity” really a huge problem
> 
> If we want easy to test/easy to maintain code then it can be yes.

This is a question of long term maintenance. My experience in an Agile 
environment is that these changes must be planned otherwise they become break 
fixes. Refactoring must be very carefully done. The author may have this 
complexity there for an unmentioned reason.

> 
>> - This one: Replace == with === : has been discussed and I think your making 
>> the change suggested broke things.
> 
> It didn’t break things in any major way, the tests passed, examples worked 
> and the application I’m working on worked. I believe there was one instance 
> that caused an issue for Harbs.

OK. Well I recall that and I also recall several people doubting that the 
change was needed or necessary. Perhaps both sides could be put on a wiki page.

> 
> There are some other useful rules in there I’ll document them.

Thanks. Do you know how to deactivate useless rules?

> 
>> Probably the best approach would be to collect these into a wiki page and 
>> then determine what conventions developers consider important. Once that is 
>> done change the sonar configuration and show true technical debt. I think 
>> that this is much less risky to the project and much less distraction to the 
>> team.
> 
> Sure I’ll go with that approach.

Wonderful.

Regards,
Dave

> 
> Thanks,
> Justin



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Dave Fisher]

> On Jul 6, 2017, at 4:30 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>>> IMO, even more important than technical debt is a test system and tests to 
>>> make sure any changes don't break anything.
>> 
>> That would include any changes to fix “technical debt”.
> 
> Or if fact any changes right?

If you make a change to fix technical debt then you should also assure that 
both existing tests pass and if no tests exist then tests are added and proper.

As Alex mentions various integration and automation (Selenium) tests also pass. 
In addition there is a.bonus if both Flex and FlexJS are covered.

Regards,
Dave


signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

>> IMO, even more important than technical debt is a test system and tests to 
>> make sure any changes don't break anything.
> 
> That would include any changes to fix “technical debt”.

Or if fact any changes right? 

Thanks,
Justin

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Justin Mclean]

Hi,

BTW Sonar can give you useful test coverage statistics [1] and will even show 
line by line where a test is covered by tests [2] look at the red and green 
bars in the gutter.

Thanks,
Justin

1. 
https://builds.apache.org/analysis/component_measures/domain/Coverage?id=org.apache.flex.flexjs.compiler%3Aflexjs-compiler-parent
2. 
https://builds.apache.org/analysis/component_measures/metric/new_overall_line_coverage/list?id=org.apache.flex.flexjs.compiler%3Aflexjs-compiler-parent

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> - Do we care about code being commented out? I think not.

If we know why it was commented out sure. There’s always the concern is this 
code possibly needed or not?

> - Does a semicolon matter?

It marked as a minor issue but it can cause issues when JS code is optimised 
and/or minified. It’s easy and safe to fix.

> - Is “:Object” really a critical issue?

Critical no (and it's not marked as such) and in some cases it’s quite useful. 
Like all rules there are exceptions. Using a class with named properties gives 
you type safety and performance benefits.

> - Is refactoring “complexity” really a huge problem

If we want easy to test/easy to maintain code then it can be yes.

> - This one: Replace == with === : has been discussed and I think your making 
> the change suggested broke things.

It didn’t break things in any major way, the tests passed, examples worked and 
the application I’m working on worked. I believe there was one instance that 
caused an issue for Harbs.

There are some other useful rules in there I’ll document them.

> Probably the best approach would be to collect these into a wiki page and 
> then determine what conventions developers consider important. Once that is 
> done change the sonar configuration and show true technical debt. I think 
> that this is much less risky to the project and much less distraction to the 
> team.

Sure I’ll go with that approach.

Thanks,
Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> A large percentage of the complaints are inaccurate. The reason the technical 
> debt increased is largely because of the new TLF code.
> 
> Who made these rules and how do we change them? We can make it look much 
> better by just changing some of the rules…

The rules come from various places - CVEs, PMD and generally accepted rules of 
good practice. I have mention several times that they needed some fine tuning.

If you click on the “…” next to a rule it will give you more information 
including in some case where it come from.

Thanks,
Justin

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

[Alex Harui]

I have a subset of Mustella working on both platforms in the BasicTests
that run from the checkintests target in the Ant build.  There is a
writeup on Mustella in the wiki
https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview.  I
haven't gone through it to see how much does or doesn't apply to FlexJS.
The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.  I
basically copied the Flex SDK's BasicTests and modified it a bit to run in
FlexJS and commented out most tests because back when I did it, we didn't
have many components.  It might be interesting to comment more tests back
in and see if they run.

There are some FlexUnit tests that run as part of the Core.swc Ant build,
but only on SWF.

The Maven build runs some Selenium tests that I think are written in Java,
and I think only test JS output.

I haven't invested much time in test infrastructure or test creation since
there were some strong opinions about not liking Mustella and some
thoughts about how to make FlexUnit run on both platforms.

My personal preference is that tests should be written in MXML and/or AS
and run on both platforms.  Bonus points if existing tests can be run
unmodified or mostly unmodified.

-Alex

On 7/6/17, 2:02 PM, "Harbs"  wrote:

>Where are the instructions on how to use it? If I know how to write
>tests, I’d be much better about doing so…
>
>> On Jul 6, 2017, at 11:53 PM, Alex Harui 
>>wrote:
>> 
>> I have put in place a test infrastructure
>

FlexJS Tests (was Re: [FlexJS] technical debt)

[Harbs]

Where are the instructions on how to use it? If I know how to write tests, I’d 
be much better about doing so…

> On Jul 6, 2017, at 11:53 PM, Alex Harui  wrote:
> 
> I have put in place a test infrastructure

Re: [FlexJS] technical debt

[Harbs]

Yup.

For example: I’d say an extremely large percentage of the “technical debt” in 
TLF is there for a reason. Do NOT “fix” any of that…

> On Jul 6, 2017, at 11:53 PM, Alex Harui  wrote:
> 
> But IMO, for right now, if "it ain't broke, don't fix it".

Re: [FlexJS] technical debt

[Alex Harui]

Hi Dave,

There are almost no automated tests for the FlexJS framework.  I have put
in place a test infrastructure, but nobody has volunteered more tests.  So
no test would have caught the "==" to "===" issues, and no tests are going
to catch issues arising from trying to clean up technical debt, if in fact
there is as much as the current tools indicate.

Justin is welcome to write anything he wants in the wiki.  But IMO, for
right now, if "it ain't broke, don't fix it".

Thanks,
-Alex

On 7/6/17, 12:23 PM, "Dave Fisher" <dave2w...@comcast.net> wrote:

>Hi Alex,
>
>> On Jul 6, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID>
>>wrote:
>> 
>> IMO, even more important than technical debt is a test system and tests
>>to make sure any changes don't break anything.
>
>That would include any changes to fix “technical debt”.
>
>> 
>> I could be wrong, but I think our customers would rather have us spend
>>our time and energy on missing features like AMF right now.
>
>I think that users or consumers is a better term than customers.
>
>Missing features is always great.
>
>If Justin’s itch is technical debt then I think he should at least follow
>a wiki approach and also address Harbs comment else thread. If he has
>people from his company do it then that is great too.
>
>Didn’t the blind change from “==“ to “===“ already cause tests to break?
>
>Best Regards,
>Dave
>
>> 
>> My 2 cents,
>> -Alex
>> 
>> From: Dave Fisher <dave2w...@comcast.net<mailto:dave2w...@comcast.net>>
>> Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>"
>><dev@flex.apache.org<mailto:dev@flex.apache.org>>
>> Date: Thursday, July 6, 2017 at 9:24 AM
>> To: "dev@flex.apache.org<mailto:dev@flex.apache.org>"
>><dev@flex.apache.org<mailto:dev@flex.apache.org>>
>> Subject: Re: [FlexJS] technical debt
>> 
>> Hi Justin,
>> 
>> (I missed your double reply until I reviewed the thread before sending.
>>This caused me to remove part of this email.)
>> 
>> I looked at some of the major and minor Code Smells. I think that
>>rather than accepting the ActionScript conventions that Sonar provides
>>that most of these can be eliminated by resetting the rules to match
>>this project’s ideas about how Flex smells.
>> 
>> - Do we care about code being commented out? I think not.
>> - Does a semicolon matter?
>> - Is “:Object” really a critical issue?
>> - Is refactoring “complexity” really a huge problem - Function has a
>>complexity of 14 which is greater than 10 authorized.
>> - This one: Replace == with === : has been discussed and I think your
>>making the change suggested broke things.
>> 
>> Probably the best approach would be to collect these into a wiki page
>>and then determine what conventions developers consider important. Once
>>that is done change the sonar configuration and show true technical
>>debt. I think that this is much less risky to the project and much less
>>distraction to the team.
>> 
>> Only once Sonar rules are properly tuned is it a powerful tool for
>>assuring code quality. Until then it can be a nearly useless sink for
>>scarce developer time and a chance for “hair on fire” concern over
>>“technical debt”.
>> 
>> I agree that like it is it could be a measure of usefulness for new
>>developers in a commercial situation.
>> 
>> Regards,
>> Dave
>> 
>> On Jul 5, 2017, at 11:53 PM, Justin Mclean
>><jus...@classsoftware.com<mailto:jus...@classsoftware.com>> wrote:
>> 
>> Hi,
>> 
>> Dave I assume the case statement issue you referring to is is the last
>>one in this list [1]. It not a bug but style wise it’s a little odd and
>>probably should still be fixed.
>> 
>> Thanks,
>> Justin
>> 
>> 1. 
>>https://builds.apache.org/analysis/component_issues/index?id=org.apache.f
>>lex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severitie
>>s=CRITICAL
>> 
>

Re: [FlexJS] technical debt

[Dave Fisher]

Hi Alex,

> On Jul 6, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
> 
> IMO, even more important than technical debt is a test system and tests to 
> make sure any changes don't break anything.

That would include any changes to fix “technical debt”.

> 
> I could be wrong, but I think our customers would rather have us spend our 
> time and energy on missing features like AMF right now.

I think that users or consumers is a better term than customers.

Missing features is always great.

If Justin’s itch is technical debt then I think he should at least follow a 
wiki approach and also address Harbs comment else thread. If he has people from 
his company do it then that is great too.

Didn’t the blind change from “==“ to “===“ already cause tests to break?

Best Regards,
Dave

> 
> My 2 cents,
> -Alex
> 
> From: Dave Fisher <dave2w...@comcast.net<mailto:dave2w...@comcast.net>>
> Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" 
> <dev@flex.apache.org<mailto:dev@flex.apache.org>>
> Date: Thursday, July 6, 2017 at 9:24 AM
> To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" 
> <dev@flex.apache.org<mailto:dev@flex.apache.org>>
> Subject: Re: [FlexJS] technical debt
> 
> Hi Justin,
> 
> (I missed your double reply until I reviewed the thread before sending. This 
> caused me to remove part of this email.)
> 
> I looked at some of the major and minor Code Smells. I think that rather than 
> accepting the ActionScript conventions that Sonar provides that most of these 
> can be eliminated by resetting the rules to match this project’s ideas about 
> how Flex smells.
> 
> - Do we care about code being commented out? I think not.
> - Does a semicolon matter?
> - Is “:Object” really a critical issue?
> - Is refactoring “complexity” really a huge problem - Function has a 
> complexity of 14 which is greater than 10 authorized.
> - This one: Replace == with === : has been discussed and I think your making 
> the change suggested broke things.
> 
> Probably the best approach would be to collect these into a wiki page and 
> then determine what conventions developers consider important. Once that is 
> done change the sonar configuration and show true technical debt. I think 
> that this is much less risky to the project and much less distraction to the 
> team.
> 
> Only once Sonar rules are properly tuned is it a powerful tool for assuring 
> code quality. Until then it can be a nearly useless sink for scarce developer 
> time and a chance for “hair on fire” concern over “technical debt”.
> 
> I agree that like it is it could be a measure of usefulness for new 
> developers in a commercial situation.
> 
> Regards,
> Dave
> 
> On Jul 5, 2017, at 11:53 PM, Justin Mclean 
> <jus...@classsoftware.com<mailto:jus...@classsoftware.com>> wrote:
> 
> Hi,
> 
> Dave I assume the case statement issue you referring to is is the last one in 
> this list [1]. It not a bug but style wise it’s a little odd and probably 
> should still be fixed.
> 
> Thanks,
> Justin
> 
> 1. 
> https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL
> 



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Harbs]

A large percentage of the complaints are inaccurate. The reason the technical 
debt increased is largely because of the new TLF code.

Who made these rules and how do we change them? We can make it look much better 
by just changing some of the rules…

Harbs

> On Jul 6, 2017, at 2:24 AM, Justin Mclean  wrote:
> 
> Hi,
> 
> If you take a look at this [1] you see that technical debt increased a bit 
> between the 0.8 and 0.9 releases. It would be good if we could reduce this.
> 
> While Sonar cube isn’t perfect, probably needs some tuning, and there are a 
> number of false positives in there it is trying to tell us something.
> 
> Thanks,
> Justin
> 
> 1. https://builds.apache.org/analysis/overview?id=20942

Re: [FlexJS] technical debt

[Alex Harui]

IMO, even more important than technical debt is a test system and tests to make 
sure any changes don't break anything.

I could be wrong, but I think our customers would rather have us spend our time 
and energy on missing features like AMF right now.

My 2 cents,
-Alex

From: Dave Fisher <dave2w...@comcast.net<mailto:dave2w...@comcast.net>>
Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" 
<dev@flex.apache.org<mailto:dev@flex.apache.org>>
Date: Thursday, July 6, 2017 at 9:24 AM
To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" 
<dev@flex.apache.org<mailto:dev@flex.apache.org>>
Subject: Re: [FlexJS] technical debt

Hi Justin,

(I missed your double reply until I reviewed the thread before sending. This 
caused me to remove part of this email.)

I looked at some of the major and minor Code Smells. I think that rather than 
accepting the ActionScript conventions that Sonar provides that most of these 
can be eliminated by resetting the rules to match this project’s ideas about 
how Flex smells.

- Do we care about code being commented out? I think not.
- Does a semicolon matter?
- Is “:Object” really a critical issue?
- Is refactoring “complexity” really a huge problem - Function has a complexity 
of 14 which is greater than 10 authorized.
- This one: Replace == with === : has been discussed and I think your making 
the change suggested broke things.

Probably the best approach would be to collect these into a wiki page and then 
determine what conventions developers consider important. Once that is done 
change the sonar configuration and show true technical debt. I think that this 
is much less risky to the project and much less distraction to the team.

Only once Sonar rules are properly tuned is it a powerful tool for assuring 
code quality. Until then it can be a nearly useless sink for scarce developer 
time and a chance for “hair on fire” concern over “technical debt”.

I agree that like it is it could be a measure of usefulness for new developers 
in a commercial situation.

Regards,
Dave

On Jul 5, 2017, at 11:53 PM, Justin Mclean 
<jus...@classsoftware.com<mailto:jus...@classsoftware.com>> wrote:

Hi,

Dave I assume the case statement issue you referring to is is the last one in 
this list [1]. It not a bug but style wise it’s a little odd and probably 
should still be fixed.

Thanks,
Justin

1. 
https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL

Re: [FlexJS] technical debt

[Dave Fisher]

Hi Justin,

(I missed your double reply until I reviewed the thread before sending. This 
caused me to remove part of this email.)

I looked at some of the major and minor Code Smells. I think that rather than 
accepting the ActionScript conventions that Sonar provides that most of these 
can be eliminated by resetting the rules to match this project’s ideas about 
how Flex smells.

- Do we care about code being commented out? I think not.
- Does a semicolon matter?
- Is “:Object” really a critical issue?
- Is refactoring “complexity” really a huge problem - Function has a complexity 
of 14 which is greater than 10 authorized.
- This one: Replace == with === : has been discussed and I think your making 
the change suggested broke things.

Probably the best approach would be to collect these into a wiki page and then 
determine what conventions developers consider important. Once that is done 
change the sonar configuration and show true technical debt. I think that this 
is much less risky to the project and much less distraction to the team.

Only once Sonar rules are properly tuned is it a powerful tool for assuring 
code quality. Until then it can be a nearly useless sink for scarce developer 
time and a chance for “hair on fire” concern over “technical debt”.

I agree that like it is it could be a measure of usefulness for new developers 
in a commercial situation.

Regards,
Dave

> On Jul 5, 2017, at 11:53 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Dave I assume the case statement issue you referring to is is the last one in 
> this list [1]. It not a bug but style wise it’s a little odd and probably 
> should still be fixed.
> 
> Thanks,
> Justin
> 
> 1. 
> https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL



signature.asc
Description: Message signed with OpenPGP

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

Dave I assume the case statement issue you referring to is is the last one in 
this list [1]. It not a bug but style wise it’s a little odd and probably 
should still be fixed.

Thanks,
Justin

1. 
https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> You cut my previous reply which means I need to repeat.

Why is that? All modern email clients support threaded messages. so people 
should be able to see my email and your original in context. When replying 
repeating the whole email is generally frowned upon. Sorry if I cut too much 
out as finding the middle ground can sometimes be tricky.

Rereading your message perhaps rather than "The singular code smell” you meant 
"This singular code smell”? That line in your email isn’t entirely clear. 

> You called out changes since 0.8. And I only looked at the change since in 
> Sonar. I took about 5 minutes, a very superficial check.
> 
> My point in general was the the recent changes do look pretty clean.

I’m not sure I would call this clean as it added 5,300 odd code smalls (a 41% 
increase to the total) and 89 days of technical debt. [1] The new code had a 
technical debt rating of 19.5% when the technical debt of existing code was 
around 2-3% so that probably indicates something has changed.

We’re still getting a “A” for matainability as we have a lot of small files 
with smallish amount of TD [2], but that could slip into B (5-10%) or even C 
(10-20%) fairly quickly if new changes keep at the current TD rate.

Of course people have different options of what is clean and what isn’t and a 
lot of what Sonar is reporting isn't going to matter so I would certainly 
wouldn't take those numbers too literally.

Thanks,
Justin

1.https://builds.apache.org/analysis/component_issues?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#resolved=false|types=CODE_SMELL|sinceLeakPeriod=true
2. 
https://builds.apache.org/analysis/component_measures/domain/Maintainability?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent

Re: [FlexJS] technical debt

[Dave Fisher]

Hi Justin,

You cut my previous reply which means I need to repeat.

You called out changes since 0.8. And I only looked at the change since in 
Sonar. I took about 5 minutes, a very superficial check.

Lots of TD should be explored carefully hopefully by the original developer.

I agree with the notion that these changes should be at the beginning of a 
cycle.

My point in general was the the recent changes do look pretty clean.

Let's see what the developers think.

Regards,
Dave

Sent from my iPhone

> On Jul 5, 2017, at 6:19 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> In the differential all 30 of the bugs are of the form:
>> 
>> Make this class “Event" override "Event.clone()” function
> 
> Which some are false positives as there’s a cloneEvent method. Note you can 
> mark them as such in the interface. I had already fixed a couple of these a 
> few weeks back.
> 
>> The singular code smell (Sonar says that flex smells very good indeed.)
> 
> Not sure where you seeing just 1 as I can see 13,100 and their are a 
> varieties of issues. Again some worth looking into and others not.
> 
> Thanks,
> Justin

Re: [FlexJS] technical debt

[Justin Mclean]

Hi,

> In the differential all 30 of the bugs are of the form:
> 
> Make this class “Event" override "Event.clone()” function

Which some are false positives as there’s a cloneEvent method. Note you can 
mark them as such in the interface. I had already fixed a couple of these a few 
weeks back.

> The singular code smell (Sonar says that flex smells very good indeed.)

Not sure where you seeing just 1 as I can see 13,100 and their are a varieties 
of issues. Again some worth looking into and others not.

Thanks,
Justin

Re: [FlexJS] technical debt

[Dave Fisher]

Hi -

In the differential all 30 of the bugs are of the form:

Make this class “Event" override "Event.clone()” function

All of the 133 vulnerabilities are of these forms:

Make this "public static" field const
Remove this use of the "trace" function.

The singular code smell (Sonar says that flex smells very good indeed.)

Last statement in this switch-clause should be an unconditional break

This looks like recent work. I’d say it looks pretty good and would be easy to 
address.

I agree with Justin that it is something that all devs should look at from time 
to time.

Regards,
Dave

> On Jul 5, 2017, at 4:24 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> If you take a look at this [1] you see that technical debt increased a bit 
> between the 0.8 and 0.9 releases. It would be good if we could reduce this.
> 
> While Sonar cube isn’t perfect, probably needs some tuning, and there are a 
> number of false positives in there it is trying to tell us something.
> 
> Thanks,
> Justin
> 
> 1. https://builds.apache.org/analysis/overview?id=20942



signature.asc
Description: Message signed with OpenPGP

[FlexJS] technical debt

[Justin Mclean]

Hi,

If you take a look at this [1] you see that technical debt increased a bit 
between the 0.8 and 0.9 releases. It would be good if we could reduce this.

While Sonar cube isn’t perfect, probably needs some tuning, and there are a 
number of false positives in there it is trying to tell us something.

Thanks,
Justin

1. https://builds.apache.org/analysis/overview?id=20942