tvoklov

// this is a very highly opinionated scalafmt file that aligns with
// what I view as most easily readable code style
// the point of this file is not to just make formatting more consistent,
// but enforce that consistency throughout the entire project

// works well with ci/cd actions that do a scalafmt check
// annoy your developers with linters until they break and adopt your code style!

version = 3.8.1
runner.dialect = scala3

tvoklov

version = 3.7.3
runner.dialect = scala3

align.preset = more
maxColumn = 80

align.multiline = true

align.stripMargin = true
assumeStandardLibraryStripMargin = true

tvoklov

FROM ubuntu

COPY ./[[[ path-to-duc-binary ]]]/noip-duc /opt/noip/noip-duc

ENTRYPOINT /opt/noip/noip-duc --username $USERNAME --password $PASSWORD -g $HOSTNAME

tvoklov

HI!!!!!

TODAY I WILL MAKE INSANE DI USING SCALA THAT YOU WILL HATE!!! ZIO DOES IT BETTER, BUT ZIO SUCKS FOR OTHER REASONS!!!!

OK, LETS GO!!!

import cats.Monad

tvoklov

import cats.effect.{Async, Clock, IO, IOApp, Ref}
import cats.syntax.all._

import java.time.LocalDateTime

trait Metric[F[_]] {
  def modify(name: String, by: Int): F[Unit]

  def set(name: String, value: Int): F[Unit]
}

tvoklov

---- Minecraft Crash Report ----
// I let you down. Sorry :(

Time: 2023-02-19 20:53:28
Description: Unexpected error

java.lang.ClassCastException: class twilightforest.entity.SpikeBlock cannot be cast to class twilightforest.entity.monster.BlockChainGoblin (twilightforest.entity.SpikeBlock and twilightforest.entity.monster.BlockChainGoblin are in module twilightforest@4.2.1518 of loader 'TRANSFORMER' @654e6a90)
	at twilightforest.client.renderer.entity.BlockChainGoblinRenderer.m_5523_(BlockChainGoblinRenderer.java:27) ~[twilightforest-1.19.2-4.2.1518-universal.jar%23241!/:4.2.1518] {re:classloading}
	at net.minecraft.client.renderer.entity.EntityRenderDispatcher.m_114397_(EntityRenderDispatcher.java:123) ~[client-1.19.2-20220805.130853-srg.jar%23245!/:?] {re:mixin,pl:accesstransformer:B,xf:fml:twilightforest:renderer,xf:fml:twilightforest:bake,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,xf:fml:twilightforest:renderer,xf:fml:twilightforest:bake,pl:mixin:APP:vivecraft.nonvr.mixins.json:clie

tvoklov

// ==UserScript==
// @name         SHOUT EVERYTHING
// @version      0.1
// @description  make every website shout at you
// @author       tvoklov
// @match HTTP://*/*
// @match HTTPS://*/*
// @grant GM_log
// ==/UserScript==

tvoklov

ZIO is not made for FP developers

I've recently revisited a project that, out of curiosity, I tried writing in ZIO instead of cats effect, and the more I looked at it the more I got confused how weird and seemingly unwieldy this library is.

Here's an example: I have to get some data from an http server and send it into a kafka queue.

That function, written with cats effect, will look like this:

def readAndSendToKafka[F[] : Async](httpClient: Client[F], kafkaProducer: Producer[F])(httpUrl: Url, kafkaTopic: String): F[Unit] =

tvoklov

import cats.Monad
import cats.effect.kernel.Async
import cats.effect.std.Random
import cats.syntax.all._

def generate[F[_]: Monad](random: Int => F[List[Byte]], alphabet: Array[Char], size: Int) = {
  val mask = (2 << (Math.log(alphabet.length - 1) / Math.log(2)).toInt) - 1
  val step = Math.ceil(1.6 * mask * size / alphabet.length)

  def go(filled: List[Char], rest: List[Byte]): F[List[Char]] =

tvoklov

Hey there. This is an edit I made after I talked to some people who know much more than I do and shared my grievances over distributed transactions in a microservice architecture. Here's how my view changed:

• Yes, distributed transactions are not desirable
• Sometimes, especially considering times when talking to outside services they are necessary

I'm gonna keep this post up since I still believe that when working on a fully internal architecture (you have access to all the source code and/or are the one designing the system) distributed transactions might show a failure in design. They are a clutch, and you shouldn't depend too much on them.

---

sometimes microservices seem like they create more problems than they solve.