Leetcode란?

다들 이름은 들어봤을 것이다! Leetcode 리트코드란 알고리즘 사이트로서, 많은 문제와 영어로 되어있어서 경력직 코테에 많은 도움이 된다. 왜냐? 많은 곳이 영어로서 알고리즘 테스트를 보기때문이다... 그리고 이미 백준은 아이디가 많은 문제를 풀었어서 새로운 유형의 문제를 정복해보고 싶다는 생각에 도전하게 되었다.

어떤 식으로 풀까?

리트코드는 다음과 같이 왼쪽의 문제와 코드를 작성할 수 있는 공간이 있다. 다만 디버깅과 자바 유저들이라면 당연시 여기는 자동완성, auto import등이 원활하게 지원이 되지 않는다. 그렇기에 나는 IDE에서 풀고 복붙을 해서 넣자! 라는 생각을 하게 된다. 하지만 그렇기엔 무언가... 무언가... 누군가가 툴을 만들어 놓지 않았을까? 라는 생각을 하게 되었다.

Leetcode plugin - LeetCode Editor

그렇게 나는 플러그인을 찾아보았고 결국 찾았다. LeetCode Editor라는 플러그인을 말이다.

이 리뷰는 Coursera "kotlin for java developers"을 보고 리뷰하는 포스트입니다.

현재까지의 느낀 점

정말 강의 자체는 구성을 잘해놨다라는 느낌이 든다. Coursera를 처음 써보는 것인데 중간 중간에 문제도 있고, 플레이그라운드라는 실습과제와 IntelliJ의 플러그인 덕분에 계속 해볼 수 있어서 좋았다. 하지만 강의가 더 많은 지식을 요구할수록 번역의 퀄리티가 더더욱 하락하여 권하기는 아쉽다.

목차

• 무효화 가능성
• 기능적 프로그래밍

무효화 가능성(Nullablity)

해당 장에서는 Kotlin의 Nullability의 대해서 나온다. kotlin은 컴파일시에 null에 대해서 잡고, null에 대해서 접근할때는 다음과 같이 한다.

var s: String?
val length: Int = s?.length ?: 0

위처럼 nullable한 객체는 ?. 체이닝으로 안전하게 null이 되도록 하고 ?: 엘비스 연산자로 null일때의 액션을 정하면 not null인 영역으로 바꿀 수 있다.

안전한 캐스트

val s = if(a is String) a else null
val s: String? = any as? String

위처럼 진행한다면, 캐스팅을 안전하게 해당 타입이면 String, 아니면 null로서 캐스팅이 가능하다. 위의 nullable 연산자 캐스팅과 같이 쓰면 효과적으로 컴파일 시 방어가 가능하다.

이 리뷰는 Coursera "kotlin for java developers"을 보고 리뷰하는 포스트입니다.

왜 이 강의를 골랐을까?

무언가를 만들었다면 그 이유가 분명하다. 그렇다면 그 이유에 대해서 가장 잘 설명해줄 사람에게 무언가를 배운다면, 이유에 공감하기 쉽고 익히기에 더욱 좋을 것! 이라는 생각을 하였다. 그래서 해당 코스를 수강하기로 하였다. 더불어.... 회사에서 하라고 했다. 이왕 하는 김에 스터디를 하기로 하였고, 예전에 써봤지만, 그래도 내가 필요한 부분만 쏙쏙 빼먹기 위하여 이렇게 블로그로 정리한다!

목차를 정리한 후 필수 부분을 간단하게 정리하고자 한다.

참고: 영어가 가능한 한국인이면 영어로 듣고, 아니라면 이 강의 자체를 안듣기를 바란다.

목차

• Java에서 Kotlin으로
• 기본사항
• 제어구조
• 확장기능

스프링 데이터 레디스 장애, 그 이후

이어지는 내용입니다. 전 포스트를 확인해주세요. 스프링 업그레이드, 장애로부터 살아남기 (2)

