Communicating complex ideas is always a challenge. That applies especially to technical descriptions. What if I told you I want a database that stores information from a scan? I might say there are Deb packages, users, and files, and you should store the state of each. You might ask me how they should be connected. We might spend lots of time typing back and forth, using English. But why spend that time, when “a picture is worth a thousand words”?
Behold our first attempt at documenting a database schema!
Yes, that is a bit hard to read. Fear not, we used draw.io to generate XML for this schema. See instructions in our docs/README to open this file in the draw.io editor. The file you want to open is DB_Tables.xml.
It seems we can benefit already from using Docker. For instance, if I can bring up my entire stack with one command, it will make it far easier for everyone to follow along. That gives benefits for demos, and for anyone on the internet to try out our code. Also, we can integrate this into our Travis builds and do a full stack test.
I have started this (see Github issue), and immediately run into a snag with a stack trace. I’m guessing some code is missing somewhere. No matter, we’ll fix that with a second Github issue.
Things are moving forward here at Doveps. This week was the first week of our first paid employee! His name is Mark, and he hails from the Philippines.
For A-squared, the tools and technologies we use are a little less common than the standard “LAMP” stack. The biggest difference is that we are using a graph database: Neo4j.
The tutorials for Neo4j talk a lot about graphs as applied to social media. A-squared is a lot like social media for configuration management. Instead of using the wisdom of crowds to find large scale patterns, we will apply the wisdom of system administrators and engineers to generate configuration management patterns.
Mark’s work will be moving us in this direction. He will be building Neo4j queries, and attaching them to Python APIs. This sets us up for success in helping companies automate DevOps.
Following up from my earlier DevOpsDays DC, Day 1 post, here are some thoughts both from today, and from the conference as a whole.
Nathen Harvey is an awesome organizer! Shout out for making everything smooth, and keeping people as comfortable as we can be while pushing us outside our comfort zones.
At the opening of the conference, Nathen had everyone stand up, then sit us down by groups depending on answers to questions. For instance “have you been to a conference”, “have you been to DevOpsDays”. It was a great participatory method, and by the end a really effective visual indicator of the few really new people. Those people would have gotten lost in a sea of hands, or maybe have felt too nervous to raise their hand. See “pushing outside comfort zone”. That’s how we grow!
The organizers sounded these really cool chimes, by hand, when it was time to assemble, or to notify a speaker they’re out of time. Really nice, human-centered way to get this done.
Slide Karaoke! I’ll post a video when I get it. Fun way to get up in front of everyone and break the ice.
Summary from yesterday’s DevOpsDays: I am recovering from the after-party!
It was a great first day! Some reactions from the first three keynotes:
John B. Owens II: The PTO is a revenue-neutral organization, funded only by patent application fees. So they’re more like a business, very responsive. Devops matters to them!
Mark A. Schwartz: I really got a lot out of this talk. Some highlights: “Business Value” is a poorly defined term. Attempts to tie it to profit often fail. My big takeaway from this “meditation on business value” (his words): non-hierarchical empowered teams rock!
David Copeland: You can build the dev of your business around AWS, and delay hiring Ops specialists.
Tapabrata Pal: Capitol One is 20 years young in the banking world, and focuses on agile/devops. They built an awesome build status visualizer called Hygieia which I really want to try out.
Trent Hone, Laura Barton: Tying evolutionary patterns in nature to real world business cases.