Programmer's Digest

*목적  Race Condition방지, data corruption 방지 *Race condition  특정 접근 순서에 따라서 실행결과가 달라지는 경우 *silient corruption  data corruption을 운이좋게 피해간 경우 *Non-preemptive kernel  no race condition. 평균 대기시간 증가 *Critical Section  process들이 공유변수들을 수정할수 있는 코드의 영역 *Critical Section Problem  critical section에는 오직 한 process만 실행되도록 하는 문제 Requirement :  1) mutual exclusion : critical section에는 오직 한 process만이 실행될수 있다. 2) progress : 어떤 process가 임계영역에 들어가려 할때, 무기한 연기가 되어서는 안된다. 3) Bounded Waiting : 어떤 process가 임계영역에 들어가기 위해 대기하는 시간은 유한해야한다. 구현방법: Static Alternation  progress requirement를 만족하지 않음. 한 프로세스가 실행되고나서 다른 process가 실행되기 전까지는 무기한 연기됨. Peterson’s algorithm  progress, Bounded waiting 모두 만족 Special H/W instruction  atomic operation을 코드로 구현하는 것이 아니라, 하나의 instruction으로 구현. Mutex Locks   critical section 문제를 해결하기 위한 SW tool 문제점 : busy waiting이 발생함 bush waiting이란 instruction을 수행하면서 기다림(CPU cycle 낭비) 해결책 :  1) process를 semaphore의 waiting queue에 넣고 wait state...

모든 Proceess가 다른 process에 의해 야기될수 있는 event를 기다리고 있을때 발생 *필수조건 1) Mutual Exclusion : 최소 하나의 자원이 비공유 모드로 지원되어야 함 2) hold and wait : process는 최소하나의 자원을 점유한 상태로, 다른 process에 의해 점유된 자원을 얻기 위해 대기해야함 3) No preemption : 자원들은 선점이 될 수 없고, 자발적으로만 방출될수 있다. 4) circular wait : waiting process들이 순환적 대기를 해야한다. * Solution 1) system이 deadlock state에 들어가지 않도록 하는 protocol이 사용(deadlock prevention, deadlock avoidance) 2) system이 deadlock에 들어가도록 허용하되, detect해서 recover하도록 하는 방법 3) 어차피 자주 발생하지 않으므로 무시하는 방법(most popular) deadlock prevention,avoidance 방법은 비용이 너무 크므로 발생하면 재부팅 *Deadlock Prevention : deeadlock 발생 4가지 조건중 하나라도 안되도록 하는 방법 1) mutual exclusion : resource를 sharable하게 만듬 2) hold and wait : 실행전에 필요한 resource들을 모두 요청하게 한다. 3) No preemption : process가 자원들을 점유하다가 즉시 할당할수 없는 자원을 요청하면 현재 점유되고 있는 자원들이 released 4) circular wait : 모든 자원 타입들에 전체적인 순서를 부여하여 각 process가 열거된 순서대로 자원을 요청하도록 요구. *Deadlock Avoidance : 자원이 어떻게 요청될지에 대한 추가 정보를 요구, 프로세스의 요청과 방출에 대한 완전한 순서를 파악함으로써 교착상태를 피하기 위해서 process의 대기여부 결정 safe state : 시...

다중 프로그래밍 실현을 위해 메모리에 많은 process들을 동시에 유지 *Address Binding Time compile time binding : 만일 process가 memory내에 들어갈 위치를 컴파일 시간에 미리 알수 있다면 컴파일러는 절대코드를 생성가능 load time binding : 이진코드를 재배치 가능 코드로 만듬 execution time binding : process가 실행하는 중간에 memory 내의 한 segment에서 다른 segment로 옮겨질수 있다면 바인딩이 실행시간까지 허용되었다고 함 *Logical vs Physical Address logical address : cpu가 생성하는 주소 physical address: 메모리가 취급하는 주소 compile-time binding과 load-time binding에서는 logical addr = physical addr execution-time binding은 logical addr != physical addr *MMU(Memory Management Unit)  virtual(logical) addr -> physical addr *Dynamic Loading  각 routine이 재배치 가능 상태로 디스크에 대기하다가, 필요할때 적재. 사용되지 않는 routine은 적재 되지 않는다. *Dynamic Llinking linking이 실행시간 까지 미루어짐. 라이브러리를 부르는 곳마다 stub이 생겨서 메모리를 찾는방법과 없을경우 라이브러리 적재방법을 알려준다. *Swapping  일시적으로 process를 main memory에서 disk로 이동시켰다가 다시 memory로  이동시키는것. 목적 : process들을 실행하는데 필요한 공간이 physical memory공간을 초과할때 사용 roll in, roll out : 더 높은 우선순위의 process가 swap-in 되고 더 낮은 우선순위의 procss가 swap-ou...

