오늘 공부할 내용

• java 보강 수업 복습
• TiL 정리 및 블로그 업데이트

오늘 공부한 것 & 배운 내용

• 등원시간

  • 개발자 취업 관련 유튜브
    • 개발자 도서 추천
      • C언어와 자료구조가 개발자의 가장 기초 학문이라고 하면서 추천해주셨는데 C언어는 언젠가는 배워야될수도있겠다 이런생각이 들고 자료구조는 입문서라도 찾아서 미리 배워놓는게 좋을 것 같다
      • 그 외에도 개발관련 읽을 책들을 추천해주셨는데 기술관련이 아니더도 꾸준히 관련 분야에 대해 읽다 보면 개발자가 무엇인지 개발이무엇인지 배워갈 수 있을 것 같다
        • 공부시간에 10분정도 독서하는 것을 개발 주제로된 것으로 한정해서 하루 2~30분정도로 라도 꼭 책을 읽는 습관을 들여야 겠다
    • T자 개발 방법론
      • 기초를 충분히 쌓고 자신의 전문분야에 깊이를 더하도록 공부를 해나가면서 확장되는 기술은 얕게얕게 가져가는게 T자 공부법이라고 한다
      • 무엇보다 중요한건 프로그래밍 전반에 관한 기초와 그것을 활용한 전문분야를 깊게 파면서 관련기술들에 관심을 가지는게 중요한 것 같다
        • 지금 java와 spring이라는 확실한 목표가 있는건 나에게 좋지만 전반적인 기초가 너무 부족하다. 독서시간 확보와 독서 주제를 한정해서 키워나가야 될 것 같다
    • 중급 개발자가 되는 걸 목표로하라
      • 초급 개발자에서 중급 개발자로 넘어가기까지가 어려운 과정이어서 10 ~15 %정도 밖에 넘어가질 못하고 기간은 보통은 5~7년 정도가 걸린다고 한다.
      • 이 기간동안 정말 개발에 집중해서 프레임워크로 회사가 원하는대로 그대로 보여줄 수 있는 중급 개발자라고 한다
        • 이 부분은 T 개발 방법과 일맥 상통하는 점이 보여서 내가 배우는것에 집중하자는 생각이 들었다
        • 취업 이후에 목표에 대해서 생각해보고 싶었는데 신입개발자가 된 이후에 목표가 생긴 것 같다 ! -> 굿
    • 개발자로 성장하는 방법
      • 페이스북으로 연동하는 API가 공식 문서가 영어라 어려워서 자꾸피했더니 발전을 못하고 있었는데 이직한 회사에서 전담한 분야가 해당분야였다는 내용
      • 결국은 영어든 어떤 분야든 필요한것은 해야되는데 그것을 피하지않고 해나가면 결국 언젠가는 자연스럽게 해나가고 주변에 인정도 받아서 성장할수 있다는 내용이었다
        • 영어 자료읽기가 나에게는 지금 적용될 수 있는 부분인 것 같다. 구글에서 한글자료를 안뜨게하는 방법을 사용해서 해보자
          • 이렇게 안해도 영어자료만 우선적으로 클릭하니까 자연스레 영어자료가 검색결과가 상단에 배치됬다

• 준비시간

  • 채용공고

    • Scalable : 사용자 수가 급증해도 애플리케이션이 멈추거나 성능이 크게 떨어지는 일이 없다

    • 담담업무중 DB설계도 포함된 곳이 있길래 검색해 봤더니 보통은 PL이 하지만 담담이 없는 경우 백엔드가 한다고 한다

      • 이 부분은 java강사님께 한번더 여쭤보면 더 도움이 될것 같다

      • Pl은 Project Leader를 뜻하는 것 같다

