I was talking with Tory Adams @BEZEI2K about working with Orchestrate‘s Services. We’re totally sold on what they offer and are looking forward to a lot of the technology that is in the works. The day to day building against Orchestrate is super easy, and setting up collections for dev or test or whatever are so easy nothing has stood in our way. Except one thing…
Every once in a while we have to work disconnected. For whatever the reason might be; Comcast cable goes out, we decide to jump on a train or one of us ends up on one of those Q400 puddle jumpers that doesn’t have wifi! But regardless of being disconnected from wifi, cable or internet connectivity we still want to be able to code and test!
In Memory Orchestrate Wrapper
Enter the idea of creating an in memory Orchestrate database wrapper. Using something like convict.js one could easily redirect all the connections as necessary when developing locally. That way development continues right along and when the application is pushed live, it’s redirected to the appropriate Orchestrate connections and keys!
This in memory “fake” or “mock” would need to have the key value, events, and graph store setup just like Orchestrate. With the possibility of having this in memory one could also easily write tests against a real fake and be able to test connected or disconnected without mocking. Not to say that’s a good or bad idea, but just one more tool in the tool chest doesn’t hurt!
If something like this doesn’t pop up in the next week or three, I might just have to kick off this project myself! If anybody is interested please reach out to me and let’s discuss! I’m open to writing it in JavaScript, C#, Java or whatever poison pill you’d prefer. (I’m not polyglot to limit my options!!)
Other Ideas, Development Shop Swap
Another idea that I’ve been pondering is setting up a development shop swap. I’ll leave the reader to determine what that means! 😉 Feel free to throw down ideas that this might bring up and I’ll incorporate that into the soon to be implementation. I’ll have more information about that idea right here once the project gets rolling. In the meantime, happy coding!
Love the idea of a dev shop swap. I interpret that like this: two dev shops at different companies swap developers for a day/week/etc. To bring in a different perspective to the code, or bring in expertise that you don’t have on staff, etc.
This will work great if there’s a lot of trust (no worry about IP sharing, probably need NDAs in place), and if the pair of devs provides mutual benefit (eg, non-overlapping expertise).
Looking forward to it!
Good concerns to bring up, regarding IP sharing, NDAs and related issues. Some shops I think could probably mitigate these issues easily, some not so much. Whatever the case it’d be something the tool should definitely work to make as easy as possible to mitigate concerns and help people cross over to other companies and expand their learning and experience.
Something like that would be really useful for those of us doing dev work for local governments. And the NDAs would only need to go one way, since we don’t have a product to sell. Fitting people into the workflow quickly could be a challenge, but if it were planned out in advance, I’m sure it would be very valuable!
Workflow is one of the big on the ground questions.
I vote in node.js to begin with. For the Memory Wrapper.
Maybe Go maybe Node? Many options…! 🙂
I’m down for either, maybe leaning towards Go since I haven’t gotten to do anything beyond “Hello World” type stuff in it yet.
Ditto. That’s my same thought.
I built something similar into the orchestrate-rails ruby gem to facilitate development. But it is really more of an in-memory cache to persist data while the application is running. I initially put it in to eliminate redundant GET calls while in dev/test mode. Since all of the PUT requests are cached as well, saving them for ‘replay’ later would pretty much accomplish what you describe. So I’ll probably do that pretty soon. This has been on my list – thanks for the inspirational push!
Of course, this only solves the problem if you’re developing in ruby. Building a more general-purpose wrapper would be really useful!
Also, I implemented tests using VCR, which can be really helpful if you have some pre-recorded test results when working offline.
Fun stuff!
I was looking at VCR myself recently. With this project I think we’ll aim to write it in Go. I spoke with Matt (twitter @roder) about it and he suggested that to enable a multi-OS binary, etc. So that may be an interesting approach to take. Will pull more people together soon and get a real discussion going. I’m aiming to do so sometime this weekend.
I like the idea of a dev swap, sort of an externship, but I think that it would be very challenging. There is always a productivity hit when you bring a new developer onto a project and it can take awhile for a new dev to up to speed enough to really help a project. It varies from project to project and dev to dev, but those time considerations mean that you are probably looking at weeks on a project, which might be difficult. Still a good idea, just have to think about logistics.
I love your use of the word externship. I may have to co-opt for use in any code base I start putting together. 🙂
Developer swaps are a great idea. They’ve been happening for a few years now (the first ones were in 2009). Here is a write-up of the plans for the first one: http://blog.8thlight.com/paul-pagel/2009/03/19/software-journeyman-program.html
The Chicago Tribune also wrote an article about them: http://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectives
As I know it, there are a handful of shops who regularly do these. They’ve had a lot of benefits from them.
Excellent links Corey. Thanks for posting those! 🙂
When I get rolling on this idea more, I’ll definitely reach out. After all, some of your code camping was part of the nexus of this idea. 😉