Summary application이 Facebook, Github 같은 HTTP 서비스에 대한 사용자 계정에 접근을 할수 있도록하는 인증 framework. 사용자 인증을 사용자 계정을 호스팅하고 있는 서비스에 맡기고 third-party application에게 사용자 계정에 대한 정보에 접근 할수 있도록 권한을 부여 web app, desktop app, mobile app에게 authorization flow를 제공해줌 참고 Grant Type : Authorization Code 유저에게 인가요청 유저가 인가허가 Auth Server는 Client에게 authorization code 부여 Client는 access token을 Auth Server에 요청 Auth Server는 Client에게 token 전달 Grant Type : Implicit 위 과정 3번과정을 다음과 같이 변경 Auth Server에서 Access Token과 함께 redirection URI 전달 redirection URI로 이동하여 token 획득 client에서 token extract 스크립트를 브라우저로 전달 브라우저에서 Client로 token 전달 Grant Type : Resource Owner Password Credentials username과 password를 app에서 username과 password를 입력받아서 인가서버에 보내서 토큰 획득 다른 방식이 안될때만 사용권장, app이 user에 의해 신뢰가 될때만 사용(e.g. 앱 자체가 Auth service에 의해 소유될때) Grant Type : Client Credentials app 자체의 credentials(client id, client secret) 를 Auth Server에 보내서 Access Token을 획득 app이 redirect URI에 대한 정보를 업데이트 하고 싶다거나, api를 통해서 app 자체의 데이터를 받아고고 싶을 때 사용이 가능하다.

1. 프로젝트 루트폴더에 .travis.yml 파일을 생성한다. 2. .travis.yml 파일을 다음과 같이 작성한다. 로그인 echo "$DOCKER_PASS" | docker login -u "$DOCKER_USER" --password-stdin   현재 경로에 있는 DOCKERFILE build & push docker build --tag kimwithglasses/safe-place-db:0.0.1 . && docker push kimwithglasses/safe-place-db 경로 이동하여 gradle project build & push cd SafePlaceAPI && ./gradlew bootJar && docker build --tag kimwithglasses/safe-place-api:0.0.1 .  && docker push kimwithglasses/safe-place-api 3. 위의 경우는 password가 노출되어있기 때문에 암호화를 진행한다. .travis.yml이 있는 경로로 이동 DOCKER_PASS 변수 암호화 travis encrypt DOCKER_PASS=" password " --add --com 4. 최종 완성된 .travis.yml 파일의 모습은 다음과같다.

 내가 정의한 커스텀 MySql 이미지와 Spring Boot 서버를 docker-compose를 실행하는데 Connection Link Failure에러가 자꾸 났다. 원인은 의외의 곳에 있었다.  커스텀 MySql 이미지가 다 실행되기도 전에 Spring Boot 서버가 실행되었기 때문이다. 사실 depends_on: - safe-place-db   구문이 실행되면 실행의 순서가 보장되리라고 생각했는데, 실제로는 safe-place-db가 up 될때까지 보장해주는 것이었다. up이 된 순간 부터는 두가지 컨테이너가 동시에 실행되는 것이다. 따라서 docker-compose.yml에    restart: on-failure:10  을 추가하여 수정했다. 추가한 구문은 실패할때 10번까지 재실행을 허용하라는 의미이다. 보통 safe-place-db에서 sql 스크립트에대한 실행이 없을때는 depends on 구문으로 충돌이 나는 경우는 없지만 이번 경우는 달랐다. 완성된 docker-compose.yml 은 다음과 같다.

 Spring Boot 2.x 버전의 앱을 JAR로 패키징하는데 꽤나 많은 시간을 소비하였는데, 2.x 이전버전의 경우를 시도하다 보니 시행착오를 많이했다. 스택오버플로우 에서 찾아보면서 꼼꼼히 읽는 훈련을 계속 해야겠다. 해답은 간단했다. https://stackoverflow.com/a/52404325/8276700   Spring Boot 2.x 버전에서 bootJar과 bootWar 이라는 gradle task가 app을 패키징하는 역할을 한다. bootJar task는 실행가능한 jar file을 만드는데 책임을 지고 이는 java plugin이 적용이 될때 자동으로 생성된다고 한다. 따라서 build.gradle 파일에 다음 라인을 추가해야한다. plugins {     id 'java'     id 'org.springframework.boot' version '2.3.4.RELEASE' } 그리고 루트 디렉토리에서  ./gradlew bootJar  을 입력하면 build/libs 폴더에 jar 파일이 생성된다. 유사하게 bootWar는 executable war file을 생성하고 war plugin이 적용될때 동작한다. $./gradlew bootWar  을 입력하여 실행할수 있다.

