작업을 할때 이것저것 많이 켜두긴 하지만, 그래도 특별히 빌드 돌릴때 아니면 팬이 미쳐 날뛰지 않는데, 오늘은 유난히 계속해서 맥이 이륙하려 날뛰었다. 해결후 캡쳐한거라 보이지 않지만, 문제의 Google Chrome Helper (Renderer)가 CPU를 미친듯이 먹고있었다. Chrome Menu → Window → Task Manager 로 진입해 확인해보니, 보통 일부 크롬 플러그인이 리소스를 잡아먹기도 한다는데, 난 크롬 탭중에 특정 Grafana 페이지가 무슨 비트코인 채굴마냥 리소스를 다 먹고있었다. (그래프가 좀 많긴 하더만은...) 종료시켜주니 이제야 맥이 좀 쉰다,, 고생시켜서 미안 😢
배경 아직 내 앞가림도 제대로 못하는 병아리 신입 개발자이지만, 고등학교 3년동안 희망직업이 교사일 만큼 나는 지식 전파와 학습법 공유 등에 꽤나 재미를 느낀다 나도 출발이 비전공자라서 주변에 인맥도 없고 정보의 가뭄 속에서 오래 고생했던 경험이 있기에, 이런 부분들에 더 집착하는 경향이 있는것 같기도 하다 개발에 어떤 분야들이 있는지, 각각은 어떤 특징과 장단점을 갖는지, 어떤 공부를 어떻게 해야하는지 등 열심히 인터넷 서칭을 하지만 유용한 정보를 얻긴 힘들고 (주로 나오는건 학원 광고들뿐..), 인강을 단순무식하게 외우는 등 비효율적으로 학습을 삽질했던 때를 기억하면, 지금도 속 쓰리곤 한다 지금도 가끔가다 Collection 프레임워크 메서드 종류를 종이에 써가며 학습하시는 분을 보면, 마음 한켠이..
JPA의 사실과 오해 (사실은 JPQL과 Fetch Join의 오해) 20.05.25 JPA 스터디 하며 깨닫게 된 오해 JPA를 꽤나 오래 써왔는데(그래봤자 1년이긴 하지만), 이번에 스터디를 하며 크게 잘못 알고 있던 개념 몇가지를 정정하고, 스스로 부끄럽기도 하고 나름의 컬쳐쇼크를 받았다. 1. N+1은 연관 엔티티가 Collection인지가 중요한게 아니다. ( 주의 - JPQL 기준, SQL X ) 사실 왜 (당시 스터디하던) 우리 모두가 N+1 문제를 연관 엔티티의 컬렉션 여부와 관련지어 생각해왔던 건지 모르겠다. 대부분의 교재나 링크들에서 Member -* Orders 와 같은 일대다의 관계를 예시로 들며 설명하기 때문일까. 나는 이제까지 N+1 이 member.getOrders() 의 컬렉..
우테코 레벨4 프로젝트 과정에서 정리한 Wiki 문서 배경 Pobi 강의 - 개발 방법 중에 단위 테스트는 기존의 main/test 구조로 test 디렉토리에서 돌리고, 오래 걸리는 인수테스트는 별도의 디렉토리로 분리해 CI 환경에서만 돌리는 방법도 존재한다. 참고자료 Separating acceptance tests Seperating acceptance tests 과정의 Trouble shooting Is there a way to specify dependencies for a newly created sourceset in gradle? Gradle Java Plugin 과정 기존의 src - main/test 구조에서 src - main/test/acceptanceTest 구조로 바꿔본다. (a..
우테코 레벨4 프로젝트 과정에서 정리한 Wiki 문서 본 문서는 Spring Rest Docs + @SpringBootTest + WebTestClient 버전의 예제로 설명 참고자료 https://docs.spring.io/spring-restdocs/docs/2.0.4.RELEASE/reference/html5/ ★ https://docs.spring.io/spring/docs/current/spring-framework-reference/pdf/testing-webtestclient.pdf ★ http://woowabros.github.io/experience/2018/12/28/spring-rest-docs.html ★ https://cheese10yun.github.io/spring-rest-d..
Lv4 : 팀 프로젝트 -> https://github.com/eattogether/hey-together -> 팀 위키 요구사항 지속적 통합 (모든 테스트 통과할때만 배포, 테스트 커버리지 80%, 품질 기준 통과(정적 분석 도구 이용))을 적용해 일정 기준이 넘는 환경으로 배포 Spring Rest Docs를 이용해 API 문서화 프론트는 프레임워크를 사용하기보다 바닐라 JS 기반으로 개발하는게 어떨까? 인증은 OAuth2를 기반으로 하면 어떨까? 단 Spring Security 사용X 인증을 제외하고 최소 하나 이상의 외부 API와 연동 성능을 높이기 위해 자주 사용하지(변하지) 않는 데이터에 대해 (백엔드 부분에) Cache를 적용 REST 원칙을 지키며 개발 (참고링크) Docker 경험 기능 ..
2019년 회고 ~3월 학교 막학기를 앞두고 방향을 무척 고민했던 시기. 방학이라 시간은 많고 "무엇을 어떻게 공부해야할지"는 몰라서, 무식한 방법으로 책이나 인강을 들어대며 시간을 보냈다. (물론 나중에보니 다 도움됬지만) 원인은 개발로 전향한지 얼마 안된 시기였고, 제대로 경험해본건 그나마 안드로이드, 프론트는 취향아닌것같고, 백엔드는 경험해보지못한 분야에 대한 막연한 두려움. 어느길로 나아가야할지 방향을 못 잡고 있었다. 개발 프로그램/동아리나 인턴도 몇군데 넣었다. 모두 면접에서 탈락. 최탈의 아픔에 대해 알게됬다. 쉽게보고 경험삼아 지원했던 회사들에 광탈하니 자존감이 무척 하락했다. 4~11월 지원한 몇군데에 탈락하고 조용히 막학기 수업이나 들으며 공부를 병행하기로 했다. 그러던중 우테코 공고가..
오늘 프로젝트에서 주요 도메인 모델들의 구조를 잡고 연관관계를 매핑하는 과정에서 삽질로 많은 시간을 소모해, "당연하지만" 다시한번 깨달은 사실을 정리하고 기록해보기로 했다. 배경 상황은 비슷한 예시로 들어보면, 가장 이해하기 쉬운 게시글(Article) - 댓글(Comment)의 관계를 설정해보자. Article(일) - Comment(다)의 일대다/다대일 양방향 연관관계 상태이다. (물론 일대다는 가급적 자제하고 다대일만 매핑하는게 best practice이지만, 양방향이 꼭 필요한 상황이라고 가정해보자) 상황에 따른, 양방향 연관관계 Entity 값 저장 방식 양방향 연관관계 Entity를 save하면서, 당연한건데 큰 그림와 방향을 놓치고 있었다. 정리해보면 다음과 같다. Article은 둘째치고..
- Total
- Today
- Yesterday
- OneToMany
- mysql
- graph
- Data Structure
- 웹해킹
- brute-force
- bfs
- 개발자
- Android Studio
- 해외여행
- 회고
- javascript
- 우아한 테크코스
- reversing
- Java
- C
- FRAGMENT
- sort
- 리버싱
- dfs
- Vo
- Algorithm
- queue
- 프로그래머스
- socket
- Stack
- webhacking.kr
- JPA
- Android
- git
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |