You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <ap...@qrmedia.com> on 2014/10/09 04:11:20 UTC
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
> I will volunteer to undebt one provider for each provider someone else
> volunteers for. Anyone with me?
I'm up! Any specific one that you feel would be a good example?
Before we start, though: do we have an up-to-date list of what we
consider Good Practice and what we want to clean up here? I fully
sympathize with Inbar, but I think part of the problem here is that
beyond copy-pasting existing code I don't think we have anything
outside of people's heads that describes what we're actually looking
for. The few dev guides we have [1, 2, 3] certainly aren't enough.
I obviously would love to be a position where all code has been
cleaned up to the point that copy-paste is in line with the jclouds
State Of The Art. Even if that is not the case, it would at least be
great if contributors could have somewhere to go for advice. And we
should probably agree that we'll prefer current guidelines over
consistency with the rest of an older codebase.
Getting back to this one: draft of what we're looking for?
* MWS tests
* No abstract builders
* Use Objects.equal in equals()
* Move common @Path to top of interface
* private, error-throwing constructors for domain objects created by builders
Is this the kind of stuff you have in mind? I'm just looking the PR by
Inbar that triggered this here...
Regards
ap
[1] https://wiki.apache.org/jclouds/Coding%20Standards
[2] https://wiki.apache.org/jclouds/Best%20Practices
[3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>
> -A
> ---------- Forwarded message ----------
> From: "inbar stolberg" <no...@github.com>
> Date: Oct 8, 2014 4:51 PM
> Subject: Re: [jclouds] cinder availability zones api + list call
> implemented (#560)
> To: "jclouds/jclouds" <jc...@noreply.github.com>
> Cc:
>
> In
> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>
>> + * See the License for the specific language governing permissions and
>> + * limitations under the License.
>> + */
>> +
>> +package org.jclouds.openstack.cinder.v1.extensions;
>> +
>> +/**
>> + * Extension namespaces
>> + */
>> +public final class ExtensionNamespaces {
>> +
>> + /**
>> + * Admin Action extension
>> + */
>> + public static final String ADMIN_ACTIONS =
>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>> +
>
> 90% of this code is copy paste of existing code from the same branch not
> old code either ...
> I have no problem fixing this but doesnt seem like there is cosistency in
> the code if i can copy paste some thing and get rejected over 100 lines....
> :/
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>
--
Andrew Phillips
qrmedia
Unless expressly stated otherwise, this message is confidential.
Access to this e-mail by anyone else is unauthorised. If you are
not an addressee, any disclosure or copying of the contents of
this e-mail or any action taken (or not taken) in reliance on it
is unauthorised and may be unlawful. If you are not an addressee,
please inform the sender immediately.
This message is confidential and may not be redistributed or
broadcast in whole or part in any form, including but not limited
to any form of internet transmission including email, usenet,
newsgroups, www, irc, icq, etc.
All liability for errors and viruses is disclaimed.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Ignasi Barrera <na...@apache.org>.
+1000 to this proposal. It's time to get our hands dirty and clean up our
technical debt with the same energy Adrian had this weekend when
unasynching.
Andrew's list seems to be a good starting one, and I'd only add:
* Recover the essence of labs. For *all* labs repos. If they're peoduction
ready, promote. Otherwise change aggressively. Deprecation makes no sense
there and we should push providers to be promoted or deleted. TTL in labs
has to be limited.
This said, I volunteer to cleanup (refactoring all tests and all mentioned):
* chef
* digitalocean (this is pretty clean, Adrian, mind having a look to use it
as a reference?)
* cloudsigma
* elasrichosts
* abiquo
Let's get things done.
El 09/10/2014 05:35, "Adrian Cole" <ad...@gmail.com> escribió:
> https://github.com/rcoedo/assertj-mws/issues/1
>
> On Wed, Oct 8, 2014 at 8:29 PM, Adrian Cole <ad...@gmail.com>
> wrote:
> > You'll notice there's very little code to author an assertion (<200
> > lines in this case), so I'm not sure it is worthwhile making a
> > dependency, bothering someone to publish to maven and keep it current.
> > That said, this one is nicely written and actually includes tests...
> > tough call.
> >
> > On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
> >> Roman Coedo started on assertj-mws; could you share some feedback with
> >> him?
> >>
> >> https://github.com/rcoedo/assertj-mws
> >>
> >> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
> >>> Also, I think we waste breath on some things that we haven't really
> >>> started doing.
> >>>
> >>> Ex. if I had to say that in a unit test, we prefer assert
> >>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
> >>>
> >>> One thing I would love to see is to start using Truth or assertj which
> >>> have fluent ways to act on things like collections without one wanting
> >>> to cut themselves. For example, we could generate assertj assertions
> >>> for our common models, which could make things like MockWebServer,
> >>> BlobStore, FluentIterable, etc. assertions far more delightful to
> >>> write.
> >>>
> >>> -A
> >>>
> >>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com>
> wrote:
> >>> > I think google looks to be in pretty good shape, including
> appropriate
> >>> > use of weird builder
> >>> >
> >>> > ex. weird builder is kindof ok when there exists a base resource from
> >>> > which everything else is derived. ex Resource vs Instance.
> >>> >
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
> >>> >
> >>> > However, things not sensible to extend have concrete builders.
> >>> >
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
> >>> >
> >>> > I haven't reviewed through all of google, but each time I've
> >>> > accidentally entered, it has looked pretty good.
> >>> >
> >>> > -A
> >>> >
> >>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <
> aphillips@qrmedia.com> wrote:
> >>> >>> I will volunteer to undebt one provider for each provider someone
> else
> >>> >>> volunteers for. Anyone with me?
> >>> >>
> >>> >>
> >>> >> I'm up! Any specific one that you feel would be a good example?
> >>> >>
> >>> >> Before we start, though: do we have an up-to-date list of what we
> consider
> >>> >> Good Practice and what we want to clean up here? I fully sympathize
> with
> >>> >> Inbar, but I think part of the problem here is that beyond
> copy-pasting
> >>> >> existing code I don't think we have anything outside of people's
> heads that
> >>> >> describes what we're actually looking for. The few dev guides we
> have [1, 2,
> >>> >> 3] certainly aren't enough.
> >>> >>
> >>> >> I obviously would love to be a position where all code has been
> cleaned up
> >>> >> to the point that copy-paste is in line with the jclouds State Of
> The Art.
> >>> >> Even if that is not the case, it would at least be great if
> contributors
> >>> >> could have somewhere to go for advice. And we should probably agree
> that
> >>> >> we'll prefer current guidelines over consistency with the rest of
> an older
> >>> >> codebase.
> >>> >>
> >>> >> Getting back to this one: draft of what we're looking for?
> >>> >>
> >>> >> * MWS tests
> >>> >> * No abstract builders
> >>> >> * Use Objects.equal in equals()
> >>> >> * Move common @Path to top of interface
> >>> >> * private, error-throwing constructors for domain objects created by
> >>> >> builders
> >>> >>
> >>> >> Is this the kind of stuff you have in mind? I'm just looking the PR
> by Inbar
> >>> >> that triggered this here...
> >>> >>
> >>> >> Regards
> >>> >>
> >>> >> ap
> >>> >>
> >>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> >>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
> >>> >> [3]
> https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
> >>> >>
> >>> >>
> >>> >>
> >>> >>>
> >>> >>> -A
> >>> >>> ---------- Forwarded message ----------
> >>> >>> From: "inbar stolberg" <no...@github.com>
> >>> >>> Date: Oct 8, 2014 4:51 PM
> >>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
> >>> >>> implemented (#560)
> >>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
> >>> >>> Cc:
> >>> >>>
> >>> >>> In
> >>> >>>
> >>> >>>
> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
> >>> >>>
> >>> >>>> + * See the License for the specific language governing
> permissions and
> >>> >>>> + * limitations under the License.
> >>> >>>> + */
> >>> >>>> +
> >>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
> >>> >>>> +
> >>> >>>> +/**
> >>> >>>> + * Extension namespaces
> >>> >>>> + */
> >>> >>>> +public final class ExtensionNamespaces {
> >>> >>>> +
> >>> >>>> + /**
> >>> >>>> + * Admin Action extension
> >>> >>>> + */
> >>> >>>> + public static final String ADMIN_ACTIONS =
> >>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> >>> >>>> +
> >>> >>>
> >>> >>>
> >>> >>> 90% of this code is copy paste of existing code from the same
> branch not
> >>> >>> old code either ...
> >>> >>> I have no problem fixing this but doesnt seem like there is
> cosistency in
> >>> >>> the code if i can copy paste some thing and get rejected over 100
> >>> >>> lines....
> >>> >>> :/
> >>> >>>
> >>> >>> —
> >>> >>> Reply to this email directly or view it on GitHub
> >>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Andrew Phillips
> >>> >> qrmedia
> >>> >>
> >>> >> Unless expressly stated otherwise, this message is confidential.
> >>> >> Access to this e-mail by anyone else is unauthorised. If you are
> >>> >> not an addressee, any disclosure or copying of the contents of
> >>> >> this e-mail or any action taken (or not taken) in reliance on it
> >>> >> is unauthorised and may be unlawful. If you are not an addressee,
> >>> >> please inform the sender immediately.
> >>> >>
> >>> >> This message is confidential and may not be redistributed or
> >>> >> broadcast in whole or part in any form, including but not limited
> >>> >> to any form of internet transmission including email, usenet,
> >>> >> newsgroups, www, irc, icq, etc.
> >>> >> All liability for errors and viruses is disclaimed.
> >>
> >> --
> >> Andrew Gaul
> >> http://gaul.org/
>
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
https://github.com/rcoedo/assertj-mws/issues/1
On Wed, Oct 8, 2014 at 8:29 PM, Adrian Cole <ad...@gmail.com> wrote:
> You'll notice there's very little code to author an assertion (<200
> lines in this case), so I'm not sure it is worthwhile making a
> dependency, bothering someone to publish to maven and keep it current.
> That said, this one is nicely written and actually includes tests...
> tough call.
>
> On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
>> Roman Coedo started on assertj-mws; could you share some feedback with
>> him?
>>
>> https://github.com/rcoedo/assertj-mws
>>
>> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
>>> Also, I think we waste breath on some things that we haven't really
>>> started doing.
>>>
>>> Ex. if I had to say that in a unit test, we prefer assert
>>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>>>
>>> One thing I would love to see is to start using Truth or assertj which
>>> have fluent ways to act on things like collections without one wanting
>>> to cut themselves. For example, we could generate assertj assertions
>>> for our common models, which could make things like MockWebServer,
>>> BlobStore, FluentIterable, etc. assertions far more delightful to
>>> write.
>>>
>>> -A
>>>
>>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
>>> > I think google looks to be in pretty good shape, including appropriate
>>> > use of weird builder
>>> >
>>> > ex. weird builder is kindof ok when there exists a base resource from
>>> > which everything else is derived. ex Resource vs Instance.
>>> >
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>>> >
>>> > However, things not sensible to extend have concrete builders.
>>> >
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>>> >
>>> > I haven't reviewed through all of google, but each time I've
>>> > accidentally entered, it has looked pretty good.
>>> >
>>> > -A
>>> >
>>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> >>> I will volunteer to undebt one provider for each provider someone else
>>> >>> volunteers for. Anyone with me?
>>> >>
>>> >>
>>> >> I'm up! Any specific one that you feel would be a good example?
>>> >>
>>> >> Before we start, though: do we have an up-to-date list of what we consider
>>> >> Good Practice and what we want to clean up here? I fully sympathize with
>>> >> Inbar, but I think part of the problem here is that beyond copy-pasting
>>> >> existing code I don't think we have anything outside of people's heads that
>>> >> describes what we're actually looking for. The few dev guides we have [1, 2,
>>> >> 3] certainly aren't enough.
>>> >>
>>> >> I obviously would love to be a position where all code has been cleaned up
>>> >> to the point that copy-paste is in line with the jclouds State Of The Art.
>>> >> Even if that is not the case, it would at least be great if contributors
>>> >> could have somewhere to go for advice. And we should probably agree that
>>> >> we'll prefer current guidelines over consistency with the rest of an older
>>> >> codebase.
>>> >>
>>> >> Getting back to this one: draft of what we're looking for?
>>> >>
>>> >> * MWS tests
>>> >> * No abstract builders
>>> >> * Use Objects.equal in equals()
>>> >> * Move common @Path to top of interface
>>> >> * private, error-throwing constructors for domain objects created by
>>> >> builders
>>> >>
>>> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>>> >> that triggered this here...
>>> >>
>>> >> Regards
>>> >>
>>> >> ap
>>> >>
>>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
>>> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> -A
>>> >>> ---------- Forwarded message ----------
>>> >>> From: "inbar stolberg" <no...@github.com>
>>> >>> Date: Oct 8, 2014 4:51 PM
>>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
>>> >>> implemented (#560)
>>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>>> >>> Cc:
>>> >>>
>>> >>> In
>>> >>>
>>> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>> >>>
>>> >>>> + * See the License for the specific language governing permissions and
>>> >>>> + * limitations under the License.
>>> >>>> + */
>>> >>>> +
>>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>> >>>> +
>>> >>>> +/**
>>> >>>> + * Extension namespaces
>>> >>>> + */
>>> >>>> +public final class ExtensionNamespaces {
>>> >>>> +
>>> >>>> + /**
>>> >>>> + * Admin Action extension
>>> >>>> + */
>>> >>>> + public static final String ADMIN_ACTIONS =
>>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>> >>>> +
>>> >>>
>>> >>>
>>> >>> 90% of this code is copy paste of existing code from the same branch not
>>> >>> old code either ...
>>> >>> I have no problem fixing this but doesnt seem like there is cosistency in
>>> >>> the code if i can copy paste some thing and get rejected over 100
>>> >>> lines....
>>> >>> :/
>>> >>>
>>> >>> —
>>> >>> Reply to this email directly or view it on GitHub
>>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Andrew Phillips
>>> >> qrmedia
>>> >>
>>> >> Unless expressly stated otherwise, this message is confidential.
>>> >> Access to this e-mail by anyone else is unauthorised. If you are
>>> >> not an addressee, any disclosure or copying of the contents of
>>> >> this e-mail or any action taken (or not taken) in reliance on it
>>> >> is unauthorised and may be unlawful. If you are not an addressee,
>>> >> please inform the sender immediately.
>>> >>
>>> >> This message is confidential and may not be redistributed or
>>> >> broadcast in whole or part in any form, including but not limited
>>> >> to any form of internet transmission including email, usenet,
>>> >> newsgroups, www, irc, icq, etc.
>>> >> All liability for errors and viruses is disclaimed.
>>
>> --
>> Andrew Gaul
>> http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
You'll notice there's very little code to author an assertion (<200
lines in this case), so I'm not sure it is worthwhile making a
dependency, bothering someone to publish to maven and keep it current.
That said, this one is nicely written and actually includes tests...
tough call.
On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
> Roman Coedo started on assertj-mws; could you share some feedback with
> him?
>
> https://github.com/rcoedo/assertj-mws
>
> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
>> Also, I think we waste breath on some things that we haven't really
>> started doing.
>>
>> Ex. if I had to say that in a unit test, we prefer assert
>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>>
>> One thing I would love to see is to start using Truth or assertj which
>> have fluent ways to act on things like collections without one wanting
>> to cut themselves. For example, we could generate assertj assertions
>> for our common models, which could make things like MockWebServer,
>> BlobStore, FluentIterable, etc. assertions far more delightful to
>> write.
>>
>> -A
>>
>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
>> > I think google looks to be in pretty good shape, including appropriate
>> > use of weird builder
>> >
>> > ex. weird builder is kindof ok when there exists a base resource from
>> > which everything else is derived. ex Resource vs Instance.
>> >
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>> >
>> > However, things not sensible to extend have concrete builders.
>> >
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>> >
>> > I haven't reviewed through all of google, but each time I've
>> > accidentally entered, it has looked pretty good.
>> >
>> > -A
>> >
>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> >>> I will volunteer to undebt one provider for each provider someone else
>> >>> volunteers for. Anyone with me?
>> >>
>> >>
>> >> I'm up! Any specific one that you feel would be a good example?
>> >>
>> >> Before we start, though: do we have an up-to-date list of what we consider
>> >> Good Practice and what we want to clean up here? I fully sympathize with
>> >> Inbar, but I think part of the problem here is that beyond copy-pasting
>> >> existing code I don't think we have anything outside of people's heads that
>> >> describes what we're actually looking for. The few dev guides we have [1, 2,
>> >> 3] certainly aren't enough.
>> >>
>> >> I obviously would love to be a position where all code has been cleaned up
>> >> to the point that copy-paste is in line with the jclouds State Of The Art.
>> >> Even if that is not the case, it would at least be great if contributors
>> >> could have somewhere to go for advice. And we should probably agree that
>> >> we'll prefer current guidelines over consistency with the rest of an older
>> >> codebase.
>> >>
>> >> Getting back to this one: draft of what we're looking for?
>> >>
>> >> * MWS tests
>> >> * No abstract builders
>> >> * Use Objects.equal in equals()
>> >> * Move common @Path to top of interface
>> >> * private, error-throwing constructors for domain objects created by
>> >> builders
>> >>
>> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>> >> that triggered this here...
>> >>
>> >> Regards
>> >>
>> >> ap
>> >>
>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
>> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>> >>
>> >>
>> >>
>> >>>
>> >>> -A
>> >>> ---------- Forwarded message ----------
>> >>> From: "inbar stolberg" <no...@github.com>
>> >>> Date: Oct 8, 2014 4:51 PM
>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
>> >>> implemented (#560)
>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>> >>> Cc:
>> >>>
>> >>> In
>> >>>
>> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>> >>>
>> >>>> + * See the License for the specific language governing permissions and
>> >>>> + * limitations under the License.
>> >>>> + */
>> >>>> +
>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
>> >>>> +
>> >>>> +/**
>> >>>> + * Extension namespaces
>> >>>> + */
>> >>>> +public final class ExtensionNamespaces {
>> >>>> +
>> >>>> + /**
>> >>>> + * Admin Action extension
>> >>>> + */
>> >>>> + public static final String ADMIN_ACTIONS =
>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>> >>>> +
>> >>>
>> >>>
>> >>> 90% of this code is copy paste of existing code from the same branch not
>> >>> old code either ...
>> >>> I have no problem fixing this but doesnt seem like there is cosistency in
>> >>> the code if i can copy paste some thing and get rejected over 100
>> >>> lines....
>> >>> :/
>> >>>
>> >>> —
>> >>> Reply to this email directly or view it on GitHub
>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Andrew Phillips
>> >> qrmedia
>> >>
>> >> Unless expressly stated otherwise, this message is confidential.
>> >> Access to this e-mail by anyone else is unauthorised. If you are
>> >> not an addressee, any disclosure or copying of the contents of
>> >> this e-mail or any action taken (or not taken) in reliance on it
>> >> is unauthorised and may be unlawful. If you are not an addressee,
>> >> please inform the sender immediately.
>> >>
>> >> This message is confidential and may not be redistributed or
>> >> broadcast in whole or part in any form, including but not limited
>> >> to any form of internet transmission including email, usenet,
>> >> newsgroups, www, irc, icq, etc.
>> >> All liability for errors and viruses is disclaimed.
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Andrew Gaul <ga...@apache.org>.
Roman Coedo started on assertj-mws; could you share some feedback with
him?
https://github.com/rcoedo/assertj-mws
On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
> Also, I think we waste breath on some things that we haven't really
> started doing.
>
> Ex. if I had to say that in a unit test, we prefer assert
> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>
> One thing I would love to see is to start using Truth or assertj which
> have fluent ways to act on things like collections without one wanting
> to cut themselves. For example, we could generate assertj assertions
> for our common models, which could make things like MockWebServer,
> BlobStore, FluentIterable, etc. assertions far more delightful to
> write.
>
> -A
>
> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
> > I think google looks to be in pretty good shape, including appropriate
> > use of weird builder
> >
> > ex. weird builder is kindof ok when there exists a base resource from
> > which everything else is derived. ex Resource vs Instance.
> >
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
> >
> > However, things not sensible to extend have concrete builders.
> >
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
> >
> > I haven't reviewed through all of google, but each time I've
> > accidentally entered, it has looked pretty good.
> >
> > -A
> >
> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
> >>> I will volunteer to undebt one provider for each provider someone else
> >>> volunteers for. Anyone with me?
> >>
> >>
> >> I'm up! Any specific one that you feel would be a good example?
> >>
> >> Before we start, though: do we have an up-to-date list of what we consider
> >> Good Practice and what we want to clean up here? I fully sympathize with
> >> Inbar, but I think part of the problem here is that beyond copy-pasting
> >> existing code I don't think we have anything outside of people's heads that
> >> describes what we're actually looking for. The few dev guides we have [1, 2,
> >> 3] certainly aren't enough.
> >>
> >> I obviously would love to be a position where all code has been cleaned up
> >> to the point that copy-paste is in line with the jclouds State Of The Art.
> >> Even if that is not the case, it would at least be great if contributors
> >> could have somewhere to go for advice. And we should probably agree that
> >> we'll prefer current guidelines over consistency with the rest of an older
> >> codebase.
> >>
> >> Getting back to this one: draft of what we're looking for?
> >>
> >> * MWS tests
> >> * No abstract builders
> >> * Use Objects.equal in equals()
> >> * Move common @Path to top of interface
> >> * private, error-throwing constructors for domain objects created by
> >> builders
> >>
> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
> >> that triggered this here...
> >>
> >> Regards
> >>
> >> ap
> >>
> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
> >>
> >>
> >>
> >>>
> >>> -A
> >>> ---------- Forwarded message ----------
> >>> From: "inbar stolberg" <no...@github.com>
> >>> Date: Oct 8, 2014 4:51 PM
> >>> Subject: Re: [jclouds] cinder availability zones api + list call
> >>> implemented (#560)
> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
> >>> Cc:
> >>>
> >>> In
> >>>
> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
> >>>
> >>>> + * See the License for the specific language governing permissions and
> >>>> + * limitations under the License.
> >>>> + */
> >>>> +
> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
> >>>> +
> >>>> +/**
> >>>> + * Extension namespaces
> >>>> + */
> >>>> +public final class ExtensionNamespaces {
> >>>> +
> >>>> + /**
> >>>> + * Admin Action extension
> >>>> + */
> >>>> + public static final String ADMIN_ACTIONS =
> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> >>>> +
> >>>
> >>>
> >>> 90% of this code is copy paste of existing code from the same branch not
> >>> old code either ...
> >>> I have no problem fixing this but doesnt seem like there is cosistency in
> >>> the code if i can copy paste some thing and get rejected over 100
> >>> lines....
> >>> :/
> >>>
> >>> —
> >>> Reply to this email directly or view it on GitHub
> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
> >>>
> >>
> >>
> >>
> >> --
> >> Andrew Phillips
> >> qrmedia
> >>
> >> Unless expressly stated otherwise, this message is confidential.
> >> Access to this e-mail by anyone else is unauthorised. If you are
> >> not an addressee, any disclosure or copying of the contents of
> >> this e-mail or any action taken (or not taken) in reliance on it
> >> is unauthorised and may be unlawful. If you are not an addressee,
> >> please inform the sender immediately.
> >>
> >> This message is confidential and may not be redistributed or
> >> broadcast in whole or part in any form, including but not limited
> >> to any form of internet transmission including email, usenet,
> >> newsgroups, www, irc, icq, etc.
> >> All liability for errors and viruses is disclaimed.
--
Andrew Gaul
http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
Also, I think we waste breath on some things that we haven't really
started doing.
Ex. if I had to say that in a unit test, we prefer assert
!list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
One thing I would love to see is to start using Truth or assertj which
have fluent ways to act on things like collections without one wanting
to cut themselves. For example, we could generate assertj assertions
for our common models, which could make things like MockWebServer,
BlobStore, FluentIterable, etc. assertions far more delightful to
write.
-A
On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
> I think google looks to be in pretty good shape, including appropriate
> use of weird builder
>
> ex. weird builder is kindof ok when there exists a base resource from
> which everything else is derived. ex Resource vs Instance.
>
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>
> However, things not sensible to extend have concrete builders.
>
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>
> I haven't reviewed through all of google, but each time I've
> accidentally entered, it has looked pretty good.
>
> -A
>
> On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> I will volunteer to undebt one provider for each provider someone else
>>> volunteers for. Anyone with me?
>>
>>
>> I'm up! Any specific one that you feel would be a good example?
>>
>> Before we start, though: do we have an up-to-date list of what we consider
>> Good Practice and what we want to clean up here? I fully sympathize with
>> Inbar, but I think part of the problem here is that beyond copy-pasting
>> existing code I don't think we have anything outside of people's heads that
>> describes what we're actually looking for. The few dev guides we have [1, 2,
>> 3] certainly aren't enough.
>>
>> I obviously would love to be a position where all code has been cleaned up
>> to the point that copy-paste is in line with the jclouds State Of The Art.
>> Even if that is not the case, it would at least be great if contributors
>> could have somewhere to go for advice. And we should probably agree that
>> we'll prefer current guidelines over consistency with the rest of an older
>> codebase.
>>
>> Getting back to this one: draft of what we're looking for?
>>
>> * MWS tests
>> * No abstract builders
>> * Use Objects.equal in equals()
>> * Move common @Path to top of interface
>> * private, error-throwing constructors for domain objects created by
>> builders
>>
>> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>> that triggered this here...
>>
>> Regards
>>
>> ap
>>
>> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>> [2] https://wiki.apache.org/jclouds/Best%20Practices
>> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>>
>>
>>
>>>
>>> -A
>>> ---------- Forwarded message ----------
>>> From: "inbar stolberg" <no...@github.com>
>>> Date: Oct 8, 2014 4:51 PM
>>> Subject: Re: [jclouds] cinder availability zones api + list call
>>> implemented (#560)
>>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>>> Cc:
>>>
>>> In
>>>
>>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>>
>>>> + * See the License for the specific language governing permissions and
>>>> + * limitations under the License.
>>>> + */
>>>> +
>>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>>> +
>>>> +/**
>>>> + * Extension namespaces
>>>> + */
>>>> +public final class ExtensionNamespaces {
>>>> +
>>>> + /**
>>>> + * Admin Action extension
>>>> + */
>>>> + public static final String ADMIN_ACTIONS =
>>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>>> +
>>>
>>>
>>> 90% of this code is copy paste of existing code from the same branch not
>>> old code either ...
>>> I have no problem fixing this but doesnt seem like there is cosistency in
>>> the code if i can copy paste some thing and get rejected over 100
>>> lines....
>>> :/
>>>
>>> —
>>> Reply to this email directly or view it on GitHub
>>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>>
>>
>>
>>
>> --
>> Andrew Phillips
>> qrmedia
>>
>> Unless expressly stated otherwise, this message is confidential.
>> Access to this e-mail by anyone else is unauthorised. If you are
>> not an addressee, any disclosure or copying of the contents of
>> this e-mail or any action taken (or not taken) in reliance on it
>> is unauthorised and may be unlawful. If you are not an addressee,
>> please inform the sender immediately.
>>
>> This message is confidential and may not be redistributed or
>> broadcast in whole or part in any form, including but not limited
>> to any form of internet transmission including email, usenet,
>> newsgroups, www, irc, icq, etc.
>> All liability for errors and viruses is disclaimed.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
I think google looks to be in pretty good shape, including appropriate
use of weird builder
ex. weird builder is kindof ok when there exists a base resource from
which everything else is derived. ex Resource vs Instance.
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
However, things not sensible to extend have concrete builders.
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
I haven't reviewed through all of google, but each time I've
accidentally entered, it has looked pretty good.
-A
On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> I will volunteer to undebt one provider for each provider someone else
>> volunteers for. Anyone with me?
>
>
> I'm up! Any specific one that you feel would be a good example?
>
> Before we start, though: do we have an up-to-date list of what we consider
> Good Practice and what we want to clean up here? I fully sympathize with
> Inbar, but I think part of the problem here is that beyond copy-pasting
> existing code I don't think we have anything outside of people's heads that
> describes what we're actually looking for. The few dev guides we have [1, 2,
> 3] certainly aren't enough.
>
> I obviously would love to be a position where all code has been cleaned up
> to the point that copy-paste is in line with the jclouds State Of The Art.
> Even if that is not the case, it would at least be great if contributors
> could have somewhere to go for advice. And we should probably agree that
> we'll prefer current guidelines over consistency with the rest of an older
> codebase.
>
> Getting back to this one: draft of what we're looking for?
>
> * MWS tests
> * No abstract builders
> * Use Objects.equal in equals()
> * Move common @Path to top of interface
> * private, error-throwing constructors for domain objects created by
> builders
>
> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
> that triggered this here...
>
> Regards
>
> ap
>
> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> [2] https://wiki.apache.org/jclouds/Best%20Practices
> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>
>
>
>>
>> -A
>> ---------- Forwarded message ----------
>> From: "inbar stolberg" <no...@github.com>
>> Date: Oct 8, 2014 4:51 PM
>> Subject: Re: [jclouds] cinder availability zones api + list call
>> implemented (#560)
>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>> Cc:
>>
>> In
>>
>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>
>>> + * See the License for the specific language governing permissions and
>>> + * limitations under the License.
>>> + */
>>> +
>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>> +
>>> +/**
>>> + * Extension namespaces
>>> + */
>>> +public final class ExtensionNamespaces {
>>> +
>>> + /**
>>> + * Admin Action extension
>>> + */
>>> + public static final String ADMIN_ACTIONS =
>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>> +
>>
>>
>> 90% of this code is copy paste of existing code from the same branch not
>> old code either ...
>> I have no problem fixing this but doesnt seem like there is cosistency in
>> the code if i can copy paste some thing and get rejected over 100
>> lines....
>> :/
>>
>> —
>> Reply to this email directly or view it on GitHub
>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>
>
>
>
> --
> Andrew Phillips
> qrmedia
>
> Unless expressly stated otherwise, this message is confidential.
> Access to this e-mail by anyone else is unauthorised. If you are
> not an addressee, any disclosure or copying of the contents of
> this e-mail or any action taken (or not taken) in reliance on it
> is unauthorised and may be unlawful. If you are not an addressee,
> please inform the sender immediately.
>
> This message is confidential and may not be redistributed or
> broadcast in whole or part in any form, including but not limited
> to any form of internet transmission including email, usenet,
> newsgroups, www, irc, icq, etc.
> All liability for errors and viruses is disclaimed.