The most common reaction I received from friends and family in the United States is surprise and curiosity. Admittedly Tiranë is not a typical place for an American to end up. But I am no stranger to this city. I have a long history in Tiranë. I fell in love with the culture and the people, and made good friends that are still in my life today. Some even helped me relocate. (Thank you!) So while it may be unusual for an American to end up in Albania, it is not unusual for me to end up here.

But how did I make the jump? Or why leave the United States, especially while the world holds its collective breath amid a global pandemic? It was not an easy decision, so it will not have an easy explanation.

A visit to Tiranë in June. 🔗

In June 2021, I visited Tiranë with friends who had never visited Albania before. In the course of that trip, I did not realize I was being pulled back into a culture, city, and country that has stuck with me for many years. But I was.

Fate took my hand, and after a year of cloudy uncertainty, I knew a new part of my destiny. On a fateful flight flying westbound, my heart was resolved to return eastbound. And how hard must I bite my tongue to acknowledge this privilege bestowed unto me by my American passport? To leave the story unfinished was only a matter of resolve, thus I knew I must pursue the next chapter.

Fast forward… and I am here in Tiranë. I made my arrival quietly to give me time to settle. (Literally.) I only had a bed, fridge, microwave, and a sofa. Now it is feeling more like my home. I am eager to make rounds to my favorite places and saying përshëndetje to old friends again soon.

Is the future in Stockholm? 🇸🇪 🔗

Part of my move is also motivated by my work team’s upcoming relocation. My team will relocate to Stockholm, Sweden over the next year. I am not sure where my fate will leave me. I love what I do and I feel privileged to be paid for it. So if I will continue forward on this same path, then I know I will go.

Yet I prefer to know by experience than to guess by speculation. So if I will go with my team, I would like to experience first-hand what would be my new home. Another fact is that plane tickets to Europe are cheaper from Europe. Cheaper than from the United States, even though Tiranë is a “premium” destination by European standards.

Eventually I hope to visit my new office and see it for myself. Again wondering how hard to bite my tongue if I acknowledge the unique privilege I have to casually shift my life in such a seismic way.

Here, for now. 🔗

If you are a friend and happen to be in Tiranë, drop me a note!

I created this for the RIT Linux User’s Group (a.k.a. RITlug). RITlug welcomes student-led projects for members to work on together. RITlug executive board members want to better encourage students to share and join projects for collaboration with the community (in the spirit of FOSS). To do this, the executive board members will create and offer both a template website and template documentation tools to introduce students to project development process. Then, students are better able to sustain a more diverse community around their projects.

“Start writing ReStructuredText already!” 🔗

The philosophy with this small project is: “Start writing ReStructuredText already!” I use Sphinx with ReadTheDocs as a deployment option across different organizations. I want a common base to later customize for a specific project’s needs.

The whole point of this project is to save time kicking off a new project’s recently-established documentation effort.

Sphinx Travis CI testing configuration included 🔗

Complex documentation tool chains need simple validation of successful builds. This avoids long periods where documentation may not build and the public docs are out of date. It also better engages core contributors to monitor and take care of their documentation.

A Travis CI configuration is included. Fork this repository and enable the repo on travis-ci.org to start running builds.

Add a star on GitHub 🔗

Does this sound helpful? Check it out and add a star at justwheel/sphinx-docs-opinionated-quickstart. The project is licensed under the BSD 3-Clause License; feel free to fork it and form your own opinions too.

Photo by Jānis Skribāns on Unsplash.

This week is the last week of the fall 2017 semester at RIT. This semester, I spent time with the MetaBrainz community working on ListenBrainz for an independent study. This post explains what I was working on in the last month and reflects back on my original objectives for the independent study.

Running my own ListenBrainz 🔗

The RIT Linux Users Group hosts various virtual machines for our projects. I requested one to set up and host a “production” ListenBrainz site. The purpose of doing this was to…

1. Test my changes in a “production” environment
2. Offer a service for the RIT Linux Users Group to poke around with

I spent most of this time working with our system administrator to set up the machine and adjust hardware specs for ListenBrainz. Once we fixed storage space and memory issues, it was easy to set it up and get ListenBrainz running. My experience writing the development guide made it easy to get set up and get working. On the first run, it worked!

Now, listen.ritlug.com is live.

Figuring out HTTPS 🔗

My next challenge for the site is to set up HTTPS. I tried using a reverse proxy in nginx to set up HTTPS, but I received 502 Bad Gateway errors. I realized I spent too much time figuring this out on my own and decided to ask for help in the MetaBrainz community forums.

Proposing new statistics 🔗

Halfway through the independent study, I realized I would fall short of my original objective of implementing basic statistics in ListenBrainz. To compromise, I wrote a proposal for new statistics to start in the project. My proposal looked at other proprietary platforms that compete with ListenBrainz to see some of their statistics. I also came up with some of my own.

I proposed this to the MetaBrainz community on the community forums. I’m awaiting feedback on my ideas. Once I get feedback, I plan to file new tickets for each statistic to track their implementation over time.

I don’t expect statistics being at the forefront of ListenBrainz for some time. A lot of work is going towards other areas of the project. But later in 2018, I expect more focus on the user-facing side of the project.

My statistic and Google BigQuery 🔗

My biggest blocker over the last month was Google BigQuery. I wrote a statistic to calculate play counts over a time period, but was asked to test my statistic. To test my statistic, I needed real data to work with.

Originally, I tried using the Simple Last.fm Scrobbler to submit listens to the local IP address for my development environment, but I wasn’t able to get the app to reach my ListenBrainz server. To get the data, I had to set up Google BigQuery credentials so I could make queries against data on the production site, listenbrainz.org.

I tried working through the Google BigQuery documentation. There’s a lot of documentation for using BigQuery as a developer, but it was confusing where to find the information I needed to set it up in my development environment. I tried creating a new project in the Google Cloud Platform, but I was confused because it prompted me to upload my own data instead of accessing data already in BigQuery.

Too late, I realized I spent too much time on my own and not asking for help. I submitted a pull request with the statistic I made and asked for help in the MetaBrainz community. I also offered to write documentation for setting this up once I learn how to do it.

Reflecting back 🔗

I looked back on my original objectives for the independent study, and I was satisfied and dissatisfied.

Not enough programming 🔗

I wanted this independent study to enhance my programming knowledge. I especially wanted to focus on Python because I wanted to become more familiar with the language. However, I actually didn’t do much programming during the independent study, to my own fault.

My biggest challenge was I bit off more than I could chew. I wanted to write code, and made a big goal before I knew the code base of the project. Even now, I still am not completely comfortable with the code yet. It’s a big project with a lot of things going on. I was able to understand the things I did work on, but there’s still a lot.

I realized that next time, I need to spend more time evaluating the code base of a project before writing out my milestones. I wish I set more realistic, smaller milestones for myself. My milestone of implementing basic reports was lofty given my existing programming knowledge.

Successes 🔗

One of my other objectives was to write documentation for the project. I felt I succeeded in this milestone, and actually found it enjoyable and interesting to do! I helped separate out documentation from the README into the dedicated ReadTheDocs site. I wrote the development environment guide and helped fix some build issues with the docs site. I also plan to write more for some of the other pain points I found, like Google BigQuery.

My last milestone was to create a use case for a data visualization course at RIT. While I didn’t implement my basic reports, I did create the proposal and make an effort to write new statistics. There’s a lot of potential now to work with the data in Google BigQuery and do front-end work with tools like D3.js and Plotly.js. I believe there’s significant potential to use ListenBrainz as a hands-on project for students to explore data visualization with real data. I hope to support my independent study professor, Prof. Roberts, with questions and logistics of using it as a tool for learning in the future.

Unexpected success 🔗

I also think I had an unplanned success too. I immersed myself in the community for ListenBrainz too. Over the last few months, I realized that many of my strengths are in community management and tooling. During my time in the community, I did the following:

• Fixed SELinux labels in Docker
• Contributed a pull request template
• Drafted contributing guidelines
• Fixed a PostgreSQL bug
• And more…

To the future! 🔗

This ends my independent study with ListenBrainz, but it doesn’t end my time contributing! I chose ListenBrainz because it’s a project I’m passionate about. An independent study allowed me to justify more time on it than a side project in my free time. I’m happy to have that opportunity, but I don’t want to end here!

I want to follow through on the statistics because I’m passionate about understanding music listening trends. I think there’s a lot of power for psychological research through music data. To this point, I filed a ticket to request tagging listens with “emotion” words that are synced back to MusicBrainz entities.

I won’t have as much time to work on the project without the course credit, but I hope to stay involved for the future. I love the project and I love the community. I’m thankful for the opportunity to work on this project as an independent study, and learn some things along the way.

Last week moved quickly for me in ListenBrainz. I submitted multiple pull requests and participated in the weekly developer’s meeting on Monday. I was also invited to take part as a mentor for ListenBrainz for the upcoming round of Google Code-In! In addition to my changes and new role as a mentor, I’m researching libraries like D3.js to help build visualizations for music data.  Suddenly, everything started moving fast!

