규도자 개발 블로그
next.js에서 sass사용하기 react에서 썼던 것처럼 당연히 될 줄 알았는데 이게 웬걸 오류가 뜬다. 해서 찾아보니 방법이 다 있더라. $ npm install --save @zeit/next-sass node-sass //npm $ yarn add @zeit/next-sass node-sass //yarn 그리고 프로젝트 루트디렉토리에 next.config.js를 생성한다. package.json과 같은 위치라고 보면 된다. 그 안에 다음 내용을 입력한다. // next.config.js const withSass = require('@zeit/next-sass'); module.exports = withSass(); sass뿐만 아니라 css도 같이 사용할 거라면 아래와 같이 입력하면 된다. ..
엔트로피. 열역학 제 2법칙의 다른 이름이다. 간단하게 우주만물은 정돈된 상태에서 혼돈된 상태로 가고 있다는 말이다. 우리가 석유를 소비하면 석유형태로 저장돼있는 에너지가 열로 변하고 그 화학작용으로 인해 석유가 가스형태로 대기 중에 흩어지는 걸 생각하면 된다. 영원할 것만 같은 태양도 언젠가는 핵융합과정이 끝나는 것처럼 말이다. 엔트로피라는 책이 있는데 거기에서 재활용에 대한 부분이 나온다. 세상에 재활용은 없다는 게 책의 뜻이었다. 이게 무슨 소리인가 하겠지만 버려진 플라스틱을 다시 모아서 쓸 수 있는 플라스틱으로 재가공한다는 것 자체가 에너지를 소비하기 때문에 재활용이 아니라는 게 골자이다. 소프트웨어는 다르다. 물론 찾아서 적용하는 데에는 에너지가 소비된다. 하지만 직접 만드는 것보다 비교가 되지..
모던웹의 정의가 Single Page Application을 기반으로 한 다양한 동작과 데이터변환이 이뤄지는, 흡사 네이티브 앱과 비슷한 형태로 점점 구체화되면서 React나 Angular, Vue 등등의 node진영의 프론트엔드 프레임워크, 혹은 라이브러리들이 주목받고 있다. 이제부터는 순전 내 경험이다. 이게 좋다 저게 좋다 뭐가 좋다고 해서 막상 써보려고 하면 만만찮은 러닝커브에 곤혹스럽다. 그뿐이랴, 하나의 라이브러리나 프레임워크를 배워보려고 하면 넝쿨에 딸려 올라오는 감자 알뿌리들마냥 다른 것들이 후두두둑 같이 떨어진다. 넌 이게 하고 싶어? 그럼 이것도 배워야 돼. 이 기능을 넣고 싶니? 으음~ 그땐 이게 필요해. 항상 이런 식이다. 나만 해도 그냥 프론트엔드를 React.js로, 백엔드를 D..
오직 자신없는 사람들만 의도로 평가받길 원한다. 어디에선가 봤던 말인데 너무나도 공감가는 말이라 적어뒀다. 요즘 정치적 올바름이다 뭐다 해가지고 어떤 창조물이든 창작물이든 결과물을 막론하고 못배워 쳐먹어서 우리의 의도를 파악하지 못한다느니 뭐라느니 생산자와 소비자의 관계가 역전된 듯한 것들을 많이 봐와서일까. 의도가 중요하지 않다는 얘기는 아니다. 일단 '기본'은 갖춘 상태에서 지껄인다면 모를까 말이다. 그리고 애초에 진짜 마스터피스라고 불리우는 작품은 딱히 저렇게 의도에 동정여론을 불러일으키려 하지도 않는다. 오히려 나중에 숨겨진 의도를 깨닫고 더 감탄한다면 모를까. 그러니까 의도를 강조하는 사람들은 자신들의 부끄러운 결과물을 감추려고 의도라는 방패로 감싸는 것이다. 왜냐. 의도라는 것은 그 어떤 신성..
항상 vendor, sources, src, images, lib 등 자주 쓰이는 디렉토리 이름에 신경이 쓰였다. 용도도 궁금하고... 종국에는 개인적으로 프로젝트를 하는데 유지보수에 도움이 될까 하는 이유로 많은 사람들이 쓰는 디렉토리 이름들을 찾아봤는데 아무리 해도 위에 썼던 이름들 혹은 내가 작업하며 봤던 만들어져있던 디렉토리 이름 그 이상은 찾을 수가 없었다. 그러던 와중 내가 쓰는 IDE인 Jetbrain사의 IntelliJ Idea에 디렉터리나 파일 아이콘을 atom의 것으로 만들어주는 플러그인을 발견하였다. 이것을 보니 특정 이름의 디렉토리만 atom의 디렉토리 모양으로 바꿔주는 것으로 보아 이 소스코드를 보면 어떤 디렉토리이름을 많이 사용하는지 역추적할 수 있겠다 싶어서 뒤져봤다. 이곳이 ..
나는 코딩이나 프로그래밍이라는 작업에 있어서 그 범주가 어디에 속해있냐고 정의해야한다고 하면 지극히 사무적인 업무와 예술 같은 창의적인 행위 그 사이의 어느쯤으로 둘 것이다. 데이터의 정제와 전송은 꼭 일정한 규격을 맞춰야 하는 사무적인 일 같지만 그 내부의 코드는 만드는 사람마다 제각각이기 때문이다. 개인적인 지론이지만 프로그래머의 최종 아웃풋은 서비스나 정제된 데이터가 아닌 코드라고 생각한다. (원할한 서비스나 데이터는 응당 있어야할 요소이므로) 결과값은 같아도 구현하는 방식은 프로그래머마다 천차만별이다. 당장에 알고리즘 풀이사이트를 가봐도 알 수 있다. 정해진 문제에 대해서도 그렇게 많고많은 방법과 해결책을 제시하는데 딱히 정해지지 않은 답을 찾아가는 데에 있어서 프로그래머의 창의력만큼 중요한 요소..