전체 글

· TIL
늦게자고 늦게 일어났다. 2주차 팀 프로젝트가 시작되었다. 개인 프로젝트였던 키오스크를 더욱 발전시키거나 호텔 예약 시스템을 만드는 선택적 과제이다. 키오스크를 완성하며 아쉬웠던점이 많았기 때문에 키오스크를 리팩토링 해보고 싶은 욕심도 있었지만 해당 과제는 나중에 내 손으로 직접 리팩토링 하도록 하고 빠른 발전을 위해 새로운 과제를 시도하는 쪽으로 의견을 내었다.이번에는 협업프로젝트인 만큼 플로우차트와 UML을 그리고 시작하기로 했다. 플로우차트 이전 개인과제와 비교해도 특별히 어려운 내용은 아니다. 오히려 협업 과제로 나온것 치고는 너무 별 내용이 없다는 느낌이었다. 클래스 다이어그램 개념을 오래 전에 배워본 기억은 있으나 가물가물 하여 구글반 내 생각 반 섞어 얼기설기 무언가를 완성해왔다. 어떻게 끄..
· TIL
뭘 했길래 시간이 이리 빠르지 정신 차려보니 밤인데package import 작은 의문이 들었다. 같은 이름의 클래스가 서로 다른 패키지에 존재할때 다른 클래스나 메인에서 두 패키지를 모두 import 한다면 해당 클래스들은 어떻게 불러 올 수 있는가? 애초애 그런 행위를 하면 안되나? 혹은 overload 시키듯 구분할 수 있는 여지를 두면 JVM이 알아서 처리를 하는가? overload VS override 해당 의문을 해결하기 위해 검색해보던 도중 내가 overload와 override의 구분을 모른다는것을 알게 되었다. overloading은 이름이 같은 메서드에 매개변수 차이를 주는것 public void print(int x) { System.out.println(x); } public voi..
· TMI
블로그 작성을 Velog로 시작한 만큼 마크다운 사용에 있어 Velog방식이 너무 익숙해져 있었다. 지금 작성하는 이 글도 사실 Velog로 작성하여 tistory로 옮긴것이다.Velog식 이미지 올리기 ![](https://velog.velcdn.com/images/q83x3x3/post/ee544422-8847-4924-80de-f8df4a68ca34/image.png) 이미지 보기 Velog 에서는 외부 사이트의 이미지를 복사하거나 내 컴퓨터에서 업로드를 하게 되면 velog 서버에 해당 이미지를 저장하여 내 블로그로 가져오는 듯 하다. tistory로 본진을 옮긴 현재 내가 velog를 이용해서 작성하는 글은 일단 비공개로 저장은 되지만 이미지가 위치한 곳이 velog의 서버라는 점에서 불안정함을..
· TMI
오버로딩에 관한 강의다. 강의를 집중하다보니 내 IDE환경과 다른 부분이 눈에 띄었다. 호출하고 있는 메서드 내에 집어넣는 매개변수가 해당 메서드에서 어떤 이름으로 작성되어있는지 보여주는 기능. 해당 기능을 활성화 하러 가보자. 저 기능은 Inlay Hints 라고 검색하면 나온다. 뉴비한테 매우 필요한 기능이라고 생각한다. window 상에서 설명한다. mac 도 비슷할거라 본다. 오른쪽에 있는 항목들 싸그리 체크해버리기로 했다.
· TIL
솔직히 말해 velog 너무 불편하다. Markdown 결과를 우측에 보여주는것 말고는 특별한 장점이랄게 없는 듯 하다. 그래서 티스토리로 블로그를 옮기게 되었다. 6일자 글에 toggle기능과 22일자 글에 이미지 크기 조정을 사용한 적 있는데 velog에선 미리보기에서는 적용되는걸로 보이나 실제 발행 후 글을 조회해보면 기능하지 않더라. 티스토리로 옮기니까 따로 손대지 않아도 바로 되는 것을 보고 옮기길 잘했다는 생각이 들었다. 글이 하나라도 적을때 옮겨야 일이 줄어든다. 심지어 티스토리는 꾸밀것도 꾸밀 방법도 무궁무진하더라 가벼운 복습 Car car1 = new car(); //호출자 public Car () { } // 선언, 생성자 이 이미지를 삽입하려던 시도가 나를 velog 에서 tistor..
· KPT
스파르타 내일배움캠프 Chapter 1 미니프로젝트를 마치며 6조 팀원들과 함께 KPT를 작성해 보고자 한다. "근데 KPT가 뭐지?" Keep, Problem, Try의 약자로 회고 내용을 세 가지 관점으로 분류하고 회고를 진행하는 회고 방법론 중 하나라고 한다... 는데 바로 시작해보자! KEEP - 좋았던 부분, 계속해서 유지되었으면 하는 부분 모르는 부분이 생길때 스스로 해결해보려 노력하고 문제가 있을 땐 주저 없이 질문하고 반대의 상황에서도 주저 없이 도와주기 각자 맡은 기능들을 완벽하게 구현하기 위해 모두 성실하게 임했다. 협업 경험을 위한 Git hub repository 생성과 기능별 branch 생성이 잘 이루어 졌다. PROBLEM - 잘되지 않았던 부분, 문제라고 생각하는 부분 프로젝..
정유감
정말유감이야