나빼고다천재

러닝커브 낮은게 장점이라 들었는데 막상 손대고 나서 보니 뭐 이렇게 어렵지

angular보다 더 어려운데...

사내에서 오래된 아주 레거시 프로젝트가 있는데(문젠 그걸 아직도 현역으로 굴리는곳이 있다는것이다)

이클립스로 프로젝트가 세팅되어 인텔리제이나 vscode같은 툴로 해본적이 없는데 

어느날 이클립스를 켜보니 응용 프로그램을 실행할 수 없습니다 이러면서 뻗는것 아닌가

다행스럽게도 구글링 해보니 나와 같은 사람이 많다

해결 방법은 터미널에 아래 명령어를 입력하면된다

codesign --force --deep --sign - /Applications/Eclipse.app/Contents/MacOS/eclipse

막상 오류났을떄 심장이 덜컹했는데 예상외로 이런 문제를 겪는사람이 많다는 사실에 놀랬고 다들 덤덤하게 쓰는것도 웃기네 ㅋㅋㅋ

회사가 맥북 지급해줘서 쓰고 있는데

사실 윈도우 환경에 비해 압도적으로 편하다는 모르겠음

아래는 내가 생각한 장점

1. 빌드시간이 빠르다(동 사양에서는 빠른진 모르겠음 이전에 썼던 그램보단 빨랐다)

2. 별도의 터미널 프로그램 설치없이 iterm으로 접속가능한거

3. xcode 사용이 가능하다

4. 컨트롤 + 스페이스 이거 ㅈㄴ 편함

단점

1. 시스템 오류 혹은 오래된 레거시 툴 이런것들은 맥용 셋팅 맥용 버전 다 따로 찾아야봐야함 심지어 최신버전도

2. 램 확장성이 구림(개발자 피시는 램 많은게 장땡인데...)

3. xcode 사용성 개구림

4. 폴더 열었을때 윈도우마냥 경로 안보여줌

5. 최소화 하면 알트탭해도 리스트가 안나옴 독 열어서 직접 다시 원상복구 시켜줘야함

6. 무슨 이유인진 모르겠는데 램을 자꾸 퍼먹음 run cat 이라는걸 받아서 쓰는데 여유 램 공간이 idle 상태에서도 2기가가 채 안나옴

뭐 이게 맞다 그르다 이건 아닌데

사실 나는 맥이 좋은지 모르겠음

사양이 그렇게 높은것도 아니고...그램처럼 휴대성이 좋은것도 아니고...걍 로고 감성인듯

이외에 쓰시는분들 혹여나 EAGLE 보시면 장점 단점좀 써주십쇼 

고견을 듣고 장점은 수용하고 단점은 참고해보겠습니다

참고한다고

오늘은 조금 이슈와 되는 이야기에 대해 해보자한다.

지금 프론트엔드의 개발환경은 바야흐로 대 타입스크립트의 시대이다. 고품질의 프레임워크 중 일부는 타입스크립트를

강제하며 기업들의 요구사항에도 타입스크립트의 사용 경험을 요구하는곳이 늘고있다.

실제로 몇번의 타입스크립트 사용도 해보았다. 이것이 제공하는 이점은 이미 인터넷에 널리고 널렸지만

오늘은 반대의 사례를 한번 보고 왜 그런일이 일어났는지를 고찰해보자

Turbo8의 타입스크립트 드랍

Turbo8에 대해 생소하다는 사람이 있겠지만 뒤의 말이 핵심이다 Turbo8의 개발자 DAVID HEINEMEIER HANSSON

이라는 사람이 타입 스크립트를 드랍하고 모두 javascript로 통일하겠단다.

문제는 이 사람이 나름의 커리어를 가진 사람이라는것이다.

루비온 레일즈의 프레임워크 개발자 창시자 중 한명이다(이하 데이비드). 이런 인지도 있는자가 왜 그런짓을 한것일까?

