Issue #16 – The magic of open source

Issue #16 – The magic of open source

<1/> Hacktoberfest

It is that time of the year, for Hacktoberfest. Whether you will be participating to give back to the contributors of the tools that you use, to have fun, climb leaderboards or sharpen your skills, you only need 4 merged pull requests for you to complete hacktoctoberfest. This year DigitalOcean is encouraging non-technical contributors to participate.

Deciding where to start can be tricky, however, it might be easier to start with tools that you are already used to working with on a day-to-day basis, otherwise you can just search Hacktoberfest on Github topics and find whatever calls your name.
DigitalOcean hosts some meetup events throughout the duration, and there are online and in-person events that one can attend.

Contributing and maintaining

There are a couple of ways to participate, you could be a maintainer of a repo or a contributor, and there are rules of engagement that govern how to successfully go about each one of these. As a maintainer you add hacktoberfest to your repo topic, and add hacktoberfest label to issues you want contributors to help with, add a CONTRIBUTING.md file with guidelines for your repo, the rest of the rules can be found here. As a contributor you will have to register between the 26th of September and the 31st of October, we will also be having our own in-house leaderboard for hacktoberfest, be on the lookout for that.
For new contributors here is a list of resources that you can use.

There is a also a focus on quality, “quantity is fun, quality is key” seems to be the running theme for hacktoberfest, DigitalOcean is discouraging spammy contributions, what does that mean? For maintainers it means having repos that encourage just adding your name to a list will not count towards contributions, for contributors it is creating pull requests that do not concern a repo. Here is a list of all things considered spammy.

Happy Hacking!

<2/> The Weekly Dev

Reliable distributed systems are systems that keep providing their services even when one or more components of the system become unavailable. When building reliable distributed systems, be it web services or DBMS, these systems are likely to fail due to network issues. It is thus important to think about system design tradeoffs at scale. In normal conditions the system should be available to receive requests and respond to requests, however, in case of network failure, we need to design our system to either be available or consistent. Dr. Eric Brewer in his Towards Robust Distributed Systems talk, he illustrated the trade-off between a distributed system being available at all times or being correct.

The whole notion of CAP Theorem is that it is impossible to build a read-write system in a network that can satifisfy all of the following:

• Consistent – All nodes in a network have the same data at the same time, irrespective of how the client connects to the network the system should return the latest write, the system should behave as though it is a single unit. The system is only consistent if it can guarantee the client the latest write, all read data that comes after a write should return the latest write data.
• Available – Every request eventually gives a response, success or failure. There are no limits to how long the response should be returned, however, the system should eventually give a response. The state of one or more nodes does not affect the fact that the client should get a response.
• Partion Tolarance – The system continues to work despite node loss, when a system experiences partition, messages from one part of the partitioned component to another component are lost. The system can respond to this by being consistent or available.

The choice that one must make is this, in case of partition, do you want to return outdated data or none at all? It is pivotal that we also look at CAP Theorem as a compromise design choice, it should not be polarizing, where we choose one instead of the other. We should look at CAP Theorem as a spectrum to decide what do we want more of, should our system be more available, or more consistent while we still meet the other condition.

<3/>Deeper Dives

The CAP FAQ | Paper Trail

Writing about distributed systems, compilers, virtual machines, databases and research papers from SOSP, ATC, NSDI, OSDI, EuroSys and others

Paper Trail

<4/> Inside the console

OpenSearch is a community-driven and open-source search and analytics suite alternative to Elasticsearch. OpenSearch analytics suite comes packed with a search engine daemon, NoSQL database, and a visualization interface, OpenSearch also offers a distributed, full-text search engine based on Apache Lucene with an interface for RESTful API and JSON documents support.

As more and more development teams embrace microservices and distributed systems, observability becomes increasingly important to managing services, troubleshooting issues, and keeping track of your production environment. Cloud computing lowers the cost of monitoring and observability solutions tend to be pricey and cumbersome to set up. OpenSearch offers a solution that is open-source and makes observability easier than ever before. AWS OpenSearch Service is what we knew as AWS Elasticsearch Service, here is some drama for the day. Also check-out the list of features and pricing for AWS OpenSearch.

<5/> #Geeking It Up

Packer
Packer is a free and open source tool for creating golden images for multiple platforms from a single source configuration.
Ably
Ably provides a suite of APIs to build, extend, and deliver powerful digital experiences in realtime.
Ditto
Ditto is a real-time database for mobile, web, IoT, and server apps that can magically sync data with or even without the internet.
HyperUI
Free Tailwind CSS components that can be used in your next project. Perfect for Laravel, Rails, React, Vue and more

‍