• 자율학습 시간

  • 수업 자료 & github repo 정리

    • 이전 repo가 TIL로 너무 많은 내용들이 묶여있어서 수업자료 별 repo를 만들기 위해 폴더와 repo를 정리하였다

    • 과정

      • TIL 폴더에 Java 폴더에 있는 수업자료들을 JBS-java옮김
        • 수업 초반 프로젝트와 package를 잘 구별 못해서 중구난방으로 구성되어 있던 soruce트리를 정리하여 하나의 프로젝트안에 패키지들로 구분하여 자료를 정리하였다
          • 처음엔 어떻게 정리할지도 몰랐는데 이제는 깔끔하게 정리할수 있게 된것이 스스로 발전됬다고 느꼈다
        • 새로만든 프로젝트폴더를 새로만든 repo에 연결하기
          • repo를 처음 만들때 아예 빈 repo로 만들어야 되는데 readme파일을 추가하고 싶어서 체크하면서 만들었더니 만드는 순간 main branch가 생겨났다. 그래서 master로 push하는 순간 새로운 branch가 생겨서 merge를 해야할 필요성이 생겼다
          • 변경점을 비교하는 메뉴에 들어가봤더니 변경점이 없다면서 pull request를 작성할 수가 없어서 merger할 방법을 찾지 못했다
            • 이 부분은 한번 따로 시도해봐보면 좋을 공부가 될 것 같다
          • 그래서 여러번 다시시도해보다가 readme file을 빼고 만들어 봤더니 비어있는 repo가 생겨났고 거기에다가 remote을 add했더니 자연스럽게 default branch가 master가 되어서 문제를 해결 할 수 있었다
            • 이렇게 했을 때 문제는 push할 때 항상 origin master를 붙여줘야 되서 불편 했다
              • 어떻게 해결할지 찾아보면 도움될 것 같다
        • 그렇게 해서 전체 자료를 push해고 repo를 확인했더니 src폴더에 화살표가 표시되어 있고 접근을 할 수 가 없었다
          • 검색을 통해 알아본 결과 src폴더안에 .git 폴더가 생성되어 있어서 그랬다...
          • .git을 지우고 다시 커밋해보려고 했는데 그래도 인식하지 못해서 src폴더를 지웠다가 다시 복구하니 git에서 인식을 하였고 다시 commit&push를 통해 문제를 해결하였다
        • 이런 과정 거쳐서 local폴더가 잘작동하는지 보기 위해서 Intellij에서 열어봤는데 projcet설정이 풀렸는데 src폴더와 out 폴더가 설정이 안되어 있었다
          • 그래서 project설정에 들어가서 src폴더 설정하고 out폴더 설정했는데 out폴더를 읽지를 못해서 실행을 하지 못하는 상황이었다
          • 다시 설정에 들어가서 out폴더 경로를 수동으로 설정해주고 IDEA를 껐다 켰더니 설정이 적용되어서 정상 작동하게 되었다
            • 예전에 같은 문제를 겪었을 때는 해결 못한 문제인데 이번엔 스무스하게 해결해서 기분이 좋았다
        • 이런 번거로운 과정 거치지 않고 repo를 먼저만들고 clone하는게 가장 편안한 방법이라서 clone한 폴더를 project폴더로 만들수 없는지 실습해보았다
          • 새로운 repo를 만들어 clone한 뒤 IDAE에서 해당폴더를 프로젝트 폴더로 설정했더니 자연스럽게 project폴더가 되어서 다시 커밋푸쉬 해보아도 잘 사용되는 것을 확인 했다
        • 마지막으로 처음상황(main 이 있고 push를 하면 master브랜치로 푸쉬되서 pullrequest가 안되는 상황)을 해결해 보기 위해 이것저것 더 시도해봤지만 pullrequest를 받는 부분까지는 성공했으나 깔끔하게 하나로 merge하는 방법은 찾지 못했다
          • 이부분은 조금더 git에 대해서 공부해보고 다시 도전해봐야겠다

    • 배운점

      • 이런 문제가 생기고 해결해 가는 과정에서 학습효과가 큰 것 같다. 문제 발견했을 때 스스로 해결해나가는 경험들을 늘려 나가 보자

      • 자료찾는 과정중에 생활코딩에 프로젝트 관리 페이지를 찾았고 이것 통해서 git공부를 진행해봐야겠다

      • https://opentutorials.org/course/3837

