New Trio of Series: Go, Bash, and Distributed Databases

I’m starting three new series and only making this post now that I’ve got the first round posted and live. Each of these I’ll be back posting so that I have a kind of linked list of blog entries for each of the series. So if you’re into learning Go, I’ve got that going, or you’re into bash hacking, got that too, and of course if you’re digging into distributed systems and databases, I’m tackling that too. It’s kind of the trio of core technologies I’m working on these days, enjoy:

The Nuances of Go – This is going to be a series where I go through some of the details of Go. It’s going to be kind of all over the board, but drill into usage of the language, the why, and what for of various features, capabilities, and related topics.

‘bash’ A.K.A. The Solution for Everything – Bash has been around for a while. But let’s not talk about how old it is, the shell has been used and is being used by about every single operating system on the planet. It’s hugely popular and it isn’t exactly being replaced. You can also basically do anything on a computer that you would want to or need to do with it. However there are lot’s of features and commands one ought to know, this series is going to tackle a new command every new post and go into details of how to use it, what it can be used for, and related tips n’ tricks.

Distributed Database Things to Know – This series is going to cover various features and nuances of the Cassandra distributed database cluster technology. I’ll be diving into a whole host of capabilities, code, and a pointer or three back to white papers when relevant that helped bring these distributed databases into existence.

My goal with each of these is to rise early Monday morning, and time box each article to about 30 minutes. 30 minutes for Go, 30 minutes for bash, and 30 for Cassandra. Then I’ll publish those throughout the week. I set this goal with the hilarious fact that I’m taking time to go record some LinkedIn learning courses on Go and Terraform. With that it might be a week before you see the next trio published. But they’re halfway written already so I might surprise myself. Happy thrashing code!

A New Adventure of Multi-model Distribute Graph Time Series […etc…] Database(s) Explorations Begins!

I arrived at the airport, sending a few tweets of this or that nature with all of this Github and Microsoft News. I have a great view out the window from the Alaska Lounge just before heading to the D gates. For you aeronautics fans like myself, here’s a picture of that view and a few of those Alaska Planes with one of the newly acquired Virgin America Planes!


All this news with Github and Microsoft was easily eclipsing WWDC18 and in the meanwhile little ole’ me is on my way to a new adventure in my career. So priorities what they are, the news being excited, I’m more excited today to announce today I’m joining a most excellent team at DataStax! to bring forth investigation, research, knowledge, ideas, and whatever else I can as a Developer Evangelist with the crew here at DataStax! I’m unbelievably stoked as I’ve been searching for a company that would check all of my “will this work” check boxes for some months now! DataStax won out among the other prospective candidate companies and I’m starting today!


To kick off this adventure, I’m heading to San Francisco to join in the fun attending DevxCon. I’ll be there a little later today, hopefully in time for the kick off (ya know, pending flights and BART are all timely and such)! Then a full day of the conf, then later will join the team for a visit to DataStax HQ and maybe a few surprises. I’m super excited and ready to bring awesome content your way, while inventing, building, and experimenting my way through some awesome technologies!

The Developer Advocates – Observations on Microsoft’s New Competence

racoonRecently a whole slew of people got hired at Microsoft. Many of us have taken notice. It’s left a lot of people with questions like:

  • Why would Erik, Ashley, or Jesse work at Microsoft?
  • Doesn’t it seem suspicious?
  • I wonder what kind of cash they allocated to that payroll budget?
  • Does Microsoft hire anybody that actually uses Microsoft tooling anymore?
  • I’m confused, what is even going on?

The answers may be more obvious for those of us that have kept an eye on Microsoft. There has been this grand upheaval and cultural change that has occurred. CEO Satya Nadella has legitimately shifted the culture in a way that much of the company has wanted to go. Somehow, he’s also managed to start changing the culture even for those that weren’t sure or didn’t want to go.

Satya has taken what core individuals like Scott Guthrie, Scott Hanselman, and many others have hoped for and pushed for over the years and started to enable the people within Microsoft to make this happen. You can read plenty about how Microsoft has gotten it’s groove back, and about the work the Scotts and others have done to get that groove going. But I’m not particularly writing about that, but it has inspired this article in a big way. I’m going to elaborate on what I’ve observed and what I know to make a strong, effective, useful, and community focused developer advocate and developer advocates team.

