
나의 첫 직장에서는 백엔드 개발자가 서비스 론칭을 위한 서버 세팅을 도맡아 하고 있었다. 그러다보니 프론트 개발자나 아이폰 개발자와 같은 다른 개발자들은 실서버 배포를 진행할 일이 거의 없었고, 있다고 하더라도 백엔드 개발자에게 요청을 넣고 기다리는 형태로 배포를 진행했었다. 그러다보니 프론트 개발자가 구문 오류를 확인하지 못하고 배포 요청을 진행할 경우 백엔드 개발자가 배포를 진행하다가 빌드 에러가 터져서 검토 요청을 다시 넣고, 프론트 개발자가 검토 요청을 확인하고 재검토를 진행하며 재배포 요청을 넣을 때 까지 상당한 시간이 소모 되는 경우가 많았다. 배포만이 문제가 아니다. 특이하게도 개발자 한 명이 프로젝트 하나를 도맡아 처리하는 성향이 강했던 기업이라 브랜치가 사실 의미가 별로 없었다. 어차피 ..

프로그램 개발을 할 때 단위 테스트라는걸 사용한다고 한다. 말 그대로 작성한 프로그램에 대한 테스트를 진행하는건데, 사실 얘를 들은게 이번이 처음은 아니다. 이런게 있다고 수도 없이 많이 들었고, 코테에서 단위 테스트를 진행하는 기업들도 있어서 낯선 이름은 아니다. 그런데 솔직히 얘를 왜 해야 하는지 100% 이해하는건 아니다. 어차피 프로그램 작성은 해야 하는 일이고, 프로그램이 동작하다가 원하는 흐름대로 되지 않으면 console.log나 break point 걸어두고 테스트 해보면 다 해결 되는 일 아닌가? 하지만 이름 있는 개발자들이 중요하다고 하는데는 이유가 있겠지. 한 번 해보기로 한다. 이번 프로젝트에서 사용해볼 단위 테스트 라이브러리는 Jest인데, 모든 단위 테스트 라이브러리가 그런건진 ..

대충 요렇게 생긴 그래프에 대해서 얘기해보겠다. 싸인, 코싸인, 탄젠트에 대해서는 아무리 수포자라고 하더라도 한번 쯤은 들어본 적이 있을텐데, 위 그래프가 그 중 하나인 싸인 그래프이다. 뜬금없이 싸인그래프를 왜 갖고왔냐면, Javascript Canvas를 가지고 놀다가 물결을 그리고 싶어져서 그리려고 하다가 위와 같은 방법이 있다는 사실을 알게 되었다. 사실 나도 수포자라서 수학적으로 위 그래프를 해석하지는 못하지만, 위 그래프의 모양을 나타내는 방법을 Javascript로 표현하자면 다음과 같다. let stack = 0; const speed = 0.1; function progress() { stack += speed; return Math.sin(stack); } window.setInterv..

개요 우리는 웹 사이트를 개발하건, 게임을 개발하건, 아무튼 뭘 개발하건 사용자로부터 어떤 특정한 값을 얻어야 할 때가 있다. 음식점에 배달을 시킬 때 집 주소를 입력하거나, 게임에서 캐릭터를 만들 때 닉네임을 정한다던지 말이다. 그런데 사용자가 정말 개발자의 의도대로 입력값을 넣어준다면 정말 좋을텐데, 사용자는 그렇게 착하지 않다. 주소지를 입력하는 창에 한 편의 소설을 적을 수도 있고, 닉네임에 불쾌감을 주는 단어나 무슨 뜻인지도 모르겠는 특수문자들을 남발하는 경우가 있을 것이다. (개발지식이 있는 유저들은 게임 닉네임으로 코드를 짜고 있겠지) 서비스 제공자는 이러한 사용자들의 똘끼(?)를 언제나 염두에 두고 있어야 하며, 사용자가 어떤 이상한 짓을 해도 프로그램이 개발자의 의도 하에서 제어가 될 수..
개요 아마 웹 개발자로 일을 했다면, 혹은 공부를 했다면 지나가는 길에 한 번 쯤은 Restful API가 무엇인지 들어봤을 것이다. 뜻이 뭔지 알고 있는 사람도 있을 것이고, 현재 본인이 만들고 있는 프로그램에 사용을 했음에도 불구하고 뜻을 적어보라면 못 적는 사람도 있을 것이다. 그래서 Restful API가 무엇인지 설명해보고자 한다. 자원과 행위의 표현 Restful API란 다시 말해, Resource, Verb, Representations을 말한다. 이렇게 말하면 잘 이해가 안 될 수도 있으니 예제를 보자. 예제 우리가 보통 프론트엔드를 개발하여 서버와 통신을 하고자 한다면, 해당 서버의 특정 자원을 요구하게 된다. 하지만 해당 자원을 어떤 형태로 사용할 것인지를 명시하기 위해 우리는 보통 ..