Last week: Recap 🔗

The ListenBrainz team accepted my development environment improvements and documentation. This gave me an opportunity to better explore project documentation tools. I experimented with Sphinx and Read the Docs. Sphinx introduced me to reStructuredText for documentation formats. I’ve avoided it in favor of Markdown for a long time, but I see where reStructuredText is stronger for advanced documentation.

Since ListenBrainz is a new project, I plan to contribute documentation for any of my work and improve documentation for pre-existing work. One of the goals for this independent study is to make ListenBrainz a viable candidate for a future data analysis course. To make it easy to use and understand, ListenBrainz needs excellent documentation. Since one of my strengths is technical writing, I plan to contribute more documentation this semester.

You can see some of the new documentation already!

Google Code-In mentor 🔗

The MetaBrainz community manager, Freso Olesen, approached me to mentor for Google Code-In. Google Code-In is an opportunity for teenagers to meaningfully contribute to open source projects. Google describes Google Code-In as…

Pre-university students ages 13 to 17 are invited to take part in Google Code-in: Our global, online contest introducing teenagers to the world of open source development. With a wide variety of bite-sized tasks, it’s easy for beginners to jump in and get started no matter what skills they have.

Mentors from our participating organizations lend a helping hand as participants learn what it’s like to work on an open source project. Participants get to work on real software and win prizes from t-shirts to a trip to Google HQ!

MetaBrainz is a participating organization of Google Code-In this cycle. Because of my work with ListenBrainz, I will contribute a few hours a week to help mentor participating students with ListenBrainz. Beginner problems should be easy to help with since I’m still beginning too, and as I spend more time with ListenBrainz, I can help with harder problems.

I’m excited to give back to one of my favorite open source projects in this way! I’m grateful to have this chance to help out during Google Code-In.

Choosing easyfix bugs 🔗

After I figured out the development environment issues, I went through open tickets filed against ListenBrainz to find some to work on. I made a preliminary pass through all open tickets and left some comments for more information, when needed. The tickets I highlighted to look into next were

• LB-85: Username in the profile URL should be case insensitive
• LB-124: Install messybrainz as a a python library from requirements
• LB-176: Add stats module and begin calculating some user stats from BigQuery
• LB-206: “playing_now” submissions not showing on profile
• LB-212: Show the MetaBrainz logo on the listenbrainz footer.

Of these five, LB-124 and LB-212 are already closed. While drafting this article, I completed LB-124 in PR #266. This was part of a test to get the documentation building again because of odd import errors. Later, a new student also learning the project for the first time asked to work on LB-212. Since it was a good first task to explore the project code, I passed the ticket to him.

I want to do one more “easyfix” bug before going into the main part of my independent study timeline. I don’t yet feel comfortable with the code and one more bug solved will help. After this, I plan to pursue the heavier lifting of the independent study to explore data operations and queries to make.

Researching D3.js 🔗

Prof. Roberts introduced D3.js as a library to build interactive, dynamic charts and visual representations of data. I haven’t yet looked into much front-end work, but this was a cool project that I wanted to highlight in my weekly report. This feels like it could be a powerful match for ListenBrainz, especially since the data has high detail.

Upcoming activity 🔗

This next week, I won’t have as much time to contribute to ListenBrainz. On October 21, I’m traveling to Raleigh, NC for All Things Open. On October 24, I present my talk, “What open source and J.K. Rowling have in common”. Since I’ll be out of Rochester and missing other classwork, I expect less time on my ListenBrainz work.

This next week will be slower than the last two weeks. Hopefully I’ll learn something at the conference too to bring back for ListenBrainz.

Until then… keep the FOSS flag high.

One of the first rites of passage when working on a new project is creating your development environment. It always seems simple, but sometimes there are bumps along the way. The first activity I did to begin contributing to ListenBrainz was create my development environment. I wasn’t successful with the documentation in the README, so I had to play around and work with the project before I was even running it.

The first part of this post details how to set up your own development environment. Then, the second half talks about the solution I came up with and my first contribution back to the project.

Install dependencies: Docker 🔗

This tutorial assumes you are using a Linux distribution. If you’re using a different operating system, install the necessary dependencies or packages with your preferred method.

ListenBrainz ships in Docker containers, which helps create your development environment and later deploy the application. Therefore, to work on the project, you need to install Docker and use containers for building the project. Containers save you from installing all of this on your own workstation! Since I’m using Fedora, I run this command.

sudo dnf install docker docker-compose

Register a MusicBrainz application 🔗

Next, you need to register your application and get a OAuth token from MusicBrainz. Using the OAuth token lets you sign into your development environment with your MusicBrainz account. Then, you can import your plays from somewhere else.

To register, visit the MusicBrainz applications page. There, look for the option to register your application. Fill out the form with these three options.

• Name: (any name you want and will recognize, I used listenbrainz-server-devel)
• Type: Web Application
• Callback URL: http://localhost/login/musicbrainz/post

After entering this information, you’ll have a OAuth client ID and OAuth client secret. You’ll use these for configuring ListenBrainz.

Update config.py 🔗

With your new client ID and secret, update the ListenBrainz configuration file. If this is your first time configuring ListenBrainz, copy the sample to a live configuration.

cp listenbrainz/config.py.sample listenbrainz/config.py

Next, open the file with your favorite text editor and look for this section.

# MusicBrainz OAuth
MUSICBRAINZ_CLIENT_ID = "CLIENT_ID"
MUSICBRAINZ_CLIENT_SECRET = "CLIENT_SECRET"

Update the strings with your client ID and secret. After doing this, your ListenBrainz development environment is able to authenticate and log in from your MusicBrainz login.

Initialize ListenBrainz databases 🔗

Your development environment needs some databases present to work. Before proceeding, run these three commands to initialize the databases.

docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_msb_db --create-db
docker-compose -f docker/docker-compose.yml -p listenbrainz run --rm web python3 manage.py init_influx

Your development environment is now ready. Now, let’s actually see ListenBrainz load locally!

Run the magic script 🔗

Once you have done this, run the develop.sh script in the root of the repository. Using docker-compose, the script creates multiple Docker containers for the different services and parts of the ListenBrainz server. Running this script will start Redis, PostgreSQL, InfluxDB, and web server containers, to name a few. But this also makes it easy to stop them all later.

./develop.sh

You will see the containers build and eventually run. Leave the script running to see your development environment. Later, you can shut it down by pressing CTRL^C. Once everything is running, visit your new site from your browser!

http://localhost/

Now, you are all set to begin making changes and testing them in your development environment!

Making my first pull request 🔗

As mentioned earlier, my first attempt at a development environment was unsuccessful. My system kept denying permission to the processes in the containers. After looking at system audit logs and running a temporary setenforce 0, I tried the script one more time. Everything suddenly worked! So the issue was mostly with SELinux.

With my goal to get my environment set up, I figured out a few issues with the configuration offered by the project developers. I eventually made PR #257 against listenbrainz-server with my improvements.

Labeling SELinux volume mounts 🔗

To diagnose the issue, I started with a quick search and found a StackOverflow question with my same problem. There, the question was about Docker containers and denied permissions in the container. The answers explained it was an SELinux error and the context for the containers was not set. However, temporarily changing context for a directory didn’t seem too effective and doesn’t persist across reboots.

Continuing the search, I found an issue filed against docker-compose about the :z and :Z flags for volume mounts. These flags set SELinux context for containers, with the best explanation I found coming from this StackOverflow answer.

Two suffixes :z or :Z can be added to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The ‘z’ option tells Docker that the volume content will be shared between containers. Docker will label the content with a shared content label. Shared volumes labels allow all containers to read/write content. The ‘Z’ option tells Docker to label the content with a private unshared label.

Therefore, I added the :z flag to all the volume mounts in the docker-compose.yml file. I submitted a fix upstream for this in listenbrainz-server#257!

Correct the startup port 🔗

In the README, it says the server will start on port 8000, but the docker-compose.yml file actually started the server on port 80. I included a fix for this in my pull request as well.

git push! 🔗

This post makes a debugging experience that actually took hours look like it happened in minutes. But after getting over this hurdle, it was awesome to finally see ListenBrainz running locally on my workstation. It was an even better feeling when I could take my improvements and send them back in a pull request to ListenBrainz. Hopefully this will make it easier for others to create their own development environments and start hacking!

Many students take part in independent studies where they work on their own projects. However, in the spirit of open source collaboration, I wanted to contribute to a project that already existed. That way, my work would be helpful to a real-world project where it would have a value even after the end of the semester. Additionally, I wanted  a project to help me sharpen my Python skill. And ListenBrainz was a fun, exciting candidate for this.

Objectives 🔗

The independent study proposal included three primary goals I hoped to meet during this independent study:

1. Add basic reports to ListenBrainz from listening history data for top songs / artists / albums of week, month, year, etc.
2. Create documentation to improve ease to use and develop for the ListenBrainz project
3. Offer as a use case for the data visualization course in fall 2018 with instructions on how to use the data

Add basic reports 🔗