추가적으로 레딧과 포럼에서는 그의 행동이 오픈소스에 기여한 개발자들을 무시하는 처사라 비난하고 있으며

그가 타입스크립트의 어떤 부분이 싫은지 명확하게 설명하지 않고 있다며 그를 비꼬고 있다

(덤으로 turbo8의 PR창은 난리났다. 이런식으로 기여자들을 무시하는 처사는 처음이다 바보같은 짓이다.

이렇게 할꺼였으면 TSDoc을 활용해 타입에 대한 가이드라도 있어야했다. 등등..

재미있는건 옹호하는댓글도 상당수있으며 잘된 결정이라 해주는 사람도 있다.

시간이 있으면 보러가보자)

화자는 그러한 부분을 제하고 그가 블로그에 남긴 글들과 그리고 실제 개발자들이 느끼는 부분

그리고 화자의 사견을 덧붙여 글을 작성하도록 하겠다.

(아래 내용은 데이비드의 블로그 내용 중 일부를 한글로 번역하여 가져왔다)

타입 스크립트는 쉬운 일을 어렵게 만듭니다. 어려움이 닥치면 아무거나(any)라고 하게 되죠
그런건 사양하겠습니다.

데이비드의 타입스크립트에 관한 글들 중 가장 인상적인 부분이자 타입스크립트를 사용하며 느낀 첫부분인것 같다.

타입스크립트의 분명한 단점이다. 그의 관점은 짧고 간결해야할 작성을 타입을 명시하고 정하는 행위가 어려운

일이라 표현하고 있다. 이것은 틀린말이 아니다. 물론 누군가는 그렇게 어려운 일이 아니라는 논리를 펼치겠지만

우린 그가 루비 온 레일즈라는 프로그래밍 역사에 기록될 뛰어난 프레임워크의 개발자 중 한명이라는 사실을

기억해야한다. 권위에 기대는것이 아니라 그렇게 생각하는 이유는 다음 문단을 보며 알수있다.

우리가 브라우저에 실행되는것이 Typescript가 아니라 Javascript를 실행한다는 사실을 받아드려야합니다.
그렇기 때문에 어떠한 도구나 타이핑 없이 코드를 쓸수있다는 그 상황이 축복인것입니다.

그의 논지는 웹에서 작동되는 언어는 타입스크립트가 아니라 자바스크립트이며 그러한 사실을 인정하고 그것이 

흔히들 이야기하는 스펙임을 깔고 가야한다는것이다. 그는 실제로 타입스크립트를 제거하는 코드가 담긴 

형상을 turbo8로 병합하면서 코드의 간결성,직관성이 훨씬 좋아졌다는 코멘트로 남겼다.

포럼에서 타입스크립트를 싫어하는 이유를 정리해보았다.

1. 코드를 짜는 시간보다 TS 완벽한 타입체크를 하는데 더 많은 시간들 들여야한다.

2. 지원하지않는 외부 라이브러리들이 존재한다.

3. 자바스크립트는 애초에 C++,java 같은 강타입 언어들의 패러다임을 벗어나고자 나온 약타입언어다. 그렇기에

일정 부분 유연성을 주어야한다.

4. TS는 coffescript,backbone 같은것처럼 언젠간 없어지겠지만 JS는 그렇지않다. 

5. 브라우저의 디버깅이 훨씬 더 어렵다.

6. 빌드 프로세스가 복잡해진다.

7. 새로운 개발자나 후임자가 배우기 어렵다.

아래는 레딧에서 타입스크립트에 관한 글중 최고 표를 받은 댓글 내용 중 일부이다.

Q1. 타입스크립트를 좋아하시나요 싫어하시나요?

A1. 나는 그 언어를 싫어한다. 나쁘진 않지만 필요하지 않을뿐이다. 대규모의 프로젝트를 진행할때도

오류추적이 그렇게 복잡했던적이 없다. 정작 그 언어가 가진 단점은 코드를 읽기 어렵게해 

평생 직장을 얻게 해주는것뿐이다. 

Q2. 순수한 자바스크립트를 선호하는 그 이유는 무엇입니까?

A2. 일반 JS는 읽기가 매우 쉽습니다. 대부분의 문서와 도구는 일반 JS에 다 포함되어있습니다

코드를 작성하고 웹에서 즉각적으로 결과를 확인하는 디버깅으로 충분합니다. 

Q3. 타입스크립트를 사용하면 생산성이 떨어지나요?

A3. 명백합니다 느려집니다. 타입스크립트와 싸우는 시간이 더욱 더 늘어날것입니다. 모두가 타입스크립트의

생산성을 찬양하지만 실상은 그렇지 않습니다. 이상하게 타입스크립트의 생산성을 이야기할땐

초기설정와 중간설정(작은 단위의 임포트,인터페이스 추상화)의 시간을 빼고 코드를 치고

디버깅 하는 시간만 거론합니다

그러면서 자바스크립트의 생산성을 이야기할땐 마치 디버깅을 하게 되면 세상의 종말이 올것이라

디버깅에 큰일이 날것처럼 이야기합니다. 실상은 그렇지 않습니다.

모든 프로그램은 잠재적인 위험을 가지고 있습니다. 

화자는 타입스크립트를 신봉하지도 그렇다고 부정하지도 않는다.

다만 일부 부정적인 의견과 긍정적인 의견을 모두 받아드린 편이다.

해줄수있는 말은 취업을 원한다면 배워야한다는것이다.

요새 본의아니게 본업과 동떨어진 분야를 작업하다보니

프론트엔드의 트렌드를 놓치고 있는것같다.

next js를 이젠 더이상 정말 미룰수없을것같아서

강의를 하나 보고 있는데 오늘 문득 이런 생각이 들었다.

nextjs

이게 진짜 미래인가?

SSR이 가지는 이점은 많지만 SSR이라는 이점을 누리기 위해 또 언제 도태될지 모르는 메타프레임워크를 배워야한다는게

참...

어려운 밤이다.

웹 개발에서 우린 자주 이 단어를 접하게 된다

돔 이라고도 부르고 알파벳 하나씩 끊어부를때도 있고...

뭐 여러 경우로 부르게 된다. 

오늘 주제는 버추얼돔..그게 무엇인가 이다.

DOM은 줄임말이고 원래의 이름은 Document Object Model 이다

웹페이지의 구조를 대략적으로 나타내는 트리 구조이다

https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction

뭐 자세한 설명은 위의 사이트를 참고하는게 더 정확하고 

React의 버추얼 돔에 대해 설명하겠다.

간혹 백엔드 분들에게 React의 버추얼돔은 왜쓰는걸까요? 라는 질문을 종종 받을때가 있다. 

전통의 방법대로 만든 웹페이지들은 페이지의 내용이 바뀔 경우 페이지 전체를 불러와야하는것을 알고있다.

단지 이 행동은 성능적인 면에서도 뛰어나지 못하지만 UX적인 면에서도 끔찍하다 만약 여러분이 페이지 내용이

실시간으로 업데이트 될때마다 생각해보자 그런데..매번 새로고침이 된다!

이는 끔찍한 유저 경험으로 그렇게 썩 좋지 못한 경험을 전달한다.

이를 보안하고자 React는 버추얼 돔을 도입하여 가상돔의 변경된 부분만을 빠르게 반영하여 해당 컴포넌트 부분만 다시 

불러오는 경우로 좋은 유저 경험을 제공한다. 

원랜 diff니 버추얼 돔이 2개의 비교 방법 뭐 등등 많지만 미리 나중에 쓸 내용을 정리하고자 대충 이런게 있다라는 느낌으

로 정리했다.

주요 언어는 JS 기반이 될것

가급적이면 쉽고 이해하기 편하고 거두절미하고 본론으로 같은 바를 추구하는 바이나

내용이 복잡하거나 설명해야될 내용이 많다면 지켜지지 않을 수 도 있음

그점 유의바랍니다