find actions > view pull requests > github enterprise 에 로그인로그인을 위해선 personalize token 생성해주면 됨.https://github.tossinvest.bz/settings/tokens생성한 토큰을

우테코를 수료하고 개발자로 취업한지 만으로 1년이 됐다. 매일 교육장으로 향하다 다른 방향의 지하철을 타고 혼자서 회사를 가던 날이 떠오른다. 그때의 날씨, 온도가 되니 1년이 지났구나 하는 것을 느끼게 된다. 회사에서도 "오신지 1년밖에 되셨어요? 2년은 넘은 것 같

회복력 시대예정된 전쟁자본주의와 자유 (밀턴 프리드먼)승자독식 사회 (필립 쿡)불편한 진실 (엘고어)어떻게회사에서 오래 살아남는가 (필 포터)우리는 어떻게 여기까지 왔을까(스티븐 존슨)죽음의 수용소에서나는 왜 너를 사랑하는가니체의 말철학이 필요한 시간로마인 이야기

가위바위보 이벤트를 하면서 푸시를 보낼일이 많이 생겼다. 예를 들어 가위바위보에 승리하고 나면 1승을 추가로 하면 또 다른 무언가를 얻을 수 있다고 푸시를 보낸다. 처음에는 이런 것들이 그렇게 많지 않아서 코드에서 직접적으로 푸시를 보내는 코드를 추가했었다. 하지만 이

가위바위보 이벤트가 생각보다 잘되었고, 이걸 조금 더 개선해보는 아이디어 중 하나가 가위바위보 몇등을 했는지를 보여주는 리더보드를 만드는 것이었다. 랭킹을 보여주려면 레디스의 zSet을 쓰면 된다고 생각했다. 하지만 문제는 과거 데이터까지도 다 반영해서 랭킹을 보여줘야

https://www.youtube.com/watch?app=desktop&v=92NizoBL4uA가장 일반적으로 쓰이는 전략이다. 캐시에서 먼저 확인하고 있으면 가져온다. 없으면 DB에서 가져와서 레디스에 저장한다. lazy loading이라고도 부른다. 레

가위바위보 이벤트를 만들면서 재밌는 문제가 있었고, 다른 분들의 도움으로 해결할 수 있었다. 그 문제와 해결 과정이 재밌었다. 우선 가위바위보 이벤트는 다른 사람에게 링크를 보내서 링크를 받은 사람이 경기에 참여함으로서 두 사람이 가위바위보를 하게된다. 여기서 제약 조

레디스 클라이언트는 레디스 서버에 연결하여 레디스 데이터 구조를 조작할 수 있게 해준다. 서버 개발자는 cli가 아닌 코드 상에서 레디스에 접근해서 데이터를 다룰 수 있어야 한다. Java용 Redis 클라이언트 라이브러리로는 Lettuce, Redisson, Jedi

기본적으로 hash table을 사용해서 데이터를 저장하고 조회한다. SET key value : 키(key)에 값(value)을 저장합니다.GET key : 키(key)에 저장된 값을 반환합니다.GETRANGE key start end : 키(key)에 저장된 값을

Redis는 REmote Dictionary Server를 https://redis.io/docs/about/http://redisgate.kr/redisgate/ent/ent_intro.php

현재 팀의 특성상 기존 코드에 새로운 기능을 덧대는 일보다는 항상 새로운 기능을 만들고 나가는 일이 많았다. 하지만 이번에는 기존 코드가 조금 변경되어 기능이 나갔는데, 기존 기능과의 하위 호환성을 고려하지 않고 배포가 나갈뻔 했다. 배포를 할 때는 서버/프론트의 배포

내가 주로 담당하는 기능들은 이벤트로 무료 주식을 나눠주는 기능이다. 그런데 이 무료 주식들에 대해 취소해달라는 CS가 생각보다 많이 들어온다 (소수점 주식을 보는게 거추장스럽거나, 다른 증권사 직원들인 경우). 이 CS 때문에 컨텍스트 스위칭도 자주 발생하고, cs

작성 이유 회사에 들어오고 3주차였나 4주차였나 처음으로 냈던 에러가 batch job 관련 된 것이었다. 30만명을 대상으로 푸시 / 알림을 발송하는 기능이었는데 아침에 모니터링을하며 로그를 보니 2명에게만 발송되었다 (꿈인줄 알았다). Batch를 정말 Batch

현업에서의 개발은 학습 목적의 개발과 차이가 난다고 느껴지는 몇몇 포인트가 있다. 그런 것들 중 하나가 운영을 위한 코드나 기능들이 들어가야할 때가 있다는 점이다. 이번에도 주식 예언과 관련된 이벤트를 만들다가 사용자들의 데이터 변경 히스토리들을 다 저장해서 나중에 필

캐싱이라는 것이 그냥 얼마나 캐싱할지 시간만 잘 걸어두면 되는거라고 생각을했다. 하지만 뭐를 키를 뭐로 잡을 것인지, 데이터가 변경이 일어났을 때 원본 데이터와 동기화를 어떻게 맞출 것인지 등 고려할 것이 많았다. 그래서 이번에는 이론적인 것보다는 경험으로 배운 것들을

Github repo 학습 배경 프로젝트 코드들을 보다가 캐시가 적용되어 있는 부분들이 있었다. 재밌는 점은 레디스를 이용해서 캐시를 이용한 부분도 있었고 로컬 캐시를 이용한 부분도 있었다. 로컬 캐시 중에서도 Caffeine Cache가 적용되어 있어서 간단하게 써

1. val, var private val은 자바의 프로퍼티와 동일하다. 2. 생성자 3. init 4. object 5. 바로 fun 6. companion object 7. 인터페이스와 구현체 8. data / eqhc 9. private set

예상보다 조금 빠르게 우테코를 떠나게 됐다. 우테코 과정을 되돌아보고 잘했던 것과 못했던 것들을 짚어보면 새로운 시작에도 도움이 될 것 같다. 딱 작년 이맘때 쯤 우테코에 지원을 했고 우테코에 합격하고 나서도 갈지 말지 되게 고민을 많이 했다. 취업을 목적으로 하던 공

마지막 데모데이를 위한 한 주였다. 레벨 4 초반에는 나를 포함해서 뭔가 팀이 프로젝트에 집중하지 못한다는 느낌을 받았다. 그래서 레벨 3 때 그 재밌는 느낌이 나지 않았다. 레벨 4 중반부터 새로운 기능들이 생기고 다시 사용자가 늘면서 점점 몰입을 할 수 있었다. 데

이전 글에서 Replication 원리와 아키텍처에 관해 다뤘다. 이제 실제 어떻게 진행했는지 정리한다. 레플리카 서버에서 소스 서버의 바이너리 로그 파일명과 파일 내에서의 위치(Offset 또는 Position)로 개별 바이너리 로그 이벤트를 식별해서 복제가 진행되는