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

Mobility Workshop

April 27, 2014 — JaZahn

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 »

noSQL vs Relational DB

June 26, 2013 — JaZahn

There are a billion articles on this, but having read half of them, I’d like to vomit what I’ve taken away as important from them.

Relational databases are integral to any software developer. We’ve been working with them since day 1 of our career. Now comes mongoDB and the appengine Datastore, and there is a ton of hype behind it. But what are the actual benefits?

The big thing you lose with noSQL is joins. If you’re not doing joins noSQL will probably outperform a relational db. So if you don’t need reporting, if there’s no complexity needed for the data, noSQL is actually a fine solution. That’s not to say you can’t do joins. They’re just different and much slower to perform. So you end up with a bunch of data redundancy, which makes changes to that redundant data much more difficult, but eh, if that data barely ever changes, it ain’t no thang.

Another thing you lose that are the constraints on data, foreign keys, data type constraints. All of that has to be handled in the application layer. Which it should be anyway, but having a second line of defense for validation is nice. We all tend to think in terms of objects. Set objects with clear constraints, so having things set from the get go is understandable. The gain of data amorphism, I haven’t really been able to imagine a real world situation where that’s an actual plus.. which could be due to lack of imagination because that’s what I’ve done forever.

The big thing you gain with noSQL is ‘elastic scaling’. When a relational db starts to get huge, the db gets bigger. The single server that’s running the db has to be bigger and badder, and all replication has to be just as big. With noSQL, you can break up the data between servers. This is especially useful in the cloud, and when trying to cut costs in general. 5 small-medium servers can be dirt cheap compared to 1 huge server.

Posted in Databases, Design & Modeling. Tags: , , , , , . 1 Comment »

Back in Time with PHP

December 16, 2012 — JaZahn

I recently had the opportunity to work on a PHP application that was written by a student in 2004. Before the time of PHP frameworks and separation of MVC, when applications had SQL and HTML in the same files. Each page was a form that submitted to itself. Everything contained in one file per page. Pretty crazy, right?

Crazy like awesome. I had so much fun working on features for this old application. It wasn’t just nostalgic, it was like comfort food. Easy and delicious. I’m not really sure how comfort food is “easy”, but just go with it. I was practically begging to do more work on it.

I can’t imagine myself creating a new application like this from scratch, but I’ve been thinking about the benefits. Anyone with just a tiny bit of PHP experience could pick it up and maintain it, there’s no technology ramp-up time. A project like this could be orphaned and passed around between anyone. It could be used to teach people basic PHP within the organization. Say, people who are so Java-centric they refuse to learn anything new or different.

It was a good opportunity to take a look at the past and see what we’ve lost by going forward with technology.

Posted in Design & Modeling, Development, PHP. Tags: , . Comments Off on Back in Time with PHP »

Agile Documentation and Research Stories

November 2, 2012 — JaZahn

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

Posted in Agile, ATG, Design & Modeling, Development, Uncategorized. Tags: , . Comments Off on Agile Documentation and Research Stories »
«
»