맥 스튜디오 울트라 사용후기

하나도 좋은지 모르겠음

m1때문에 못 쓰는 몇 가지 빼고는 불편한 것도 없음

  • Virtualbox
  • docker m1 지원 안되는 image
  • 모니터 기본 연결이 한개밖에 없는데 추가usb연결 꽂으면 부팅할 때 마다 운에따라 모니터 순서가 바뀜

돈 신경 안 쓰면 최고의 선택 아닐까

  • 소음 없고
  • 필요한거 다 켜놔도 안느려지고
  • 빌드속도 빠름

가성비같은거 신경 안쓰면 최고의 선택 아닐까

Error – git 깔란 팝업 좀 안뜨게 해라 -Monterey 12.6

업그레이드 후에 xcode terminal 툴이 고장났는지
터미널에서 git실행시키면failed 자꾸 이지랄이 뜬다
ios계열 개발 안해서 생전 켜보지도 않은놈에 것

본좌도 한 실수: xcode다시 설치하고 해도 소용없다

https://www.client9.com/uninstall-xcode-on-macos-sierra/
sudo rm -rf ~/Library/Developer/
sudo rm -rf ~/Library/Caches/com.apple.dt.Xcode
sudo rm -rf /Library/Developer/CommandLineTools

xcode-select --install

해결

1. git을 따로 설치해줘도 된다

둘 중 하나만…
시스템 라이브러리쪽은 port를 선호한다

brew install git
sudo port install git

설치를 따로 해주는게 좋은점은… 최신버전(뭐가 바뀐건지 모르지만)을 쓸 수 있고
애플 업데이트 오류났을 때 영향을 안 받을 수 있다

간혹애플에서 똥싸놓은것들하고 충돌이 날 가능성도 있긴하겠지만 그러면 그때가서 지우자

2. xcode를 한번 실행시켜준다

그러면 뭐 설치하라고 뜨는데 대충 선택해서 클릭하면 그다음부터 잘 된다

AWS – 세계에서 가장 머대리 클라우드

없었으면 더 좋았을 eksctl

eks는 사회악이다.
잘못 만들어진 툴은 없느니만 못하다
이딴게 있으면 다른게 만들어질 여지조차 막아버리니까

eksctl이 없으면 다른방향으로 de facto가 생겼을텐데

aws의 대부분이 널리 사용되고 기능많은 애매한 실패작이다
소니-애플로 이어지는 심플하고 쓰기좋은 제품군이 나오기 전의
복잡한 툴을 보는 느낌이다

오동작은 하지 않는다

클라우드의 아이폰은 뭘까

aws cli로 하면 될 것 같은데 애매하게 cloud formation을 만들어내는 eksctl 때문에 cli기능이나 다른 프로비저닝 툴이 활성화가 덜 됐다.

AWS의 대머리 메시지

You do not have permission to access the specified resource

eni를 지우려는데 이상한 소리를 하면서 안 지워진다

검색하다 보니 누구는 EB가 누구는 lambda가 남아있어서 그렇다고 한다.
lambda에서 생성한건 다른데서 삭제가 안된다고?

씨이발 그럼 어디어디 지워야할지 알려주던가
루트계정으로 들어갔는데 권한이 없다니

iam복잡하게 만들려다가 다 망쳐먹은듯

내 경우에는 rds가 생성 돼 있어서 삭제가 안됐었다

nextcloud, 분노, helm, homeserver

홈서버운영한지 xx년차 – k3s서버 helm으로 관리하면서 열받아서

  1. 쌩으로 설치해서 쓰다가
  2. docker-compose로 쓰다가
  3. docker swarm으로 쓰다가
  4. k3s로 쓰는중인데

1,2,3은 다 좋았는데 k3s로 가면서 문제가 많이 생긴다
애플리케이션 그냥 실행시키던 시대엔 대부분 php라서 apache에 연결해서 실행시켰고
자바계열은 ajp연결했고

Docker는 가장 편했다. 이미지도 대부분 잘 만들어져 있어서 env만 잘 넣으면 실행이 됐다.
간혹 volume으로 설정파일을 넣어야 하는 경우가 있긴하다..
이걸 docker-compose로 만들고 apache, nginx로 vhost라우팅

docker-swarm도 traefik연결하는게 좀 삽질이 심했지만 안정화 이후엔 편안했다

