2013-04-24
OpenStack Meeting times
If you are interested in joining in on the OpenStack discussions the meetings are documented here. They are conducted online in IRC forums or alternatively in Valhalla. I've created this Google Calendar feed from the wiki docs... but I make no guarantee that this feed will stay up to date other than this is the one I personally use to keep on top of things. Also, Valhalla is a bit of a schlep.
2013-04-17
OpenStack and you...
I'm only a few weeks old in the OpenStack community and I can tell you that this is by far the most democratic open-source project I've ever seen. Typically there is a project owner who for better or worse is the guy you have to please. Let's call him "benevolent dictator for life" or BDL for short.
In most of my experience the trick is to get the BDL's attention and approval. If the BDL doesn't like you for whatever reason, you can GTFO. That's not how OpenStack works.
The OpenStack community has a lovely welcome guide (warning: pdf) and they also give you free candy. In the community process, anyone can bring proposals to the design summit and the community both online and physically present discuss change proposals and enhancements for the coming release. What's special about this process is anyone could propose a design change to OpenStack.
When I mean anyone, I mean anyone. You could represent a billion-dollar behemoth or you could be from a local shop that runs its own datacenter which just happens to want to donate developer time.
When I've been lucky enough to get to do open-source work as my day-job that's the kind of situation I would have been in myself: the day job is deliver web-site X but to do that you shave the yak of open-source bug-fixing. Much of my Grails work came out of me using the framework during my day job (living on the JVM and wanting python-like good-ness) and shaving the yaks of qrcode support, database migrations, SSL certificate issues, audit-log creation, and so on. That's how a lot of the smaller open source contributions (like mine) get done.
That kind of rubber-meets-the-road contributions keeps an open source project "real" and keeps it serving users where they live. For the first time I'm working full-time on the vSphere Nova Compute Driver. I'm taking over for Sean Chen and I want to stay on top of issues.
I'm officially soliciting feedback and input from the OpenStack + vSphere community. Let me know what's going on and what I can do to help you. And in open-source spirit, I don't care if you are a tiny shop or a huge one... let's see your code.
In most of my experience the trick is to get the BDL's attention and approval. If the BDL doesn't like you for whatever reason, you can GTFO. That's not how OpenStack works.
The OpenStack community has a lovely welcome guide (warning: pdf) and they also give you free candy. In the community process, anyone can bring proposals to the design summit and the community both online and physically present discuss change proposals and enhancements for the coming release. What's special about this process is anyone could propose a design change to OpenStack.
When I mean anyone, I mean anyone. You could represent a billion-dollar behemoth or you could be from a local shop that runs its own datacenter which just happens to want to donate developer time.
When I've been lucky enough to get to do open-source work as my day-job that's the kind of situation I would have been in myself: the day job is deliver web-site X but to do that you shave the yak of open-source bug-fixing. Much of my Grails work came out of me using the framework during my day job (living on the JVM and wanting python-like good-ness) and shaving the yaks of qrcode support, database migrations, SSL certificate issues, audit-log creation, and so on. That's how a lot of the smaller open source contributions (like mine) get done.
That kind of rubber-meets-the-road contributions keeps an open source project "real" and keeps it serving users where they live. For the first time I'm working full-time on the vSphere Nova Compute Driver. I'm taking over for Sean Chen and I want to stay on top of issues.
I'm officially soliciting feedback and input from the OpenStack + vSphere community. Let me know what's going on and what I can do to help you. And in open-source spirit, I don't care if you are a tiny shop or a huge one... let's see your code.
2013-04-11
Attending OpenStack Summit 2013 in Portland, Oregon
I've officially joined the OpenStack effort here at VMware. To that end I'll be shifting my OpenSource efforts to support OpenStack related tools. That means I'll be shifting my posting habits and be talking about more OpenStack related work here in this blog.
If you are interested in bumping into me in Portland, here's my Summit Profile. It's early days for me yet on OpenStack and there is a lot of momentum building. I'm sure we're in for a wild ride!
If you are interested in bumping into me in Portland, here's my Summit Profile. It's early days for me yet on OpenStack and there is a lot of momentum building. I'm sure we're in for a wild ride!
2013-01-10
Groovy and SOAP and the JVM
As I'm working out SOAP + Langauge du jour problems I continue to be impressed with the utility embedded in the JVM.
Rarely do you get to develop software in a completely greenfield project. Most of us have to integrate our software with other systems and that often means dealing with SOAP. I asked about what people are doing with Groovy + SOAP over at Google+ and had a few side conversations with folks.
It turns out that when forced to deal with the abject insanity that is SOAP, most Groovy users drop back and pick up those Java tools like JAX-WS. It's tools like these that keep developers coming back to the JVM and that Java to Groovy integration story is still one of the best stories going for Groovy.
In part, you have to wonder if ... in order to understand SOAP's madness you don't need a little madness to get the job done. This insanity might have to continue to exist in practical long-lived projects for quite some time. Keeping that madness bottled up in some pre-baked libraries is honestly the best thing you can do for your own continued sanity and the sanity of your own projects.
Rarely do you get to develop software in a completely greenfield project. Most of us have to integrate our software with other systems and that often means dealing with SOAP. I asked about what people are doing with Groovy + SOAP over at Google+ and had a few side conversations with folks.
It turns out that when forced to deal with the abject insanity that is SOAP, most Groovy users drop back and pick up those Java tools like JAX-WS. It's tools like these that keep developers coming back to the JVM and that Java to Groovy integration story is still one of the best stories going for Groovy.
In part, you have to wonder if ... in order to understand SOAP's madness you don't need a little madness to get the job done. This insanity might have to continue to exist in practical long-lived projects for quite some time. Keeping that madness bottled up in some pre-baked libraries is honestly the best thing you can do for your own continued sanity and the sanity of your own projects.
2012-09-14
Code Samples and the argument for WET versus DRY
In my new role at VMware I've been tasked with writing new code samples for the various API that have been created for supporting the Ecosystem around VMware's product line. This has been a very different experience for me.
I practice the principle of Don't Repeat Yourself (DRY) in most of the code I've produced during my career. In the last few years I've adopted Test Driven Development (TDD) as well as other techniques that make sense. In creating code samples most of these things still apply but DRY sort of doesn't.
The purpose of code samples is to highlight the use of the API and the target user is a programmer that is in a hurry. A methodical and slow programmer wouldn't necessarily even need samples since they would read documentation and work out via TDD the necessary information for how to use the API themselves. So my work with samples is for the developer who won't even necessarily stop to turn their attention to documents.
That means there is a need to Wholly Express our Terms (WET). In other words, if I happen to make my code too DRY there is opportunity for the learning programmer to miss vital steps. The solution to this is to choose things to repeat very carefully. This actually creates code repetition I would not want in a production system but should not completely brush aside code reuse.
The trick is to package steps up into reusable units that are easy to compose but are still expressed in an end product. In a nonsense and non NDA violating example:
Hopefully we get to demonstrate some salient parts of an algorithm leaning on services to the end user. If I have to repeat the lines for how to get 's' and 'o' over and over, this is not so bad as repeating the contents of doThing0 and doThing1 over and over. The argument can still be made that by being WET (which also means Write Everything Twice) we are being instructional.
Conversely, we could argue that DRY code should still be used here since any good coder should be able to trace back the compositions and decompose what happened. The trick with balancing WET and DRY in a code sample is to recall that we are not writing a framework or a library or even a prototype. The purpose of a code sample is to document.
So I'm learning where to balance WET versus DRY in this game of writing code samples. I tend to prefer making the mistake of making things too DRY as opposed to too WET since this means I will have fewer things to think about in the future.
Incidentally, one of the things I would normally avoid is inheritance but I feel in the case of code samples it plays very well since I can say "this algorithm I'm showing you is a variation of ... " which is probably very instructive. In another system I might have use Functional thinking paradigms instead. Remember, I'm trying to keep a low bar in these samples and avoiding the temptation to teach both the API and Functional Programming at the same time. The goal is not to introduce too many hurdles.
Do you disagree with me? Should I just use all the best practices I know and force my sample reader to climb to my level? Am I condescending by making my code samples WET assuming too low a bar for the new developer? Your feedback is welcome.
I practice the principle of Don't Repeat Yourself (DRY) in most of the code I've produced during my career. In the last few years I've adopted Test Driven Development (TDD) as well as other techniques that make sense. In creating code samples most of these things still apply but DRY sort of doesn't.
The purpose of code samples is to highlight the use of the API and the target user is a programmer that is in a hurry. A methodical and slow programmer wouldn't necessarily even need samples since they would read documentation and work out via TDD the necessary information for how to use the API themselves. So my work with samples is for the developer who won't even necessarily stop to turn their attention to documents.
That means there is a need to Wholly Express our Terms (WET). In other words, if I happen to make my code too DRY there is opportunity for the learning programmer to miss vital steps. The solution to this is to choose things to repeat very carefully. This actually creates code repetition I would not want in a production system but should not completely brush aside code reuse.
The trick is to package steps up into reusable units that are easy to compose but are still expressed in an end product. In a nonsense and non NDA violating example:
class Frobnicator extends Thingicator {
public void frobnicate() {
Something s = someService.doThing0();
Otherthing o = someOtherService.doThing1(s);
Anotherthing a = someService.doThing2(s,o);
someBinding.doTheThing(s,o,a);
}
}
Hopefully we get to demonstrate some salient parts of an algorithm leaning on services to the end user. If I have to repeat the lines for how to get 's' and 'o' over and over, this is not so bad as repeating the contents of doThing0 and doThing1 over and over. The argument can still be made that by being WET (which also means Write Everything Twice) we are being instructional.
Conversely, we could argue that DRY code should still be used here since any good coder should be able to trace back the compositions and decompose what happened. The trick with balancing WET and DRY in a code sample is to recall that we are not writing a framework or a library or even a prototype. The purpose of a code sample is to document.
So I'm learning where to balance WET versus DRY in this game of writing code samples. I tend to prefer making the mistake of making things too DRY as opposed to too WET since this means I will have fewer things to think about in the future.
Incidentally, one of the things I would normally avoid is inheritance but I feel in the case of code samples it plays very well since I can say "this algorithm I'm showing you is a variation of ... " which is probably very instructive. In another system I might have use Functional thinking paradigms instead. Remember, I'm trying to keep a low bar in these samples and avoiding the temptation to teach both the API and Functional Programming at the same time. The goal is not to introduce too many hurdles.
Do you disagree with me? Should I just use all the best practices I know and force my sample reader to climb to my level? Am I condescending by making my code samples WET assuming too low a bar for the new developer? Your feedback is welcome.
2012-07-31
Grails Plugin Testing Strategies
I've been maintaining Grails plugins for years now both on the wild-wild web and in private enterprise-only plugins. In this talk at GR8Conf I shared stories from that history, the problems I encountered and how I solved them. Grails 2.x offers us so much in the way of testing and mocking we can now get rid of a lot of the crazy things I used to do to test my plugins.
Ultimately, however, when you do things at the persistence layer you need to do a full integration test with the database since there's no real way to substitute for a real database. So my advice is to avoid at all costs dipping down any lower in the architecture than you absolutely have to. Good plugin testing starts with good plugin design... design to test.
And if you do manage to do something naughty (as I often seem to want to do) then you should make sure you have lots of safety net underneath you with a rich testing environment all around your code.
for code shown, see also:
Ultimately, however, when you do things at the persistence layer you need to do a full integration test with the database since there's no real way to substitute for a real database. So my advice is to avoid at all costs dipping down any lower in the architecture than you absolutely have to. Good plugin testing starts with good plugin design... design to test.
And if you do manage to do something naughty (as I often seem to want to do) then you should make sure you have lots of safety net underneath you with a rich testing environment all around your code.
for code shown, see also:
- https://github.com/hartsock/grails-audit-logging-plugin/tree/v100_beta
- https://github.com/hartsock/grails-qrcode
2012-07-30
Groovy Integration Patterns or The Grobnicating Frobnicator
I just gave the Groovy Integration Patterns talk at GR8Conf.us otherwise known as the Grobnicating Frobnicator talk. Where I take us on a journey through techniques on introducing Groovy into Enterprisey environments, along the way I take a really brief foray into the "Planet of the Monkey Patches" where we discuss some interesting interactions you can do with Groovy embedded in a mostly Java application. Then we move into the world of multi-tennant Java applications that can leverage Groovy and Groovy DSL to swap out function in configuration or dynamically at run-time.
The code is over at https://github.com/hartsock/groovy-integration-patterns
The code is over at https://github.com/hartsock/groovy-integration-patterns
Subscribe to:
Posts (Atom)