* 혼자 공부하려고 만든 자료이기 때문에 정확하지 않는 내용이나 오류가 있을 수 있습니다. 잘못된 점은 언제든지 고쳐주시면 배우겠습니다.
* phpDocumentor란?
phpDocumentor는 제작한 프로젝트에 대해서 문서화 해주는 도구를 말한다. 공식 홈페이지에서는 'PHP에 대한 세계 표준 자동 문서 도구(phpDocumentor is the world standard auto-documentation tool for PHP.)'라고 설명하고 있다.
우선은 phpDocumentor가 왜 수면위로 떠오르게 되었는지에 대해서 짚고 넘어가야 할 것 같다. PHP는 본래 컴파일 없이 라인 단위로 처리하는 스크립트 언어이다. 아무래도 스크립트 언어는 라인별 처리라는 개념 덕분인지 진입장벽이 낮아 독학하기에 좋은 언어였다. 그로 인해 사용률이 많아지고 인기가 많아지는 동시에 스크립트 언어에 대한 약점에 대해서 생각하게 되었던 것 같다. PHP 5로 넘어가면서 본격적으로 객체에 대한 개념이 강화되고, 이를 이용한 다양한 프레임워크가 개발되고 있다. 스크립트 언어에 대한 약점을 컴파일 언어에서 그 해답을 찾고자 했던 것 같다.
컴파일 언어의 대표적인 사례인 JAVA에서는 이미 javadoc이라는 문서화 도구가 존재하고 있었다. 아마도 phpDocumentor는 javadoc의 php 버전이었으리라. 사용 방법도 javadoc과 크게 다르지 않다. php도 객체지향 개념이 나오면서 어떤 정형화된 패턴이 나오는 것이 가정해졌기 때문에 그 공통적인 부분을 문서를 만들 수 있게 되었다.
* 주석
주석은 자신을 포함하여 프로젝트에 참여하는 사람들에게 쉽게 알아볼 수 있도록 하는 역할을 해준다. 주석을 최소화하는 것을 장려하는 사람들도 있긴 하지만, 프로젝트가 커질 수록 작은 코드가 어떤 역할을 할 수 있는지 모를 수도 있다. 그때 작업자는 그 코드에 대해서 설명글을 달아줄 수 있다. 주석은 사람이 알아볼 수 있게 쓰는 일종이 메모의 역할을 한다.
* 마무리
phpDocumentor로 대단한 것을 할 수 있는 것은 아니다. 어쩌면 이 도구로 할 수 있는 것은 자료보관일 뿐일 것이다.
사실 Phpdoc이 많은 곳에서 쓰이고 있지는 않다. 대부분의 개발자들은 코드를 보면 쉽게 알 수 있을 것이라고 말하거나 귀찮아 한다. 그만큼 손도 많이 가고 굳이 해야 하나 싶기도 하는 작업이 바로 이 작업이다. 프로젝트가 개발자에 종속되는 것은 매우 좋지 않은 현상이며, 많은 개발자들이 수긍할 수 있는 코드가 좋은 프로젝트라고 생각한다. 그들이 쉽게 프로젝트의 유지보수에 투입되려면 한눈에 정리되어있는 문서가 필요한데 문서의 유지보수는 생각보다 어렵다. 그래서 이 도구가 문서를 작성하는 데에 중요한 역할을 하는 것이다.
* 혼자 공부하려고 만든 자료이기 때문에 정확하지 않는 내용이나 오류가 있을 수 있습니다. 잘못된 점은 언제든지 고쳐주시면 배우겠습니다.
* phpDocumentor란?
phpDocumentor는 제작한 프로젝트에 대해서 문서화 해주는 도구를 말한다. 공식 홈페이지에서는 'PHP에 대한 세계 표준 자동 문서 도구(phpDocumentor is the world standard auto-documentation tool for PHP.)'라고 설명하고 있다.
우선은 phpDocumentor가 왜 수면위로 떠오르게 되었는지에 대해서 짚고 넘어가야 할 것 같다. PHP는 본래 컴파일 없이 라인 단위로 처리하는 스크립트 언어이다. 아무래도 스크립트 언어는 라인별 처리라는 개념 덕분인지 진입장벽이 낮아 독학하기에 좋은 언어였다. 그로 인해 사용률이 많아지고 인기가 많아지는 동시에 스크립트 언어에 대한 약점에 대해서 생각하게 되었던 것 같다. PHP 5로 넘어가면서 본격적으로 객체에 대한 개념이 강화되고, 이를 이용한 다양한 프레임워크가 개발되고 있다. 스크립트 언어에 대한 약점을 컴파일 언어에서 그 해답을 찾고자 했던 것 같다.
컴파일 언어의 대표적인 사례인 JAVA에서는 이미 javadoc이라는 문서화 도구가 존재하고 있었다. 아마도 phpDocumentor는 javadoc의 php 버전이었으리라. 사용 방법도 javadoc과 크게 다르지 않다. php도 객체지향 개념이 나오면서 어떤 정형화된 패턴이 나오는 것이 가정해졌기 때문에 그 공통적인 부분을 문서를 만들 수 있게 되었다.
* 주석
주석은 자신을 포함하여 프로젝트에 참여하는 사람들에게 쉽게 알아볼 수 있도록 하는 역할을 해준다. 주석을 최소화하는 것을 장려하는 사람들도 있긴 하지만, 프로젝트가 커질 수록 작은 코드가 어떤 역할을 할 수 있는지 모를 수도 있다. 그때 작업자는 그 코드에 대해서 설명글을 달아줄 수 있다. 주석은 사람이 알아볼 수 있게 쓰는 일종이 메모의 역할을 한다.
* 마무리
phpDocumentor로 대단한 것을 할 수 있는 것은 아니다. 어쩌면 이 도구로 할 수 있는 것은 자료보관일 뿐일 것이다.
사실 Phpdoc이 많은 곳에서 쓰이고 있지는 않다. 대부분의 개발자들은 코드를 보면 쉽게 알 수 있을 것이라고 말하거나 귀찮아 한다. 그만큼 손도 많이 가고 굳이 해야 하나 싶기도 하는 작업이 바로 이 작업이다. 프로젝트가 개발자에 종속되는 것은 매우 좋지 않은 현상이며, 많은 개발자들이 수긍할 수 있는 코드가 좋은 프로젝트라고 생각한다. 그들이 쉽게 프로젝트의 유지보수에 투입되려면 한눈에 정리되어있는 문서가 필요한데 문서의 유지보수는 생각보다 어렵다. 그래서 이 도구가 문서를 작성하는 데에 중요한 역할을 하는 것이다.
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.sung ki choi
ajax 등장 이전부터, ajax, comet, 그리고 html5의 웹소켓까지 기술의 흐름을 간략하게 정리해 보았습니다.
웹 어플리케이션의 개발을 다뤄보지 않은 개발자들을 대상으로 처음부터 웹소켓을 다루기 전에,
1. 이전 세대의 통신 기법은 어떤 모양이었는지
2. 웹소켓이 왜 환영받을 만한 기술인지
... 등을 공감할 수 있기 위한 목적으로 PT를 작성 하였습니다.
MFC 발견 1주차 자료입니다.
GUI프로그래밍과 윈도우 프로그래밍 소개입니다.
MFC의 전신인 SDK(API)와의 비교, Qt 라이브러리 간단한 소개, 닷넷의 간단한 소개 등 MFC 외에도 다양한 GUI 및 윈도 프로그래밍 기술에 대해 소개를 합니다.
MFC와 SDK(API) 비교를 통해 MFC의 캡슐화된 개념을 알아봅니다. 또한 MFC가 왜 탄생을 하게 되었는지에 대해서도 소개를 합니다.
MFC의 소스코드들을 직접 찾아가보면서 어떻게 MFC가 구성되며 실행되는지에 대한 내용을 파해쳐봅니다.
전반적으로 MFC에 대한 진입장벽을 낮추어 주는데 초점을 맞추었습니다.
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.sung ki choi
ajax 등장 이전부터, ajax, comet, 그리고 html5의 웹소켓까지 기술의 흐름을 간략하게 정리해 보았습니다.
웹 어플리케이션의 개발을 다뤄보지 않은 개발자들을 대상으로 처음부터 웹소켓을 다루기 전에,
1. 이전 세대의 통신 기법은 어떤 모양이었는지
2. 웹소켓이 왜 환영받을 만한 기술인지
... 등을 공감할 수 있기 위한 목적으로 PT를 작성 하였습니다.
MFC 발견 1주차 자료입니다.
GUI프로그래밍과 윈도우 프로그래밍 소개입니다.
MFC의 전신인 SDK(API)와의 비교, Qt 라이브러리 간단한 소개, 닷넷의 간단한 소개 등 MFC 외에도 다양한 GUI 및 윈도 프로그래밍 기술에 대해 소개를 합니다.
MFC와 SDK(API) 비교를 통해 MFC의 캡슐화된 개념을 알아봅니다. 또한 MFC가 왜 탄생을 하게 되었는지에 대해서도 소개를 합니다.
MFC의 소스코드들을 직접 찾아가보면서 어떻게 MFC가 구성되며 실행되는지에 대한 내용을 파해쳐봅니다.
전반적으로 MFC에 대한 진입장벽을 낮추어 주는데 초점을 맞추었습니다.
Docker 와 Python 으로 아카마이 API 5분만에 사용해보기!Seung Heun Noh
아카마이는 최근 SOAP 기반의 API 를 버리고(?) REST 기반의 OPEN API 로 지속적인 변화를 꾀하고 있습니다. 보다 쉬운 API 테스트 및 활용을 지원하기 위해 Python 환경의 Docker Container 를 제공중인데요, 아카마이의 API 의 기본적인 컨텍스트와 Docker Container 를 통해 독립된 개발 환경을 활용하는 방법을 알아보도록 하겠습니다.
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS충섭 김
Confd, systemd, fleet을 이용한 어플리케이션 배포 in CoreOS
Docker Seoul Meetup #2에서 발표한 자료입니다.
CoreOS에서 confd와 sidekick service를 이용한 서비스 배포에 대한 내용입니다.
http://www.youtube.com/watch?v=5ixJCM6pAcg
영상과 함께 보시면 더 좋습니다 :)
2017년 12월 6일 W3C Conference에서 "Docker와 DevOps에서 Serverless와 NoOps로의 여정"라는 주제로 발표한 자료입니다.
데모로 시연한 샘플코드는 아래와 같습니다.
https://github.com/novemberde/serverless-webapp-demo
머신러닝 및 데이터 과학 연구자를 위한 python 기반 컨테이너 분산처리 플랫폼 설계 및 개발Jeongkyu Shin
머신러닝 및 데이터 과학 분야의 컴퓨팅 수요는 해가 갈수록 급증하고 있습니다. 이와 더불어 분산처리 기술, 데이터 파이프라이닝 및 개발 환경 스택 관리 등의 관련된 다양한 이슈들 또한 엄청나게 늘어나고 있습니다. 머신러닝 모델의 기하급수적인 모델 복잡도 증가 추세와 마찬가지로, 모델 학습을 위한 환경 관리 또한 갈수록 복잡도가 높아지는 추세입니다.
이 세션에서는 이러한 문제를 해결하기 위해 python 언어 기반의 분산처리 스케쥴링/오케스트레이션 미들웨어 플랫폼을 개발한 4년간의 과정에서 겪은 다양한 문제들에 대해 다룹니다. 2015년 컨테이너 기반의 고밀도 분산처리 플랫폼 설계 및 프로토타이핑 과정을 PyCon KR에서 발표한 이후, 실제 구현 및 오픈소스화, 안정화를 거치며 겪은 다양한 기술적/비기술적 문제들에 대한 경험을 공유합니다.
기술적으로는 최근 몇 년 간의 클러스터 플랫폼 관련 기술의 진보와 함께 탄생한 다양한 도구들과, 이러한 도구들을 python 기반으로 엮어내기 위해 사용하고 개발한 다양한 오픈소스들을 다룹니다. Python 기반의 컨테이너 스케쥴링 및 오케스트레이션 과정의 구현과, 다양한 프로그래밍 언어로 만든 SDK를 graphQL을 이용하여 연동하는 과정에서의 몇몇 유의점을 설명합니다. 아울러 python 기반의 SDK를 다양한 언어로 포팅했던 경험을 간단하게 안내합니다.
플랫폼을 개발하는 중 등장한 TensorFlow, PyTorch 등의 다양한 머신러닝 프레임워크들을 도입하며 겪은 문제와 해결 과정에 대해서도 나눕니다. 연구 분야에는 Python 2.7 기반의 프레임워크들이 여전히 많습니다. 이러한 프레임워크 및 라이브러리의 지원을 위하여 Python 2 기반의 프레임워크와 Python 3.7로 구현한 컨테이너 인터페이스를 단일 컨테이너 환경에 중복 빌드 및 상호 간섭 없이 공존시키기 위해 개발한 아이디어를 소개합니다.
마지막으로 Python 기반의 프레임워크를 개발, 배포 및 상용화 하는 과정에서 겪은 다양한 어려움을 소개합니다. 솔루션을 배포 및 보급할 때 겪는 다양한 런타임, 하드웨어 환경 및 개인 정보 보호를 위한 폐쇄망 대상의 디플로이 등에 대응하기 위하여 Python 응용프로그램을 단독 실행용으로 패키징하는 과정에서 겪은 팁들을 설명합니다. 또한 GUI 빌드 및 Python, Go 및 C++을 함께 사용한 드라이버 가상화 레이어 개발 등의 내용도 살짝 다룹니다.
이 슬라이드는 PyCon KR 2019의 발표 슬라이드입니다. ( https://www.pycon.kr/program/talk-detail?id=138 )
iOS App 개발 with React Native + ClojureScriptCheolhee Han
ClojureScript 와 React Native 를 이용하여, 사물인터넷 기기와 App의 프로토타입 개발한 결과를 시연합니다.
React Native 를 채택까지의 과정을 전개합니다.
왜 Clojure로 개발하는가? 대한 이야기.
소스 저장소
https://github.com/cheolhee/ReactNativeDuckie
이 발표는 [야생의 땅: 듀랑고]의 지형 배포 시스템과 생태계 시뮬레이션 자동화 시스템에 대한 이야기를 다룹니다. 듀랑고의 각 섬은 크기와 지형, 기후 조건이 다양하고 섬의 개수가 많아서 수동으로 관리하는 것은 사실상 불가능합니다. 몇번의 사내 테스트와 베타 테스트를 거치면서 이러한 문제를 해결해주는 자동화된 도구의 필요성이 절실해졌고, 작년에 NDC에서 발표했던 생태계 시뮬레이터와 Docker, 그리고 아마존 웹서비스(AWS)를 이용하여 수많은 섬들을 자동으로 생성하고 관리하는 자동화 시스템을 구축하게 되었습니다. 그 과정에서 했던 고민들, 기존의 애플리케이션을 "Dockerizing" 했던 경험, AWS의 각 서비스들을 적절히 활용했던 이야기, AWS의 각 지역별 요금이 상이하다는 점을 이용해서 비용을 절감한 사례, 그리고 자동화 시스템의 문제점과 앞으로의 방향에 대해서 이야기 할 계획입니다.