• Java 보강 day2

  • 수업 요약 : 멀티스레드 추가 설명과 예제, 스레드풀 개념과 사용 방법에 관한 수업이었다

  • 내용 정리

    • 멀티스레드

      • 세마포
        • 세마포(Semaphore)는 동기화를 하는 또다른 방법이다.
          • 세마포는 가상의 Permit을 만들어 생성되고 외부의 스레드는 Permit을 요청해 확보(acquire)하거나 이전에 확보한 Permit을 반납(release)할 수 있다
            • 세마포 객체를 만들 때 argument에 permit의 갯수를 입력할 수 있다.(permit이 여러개 일 수 있다)
            • 해당 세마포 객체가 permit이 0개 일지라도 release()를 하면 permit이 하나 늘어난다(창조경제 인가)
          • 스레드가 aquire를 시도하는 방식은 다양하다
            • acuire(): permit을 acuire할 때까지 기다린다. interrupt로 방해할 수 있다
            • tryAcuire(): aquire을 시도하고 blocking하지 않고 결과에 따라 boolean을 반환한다
            • tryAcuire(timeout,TimeUnit): timeout만큼 기다리는데 단위가 TimeUnit이다. 결과에 따라 boolean을 반환한다
            • acquireUninterrupibly: acquire할 때까지 기다리지만 interrupt할 수 없다.
          • 참고자료: https://aroundck.tistory.com/5873
        • 세마포를 활용해 '식사하는 철학자 라는 문제를 풀는 법을 배웠다'
          • 문제: https://namu.wiki/w/%EC%8B%9D%EC%82%AC%ED%95%98%EB%8A%94%20%EC%B2%A0%ED%95%99%EC%9E%90%20%EB%AC%B8%EC%A0%9C
          • 철학자들 스레드이고 집어야할 포크를 세마포로 보고 스레드들이 left right 포크에 permit을 모두획득했을 때 식사를 하도록 구현을 하는 방식이 었다.
            • 나중에 혼자 풀어보는 것을 당부하셨으니 꼭 풀어봐야 겠다
      • JFC와 Sychronized
        • JFC에 일부 구현체는 Sychronized 키워드를 사용하여 구현되어 있는데 List에 Vector가 그대표적인 예이다
          • ArrayLIst같이 동기화 되지 않은 구현체를 동기화해서 사용하고 싶다면 Colletions.synchronizedList를 사용하여 동기화된 LIst로 변환하여 사용할 수 있다
            • 자료를 더 찾아보니 완전히 동기화 문제가 문제가 해결되는 것은 아니고 따로 동기화를 해주어야 한다고 한다
            • 참고자료 :https://okky.kr/article/279692

    • 스레드풀

      • 스레드는 할당된 작업을 마치면 종료되기 때문에 작업이 있을 때마다 생성해서 사용해야 한다. 하지만 스레드를 계속 생성할경우 생성과 종료시에 생기는 오버헤드 때문에 메모리에 부담을 준다
        • 스레드 풀은 미리 스레드를 생성해서 풀에 대기시켜 놓은 다음 작업이 요청될 때 해당 스레드를 사용하여 스레드에 오버헤드를 줄여 최적화하는 방식이다.
        • 스데드풀에 스레드는 작업을 마치더라도 종료되지 않으며 다음 작업을 실행하게 된다
        • 작업들이 몰릴 경우 스레드가 모두 사용되고 있을 경우가 있기 때문에 작업들은 queue에 담겨서 스레드에게 분배된다.
      • 스레드풀의 생성은 java.util.concurrent.Executors에 factory 메서드로 생성할 수 있다.
        • newFixedThreadPool 고정된 스레드풀을 간편히 생성할 때 사용할 수 있으며 생성할 때 스레드 갯수를 입력받는다.
        • newCachedThreadpool은 확장 가능한 스레드 풀로써 작업이 있을 때 스레드를 생성하고 스레드의 대기상태가 길어지면 스레드를 종료시켜서 최적화를 시키는 기능이 있다.
        • new ThreadPoolExecutor를 통해 여러가지 설정을 직접해서 생성할 수도 있는데 이때 코어 스레드 개수, 최대 스레드 개수, 대기시간(지나면 종료), 대기시간 단위, queue 객체 까지 입력받는다.
        • 참고자료: https://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
      • 예제에 사용된 Interface 정리
        • Interface Callable
          • Runnable과 비슷한 인터페이스로 스레드에 사용되는 인터페이스지만 return값이 있고 check exception을 throws할 수 있다는 점이 다르다
            • 아직은 예외를 thows할 수 있는게 어떤 의미를 가지는지는 잘모르겠다..
          • https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Callable.html
        • Interface Future
          • Future는 동기화된 결과가 완료되서 전달될 때까지 blocking 하여 값을 변수에 담는다
            • 스레드 풀에 실행 결과가 future 변수에 담기게 된다
          • 결과 값은 get()메서드를 사용해서 출력할 수 있고 작업이 완료될 때까지 blocking 되기 때문에 timout을 설정하거나 Interrupte할 수 있다.
          • cancel을 통해 작업을 취소할 수 있지만 작업이 완료되거나 이미 취소된 작업은 취소할 수 없다
            • 취소한 시점에 작업이 시작되지 않았다면 정상적으로 취소되고 작업은 시작되지 않는다.
            • 취소한 시점에 작업이 이미 시작되었다면 arguments에 입력하는 myInterruptIfRunning을 통해 해당 Thread에 Interrupt를 걸지 여부를 결졍할 수 있다.
          • https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
      • execute() 메소드와 submit 메소드의 차이
        • execute():Runnable 객체를 실행하는 메서드, 비동기적으로실행한다(?)
        • submit(): Runnable, Callable 객체를 모두 실행시킬 수 있으며 Future객체를 return한다.
          • Runnable의 Future객체는 작업이 완료됬는지 확인하는데 사용될 수 있다
        • 참고자료
          • http://tutorials.jenkov.com/java-util-concurrent/executorservice.html
          • https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/Executor.html
          • https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/ExecutorService.html

    • 백엔드 개발자는 멀티스레드를 사용한다면 배치작 업에서 스레드풀을 사용하는 경우가 많다고 하셨기 때문에 기억해두었다가 나중에 활용하면 좋을 것 같다

