隣席の開発者群

이건 정말 잡담이다. 그냥 왜 Front를 선택한건지, 왜 풀스택이 아닌지, 그러려면 어떻게 해야할지 그냥 내 생각을 쓰려는거다. 왜 쓰냐고 묻는다면, 지금 이 생각을 정리해야 나중에 잊고 살다가도 떠올릴테니까. 1. 왜 Front인가? 글쎄 이건 나도 의문이다. 1년 남짓, 얼마 안되는 개발 인생이지만 조금 이야기를 하자면 많은 개발자들이 그렇듯 난 국비지원학원 출신이다. 절대 컴퓨터 공학을 전공하지 않았고, 오히려 경제학이라는 전공으로 학사학위를 가지고 있다. 사실 학문으로의 컴퓨터는 관심도 없었다. 그냥 테크덕후에 콘솔겜 좋아하고, 오타쿠라 컴퓨터와는 멀어지기 힘든 인생이었기 때문에 하드웨어 정도만 자연스레 좀 잘 알게 된 것 뿐이었다. 어쨌든 내게 재미없는 경제학보다는 원래 좋아했던 컴퓨터와 연관..

REST 를 설명하려다보니 HTTP에 대한 설명이 필요한 것 같아서 정리해왔다. 블로그 제대로 쓰는 것도 쉽지 않구나.. 시작해보자.. 1. 프로토콜...? HTTP란 뭘까? HyperText Transfer Protocol의 줄임말이다. 후벼파보니 더 알 수 없는 말만 있다. 일단 프로토콜을 사전에서 찾아보면 통신규약이다. 더 길긴한데, 그냥 축약하자. 더 다른 의미 없다. 뭐 Transfer 나 Protocol 같은 경우는 일반적인 단어 + 앞에서 설명하였음. 으로 퉁칠 수 있는데 그럼 HyperText는 뭔가? 그냥 대충 말하면 완전멋진초월텍스트다. 기존의 인류 문명은 책이라는 문서양식를 가지고 있었다. 특정방향으로 방향성을 가지고 선이 이어지듯 연결되는 텍스트들의 집합 = 책(선형적인 텍스트) 인..

어제의 글에 이어서 REST API / RESTful API 에 대한 이야기를 해볼까 한다. 1. REST API? 2023.04.26 - [Arch] - [REST] REST REST API는 윗 글에서 설명한 REST 의 규칙을 지켜서 만든 API를 의미한다. 해당 규칙을 적용하면서 또 명확히 제시하는 설계 지침? 같은게 있는데 한번 보도록 하자. 1) URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다. 찾아본 예시들이 "동사보다는 명사" 이 부분에 잘 안맞는 것 같은데, "동사보다는 명사" 라는 말보단 특정한 가공 없는 본래의 단어 그대로를 쓰자는 말과 같다고 느껴진다. 예를 들면 run 과 같은 단어를 진행형, 동명사, 3인칭, 과거형 이런 가공 없이 run 그대로 쓴다는 느낌이 ..

일단 서두에 하고 싶은 얘기가 있다. REST API의 목적 상 나름 쉽게 설명하려고 애썼을 것 같긴한데.. 이해가 잘 안간다. 왜냐? 우리나라 사람들 특이 영어로 아무리 쉽게 써놔도 어렵게 번역한다는 것이니까.. 대학에서 전공서적으로 번역판, 원서 둘 다 써본 사람이라면 이해할 것이다. 오히려 원서의 용어들이 훨씬 잘 와닿을 때가 많다. REST 도 말이 어려운데다 줄여놔서 그렇지. 당장 개발할 때 필요한 수준의 개념을 정립하려면 그렇게 어렵지 않다고 본다. 1. REST란? 오늘도 사전적 정의 부터 먼저 가져와봤다. "REST는 Representational State Transfer의 약자로 자원(Resource)을 이름으로 구분하여 자원의 상태를 주고 받는 모든 것" 대부분 어딜 가도 이렇게 설명..

학원에서 자바스크립트를 처음 배우던 시점에 Hoisting을 가르쳐줬었던 것으로 기억한다. 그 때는 애초에 수강생들이 코딩의 ㅋ 정도 겨우 알아가는 과정이라 알려줘봐야 제대로 이해할 리가 만무하니 그냥 선언하기 전에 실행시켜도 나중에 뒤에서 선언만 해주면 문제가 없다. 라는 식으로 알려줬었는데, 이번에 블로그 쓰기 시작하면서 제대로 정리해야겠다는 생각이 들어 작성한다. Hoisting (호이스팅) 이란 무엇인가? 공식적인 설명은 "인터프리터가 변수와 함수의 메모리 공간을 선언 전에 미리 할당하는 것 " 을 의미한다. 하지만 우리는 이 말로는 절대 이해할 수 없다. 그래서 일반적으로 잘 풀어서 쉽게 설명하는 경우를 가져오면 "변수와 함수의 선언과 초기화를 분리한 후, 선언만을 코드의 최상단으로 옮기는 것"..