Methods for generating basic reports, charts, and statistics about listening history are important. They help make ListenBrainz a more interesting platform for a casual music listener, not just a developer. Therefore, my goal was to add a way to add basic reports or specific metrics for presenting to the user in the front-end.

As a stretch goal, if I have extra time, I would work on generating content (e.g. charts / graphs / statistics) to show the user in the front-end.

Documentation 🔗

Documentation is something near and dear to me. I enjoy making it easier for other people to use a project or get started with contributing. Therefore, I will contribute some time as a technical writer and help improve documentation on the project. This includes improving existing documentation, like how to set up a development environment, or creating new content.

As an end deliverable, it would be nice to have someone who has never worked with the project run get a development environment set up, import some data, and see something presented to them. Good documentation is key to making something like this possible.

Use case for data course 🔗

RIT will offer a data visualization course in future semesters and it would be helpful if ListenBrainz could be a use case or even tool for the course. Then, students could work with ListenBrainz for creating different visualizations for the music data. And maybe contribute some of their visualizations back upstream! For this to happen, we need comprehensive documentation and complete features.

A focus includes making ListenBrainz a good fit for this course.

Learn more about ListenBrainz 🔗

For the next few months, until December, I will blog regularly about contributing to the ListenBrainz project and my progress. Additionally, more posts about MusicBrainz, other MetaBrainz projects, or music data may follow. I’m hoping to either create new or improve old documentation as well, so I plan to write often anyways!

For now, you can learn a bit more about ListenBrainz and other projects in the MetaBrainz family, like MusicBrainz.

• ListenBrainz
• GitHub: metabrainz/listenbrainz-server
• About MusicBrainz
• About MetaBrainz

The needs and demands of infrastructure environments changes every year. With time, systems become more complex and involved. But when infrastructure grows and becomes more complex, it’s meaningless if we don’t understand it and what’s happening in our environment. This is why monitoring tools and software are often used in these environments, so operators and administrators see problems and fix them in real-time. But what if we want to predict problems before they happen? Collecting metrics and data about our environment give us a window into how our infrastructure is performing and lets us make predictions based on data. When we know and understand what’s happening, we can prevent problems before they happen.

But how do we collect and store this data? For example, if we want to collect data on the CPU usage of 100 machines every ten seconds, we’re generating a lot of data. On top of that, what if each machine is running fifteen containers? What if you want to generate data about each of those individual containers too? What about by the process? This is where time-series data becomes helpful. Time-series databases store time-series data. But what does that mean? We’ll explain all of this and more and introduce you to InfluxDB, an open source time-series database. By the end of this article, you will understand…

• What time-series data / databases are
• Quick introduction to InfluxDB and the TICK stack
• How to install InfluxDB and other tools

Introducing time-series concepts 🔗

If you’re familiar with relational database management software (RDBMS), like MySQL, tables, columns, and primary keys are familiar terms. Everything is like a spreadsheet, with columns and rows. Some data might be unique, other parts might be the same as other rows. RBDMS’s like MySQL are widely used and are great for reliable transactions that follow ACID (Atomicity, Consistency, Isolation, Durability) compliance.

With relational database software, you’re usually working with data that is something you could model in a table. You might update certain data by overwriting and replacing it. But what if you’re collecting on data on something that generates a lot of data and you want to watch change over time? Take a self-driving car. The car is constantly collecting information about its environment. It takes this data and it analyzes changes over time to behave correctly. The amount of data might be tens of gigabytes an hour. While you could use a relational database to collect this data, they’re not built for this. When it comes to scaling and usability of the data you’re collecting, an RBDMS isn’t the best tool for the job.

Why time-series is a good fit 🔗

And this is where time-series data makes sense. Let’s say you’re collecting data about a city traffic, temperature from farming equipment, or the production rate of an assembly line. Instead of going into a table with rows and columns, imagine pushing multiple rows of data that are uniquely sorted by a timestamp. This visual might help make more sense of this.

Having the data in this format makes it easier to track and watch change over time. When data accumulates, you can see how something behaved in the past, how it’s behaving now, and how it might behave in the future. Your options to make smarter data decisions expands!

Curious how the data is stored and formatted? It depends on the time-series database (TSDB) you use. InfluxDB stores the data in the Line Protocol format. Queries return the data in JSON.

If you’re still confused or trying to understand time-series data or why you would want to use it over another solution, you can read an excellent, in-depth explanation from Timescale’s blog or InfluxData’s blog.

InfluxDB: A time-series database 🔗

InfluxDB is an open source time-series database software developed by InfluxData. It’s written in Go (a compiled language), which means you can start using it without installing any dependencies. It supports multiple data ingestion protocols, such as Telegraf (also from InfluxData), Graphite, collectd, and OpenTSDB. This leaves you with flexible options for how you want to collect data and where you’re pulling it from. It’s also one of the fastest-growing time-series database software available. You can find the source code for InfluxDB on GitHub.

This article will focus on three tools in InfluxData’s TICK stack for how you can build a time-series database and begin collecting and processing data.

TICK stack 🔗

InfluxData creates a platform based on four open source projects that work and play well with each other for time-series data. When used together, you can collect, store, process, and view the data easily. The four pieces of the platform are known as the TICK stack. This stands for…

• _T_elegraf: Plugin-driven server agent for collecting / reporting metrics
• _I_nfluxDB: Scalable data store for metrics, events, and real-time analytics
• _C_hronograf: Monitoring / visualization UI for TICK stack (not covered in this article)
• _K_apacitor: Framework for processing, monitoring, and alerting on time-series data

These tools work and integrate well with the other pieces by design. However, it’s also easy to substitute one piece out for another tool of your choice. For this article, we’ll explore three parts of the TICK stack: InfluxDB, Telegraf, and Kapacitor.

InfluxDB 🔗

As mentioned before, InfluxDB is the time-series database (TSDB) of the TICK stack. Data collected from your environment is stored into InfluxDB. There are a few things that stand out about InfluxDB from other time-series databases.

Emphasis on performance 🔗

InfluxDB is designed with performance as one of the top priorities. This allows you to use data quickly and easily, even under heavy loads. To do this, InfluxDB focuses on quickly ingesting the data and using compression to keep it manageable. To query and write data, it uses an HTTP(S) API.

The performance notes are noteworthy standing up the amount of data InfluxDB is capable of handling. It can handle up to a million points of data per second, at a precise level even to the nanosecond.

SQL-like queries 🔗

If you’re familiar with SQL-like syntax, querying data from InfluxDB will feel familiar. It uses its own SQL-like syntax, InfluxQL, for queries. As an example, imagine you’re collecting data on used disk space on a machine. If you wanted to see that data, you could write a query that might look like this.

SELECT mean(diskspace_used) as mean_disk_used
FROM disk_stats
WHERE time() >= 3m
GROUP BY time(10d)

If you’re familiar with SQL syntax, this won’t feel too different. The above statement will pull the mean values of used disk space from a three-month period and group them by every ten days.

Downsampling / data retention 🔗

When working with large amounts of data, storing it becomes a concern. Over time, it can accumulate to huge sizes. With InfluxDB, you can downsample into less precise, but smaller metrics that you can store for longer periods of time. Data retention policies for your data enable you to do this.

For example, pretend you have sensors collecting data on the amount of RAM in a number of machines. You might collect metrics on the amount of memory in use by multiple users, the system, cached memory, and more. While it might make sense to hang on to that data for thirty days to watch what’s happening, after thirty days, you might not need it that precise. Instead, you might only want the ratio of total memory to memory in use. Using data retention policies, you can tell InfluxDB to hang on to the precise data for all the different usages for thirty days. After thirty days, you can average data to be less precise, and you can hold on to that data for six months, forever, or however long you like. This compromise meets in the middle between keeping historical data and reducing disk usage.

Telegraf 🔗

If InfluxDB is where all of your data is going, you need a way to collect and gather the data first. Telegraf is a metric collection daemon that gathers various metrics from system components, IoT sensors, and more. It’s open source and written completely in Go. Like InfluxDB, Telegraf is also written by the InfluxData team and is built to work with InfluxDB. It also includes support for different databases, such as MySQL / MariaDB, MongoDB, Redis, and more. You can read more about it on InfluxData’s website.

Telegraf is modular and heavily based on plugins. This means that Telegraf is either lean and minimal or as full and complex as you need it. Out of the box, it supports over a hundred plugins for various input sources. This includes Apache, Ceph, Docker, IPTables, Kubernetes, NGINX, and Varnish, just to name a few. You can see all the plugins, including processing and output plugins in their README.

Even if you’re not using InfluxDB as a data store, you may find Telegraf useful as a way to collect this data and information about your systems or sensors.

Kapacitor 🔗

Now we have a way to collect and store our data. But what about doing things with it? Kapacitor is the piece of the stack that lets you process and work with the data in a few different ways. It supports both stream and batch data. Stream data means you can actively work and shape the data in real-time, even before it makes it to your data store. Batch data means you retroactively perform actions on samples, or batches, of the data.

One of the biggest pluses for Kapacitor is that it enables you to have real-time alerts for events happening in your environment. CPU usage overloading or temperatures too high? You can set up several different alert systems, including but not limited to email, triggering a command, Slack, HipChat, OpsGenie, and many more. You can see the full list in the documentation.

Like the previous tools, Kapacitor is also open source and you can read more about the project in their README.

Installing the TICK stack 🔗

Packages are available for nearly every distribution. You can install these packages from the command line. Use the instructions for your distribution.

Fedora 🔗

sudo dnf install https://dl.influxdata.com/influxdb/releases/influxdb-1.3.1.x86_64.rpm \
https://dl.influxdata.com/telegraf/releases/telegraf-1.3.4-1.x86_64.rpm \
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.1.x86_64.rpm

CentOS 7 / RHEL 7 🔗

sudo yum install https://dl.influxdata.com/influxdb/releases/influxdb-1.3.1.x86_64.rpm \
https://dl.influxdata.com/telegraf/releases/telegraf-1.3.4-1.x86_64.rpm \
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.1.x86_64.rpm

Ubuntu / Debian 🔗

wget https://dl.influxdata.com/influxdb/releases/influxdb_1.3.1_amd64.deb \
https://dl.influxdata.com/telegraf/releases/telegraf_1.3.4-1_amd64.deb \
https://dl.influxdata.com/kapacitor/releases/kapacitor_1.3.1_amd64.deb
sudo dpkg -i influxdb_1.3.1_amd64.deb telegraf_1.3.4-1_amd64.deb kapacitor_1.3.1_amd64.deb

Other distributions 🔗

For help with other distributions, see the Downloads page.

See the data, be the data 🔗

Now that you have the tools installed, you can experiment with some of these tools. There’s plenty of upstream documentation on all three projects. You can the docs here:

• InfluxDB documentation
• Telegraf documentation
• Kapacitor documentation

Additionally, for more help, you can visit the InfluxData community forums. Happy hacking!

Internet Relay Chat, or IRC, is one of the oldest chat protocols around and still popular in many open source communities. IRC’s best strengths are as a decentralized and open communication method, making it easy for anyone to participate by running a network of their own. There’s also a variety of clients and bots available for IRC. But on the reverse side, usability is a concern. Most common user interfaces for IRC clients or platforms aren’t always intuitive. People from parts of the world with unstable Internet connections are challenged with remaining connected to participate in conversation. Many people have tried addressing this problem before, but none have come as far as Riot.

What is Riot? 🔗

Riot is a free, open source, and multi-platform client based on the Matrix protocol. To understand better, think of Matrix as the protocol and Riot as the client. Matrix is a decentralized, secure, messaging protocol. It has the benefit of using HTTP / JSON APIs, is capable of sending and receiving messages with full end-to-end encryption, WebRTC VoIP / video calling, and maybe most importantly, integration capabilities. Matrix was built to integrate with IRC servers and other communication protocols, meaning you can use the Riot client as an IRC bouncer. You can read more of the details on what separates Matrix from Riot on their FAQ.

As a result, Riot becomes most useful in its implementation as the default Matrix client. It’s convenient and decentralized, as anyone is able to launch their own Matrix “homeserver” and connect it with Riot. However, Matrix by default has servers bridged with Freenode, Mozilla IRC, and more. This lets you use Riot as a persistent client that keeps you connected to IRC even when you’re not there.

Outside of the web application, you can also find it as a desktop application for Mac, Windows, and Linux, or a mobile application for iOS and Android. In this guide, you’ll learn how to get started using Riot as a full-time messaging client with the default Matrix / IRC integration servers.

Register and get a client 🔗

First, you’ll need to grab an account from Riot’s website. Registration is straightforward and shouldn’t take you much time. You can find the registration form here. Once you’re registered and have confirmed your email, you’ll need to get the Riot applications on your devices of choice.

Desktop clients 🔗

There are desktop clients available for Windows, macOS, and Linux. If you’re running Windows or macOS, you can download the right version for your desktop on the Riot downloads page. If you’re using Debian, Ubuntu, or a related operating system, you can add a repository to your system to install the Riot desktop client. You can read this guide on how to add the repository and install Riot to your system.

Fedora 🔗

Riot is not yet officially packaged in Fedora’s repositories. However, there is a third-party Copr repository where the desktop application is packaged. Until it makes it into Fedora’s repositories, you can use this version to get started with Riot. You can find the Copr project and install instructions here.

Mobile clients 🔗

Want to have Riot integrated on your phone or prefer a mobile client? You can also find official versions of Riot on iOS, Google Play Store, and F-Droid. Using any of the mobile clients will integrate fully with a desktop client, if you choose to use both. This guide will focus more on the desktop clients.

Setting up Freenode in Riot 🔗

Riot currently supports eight IRC networks: Freenode, Moznet, Snoonet, OFTC, GIMPNet, Foonetic, Rizon, and EsperNet. Although you can use any network you like and the instructions will mostly be the same, this guide focuses on using Freenode.

Joining your first channel 🔗

One of the first things you’ll see after signing into Riot is the directory. In the directory, you can search through chat rooms on Matrix itself or any of the other IRC servers that are integrated. To join your first channel, you can select the IRC channel of choice in the dropdown menu and search for a channel.

For example, if we want to find #opensource.com on Freenode, you can select the Freenode option and search for #opensource.com. Once it’s there, you can join and say hello to the rest of the Opensource.com community hanging out in IRC.

Alternatively, if you would prefer directly joining a room, you can type the following as a command from any chat window in Riot.

/join #freenode_#channelname:matrix.org

Setting your IRC nick 🔗

By default, your IRC nick, or username, will be similar to your display name in Riot. Sometimes it will have a [m] appended to the end. However, after you connect to a channel, you can change your nick on the IRC side as well. You’ll need to start a new conversation with the IRC integration bot between Riot and Freenode.

In the bottom left corner of your Riot client, you can start a new personal chat with any user. To message the IRC integration bot, start a new chat with @appservice-irc:matrix.org. This will put you and the bot together in a private chat. To change your nick, send the following command to the bot:

!nick irc.freenode.net <IRC nick>

You should receive a confirmation message, similar to: “Nick changed from ‘OldNick’ to ‘NewNick.’” For more help, you can read the official documentation on changing your nick.

Authenticating with NickServ 🔗

One of the other vital functions you might need to do is authenticate with NickServ. This is especially important if you want to use your registered IRC nick or are a member of invite-only channels. However, it’s possible to do this too.

You’ll need to start another direct chat again. This time, you can search for the user @freenode_NickServ:matrix.org. This will put you into a private message with NickServ on Freenode’s servers. To authenticate, you can send a message just like you normally would.

IDENTIFY <username> <password>

After doing this, you should receive the normal confirmation that you are now logged in as your account. Remember to use caution when opening this chat in a public place, as your password will be displayed in plaintext whenever you open that direct message with NickServ.

Say hello! 🔗

Once you’ve joined a channel, claimed your nick, and authenticated with NickServ, you will be all set to begin using Riot. In any channel bridged in IRC with Matrix, all of your messages from Riot will show up in the IRC channel. Riot can also act like an IRC bouncer that keeps you persistently connected. Whenever you open Riot, you will be able to see a log of past discussions even if you weren’t connected to the Internet.

Both Matrix and Riot are open source projects. You can find Matrix’s code and Riot’s code on GitHub. If you want to better understand how the integration bridge works, you can read this blog post by one of the developers.

Have any comments or stories to share about using Riot? Are you already using it for IRC? Share your comments with us down below!

This is a short series to introduce Kubernetes, what it does, and how to experiment with it on Fedora. This is a beginner-oriented series to help introduce some higher level concepts and give examples of using it on Fedora. In the first post, we covered key concepts in Kubernetes. This second post shows you how to build a single-node Kubernetes deployment on your own computer.

Once you have a better understanding of what the key concepts and terminology in Kubernetes are, getting started is easier. Like many programming tutorials, this tutorial shows you how to build a “Hello World” application and deploy it locally on your computer using Kubernetes. This is a simple tutorial because there aren’t multiple nodes to work with. Instead, the only device we’re using is a single node (a.k.a. your computer). By the end, you’ll see how to deploy a Node.js application into a Kubernetes pod and manage it with a deployment on Fedora.

This tutorial isn’t made from scratch. You can find the original tutorial in the official Kubernetes documentation. This article adds some changes that will let you do the same thing on your own Fedora computer.

Introducing Minikube 🔗

Minikube is an official tool developed by the Kubernetes team to help make testing it out easier. It lets you run a single-node Kubernetes cluster through a virtual machine on your own hardware. Beyond using it to play around with or experiment for the first time, it’s also useful as a testing tool if you’re working with Kubernetes daily. It does support many of the features you’d want in a production Kubernetes environment, like DNS, NodePorts, and container run-times.

Installation 🔗

This tutorial requires virtual machine and container software. There are many options you can use. Minikube supports virtualbox, vmwarefusion, kvm, and xhyve drivers for virtualization. However, this guide will use KVM since it’s already packaged and available in Fedora. We’ll also use Node.js for building the application and Docker for putting it in a container.

