Source : http://www.opennaru.com/cloud/cloud-native-visiting-seminar/
* OpenShift 의 주요 기능과 컴포넌트 그리고 용어 소개
* OpenShift H/W 와 S/W 아키텍처
* PaaS 구축 시 반드시 고려해야 하는 부분들은 무엇인가?
* Scale In/Out 및 Auto Healing 이란?
* 애플리케이션 장애시 자동 복구 데모
* 오토 스케일링 데모
* OpenShift 환경에서 Apache/Tomcat 구성 및 배포 데모
오픈소스SW 방식의 연구개발 프로젝트를 수행하는 기업의 거버넌스 체계를 어떻게 구축하고 관리해야 하는지 제시
Presents how to establish and manage a governance system for companies conducting R&D projects using open source SW.
Source : http://www.opennaru.com/cloud/cloud-native-visiting-seminar/
* OpenShift 의 주요 기능과 컴포넌트 그리고 용어 소개
* OpenShift H/W 와 S/W 아키텍처
* PaaS 구축 시 반드시 고려해야 하는 부분들은 무엇인가?
* Scale In/Out 및 Auto Healing 이란?
* 애플리케이션 장애시 자동 복구 데모
* 오토 스케일링 데모
* OpenShift 환경에서 Apache/Tomcat 구성 및 배포 데모
오픈소스SW 방식의 연구개발 프로젝트를 수행하는 기업의 거버넌스 체계를 어떻게 구축하고 관리해야 하는지 제시
Presents how to establish and manage a governance system for companies conducting R&D projects using open source SW.
왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항rockplace
[Microsoft Azure와 Red Hat OpenShift를 통한 비즈니스 스피드 업! 웨비나]
왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항
락플레이스 구천모 상무
영상 다시보기 : https://youtu.be/i3yKrHLHYJI
디지털 시대에 기업들은 빠르게 변화하는 시장과 환경에 발 빠르게 대처하기 위하여 점점 조직을 작게 만들어 민첩성을 확보하고자 노력하고 있습니다. 이를 위한 기술의 하나로 '클라우드 네이티브'의 도입이 가속화 되고 있는데요, 이는 클라우드 컴퓨팅 모델의 장점을 모두 활용하여 애플리케이션을 개발하고 실행하기 위한 접근 방식을 일컫습니다. 아키텍처 관점에서는 분산을 통한 유연성 확보, 운영 관점에서는 애플리케이션도 분산시켜야 하는데요, 이를 위해서는 다양한 클라우드 환경에서 자유롭게 이식하기 위한 '컨테이너' 구현이 필수적입니다.
이준영 (현 소프트웨어인라이프 연구원)
OpenShfit와 CSB.IO
인프라 비용을 절감하고 애플리케이션 개발속도를 향상 시킬 수 있는 방안으로 PaaS와 레드햇의 오픈 소스 솔루션인 OpenShift에 대하여 설명한다.
그리고, CSB.IO와 OpenShift의 미래 모습에 대해서도 소개한다.
- The Cloud Life Seminar 2014 발표 내용
OpenStack과 업스트림 컨트리뷰션 (2016 IT 21 글로벌 컨퍼런스)Ian Choi
2010년 7월 Rackspace사와 NASA부터 시작된 OpenStack 프로젝트는 빠른 성장세를 거쳐 2016년 4월에는 13번째 릴리즈에 해당하는 Mitaka 버전이 등장하였습니다. OpenStack은 클라우드 관리 오픈 소스 소프트웨어로, 최근 User Survey에 따르면 약 2/3에 해당하는 클라우드 인프라에서 프로덕션 또는 실제 운용 목적으로 사용할 정도로 충분한 성숙도를 갖추고 있습니다. 이와 같이 OpenStack이 발전할 수 있었던 배경에는 사용자, 개발자, 여러 업체들이 주도적으로 참여할 수 있도록 이루어진 커뮤니티 및 생태계를 통한 지속적인 업스트림 컨트리뷰션이 있습니다. 최근 발표된 Mitaka를 살펴보면, 178개 국가에서 345개 조직에 속한 2,336명에 달하는 구성원이 350만 줄에 해당하는 코드를 기여하였으며, 지난 릴리즈와 비교하였을 때 8개의 신규 프로젝트가 추가되는 등의 컨트리뷰션이 있었습니다. 본 발표에서는 이와 같이 강력하고 지속적인 업스트림 컨트리뷰션을 주제로 하여 클라우드 관리 오픈 소스 소프트웨어인 Openstack이 어떤 식으로 사용자, 개발자, 여러 업체들과 함께 지속적으로 발전하고 있는지를 살펴봅니다.
이 문서는 최근 대두되는 개방형 혁신 연구개발 프로젝트를 위한 거버넌스 구축하기 위하여 필요한 요소를 알아봅니다. 다양한 핵심 산업에서 사실상의 표준으로 자리잡은 많은 오픈소스 프로젝트들을 중심으로 성공적인 오픈소스 프로젝트로 가능 여정에 어떤것이 필요한지 이야기합니다.
DEVOPS 전반적인 것에 대해서 소개를 한 자료입니다.
http://wiki.tunelinux.pe.kr/display/sysadmin/DEVOPS
https://groups.google.com/forum/#!topic/sysadminstudy/g4bM_xbZPC8
DevOps 시작
DevOps 정의
Dev vs Ops 충돌
DevOps 유래
참고자료
애자일 방법론
ITIL
린스타트업
린 생산방식
애자일을 OPS로 확장
DevOps 관점 : 측정지표 관점, 프로세스 관점, 기술 관점
DevOps가 아닌 것은?
DevOps 소개
프로젝트 세팅 : 전통적인 프로젝트 세팅, 애자일 프로세스 세팅
하나의 팀
핵심
가치와 목적
프로세스
도구
DevOps 구성하기
측정지표 : cycle time, 변경(change)
흐름 개선하기
배포 개선 및 가속화 : batch size 줄이고 더 자주 배포하여 cyclle time 줄이기.
못 다한 이야기 : Metrics and Measurement View / Process View / Technical View
Top 11 Things About DevOps
DevOps의 기초 원리 : 전체 시스템적인 사고, 피드백 루프를 확대하기, 지속적인 실헝과 학습
자동화 도구
이상적인 프로젝트란?
버전관리
티켓관리
지속적인 통합(CI)
지속적인 배포(CD)
프로비저닝 툴체인
OS설치
설정
오케스트레이션(배포)/워크플로우
이제 무엇을 할까?
나가면서
참고자료
ZUIX is a design system created by Zigbang's CTO team to standardize design across all of Zigbang's services. It uses React Native for responsive, multi-platform components and includes tools like Storybook for development and a design review infrastructure for validation. The deployment process involves code reviews, CI/CD pipelines, and publishing to a npm registry. Training and documentation is provided through tools like Google Classroom and Notion. The team aims to further develop ZUIX by improving the design review tools, adding end-to-end testing, and analyzing component usage. The goal is to solve Zigbang's unique challenges through an agile, collaborative approach between designers and developers.
왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항rockplace
[Microsoft Azure와 Red Hat OpenShift를 통한 비즈니스 스피드 업! 웨비나]
왜 컨테이너인가? - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려사항
락플레이스 구천모 상무
영상 다시보기 : https://youtu.be/i3yKrHLHYJI
디지털 시대에 기업들은 빠르게 변화하는 시장과 환경에 발 빠르게 대처하기 위하여 점점 조직을 작게 만들어 민첩성을 확보하고자 노력하고 있습니다. 이를 위한 기술의 하나로 '클라우드 네이티브'의 도입이 가속화 되고 있는데요, 이는 클라우드 컴퓨팅 모델의 장점을 모두 활용하여 애플리케이션을 개발하고 실행하기 위한 접근 방식을 일컫습니다. 아키텍처 관점에서는 분산을 통한 유연성 확보, 운영 관점에서는 애플리케이션도 분산시켜야 하는데요, 이를 위해서는 다양한 클라우드 환경에서 자유롭게 이식하기 위한 '컨테이너' 구현이 필수적입니다.
이준영 (현 소프트웨어인라이프 연구원)
OpenShfit와 CSB.IO
인프라 비용을 절감하고 애플리케이션 개발속도를 향상 시킬 수 있는 방안으로 PaaS와 레드햇의 오픈 소스 솔루션인 OpenShift에 대하여 설명한다.
그리고, CSB.IO와 OpenShift의 미래 모습에 대해서도 소개한다.
- The Cloud Life Seminar 2014 발표 내용
OpenStack과 업스트림 컨트리뷰션 (2016 IT 21 글로벌 컨퍼런스)Ian Choi
2010년 7월 Rackspace사와 NASA부터 시작된 OpenStack 프로젝트는 빠른 성장세를 거쳐 2016년 4월에는 13번째 릴리즈에 해당하는 Mitaka 버전이 등장하였습니다. OpenStack은 클라우드 관리 오픈 소스 소프트웨어로, 최근 User Survey에 따르면 약 2/3에 해당하는 클라우드 인프라에서 프로덕션 또는 실제 운용 목적으로 사용할 정도로 충분한 성숙도를 갖추고 있습니다. 이와 같이 OpenStack이 발전할 수 있었던 배경에는 사용자, 개발자, 여러 업체들이 주도적으로 참여할 수 있도록 이루어진 커뮤니티 및 생태계를 통한 지속적인 업스트림 컨트리뷰션이 있습니다. 최근 발표된 Mitaka를 살펴보면, 178개 국가에서 345개 조직에 속한 2,336명에 달하는 구성원이 350만 줄에 해당하는 코드를 기여하였으며, 지난 릴리즈와 비교하였을 때 8개의 신규 프로젝트가 추가되는 등의 컨트리뷰션이 있었습니다. 본 발표에서는 이와 같이 강력하고 지속적인 업스트림 컨트리뷰션을 주제로 하여 클라우드 관리 오픈 소스 소프트웨어인 Openstack이 어떤 식으로 사용자, 개발자, 여러 업체들과 함께 지속적으로 발전하고 있는지를 살펴봅니다.
이 문서는 최근 대두되는 개방형 혁신 연구개발 프로젝트를 위한 거버넌스 구축하기 위하여 필요한 요소를 알아봅니다. 다양한 핵심 산업에서 사실상의 표준으로 자리잡은 많은 오픈소스 프로젝트들을 중심으로 성공적인 오픈소스 프로젝트로 가능 여정에 어떤것이 필요한지 이야기합니다.
DEVOPS 전반적인 것에 대해서 소개를 한 자료입니다.
http://wiki.tunelinux.pe.kr/display/sysadmin/DEVOPS
https://groups.google.com/forum/#!topic/sysadminstudy/g4bM_xbZPC8
DevOps 시작
DevOps 정의
Dev vs Ops 충돌
DevOps 유래
참고자료
애자일 방법론
ITIL
린스타트업
린 생산방식
애자일을 OPS로 확장
DevOps 관점 : 측정지표 관점, 프로세스 관점, 기술 관점
DevOps가 아닌 것은?
DevOps 소개
프로젝트 세팅 : 전통적인 프로젝트 세팅, 애자일 프로세스 세팅
하나의 팀
핵심
가치와 목적
프로세스
도구
DevOps 구성하기
측정지표 : cycle time, 변경(change)
흐름 개선하기
배포 개선 및 가속화 : batch size 줄이고 더 자주 배포하여 cyclle time 줄이기.
못 다한 이야기 : Metrics and Measurement View / Process View / Technical View
Top 11 Things About DevOps
DevOps의 기초 원리 : 전체 시스템적인 사고, 피드백 루프를 확대하기, 지속적인 실헝과 학습
자동화 도구
이상적인 프로젝트란?
버전관리
티켓관리
지속적인 통합(CI)
지속적인 배포(CD)
프로비저닝 툴체인
OS설치
설정
오케스트레이션(배포)/워크플로우
이제 무엇을 할까?
나가면서
참고자료
ZUIX is a design system created by Zigbang's CTO team to standardize design across all of Zigbang's services. It uses React Native for responsive, multi-platform components and includes tools like Storybook for development and a design review infrastructure for validation. The deployment process involves code reviews, CI/CD pipelines, and publishing to a npm registry. Training and documentation is provided through tools like Google Classroom and Notion. The team aims to further develop ZUIX by improving the design review tools, adding end-to-end testing, and analyzing component usage. The goal is to solve Zigbang's unique challenges through an agile, collaborative approach between designers and developers.
This document discusses Kakao's search platform front-end project. It describes the architecture of an integrated search service using microservices and the need for a design system due to fragmented UIs. It introduces the KST (Kakao Search Template) project for creating a design system including 200+ UI blocks and templates. The KST Builder, Logger, and Dashboard are discussed for managing templates, logging usage, and monitoring coverage. Maintaining a consistent design system is important for operating diverse search services and platforms.
This document discusses Banksalad Product Language (BPL), which is a method used at Banksalad to standardize UI text, elements, and components. It allows designers and developers to use consistent terms, while abstracting UI elements to different levels suitable for their roles. Examples of standardized elements are provided, as well as external resources that discuss concepts like tree shaking that are relevant to BPL. While BPL has benefits, the document considers whether there may be better approaches than BPL.
This document summarizes a presentation about using Stitches, a React styling library, and Storybook for component design.
The presentation introduces Stitches as the styling library used for its support of React, easy usage, and themes. Key features of Stitches discussed include creating styled components, variants, and comparisons to other libraries.
Storybook is presented as a way to improve communication between designers and developers by allowing visualization of components alongside their stories. Clean communication through a shared Storybook is emphasized.
Reflections on initially creating a design system note the benefits of consistency and speed but also identify areas for improvement like documentation, process alignment, and understanding each other's roles. Establishing trust and understanding between
비행기 설계를 왜 통일 해야 할까?
디자인 시스템을 하는 이유
비행기들이 다 용도가 다르다...어떻게 설계하지?
맥락이 다른 페이지와 패턴
경유지까지 아직 멀었다... 언제 수리하지?
디자인 시스템을 적용하는 시점
엔지니어랑 얘기해서 정비해야하는데...어떻게 수리하지?
디자인 시스템을 적용하는 프로세스
비행기 설계가 바뀐걸 어떻게 알리지?
디자인 시스템의 전파
The document discusses Kotlin coroutines and how they can be used to write asynchronous code in a synchronous, sequential way. It explains what coroutines are, how they work internally using continuation-passing style (CPS) transformation and state machines, and compares them to callbacks. It also outlines some of the benefits of using coroutines, such as structured concurrency, light weight execution, built-in cancellation, and simplifying asynchronous code. Finally, it provides examples of how to use common coroutine builders like launch, async, and coroutineScope in a basic Android application with ViewModels.
This document contains the transcript from a presentation given by Wonsuk Lim from Naver on tips for debugging and analyzing Android applications. Some key tips discussed include fully utilizing the Android emulator's capabilities like 2-finger touch control, clipboard sharing between the emulator and host PC, and mocking locations. Advanced settings for the emulator like foldable and camera emulation are also covered. The presenter recommends ways to configure developer options and use tools like LeakCanary, the Android profiler, and Stetho for testing app stability. Methods for understanding the Android framework by reviewing system services and managers via AIDL files and logcat dumps are presented. Finally, reverse engineering tools like APK Extractor and decompilers are introduced.
2. 안녕하세요
201706 | KOSSLAB SEMINAR
NAVER 오픈소스 거버넌스를 담당하고 있습니다.
• NAVER가 오픈소스 SW를 올바르게 사용하고
• 오픈소스 생태계에 기여할 수 있도록
정책을 만들고 문화를 키우는
일을 하고 있습니다.
3. 오늘 발표에서는
201706 | KOSSLAB SEMINAR
NAVER 오픈소스 공개 경험을 공유합니다.
• OPEN – 오픈소스 프로젝트로 선정하는 기준은 무엇인지
• SHARE – 어떻게 오픈소스 프로젝트 공개를 준비하는지
• ENJOY – 공개 이후 어떻게 사용자들과 소통하는 지에 대해서
이야기를 나누려고 합니다.
Icons used for these slides are made by Madebyoliver from www.flaticon.com is licensed by CC 3.0 BY.
7. 네이버 전사에서 사용하는 Application Performance Management tool
시스템 복잡도가 높아지며 발생하는 문제를 해결하기 위해
대규모 분산 시스템의 성능을 분석하는 새로운 플랫폼 개발 후 공개
3,831 stars @ Github
Pinpoint
https://github.com/naver/pinpoint
201706 | KOSSLAB SEMINAR
8. UI 인터랙션, 이펙트, 유틸리티로 구성된 통합 Javascript 라이브러리
뿜, 샵윈도우, 쇼핑 검색, 스포츠 등의 네이버 서비스에 사용
egjs
https://github.com/naver/egjs
201706 | KOSSLAB SEMINAR
9. 대규모 서비스 운용에 필요한 고가용성, 확장성 요구사항을 구현한
Redis 기반 분산 저장 플랫폼
밴드, 카페 등의 네이버 서비스에 사용
nbase-arc
https://github.com/naver/nbase-arc
201706 | KOSSLAB SEMINAR
10. 오픈소스 차트 라이브러리인 C3의 forked project
네이버 내부 요구사항을 반영
billboard.js
https://github.com/naver/billboard.js
201706 | KOSSLAB SEMINAR
16. NAVER
Open Source
Criteria NAVER에서 잘 사용하고 있는 SW
- 우리가 만났던 문제와 해결책을 공유
- 우리가 잘 사용하고 있어야 남들도 잘 사용할 수 있을 것이라는 최소한의
qualification
- Maintainer가 업무와 프로젝트 운영의 balance를 맞추는 데 도움이 됨
201706 | KOSSLAB SEMINAR
17. NAVER
Open Source
Criteria nbase-arc
- Disk 기반의 클러스터 환경에서 많은 쓰기 부하를 일정 응답 속도로 처리
해야하는 요구 사항을 만족시키기 위해
- In-memory 기반의 scale-out 클러스터 DB를 새로이 개발해서 사용
- 2015년 오픈소스 프로젝트로 공개
201706 | KOSSLAB SEMINAR
nBase-ARC: Redis Cluster | 20140114 | http://d2.naver.com/helloworld/614607
18. NAVER
Open Source
Criteria 외부 개발자/사용자들에게 가치있는 SW
- 같은 문제를 가지고 있는 개발자들에게 도움이 되는 SW
- 사용자들이 적극적으로 참여할 수 있는 SW
- 오픈소스 프로젝트가 다양한 요구사항에 대응할 수 있는 원동력
201706 | KOSSLAB SEMINAR
19. NAVER
Open Source
Criteria billboard.js
- 널리 사용되고 있는 C3 라이브러리의 maintainance 부재
- 신규 요구사항을 적용한 forked project 운영
201706 | KOSSLAB SEMINAR
Why we decided to start billboard.js? | 20170609 |
https://github.com/naver/billboard.js/wiki/Why-we-decided-to-start-billboard.js%3F
21. NAVER
Open Source
Criteria Pinpoint
- 공개 후 외부 사용자들이 각자의 요구 사항에 필요한 feature를 개발
- 개발한 내용을 다시 Pinpoint에 contribution
201706 | KOSSLAB SEMINAR
Pinpoint enhancements | 20170214 |
https://groups.google.com/forum/#!topic/pinpoint_user/miqxcXd31AQ
23. NAVER
Open Source
Preparation Code Cleanup
- 네이버 내부 코드와 공개할 내용 분리
- 코드 내 주석 정리
- 내부 개발 정보가 포함되었는지 확인
- 필요 시 영문으로 번역
- Commit 메시지 정리
201706 | KOSSLAB SEMINAR
25. NAVER
Open Source
Preparation License check
- 직접 개발한 코드 이외의 내용에 대해 출처 및 라이선스 확인
- 외부로 나가는 모든 NAVER SW에 적용
- license conflict가 나지 않도록 배포 라이선스 결정
201706 | KOSSLAB SEMINAR
28. NAVER
Open Source
Preparation Open Notice
- 네이버 개발자 채널
- http://d2.naver.com
- https://www.facebook.com/naverengineering
- 같은 관심사를 가지고 있는 개발자 커뮤니티
- 개발자 뉴스 포탈
201706 | KOSSLAB SEMINAR
31. Beyond
NAVER
Open Source Communication
- 온라인
- Github Issues
- Google groups
- Mailing List
- Team Blog
- 오프라인
- Meetup / Hands-on
- Conference
201706 | KOSSLAB SEMINAR