하고싶은대로##

Error: Could not find a valid build in the '/Users/이름/폴더/폴더이름/.next' directory! Try building your app with 'next build' before starting the server.

next dev나 next start 명령어를 쳤을 때, 실행이 안될 경우 문제 해결 방법이다.

문제 해결 방법은 간단하다.

next build 명령어를 입력 후, next dev를 하면 된다.

어려운 문제는 아니고, 먼저 빌드를 해놓아야 실행가능한다고 한다.

사실 오류 창만 잘 읽으면 해결할 문제이다.

요즘 프레임워크나 라이브러리는 친절해서 오류 문구만 잘 읽어도 50프로 이상은 잘 해결되는 것 같다.

웹을 만들다보면, onFocus, onBlur, onClick을 태그에 옵션에 주어 많이 사용한다.

이 옵션들을 사용할 때 문제가 발생했는데, 순서의 문제가 발생했다.

나 같은 경우, 검색창을 만드는데, 검색창을 클릭, 즉 Focus를 넣었을 때, 추천 검색어가 밑에 주르륵 뜨도록 하고 싶었다.

그리고 검색창에 Focus가 사라졌거나, 추천 검색어를 클릭했을때, 추천 검색어 창이 사라지도록 하고 싶었다.

검색창에 Focus가 사라졌을때는, 검색창이라는 input 박스 이외에 다른 곳을 클릭했을때를 말한다.

이런 처리는 onBlur을 사용하여 해결할 수 있다.

onFocusOut이라는 옵션도 있지만, 이 옵션은 styled component에서 작동을 하지 않길래 onBlur을 사용했다...나중에 원인을 알아봐야하겠지만..

어쨌든 이럴때 문제가 있었다.

onBlur이 onClick보다 먼저 작동하는 것이다.

무슨 말이냐면, 추천 검색어를 클릭하려고 하는 순간, 검색창에서 Focus는 사라지고, 추천 검색어 창이 사라져서 클릭이 안되는 것이다!!

이 문제를 해결하기 위해, onBlur에 함수에 시간 지연을 넣어서 해결할까, 아니면 boolean 변수를 추가할까 고민을 했는데,

더 나은 방법이 있었다.

바로  onMouseDown이라는 옵션을 사용하는 것!

마우스 클릭을 했을때! 그러니까 마우스 버튼을 눌렀을때 작동하는 옵션인데,

이 옵션은 다행히 onBlur보다 먼저 작동하여 내가 겪는 문제를 해결할 수 있었다.

개발자는 개발 도서를 읽어야한다는 많은 사람들의 말을 듣고, 개발 도서를 읽어야겠다!라는 생각으로 읽은 책이다.

Effective C++, 패턴 디자인 같은 책을 읽긴 좀 그래서 개발 도서면서 좀 가벼워 보이는 제목을 가진 이 책을 읽어보았다.

처음에는 이게 왜 개발 도서일까?라는 생각을 했는데 많은 것을 배웠다....

읽은 책들에 글을 안쓰는게 읽은 책이 없어서가 아니라 글 쓰기가 귀찮아서 안쓰는 건데, 이 책만큼은 남겨둬야한다 생각해서 글을 쓴다.

2003년에 처음 책이 쓰여졌고, 책의 저자 폴 그레이엄은 정말 혜안이 있다는 생각이 들었다.

2013년에 책이 개정되면서 내용도 많이 개정되었는지 아닌지는 모르겠지만, 2013년이라고 하더라도, 7년이 지난 지금의 미래를 예측했다..

앱들이 기기 종속적이 아니라, 웹으로 옮겨질 거라는 예측 ( 저자는 드랍박스를 창립해서 승승장구하고 있는 것으로 안다 )

언어의 변화 ( 물론 책에서는 저자는 LISP를 찬양했지만, LISP와 비슷한 Python이 지금의 대세가 되었다 )