Pre-requirements 🔗

You can install the prerequisites with this command.

$ sudo dnf install kubernetes libvirt-daemon-kvm kvm nodejs docker

After installing these packages, you’ll need to add your user to the right group to let you use KVM. The following commands will add your user to the group and then update your current session for the group change to take effect.

$ sudo usermod -a -G libvirt $(whoami)
$ newgrp libvirt

Docker KVM drivers 🔗

If using KVM, you will also need to install the KVM drivers to work with Docker. You need to add Docker Machine and the Docker Machine KVM Driver to your local path. You can check their pages on GitHub for the latest versions, or you can run the following commands for specific versions. These were tested on a Fedora 25 installation.

Docker Machine 🔗

$ curl -L https://github.com/docker/machine/releases/download/v0.12.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine
$ chmod +x /tmp/docker-machine
$ sudo cp /tmp/docker-machine /usr/local/bin/docker-machine

Docker Machine KVM Driver 🔗

This installs the CentOS 7 driver, but it also works with Fedora.

$ curl -L https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-centos7 >/tmp/docker-machine-driver-kvm
$ chmod +x /tmp/docker-machine-driver-kvm
$ sudo cp /tmp/docker-machine-driver-kvm /usr/local/bin/docker-machine-driver-kvm

Installing Minikube 🔗

The final step for installation is getting Minikube itself. Currently, there is no package in Fedora available, and official documentation recommends grabbing the binary and moving it your local path. To download the binary, make it executable, and move it to your path, run the following.

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ chmod +x minikube
$ sudo mv minikube /usr/local/bin/

Now you’re ready to build your cluster.

Create the Minikube cluster 🔗

Now that you have everything installed and in the right place, you can create your Minikube cluster and get started. To start Minikube, run this command.

$ minikube start --vm-driver=kvm

Next, you’ll need to set the context. Context is how kubectl (the command-line interface for Kubernetes) knows what it’s dealing with. To set the context for Minikube, run this command.

$ kubectl config use-context minikube

As a check, make sure that kubectl can communicate with your cluster by running this command.

$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Build your application 🔗

Now that Kubernetes is ready, we need to have an application to deploy in it. This article uses the same Node.js application as the official tutorial in the Kubernetes documentation. Create a folder called hellonode and create a new file called server.js with your favorite text editor.

var http = require('http');

var handleRequest = function(request, response) {
 console.log('Received request for URL: ' + request.url);
 response.writeHead(200);
 response.end('Hello world!');
};
var www = http.createServer(handleRequest);
www.listen(8080);

Now try running your application and running it.

$ node server.js

While it’s running, you should be able to access it on localhost:8080. Once you verify it’s working, hit Ctrl+C to kill the process.

Create Docker container 🔗

Now you have an application to deploy! The next step is to get it packaged into a Docker container (that you’ll pass to Kubernetes later). You’ll need to create a Dockerfile in the same folder as your server.js file. This guide uses an existing Node.js Docker image. It exposes your application on port 8080, copies server.js to the image, and runs it as a server. Your Dockerfile should look like this.

FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js

If you’re familiar with Docker, you’re likely used to pushing your image to a registry. In this case, since we’re deploying it to Minikube, you can build it using the same Docker host as the Minikube virtual machine. For this to happen, you’ll need to use the Minikube Docker daemon.

$ eval $(minikube docker-env)

Now you can build your Docker image with the Minikube Docker daemon.

$ docker build -t hello-node:v1 .

Huzzah! Now you have an image Minikube can run.

Create Minikube deployment 🔗

If you remember from the first part of this series, deployments watch your application’s health and reschedule it if it dies. Deployments are the supported way of creating and scaling pods. kubectl run creates a deployment to manage a pod. We’ll create one that uses the hello-node Docker image we just built.

$ kubectl run hello-node --image=hello-node:v1 --port=8080

Next, check that the deployment was created successfully.

$ kubectl get deployments
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-node   1         1         1            1           30s

Creating the deployment also creates the pod where the application is running. You can view the pod with this command.

$ kubectl get pods
NAME                          READY     STATUS    RESTARTS   AGE
hello-node-1644695913-k2314   1/1       Running   0          3

Finally, let’s look at what the configuration looks like. If you’re familiar with Ansible, the configuration files for Kubernetes also use easy-to-read YAML. You can see the full configuration with this command.

$ kubectl config view

kubectl does many things. To read more about what you can do with it, you can read the documentation.

Create service 🔗

Right now, the pod is only accessible inside of the Kubernetes pod with its internal IP address. To see it in a web browser, you’ll need to expose it as a service. To expose it as a service, run this command.

$ kubectl expose deployment hello-node --type=LoadBalancer

The type was specified as a LoadBalancer because Kubernetes will expose the IP outside of the cluster. If you were running a load balancer in a cloud environment, this how you’d provision an external IP address. However, in this case, it exposes your application as a service in Minikube. And now, finally, you get to see your application. Running this command will open a new browser window with your application.

$ minikube service hello-node

Congratulations, you deployed your first containerized application via Kubernetes! But now, what if you need to our small Hello World application?

How do we push changes? 🔗

The time has come when you’re ready to make an update and push it. Edit your server.js file and change “Hello world!” to “Hello again, world!”

response.end('Hello again, world!');

And we’ll build another Docker image. Note the version bump.

$ docker build -t hello-node:v2 .

Next, you need to give Kubernetes the new image to deploy.

$ kubectl set image deployment/hello-node hello-node=hello-node:v2

And now, your update is pushed! Like before, run this command to have it open in a new browser window.

$ minikube service hello-node

If your application doesn’t come up any different, double-check that you updated the right image. You can troubleshoot by getting a shell into your pod by running the following command. You can get the pod name from the command run earlier (kubectl get pods). Once you’re in the shell, check if the server.js file shows your changes.

$ kubectl exec -it <pod-name> bash

Cleaning up 🔗

Now that we’re done, we can clean up the environment. To clear up the resources in your cluster, run these two commands.

$ kubectl delete service hello-node
$ kubectl delete deployment hello-node

If you’re done playing with Minikube, you can also stop it.

$ minikube stop

If you’re done using Minikube for a while, you can unset Minikube Docker daemon that we set earlier in this guide.

$ eval $(minikube docker-env -u)

Learn more about Kubernetes 🔗

You can find the original tutorial in the Kubernetes documentation. If you want to read more, there’s plenty of great information online. The documentation provided by Kubernetes is thorough and comprehensive.

Questions, Minikube stories, or tips for beginners? Add your comments below.

This article is part of a short series that introduces Kubernetes. This beginner-oriented series covers some higher level concepts and gives examples of using Kubernetes on Fedora.

The information technology world changes daily, and the demands of building scalable infrastructure become more important. Containers aren’t anything new these days, and have various uses and implementations. But what about building scalable, containerized applications? By itself, Docker and other tools don’t quite cut it, as far as building the infrastructure to support containers. How do you deploy, scale, and manage containerized applications in your infrastructure? This is where tools such as Kubernetes comes in. Kubernetes is an open source system that automates deployment, scaling, and management of containerized applications. Kubernetes was originally developed by Google before being donated to the Cloud Native Computing Foundation, a project of the Linux Foundation. This article gives a quick precursor to what Kubernetes is and what some of the buzzwords really mean.

What is Kubernetes? 🔗

Kubernetes simplifies and automates the process of deploying containerized applications at scale. Just like Ansible orchestrates software, Kubernetes orchestrates deploying infrastructure that supports the software. There are various “layers of the cake” that make Kubernetes a strong solution for building resilient infrastructure. It also assists with making systems that can grow at scale. If your application has increasing demands such as higher traffic, Kubernetes helps grow your environment to support increasing demands. This is one reason why Kubernetes is helpful for building long-term solutions for complex problems (even if it’s not complex… yet).

At a high level overview, imagine three different layers.

• Users: People who deploy or create containerized applications to run in your infrastructure
• Master(s): Manages and schedules your software across various other machines, for example in a clustered computing environment
• Nodes: Various machines to support the application, called kubelets

These three layers are orchestrated and automated by Kubernetes. One of the key pieces of the master (not included in the visual) is etcd. etcd is a lightweight and distributed key/value store that holds configuration data. Each node, or kubelet, can access this data in etcd through a HTTP/JSON API interface. The components of communication between master and node such as etcd are explained in the official documentation.

Another important detail not shown in the diagram is that you might have many masters. In a high-availability (HA) set-up, you can keep your infrastructure resilient by having multiple masters in case one happens to go down.

Terminology 🔗

It’s important to understand the concepts of Kubernetes before you start to play around with it. There are many core concepts in Kubernetes, such as services, volumes, secrets, daemon sets, and jobs. However, this article explains four that are helpful for the next exercise of building a mini Kubernetes cluster. The three concepts are pods, labels, replica sets, and deployments.

Pods 🔗