그렇게 2번째 픽스 배포 이후, 3번째 배포를 하기 시작하였다. 당연히 이번에도 하루 이상을 카나리 배포를 켜놨다. 당연히 이번에도 이상한 일이 일어났다. 바로 한 API에서 저장이 안되는 문제가 일어났다.

그렇게 세번째 롤백을 하게된다....

스프링 데이터 레디스 장애, 그 이후

이어지는 내용입니다. 전 포스트를 확인해주세요. 스프링 업그레이드, 장애로부터 살아남기 (1)

스프링 장애 이후, 빠르게 고치고 다시 나가기로 하였다. 그리고 저번 카나리때 제대로 확인이 되지 않는다는 피드백이 있었다. 그렇기에 해당 배포를 카나리를 24시간 이상 켜두기로 하였다.

그렇게 카나리를 키고 어떠한 에러로그가 눈에 띄였다.

NEW Version

java.lang.ClassCastException: org.springframework.cache.support.NullValue cannot be cast to com.~~~~.XXXdomain.XXX

Old Version

ERROR KryoRedisSerilizer.deserilaiize:81 - redis deserialize error: {}Encountered unregistered class ID:13394

그렇게 두번째 롤백을 하게된다....

스프링 업그레이드, 장애로부터 살아남기

업그레이드를 하면서 발생한 1건의 장애와 2건의 장애가 날뻔한 이야기를 코드를 보면서 이야기 하고자 한다. 미래의 나와 누군가 이 블로그를 본 누군가에게 정말 큰 도움이 되었으면 한다.

먼저 업그레이드 시리즈에서 예고한 바로 그 친구, Spring data redis에 대해서 이야기 하고자 한다.

타임라인은 이렇다. 시간은 정확하지 않다!

Time	Action
~ 2시	스테이지 확인
2시 ~ 3시	카나리 배포 후 JVM & Nginx 메트릭 확인
3시 ~ 5시	전체 배포
5시 ~ 5시 30분	타 이슈건으로 롤백
5시 30분 ~ 6시	롤백을 롤백
6시 ~ 7시	VOC를 받기 시작, 롤백
7시 ~ 8시 반	장애 분석
8시 반 ~ 새벽 1시 반	장애 복구

VOC는 어떤 VOC였나면, CS툴에서 유저의 개인정보를 수정했는데도 불구하고, 개인정보가 반영이 되어있지 않은 장애였다. 원인은 스프링 데이터 레디스 2의 기본 캐시키 전략 변경 때문이다.

마저 가보자! 테스트 전략 수립

이어지는 내용입니다. 전 포스트를 확인해주세요. Spring 5 업그레이드 고군분투 (2)

한번 테스트를 위한 스펙만 나열해보자!

• MySQL, Redis를 사용
• 25%의 낮은 유닛 테스트 커버리지(더이상 쓰지 않는 코드의 테스트 커버리지가 더 높았음)
• 400+ 여개의 API
• 500 ms 내의 응답

크게 이정도가 될 것 같다. 이로 인하여 파생되는 문제들은 다음과 같다.

1. 쓰기, 읽기가 다를 수 있는 문제
2. 성능이 안좋아져 SLA를 지킬 수 없는 문제
3. 커버리지가 너무 낮아 안전하게 배포할 수 없는 문제.

그래서 다음과 같은 테스트를 진행할 수 있다.

1. MySQL(모든 테이블 대상), Redis(모든 캐쉬 대상) 쓰고 읽기
2. 부하테스트
3. API 케이스 별로 다 테스트 하기

이 테스트들을 어떻게 접근하고 진행했는지 공유하고자한다.

스프링 업그레이드 조사 시작!

이어지는 내용입니다. 전 포스트를 확인해주세요. Spring 5 업그레이드 고군분투 (1)

내가 업그레이드 해야하는 스펙은 다음과 같다.