The developer advocate team over at Microsoft is led by Jeff Sandquist, Brian Liston, and a few others. They’re solid individuals with good ideas about how to build and have an advocate team contribute effectively to the community in which it works. Here are the top three obvious things they’ve done that have made the team effective, relevant, intelligent, and useful.

  1. The team is diverse. I’m not even going to play around, diverse teams with many ideas and a range of people do better. End of story, it really ought not to be complicated these days. But one can’t just start a team and say “I want my team to be diverse”. That’s a start, but the important part is does one know how to build a diverse team? In technology, if one doesn’t have insight into actual human begins this doesn’t pan out so well. One has to have the ability to communicate effectively to people out of the tech nerd guy stereotype trope in order to actually build this type of team. Jeff, Brian, and crew appear to have this ability. I’ll write more on this later, but suffice it to say, this is a top skillset of a developer advocate team’s leadership.
  2. The team has to be skilled at a variety of complementing technologies. If someone knows X, and the next person knows X, and nobody knows Y, then the team is going to be fairly weak and likely broken in representing and providing value around Y, and in some sense even around X. At this point the Developer Advocates that have been introduced have some pretty extensive skillsets around key technologies that the Microsoft Technical Evangelists have traditionally been extremely weak in. This current team has some skills in the Windows space, but there’s been a big focus in filling the massive skills gap around Linux, cloud technology (ironic there’s traditionally been such a gap on the cloud team), non-MS languages like Go, distributed systems, data analysis and intelligent (or data science or whatever one may call these roles), and more. The Advocate team (also not called evangelists anymore, finally) is finally in a good position to actually start doing advocacy around actual cloud technology. I’m excited for the potential of the prospects!
  3. The third thing that has stood out, is that they’ve hired people that know how to do the advocacy thing already. They’re not trying to define or redefine it on Microsoft’s terms but instead have brought people onboard that are already natural advocates of things they find interesting. Take Erik St Martin (@erikstmartin) for example; co-authored a book, “Go in Action“ with Brian Ketelsen (@bketelsen), co-hosts Go Time FM. That brings up another great example with Brian Ketelsen. Both of these guys are hug advocates in their own right, without connection to any specific big company or what not. These are the types of people that bring huge strength to a team with already proven ability to delivery. Then there’s Jesse Frazelle, but seriously, I really don’t even need to mention the work she’s done with containers (cough cough, docker, etc). Another person you should be watching is Anthony Chu (@nthonyChu), who’s been a steady Azure and great technologies advocate over the years, also joined up. You can read more about the individual team members here, and I hear through the secret grapevine that there are more en route to join. Simply put, Microsoft isn’t pulling their punches!

Before a lot of the Microsoft team had been formed into the epic legion it is today, there were a number of articles pointing to this rebirth into a newly relevant organization. One that was solid is Ars Technica’s “Microsoft’s renewed embrace of developers, developers, developers, developers“ by Peter Bright (@drpizza). One of the first, as anyone who reads & subscribes to [Red Monk] analysis would suspect, was published by James Governor (@monkchips) with “On Hiring Jesse Frazelle: Microsoft’s Developer Advocacy Hot Streak Continues“. The writing has been on the proverbial wall.

So now what?

Now the thing to wait and see is if the team and the team’s leadership can direct all of this energy into their respective efforts. The team is big, lots of people, lots of focus points. How will they use each others’ strengths while building up along core competencies? How will they provide value without detracting from product and push product without losing community value? There are a lot of questions to be answered and I’ll be keeping a close eye on their efforts. As I do with all of the advocacy teams I find fellow interests in. The advocacy, effectiveness, and reasons for it all has been an interest of my own for some time. So much so you can expect more than a few more articles on this topic, until then, cheers!


Coding on & Orchestrate.js & Orchestrate.NET

First context, then I’ll dive in.


Orchestrate is a service that provides a simple API to access a multitude of database types all in one location. Key value, graph or events, some of the database types I’ve been using, are but a few they’ve already made available. There are many more on the way. Having these databases available via an API instead of needing to go through the arduous process of setting up and maintaining each database for each type of data structure is a massive time saver! On top of having a clean API and solid database platform and infrastructure Orchestrate has a number of client drivers that provide easy to use wrappers. These client drivers are available for a number of languages. Below I’ve written about two of these that I’ve been involved with in some way over the last couple of months.


This library I’m currently using for a demonstration application built against the services (follow us on twitter ya! @BeDeconstructed), a startup I’m co-founding. I’m not sure exactly what the app will be, but being .NET it’ll be something enterprisey. Because: .NET is Enterprise! For more on this project check out the Blog.

Some of the latest updates with this library.

But there’s still a bit of work to do for the library, so consider this a call out for anybody that has a cycle they’d like to throw in on the project, let us know. We’d happily take a few more pull requests!  The main two things we’d like to have done real soon are…


