728x90
뇌가 추구하는 것 1. 규칙성과 예측성 - 불확실성을 감소시킬 방법을 찾아라 - 당신과 나의 뇌는 일관성있는 편안함을 추구한다. 이것이 모든 상황을 예측하는 배경이 될 것이며 따라서 여타 상황의 불확실성을 감소시키게 될 것이다 2. 참신함과 용이함 - 우리의 뇌는 보상에 대한 기대가 존재하며 가령, 목표를 가질 땐 이에 대한 노력보다 매력적인 보상에 더 집중한다 - 두뇌 속에선 예측 가능한-그러한 편안함을 찾지만 반대로 새롭고 보람있으며 '쉬운 일'을 추구하는 경향이 있다 - 위와 같은 사항은 지속적인 행동/생산적으로 활동하려는 시도에 걸림돌이 된다 걸림돌을 제거하기 위한 방법 1. 목표에 대한 명확성 - "내일 일어나자마자 코딩할 거야" X - "내일 오전에 내 작업방에서 1시간 정도는 프로젝트의 데이..
니코씨와 함께하는 블록체인 개발 #1 package.json에 index.js 실행 명령어 설정 비효율적으로 프로젝트를 실행시켜보자 ... "scripts": { "build": "tsc", "start": "node build/index.js", }, ... 1. npm run build (ts한테 컴파일시키고) 2. npm run start (컴파일된 js파일 작동시키고.) 더 나은 방법으로 가자 // in terminal npm i ts-node // in package.json ... "dev" : "ts-node src/index.js", ... 원한다면 이 시점즈음에 nodemon도 설치하여 자동 커맨드 실행을 해주자 "dev": "nodemon --exec ts-node src/index.t..
니코씨와 함께하는 타입스크립트 기반 프로젝트 러닝 #1 프로젝트 빌딩 npm 명령어 실행 npm init -y //이후 package.json에서 javascript 설정 코드 삭제 npm install -d typescript // ts 라이브러리 설치 경로 및 파일 생성 src > index.ts #2 typescript 설정 config파일 생성 touch tsconfig.json //혹은 직접 만들기 해당파일을 통해 VSCode가 Typescript를 인식하게 됨, 이후 자동완성기능 제공 config파일 작성 // ts : Compiler { "inclue": [ // src의 모든 파일을 확인하도록 명시 "src" ], "compilerOptions" : { // Ts -> Js로 컴파일 시킬 ..
GitHub Copilot is generally available to all developers | The GitHub Blog We’re making GitHub Copilot, an AI pair programmer that suggests code in your editor, generally available to all developers for $10 USD/month or $100 USD/year. It will also be free to use for verified students and maintainers of popular open source proje github.blog 이 팝업 뭐에오 언제부턴가 Github에 들어가면 팝업을 띠링하고 거슬렸던 것, 알고보니 그게 (유투버..
니코의 타입스크립트 강의를 하나 들어보자. #1 세팅 2. 노드버전 확인 node -v // 18.0.0 임을 확인 1. Visual studio Code TypeScript도 VSC도 MS가 만들었으니 찰떡궁합으로 써보자. #2 TypeScript 사용해보기 The starting point for learning TypeScript Find TypeScript starter projects: from Angular to React or Node.js and CLIs. www.typescriptlang.org 작동방식 1. 개발자가 코드 작성 2. 타입스크립트가 코드 확인 3. JS를 통한 컴파일 시점 이전에 자바스크립트의 기존의 잠재적 오류가능성을 방지 => TS가 런타임에 작동되는 것이 아니다 예시..
개발자 필독서 중에서도 당연시 언급되는 클린코드. 1장부터 다시 보았다 #1 Intro 당신의(혹은 당신의 팀의) 시간과 비용과 노력을 위하여 "좋은 아키텍처가 비싸다는 생각이 든다면, 나쁜 아키텍처를 시도해봐라." 현재 가장 좋은 코드라고 판단이 된다는 것은 후에 변경될 가능성의 존재를 무시해도 괜찮다는 의미가 되진 못할 거다. 그렇다고 변경될 가능성을 지나치리 신경써 확장성을 가지고자 작성하면 그것도 좋지 않다 개발의 진척도가 조금만 지나도 더 이상 쓰지 않는 코드, 무의미한 파라미터의 처리가 난감해진다. 이 레거시 코드 처리의 난처함은 필연적이며, 그나마 가장 깔끔한 길을 찾기 위하여 모두를 위한 가이드라인이 이 책이라고 생각한다. 뼈대의 규칙은 바뀌지 않는다 작성자는 꽤나 오랫동안 다양한 개발경험..