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 <adrian.f.c...@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 <aphill...@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" <notificati...@github.com>
>>> Date: Oct 8, 2014 4:51 PM
>>> Subject: Re: [jclouds] cinder availability zones api + list call
>>> implemented (#560)
>>> To: "jclouds/jclouds" <jclo...@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.

Reply via email to