Skip to content

Instantly share code, notes, and snippets.

Avatar
:octocat:
Learning Rust and IR.

LYK dalinaum

:octocat:
Learning Rust and IR.
View GitHub Profile
@dalinaum
dalinaum / Rx.kt
Last active Jan 26, 2022
코루틴을 쓰기 전의 코드와 쓴 후의 코드
View Rx.kt
fun getProfilePage() {
getUserById("fastcampus")
.map { getAdditionalUserInfo(e) }
// 내용이 길어질 수록 길어지는 체이닝 .XX, .YY.
// 줄줄이 쓰고 싶은데 어떤 것을 .map이나 .filter나 .flatMap에 나누어서 전달해야.
.subscribeWith(object: DisposableObserver<String>() {
override fun onError(e: Exception) {
handleUserInfo(e)
}
override fun onSuccess(additionalUserInfo: AdditionalUserInfo) {
View weird.py
answers_query = """
SELECT a.id, a.body, a.owner_user_id
FROM `bigquery-public-data.stackoverflow.posts_questions` AS q
INNER JOIN `bigquery-public-data.stackoverflow.posts_answers` AS a
ON q.id = a.parent_id
WHERE q.tags LIKE '%bigquery%'
"""
@dalinaum
dalinaum / conflict-resolution-for-eventual-consistency-goto.md
Created Mar 21, 2021
결과적 일관성을 위한 충돌 해결 (Conflict Resolution for Eventual Consistency)
View conflict-resolution-for-eventual-consistency-goto.md

결과적 일관성을 위한 충돌 해결 (Conflict Resolution for Eventual Consistency)

  • 마틴 클레프만 (Martin Kleppmann)

소개

분산 시스템에서 충돌 해결(Conflict resolution)을 다루려 합니다. 다른 사람들이 데이터를 독립적으로 변경했을 때 어떤 일이 일어나고, 일어난 충돌을 어떻게 해결하냐입니다. 내 이름은 마틴 크레프만이며 캠브리지 대학의 연구자이고요. 예전에는 산업에서 인터넷 스타트업에 종사했습니다. 또 링트인(LinkedIn)에서도 몇년동안 일했습니다.

Trve 데이터

@dalinaum
dalinaum / no-won.sh
Last active Apr 30, 2021
백쿼트를 제대로 쓰게
View no-won.sh
#!/bin/sh
dir="~/Library/KeyBindings"
file="DefaultKeyBinding.dict"
mkdir -p $dir
cd $dir
echo "{" >> $file
echo " \"\" = (\"insertText:\", \"\`\");" >> $file
echo "}" >> $file
View m1-homebrew.sh
#!/bin/sh
brew_root="/usr/local/m1-homebrew"
brew_bin="$brew_root/bin"
sudo mkdir $brew_root
sudo chown $(whoami) $brew_root
curl -L https://github.com/Homebrew/brew/tarball/master | tar xz -C $brew_root --strip 1
echo "export PATH=$brew_bin:\$PATH" >> ~/.zshrc
@dalinaum
dalinaum / yyerror.md
Last active Feb 3, 2021
좋은 구문 오류 생성하기
View yyerror.md

좋은 구문 오류 생성하기

Go 언어 개발자 러스 콕스Generating Good Syntax Errors의 번역입니다. 해당 글은 Creative Commons Attribution License 라이선스를 따르며 번역본도 역시 동일합니다.

yacc류와 같은 파서 생성기(parser generator, 구문 분석기 생성기)를 써야할지 (일반적으로는 재귀 하강(recursive descent)을 이용해) 손으로 파서를 작성할지 여부는 컴파일러를 작성할 때 큰 논쟁거리입니다. 파서 생성기를 이용하면 파서 개발자는 파싱할 언어를 정확하게 정의하고 대부분의 지저분한 작업은 프로그램이 합니다. 반면 손으로 재귀 하강 파서를 만드는 것을 지지하는 사람들은 파서 생성기는 과도하고, 파서는 손으로 작성하기 충분히 쉬우며, 그 결과는 이해하기 쉽고, 더 효과적이며, 구문 상 유효하지 않는 프로그램에 대해 더 나은 오류 메시지를 줄 수 있다고 주장합니다.

대부분의 종교 논쟁에서와 마찬가지로 어느 쪽을 선택할지는 무엇보다 친숙함에 의해 결정되는 것으로 보입니다. 나는 yacc를 사용하는 법을 손으로 파서를 작성하는 것보다 먼저 알았기에 파서 생성기 편에 강하게 서게 되었습니다. 지금은 두 기술을 어떻게 적용하는지 알지만, 여전히 파서 생성기를 사용하곤 합니다. 사실, 손으로 파서를 작성하기 보다는 파서 생성기로 여러 프로젝트를 작성했습니다. 앞으로 보게 될 좋은 표기법은 많은 것을 의미할 것입니다.

Coder At Work에서 켄 톰슨 (Ken Thompson) (주: 유닉스

@dalinaum
dalinaum / squash-merge.markdown
Last active Feb 1, 2021
스쿼시, 머지 가이드
View squash-merge.markdown

머지 제거

git log를 봤을 때 마지막에 마스터를 머지했네요.

commit 449ce0b2929cddd7cf760f63d4e07dc25d574abd (HEAD -> patch-1, danuel/patch-1)
Merge: 8fea8a6c1fc 66eb9821666
Author: Danuel <public.danuel@gmail.com>
Date:   Mon Jan 18 23:50:41 2021 +0900
View slima.md

Windows + Common Lisp 개발에서 사용하기 위해 Atom에서 SLIMA를 써보기로 결정했다.

apm install slima
apm install language-lisp
apm install lisp-paredit
apm install parinfer

CLISP이 설치되어 있기 때문에 그걸 쓰기로 했다. 설치된 Lisp 구현이 없으면 Roswell을 이용해 설치하면 될 것 이다. 윈도 환경에 Scoop과 Roswell을 사용하는 것은 지난 글에서 다루었다.

View opearator_fusion_in_rxjava2.md

RxJava 2의 연산자 결합 (Operator fusion in RxJava 2) https://proandroiddev.com/operator-fusion-in-rxjava-2-dcd6612cffae

작성: Vasya Drobushkov

서문

RxJava는 강력한 라이브러리지만 몇가지 문제도 있습니다. 특히 성능과 메모리 문제는 라이브러리가 풀려는 문제와 기술적인 관점에서 솔루션이 설계되는 방식에서 비롯됩니다.

RxJava는 간접비용(overhead)를 최소화하기 위해 "연산자 결합" (Operator fusion)이라 불리는 여라 가지 최적화를 가집니다. 그리고 우리는 이 글에서 거기에 대해 다룰 예정입니다.

View mclauren_stanley_uber.md

McLauren Stanley가 작성한 우버 앱 스위프트 고생기를 러프하게 번역해보았습니다.

불행히도 제가 겪은 (거의) 가장 큰 엔지니어링 재앙 이야기를 여러분께 들려드리겠습니다. 정치, 설계, 매몰 비용 오류에 관한 이야기입니다. [지금은 Aberlour Cask Strngth Single Malt Scotch를 마시는 중입니다.]

2016년으로 되돌아갑니다. 도날드 트럼프는 아직 대통령이 아니었기 때문에 #우버를_지우자(#DeleteUber) 운동은 아직 없었습니다. 트래비스 캘러닉(Travis Kalanick)이 여전히 CEO였고 우리는 국제적으로 활주하는 초 성장 단계였습니다. 대중은 극도로 긍정적이었고 우버는 높이 성장중이었습니다.

그러나 급 성장에는 문제가 있었고 앱 자체에 균열이 보이기 시작했습니다. 엔지니어링 조직은 매년 이전에 비해 거의 두 배가 되었습니다. 그렇게 빠르게 성장할 때 엄청나게 다양한 기술을 갖게 됩니다. 그런 점은 빌더가 빌드(Let Builder's build, 주: 우버의 핵심가치 중 하나. 창의적인 것을 만들어 내었다는 평가와 사회질서와 대립한다는 평이 있음.)하게 하자는 해킹 사고와 결합해 앱 구조가 복잡하고 깨지기 쉬웠습니다. 그 시절 우버는 클라이언트 측의 로직이 극단적으로 무거웠기 때문에 앱은 자주 망가졌습니다. 우리는 지속적으로 핫 픽스, 시급한 릴리즈 등을 진행해습니다. 디자인도 크게 확장되었습니다.

이 모든 문제의 결과로 "앱의 바닥부터 재작성"하는 생각으로 조직의 모든 수준에서 집결하는 움직임이 시작되었습니다. 우리가 더 느리게 하는 설계 때문에 더 빠르기 위해 처음부터 만들어야 한다는 것이 일반적인 정서였습니다.