If you imagine Kubernetes as a Lego® castle, pods are the smallest block you can pick out. By themselves, they are the smallest unit you can deploy. The containers of an application fit into a pod. The pod can be one container, but it can also be as many as needed. Containers in a pod are unique since they share the Linux namespace and aren’t isolated from each other. In a world before containers, this would be similar to running an application on the same host machine.

When the pods share the same namespace, all the containers in a pod:

• Share an IP address
• Share port space
• Find each other over localhost
• Communicate over IPC namespace
• Have access to shared volumes

But what’s the point of having pods? The main purpose of pods is to have groups of “helping” containers on the same namespace (co-located) and integrated together (co-managed) along with the main application container. Some examples might be logging or monitoring tools that check the health of your application, or backup tools that act when certain data changes.

In the big picture, containers in a single pod are always scheduled together too. However, Kubernetes doesn’t automatically reschedule them to a new node if the node dies (more on this later).

Labels 🔗

Labels are a simple but important concept in Kubernetes. Labels are key/value pairs attached to objects in Kubernetes, like pods. They let you specify unique attributes of objects that actually mean something to humans. You can attach them when you create an object, and modify or add them later. Labels help you organize and select different sets of objects to interact with when performing actions inside of Kubernetes. For example, you can identify:

• Software releases: Alpha, beta, stable
• Environments: Development, production
• Tiers: Front-end, back-end

Labels are as flexible as you need them to be, and this list isn’t comprehensive. Be creative when thinking of how to apply them.

Replica sets 🔗

Replica sets are where some of the magic begins to happen with automatic scheduling or rescheduling. Replica sets ensure that a number of pod instances (called replicas) are running at any moment. If your web application needs to constantly have four pods in the front-end and two in the back-end, the replica sets are your insurance that number is always maintained. This also makes Kubernetes great for scaling. If you need to scale up or down, change the number of replicas.

When reading about replica sets, you might also see replication controllers. They are somewhat interchangeable, but replication controllers are older, semi-deprecated, and less powerful than replica sets. The main difference is that sets work with more advanced set-based selectors – which goes back to labels. Ideally, you won’t have to worry about this much today.

Even though replica sets are where the scheduling magic happens to help make your infrastructure resilient, you won’t actually interact with them much. Replica sets are managed by deployments, so it’s unusual to directly create or manipulate replica sets. And guess what’s next?

Deployments 🔗

Deployments are another important concept inside of Kubernetes. Deployments are a declarative way to deploy and manage software. If you’re familiar with Ansible, you can compare deployments to the playbooks of Ansible. If you’re building your infrastructure out, you want to make sure it is easily reproducible without much manual work. Deployments are the way to do this.

Deployments offer functionality such as revision history, so it’s always easy to rollback changes if something doesn’t work out. They also manage any updates you push out to your application, and if something isn’t working, it will stop rolling out your update and revert back to the last working state. Deployments follow the mathematical property of idempotence, which means you define your specs once and use them many times to get the same result.

Deployments also get into imperative and declarative ways to build infrastructure, but this explanation is a quick, fly-by overview. You can read more detailed information in the official documentation.

Installing on Fedora 🔗

If you want to start playing with Kubernetes, install it and some useful tools from the Fedora repositories.

sudo dnf install kubernetes

This command provides the bare minimum needed to get started. You can also install other cool tools like cockpit-kubernetes (integration with Cockpit) and kubernetes-ansible (provisioning Kubernetes with Ansible playbooks and roles).

Learn more about Kubernetes 🔗

If you want to read more about Kubernetes or want to explore the concepts more, there’s plenty of great information online. The documentation provided by Kubernetes is fantastic, but there are also other helpful guides from DigitalOcean and Giant Swarm. The next article in the series will explore building a mini Kubernetes cluster on your own computer to see how it really works.

Questions, Kubernetes stories, or tips for beginners? Add your comments below.

When people first think of “open source”, their mind probably first goes to code. Something technical that requires an intermediate understanding of computers or programming languages. But open source is a broad concept that goes beyond only binary bits and bytes. Open source projects hold great regard for community participation. The community is a fundamental piece of a successful open source project. For my experience getting involved with open source, I began in the community and worked my way around from there. At the age of fifteen, I was beginning my open source journey and I didn’t even know it.

Gaming introduces open source 🔗

One of my strongest memories of a “gaming addiction” was when I was fifteen and a younger cousin introduced me to the game Minecraft. The game was in beta then, but I remember the sandbox-style of the game entertaining the two of us for hours. But what I discovered was that playing the game alone became boring. Playing and mining with others made the experience more fun and meaningful. In order to do this, I learned I would have to host a server for my friends to connect to play with me.

I originally used the “vanilla” Minecraft server software at first, but it was limited to what it could do, and didn’t compare to other multiplayer servers in existence. They all seemed to be using something that offered more, so players could play games, cast spells, or do other unique things that would normally not be possible in the game. After digging, I discovered Bukkit, an open source Minecraft server software with an extensible API to let developers change the multiplayer experience. I soon became wrapped up with Bukkit like a child with a new toy. Except this toy had me digging through my computer to set up “port forwarding”, “setting NAT records”, and “creating static IP addresses”. I was teaching myself the basics of computer networking in the guise of creating a game server for my friends.

Over time, my Minecraft server hobby began to take up more and more time. More people began playing on my server and I began searching for ways to improve the performance of my server. After doing some digging, I discovered the SpigotMC project, shortened to just Spigot. Spigot was a fork of the Bukkit project that made specific enhancements to performance. After trialing it on my server, I discovered the performance gains were measurable and I would commit to using Spigot from then on.

Participating in SpigotMC 🔗

Before long, I began running into new challenges with managing my Minecraft server community, whether it was finding ways to scale or finding the best ways to build a community up. In October 2013, I registered an account on the Spigot forums to talk with other server owners and seek advice on ways I could improve. I found the community welcoming and accepting to helping me learn and improve. Several people in the community were owners of larger servers or developers of unique plugins to Spigot. In response to my detailed inquisitions, they responded with genuine and helpful feedback and support. Within a week, I was already in love with the people and helpfulness of the Spigot community.

I became an active participant in the forum community in Spigot. Through the project, I was introduced to IRC and how to use it for communicating with other server owners and developers. What I didn’t realize was a trend in my behavior. Over time, I began shifting away from asking all the questions. Almost as if in a role reversal, I became the one answering questions and helping support other new server owners or developers. I became the one in an advisory role instead of the one always asking.

In April 2014, the project lead of Spigot reached out to me asking if I would consider a role as a community staff member. Part of my responsibilities would be responding to reports, encouraging a helpful and friendly community, and maintaining the atmosphere of the community. With as much prestige and honor as my sixteen-year-old self could muster, I accepted and began serving as a community moderator. I remember feeling privileged to serve the position – I would finally get to help the community that had done so much to help me.

Expanding the open source horizon 🔗

Through 2014 and 2015, I actively served as a moderator of the community, both in the forums and the IRC network for Spigot. I remained in the Spigot community as the project steadily grew. It was incredible to see how the project was attracting more and more users.

However, my open source journey did not end there. After receiving my high school diploma in May 2015, I had set my sights on the Rochester Institute of Technology, a school I noted as having the country’s only Free and Open Source Software minor. By coincidence, I also noticed that my preferred Linux distribution, Fedora, was holding its annual contributor conference in Rochester, a week before I would move in for classes. I decided I would make the move up early to see what it was all about.

Flock 2015 introduces Fedora 🔗

The summer passed, and before I knew I was ready, I was packing up from my home outside of Atlanta, Georgia to leave for Rochester, New York. After fourteen hours of driving, I finally arrived and began moving into my new home. A day after I arrived, Flock was slated to begin, marking my first journey in Rochester.

At Flock, I entered as an outsider. I was in an unfamiliar city with unfamiliar people and an open source project I was only mildly familiar with. It was all new to me. But during that week, I discovered a community of people who were united around four common ideals. Freedom, Friends, Features, First: the Four Foundations of the Fedora Project were made clear to me. The community members at Flock worked passionately towards advancing their project during the talks and workshops. And after the talks finished, they gathered together for hallway discussions, sharing drinks, and enjoying the presence of their (usually) internationally dispersed team. Without having ever attended a Fedora event before, I knew that the Four Foundations and the community behind Fedora were the real deal. Leaving Flock that year, I vowed to pursue becoming a part of this incredible community.

Pen to paper, keyboard to post 🔗

The first major step I took towards contributing to the Fedora Project was in September 2015, during Software Freedom Day. Then Fedora Community Action and Impact Coordinator Remy DeCausemaker was in attendance representing Fedora. During the event, I reached out to the Fedora Magazine editorial team asking to become involved as a writer. By the end of September, I penned my first article for the Fedora Magazine, tying in my experience in the Spigot community to Fedora: run a Minecraft server using Spigot.

My first step getting involved with the Fedora community was an exciting one. I remember feeling proud and excited to see my first article published on the front page, not only helping Fedora, but also helping Spigot. I realized then that it was relatively straightforward to contribute this kind of content, and I would keep writing about software I was familiar with for the Magazine.