등등 정말 많은 변화를 예측했고, 현실이 되었다.

물론 내가 2003년에 개발자로 살아보지 않아서, 그 시대 살았다면, 누구나 예측 가능한 내용이었을 수도 있지만, 무엇이 되었든, 책을 읽으면서 소름이 돋았다.

이 책의 전반적인 내용은

1. 해커와 화가를 비교하며 연관 없어 보이는 두 직업은 매우 비슷하다!라는 내용과

2. 공부쟁이( 문제 해결에 몰두하는 사람 )이 세상을 바꾼다라는 내용이다.

저자가 스타트업으로 성공한 사람이라 ( 비아웹을 만들어서 야후에 팔았다 ) 스타트업 관련된 내용들도 많은데,

스타트업에 대한 이야기는 나를 매혹시켰고, 이번 방학에 스타트업에서 인턴을 하게 되었다...

일을 해보니 책에서 읽은만큼 매력적이지는 않은 것 같당...회사 바이 회사겠지만..

저자는 능력이 된다면 스타트업에서 일해라! 일은 100배 힘들지만, 그만큼 성장하고 100배만큼 돈 벌 수 있다!라는 말과

정형화된 개발을 안하고 자유롭게 개발할 수 있다! 라는 말이 정말 인상적으로 들렸다.

올해 초에 많이 고민한게, 좋은 개발자가 되려면 사실 부품화가 될 수 밖에 없는데, 이게 너무 스트레스였다.

디자인 패턴을 공부하고, 소프트웨어 공학을 공부하고, 코딩 컨벤션을 공부하며 틀에 박힌 코딩을 한다는 생각이 너무 스트레스로 다가왔고,

코딩하는 내가 공장에서 똑같은 일을 계속하는 로봇처럼 느껴졌고, 개발자를 포기할까도 많이 생각했다.

하지만 이 글을 읽으면서 관점의 차이라는 것을 알게 되었고, 코딩하는 것이 그림을 그리는 것처럼 자유로운 행위로 느껴졌다.

물론 힘들고, 틀에 맞춰야하는 경우도 많지만, 예전보다는 스트레스를 덜 받는 것 같다.

그리고 예전에는 일자리에 대한 강박관념이 있었다. 뭔가 대기업을 가야할 것 같고, 다른 곳을 가면 불안정적이고 성장도 힘들고 그럴 거라는 생각이 있었지만, 그런 것도 아니고, 내가 스스로 만든 강박관념이라는 것을 알게 되었다.

사람이 아주 많이 바뀌진 않았겠지만, 책을 읽고 예전보다는 시야가 넓어졌고, 덕분에 개발에 대한 고정관념과 강박관념이 사라진 것 같다.

그리고 전보다 개발을 즐겁게 할 수 있게 되었다.

그리고 과거의 개발자인 저자 폴 그레이엄이 생각한 내용들을 보며, 지금 우리가 왜 이런 기술을 사용하고, 이런 위치에 있는지 이해할 수 있었다.

학교에서 프로그래밍 언어 시간에 배웠던 내용을 머리로만 이해했다면, 이 책을 읽고 배운 내용들을 가슴으로 와닿게 이해할 수 있었다.

이 책을 읽고 PL 수업을 들었다면, 즐겁게 수업을 들었을텐데,, 좀 아쉽다

그리고 개발적으로뿐만 아니라 스타트업?쪽으로도 시야가 넓어진 것 같다.

개발 마인드가 나와 생각하는 것이 비슷해서 재밌게 읽었는데,

문제 해결 의식, 문제 해결 방법 등을 배울 수 있었다.

특히 디자인과 비교를 하면서 설명을 했는데, 사람들의 문제를 해결해야한다는 생각, 그리고 계속해서 발전해야한다는 생각, 정답은 없다는 생각 등

이 책을 읽고, 개발이 디자인과 닮았고, 개발이 정답이 있는 수학문제보다는, 예술에 가깝다는 생각이 많이 들었다.

