Managing the Kotlin Weekly
Planted January 25, 2020
Pruned June 9, 2025

I just sent the issue #182 of the Kotlin Weekly. #182 means that this has been the week 182 that the Kotlin Weekly is alive. Many things have changed since the first edition on the 7th of August 2017, sent to over 200 initial subscribers with 5 articles.
In some of the first editions, the content was so scarce that I ended up writing my own articles to include them, or adding some code snippets I posted on Twitter. Slowly and steadily, the evolution of Kotlin has followed a clear trend since then.
Trends for Kotlin according to Google trends. The spike in May 2017 corresponds to the Google I/O, where Kotlin official support for Android was announced.
Fast forward a few years, and today Kotlin is a trend that has arrived to stay. It regularly scales a few positions in most of the language popularity indexes, and more content is being generated by the community. Kotlin Weekly is a well-positioned thermometer to determine the health of the language, where we can count things such as subscribers, interaction with the mailing list, issues being submitted for publication, etc.
PYPL PopularitY of Programming Language index
The Kotlin Weekly has been increasing its influence and capacity to serve the Kotlin community. Last year we were Media Partners of the KotlinConf, Droidcon India and Droidcon. We have been quoted in some books as a central resource to learn and keep up with all the news in the Kotlin world. In Pusher State of Kotlin, the Kotlin Weekly was stated as the preferred Kotlin source outside of the JetBrains bubble.
Excerpt of Kotlin Blueprints
Kotlin Weekly has undergone a few changes since that initial version. The website changed from a very basic HTML into a decent website (courtesy of 47degrees), and there is now a professional design for the mailing list, including clustering of categories and an improved UX.
I have been tweaking the process I use to publish the Kotlin Weekly, under the principle of _working now in order to work less in the future (_AKA automation). Initially, it was a manually crafted project, where I used to fill in the articles I was receiving after some filtering. Over time, a few steps have been added that make the process easier, more pleasant and less error-prone. I would like to share today a few of the things I do.
Receiving content
Right now, there are three primary ways I have to receive the content: through the website, as an email, and via Twitter. Around 71% of all the content is sent via the Website, around 26% of the content is received via email, 2% via Twitter and the rest via different channels.
In some of the Pomodoro breaks I have, or during regular breaks, I read the content of every single article or library that is being sent. I add it later to a SQL Database that I have hosted in Amazon Cloud, where I store the author, URL, date, channel where the article was received, whether the article has been published or no, comments about that link and a field called quality. This last field goes from 1 to 3, and it is quite simple: 1 is the lowest value, and 3 is the highest value.
I do effectively read all the articles, and assign this value based on a personal perception:
- 3 means that it is an immediate candidate for publication.
- 2 means that it might need some re-evaluation (if there are quality issues, I contact the author suggesting them some changes).
- 1 means that the article cannot be right now considered for publication. These are not only quality issues, but can be referred to anything (articles with a thematic that does not fit the Kotlin Weekly, spam, etc).
The idea of keeping this database is to be able to extract statistics. I can easily check about which URL has been mostly highlighted, which author has more content published, etc. This information can be later used to improve how Kotlin Weekly operates, and serve better the subscribers.
Publishing content
Now things get more interesting. I use Mailchimp to publish the Kotlin Weekly, and the content is stored in a Firebase static page. I use CircleCI for CI/CD. The Firebase page needs to be generated each week, and the Mailchimp issue needs also to be crafted each week. Since I am now dealing with a design involving categories and a better UX design, I decided to write a script to generate all this HTML/CSS content, instead of manually writing the issue.
I have created this repository, Kotlin Weekly GenScript, where I include the GenScript I use (written obviously in Kotlin).
The GenScript takes a .yaml file, creates a .MD file that will be used on the website and generates all the HTML code that will be used in Mailchimp to write the issue.
`val filename = "2020-01-26"
val file = File("src/yamls/" + filename + ".yaml")
val result = Yaml.default.parse(Issue.serializer(), file.readText())
createMdFile(result, filename)
var html = _createHeader_(result.number.toString(), result.date)
html += _createTitle_(result.title)
result.announcements?._let_ **{** html += _createAnnouncements_(result.announcements) **}
**result.articles?._let_ **{** html += _createArticles_(result.articles) **}
**result.sponsored?._let_ **{** html += _createSponsored_(result.sponsored) **}
**result.android?._let_ **{** html += _createAndroid_(result.android) **}
**result.kotlinMultiplatformArticles?._let_ **{** html += _createMultiplatform_(result.kotlinMultiplatformArticles) **}
**result.videos?._let_ **{** html += _createVideos_(result.videos) **}
**result.jobs?._let_ **{** html += _createJobs_(result.jobs) **}
**result.podcast?._let_ **{** html += _createPodcast_(result.podcast) **}
**result.conferences?._let_ **{** html += _createConferences_(result.conferences) **}
**result.libraries?._let_ **{** html += _createLibraries_(result.libraries) **}**`
The .MD file is automatically copied into the folder where I store the static page created with Jekyll, that will later be uploaded into Firebase:
`//Copy file to the kotlin-weekly project
Runtime.getRuntime().exec("cp src/mds/"+filename+"-title.md ../kotlin-weekly/_posts/")
_println_("Moving to kotlin-weekly directory")
Runtime.getRuntime().exec("cd ../kotlin-weekly")`
As a nice side effect, I copy directly into the clipboard the entire HTML, so I just need to paste it into Mailchimp:
val clipboard = Toolkit.getDefaultToolkit()._systemClipboard
_clipboard.setContents(StringSelection(html), null)
After I commit the content from the Jekyll directory into GitHub, a hook will be triggered. This hook will build the Jekyll page, and automatically post it into Firebase.
CircleCI doing what is supposed to do.
With this mechanism, I can focus on writing the issue, rather than dealing with publishing it, fixing CSS problems (the hardest problem in Computer Science) or anything else.
Future work
There are a few other improvements I have on Kotlin Weekly’s pipeline:
- Automating the sponsorship of issues: right now the process of contacting sponsors and invoicing is very manual. Sponsors contact me, I send the price, explain some of the numbers, block the dates and create the invoice manually. I would like to set up this project automatically, with payment via PayPal.
- Publishing the Firebase Static Page automatically: I still need to commit to GitHub manually. I would like to automate this process via CircleCI.
- Contact via the website: the contact via the website is still a mailto: link, and I would like to remove mailto: and do it via a PHP script. Firebase Pages does not support PHP, so I might need to move everything into Amazon or Google Cloud.
- Download from my content database automatically the 10 candidates to be included each week. I would like to experiment with ML to write the introduction automatically, so my job will be limited to decide the quality of each article (from 1 to 3) and let the machines do the rest.
Do you have any ideas of how the Kotlin Weekly could be improved? I would love to hear your feedback.
I write my thoughts about Software Engineering and life in general on my Twitter account. If you have liked this article or it did help you, feel free to share it, ♥ it and/or leave a comment. This is the currency that fuels amateur writers.