K3s 문제들

ingress

ingress는 복잡하고 어렵긴한데 익숙해지면 어떻게든 할만하다

이상하지는 않다.

차트의 문제

helm차트는 좀처럼 쓸만한게 없다.
artifact.io에서 검색해서 쓰는데 얼마 나오지도 않고
오피셜도 제대로 안 돌아가는게 많다.

bitnami가 그나마 나은편이데 중간중간 함정이 있다.
잘 안된다싶으면 내가 잘못한게 아니고 차트가 잘못됐음을 빨리 인정하고 다른걸 찾던가 새로 만들거나 적당히 고쳐 써야야한다

Docker 함정 빈도가 10%정도라면
Helm은 함정 빈도가 30%정도 된다

helm의 기능문제

차트가 완벽하면 좋은데 다 조금씩 모지란 새끼들이다
그렇다고 완전히 새로 만들기는 시간이 너무 낭비되고 조금만 고쳐 쓰고싶다

잘못된 telmplate파일만 오버라이딩해서 쓸 수 있으면 좋겠는데 그런건 지원되지 않는다.

오버라이딩이 되어야오피셜 차트버전업 혜택을 보면서 나한테 맞게 커스터마이징 해서 쓸 수 있는데… 아예 복붙해서 만들거나 대강 알아서 써야한다.

해결방법으로 겨우 만든게

helmsman으로 하위디렉토리에 차트를 넣고

/chart.d
  /nginx
  /nextcloud
  /postgres
chart_override.d/
  /nginx
  /nextcloud
  /postgres
helmfile.yaml
init.sh

이런식으로 놓고 init.sh를 실행할 때 마다 chart를 새로 받아서 chart.d에 압축을 풀고
chart_override 디렉토리에서 그냥 덮어씌워 복사하게 만들어서 썼는데
잘 되긴하는데… 뭔가 기분나빠서 관뒀다

덮어씌우기 복사하는거라서 잘못된 파일을 빼는건 안된다.
빈 파일로 덮어띄우던가 삭제하는건 따로 만들어야할듯

문제의 차트 nextcloud helm

설정이 중간중간 잘못 돼 있다
values.yaml만 가지고 모든걸 컨트롤 하려다보니 이런 문제가 발생하지 않았을까

helm차트를 bitnami, truechart등 한곳에서 여러개를 만들다 보니
공통패턴으로 활용하는데 과도하게 집착하는 것 같고…
그것때문에 오류가 나는 경우가 조금 보인다

helm도 깔끔하게 상당부분 수동으로 하도록 해야한다.
어차피 개별 오픈소스 도커이미지가 제각각이라 별 수 없고 공통적인 설정같은건 불가능하다

결국 환경변수 도 이런식으로 제각각이잖아
MYSQL_DATABASE, POSTGRES_DB

deployment.yaml만 수정하니 쓸만해졌다
설정파일을 사용하는 버전으로 완전 수정할까 했는데
그냥 잘 되서 그만뒀다

결론

helm차트에서 뭔가 잘 안되면 folk해서 적당히 수정해서 써야한다.

굉장히 높은 확률로 내가 잘못한게 아니라 차트가 잘못됐다.

도커이미지는 그나마 오피셜로 관리가 되는데 helm은 뭔가 애매하다.
예전 ansible이나 chef마냥 버전지원이 제대로 안되는 느낌..
예전에 ansible, chef와 비슷하다. 차트(레시피)를 바닥부터 다 새로 만들어야될 정도로 공개된 것 중에 쓸만한게 없었다. 때마침 컨테이너 기술이 활성화 되기도 했고

너, 자바충이지? – 자바에 중독된 뇌를 고쳐라 1

뇌가 자바에 절여진 자바충들아 자바를 버려라

코틀린이라는 압도적인 솔루션이 나왔음에도 자바만을 고집하는 어리석은 자바충들이 이제라도 코틀린으로 넘어오길 바라며

자바충 특

  • 자바 버전올라가는거 싫어함
  • log4j 뉴스나오기 전까지 업데이트 안함
  • stream()쓰면 안되는 줄 앎
  • 리플렉션 쓰는거 싫어함

자바에 비해 코틀린은 문법이 유연하다

Entity to DTO코드 만들기 비교