그리고 책의 마지막 구절이 기억에 남는다.

디자인은 사람을 위한 것이고, 디자이너도 사람이다.

개발 언어를 설명하면서 말한 것인데, 예전에는 "왜 파이썬을 써? 비개발자나 쓰는거아니야? 속도도 느린거"

이런 생각을 가졌었는데, 언어에 대한 내 사고가 바뀐 것 같다.

그리고 개발할 때, 처음부터 완벽할 수는 없다. 

프로토타입을 계속 만들며 발전을 시켜야한다라는 말은

요즘 유행하는 DEV Oops나 에자일 기법을 떠올리게 했다.

이 책을 읽고, 나도 이런 사람처럼 끊임없이 발전하고 싶고, 혜안을 가지고 살고 싶다고 생각했다.

정말 대단한건 이 책을 쓴 이후로 드롭박스로 성공한 것....

학교 도서관에서 빌려서 읽었는데, 책을 사서 두고두고 읽고싶다.

물론 이 책의 내용이 하나부터 열까지 다 맞는건 아니지만,

개발적으로, 그리고 개발 외적으로 정말 나에게 많은 도움이 된 것 같다.

근데 책이 너무 옛날 책이라 예쁘지도 않고 읽기 불편한데 리뉴얼한번만 해주면 좋겟다..그러면 책 살텐데

Lodash의 Debounce를 공부하다가, 정말 어이가 없는 경우가 있어서 하루 종일 무엇이 문제일까 고민하다가,

드디어 원인을 알아냈다!

문제는 이렇다

먼저 내가 어떤 것을 만드려고 했는지 설명하겠다.

현재 만든 것은 이름을 입력하면, axios로 api에서 가져온 이름 데이터 중, Family Name, 즉 성이 같은 이름들을 뽑아내는 것이다.

이럴 때, 검색 창에서 이름을 입력할 때마다 계속 데이터를 요청하면 서버에 과부하를 가져다 줄 수 있다.

예를 들면 김길동을 검색할 때, ㄱ -> 기 -> 김 -> 김ㄱ ->  김기 -> 김길  이런 순으로 나아갈텐데, 이렇게 변화할 때마다,

서버에 계속해서 ㄱ에 맞는 데이터 가져와! 기에 맞는 데이터 가져와! 김에 맞는 데이터 가져와! 김ㄱ에서 김에 맞는 데이터 가져와!

이렇게 계속 요청한다. 이것은 서버에 요청도 문제지만, 렌더링 같은 프론트 쪽에서도 오버헤드가 커지게 된다.

이런 경우를 방지하기 위해 방법을 생각해봤는데,

내가 처음에 생각한 방법은 ,useEffect를 사용하는 방법이었다.

검색어에 입력된 정보를 문자열 변수에 저장한 후, 문자열의 첫번째 값이 바뀔 때만 데이터를 서버에 요청하는 방식이었다.

이 방법도 잘 작동했지만, debounce delay라는 방법이 있고, 실제로 이 방법을 많이 사용한다하여 공부해보았다.

Lodash라는 라이브러리에서 제공하는 함수인데, ㄱ -> 기 -> 김 -> 김ㄱ ->  김기 -> 김길 이렇게 진행되며 요청을 할 때, 계속해서 요청을 보내는 것이 아니라, 값이 바뀔 때는 가만히 있다가, 값이 바뀌지 않을 때 마지막 요청, 마지막 이벤트에 대한 함수의 결과 값만 반환하는 방식이었다.

그래서 debounce delay라는 방식은 값이 바뀌지 않을 때, 이벤트가 더 이상 일어나지 않은 후 얼마 간의 딜레이 후에 작동을 하는 방식이다.

이에 대한 설명은 

https://frontcode.tistory.com/60

이 블로그를 참고해보는 것이 좋을 것 같다. 여기 글에서는 일단 오류 해결을 중점적으로 작성할 예정이다.