순서가 조금 잘못된 것 같긴한데, 어쩔 수 없다고 생각한다. 체계적으로 공부를 해서 기초부터 차근차근 닦아올려가며 일을 하게 된 것이 아니라 당장 오늘 이 코드를 작성하지 못하면 큰일난다는 생각으로 언제나 목에 칼이 들어온 기분으로 코드를 만들어가며 체득하는 신입 SI 개발자는 이런 체계적인 용어? 개념적인 지식? 그런거 모르기 때문에 아 내가 지금까지 써온 이런게 이런 이름이구나~ 라며 깨닫기 마련이다. 오늘은 이런 식으로 깨달은 Scope 와 Closure 기법에 대한 이야기를 해보고자 한다. 1. Scope (유효범위) Scope는 유효범위를 의미한다. 정의나 설명을 통해 이야기하면 누구나 한번에 이해하긴 힘들다. 하지만 일단 이런거다 정도는 알고 있어야하니 정리해보자. 함수, 변수를 선언 했을 때..

어제 일하다 한가지 이상한 점을 확인 했는데 Ag Grid에서 발생한 문제였다. 일단 먼저 Ag Grid가 제공하는 파워풀한 기능들이 당연히 이런걸 전제하고 만들어져있을 것이라고 생각하고 있었는데 세상에 당연한 것은 없다는 것을 한 번 더 깨닫게 해준다. 1) 사건의 발단 지금은 막 단위테스트가 진행되는 중이고 곧 통합테스트가 진행될 예정인 타이밍이라, 내 옆자리에 계신 선배님이 정말 열심히 테스트하는데로 버그를 수정하시며 고생을 하고 계신다. 근데 어제 저녁 "어 오타씨 AG Grid row Data 넣어주면 자체적으로 그 데이터랑 똑같은 데이터를 가지고 있는게 아니라 원본을 그대로 보고 있네요?" 라며 말씀을 하셨는데, 그러면 안되는데.. 라는 생각이 스쳐지나갔다. 자세히 설명하면 Grid 상에서 데..

내가 경험한 프로젝트의 아키텍처들은 경력에 비해 상당히 다양하다. 우리 회사의 특성 상 정해진 솔루션이 있고 매번 똑같은 구조의 프로젝트만 경험할 것이라고 예상했으나 고객사에 기존에 개발되어있던 Legacy 프로젝트가 있다면 꼭 그렇지 않다는 사실을 알게 되었다. 내가 경험한 프로젝트 구조들은 다음과 같다. 1. 학원프로젝트 2. (React + Redux) Monolithic Arch.(MA)를 채용한 고객사의 Legacy 프로젝트 3. (React + Mobx) MSA 를 채용한 우리회사의 솔루션이 들어간 프로젝트 4. (React + React-Query) MSA(MonoRepo)를 채용한 우리 회사의 버전업 솔루션 프로젝트 이 중 오늘은 Monolithic Arch. 와 MSA간의 차이에 대해서 ..

1) 사건의 발단 회사 동료가 질문을 해왔다. 그 질문이 뭐였냐 하면, 현재 우리가 진행하는 프로젝트 상에서 테이블을 띄워주는 library로 AGgrid를 사용하고 있다. 근데 이 AG grid의 함수들을 사용하는 방법이 두가지다. 1번이 gridRef를 통해 DOM 자체를 참조하여 해당 Grid DOM의 API를 끌어다쓰는 방법이고 2번이 해당 Grid DOM 의 gridApi 자체를 State에 set해두고 그 State를 사용하는 방법이다. 여기서 동료가 모르곘다는 부분은 DOM 이 이해가 가지 않는다는 것이었다. 그래서 설명해준 그대로 블로그 글도 써두기로 했다. 2) DOM이란? 우리는 사실 DOM이라는 말은 진짜 많이 들어봤다. React에 대한 내용을 조금이라도 들어봤다면 Virtual D..

알고리즘을 시작하기 전에 자료구조라는 것을 알아야한다고 해서 봤는데, 정보처리기사 따던 시점에 봤던 말들이 나와있어서 좀 반가웠다. 그런 김에 복습 겸 살짝 정리해보고자 한다. 1) Queue (큐) Queue는 위 아래 구멍이 뚫려있는 원통으로 생각해보면 좋다. 일단 정보처리기사를 공부하던 나는 이렇게 이해했고, 교재에서도 제시하니 가장 명확한 설명이 아닐까 싶다. 위의 그림과 같이 Queue는 입구와 출구가 정해져있다. 한쪽으로는 데이터를 꺼내고, 한쪽에서는 데이터를 넣기만 하도록 구조를 잡는다고 보면 된다. 이런 모양을 가지고 있게 되면 처음 넣은 요소가 꺼낼때도 가장 처음으로 나오게 되는데 이를 'FIFO' (First In First Out) 라고 부른다. 쉽게 이해하기 위해 JS 코드로 한번 ..