With the latest fixes, additions and updates the orchestrate.js client driver is getting more feature rich by the day. In addition @housejester has created an orchestrate-brain project for Hubot that uses Orchestrate.js. If you’re not familiar with Hubot, but sure to check out the company robot that can dramatically improve and reduce employee efficiency! Keep an eye on that project for more great things, or create a Hubot to keep a robotic eye on the project.

Here are a few key things to note that have been added to help in day-to-day coding on the project.

  • The travis.yml file has been added for the Travis Continuous Integration build. This build runs against node.js v0.10 and v0.8.
  • Testing is done with mocha, expect.js and nock. To get the tests up and running, clone the repo and then build with the make file. The tests will run in tdd format.
  • Promises are provided via the kew library.

If you’re opening up the project in WebStorm, it’s great to setup the mocha tests with the integrated mocha testing as shown below. After you’ve cloned the project and run ‘npm install’ then follow these steps to add the Mocha testing to the project. We’ve already setup exclusions in the .gitignore for the .idea directory and files that WebStorm uses.

First add a configuration by clicking on Edit Configurations.

Edit Configurations
Edit Configurations

Next click on the + to add a new configuration to run. Select the Mocha option from the list of configurations.

Mocha & Other Configurations in WebStorm
Mocha & Other Configurations in WebStorm

On the next screen set a name for the configuration. Set the test directory to the path for the test directory in the project. Then finally set the User interface option for Mocha to TDD instead of the default BDD.

Edit Configuration Dialog
Edit Configuration Dialog

Last but not least run the tests and you’ll see the list of green lights light up the display with positive results.

Test Build
Test Build

A Recap Of My Top 4 Tech Article Reads From Pocket

Sometimes I get overwhelmed with the number of articles that are in my pocket. I’ve got articles on livability, transit, cycling, auto issues, node.js, java, javascript, coding practices, software craftsmanship, feminism, heavy metal, death metal, black metal, jazz, progressive jazz, fusion jazz, NASA news, space discoveries, space research, Star Trek news, Star Wars news, information on sci-fi books and a slight spattering of politics and some other just interesting nonsensical stuff.

Here's a shot of Pocket on OS-X with an article about Seattle's Tech Advantage over many American cities being rooted in urban density. Which, I'd also argue, gives Seattle a unique advantage (And is a serious pain point for Microsoft's misstep into the suburbs decades ago)
Here’s a shot of Pocket on OS-X with an article about Seattle’s Tech Advantage over many American cities being rooted in urban density. Which, I’d also argue, gives Seattle a unique advantage (And is a serious pain point for Microsoft’s misstep into the suburbs decades ago)

I’ve taken the time to sort through this list of articles, pick out the top technical articles and get this down to a manageable level again. In the process I’ve created this list of solid articles that I’ve now officially read or found useful in some way and present it here for you dear reader. Enjoy, I hope they’re useful to you too.

Article Recon, The Top

  1. Zef Hemel wrote up a piece titled “Docker: Using Linux Containers to Support Portable Application Deployment“. In the article Zef delves into a number of things that are key to understanding Docker and the notion of portland application deployment. Other topics covered include isolation, security, reproducing deployments and resource constraints. The article closes with an example of  application containers and their respective deployment.
  2. 7 Javascript Basics Many Developers Aren’t Using (Properly) albeit slightly useful, I found this one more entertaining. It does give some small insight to the scope of oddities that JavaScript has and how one can easily miss the basics in JavaScript.
  3. Even though the article is from late last year, “The Premature Return to SQL” is a good read. As Alex Popescu   states it, “This pisses me off. A lot.” I too find myself pissed off a lot at the naive understanding and decisions making around SQL or alternate options. It’s almost as if some people decide to just flip a coin to make these determinations with zero insight into what they’re actually attempting to do.
  4. The article “No Deadlines for You! Software Dev Without Estimates, Specs or Other Lies” is spectacular in laying out how bullshit specs and estimates are. They’re almost entirely wasted effort on the developers part. In my own opinion it is often a failure (and yeah, I’ve been in management and leadership too, and removed these issues) of management to understand in the slightest what is actually being built or how it is being built. A lack of vision on behalf of the project is a sure fire sign that the original estimates are already completely off, the design and build out of whatever it is will likely be wrong and a host of other issues. Building software isn’t a bridge, it’s more like a painting, you decide as you go. There is no paint by numbers in software development.

Anyway, that’s my list from the 50+ tech articles that were in my Pocket app. Maybe on day I can get disciplined enough to keep the list limited to really good reads and I’ll start putting together a “My Top Pocket Reads this Month” blog entries? That sounds like it could be useful. Until then, happy coding.