공부하면서 느낀점

• 잠깐 쉬는시간에 okky 글을 읽었는데 어떤 선배 개발자 분이 개발자의 기본기 중 API문서 읽는 능력과 습관, 오류 트레이스를 읽는 능력과 습관 이라고 정리해 주셨다..

  • 기본기가 부족할수 밖에 없는 나로서는 이런 충고가 고마울 뿐이다.
  • https://okky.kr/article/674111

• 위의 얘기와 이어지는 생각이지만 오늘 git repo 문제 해결하면서도 그렇지만 점점 물어보는 것보다는 스스로 해결하는 방식에 익숙해지려고 노력중이다.

  • 물어봐서 해결하는 것은 쉬운 해결책이지만 능력 향상에는 도움이 안된다.
  • 더 나아가서 해결하는 방식도 단순 검색을 통한 단편적인 해결책이 아닌 공식 API문서를 통한 원리를 이해한 뒤에 해결하는 방식으로 나아가면 더 발전을 이룰 수 있을 것 같다
    • 위 방식의 가장 큰 단점은시간이 오래걸린 다는 것인데 어떻게 탐색하고 공부하는 시간을 단축시킬 수 있을까 고민하면서 접근하면 더 실용적인 방안이 나올 것 같다

• 열심히 검색해서 자료찾으면서 하는 것은 좋은데 생각 없이 하다보면 단어 하나찾으려다 msstore가서 영어단어장 다운받고 있다

  • 공부 집중력 위해 이런 부분들 어떻게 관리할까 고민해봐야 될 것 같다

• 요즘 공부할 때 참고자료를 많이 읽고 있고 참고자료도 남겨두어서 나중에 또 궁금할 때 자세히 찾아보도록하고 있는건 잘하고 있는 것 같다

  • 참고 자료남기다보니 자료에 신뢰성에 대해서 생각하게 된다. 기존엔 잘정리된 개인 블로그에서 자료를 많이 얻었지만 그래도 더 신뢰있는 자료는 공식 API문서 일테니 그쪽위주로 참고하는게 더 좋아보인다.

  • 이건 위에 선배개발자의 권고사항과 일맥상통하는 방향이니 좋은 방향이라고 생각한다

내일 공부할 내용

• Java 복습 - 멀티스레드 못한것 보충
• Java 복습 - 정규표현식, unitTest
• DB 복습
• TiL 정리 및 블로그 업데이트