docker-compose up : Builds, (re)creates, starts, and attaches to containers for a service -d, --detach : Detached Mode, Run container in background. docker rmi <your-image-id> : delete image with id docker images : list docker images docker build --tag <tag-name> .  : build docker image in current directory with tag name docker tag bb38976d03cf yourhubusername/verse_gapminder:firsttry : tag already created image  docker push yourhubusername/verse_gapminder : push image to docker hub repo

Spring Maven Project에서 갑자기 api endpoint에 404 error가 뜰때  Git의  커밋로그를 분석하여 차이가 발생한 부분을 찾아보았다. 프로젝트의 .classfile에 다음 라인이 누락삭제되어서 발생하였다. <attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/> 이 라인이 어쩌다가 누락이 된것인지는 확실치 않지만 잘되던 프로젝트가 갑자기 안될때는 커밋로그를 분석하는게 좋은것같다. 또한 Spring Boot를 쓰면 실수할만한 환경설정들이 줄어든다는것도 느낀다. 이클립스에서Dynamic Web Module to x.x” Error in Eclipse 먼저 org.eclipse.wst.common.project.facet.core.xml 파일에 <installed facet="jst.web" version="y.y"/> 부분의 y.y를 x.x로 수정한다. 그리고 x.x 버전에 맞는  tomcat버전을 세팅한다. servlet 버전에 맞는 tomcat 버전은 다음에서 확인한다.( LINK )

 1. 인턴십(또는 신입으로서 일)을 시작하기 전에 팀멤버들을 만나서 소통하라. 자신을 소개하라. 2. 멍청한 질문이라는건 존재하지 않는다, 주저하지 말고 질문하되 그 질문에 답을 해줄수 있는 적절한 사람에게 하라. 3. 질문하기전에 문제에대해서 충분히 고민해보고 해결하려고 노력하라. 4. 스스로 모든 문제를 해결하려고 하지마라. 5. 반드시 코드를 제출하기전에 테스트를 충분히 작성하라. (테스트를 작성하지 않은 코드는 쓸모없다.) 6. 데드라인을 넘겼다고 해서 세상종말인 것은 아니다. 세상종말은 커뮤니케이션을 하지 않을때이다. 항상 내가 하는 일을 설명할 준비가 되어있고, 현재 겪고있는 이슈들을 커뮤니케이션하라. 다른 사람의 생각을 짐작하지 말고 커뮤니케이션 하라.  7. 장기적으로 성장하고 싶으면 , 시니어들의 설명을 귀담아듣고 메모하라.  출처 : Top 6 Tips to survive as a Junior Developer or Intern (from an Amazon SDE Intern)

mysql 8.x 버전 이후로 발생 jdbc url에 allowPublicKeyRetrieval=true&useSSL=false 필요 예시: jdbc:mysql://localhost:3306/dev-product?useUnicode=true&characterEncoding=utf8&allowPublicKeyRetrieval=true&useSSL=false 출처  

user 조회: select host, user, authentication_string from user; drop user: drop user springstudent@'%' 외부에서 접근 가능하도록 유저 생성: create user springstudent@'%' identified by 'springstudent'; local에서만 접근 가능하도록 유저 생성: create user springstudent@localhost identified by 'springstudent'; spring student에게 moBack 데이터베이스에 대한 모든 권한 부여: grant all privileges on moBack to 'springstudent';

아래와 같이 선언해서는 위의 에러가 계속 발생한다. grant all privileges on moBack to 'springstudent'; 다음과 같이 선언하면 에러가 해결된다. grant all privileges on moBack.* to 'springstudent'@'%';

 마이그레이션(migration)이란 한 종류의 데이터베이스에서 다른 종류의 데이터베이스로 데이터를 옮기는 것을 의미한다