• 편의를 위해 만든 스프링을 래핑한 레거시 프레임워크(더이상 관리 안됨)
• Spring 4
• MySQL(QueryDSL, JPA, MyBatis, Spring-data-common-1,), Redis(Spring-data-redis-1, Jedis), Kafka를 사용
• 25%의 낮은 유닛 테스트 커버리지(더이상 쓰지 않는 코드의 테스트 커버리지가 더 높았음)
• 10+년이 지난 코드
• 400+ 여개의 API
• 500 ms 내의 응답
• 99.999%의 가용성
• 한국과 대만, 두 개의 Region에 서비스
• Batch, Admin, API, Core의 4개의 모듈

내가 본 적도 없는 요구사항. 압도되었다. 그 중에서 가장 힘든 부분으로 예상되는 것은 역시 레거시 프레임워크와 스프링 5의 디펜던시 부분이였다. 팀원들과 이야기 후 다음과 같은 마일 스톤으로 일을 진행하였다.

1. 레거시 프레임워크 Deprecation
2. 스프링 5 업그레이드
3. 레튜스 기반 인하우스 SDK 업그레이드

이렇게 업무를 시작하였다.

왜 Spring 5를 업그레이드 해야했을까?

2022년 카카오 장애를 다들 기억할 것이다. 카카오톡 뿐만이 아닌, 많은 카카오 서비스가 안되었다. 그리고 안된 것은 카카오 서비스 뿐만이 아니였다. 카카오 로그인을 활용한 국내의 많은 서비스들이 정상적으로 동작하지 않았었다. 이 중 가장 문제가 심했던 것은 카카오 로그인이 안되었 던 것이지 않을까 싶다.

이 과제를 받을 당시에도 인증/인가와 관련된 팀이였기에 해당 장애가 더더욱 와닿았고 팀에서도 각종 장애를 대비하여 유연한 시스템을 만들기로 하였다. 팀에서는 Redis의 Dependency를 줄이는 작업을 진행하였다. 인증/인가는 필연적으로 Redis와 의존도가 가장 높았고 장애가 자주 나서 해당 Dependency의 우선순위는 매우 높았다. 팀에서 작업 후, Redis를 장애를 재현하였다. 정말 슬프게도,,,, 원하는 대로 동작하지 않았다. Jedis 때문이였다.

아키텍쳐 패턴

SQL과 자바 메인 로직간의 분리 -> 관심사 분리 방법으로는 게이트웨이, 매퍼가 있다. 게이트웨이 방법은 행데이터게이트웨이, 레코드 집합 게이트 웨이 이렇게 2개가 존재한다. 행데이터 게이트웨이는 객체지향 방식과 꽤나 잘 어울린다. 하지만 도메인 논리가 복잡해져감에 따라 객체가 세분화되는데 이 과정에서 객체와 관계가 매핑이 되지 못한다. 레코드 집합 게이트웨이는 테이블을 객체화 시킨 것이다. 범용적으로 사용이 가능하다.

동작 문제

막대한 객체 그래프를 피하기 위해서는 레이지 로딩을 써라.

난 왜 스프링 배치를 손보게 되었을까

저번년도에 취직을 하고 열심히 일을 하고 있던 중, 보안사항을 안전하게 처리하기 위하여 배치에 투입이 되었던 적이 있다. 이미 구현이 되어있는 배치였고 나는 거기에 숟가락을 얹는 정도의 기여를 하였다. 그리고 요즘 팀에서 돌리는 배치의 수정 사항이 필요하여 예전에 숟가락만 끼얹은 다른 분이 만든 배치가 생각이 났다. 해당 배치처럼 더 좋은 배치를 만들어 팀에 기여하고 싶었다.

스프링 배치의 기본적인 구조

스프링 배치란 우선 다른 분들(감사합니다 jojoldu님..!)이 설명을 해주셨겠지만 스프링 진영에서 만든 대규모 배치 작업에서 쓰이는 툴이다. 이 스프링 배치에서는 기본적으로 잡이라는 큰 단위로 실행을 한다. 그리고 잡 밑에 스텝이라는 단위가 있으며 이 스텝 밑에 태스클릿, 그리고 이 태스클릿을 하나의 태스클릿으로 작성하거나, 리더, 프로세서, 라이터로 나누어서 구성한다. 이 중에서 내가 이번에 건드린 곳은 리더 부분이였다.

