You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Cloud Delivery Platform — Thought Model

I was asked to take a look at a thought model for a Cloud Delivery Platform. I’m not going to post that graphic, because it wasn’t ready for prime time. It was confused and I’m not really sure what it was trying to show. So I created a bit of a diagram showing what I thought was important. (Just click on it, it doesn’t seem to fit right, and the next size down is too small to read.)

cloud_delivery_platform

Halfway through I realized I’m not terribly good at making these things. I’ll get better. But there’s a few things I wanted to draw attention to in this graphic.

The Roles

This was the most important thing to me is to highlight the crossover of roles for each step. There are few steps in the process that should be perfomed by a single role. Devops is about communication.

Local Development

Coding, building, testing, packaging are all things that should be done at the same time. You don’t code 1000 lines then build. You build with every small change. In the same way, you should have tests written with the small increments. And that gets extended to “packaging”.

Packaging

I’m probably missing a very important word in my vocabulary here, but I’m going to go easy on myself, it’s late. What I’m meaning here is the process of setting up an image, or a deployable product. The configuration that will collect external dependencies and run tests when it gets to the deployed environment. This should all be done locally first. It should all be put into version control, separate from the application code. And this needs to be done in collaboration between the developer, who knows the application, and operations (or as they’ve been renamed in my organization, “Devops Engineers”) those who know how to package things appropriately.

Local Concurrence vs Cloud Linearity

Why isn’t spell check underlining “linearity”. That can’t be real. As I mentioned before, the things done locally are all done at the same time (build, test, package). That’s all just development. When it gets to the cloud, it’s a done product. Nothing should be further developed there. Nothing should be getting reworked. Everything needs to come entirely from Version Control and no manual finagling. (obviously?) So the cloud portion is linear. Everything happens in order. If it fails at any point, it’s sent back to local dev and fixed there.
Maybe this is all so obvious, it doesn’t need to be said. Maybe I’d feel better if it were just said anyway.

Posted in Continuous Integration, Uncategorized, Version Control. Tags: , , , , , , , . Comments Off on Cloud Delivery Platform — Thought Model »

Mobility Workshop

gold stick figures sitting together working on their gold laptopsA couple of months ago, we had a very successful presentation on vagrant/puppet. Given by a developer, it sparked motivation in some devops enthusiasts to give a workshop. It went really well. (Vagrant Tutorial)

They had a great format with their workshops that seemed effective. They were super enthusiastic, which translated to super prepared. They had created a wordpress post that was a very detailed, step by step instruction on getting started.

The interest and effectiveness of this sparked motivation to do “other topics”. So I put together this tutorial on mobile development, “featuring jQuery Mobile”.

I thought the idea of something where I had the material prepared beforehand and could just say “go” was a great place to start. This shouldn’t be a presentation, it should be an opportunity for people to get their hands dirty.

I was running through tutorials and found a lot of them had put their code on github. At some point I had the idea to use branches to “step” through the tutorial. The way I envisioned the workshop going was to start with nothing, and build out a mobile app through logical steps — as a lot of tutorials do. Do a header, do a menu, do a list, do a link, do a transition, do a search. Coming up with a list of “things to do” was easy.

Putting it together with github also meant I could just put the directions in the base readme and it would be a completely self-contained tutorial. (Not to mention, having it in git allowed me to force people who I know don’t want to make the switch out of SVN to use a VCS that is so much nicer.)

Anyway, the finished draft took a long time. It was a lot of easy stuff, but time consuming.

(Mobility Workshop)

The most important part came after the draft was finished. I gathered some team members and some cross-team members — basically whoever would come sit with me and had them run through it to see if it made sense. They were brutal. It was great. A lot of this work happened after hours, so the language was at times, very stream of consciousness. Having people with varied familiarity with the topics covered allowed for some invaluable revisions.

Overall, the workshop proved to be a wonderful exercise in collaboration and teamwork, and regardless of how the actual workshop goes, it has left me better than I started, so that’s good enough.

Posted in Design & Modeling, Development, Open Source. Tags: , , , , , , , . Comments Off on Mobility Workshop »

Peer Review, Peer Grading

With all the talk of MOOCs (edX / Coursera), I’ve been very interested in finding more information on peer review. So I’ve been reading the studies that espouse the benefits of peer review in general.

Duke Chronicle: Peer grading experiment a success, professor says
Mostly older articles via google

And the pitfalls:
How accurate is peer grading?

A couple years ago I was put in charge of working with UCLA’s Calibrated Peer Review for Eric Mazur. He was really excited about it — I was less so. But my problem was I was looking at the application, not the concept. Just because an application is overdeveloped drivel doesn’t mean what they were trying to do isn’t awesome. I’m of the thinking they should have simplified it. That seems to be the case with just about everything I see. Applications shouldn’t be as complicated as they’re made. The problem is there are usually too many people involved in a project’s inception and everyone needs to put a piece of themselves into it. But I digress. edX will be great.

I don’t think Mazur used the CPR for more than 2 semesters. Probably because there was too much overhead and it wasn’t intuitive enough. But a poor implementation doesn’t mean a poor idea.

Or at least that’s my theory on this. I hadn’t seen any progress with online implementations of this, people haven’t been pushing this teaching technique yet and it’s disappointing (or telling).

Coursera is making a run at it now. That is encouraging. That means edX will probably follow suit with a similar implementation. And I’m planning a mild implementation with Quizmo.

Posted in ATG, Quizmo. Tags: , , , , , , . Comments Off on Peer Review, Peer Grading »