- E-commerce BigData Scale AI Journey
- BigData Scale Deep Learning Production System Use Case
- Deep Learning, Cloud PaaS, Microservices, DevOps, etc.
- E-Commerce AI Production System Strategy
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
- E-commerce BigData Scale AI Journey
- BigData Scale Deep Learning Production System Use Case
- Deep Learning, Cloud PaaS, Microservices, DevOps, etc.
- E-Commerce AI Production System Strategy
한국 표준(?) 자바셋(Java 1.6+Spring 3.x+MyBatis)과 Monolithic 아키텍처를 사용하고 있었던 제 조직 내에서 기술적 변화를 이끌어가는 것에 관련된 내용입니다.
변화를 유도하기 위해서 어떻게 해야 하는지가 핵심이며,
Architecture, Frontend, Backend, 방법론/프로세스의 영역을 각각의 단계로 나누어서 Phase1을 수행한 것과 Phase2를 수행 중인 내용에 대해서도 다룹니다.
Phase1
- Architecture : Frontend / Backend 명시적 분리
- Frontend : Angular.js, Grunt, Bower 도입
- Backend : Java 1.7/Spring4, ORM 도입
- 방법론/프로세스 : Scrum, Git
Phase2
- Architecture : Micro-Service Architecture(MSA)
- Frontend : Content Router, E2E Test
- Backend : Polyglot, Multi-Framework
- 방법론/프로세스 : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop
100% Serverless big data scale production Deep Learning Systemhoondong kim
- BigData Sale Deep Learning Training System (with GPU Docker PaaS on Azure Batch AI)
- Deep Learning Serving Layer (with Auto Scale Out Mode on Web App for Linux Docker)
- BigDL, Keras, Tensorlfow, Horovod, TensorflowOnAzure
2018년 서울시 앱 공모전 (URL: https://mplatform.seoul.go.kr )에서 GitHub 설명을 위한 자료입니다. 이전 https://www.slideshare.net/ianychoi/git-github-46020592 자료에 모바일 앱 개발 환경 및 GitHub Desktop 프로그램에 대한 부분을 추가하였습니다.
[DEVIEW 2017] 14일만에 GitHub 스타 1K 받은 차트 오픈소스 개발기Jae Sung Park
차트란 무엇일까요? 차트는 우리가 일상에서 아주 쉽게 자주 접하지만, 막상 개발자로써의 경험을 하는 동안 차트 개발(적용)은 쉽게 경험해 보기 어려운 영역이기도 합니다.
본 발표는 '차트'라는 영역에 대한 개발 경험기와 함께 오픈소스로 공개 후, 단 기간 내에 많은 주목을 받기 까지의 과정을 통해 어떻게 의미있는 성과를 글로벌 하게 얻을 수 있었는가에 대한 오픈소스 성장에 대한 경험도 같이 공유합니다.
이를 통해 다양한 오픈소스 개발 시도와 참여가 활발히 이루어 지는데 도움을 줄수 있게 되기를 기대 합니다.
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기Chris Ohk
C++11을 시작으로 모던 C++이 도입된 지도 어느새 6년이라는 시간이 흘렀습니다. 올해는 C++17 표준이 도입될 예정입니다. 그만큼 많이 개선되고 새로운 기능들이 많이 도입되었기에 실무에서 사용해보고 싶은 경우도 많습니다. 하지만 이미 서비스 중이라 기존 프로젝트를 새 버전의 VS로 마이그레이션하기 어려운 프로젝트가 많습니다. 그렇다고 아예 불가능한 일도 아닙니다. 이번 세미나에서는 기존 프로젝트를 새 버전의 VS로 마이그레이션하면서 발생했던 문제와 마이그레이션 이후 모던 C++을 사용하면서 발생했던 문제, 그리고 해결법을 설명하고자 합니다. 또한 새 버전의 VS에 생긴 유용한 기능들도 함께 알려드립니다.
100% Serverless big data scale production Deep Learning Systemhoondong kim
- BigData Sale Deep Learning Training System (with GPU Docker PaaS on Azure Batch AI)
- Deep Learning Serving Layer (with Auto Scale Out Mode on Web App for Linux Docker)
- BigDL, Keras, Tensorlfow, Horovod, TensorflowOnAzure
2018년 서울시 앱 공모전 (URL: https://mplatform.seoul.go.kr )에서 GitHub 설명을 위한 자료입니다. 이전 https://www.slideshare.net/ianychoi/git-github-46020592 자료에 모바일 앱 개발 환경 및 GitHub Desktop 프로그램에 대한 부분을 추가하였습니다.
[DEVIEW 2017] 14일만에 GitHub 스타 1K 받은 차트 오픈소스 개발기Jae Sung Park
차트란 무엇일까요? 차트는 우리가 일상에서 아주 쉽게 자주 접하지만, 막상 개발자로써의 경험을 하는 동안 차트 개발(적용)은 쉽게 경험해 보기 어려운 영역이기도 합니다.
본 발표는 '차트'라는 영역에 대한 개발 경험기와 함께 오픈소스로 공개 후, 단 기간 내에 많은 주목을 받기 까지의 과정을 통해 어떻게 의미있는 성과를 글로벌 하게 얻을 수 있었는가에 대한 오픈소스 성장에 대한 경험도 같이 공유합니다.
이를 통해 다양한 오픈소스 개발 시도와 참여가 활발히 이루어 지는데 도움을 줄수 있게 되기를 기대 합니다.
[C++ Korea 3rd Seminar] 새 C++은 새 Visual Studio에, 좌충우돌 마이그레이션 이야기Chris Ohk
C++11을 시작으로 모던 C++이 도입된 지도 어느새 6년이라는 시간이 흘렀습니다. 올해는 C++17 표준이 도입될 예정입니다. 그만큼 많이 개선되고 새로운 기능들이 많이 도입되었기에 실무에서 사용해보고 싶은 경우도 많습니다. 하지만 이미 서비스 중이라 기존 프로젝트를 새 버전의 VS로 마이그레이션하기 어려운 프로젝트가 많습니다. 그렇다고 아예 불가능한 일도 아닙니다. 이번 세미나에서는 기존 프로젝트를 새 버전의 VS로 마이그레이션하면서 발생했던 문제와 마이그레이션 이후 모던 C++을 사용하면서 발생했던 문제, 그리고 해결법을 설명하고자 합니다. 또한 새 버전의 VS에 생긴 유용한 기능들도 함께 알려드립니다.
1. 고급 Git과 브랜치 전략,
그리고 히스토리 최적화
2020.04.25
Speaker :김주석 (@ggaengma)
Sub : 원기태
Follow : 전고은
2. Topic
열심히 개발자로 살아왔지만 귀찮아서 대충 알고 쓰거나 그냥 넘어갔던 "중요한 것"들에 대한 스터디
- Topic : 정규식
Title "언제까지 복사해서 붙여넣을거에요?"
(Speaker:원기태 / Sub:전고은 / Follow:윤명환)
- Topic : SQL
Title "Query plan"
(Speaker:윤명환 / Sub:서승재 / Follow:원기태)
- Topic : AWS
Title "AWS에는 EC2만 있는게 아니라니까"
(Speaker:서승재 / Sub:윤명환 / Follow:김주석)
- Topic : Git
Title "고급 Git과 브랜치 전략, 그리고 히스토리 최적화"
(Speaker:김주석 / Sub:원기태 / Follow:전고은)
- Topic : Shell
Title "효율적인 Shell script와 텍스트 에디팅"
(Speaker:전고은 / Sub:김주석 / Follow:서승재)
오늘 우리는...
3. 아는 것 vs 잘 아는 것 vs 잘 활용하는 것
운전을 하는 방법(technical)을 아는 것 vs 운전을 잘 하는 것(knowhow)
- 보통의 개발자는…
- init, clone, commit, pull, push, merge, add, branch, checkout,...
- ------------------------------------------------------------------------------------------------------
- 좀 더 잘하고 싶은 개발자는…
- fetch, log, revert, cherry-pick, diff, rebase, tag, …
- ------------------------------------------------------------------------------------------------------
- 제대로 활용하는 개발자는…
- git branch 모델
4. 뭣이 중한디?
- 좀 더 고급지게 알면, 그 자체로 의미는 OK
-> 다양한 상황이나 환경에서 문제를 해결할 수 있으니까!
- 근데 운전을 하는 법 <<< 운전을 잘 하는법
- Git을 사용하는 법 <<< Git을 잘 활용 하는 것
5. 필요한 건 시간, 그리고 습관
- branch의 사전적 의미 = (나무 등의)가지
- 가지를 뻗어나가자!
- … 근데 그러다보면 가지가 산만해서 가지치기(rebase)가 필요!
- 어떤 줄기의 기원은 A줄기이고, A줄기의 원래 줄기는 B이고… 결국 뿌리 (root)
는 하나인데..?
- 개발 언어에 framework가 있다면, Git에는 Branch전략(model)!
- 공통 규약이자 신뢰의 약속
- 개발과 배포의 효율성, 그리고 자동화
- 코드리뷰(Online and Offline)가 없다면, 전략도 자동화도 쓸모 아리마생
6. 다짜고짜 고급진 두 가지 전략 - 첫번째
- 첫번째, 배포할 것을 merge (병합해서)해서 배포하기
- 배포 담당자의 역할 감소
- 상대적으로 단순한 모델
- 오랜 전통(?)을 지닌 Branch 전략
- “제외시키고 나가기”에 어려움
- REF. http://hundredin.net/2014/04/06/a-successful-git-branching-model/
8. 다짜고짜 고급진 두 가지 전략 - 두번째
- 두번째, 배포할 것을 cherry-pick(당겨다가) 배포하기
- 배포 담당자가 바쁨(배포날은 이것만 한다!…)
- 첫번째 전략보다 상대적으로 복잡
- 현재(아직까지는) Google의 Branch 전략 (그럼 묻따않 채택?!?!?)
- 확실히 배포될 것들로만 이루어지기에 제외시키고 나갈 필요 없음
10. 코드 리뷰는 어떻게…?
- 아, 개발하기도 바빠 죽겠는데...
- 코드리뷰 = 운동
- 시간이 나면 하는 게 아니라, 시간을 내서 해야하는 것
- 기본은 Online으로 Merge Request, Pull Request
- 너무나도 복잡하거나 너무나도 중요해서 설명이 필요하면, Offline 코드 리뷰
- 공통적인 코딩 컨벤션이 반드시 필요 (시간 낭비 이슈 최소화)
- (걱정마...구글이 있어) https://google.github.io/styleguide/javaguide.html
- 글로벌, 그리고 국내 Top IT기업에서 코드 리뷰를 하지 않는 개발조직은, 단 한
곳도 없음! (찾으면 500원)
11. Github, Bitbucket, Gitlab
- git 그 자체가 아니고 대한 저장소에 대한 서비스
- 대표주자 삼총사. github VS bitbutcket VS gitlab
- 비싸지만 좋고 그 자체가 표준에 가까워(교과서) VS 더 비싸고 더 좋고 사용자
친화적이고 편리하고 연동하기 좋아(전과) VS 싸고 괜찮고 어지간한건 다 있
어(제본)
- 시작은? Gitlab
- 무료 CI/CD 경험! 무료 Hook 경험! Snippet까지! Issue! 무료! 무료! 무료!...
- 근데... 느려… 뻗어…
- 그런 상황이 왔을 때, 유료를 고민해도 늦지 않다!
- Bitbucket의 Lock-in을 감당하기 어려울수도… (feat. JIRA)
14. 역사를 잊은 민족에게 미래는 없다
- 역사(history)를 잊은(관리하지 않은) 민족(개발조직)에게 미래(보다 나은 개발
환경)는 없다! 형상관리의 당위성
- Commit은 반드시 기능 단위로! 왜? 그래야 알아보니까
- burning 하다가 commit을 잊었다면?
- 선택(add)하여 commit! (git add -p === git status + git diff + git add)
- 일하는데 갑자기 이거 먼저 해달라는 군주의 부탁?
- 빼뒀다가(stash) commit하고, 꺼내오기(pop)
- 기능까지는 아닌데 commit이 필요하다면?
- 의미가 필요하지 않은 commit history를 정제(rebase)
- 다중 remote 가 필요한 시점? -> 폐쇄된 저장소에서 사용
16. merge VS rebase
- 원래 git은 3-way-merge 방식 (나, 너, 그리고 조상)
- 코드가 합쳐지는 과정은 merge이거나 rebase 두 가지
- 정답은 없지만 모든 히스토리 우선? merge. 최적화? rebase
- remote에 push된 commit은 rebase를 하지 않는 것이 관례
17. Git rebase : 과정을 알아야 고오급
git checkout feature git rebase master
head가 master로 변경