코드 몽키의 허둥지둥 개발공부

Id UserId Name 1 ingnoh NULL 2 injuk NULL ... N someone NULL 요런 테이블을 Id UserId Name 1 ingnoh ingnoh 2 injuk injuk ... N someone someone 요렇게 업데이트 치고 싶으면 UPDATE [테이블_이름] SET Name = UserId Where [테이블_이름].Id>0; 이렇게

스토리지 클래스 확인은 aws s3 ls 명령어로 불가능하므로, aws s3api 명령어를 활용하자. aws s3api list-objects-v2 --bucket ingnoh-test-bucket --prefix ingnohFolder 내 경우에는 폴더 내에 있는 파일들을 검색해야해서 prefix 옵션을 사용하였다. 결과 { "Contents": [ { "Key": "ingnoh/", "LastModified": "수정한 날짜임", "ETag": "\"ETag 위치임\"", "Size": 0, "StorageClass": "STANDARD" }, { "Key": "ingnoh/it.png", "LastModified": "수정한 날짜임", "ETag": "\"ETag 위치임\"", "Size": 123..

AWS lambda 노드 런타임을 사용할 때, 공통 코드를 layer(계층)에 관리하고 있다면 다음과 같이 import하여 사용하게 된다. const myLibrary = require('/opt/myLibrary'); exports.handler = function(event, context) { myLibrary.greeting(); // hello! } 그러나 해당 코드를 로컬에서 테스트하는 경우, 계층에 포함된 라이브러리가 로컬 환경의 /opt 하위 경로에 존재하지 않으므로 모듈을 임포트할 수 없는 문제가 발생한다. jest를 사용하여 테스트하는 경우, jest.config.js에 다음과 같이 작성하여 문제를 쉽게 해결할 수 있다. module.exports = { moduleNameMapper:..

잘 사용하고 있던 H2 데이터베이스 경로 상의 mv.db를 지웠다든지 하는 문제로 해당 메시지가 노출될 수 있다. 요런 문제는 그냥 다음과 같은 순서로 진행하여 해결할 수 있다. 우선 켜져있는 h2를 모두 끈 후에 다시 켠다. jdbc:h2:~/경로/데이터베이스명 형태로 접속을 시도한다. 접속이 잘 되면 연결을 끊고, 다시 jdbc:h2:tcp://localhost/~/경로/데이터베이스명 형태로 접속한다. 예를 들어 ~/worskpace/study 경로에 test.mv.db를 실수로 지운 경우, 2.의 과정에서는 jdbc:/h2:~/workspace/study/test 형태로 접속해야한다.

DTO 계층 간 데이터 교환에 사용한다. 게터와 세터를 제공하므로, 가변적이다. VO 값 객체이며, 불변적이다.

참고 리눅스 1G 파일 만들기 [ dd 명령어 ] To create 1MB file (1024kb), enter: $ dd if=/dev/zero of=test.img bs=1024 count=0 seek=1024 You will get an empty files (also known as "sparse file") of arbitrary size using above syntax. To create.. woosa.tistory.com [~] dd if=/dev/zero of=./big_file.txt bs=1024k count=1024 [~] # 또는 아래의 명령어 사용 [~] # dd if=/dev/zero of=./big_file.txt bs=1 count=0 seek=1G [~] ls -lh bi..

업무 도중에 Node.js로 다음과 같은 기능을 작성할 일이 있었다. 수 많은 Promise를 생성하되, 각각의 Promise는 1:1로 대응되는 stream의 end 또는 error 이벤트에서 상태가 결정된다. Promise.all로 작업이 완료되는 것을 기다린다. 후속 작업을 처리한다. 그런데 await Promise.all(promises); 에서 대기하던 중 Node.js 애플리케이션이 아무런 로그 없이 code 0으로 정상 종료되는 상황이 발생하였다. (물론 코드 전역에 try - catch를 걸어도 어떠한 에러도 잡히지 않았다.) 해당 문제의 원인은 다음과 같으며, 핵심은 stream의 에러 또는 스펙이 아닌 Node.js 동작 방식에 있었다. Node.js는 애플리케이션을 실행할 경우, 이벤..

아래와 같은 코드가 있다고 하자. type User = { id: number; name: string; age: number; } // 프로미스를 반환한다. async function getUserAsync(id: number): Promise { const user: User = { id, name: 'ingnoh', age: 3, }; return new Promise((resolve => { setTimeout(() => { resolve(user); }, 2000); })); } (async function main() { console.log('main start!!!'); // 첫 번째로 출력된다. const user = await getUserAsync(1); console.log(user..