위는 빠른 버전이고 아래는 느린버전이다. 최대 8자리수의 합을 구할때 빠른버전의 경우 최대 8번의 반복문을 돈다. 느린버전의 경우 Math.pow 내부에서 지수부분만큼 반복문을 돌게되므로 1+2+3+4+...+8 = 36번 돌게 된다. 위 문제를 백트레킹 방식으로 풀이할경우, 빠른버전의 경우 시간 복잡도는 10! * (8*10)*8이 되고 느린버전의 경우 시간 복잡도는 10! * (8*10)*36이 된다. 시간 제한이 2초 이기 때문에 시간이 아슬아슬하게 통과된다. 이 경우 무리하게 백트레킹으로 풀이하려고 하기 보다는 다른 풀이를 생각하는것이 안전하다고 생각한다.

SELECT * FROM table1, table2 WHERE table1.id = table2.id; SELECT * FROM table1 INNER JOIN table2 ON table1.id = table2.id; 위의 두 쿼리는 결과와 내부적인 동작 또한 서로 같다. 하지만 두번째방법이 더 가독성이 좋다.

   위 문제를 풀때, visited에 해쉬값을 다음과 같이 적용하여 계속 오답이 났다. String key = String.format("%s%s", front.row, front.col);  위와 같이 visited를 갱신하면 셀을 유일하게 구분할수 없는 경우가 생긴다. 예를들면, (1,11) 과 (11,1)의 경우에 둘다 key값이 "111" 이 되기 때문이다. 따라서 둘사이에 구분자를 추가하여 1 | 11 , 11 | 1이 서로 다른 key를 갖도록 수정하여야한다. 그리고 2차원 배열을 선언하는것이 괜찮다면 이차원 boolean 배열로 visited를 선언하는 것도 방법이다.

Topic 특정한 data stream database의 테이블과 비슷한 개념 원하는 만큼 생성가능 이름으로 구분됨(identified by name) Topic들은 partition으로 나누어짐 각각의 파티션은 정렬되어있음 partition 내에 있는 메시지들은 offset이라 불리는  incremental한 아이디를 가진다. ( partition 0, partition 1, ... ) Offset은 오직 specific partition에서 의미가 있음. partition 내에서만 순서가 존재함(partition 간에는 순서가 보장되지 않음) Data가 제한된시간 (기본 1주)내에 존재함 데이터가 partition에 써지면, 바꿀수없음(immutability) Brokers Kafka cluster는 broker(servers)들로 구성되어있다. broker들은 id로 구분 각각의 브로커는 특정 topic partition들을 가지고 있음 아무 브로커에게 연결되면 (called a bootstrap broker), 전체 클러스터에 연결됨 Topic-A는 3개의 파티션, Topic-B는 2개의 파티션을 가지고 있음. Topic replication factor broker가 down되어도 다른 broker가 계속 데이터를 서빙할수있음. 위 경우는 replication factor가 2인경우이다. 특정 한 partition에는 하나의 broker만이 leader가 될수 있다. 그 leader만 data를 주고 받을 수 있다. 다른 broker들은 leader의 데이터를 동기화한다. 이때 다른 broker들을 ISR(In-Sync-Replica)라고 부른다. Producers ack=0: Producer는 ack를 기다리지 않는다.(data 손실가능) ack=1: Producer는 leader에대한 ack를 기다린다.(limited 데이터 손실) ack=all : Leader + replicas의 ack를 기다린다(data 손실 없음) Message Ke...

 Spring에서 default로 주어져있는 index.jsp를 사용할때  java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered?  에러를 만날 수 있다. 이때는 index.jsp 파일을 view폴더에 넣고 다음과 같이 컨트롤러를 정의하여 해결할수 있다.

GROUP BY  H.HACKER_ID, H.NAME 대신 H.HACERK_ID 만 사용할시 다음의 에러를 볼수 있다. ERROR 1055 (42000) at line 1: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'run_lf9qo4ybaab.h.name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by SELECT에서 사용된 칼럼중 GROUP BY 절에있는 칼럼에 함수적 종속성을 가지고 있지 않은 칼럼이 있다는 뜻이다. 여기서 함수적 종속성이란? 어떤 릴레이션 R에서, X와 Y를 각각 R의 애트리뷰트 집합의 부분 집합이라 하자. 애트리뷰트 X의 값 각각에 대해 시간에 관계없이 항상 애트리뷰트 Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 함수 종속이라 하고, X → Y라고 표기한다. 즉, HACKER_ID는 HACKER_NAME에 함수적 종속성이 없다.