This blog post is a cross-post of the article originally published on Medium. Getting an application to work, most of the time is somewhat trivial. Enough trial and error and you have something to show off. However, as you code more, the vicious cycle of coding, breaking, and fixing chips away at your soul. Manual testing of the last few changes that you have made to your codebase always leaves a bad taste in your mouth.
This blog post is a cross-post of the article originally published on Medium. Working as an army of developers divided into 10s of feature teams, one of the big topics in our company is to move to a micro frontend architecture. So every team in our company can be truly cross-functional and have an end-to-end autonomous deployment, decreasing the time to market for the features to be developed. We currently have dozens of different frontend projects developed with a variety of frontend tooling(old fashion template engines, Vue, React, Angular).
This blog post is a cross-post of the article originally published on Medium. At Getir, all the decisions we make and the services we run heavily depend on data. To analyze and process this data, we have been using custom Python scripts since our early days. However as time has passed, and data has grown in volume, these scripts have been slower to respond to our needs. Data processing jobs, which we depend on to make decisions, that once only took minutes, started to take hours.
KairosDB is a timeseries database built on Cassandra. Even though it is coded in a way to support different database backends, it is known mostly by its usage of Cassandra as a scaleable and performant time series data storage. With KairosDB, you can store timeseries metric data in different types and then query them with aggregations over time units. In this article, we will look into the details of KairosDB and its two different Cassandra schema to understand how the insert, delete and read operations we do, work under the cover.
Let’s talk about running your Node.js applications, in a way that makes it easier to migrate to continuous integration and deployment pipelines later on the road. There are too many things that you can do in DevOps layer that will make your code more readable and easier to maintain. For example: You can assume that every configuration is retrieved through a single file, then make a spec in your Kubernetes cluster to dynamically create this file through ConfigMaps, which would solve your problem of moving/managing configuration files on multiple servers.
[2023-08-16] I’ve switched to the anubis theme in favor of more minimal design, and light/dark mode support. [2020-05-14] After the release of Github Actions i refactored this project to work with it instead of wercker. Blog posts and configuration for the Hugo is stored under the source branch of Yengas/yengas.github.io, Github Actions builds and pushes html/css/js files on the master branch of the same repository. I haven’t been designing any GUI’s since i switched from Web development to other platforms.