Kang Min Kyu stella6767

How to Install Templ CLI on Mac with nix

There are several steps missing from the golang Templ documentation when installing the command line tools on Mac.

The following are the walk-through steps you'll want to take so you can run templ generate from the mac command line

스프링 부트 구성속성 이용(Spring Boot External Configuration)

스프링 부트에서는 애플리케이션에서 필요한 속성을 "애플리케이션 구성파일" application.yml(혹은 applicatoin.properties) 에 작성하여 활용합니다.

Note	데이터구조를 계층형으로 표현할 수 있어서 개인적으로 `.properties` 파일 보다는 `.yml`(YAML) 파일 이용을 선호합니다.

[Flyway] Repeatable Migrations & Seed Data

개발 단계에서 페이징 처리 등 시드 데이터가 필요한 경우가 더러 있다. 이 때 Flyway 에서 제공하는 Repeatable migration 을 활용해 시드 데이터를 관리하면 어떤 점이 편한 지 그리고 유의할 점은 무엇이 있는 지 알아보자.

Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes.

Repeatable migration 의 가장 큰 특징은 checksum 값 (= 변경 여부 체크하는 값) 이 변경된 경우 여러 번 migration 이 적용된다는 점이다. SQL-based migration 에서 Repeatable migration 을 사용하기 위해서는 R__{description}.sql 와 같은 파일을 생성하는데, 이미 migration 처리된 파일을 수정하면 checksum 값이 변경 되면서 해당 파일의 내용이 다시 migration 처리 대상이 된다는 것이다.

위와 같은 특징으로 별도의 버전 정보를 따로 관리하지 않는다.

시드 데이터를 관리할 때 Versioned migration 보다 Repeatable migration 을 사용하면 편리한 이유도 위에서 언급한 특징에서 찾을 수 있다. Versioned migration 은 버전, 즉 특정 시점의 상태 정보를 가지고 있고 따라서 딱 한 번만 migration 처리가 된다. 따라서 시드 데이터를 Versioned migration 으로 관리하면 시드 데이터의 추가 및 삭제 시 계속 해서 파일을 생성해서 대응해야 한다.

Alpine.js

json-server

https://github.com/typicode/json-server

Instalação

Two approaches to handle error responses from Spring WebClient calls globally:

Exceptions with webclients are all wrapped in WebClientResponseException class. So we can handle that using Spring's ExceptionHandler annotation.
Using ExchangeFilterFunction while constructing the webclient bean.

Please make fork of this, as this can be removed by Github.com sooner or later.

CATF44LT7C-eyJsaWNlbnNlSWQiOiJDQVRGNDRMVDdDIiwibGljZW5zZWVOYW1lIjoiVmxhZGlzbGF2IEtvdmFsZW5rbyIsImFzc2lnbmVlTmFtZSI6IiIsImFzc2lnbmVlRW1haWwiOiIiLCJsaWNlbnNlUmVzdHJpY3Rpb24iOiJGb3IgZWR1Y2F0aW9uYWwgdXNlIG9ubHkiLCJjaGVja0NvbmN1cnJlbnRVc2UiOmZhbHNlLCJwcm9kdWN0cyI6W3siY29kZSI6IklJIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiQUMiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJEUE4iLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJQUyIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IkdPIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiRE0iLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJDTCIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJTMCIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJDIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiUkQiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJQQyIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJNIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiV1MiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJEQiIsI

With GitHub Actions, a workflow can publish artifacts, typically logs or binaries. As of early 2020, the life time of an artifact is hard-coded to 90 days (this may change in the future). After 90 days, an artifact is automatically deleted. But, in the meantime, artifacts for a repository may accumulate and generate mega-bytes or even giga-bytes of data files.

It is unclear if there is a size limit for the total accumulated size of artifacts for a public repository. But GitHub cannot reasonably let multi-giga-bytes of artifacts data accumulate without doing anything. So, if your workflows regularly produce large artifacts (such as "nightly build" procedures for instance), it is wise to cleanup and delete older artifacts without waiting for the 90 days limit.

Using the Web page for the "Actions" of a repository, it is possible to browse old workflow runs and manually delete artifacts. But the procedure is slow and tedious. It is fine to delete one selected artifact. It is not for a regular cleanup. We need

	<!--
	Since the markup IS the application state, using data-* attributes to keep track of some specifics would be handy.
	Luckily, HTMX is brutally easy to extend, so we can do that in no time!
	-->
	<article class="message task"
	th:id="'task'+${task.id}"
	th:data-task="${task.id}"
	th:data-status="${task.status.id}"
	th:hx-put="@{/task/{id}(id=${task.id})}"
	hx-ext="hx-dataset-include"

	package gunlee.demo.fiber;

	import org.junit.jupiter.api.Test;

	import java.io.BufferedReader;
	import java.io.IOException;
	import java.io.InputStreamReader;
	import java.lang.management.ManagementFactory;
	import java.lang.management.ThreadInfo;
	import java.lang.management.ThreadMXBean;

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<link href="https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css" rel="stylesheet">
	<script src="https://cdn.jsdelivr.net/gh/alpinejs/[email protected]/dist/alpine.min.js" defer></script>
	<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
	<title>Alpine and axios</title>
	</head>