해당 책을 고른 이유

이 책을 고른 이유는 구조에 대한 확신이 필요했다. 그리고 좋은 코드란 무엇인가라는 생각이 들었다. 예전에는 작은 규모의 코드를 읽었고, 이제는 회사의 규모가 크고 복잡한 코드를 읽으니 그만큼 좋은 코드에 대한 생각이 필요했다. 그리고 저번년도에 이 책이 개발자들에게 인기가 있었다는 사실을 기억하기에 이 책을 골라서 좋은 구조, 코드에 대한 확립이 필요했다.

오브젝트

해당 책은 객체지향, 이 말을 가장 알맞게 잘 설명한 책이라고 생각한다. 또한 개발자들에게 가장 친숙한 도구인 코드로 설명을 하기에, 실제로 나의 코드, 회사의 코드를 해당 문제에 대입하기에 더 좋았다. 물론 여기서 말한 문제가 정확히 나의 문제라 보긴 어려웠지만 그래도 개념만 있던 것들 보다 좋아 현재까지는 불만 없이 읽고있다. 현재 이 책은 스터디로 진행을 하고 이를 한장 마다 내가 중요하다 생각하는 개념을 옮겨넣는 블로깅이 될 것이다.

3장

이 장에서 중요한 것은 협력, 책임, 역할이였다. 그리고 그것을 더욱 활용할 수 있게 만들어주는 것이 CRC 카드라 생각한다.

Candidate를 하나 놓고 이 것의 책임과 협력점을 구한다. 그리고 어떠한 Candidate에게 책임할당을 할지 Information Expert 패턴을 활용해 할당을 한다.

Information Expert (정보전문가) 패턴

해당 패턴은 가장 해당 정보에 대해서 잘 알고있는 객체에게 책임을 전가하는 것에 있다. 정보전문가에게 책임을 할당함으로서 상태와 행동을 함께 가지는 자율적인 객체를 만들 가능성이 높아지기 때문이다.

메시지가 객체를, 행동이 상태를 결정한다.

메시지는 객체가 가지는 최소한의 인터페이스를 결정 할 수 있다. 그리고 이 인터페이스를 기반으로 객체가 책임, 역할을 할지 결정이 된다. 그리고 객체의 상태는 이 객체가 행동 중에 어떠한 일을 할지 정하는 것임으로 행동이 상태를 결정 할 수 있다고 볼 수 있다.

이 리뷰는 카프카, 데이터 플랫폼의 최강자 책을 보고 리뷰하는 포스트입니다.

카프카 디자인의 특징

1. 분산시스템
2. 페이지 캐시
3. 배치 전송 처리

분산 시스템

카프카는 분산시스템입니다. 그렇기에 유동적으로 서버 댓수를 늘릴 수가 있습니다. 만약 한대가 초당 3000개의 메시지를 처리 할 수 있고 처리 할량이 초당 12000개라면 4대로 구성을 하여서 운행을 하면됩니다.

페이지 캐시

카프카는 페이지 캐시를 이용합니다. 카프카는 OS가 페이지 캐시를 이용하도록 디자인 되어있습니다. 그렇기에 SATA 디스크를 운영해도 괜찮습니다

카프카는 페이지 캐시를 이용하기에 메가비트 단위를 처리하는 시스템이여도 5기가까지 힙으로 구성하는 것을 권장하며 남은 메모리는 페이지 캐시로 운영을 하는 것이 좋습니다. 또한 페이지 캐시를 OS에서 받아서 하는 것이기에 한 시스템에 카프카 하나만 뛰어놓는 것을 권장합니다.

배치 전송 처리