그래서 코드를

이렇게 작성했을 때는 매우 잘 작동하였다. 

하지만 inputData를 useState를 사용하여 state에 저장하여 코드를 작성하면 이렇게

딜레이가 있긴한데, 일정 딜레이 이후에 9번 변화가 있었다면 9번을 데이터 요청을 주르르륵한다.

아마 원인은 state의 값이 바뀔 때마다 리렌더링 되는데, 이때마다 함수가 새롭게 호출이 되어 문제가 발생하는 것 같다.

실제로 컴포넌트 내에 이런 "하하"라는 로그를 찍어서 확인해보면, state 값이 변경될 때마다 렌더링이 엄청나게 발생하는 것을 볼 수 있다.

그럼 이 문제를 어떻게 해결할 것인가?

state를 사용하지 않는 방법이 있지만, 이것은 근본적인 해결책이 되지 못한다.

그래서

이렇게 setInputData를 debounce Delay 함수에 넣어주면 문제가 해결된다.

하지만 이렇게 되면 비동기적으로 진행되는 JavaScript의 특성상,

fetchData가 먼저 실행되서 InputData가 바뀐 것이 반영되지 않을 수 있다.

이 부분만 고려해주면 문제 끝!!

많이 부족하지만 코드를 올려본다

https://github.com/puba5/MatZipJokBo/blob/master/pages/axiosTest.js

JavaScript에는 Function Chaining 혹은 Method Chaining이라는 기법이 있다.

만약 A라는 리스트에 filter와 map이라는 두 개의 메소드를 적용시키고 싶다.

그렇다면 원래라면

A= A.filter(~~~)

A.map(~~~~)

이런 식으로 두 줄로 적어주어야할 것이다.

하지만 이것을

A.filter(~~).map(~~~)

이렇게 한 줄로 줄여줄 수 있고, 이것을 Method Chaining이라 한다.

A = A.filter(~~~~)가 A'이 되고

A'.map(~~~)을 수행한다.

따라서 Method Chainging을 할 때 순차적으로 적는 것이 중요하다.

JavaScript는 브라우저에 컴파일된다.

그 말은 즉 따로 IDE를 설치 안해도 코딩이 가능하다는 것이다!

물론 가장 좋은 것은 좋은 IDE를 사용하여 코딩하는 것이지만,

JavaScript 공부하다가 간단하게 문법이 맞나 틀리나? 확인을 해보려고

귀찮게 IDE키고, 컴파일을 해야한다.

이럴 때 간단하고 빠르게 코딩하기 좋은 방법을 소개해드리려한다.

방법은 간단하다

f12 버튼을 누르거나, 마우스 우클릭 후 검사 버튼을 클릭한다.

그럼 웹 개발자모드가 화면에 나타난다.

여기서 오른쪽 위에 Console 탭으로 이동!

그러면 콘솔창이 깜빡깜빡 거린다.

여기서 간단하게 코딩이 가능하다!

예를 들어 상수 값이 변경 가능한가?가 궁금하면

이렇게 

const a = 3

a = 4 

코드를 입력했다.

그랬더니 상수의 값을 변경하려고해서 에러가 난다.

이렇게 문법적 오류도 잡아주고, 여기서 console.log로 확인도 가능하다.

이렇게 간단하게 JavaScript 코딩이 가능하다.

물론 복잡한 코딩은 좀 힘들 수 있겠지만, 간단한 것들은 이렇게 확인 가능하니,

자주 활용하면 좋을 것 같다 ㅎㅎ

우리가 주로 사용하는 컴퓨터 언어에는 반올림 함수가 내장되어 있다.

예를 들면 C나 C++의 경우 round()라는 함수가 존재하고, 수학 관련 라이브러리를 사용한다.

#include <math.h>  // C언어의 경우

#include <cmath>  // C++의 경우

using namespace std // C++의 경우