As I continued writing posts for the Fedora Magazine, I became aware of another team forming up in Fedora: the Community Operations, or CommOps, team. I subscribed to their mailing list, joined the IRC channel, and attended the first meetings. Over time, I became wrapped up and involved with the community efforts within Fedora. I slowly found one thing leading to another.

Today in Fedora, I am the leading member of the Community Operations (CommOps) team, the editor-in-chief of the Fedora Magazine, a Marketing team member, an Ambassador of North America, a leading member of the Diversity Team, and a few other things.

Advice for other students 🔗

When you’re first getting started, it can sometimes be tough and a little confusing. As students getting involved with FOSS, there are a few challenges that we might have to face. A lot of this can be with making the first steps into a new project. There are countless open source projects of various sizes and they all do things a bit differently from others, so the process changes from project to project.

One of the most obvious challenges with getting involved is your personal experience level. Especially when getting started, it can be easy to look at a large project or well-known project and see all the work devoted there. There are smart and active people working on these projects, and many times their contributions are quite impressive! One of the many concerns I’ve seen other students here face (including myself at first) is wondering how someone with beginning to moderate experience or knowledge can get involved, in comparison to some of these contributions from active contributors. If it’s a large project, like Fedora, it can be intimidating to think where to start when there’s so many things to do and areas to get involved with. But if you think of it all as one big project, it is intimidating and difficult for you to make that first step.

Break a bigger project into smaller pieces. Start small and look for something you can help with. A healthy open source project usually will have things like easyfix bugs that are good ones to start with if it’s your first time contributing. Keep an eye out for those if you’re getting started.

Another challenge you might face as a student or beginner to open source is something called imposter syndrome. For me, this was something I had identified with before I knew what it was. For a definition, I’ll pull straight from Wikipedia first: " Term referring to high-achieving individuals marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

Imposter syndrome can be a common feeling as you get involved with open source, especially if comparing yourself to some of those active and smart contributors that you meet as you become involved. But you should also remember you are a student – comparing yourself or your contributions to a professional or someone with years of experience isn’t fair to yourself! It’s not apple-to-apples. Your contributions as you get involved with open source are worthy and valuable to an open source project regardless of how deep, how many, or how much time you spend on the project. Even if it’s a couple of hours in the week, that’s saving others those couple of hours and it’s adding something into the project. A contribution is a contribution – it’s a bad idea to rate the worth of contributions to other contributions.

Those are some of the challenges that are useful to know and understand as you become more involved with FOSS. If you know the challenges you are up against, it makes it easier to handle them as they come.

There are also benefits to contributing to open source as a student as well. Contributing to open source is a great way for you to take knowledge and info you have learned from classes and begin applying it to real-world projects and gain experience. It’s one thing to take you to the next level as a student. If you are contributing to a project in the real world, that is unique experience that is helpful for you for future career outlooks as well.

It’s also a great networking opportunity. In open source, you meet many incredible and smart people. In my time in Fedora, I’ve met many contributors and had various mentors help me get involved. I’ve made new friends and met people who I normally would never have had the opportunity to meet.

There are also opportunities for leadership in open source projects. Whether it’s just one task, one bug, or even a role, you might find that sometimes all it takes is someone willing to say, “I’ll do this!” to have leadership on something. It might be challenging or difficult at first, but it’s a great way for you to understand working in team environments, how to work effectively even if you’re remote, and how to break down a task and work on finding solutions for complex problems.

Lastly, it’s important for younger people to become more involved with open source communities. As students and younger community members, we add unique perspective and ideas to open source projects. It’s important to a healthy community for an open source project and any open source project worth contributing to should be welcoming and accepting to students who are willing to spend time working on the project and helping solve those problems, whether they’re bugs, tasks, or other things. In short, there is absolutely a role for students getting involved with open source!

Bad puns aside, I am actually enormously excited to announce that I am participating in this year’s Google Summer of Code program for the Fedora Project. If you are unfamiliar with Google Summer of Code (or often shortened to GSoC), Google describes it as the following.

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school.

I will work with the Fedora Project over the summer on the CommOps slot. As part of my proposal, I will assist with migrating key points of communication in Fedora, like the Fedora Magazine and Community Blog, to Ansible-based installations. I have a few more things planned up my sleeve too.

Google Summer of Code proposal 🔗

My proposal summary is on the GSoC 2016 website. The full proposal is available on the Fedora wiki.

The What 🔗

The Community Blog is becoming an important part of the Fedora Project. This site is a shared responsibility between CommOps and the Infrastructure team. Unlike most applications in the Fedora infrastructure, the Community Blog is not based off Ansible playbooks. Ansible is an open-source configuration management suite designed to make automation easier. Fedora already uses Ansible extensively across its infrastructure.

My task would consist of migrating the Community Blog (and by extension, Fedora Magazine) to an Ansible-based set up and writing the documentation for any related SOPs.

The Why 🔗

Ansible is a useful tool to make automation and configuration easier. In their current set up, the Community Blog and Fedora Magazine are managed separately from each other, and are managed by a single member of the Infrastructure team. By moving them to Ansible-based installations and merging the WordPress bases together, it provides the following benefits:

1. Makes it easier for other Infrastructure team members to fix, maintain, or apply updates to either site
2. Prevents duplicate work by maintaining a single, Ansible-based WordPress install versus two independent WordPress sites
3. Creates a standard operating procedure for hosting blog platforms within Fedora (can be used for other extensions in the future)

Thanks to my mentors 🔗

I would like to issue a special thanks to my mentors, Patrick Uiterwijk and Remy DeCausemaker. Patrick will be my primary mentor for the slot, as a member of the Fedora Infrastructure team. I will be working closest with him in the context of my proposal. I will also be working with Remy on the “usual” CommOps tasks that we work on week by week.

Another thanks goes out to all of those in the Fedora community who have positively affected and influenced my contributions. Thanks to countless people, I am happy to consider Fedora my open source home for many years to come. There is so much to learn and the community is amazing.

Getting started 🔗

As of the time of publication, the Community Bonding period is currently happening. The official “coding” time hasn’t started yet. Without much delay, I will be meeting up with Patrick and Remy later today in a conference call to check in after the official announcement, make plans for what’s coming up in the near future, and become more acquainted with the Infrastructure community.

In addition to our conference call, I’m also planning on (formally) attending the next Fedora Infrastructure meeting on Thursday. Shortly afterwards, I hope to begin my journey as an Infrastructure apprentice and learn more about the workflow of the team.

Things are just getting started for the summer and I’m beyond excited that I will have a paid excuse to work on Fedora full-time. Expect more check-ins as the summer progresses!

This post serves as the project proposal for me and my team’s Humanitarian Free and Open Source Software Development “Final Project”.

In this project proposal, we take a look at the game idea we are looking at completing for this project, based on the New York 4th grade math curriculum. Our game idea is based off of a minigame from Logical Journey of the Zoombinis, a puzzle-solving educational game.

Team Members 🔗

Project 🔗

PyCut, a pizza-making puzzle game

Description 🔗

PyCut will be a simple puzzle game to teach children basic units of measurement and guiding them to think creatively to solve a problem. Our game is inspired by the Pizza Pass level of Logical Journey of the Zoombinis (1996). The purpose of the game is to use pizza creation as the activity to teach these skills.

Team Member Roles 🔗

Stephen, Justin, and Wilfried 🔗

All team members will be responsible for contributing to the code via pull requests on GitHub. Testing, refactoring, and refining the code is also everyone’s responsibility.

We are currently working on the details of which team members are responsible for the specific aspects of our project. We will have a better idea of this after completing the development plan later this week.

Source Code Repository URL 🔗

jflory7/PyCut

Communication Methods 🔗

The following methods of communication are ordered in the most preferred way to the least. These are the tools we will use internally while working on the project.

1. Our Slack team (IGME582)
2. Issue tracker on GitHub
3. In-person communication for when we meet up as a team (FOSShours have been designated for in-person collaboration)

What are the easy parts? 🔗

• Project seems pretty easily scoped. We have a curriculum to work with and we have inspiration from the original Zoombinis minigame.
• We have a lot of resources to reach out to for help when needed. #rit-foss on freenode, past developers for the HFOSS project, and more.
• Two experienced Python developers (Wilfried, Stephen), two members familiar with open source project collaboration (Justin, Wilfried) on the team.
• We have multiple previous projects to use as examples (see: FOSSRIT).

What are the hard parts? 🔗

• None of us ever created a game for Sugar on a Stick before. We aren’t sure of the scope of this task, so it will be difficult to estimate a time frame for completion.
• Ensuring that our activity meets the learning objectives of 4th graders. As college students, it may be very easy for us to assume that some elements of the game are easy, but may actually be difficult for 4th grade students. Keeping it within that scope will be a challenge.

How will you overcome both? 🔗

• Communication and setting milestones
  • We are confident that we can pace out our project effectively and get it done on time.
• Past resources and inspiration
  • Again, we have countless resources to refer to and get help from. As we run into problems, we have plenty of options for resolving them.

