Re: [ANN] juju-core 1.13.2 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/13 13:17, David Cheney wrote: Thanks John. James -- I have uploaded the release tarball now, sorry about the delay, I was in an airplane. No problem; juju-core 1.13.2 also uploaded to Saucy. Cheers James - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJSGxsTAAoJEL/srsug59jDoYwQAMKovqEhdrY8BdrHNZZWjnXx O/DH+SPpbIyyvdLqiuURpAjMXfTrUW9sOOYPmT0L/3KxokyDLvXsYJTau+v1S2m7 0yZIG8qWkMA5CBzgUoMd1tdxbJWIYEdpKvEaJaMypgB5KBZaJMSA5ZruyQwZXLM5 wgJXxRxGDXrJqfazrD+j6t+Mexd3PaFB2LWpla0HdqLXc2nAjn7ltGz7euWJNB3E n56R9J3YoFPQwUnHUnW63iCIjiBzh02A2wS72rao/V/3rCRIrR5moPRf2Y8edr+g wURt4jSD49h0KfNciz5FMTjms08txLXla/zfSP2T8Gb/Dbptf0zznuw5YCV1WeJG 5MGm9QD9SKi3kvd9hKMXLgHJxZOw0ilsorO/nLDP3wEMTM/x2O8gaOaB0YkAht2g PaiJOfIXwpVZRuZmOYufvCutozO3s755zy99QRTvQMb2/SRTnRM2I9GHgkJWgNKX Bw0l0mQjHNL9CNhcug/obrWFIgNlGUBcz6cQo2d5VH3qa3hK0PnYmiy1mzVvFz3/ HJxV6FEB8VUdjrsqpzYdkGXWpD0qXlodaTBrXKJyrY/6/Z+hgS7tsxjjfh/cOEnw GH3564WvZYWMeFI2WKhXaVoyD/FC+Go5MtKR2Z1Y9nb3QQ/sR4vgeIBQlUuthyPs KxwNytIEP+nDYg2YEr9x =iqal -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
api.Client().ServiceGet() and int types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm implementing juju get via the API. In doing so, I moved over one of our tests which did (pseudocode) set value=int64(0) DeepEquals(result, value) And it used to work when ServiceGet was connecting directly to State. Now that it goes via the API, the value is now a float64 (probably because of JSON deserialization). My guess is that the Mongo BSON type encodes int64 directly, but that is lost when going via the JSON rpc. So do we care? Are int types preserved in the rest of the system? I'm guessing this will effect charms when they grab their settings. However, can charms be strict about this today? John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIbkSgACgkQJdeBCYSNAAN2AwCgi7+/oJtlywwAFqcNuW9NdcxM y3IAoIvrVLruv0nmIcvjH1GjGvoxP+gg =tQB9 -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: [ANN] juju-core 1.13.2 has been released
James, Thanks for uploading to Saucy. Julian/David, I see the fix is committed We'll need to cut another release this week for any remaining Azure fixes in preparation for the announcement next week. David, could you confirm with Julian on when is the correct time to cut another devel release? Also when is the next stable release slated for (mid september)? -thanks, Antonio On Mon, Aug 26, 2013 at 4:08 AM, James Page james.p...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/13 13:17, David Cheney wrote: Thanks John. James -- I have uploaded the release tarball now, sorry about the delay, I was in an airplane. No problem; juju-core 1.13.2 also uploaded to Saucy. Cheers James - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJSGxsTAAoJEL/srsug59jDoYwQAMKovqEhdrY8BdrHNZZWjnXx O/DH+SPpbIyyvdLqiuURpAjMXfTrUW9sOOYPmT0L/3KxokyDLvXsYJTau+v1S2m7 0yZIG8qWkMA5CBzgUoMd1tdxbJWIYEdpKvEaJaMypgB5KBZaJMSA5ZruyQwZXLM5 wgJXxRxGDXrJqfazrD+j6t+Mexd3PaFB2LWpla0HdqLXc2nAjn7ltGz7euWJNB3E n56R9J3YoFPQwUnHUnW63iCIjiBzh02A2wS72rao/V/3rCRIrR5moPRf2Y8edr+g wURt4jSD49h0KfNciz5FMTjms08txLXla/zfSP2T8Gb/Dbptf0zznuw5YCV1WeJG 5MGm9QD9SKi3kvd9hKMXLgHJxZOw0ilsorO/nLDP3wEMTM/x2O8gaOaB0YkAht2g PaiJOfIXwpVZRuZmOYufvCutozO3s755zy99QRTvQMb2/SRTnRM2I9GHgkJWgNKX Bw0l0mQjHNL9CNhcug/obrWFIgNlGUBcz6cQo2d5VH3qa3hK0PnYmiy1mzVvFz3/ HJxV6FEB8VUdjrsqpzYdkGXWpD0qXlodaTBrXKJyrY/6/Z+hgS7tsxjjfh/cOEnw GH3564WvZYWMeFI2WKhXaVoyD/FC+Go5MtKR2Z1Y9nb3QQ/sR4vgeIBQlUuthyPs KxwNytIEP+nDYg2YEr9x =iqal -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Antonio Rosales Ubuntu Cloud Ecosystem Engineering juju.ubuntu.com/charm-championship - Share your infrastructure, win 10k! -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Policies for coding
On 23/08/13 21:37, roger peppe wrote: On 23 August 2013 04:11, Tim Penhey tim.pen...@canonical.com wrote: // TODO (thumper): 2013-08-23 bug 1654321 // Details about the change needed, or things to do. This seems reasonable, but there's one down side - currently for most TODOs, a grep will pull out both the TODO and its description, whereas this will lose that. Perhaps we could do it this other way around? // TODO (thumper) Details about the change needed // 2013-08-23 bug 1654321 It depends on what you think is the more important information. Also, as William mentions, there are many places where the details are multi-line. It makes sense to have the defined structure on the first line, and the rest is the details. Secondly, I propose the following guideline: Prefer exporting functions and interfaces to structures - unless there is a very good reason why the structure should be exported. A common example of a structure that should be exported is a params type structure that groups parameters for another exported function. By exporting interfaces, we have more ability to mock the behaviour for testing, and to change implementation details without impacting all the users of the code. I don't quite get this. There's nothing about *returning* an interface that makes more easily mockable, AFAICS. The thing that makes things easier to mock is that *parameters* are interfaces, as narrow as possible for the code in question. Doing things this way makes it the responsibility of each piece of code to enable itself to be mocked, while allowing it to present the most natural API possible to its clients. OK, there are several key problems we are trying to solve, and the general policy specified above is trying to address the problems, not be some religious, carved-in-stone, hard rule. A concrete example that I've been working on is the agent config. The exposed type, with all public data members, tied the implementation details to the use of the object. Getting the agent config to be provided by an interface, so we can change how the config is stored was an epic task because of the creep of public data poking. If you expose a structure with all public data, and have methods that rely on the relationship between data members, then you have a problem (as we did with agent config). I'm not saying that exporting structures is always bad. I'm saying that it is often bad. As William's example demonstrated, we don't want pointers to structures to be returned from interface methods (unless the structures are plain old data type structures). If you have exported structures with private members, you can't easily generate them from other packages. A key issue here is data hiding. Go gives us a great facility to do this using interfaces. For example, in the Go library, bufio.NewReader returns a concrete type, not an interface, but many methods and functions will accept an io.Reader interface value, which happens to be implemented by bufio.Reader. This is idiomatic Go, and I think it can work well. Yes this can be fine, but for very small, well defined types. A lot of juju-core doesn't fit this model. Let's not try to say oh, this is idiomatic Go so we should always do this in juju-core, because that way lies a world of hurt. There are some design patterns for large scale software that is generally used no matter what language you are writing it. Moreover some types really don't need to be mocked, as they're easily created on the fly and their methods don't rely on anything other than the data contained within them. Would there be any advantage in, for example, passing constraints.Value around as an interface? As I said above, the policy is prefer. Since constraints.Value is more of a value type, and public only data, it is easily constructable and not tightly coupled to other things. This is considered good programming practice. I'm concerned that this statement is much more true in a Java-centric world than a Go-centric one. Information hiding and abstracting implementation details from use is pretty general. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Clean Code and single character variable names
Hi all, If you haven't yet, please get a copy of Clean Code [1] as we will be starting reviews of it soon. I have found a reference in that book that pretty clearly describes my dislike for single character variable names. I type that section here. Avoid Mental Mapping [2] Readers shouldn't have to mentally translate your names into other names they already know. This problem generally arises from a choice to use neither problem domain terms nor solution domain terms. This is a problem with single-letter variable names. Certainly a loop counter may be named i or j or k (although never l!) if its scope is very small and no other names can conflict with it. This is because those single-letter names for loop counters are traditional. However, in most other contexts a single-letter name is a poor choice; it's just a place holder that the reader must mentally map to the actual concept. There can be no worse reason for using the name c than because a and b were already taken. In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. After all, if you can reliably remember that r is the lower-cased version of the url with the host and scheme removed, then you must clearly be very smart. One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand. Sometimes I feel that Go developers are trying to show off how smart they are by preferring single character variable names. This has been beaten (most often verbally) out of most other professional programming groups I have worked with. Saying that using single character variables is idiomatic Go just makes me sad, and says to me that idiomatic Go is all about being smart and not professional. Tim [1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 [2] page 25, Clean Code -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Null provider and failing early
On Tue, Aug 27, 2013 at 8:44 AM, Tim Penhey tim.pen...@canonical.comwrote: Perhaps we should have a sanity-check type callback into the provider with the constraints at the time we want to add a machine. This would give the null provider the early fail mechanism, and could also allow other providers to error if people as asking for constraints that really don't make sense. I'm sort of thinking out aloud here: maybe this could used for checking environment-specific constraints too? Some kind of VerifyMachineConstraints method that will ensure your add-machine/--to constraints are valid for the current provider/environment. In this case constraints may be nil, but the null provider would just always return false. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Clean Code and single character variable names
I don't have time to properly respond, but I'm pretty sure no one on this team is using single letter variables to save keystrokes. Is is a good point that abbreviations may be more common in one area than another. I find both ctx and txn to be completely self explanatory even with zero context (heh). On Aug 26, 2013 8:33 PM, Julian Edwards julian.edwa...@canonical.com wrote: On 27/08/13 09:26, Andrew Wilkins wrote: Traditionally I've also avoided abbreviated names (preferring context over ctx, transaction over tx/txn). I'm not 100% convinced that this is necessary, though, in these cases where there's a *conventional* and obvious abbreviation. I mean, ctx is pretty obvious. c not so much (though I use c a *lot* in llgo to shorten compiler; not great, but at least I'm pretty consistent about it, so it's a project-specific convention). YMMV. I find txn far more obvious than ctx. Talking of c, I was astounded the first time I found a struct called C being used in juju tests. Minimising cognitive overhead is more important than saving a few keystrokes. I believe this is exactly what Tim is trying to say :) -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Null provider and failing early
On 27/08/13 11:50, Andrew Wilkins wrote: On Tue, Aug 27, 2013 at 8:44 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Perhaps we should have a sanity-check type callback into the provider with the constraints at the time we want to add a machine. This would give the null provider the early fail mechanism, and could also allow other providers to error if people as asking for constraints that really don't make sense. I'm sort of thinking out aloud here: maybe this could used for checking environment-specific constraints too? Some kind of VerifyMachineConstraints method that will ensure your add-machine/--to constraints are valid for the current provider/environment. In this case constraints may be nil, but the null provider would just always return false. This is exactly what I'm thinking as well, but I had forgotten about the provider specific constraints. It does raise the question of what should happen if a provider specific constraint is passed to a provider that can't handle it. My suggestion is we fail. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Null provider and failing early
I think they should be ignored, but preserved. On Tue, Aug 27, 2013 at 11:40 AM, Tim Penhey tim.pen...@canonical.com wrote: On 27/08/13 11:50, Andrew Wilkins wrote: On Tue, Aug 27, 2013 at 8:44 AM, Tim Penhey tim.pen...@canonical.com mailto:tim.pen...@canonical.com wrote: Perhaps we should have a sanity-check type callback into the provider with the constraints at the time we want to add a machine. This would give the null provider the early fail mechanism, and could also allow other providers to error if people as asking for constraints that really don't make sense. I'm sort of thinking out aloud here: maybe this could used for checking environment-specific constraints too? Some kind of VerifyMachineConstraints method that will ensure your add-machine/--to constraints are valid for the current provider/environment. In this case constraints may be nil, but the null provider would just always return false. This is exactly what I'm thinking as well, but I had forgotten about the provider specific constraints. It does raise the question of what should happen if a provider specific constraint is passed to a provider that can't handle it. My suggestion is we fail. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Policies for coding
On 27/08/13 15:30, Gustavo Niemeyer wrote: On Mon, Aug 26, 2013 at 11:50 PM, Tim Penhey tim.pen...@canonical.com wrote: On 27/08/13 14:33, Gustavo Niemeyer wrote: On Mon, Aug 26, 2013 at 8:03 PM, Tim Penhey tim.pen...@canonical.com wrote: Information hiding and abstracting implementation details from use is pretty general. Go has private variables, private constants, private types, private functions, private methods, private fields, and private constants. None of that depends on interfaces. You are completely missing the point that was being illustrated. The comments were made with awareness of your underlying point. See the prior emails in the thread. You are making no sense. Also, Go doesn't have private anything, unless by private you mean that anything in the package can touch anything else in the package. We are talking about the problems of creating complicated structs with private members from different packages. Exactly, and this is a broad convention that ignores what the types are, and whether it makes any sense to use an interface for them or not. The tone of this thread also broadens this even further: Prefer exporting functions and interfaces to structures - unless there is a very good reason why the structure should be exported. I can't see why you are arguing against a preference. I'm not saying do this unthinkingly. Just that interfaces as a communication mechanism between packages is preferred. Yes this can be fine, but for very small, well defined types. It can be fine for a wide variety of types, as you can find out throughout the standard library and in lots of other projects out there. Large complex software systems are different to libraries. The standard library is a significant body of code that implements the http server and client that backs dl.google.com. It has a TLS implementation, an ssh server and client, template languages, regular expression support, a parser/scanner/formatter/printer/builder/ast for the Go language, and so many other non-trivial things. I didn't say that libraries are trivial. A lot of our own pain has come about how WE use Go. Not Go itself. juju-core separates things into internal packages. We test using different packages so we test the interfaces to the package. I'm trying to come up with some general guidelines that help the juju-core developers make juju better, faster, with better tests. Thinking We know better. We're doing large complex systems. is a dangerous trap. It's buying a pass to do large complex stuff that ignores prior experience. Actually ignoring the experience of the developers you have on the team who have built large successful systems in the past is equally stupid. I struggle to understand why you thing preferring interfaces for package boundaries is large complex stuff ? And I'll show you how to use a tape turing machine. This isn't the point. That's actually the point. Twisting Go to look more like X (C++, tape, whatever) isn't solving problems. Right. I'm trying to use facilities that Go has to solve our problems. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