모든 데이터 처리에 있어서 병목은 IO일 것입니다. 그렇기에 카프카는 작은 IO등을 묶어서 처리 할 수 있도록 배치 작업으로 처리합니다. 그렇기에 카프카는 빠를 수 있습니다. 하지만 그렇기에 producer에서 보내는 즉시 consumer로 간다는 것을 보장 할 수 없습니다.

프로그래머라면 다들 그런다. 자신의 코드에 책임을 질 수있어야 한다고. 하지만 그 전에 자신의 코드가 제대로 작성되는지도 확신 할 수가 없다면 어떻게 책임을 질 수 있을까?

사실 나는 내 코드가 제대로 작성이 되는지 엄청나게 불안해 한다. 하지만 제대로 확인을 못하는 게 다수다. 그래서 적어도 앞으로 이정도는 확신을 할 수 있는 코드를 만들고 싶었다. 또한 회사에서도 다들 잘 이용하시기에 제대로 배워보고 싶어 Testing과 Mockito를 공부하게 되었다.

Testing

내가 생각하는 테스팅의 장점은 다음과 같다.

1. 해당 코드의 화이트 박스
2. 변화에 방어할 수 있는 방어막
3. 코드를 설명해 주는 가이드라인
4. 설계 문서

또 하는 회고이다. 저번에 D2FEST에서 아쉽게 탈락을 한 이후로 열심히 학교다니고 있었다. 그리고 사실 D2FEST의 목적 중에 하나인 핵데이가 오픈을 하고 오늘 핵데이가 끝났다. 그에 대한 회고를 쓰려한다. 내가 한 레포지토리 자체는 사실 사라지긴 했지만 중요한 정보를 없애고 깃허브에 올렸다.

그냥 회고를 쓰면 재미가 없으니 키워드 별로 써보도록 하겠다.

플랫폼 UI 개발 전략의 모든 것 - 이재용님

1. 플랫폼 UI 스펙 분석 전략
2. 모듈화 전략
3. 전처리기 전략

스마트 에디터의 기존 설계의 문제점

에디터는 많은 곳에서 쓰는데 포스트 요구사항, 블로그 요구사항, 쇼핑 요구사항등이 에디터 공통 스타일로 들어가 코드관리가 힘들었다.

에디터의 UI 요소간 관계를 파악하기가 어려워 버그 및 사이드 이펙트 발생 플랫폼의 css와 서비스의 css의 간섭이 발생하고 스타일의 우선 순위 관리가 어려움

커스텀 및 확장을 고려하지 않았기 때문에 서비스의 요구사항을 파악하기 어려웠음

알고리즘을 준비하시나요? 요즘 기업의 채용 과정에서 코딩테스트가 생겨서 다들 알고리즘 준비하실거라 생각이 드네요. 저같은 경우는 주로 javascript를 쓰지만 자바스크립트는 제어하기 위한 언어라 생각합니다. 그래서 저같은 경우는 자바스트립트 대신에 성능도 좋고 예시도 많은 c++을 씁니다. 물론 자바도 할 수 있긴 하겠지만 자바는... 흠.. 흥미롭네요

다들 자바스크립트 좋아하시나요? 저는 자바스크립트 정말 좋아합니다!

근데 자바스크립트를 쓰실때 어떻게 해서 쓰시나요? 그리고 혹시 더 자바스크립트에 대해 알고 싶지는 않으신가요? 전 더 알고 싶고 그렇습니다.

그렇게 해서 다들 아는 것이 보통 클로저와 호이스팅 같은 중요한 친구들입니다. 하지만 이번 포스팅은 조금 알면 신기한 문법을 위주로 하려합니다!

오늘 2월 27일 길다고 하면 길고 짧다고 하면 짧은 겨울방학 기간 동안 한 D2 Campus Fest가 끝났다. 나는 React-Calenpicker라는 팀으로 나갔다. 여기서 느낀 바를 계속 기억해두려 기록하자 한다.