왜 갑자기 이런걸 신경쓰나? 갑작스레 신경쓰이게 된 건 아니고, 예전부터 상용 프로그램과 내가 만든 프로그램의 차이가 무엇이길래 이렇게 크게 사용감이 다른가 의아했었다. 사실 퍼포먼스에 대해서는 많은 프론트엔드 개발자들이 마음에 담아두는 부분일 것이다. 웹앱으로 유명한 노션을 보면 그렇게 좋을 수가 없는데 왜 내가 만든건 사용감이 이 모양일까. 버튼을 누르면 0.5초 정도 느리게 움직이는 것 같고, 로딩은 또 왜이렇게 긴지... 이 부분은 내가 다니는 회사에서도 고질적인 문제였다. 실력자들은 많았지만 작은 규모의 회사다보니 하나부터 열 까지 선임 개발자가 챙겨줄 수 없었다는 점. 그래서 내가 만든 앱이 왜 이렇게 구린지 나름대로 원인을 분석해 보고, 사내 행사 때 프레젠테이션을 했던 내용을 토대로 여기에..

본문에서 말하려는 이슈는 위와 같은 이슈를 말하는 것이다. eslint에 대해서는 다음 기회에 상세히 서술할 예정이니 오늘은 eslint를 알고 있다는 전제 하에 글을 이어 간다. eslint는 간략하게 말하자면, 자칫 잘못하면 중구난방으로 작성될 수 있는 자유분방한 언어인 Javascript를 조금 더 엄격하게 관리하기 위한 문법적 규칙을 얘기한다. 위 이슈는 문서에 작성 된 코드의 개행 문자가 CRLF 방식으로 작성 되었기에 뱉는 에러인데, 왜 CRLF를 에러로 다룰까? 운영 체제별로 파일을 다루는 방식이 다르듯, 개행 문자도 서로 다르게 취급되는데, 리눅스, Mac OS 등의 운영체제는 LF 방식을 지원하며, Windows는 CRLF를 기본으로, LF도 지원한다. 그렇기 때문에 맥, 리눅스, 윈도우..
서론많은 개발자들이 자신의 소스코드를 보관하기 위해 깃을 사용한다.그 중에서도 특히나 많은 개발자들이 이용하는 깃허브는 안정된 서비스와 여러 편의 기능으로 인해 개인 개발자 뿐 아니라 많은 회사들이 사내 프로젝트를 저장하기 위하여 사용하기도 한다.그런 깃허브가 제안한 브랜치 관리 방법이 있는데, 나도 기억에 남길겸 이 곳에 정리하기로 한다. 통상적으로 사용되던 Git Flow는 다음과 같았다. 척 보기에도 굉장히 어지럽다. 현재 많은 깃 프로그램이 그래프 시스템을 지원하는 이유이다. master 브랜치는 실서버에 배포작업을 진행할 브랜치, hotfix는 실서버에서 문제가 생겼을 때 급하게 작업하기 위한 브랜치, feature 브랜치는 이슈 수정 및 추가 개발에 사용되며 실제로는 푸쉬하지 않을 브랜치, r..
개요 본인이 만든 블로그를 구글 검색 엔진에 띄우기 위해서는 구글에 내 홈페이지가 있다는 사실을 알려야 한다. 그러한 작업을 진행하려면 구글의 Search console에 사이트를 등록해야 한다는 사실을 알 것이다. 모른다면 '티스토리 구글' 이라고만 검색해도 정말 많은 블로그에서 방법을 소개하고 있다. 하지만 내가 이 글에서 정리할 것은 그런 일반적인 검색엔진 등록 방법이 아니라, 검색 엔진 등록 작업 중 Sitemap 등록 작업이라는게 있는데, 간단하면서도 나를 고생시킨 이 문제에 대해서 이야기하고자 한다. 본론많은 블로그에서 구글에 사이트맵을 등록하기 위해서는 Sitemap.xml을 게시글에 등록 후, 미리보기를 눌러서 파일의 링크를 복사하여 구글의 Search Console에 넘긴다고 소개를 할 ..
- Total
- Today
- Yesterday
- eslint
- 기능경기대회
- kakaocdn
- 산업기능요원 인센티브T.O
- 검색
- JavaScript
- 초성검색
- 산업기능요원 현역
- 대학생 현역 산업기능요원
- 정보처리산업기사 요약
- 2021년 산업기능요원
- 초성
- 2021년 산업기능요원 재배정
- IT산업기능요원
- 산업기능요원 폐지
- 대학생 산업기능요원
- React Native
- NUXT
- 현역 산업기능요원
- 21년 산업기능요원
- React-Native
- 산업기능요원
- 산업기능요원 재배정
- 기능대회
- 캔버스 그림판 javascript
- 전국기능경기대회
- 산업기능요원 재배정 확정
- jest
- 정보처리 산업기능요원
- 2020정보처리산업기사
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |