The Journey of #100DaysOfCode #10YearsOfMongoDB (@stennie)

G’day folks!

I’ve been thinking about how to best contribute to @henna.s’s #100DaysOfCode challenge and am going to try something slightly different.

As of today, I’m 100 days away from my 10 year anniversary at MongoDB (!). Each day I’m going try to share one of my community contributions from the past 10 years and perhaps an anecdote if that seems appropriate. I hope you enjoy this slow walk down memory lane and perhaps find some useful MongoDB insights along the way.

It seemed appropriate to start with a fresh open source contribution to a project that was started in 2012 by one of my colleagues, @ThomasR :slight_smile:

I started helping with mtools releases in 2016 when Thomas had too many other projects needing his attention, and have continued to contribute (and review contributions) when I have enough round tuits.

Day #1: mtools 1.7.0 release

:mega: Share on Twitter: https://twitter.com/stennie/status/1497185811166478338

What is mtools?

Per to the mtools documentation:

mtools is a collection of helper scripts to parse, filter, and visualize MongoDB log files ( mongod , mongos ). mtools also includes mlaunch , a utility to quickly set up complex MongoDB test environments on a local machine, and mtransfer , a tool for transferring databases between MongoDB instances.

Astute readers will notice this description covers some rather different use cases: parsing and visualising log files does not have a lot in common with setting up test environments. The common factor is the original author and the convenience of having some “go-to scripts” in one installable Python package.

What do I use mtools for?

Originally mtool’s log parsing library was an essential (but fragile) tool for log-based diagnostics in an era when MongoDB server logging was not designed to be easily parseable. However, MongoDB server logging and diagnostics have evolved significantly since then with the introduction of features like Full Time Diagnostic Data Capture (FTDC) in MongoDB 3.2 and structured JSON logging (aka logv2) in MongoDB 4.4. I find MongoDB Atlas a far more convenient home for my development and production clusters, and the built-in monitoring and alerts cover my current requirements.

In modern usage, I still use mlaunch almost daily to quickly create local test clusters for reproducing community issues with different cluster topologies and server versions.

Regards,
Stennie

11 Likes

Day 2: The Big Fix

:mega: Share on Twitter: https://twitter.com/stennie/status/1497206519137329161

I was invited to join Snyk’s The Big Fix 24-hour live stream for hour #5 and hang out with @DeveloperSteve to talk open source, geek history, security, and MongoDB. I’ve known DeveloperSteve for the majority of the last 10 years – we originally kept running into each other at user groups and events around Australia and eventually started catching up intentionally :slight_smile:

