비 내리는 화요일. ☔

jinja2 template include + cache? + file-time

재밌는걸 찾았다.

jinja2을 사용하면서, 하위 include으로 내려갈수록, file을 생성해줘도, 그냥 touch을 해줘서 파일시간을 갱신해줘야 template cache을 무시하는거 같아.

그래서,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// gulpfile.js:

const buildTask = series(cleanTask, esbuildTask, injectTask, touchInjectedTask);

function watchTask() {
  watch("./js/**/*.js", buildTask);
}

exports.watch = watchTask;
exports.build = buildTask;
exports.clean = cleanTask;

…대략 잘 동작하고, webpack보다 엄청나게 빠르다 ㅎㅎ.

뭐 대충 다음과 같은 글들:

https://www.eff-lang.org/handlers-tutorial.pdf

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/algeff-tr-2016-v2.pdf

…그리고 몇 개의 구현체, 포스팅들: (아직은 별루인거 같은데)

https://hackage.haskell.org/package/fused-effects

https://github.com/dry-rb/dry-effects

https://github.com/digital-fabric/affect

https://github.com/macabeus/js-proposal-algebraic-effects

https://github.com/nythrox/effects.js

https://www.janestreet.com/tech-talks/effective-programming/

https://github.com/ocaml-multicore/effects-examples

https://overreacted.io/algebraic-effects-for-the-rest-of-us/

…음… 분명히 한국말으로 번역도 해놓았고, 심지어 js버젼으로 설명/예시도 있는데 나는 전혀 모르겠다 싶었음.

오히려 dry-rb, affect이 더 명확하기는 한거 같아.

가장 실용적으로 접근한 예는, ocaml-multicore에서 활용한 것들 같아 보인다.

분명히 장점을 볼 수 있을거 같은 개념 같다.

왜냐하면,

1. 지금의 monad을 이용한 효과와 사용처의 분리 방식을 생각해보면,
2. 하나의 monad context에서는, 한가지 타입의 monad만을 표현가능.
   1. 그래서 여러개의 monad context을 위해 monad transformer 같은것들으로 stacking하여 사용.
   2. (…그때 그때 Haskell do-notation등에 따라 분리해서 표현)
   3. 좋은점이라면 좋은점일수도 있겠지만.
3. 그런데, aeffects을 이용한다면,
   1. 굳이 그렇게 복잡하게 나누지 않아도 괜찮고,
   2. monad처럼 사용처에서 그 효과의 내용을 분리하기도 좋아 보여.

당연히 그렇기 때문에, 원래의 모나드에서 같는 장점을 그대로 잃지 않으면서, 더 평범하게 적어나가기 좋을거 같다. (…일반적인 imperative programming language에서 I/O/async/await, Maybe등이 동시에 나오거나, …처럼)

기운 없는 날… 쉬어야겠다.

https://stedolan.github.io/jq/

jq이 뭐하는 도구인지 소개는 한국어로 많은데, 그걸 갖고 조금 복잡한 패턴을 처리하는 자료는, 머리 나쁜 내가 이해하기에 적합한 자료는 찾지 못해서, 그냥 manpage을 읽고 시도.

이미 알고 있는 도구, 혹은 이미 대부분의 unix-like, linux 시스템에 깔려있는 도구들이 있는데, 막상 그 도구의 manpage을 차분히 읽어 보면, 내가 너무 게을렀었고 알려고 하지 않았기에 내 삶을 더 도움을 받을 수 있었을텐데, 그렇지 못했었던 도구들이 많은것 같아.

gnu coreutils, m4, awk, perl 만 해도 그랬었고, 조금이라도 알아가고 응용을 할수록 매일매일이 더 재밌고 강력해졌었던거 같아.

https://posco.dev/blog/2022-04-23_draft_some-engineering-tough-sells/

…공감이 가는 부분들은:

1. dynamic serialization isn’t worth it, use statically defined serialization
2. untested code is virtually always somewhat wrong
3. doing things right pays off sooner than we usually imagine
4. an ounce of design is worth a pound of implementation
5. in data engineering, the data very often violates your beliefs about the shape
6. thinking about, and minimizing edges in your code’s dependency graph is a win
7. a good (i.e. programmable, fast, reliable, reproducible) build system solves a lot of practical software engineering problems

…많은것들을 경험하되, 숙고와 자기객관화는 중요. 아니라면, 경험과 시간은 그저 흘러가게 되니.