안녕하세요! 이번엔 부트스트랩에 대하여 알아보겠습니다. 부트스트랩은 css,html,js 프레임워크입니다. 제가 우선적으로 설명할 것은 그리드 레이아웃과 그것을 사용할 수 있게 해주는 몇가지를 소개시켜드리려 합니다. 순서는 그리드 레이아웃, 컨테이너와 컬럼과 로우, 반응형 키워드 순으로 진행됩니다.

###git이란?

깃은 코드형상관리 프로그램으로서 코드가 어떻게 바뀌었나를 저장하고 기억합니다. 바로 예시로 들어가볼까요?

console.log('Hello world');

이 코드를 살짝만 바꿔봅시다.

console.log('Hello Java');

이렇게 될 시에 깃은 world가 Java로 바뀐 것으로 인식하여 알려주고 사용자의 요청에따라 버전이 달리 됩니다. 그리고 원하는 버전으로 사용자가 오고 가고 하면서 그 형상(버전)으로 이동 할 수 있게 되는겁니다. 만약 쓸모없는 코드라고 지웠다가도 만약 깃에 저장이 되있었다면 그 버전으로 가서 원하는 코드를 얻을 수 있는것이죠.

이번에 페이스북에서 그래프큐엘 알아보기라는 주제로 직접 페이스북의 컨트리뷰터 중에 한 분이 오셔서 강연해 주셨다.

###graphql의 배경 페이스북은 페이스북의 라이브러리를 이런식으로 사용중이다.

react : ui 라이브러리
graphql : data fetch 라이브러리
relay : react와 graphql 엮어주는 라이브러리

페이스북은 예전엔 데스크탑 웹이 우선적이었다. 하지만 이때 모바일은 안되는 기능들과 성능이 있었다. 이걸 고치기 위해 원래 html을 웹뷰로 보여준것과 달리 아예 네이티브 앱과 웹서버를 엮어줘야했다.

이번 gdg webtech는 2018.11.28일 maru180에서 진행 되었다. 세션은 총 3개로 이루어져있고 이번 주제는 프론트 엔드 레벨업이었다.

Angular로 프론트앤드 개발 레벨업 - 고재도

이 세션은 웹테크에 맞게 자바스크립트를 먼저 말하면서 시작을 하였다. 그리고 그와 동시에 프레임워크도 동시에 발전하였다.

2008년 그때 당시에 자바스크립트OOP로 짰다. 그리고 css, 돔선택자를 공부하고 다음에 jquery를 사용하면서 ajax 같은 것도 사용하였다. 하지만 이 때 복잡한 것을 작업했을 때 ajax를 쓰는건 너무 힘들다는 것을 알았고 이때 다른 방법들을 하게되었다. 그리고 이때 modulality, template에 대하여 공부하였다. 또한 이 때 데이터 모델을 했다.

이번 비기너 투 주니어라는 이름으로 우물 128번지에서 자리를 마련해주었다.

###Section 1 : 인썸니아 이찬하 이찬하 님께서 처음으로 먼저 열었다. 이찬하님은 비전공자 개발자로써 어떤 식으로 개발을 하게되었고 어떻게 할 수 있게 되었는지 설명해주었다. 먼저 무조건 하고서 익히라는 것은 코드 리뷰같은 피드백을 해줄 사람이 있을때라는 것이라고 말을 하였다.

• 개발 방법론
  • 최소기능을 개발하고 조금씩 더해 나가자
  • 의사소통은 수평으로, 일로서는 수직으로

Gdg 수원을 다녀오고 느낌점 및 요약정리

이번 2018.11.13에 수원에서 진행하는 gdg수원 devFest를 다녀오고 느낀점이 많아 적은 것을 공유하려한다. ###키노트 이번 데브 페스트의 주제는 digital well-being이였다.

###플러터 현재 모바일 앱 시장은 점차 커지고 있다. 웹이 앱보다 사용시간이 더 길고 더 선호한다 디자인이 심플하고 깔끔한 것을 선호함 즉 모바일 웹보다는 네이티브 앱을 더 오랜시간 사용하고 그 중에서 심플한 것을 더 선호한다.