To prepare for our discussion I used Snyk to scan some of the open source repos I contribute to on GitHub. These repos were not previously being scanned by Snyk so my goal was to hopefully find a few interesting things to discuss and fix (for swag, of course!) and add these repos to automatic scanning in future. Snyk’s free plan supports 200 open source tests per month, which seems great for side projects.

  1. First off, https://github.com/rueckstiess/mtools (Python). There were no security issues flagged in the main code or dependencies of mtools, but the Sphinx documentation generator used to build a static documentation site for GitHub pages was pinned to a rather ancient version which should be updated:

    snyk-thebigfix

  2. For more interesting surface area, I then scanned the get-started repos ("Get Started" with MongoDB Atlas) which are Docker images that provide an easy way to get started with language-specific development environments (C#, Ruby, Node.js, Java, …) including working code examples using official MongoDB drivers.

    Snyk identified an issue with the base image version used in the get-started-ruby Dockerfile:
    snyk-alpine

    I used this as an example on The Big Fix live stream and almost immediately had a pull request!

I highly recommend setting up some automated vulnerability scanning for your open source projects so you can proactively (and optionally, automatically) patch known issues.

Regards,
Stennie

6 Likes

Day 3: Full Stack Overflow Developer

:mega: Share on Twitter: https://twitter.com/stennie/status/1497586457019502594

G’day folks!

MongoDB’s highly active community was one of the appealing reasons for me to join the company. During my employee onboarding I was encouraged to join the mongodb-user discussion forum (a Google Groups predecessor of the current MongoDB Community Forums) as well as Stack Overflow. My initial job focus was supporting customers with commercial support agreements, but I’ve always tried to help in the community whenever possible.

I find community discussion is personally helpful to ramp up and test my own knowledge, gain insight into the experience of other developers, and create some evergreen answers that can be updated or improved. However, the bigger impact is educating and unblocking some developers who might be stuck on a frustrating code or deployment challenge.

Stack Overflow provides some measures of impact in your user profile. I currently have 812 answers on Stack Overflow which apparently have reached ~5.1 million people so far:

stackoverflow-impact

Stack Overflow (or more broadly, the Stack Exchange network) certainly isn’t the only community channel I’ve been active on over the past decade, but my general takeaway is that useful public discussion can benefit many more people than just the one who started the discussion.

For one example of an evergreen answer, variations of this question from July 2012 still come up regularly: How does MongoDB sort records when no sort order is specified? - Stack Overflow. I’ve revised my answer a few times when there have been notable product changes like the introduction of the Storage Engine API and WiredTiger storage engine in MongoDB 3.0, or comments and suggestions from Stack Overflow users. The server documentation has a concise definition of natural order, but community discussion can provide extra context.

Community discussion also leads to improvements in product and documentation. For example, MongoDB aggregation comparison: group(), $group and MapReduce - Stack Overflow (Sept 2012) inspired Aggregation Commands Comparison in the MongoDB server documentation.

However, my appreciation of community has also evolved over the years. While Stack Overflow has great utility as an impersonal collaborative Q&A site (one answerable question per question, please), I find courteous discussion with personal elements like salutation and sign-off more enjoyable, easier to recall, and less transactional (even if there is a common outcome of sharing knowledge). There is definitely room for multiple community channels and collaboration styles, so I would choose the approach that works best for you :slight_smile:

Regards,
Stennie

profile for Stennie on Stack Exchange, a network of free, community-driven Q&A sites

8 Likes

Day 4: What’s up, docs?

:mega: Share on Twitter: https://twitter.com/stennie/status/1497944442354814992

G’day folks!

One of the many transitions that was underway when I joined MongoDB was moving the server documentation from its original home on a Confluence wiki to a completely rewritten MongoDB Manual built using Sphinx and reStructuredText (RST).

The wiki documentation home page circa June 2012 looked like:

The first complete version of the MongoDB Manual was for MongoDB 2.2 (August 2012). The 2.2 manual was structurally very similar to modern versions of the server documentation, although build tools and presentation have evolved significantly since then.

We had a full-time technical writer leading this effort, but assistance from any contributors was (and still is!) welcome. The server manual source is available on GitHub in the mongodb/docs repo and there is a process to Contribute to the Documentation.

My first docs pull request (July 2012) was updating the glossary to “Fix some spellos, grammos, and term linking problems”. Since then I’ve submitted hundreds of suggestions (and some pull requests) across different docs projects related to MongoDB (server, driver, third party, …). The vast majority of those improvements have been driven by community discussion and feedback, and I am very grateful for everyone who has helped make the docs better.

Regards,
Stennie

3 Likes

Day 5: Got MUGs?

:mega: Share on Twitter: https://twitter.com/stennie/status/1498299387029516289

G’day again, folks!

Before I discovered 10gen (The MongoDB Company) was opening an office in Sydney, I was already in the process of setting up a Sydney MongoDB User Group (MUG). Sydney had several local user groups that broadly covering big data and NoSQL (graph databases, key/value, document databases, etc), but mostly from a sales-y point of view.

I was personally keen to learn more about MongoDB and some of the good (and rough or sharp) edges directly from developers. I had been organising and attending open source user groups for about 15 years by that point, and my experience was that user groups focused on common technology or interests provided great insight and could establish ongoing friendships.

After getting in touch with 10gen’s community team for onboarding and planning, I set up the Sydney MongoDB User Group on Meetup on May 28, 2012. Coincidentally, I had recently accepted a job offer at 10gen and was preparing to head to New York for my employee onboarding at the end of the week.

The Sydney MongoDB User Group’s first event kicked off at the end of July, 2012 when a colleague came from the US to deliver public training for MongoDB and also agreed to be our featured presenter. Fishburners, a local startup incubator, provided an excellent host venue. One of my learnings from past user group wrangling was to try to set a recurring cadence and venue, so instead of only asking about the space for July I booked it through to November on the same night (last Tuesday of the month). I wasn’t sure if there would be enough interest to sustain a monthly meeting, but I wouldn’t know until I tried.

The monthly cadence worked out, and with support from my local colleagues as speakers and co-wranglers (huge shout out to @wan and @kevinadi) we ended up running 60 meetup events in the 60 months from July, 2012. The events moved from Fishburners to the MongoDB offices once we had enough space to self-host. For 2018 we changed the Sydney MUG cadence to every second month to allow attending other events, and had our highest attendance numbers. The Sydney MUG story unfortunately went dark in 2019, with an unsuccessful handover to a new organiser leading to eventual group retirement in 2020.

The final tally was 72 user group events and over 2,000 members. This is the closest screenshot I could find on the Wayback Machine:

However, there will be a new chapter written this year – the Sydney MongoDB User Group will be returning with a little help from our awesome community members. Stay tuned :slight_smile: .

Regards,
Stennie

9 Likes

Day 6: m & m tools

:mega: Share on Twitter: https://twitter.com/stennie/status/1498664756991115264

G’day folks – back to history time for open source contributions!

2012 was apparently a bumper year for creating MongoDB-related projects. In August 2012 one of my colleagues on the Node.js driver team (Aaron Heckmann) created: m - MongoDB Version Manager. m is a bash script that helps download and switch between multiple versions of MongoDB. m was inspired by the n bash script which has analogous functionality for downloading multiple versions of Node.js.

Ready access to multiple versions of MongoDB server is essential for reproducing issues in support or community discussions, so this became one of my go-to tools (along with mlaunch, which I use to stand up local deployments). Despite being a regular m user, it looks like my first direct contribution to the project wasn’t until May 2016. I see a lot of familiar names in the contributors list as m was (and is) widely used by my colleagues.

I volunteered to help with releases and became a co-maintainer in Oct 2017. An aspect I love (and loathe) about m is that it is a monolithic bash script. This is super convenient to copy into a new VM or Docker image without worrying about compilation or dependencies, but isn’t great for testing or maintainability.

There have been a few memorable pull requests, but my favourite started off with a PR from @Oleg_Pudeyev to add distro-specific support for Debian and MongoDB Enterprise depdencies.

This is how it started:

An ambitious plan to test detection on of the Linux distros supported by MongoDB binaries turned into an epic assist from @kevinpulo and @kevinadi:

Another fun PR was @Tim_Fogarty adding support to download multiple versions of the MongoDB Database Tools, which added m tools commands.

I’m now the maintainer of mtools, m, & m tools :wink:

Regards,
Stennie

5 Likes

I loved reading the Sydney MongoDB User Group History :heart_eyes:

Hats off to all your ongoing efforts for building the MongoDB Community :cowboy_hat_face:, Hi :five: :partying_face:

Cheers :performing_arts:

5 Likes

Thanks @henna.s! I’m hoping the ratio of readers to writers for this posting run will eventually be significantly higher and more interactive, but I am enjoying the daily habit of sharing some of my community contributions. I wish I could tag and thank everyone who has helped along the way, but that is an impossibly long list :).

