우테코

어렴풋이 그냥, 다른 사람들 코드 보니까 써서, 습관적으로 작성하던 코드의 이유를 생각해보았다.개발자에게 예외 처리를 강제하기 때문에 문제 상황을 인지할 수 있음항상 처리해줘야하니 번거롭다Exception 상속으로 만들수 있음해당 시점에서 개발자에게 예외 처리를 강제하

한 Position을 여러곳에서 사용하는 경우 버그가 생길 가능성이 높아진다.(여기저기서 채용하기 때문에)XO고민할거리무조건 객체를 새로 생성해 리턴하는게 항상 좋을까?위 코드의 문제점은 성능 문제가 있음.객체를 항상 생성해서 리턴한다는 것은 메모리 사용량이 크다는 것

불안감방황새로움신기함벌써 레벨2를 시작한지 1주가 지났다.레벨2에서는 스프링을 배우기 시작했는데, 스프링을 처음 써보는 상황이 아니지만 최근 일주일동안 든 생각은 너무나도 모르는게 많고 내 스스로 사용법으로써만 스프링을 알지 이해를 하고 쓰는게 아니다는 생각을 했다.나

우테코 크루들과 위 주제로 토의해보았다.dao - data access object db에 접근하는 객체repository - 도메인 객체를 저장하고 조회하는 작업을 추상화한 저장소 계층둘다 모델 계층에서 데이터 저장에 관심이 있는것은 분명하다.모델 계층에 dao를 둘

개발을 하다 보면 늘 고민하게 되는 주제가 있다."모든 필드나 파라미터에 대해 null 체크를 해야 할까?" 나 역시 초반에는 NullPointerException을 피하기 위해 모든 곳에 null 체크를 넣으려 했다.그런데 이번 논의를 통해 내 생각이 완전히 바뀌었

서비스에서 spring validation을 쓰면 뭐가 안좋을까? 나는 스프링개발자고 스프링에서 제공하는 기능인데 그냥 쓰면 안되나? - 순수 자바를 써야하는 이유에 대해 정리해보았습니다

우테코에서 작게 프로젝트를 진행하고 있는게 있다.하지만 미션도 바쁘고 이것저것하다보니 들이는 시간은 주말포함 한 일주일에 6시간?정도가 최선인 것 같다.그러면서도 우테코에서 배운 객체지향과 테스트 등을 다 적용하다보니 너무 많은 시간이 소요됐다.그러던 와중 팀원과 회의

사생관 내가 하고싶은얘기를하자.

이번에 우테코에서 팀플을 진행하게 됐다.팀에서 협업 플로우를 정하는 도중, 깃 브랜치에 대해서 심도있게 토론해본뒤 그 내용을 정리해본다.선결론 - 깃 플로우와 유사하게 가되, hotfix만 쓰지 말자BE,FE가 한 레포지토리로 된 모노리스 구조어떻게해야 서로 간섭없이

팀원이 서비스 의존 하지말자고한다. 왤까?

깃허브 이슈 아직도 직접 닫으시나요?

코치분이 갑자기 11만개의 request를 보냈다.

아 flyway 넣기 싫다.

데모데이날 DOS 공격으로 서비스가 다운되는 문제를 피하기 위해 nginx 설정을 합니다.dos 공격에 대비한 nginx 설정을 합니다.limit_req_zone $binary_remote_addr zone=perip:100m rate=10r/s;10r/s는 1초에 1

개요 우아한테크코스에서 아맞다 서비스를 기획 및 개발중에 있습니다. 아맞다는 조직단위 이벤트 리마인드 플랫폼입니다. 아맞다는 지난 데모데이때, 메인화면 api에 대해서 11만개의 리퀘스트를 받았습니다. 11만 리퀘스트가 왔을때 모니터링 당시 가장 오래 걸리는

내 돈 돌려줘요

retry해도 실패하는 외부 api를 어떻게 대해야할까요? dlq를 도입하여 조금 더 안정적인 서비스를 만들어봅시다.

transactional outbox, failover부터 dlq까지 믿고 쓸수 있는 외부 API 의존 시스템을 구축해봅시다.