This post serves as the project proposal for me and my team’s Humanitarian Free and Open Source Software Development “Community Architecture” project (shortened to CommArch)!

In this project proposal, we take a preliminary look at the project we’re looking at analyzing, Tahrir, and the different criteria we are assigned to look at.

Team Members 🔗

Project 🔗

Tahrir by the Fedora Project

Description 🔗

Tahrir is a Pyramid app for distributing your own custom badges (based off of Mozilla Open Badges). The back-end is written in Python with an HTML/CSS and JavaScript front-end and the project is a smaller part of the Fedora Project.

Team Member Roles 🔗

Justin and Wilfried 🔗

1. Project Report I-R
2. git_by_a_bus

Stephen and Bobby 🔗

1. Project Report A-H
2. Calloway Coefficient of Fail

Source Code Repository URL 🔗

fedora-infra/tahrir

Upstream Mentors 🔗

Communication Methods 🔗

The following methods of communication are ordered in the most preferred way to the least.

1. IRC channel on freenode (#fedora-apps)
2. Issue tracker on GitHub
3. Mailing list via infrastructure@lists.fedoraproject.org

What are the easy parts? 🔗

• Project is fairly small (even though it is part of a larger project)
• People to ask for help when needed
• Git-by-a-bus is going to make analytics of contributors super easy
• Distribution of work will allow us to complete the project in a timely manner

What are the hard parts? 🔗

• Lack of a frame of reference for some team members who have never worked with open source projects in the past (e.g. we are unable to compare activity or its community to other projects)
• Since the project is a smaller project inside of a larger one (Fedora Project), it will be challenging to look at it in a modular sense
• Separation of dependencies from project requirements (Open Badges requirements and Tahrir requirements)

How will you overcome both? 🔗

Hard Stuff 🔗

• We have two people who are more advanced at hacking who can hopefully guide the two who aren’t through the project, effectively eliminating the lack of reference point.
• Three of our members are not people involved in the Fedora Project, and as such won’t be distracted by its involvement with Fedora and will only look at the project itself.
• Read up on the existing documentation and test the various endpoints of the project to identify what is needed with Open Badge and what the project is implementing itself.

Step 1: Identifying the bugfix 🔗

møte 🔗

When I started this homework assignment, there was originally one project I had in mind. As a non-code contributor to the Fedora Project, I frequently interact with Fedora’s own implementation of Meetbot. Meetbot is an IRC bot that adds meeting functionality to IRC channels. It makes it easy to highlight important info and summarize the meeting into a tidy HTML summary afterwards.

Fedora has a custom front-end for the Meetbot bot. This project is called møte and is developed by Fedora contributors Chaoyi Zha, Ralph Bean, and many others. One of its features is clustering Fedora sub-projects into teams and sorting their meetings together with JSON mappings.

Some Fedora sub-projects do not have their alias or meeting names set in these JSON files, making it difficult for their own team members or the general public from finding the records of their meetings. This inadvertently reduces transparency. Seeing as Fedora is an open project not only in code, but also in action, it made sense to try to clarify these mappings in a better way.

FOSSProfiles 🔗

More recently than møte, I am working with Prof. Stephen Jacobs this semester with FOSS@MAGIC. I am on an independent study on Open Source Journalism to help assist with marketing and growing additional exposure for the program. The website for the program is dated in its current form, and one of the goals this semester is to get it rewritten with a more modern, up-to-date layout and information.

One thing we want to have on the site is profiles of our students, alumni, mentors, and faculty. A Jinja-powered HTML generator for student profiles was made over a year ago, titled FOSSProfiles. In this project, students add their information to the repo in the form of YAML files. A user runs a Python script, and the program generates a raw HTML template with all of the students’ information in the repository. Wow! Useful.

When I went to try running it, I immediately ran into an issue and the program spat out a stacktrace at me. After troubleshooting the program and reading logs, I found two issues:

1. Student biography lines could not be over 140 characters
2. Python script did not support Python3

Step 2: Doing the bugfix 🔗

møte 🔗

My commits ranged throughout the month of January and I tried to accomplish a number of things. Before I cloned the repo and started making changes, I crawled around møte for a while to find any teams or meetings that may not have been added.

Thanks to the power of fedmsg, I was able to make a week of observations about teams that were frequently meeting in Fedora. As I observed for a week about what teams were active or inactive, I made bookmarks to their meeting pages to revisit later on.

After comparing the teams that were present in møte to the meetings I observed in a week, I began adding aliases and mappings for the teams that were lacking in the name_mappings.json file. I also added a new category to the category_mappings.json file for the Fedora Community Operations team (where I spend a lot of my own time in Fedora).

The Fedora teams I helped identify and add to møte are as follows.

• CommOps
• EMEA (Europe, Middle East, Africa) Ambassadors
• Fedora Council (formerly known as Fedora Board)
• LATAM (Latin America) Ambassadors
• Fedora Magazine editorial board meetings

During my time of my bugfix, I made 13 commits to the repository. I’m not planning to stop there, either – there’s a few more teams I hope to try adding to møte in the near future, like the Fedora Workstation, Server, and Cloud special interest groups.

Also in the process of contributing, I discovered a handful of problems and reported them in the issue tracker (see: #75 and #83).

You can see my bugfix changes live in møte here! Thanks Chaoyi for helping mentor me along in contributing.

FOSSProfiles 🔗

140 char maximum 🔗

My first step with this bugfix was in troubleshooting the stacktrace I was given running the program in Python2. The stacktrace confirmed the error was that a profile biography was over 140 characters long, and I began sorting through all existing profiles to find any that were over the limit. After a little bit of searching, I found that wilfriedE.yaml was the one over the 140 character limit. This was an easy correction and after making changes, I was able to run the program with Python2.

Python3 support 🔗

Lastly, I wanted to add support for Python3 to this program so it would run in a modern and current workstation. This in particular required a lot of research for me to look into as I had never programmed in Python before.

My first problem with running the script in Python3 was an ImportError for a specific module, ifilter. After searching for an answer, I found an easy fix. It was supported by default in Python3! To fix this error was as simple as removing the line.

Secondly, after fixing the ImportError, I found a certain string was required to be encoded as UTF-8 before Python3 was able to handle it. After looking up the encode() method and figuring out how it worked, I simply encoded the string to UTF-8. That wasn’t so bad…

Step 3: Post-bugfix analysis 🔗

For me, the most fun part was the optional part of the assignment to the end. As part of the assignment, we could add our projects to OpenHub. OpenHub is an aggregator of open source projects that makes it easy to discover, track, and compare open source projects across the web.

I added a project page for møte and FOSSProfiles and claimed my contributions as a contributor.

I’m also playing around with other projects in OpenHub… you can find my profile here.

This past year, I enrolled as a student at the Rochester Institute of Technology in Rochester, NY. For me, this is quite a distance from my hometown just outside of Atlanta, GA. Part of the motivation that led me to choose RIT as my university of choice was its participation in Free and Open Source Software education and communities. RIT is one of the few schools in the United States to offer a minor in Free and Open Source Software.

As part of my time here at RIT, I plan to take on the minor. This semester marks the first milestone of this specific track for me. I am taking the Humanitarian Free and Open Source Software (HFOSS) course, and the first assignment for our class was writing a blog post about getting introduced into the class.

HFOSS: My expectations 🔗

Going into the HFOSS course, I was reluctant because of my inexperience with programming as a whole. The course is definitely strongly focused towards a programming aspect, but it is not strictly dedicated to firing out open source code.

On the contrary, this course is an introduction to “FOSS” as a whole. What is it? What tools are used in open source? How do people communicate and contribute? Why work in the open? These are all questions that the course seems targeted towards answering. In order to answer these questions, many methods will be used, some ancillary to the programming that is necessary for many free and open source projects.

I expect this course to be a challenge because I know that I can’t escape working on a large project or two this semester that will push my abilities and require me to adapt to meet the requirements. I am not as worried about learning the tooling, culture, or common practices that go along with open source because I am moderately familiar with them already. That goes without saying, I am not a master of it all. In the big picture for this class, I feel like I will have a head-start in some areas, while in others I will have to double up to keep up.

HFOSS: What I plan to contribute 🔗

This semester, I’m also hoping to contribute back to the class as well as take something out of it. With some of my experience with open source tooling and understanding of how other projects work, I hope to share my own experiences when and where needed. Additionally, I am paying extra attention for open source communities or projects where I might be able to contribute especially closer to the end of the semester, to fulfill the humanitarian aspect of the course.

By default, the course is targeted towards the One Laptop Per Child (OLPC) program. Towards the end of the semester, the final project is creating a game on the hardware used on these machines with a spin towards 4th grade math curriculum in New York State. Another project I am a contributor of, the Fedora Project, has close ties to the OLPC program and helps develop the desktop environment used on the machines, Sugar on a Stick.

However, there is flexibility about what the final project could be on a per-student basis. Therefore, I am looking out for a particular project that I might feel a personal connection or passion towards where I feel I could help make an impact.

This sets the course and itinerary for the trip… we’ll see where I land as the semester progresses.