If anyone has found anything particularly useful or would like more posts on a specific topic, I’m also up for suggestions.

Cheers,
Stennie

4 Likes

Day 7: Tim Tam Slam @ MDBW17

:mega: Share on Twitter: https://twitter.com/stennie/status/1499030612099080196

G’day folks! Today’s topic involves a different sort of community building and hacking.

Imagine you are planning a trip from Sydney to Chicago to staff a booth at MongoDB’s annual MongoDB World developer conference in 2017 and a few days before departure you have a conversation that goes somewhat like this:

Q: So, what sort of awesome swag will we have at this booth? :raised_hands:

A: None

Me: :cold_sweat: => :thinking: => :bulb:

You’ll never believe what happened next …

As many of my colleagues and user groups have discovered, I generally travel with a generous supply of Aussie treats to give away.

:chocolate_bar: Tim Tams are an especially strong international currency: they are chocolate-coated biscuits with a variety of exclusive-to-Australia special edition flavours. The exclusive local flavours change roughly annually, and have gotten as specific as being limited to different retail chains. You can now get some locally produced Tim Tams outside of Australia, but I gather they do not have the same free-range flavour profile as my artisanally imported care packs.

:fire: Tim Tams also have one especially fun property: underneath the outside layer of chocolate coating there are two malted biscuits separated by a cream filling. If you dunk the Tim Tam in a hot beverage, the cream filling dissolves faster than the biscuits and you can briefly use the Tim Tam as a chocolate straw while it still has some integrity. This is known as a Tim Tam Slam (or a Tim Tam Explosion if you wait too long and end up holding a melty mess).

:bulb: A theme of the conference was “Giant Ideas”, so my DIY swag idea was to introduce MongoDB World attendees to the wonders of Tim Tams. I bought as many Tim Tams as I thought I could fit between my suitcase and carry-on (and then a few more!). I hoped the booth wouldn’t be too far from hot beverages as I needed those for my idea to work.

My Giant Idea is …

:bulb: Here’s how my tour on the booth started:

:tv: What does a Tim Tam Slam look like?

:raised_hands: We ended up borrowing a small table and some coffee cups for our impromptu Tim Tam Slam station, and asked challengers to tweet their photos. Most Slam attempts were successful but we had a few fun fails, too :slight_smile:

There were some epic reactions like:

awesome-moment

… and sooooooo gooooood:

sooooo-good

:raised_hands: I had a lot of fun meeting the attendees, sharing (and in some cases, sharding) Aussie treats, and talking MongoDB. I can’t recall exactly how many Tim Tams I brought with me (there is photo evidence, somewhere!) but this was one of my favourite DIY swag hacks.

:tada: I took this photo of one of my Tim Tam deployments from Down Under (in the correct orientation). I’m curious how modern readers would describe this – let me know in the poll below. For Science!

What type of Tim Tam deployment is represented in the above picture?
  • Replica set
  • Sharded cluster
  • Other (please describe in a reply)

0 voters

Regards,
Stennie

6 Likes

This is an awesome DIY Swag Hack :heart_eyes:

The youTube video is hilarious… Did you try this yourself? How was your experience?

We should do this again at MDBW 2022 :star_struck:

Cheers :performing_arts:

2 Likes

Hi Henna,

I sample all of the local Tim Tam flavours for quality control and Slam-ability. I recommend anyone with an inclination toward chocolatey goodness commit to the same empirical research to make a personal data-driven decision.

Further inspiration: https://twitter.com/hswolff/status/806158532601057280 :wink:

Indeed. Let’s see how many :heart:s this post gets as a proxy for “bring moar Tim Tams” :).

If anyone is planning on attending MongoDB World in person and hasn’t registered yet, you can use the promo code STENNIE25 for a 25% discount and a special thanks if we meet in person.

Cheers,
Stennie

4 Likes