자바충

엔티티 클래스에 public AccountDto toDto()
를 만들어서 꾸역꾸역 쑤셔넣는다
Entity, Dto가 상호 참조를 유지해야되서 좆같이 한 모듈에 쑤셔쳐박는다

코틀린 사용자

fun Entity.toDto()
으로 재미있게 만들 수 있고

  • presentation
  • service
  • model

그레이들 모듈로 레이어를 나눠서 사용하고 수 있다.
모듈화로presentation 레이어에서 Entity에 손도 못 대게 만들어둘 수 있다.

왜좋은지자세한설명은서버용량이부족해서생략
용량이부족해서띄어쓰기도생략

인도에서는 19단까지 외운다며?

표현의 풍부함은 사고의 프레임워크를 확장시켜준다

자바충의 사고방식에서 [1,2,3,4,5,6,7]에서 홀수를 꺼내려면 어떻게 해야할까?
더러워서 여기 쓰기도 싫다

kotlin way

fun filterOdd(input) = input.filter{ it % 2 != 0 }

apply, let, also, with, run, filter, sum, map 등등 처음엔 헷갈리는데
외워놓다보면 표현식이 점점 익숙해지면서 쓸데없는 부분에서 오버헤드가 사라진다.
못 외울정도는 아니기도 하고

null <> “”

아무리 자바충이라도 설마

null ? !!

귀찮다

EOF

[도서] 개발 함정을 탈출하라

소프트웨어 회사들이 흔히 하는 실수를 다 써 놨다.
이 업계에서 일하는 누가 읽어도 이거 우리회사 얘긴데.. 싶을거다.
(진짜 잘되는 회사 제외)

프로덕트 매니저의 업무 프레임워크

프레임워크라는 것은 베이스가 부족한 경우에도 필요하고
능숙하더라도 간혹 실수를 방지 해 주는 장치로 작용한다.

프로덕트 매니저로써 능숙하게 일을 하는 사람도
지금 프로덕트 매니저로 취업하거나
프로덕트 매니저 업무를 떠맡게 된 누구에게나 도움이 되지 않을까

인상깊은 내용

  • 프로덕트 매니저란?
    • 번뜩이는 아이디어, 최첨단 기술이 아닌 프로덕트를 통해 해결해야 하는 문제에 주목
  • 아무도 쓰지 않는 쓰레기를 만드는 것 = 개발함정
  • 성과물 vs 산출물
    • 기능의 실제 가치를 확인하지 않고 개발하는것은 산출물… 뭔가가 나왔다
    • 성과물은 핵심 목표를 달성할 수 있는 것
  • 이해관계자별 다른 목표(동상이몽) [목표]-[이유]
    • CEO 매년 30% 성장을 해야돼 – 그래야 다음라운드 투자를 받아
    • CTO 모바일 전략이 중요해 – 그래야 성과급을 받지
    • COO 비지니스 회원을 늘려야 해 – 그러면 수입이 늘어날거야
    • 그런데 이런식으로 각자 목표를 세우는게 문제라면… 이 문제의 해결책은 OKR이 아닐까

OKR과 마찬가지로 읽으면서 씁쓸하다
이건 상당히 센스의 영역이다.
읽고나서도 여기서 뭔가 느끼고 바꿀 수 있는 경영진이 얼마나 되려나

그리고 이 책이 프로덕트매니저의 시각에서 자기중심적으로 쓰여져서 그렇긴한데…
그 직무를 맡은 사람이 없어도 모든 구성원이 이렇게 사고해야한다.
우리나라 보통 IT회사에서는 개발팀장, 기획자, 디자이너, 그냥PM등 다양한 사람이 사실상 이 책에서의 프로덕트 매니저 포지션이기도 하고
프로젝트에 따라 누구나 프로덕트 매니저가 되기도 하니까

빗썸 API를 보면 형기증이 나…

어지럽다.. 아니 형기증은 어지러운게 아니지

이거보고 이상한게 안 느껴지는 사람은 API싸개에 적합하지 않으니
진로를 바꾸기 바랍니다

  • https://api.bithumb.com/public/ticker/all_btc
  • https://api.bithumb.com/public/assetsstatus/BTC

나머지는 취향차이로 둘 수 있는데
참을 수 없는게 딱 2가지 있다