int main(){

   int a = round(4.5);

 // a는 5라는 값을 가진다. 

   return 0;
}

이런 식으로 이미 구현되어있는 반올림 함수가 있다.

파이썬도 물론 있다.

파이썬의 반올림 내장함수는 round()이다.

하지만 여기서 매우 어이가 없는 걸 볼 수가 있는데

print(round(3.5))
print(round(3.4))
print(round(4.5))

print(round(4.6))

이렇게 하면 결과가 

4

3

5

5

이렇게 나올 것으로 예상할텐데 실제로는

4

3

4

5

이렇게 나온다.

그 이유는

파이썬에서 round 함수로 0.5를 반올림할 때, 정수 부분이 짝수면 반내림이 되고, 홀수면 반올림이 된다.

즉 3.5의 경우에는 반올림이 되서 4가 되고

4.5의 경우에는 반내림이 되어서 4가 된 것이다.

이 문제를 해결해주기 위해서는

1. 반올림 함수를 새로 구현해주든가,

2. 짝수일 경우 0.1을 더하여 round 함수를 사용하면 된다.

물론 round 함수에 인자를 넣으면, 소수점 첫번째가 아닌 다른 부분에서도 반올림할 수 있기 때문에

정수에서 반올림, 소숫점 두번째, 세번째에서 반올림할 때도 이 부분을 생각해주어야한다.

사사오입이 정확히 이런 의미는 아니지만, 편하게 외우기 위하여 사사오입이라고 외우면 편하다.

사(4)일 땐 버리고, 오(5)일 땐 올리고,

짝수일땐 버리고, 홀수일땐 올리고라고 생각하면 편하다.

C/C++/JavaScript 같은 C에서 파생된 언어에서는 내가 아는 반올림과 같았는데

파이썬은 이럴 줄은 몰랐다...ㅠㅠ 나중에 round를 사용한 코드에서 원하는 Output이 제대로 안나온다면

이 문제가 아닐까 생각해보는게 좋을 것 같다.

혹시 몰라서 테스트해본 JavaScript

내가 아는 반올림이 맞다..

왜 파이썬은..아닐까...하ㅠㅠ 

ES6 문법이 확장되면서 화살표 함수라는 것이 생겼다.

let a =  () => { } 이런 식으로 쓰는 함수인데, 

단순히 표기가 간편해졌다 뿐만 아니라 여러 가지 차이점들이 생겼다.

1. this

아마 가장 큰 차이가 this의 여부가 아닐까 싶은데, 화살표 함수에서는 this가 바인딩 되지 않는다.

즉 함수 내부에서 this를 생성하지 않으므로, this를 사용할 시 바로 바깥의 함수 또는 클래스의 this를 불러온다.

그래서 함수 안의 함수를 사용할 때, this를 바인딩해주어야하는 경우가 많은데, 화살표 함수는 그 수고를 줄일 수 있다.

하지만 이런 점 때문에, 화살표 함수는 함수나 클래스의 메소드를 만들때는 적절하지 않다.

2. arguments

일반적인 function에서는 argument라는 문법을 사용할 수 있는데

함수의 인자들을 접근할 수 있습니다.

예를 들면 

foo(){
    console.log(arguments[0])

}

이렇게 함수를 생성하면,

foo(1)로 함수를 사용하면, 1이 로그에 찍힙니다.

하지만 화살표함수는 이 기능을 지원하지않습니다.

하지만 args라는 조금은 다른 문법을 지원합니다.

3. new 사용 불가 ( 생성자로 사용 불가 )

말그대로 클래스나 객체의 생성자로 사용 불가하다

그와 동시에 new를 붙혀서 생성할 수 없다.

이 부분은 좀 더 사용하면서 익혀봐야할 것 같다.

여러 글을 읽으면서 느낀 것은 내가 화살표 함수를 모르는 것보다, 기존 함수를 잘 몰랐다는 생각이 많이 들었다.