일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 모바일웹스킨
- khaiii
- taskkill
- 코딩온라인
- terminate
- 파이썬
- Machine Learning
- 필사
- SSR
- 비동기
- 카우치코딩 #couchcoding #6주포트폴리오 #6주협업프로젝트
- 클라이언트사이드렌더링
- expression statement is not assignment or call html
- 파이콘
- 마크다운
- 카우치코딩 #couchcoding #6주포트폴리오 #6주협업프로젝트v
- 출처: 자바의 신 8장
- github
- #스파르타코딩클럽후기 #내일배움캠프후기
- 플젝후체크
- 자바파이썬
- 서버사이드렌더링
- Anaconda
- gitbash
- Morphological analysis #Corpus
- address
- Kakao
- PID
- Technical Writing
- github markdown
- Today
- Total
목록전체 글 (130)
개발 일기
상황 프레시카트라는 이커머스 서비스의 주문 기능을 구현하고 있었습니다. 주문의 특성 상, 여러 유저가 하나의 상품을 동시에 주문하는 상황이 빈번할 것입니다. 이렇게 동일한 재고 수량 데이터를 차감하는 상황이라면 코드가 잘 작동할지 점검 해보고 싶었습니다. 먼저 주문 기능의 동작을 살펴보겠습니다. 이는 하나의 트랜젝션 내에서 수행됩니다. 1) 유저가 CART(DTO) 에 주문 객체를 담는다. 2) Product_Inventory 테이블에서 주문하려는 제품의 재고를 확인한다. 3) 재고가 있는 경우 주문 수량만큼 차감하여 수량을 업데이트 한다. 3) 주문을 완료한다 주문 로직 - OrderRegisterProcessor.java @Transactional public void place(LoginUser u..
프레시카트는 1인 프로젝트 입니다. 1인 프로젝트이다 보니, 팀과 협업할 때보다 충돌이 발생하는 지점이 적었고 신경 쓸 부분도 많지 않았습니다. 현업에서는 개발 못지 않게, 개발 환경을 구성하고 개선하는 것 역시 필요할 것이라고 생각했습니다. 이전의 팀 프로젝트에서 느꼈던 어려움을 돌이켜보고, 개발자 동료들이 공유해주는 어려움을 참고하면서 여러 기술을 도입해보았습니다. Flyway로 데이터 베이스 스키마의 변경 이력 관리 도입 이유 이전에 팀 프로젝트를 할 때, DB를 공유해서 쓰면서 어려움을 겪은 적이 있었습니다. 스키마 변경이 있을 때마다, 공유된 내용을 확인하고, 변경 사항을 인지해야 했습니다. 성과 flyway 적용으로 변경 이력을 문서화 할 수 있게 되었습니다. 변경에 맞춰 애플리케이션 로직도 ..
상황 이커머스 서비스를 구현하면서, 서버 메모리에 세션을 저장하는 방식으로 로그인을 구현했습니다. 추후 서버가 증설될 경우, 세션이 여러 서버에 걸쳐 공유되어야 하는데, 기존 구조는 서버마다 저장소를 독립적으로 갖는다는 한계가 있었습니다. 이전 포스팅 에서도 살펴 보았듯, 세션의 특성 상 서버 scale-out 시에는 (서버의 대수를 늘리는 것) 별도 처리를 해줘야 하기 때문입니다. 실제로 유저가 몰려서 서버를 증설하는 상황은 아니었습니다. 하지만, 유저가 늘어나고 이에 따라 scale-out 하는 것이 매우 흔한 상황임을 가정해볼 때, 다중 서버 구성에 대비하는 것이 중요하다고 생각했습니다. 깊이 학습해볼 필요성을 느껴서 Redis로 로그인 중앙화를 구현하였습니다. 이번 포스팅에서는 1. 해당 문제를 ..
객체 지향을 고민하게 된 계기 작년에 스프링 입문을 위한 자바 객체 지향의 원리와 이해 책을 읽었습니다. (이 책을 읽고 나서 스프링을 좀 더 개발 의도에 맞게 (== 객체 지향을 생각하며) 바라볼 수 있었습니다. 디자인 패턴, SOLID 등을 소개하면서 어떻게 객체 지향을 적용할 수 있을지, 좋은 가이드가 되어준 책 이었는데요. 스프링 개발자라면 꼭 읽어보기를 추천합니다. ) 객체 지향은 인간이 사물을 인지하는 방식대로 프로그래밍 하는 방식입니다. 즉 기계에 맞춰 사고하던 방식이 아니라, 인간이 현실세계를 인지하는 방식으로 프로그램을 만들자는 의도에서 출발합니다. 객체 지향 원칙을 지키다 보면, 결합도는 낮추고 응집도는 높이는 방향으로 설계하게 됩니다. 그리고 이는 재사용성, 유지보수성을 용이하게 해줍..
상황 비밀번호 암호화를 구현하는 기술을 고민하고 있었습니다. 해시를 적용하고자 했으나, 해시는 같은 입력 값에 대해, 항상 같은 결과 다이제스트가 나오는 취약점이 있습니다. 문제 위의 취약점 때문에, 해시 알고리즘은 레인보우 테이블을 사용해서 해킹 당할 위험이 있었습니다. 해결/결과 솔트는 해싱 하기 전에, 랜덤 문자열을 비밀번호에 더합니다. 솔트와 함께 암호화 하면, 솔트가 임의 값이기 때문에 원래 값을 찾아내기 어렵습니다. 즉, 사용자 별로 다른 솔트를 사용한다면, 동일한 패스워드를 사용하더라도 다이제스트가 다르게 생성됩니다. 자바에서 지원하는 BCrypt 라이브러리를 사용하여 솔트를 구현했습니다. 해시와 비교할 때, 결과값이 예측 불가능하기 때문에, 보안을 강화하는 이점을 얻을 수 있었습니다.
상황 인증 기능을 구현할 때, 로그인이 필요한 API에 인증 처리를 강제해야 했습니다. 기존 코드는 인터셉터의 addPathPatterns로 모든 경로를 더하고, excludePathPatterns로 일부 경로만 제외하여 구현했습니다. 문제 위의 방식은 로그인이 필요 없는 경로를 추가할 때마다 직접 입력해줘서, 오타가 발생할 위험이 있었습니다. 이러한 위험을 줄이면서, 컨트롤러에서 로그인 필요 여부를 명시적으로 표현하는 방법을 고민하였습니다. 해결 /결과 @LoginCheck 라는 커스텀 애노테이션을 만들었습니다. Retention Policy를 설정하여, 런타임까지 객체를 유지 했습니다. 메서드 단위로 적용함으로써, 인터셉터를 거쳐갈 때 @LoginCheck가 붙은 메서드는 로그인 여부를 확인하도록 강..
1. 무엇이 잘 되었을까? -구현 과제가 주어졌을 때, 단계별로 쪼개는 연습 -코드 복붙을 줄이고 생각하는 훈련 -혼잣말을 하면서 스스로를 가르쳐주듯 학습. -책을 보면서, 신뢰성 있는 자료를 참고하고 깊게 공부 (블로그 글보다 책이나 강의를 보는 게 더 학습하기 용이함) -왜? 를 던지며 공부 -동료들을 사귀고, 좋은 정보를 공유하고, 같이 으쌰으쌰한 것(?) ㅎㅎ 같은 방향으로 성장하려고 하는 사람들을 만나서 좋았다. 퇴사하고 1년이 다 되어 가는데, 내가 동료의 존재를 그리워했다는 걸 새삼 깨달았다. 2. 잘 되지 않았던 것? -1일 1알고리즘 - 코딩 할 때 긴장이 되는 것 / 초조해지는 것 -> 명상과 산책을 했지만, 분명히 도움이 되지만, 장기적으로는 인정 욕구와 기대치를 줄일 필요성을 느낌...
Alan K가 주장한 객체 지향의 핵심이 뭐죠? 갑자기 멘토님이 던지신 질문이었다. 독립된 객체들끼리 메시지를 주고 받으면서 협력한다. 이렇게 답했는데, 하나 놓친 게 있었다. 다시 정리해보자. Alan K의 글을 보면, 흔히 객체지향은 캡상추다(캡슐화, 상속, 추상화, 다형성) 과는 조금 다르다. 글을 보면 캡상추다는 나중에 나온 개념이고, 아래 Alan Kay가 객체 지향 프로그래밍에 대해 주고 받은 서신을 보면. 마지막 단락이 핵심이다. "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." "객체 지향은 객체 간의 ..