스크래치는 청소년들이 재미있게 프로그래밍을 익힐 수 있도록 고안된 프로그래밍 언어입니다. 일반적인 프로그래밍 언어와는 다르게 명령이 블럭으로 만들어져 있어서 마우스를 이용해서 프로그램을 만들게 됩니다. 특히 게임이나 애니메이션과 같은 것을 쉽게 만들 수 있도록 고안되어 있기 때문에 어렵지 않게 프로그래밍 기법들을 익힐 수 있습니다.
스크래치로 만든 게임
스크래치로 만든 게임입니다. 스크래치를 이용하면 이렇게 복잡한 게임도 만들 수 있습니다. 수업 시작하기 전에 게임 한판하고 시작하시죠!
서울 강남구 신아유치원은 올해 3월부터 만 4, 5세 아이들을 대상으로 코딩 교육을 하고 있다. 코딩은 컴퓨터 명령어를 조합해 소프트웨어를 만드는 것.
이 유치원이 코딩 교육을 도입한 건 지난해 7월 교육부와 미래창조과학부가 “2018년 중학교, 2019년 초등학교에서 소프트웨어(SW) 교육을 필수로 하겠다”고 발표해서다. 일부 학부모들은 이 발표 이후 “코딩 교육을 해야 하는 것 아니냐”고 물었다. 최경숙 원장은 “너무 이른 것 아니냐고 할 수도 있지만 모든 걸 잘 받아들이는 유아기 때 코딩을 경험해 본 아이와 그러지 못한 아이는 나중에 분명 다를 거라고 생각했다”고 말했다.
교육부와 미래부가 지난해 ‘SW 중심 사회를 위한 인재 양성 추진 계획’을 발표한 지 1년 만에 사교육 시장에서 코딩 교육 열풍이 불고 있다. 특히 정부가 “‘스크래치’ 같은 블록형 코딩 프로그램을 개발하겠다”고 밝혀 영유아 사교육 시장에서 게임형 코딩 교육이 유행이다. 스크래치는 미국 매사추세츠공과대(MIT)에서 2006년 개발한 아동용 코딩 프로그램으로 명령어가 적힌 블록을 끼워 맞추며 놀이하듯 즐길 수 있다.
신아유치원이 사용하는 코딩 프로그램 ‘키즈코딩’도 이와 유사한 것으로 지난달 외국어 교육 업체 YBM의 계열사로 편입된 유아 코딩 교육 프로그램 개발사 토이코드가 만들었다. 강남·서초구 등에 있는 24개 유치원과 어린이집에서 사용 중이다. 박웅 토이코드 연구소장은 “게임하듯 순차나 반복 같은 코딩의 기본 개념을 익힐 수 있다”며 “학부모들의 관심이 많아 내년에는 학습지 형태로도 출시할 예정이다”라고 말했다.
올해 서초구에는 유치원 및 초등학생 아이들을 대상으로 하는 코딩영재스쿨이 문을 열었다. 비용은 방과 후 과정을 제외하고 한 달에 135만 원. 학원 측은 “코딩 전문가가 컴퓨팅 사고력을 몸으로 체험할 수 있도록 가르친다”고 설명했다. 방학을 이용한 코딩 캠프 외에도 코딩을 가르치는 학원이 우후죽순으로 생기고 있다.
○ 시작도 늦었는데 제대로 될지 우려
전문가들은 코딩 공교육이 너무 늦어지고 있는 가운데 실시 방침만 발표하고 명확한 가이드라인이 없어서 사교육만 커지고 있다고 지적한다. 주요 선진국들은 이미 정규 교육과정에서 코딩 교육을 하고 있다. 이스라엘은 1994년, 영국은 2014년 9월, 프랑스와 핀란드는 올해부터 시작했다. 미국은 워싱턴 텍사스 켄터키 등에 있는 고교에서 제2외국어 대신 코딩을 선택한다.
유명인들도 코딩을 강조한다. 버락 오바마 미국 대통령은 2013년 말 “휴대전화를 갖고 놀지만 말고 직접 프로그램을 만들라”라고 강조했다. 스티브 잡스 애플 창업자도 생전에 “모든 사람은 코딩을 배워야 한다. 생각하는 방법을 알려 주기 때문이다”라고 말했다.
이들이 코딩을 강조하는 건 논리적 사고력과 문제 해결력을 키울 수 있어서다. 안성진 성균관대 컴퓨터교육과 교수(입학처장)는 “초중고교생 대상의 코딩은 대학생이 배우는 어려운 프로그래밍이 아니고, 복잡한 문제도 작은 단위로 잘라 해결 능력을 키우는 데 목적이 있다”라고 했다. 디지털 시대에는 전공을 불문하고 코딩이 제2의 공용어라는 이야기도 있다.
정부 발표에 따르면 2018년 중학교에서는 현재 선택인 정보 과목을 필수(34시간)로 지정하고, 고등학교는 기존처럼 선택으로 하되 코딩 교육과정을 보강한다. 2019년부터는 초교 5, 6학년 실과 시간에 SW 기초교육을 17시간 이상 실시한다.
학교에서 코딩 교육이 제대로 이뤄질 거라고 기대하는 학부모는 별로 없다. 가장 큰 문제는 가르칠 교사가 부족하다는 것. 중고교는 정보 과목 교사라도 있지만, 초교는 이런 인력이 없다. 교육부는 2018년까지 초등 교사의 30%(6만 명)에게 SW 직무교육을 실시할 계획이다.
그러나 교사들 사이에서는 “이런 것까지 배워야 하나”, “잘 모르겠다”는 인식이 있다. 한 학부모는 “전문 교사도 없고 교육 시간도 부족한 데다 컴퓨터와 통신망도 완벽히 갖춰져 있지 않으면 진도 나가기에만 급급해 암기 과목처럼 될 것 같다”고 말했다.
어도비가 10월23일 새로운 ‘어도비 포토샵 라이트룸 CC‘ 포토그래피 서비스를 출시했다. 새 라이트룸 CC는 클라우드 기반으로 접근성이 향상돼 앞으로 사용자는 언제, 어디서든 사진을 편집, 정리, 저장 및 공유할 수 있다.
새로운 라이트룸 CC는 포토샵 CC와 클래식 라이트룸 CC(구 라이트룸 CC)의 이미징 기술을 모두 적용했다. 사진 색감 및 밝기를 조절하는 슬라이더는 사용이 보다 쉬워졌고 프리셋, 빠른 수정 도구도 좀더 간편해졌다.
모바일, 데스크톱 그리고 웹상에서 풀 해상도 화질로 편집할 수 있다. 사용자가 한 기기에서 사진을 편집하면 라이트룸 CC에 연결된 모든 기기 및 온라인상에서 변경사항이 자동 적용된다. 사진 공유도 가능하다. 또 확장 가능한 클라우드 스토리지를 제공해 모든 해상도 사진 백업을 지원한다.
인공지능으로 사진 정리 돕는다
어도비의 이미지 처리 인공지능, ‘어도비 센세이’의 활용도도 높아졌다. 원하는 키워드를 검색하면 사진에 있는 사물이 무엇인지 파악해 알아서 검색해준다. 원래 태그를 달아 검색이 가능했지만 센세이가 자동으로 태그를 달아주기 때문에 사진 정리가 한층 편해졌다. 예를 들어 풍경 사진을 찍었을 때 ‘공원’이나 ‘하늘’ 등으로 검색하면 관련 사진을 다 찾아볼 수 있다.
소셜 미디어 공유도 가능하다. 트위터, 페이스북, 어도비 디자이너 커뮤니티 비핸스 등과 라이트룸 CC와 새롭게 통합된 어도비 포트폴리오에 사진을 공유할 수 있다.
모바일·웹 업데이트하고 데스크톱 기능은 보강
iOS 및 안드로이드 라이트룸 앱도 업데이트됐다. 웹용 라이트룸 CC는 어도비 포트폴리오와의 연계가 향상돼 몇 번의 클릭만으로 사진을 개인 포트폴리오에 게시할 수 있게 됐다. 또 어도비 포토샵 라이트룸 클래식 CC는 데스크톱 중심 워크플로우에 초점을 맞춰 업데이트됐다.
새로운 라이트룸 CC 플랜은 새로운 라이트룸 CC 플랜(월 1만1천원), 크리에이티브 클라우드 포토그래피 플랜(월 1만1천원), 1TB 크리에이티브 클라우드 포토그래피 플랜(월 2만3100원) 중 선택할 수 있으며 100GB를 사용할 수 있는 라이트룸 모바일 플랜은 iOS에서 월 5.49달러, 안드로이드에서는 월 5500원에 이용 가능하다.
업계에 처음 발을 들여놓는 젊은 개발자들은 한꺼번에 많은 원칙과 개념에 대한 이야기를 듣게 된다. 관리자로 올라서는 경력 개발자는 그동안 피해 왔지만, 기술적인 측면에 폭넓은 영향을 미치는 비즈니스 개념에 대한 이야기를 듣게 된다.
다음은 지난 20년 동안 소프트웨어, 그리고 소프트웨어 비즈니스에 있어 가장 중요한 12가지 개념이다.
1. 권한 없는 책임
경력이 어느 정도 된다면 권한 없는 책임을 접해봤을 것이다.
극단적인 사례를 들면 경비원에게 분기별 수익 책임을 지우는 것이다. 경비원이 아무리 노력해도 회사의 수익성을 높일 수는 없다. 경비원이 영업 회의에 참석한다 해도 신참 영업 사원이 전화를 더 많이 걸도록 유도할 수는 없다. 영업 사원을 움직일 영향력이 없기 때문이다. 마케팅 회의에 참석해봤자 마케팅 부서에서 새로운 캠페인을 구상하도록 이끌 수도 없다.
물론 극단적인 예다. 그러나 짊어지는 책임과 실제 행사할 수 있는 영향력 사이의 격차는 그 정도가 얼만큼이든 스트레스의 원천이다. 권한 없는 책임은 조직적인 기능 장애를 나타내는 징후이며(모든 조직에 어느 정도는 있음), 해결책은 권한을 높이거나 책임을 낮추는 것밖에 없다.
2. 반복하지 말 것
“반복하지 말 것” 원칙은 시스템에서 표현은 명확하게, 한 번만 해야 한다는 것이다. 코드 한 블록을 잘라내서 여러 곳에 붙여 넣을 경우 그 설계에는 결함이 발생한다. 그 결함을 가장 먼저 수정해야 한다.
이 원칙을 위반할 경우 시간을 낭비할 뿐만 아니라 유지보수 문제도 발생한다. 여러 지점에서 잘라내서 붙여넣기한 버그를 모두 찾아 수정해야 한다. 또한 보안 결함이 복제되는 경우를 상상해 보라.
이 문제를 수정하는 방법은 전체 아키텍처를 수정하는 것부터 코드 생성기, 종속성 주입에 이르기까지 많지만 어떤 방법을 사용하든 일단 수정해야 한다!
3. 필요할 일이 없다
앞으로 필요할 것 같아서가 아니라, 지금 필요한 기능을 구현하라. 앞으로 필요할 것 같다면 십중팔구 필요할 일이 없다. 나중에 정말 필요해지면 그때 가서 넣으면 된다.
모듈을 설계하면서 그 모듈이 이번 릴리스와 앞으로의 릴리스에서 해야 할 모든 작업을 미리 생각하고 반영하려 한다면 앞으로 일어나지 않을지도 모르는 기능까지 지원하는 쓸데없이 복잡한 소프트웨어를 만들게 된다.
미래를 예측하는 것보다 현실을 이해하는 편이 훨씬 더 정확하다. 현재에 집중하라.
4. 최소 실행 가능 제품
새로운 무언가를 만들 때 최선은 *할 수 있는* 모든 일을 시원찮게 하는 것보다 정말 잘 할 수 있는 최소한의 일을 하도록 하는 것이다. 이것을 최소 실행 가능 제품(Minimum Viable Product, MVP)이라고 한다.
MVP를 하면 사용자나 고객에게 유용성을 시연하기가 더 쉬워진다. 또한 잘못될 경우 고쳐야 할 부분도 더 적고 실패할 경우 잃을 투자도 더 적다.
5. 좁고 깊게
이 개념은 MVP와 관련된다. 모든 사람에게 모든 것을 줄 수는 없다.
제품이나 기업이 더 많은 일을 하려고 노력할수록 잘 할 수 있는 가능성은 낮아지고 비용과 복잡성은 높아진다. 넓고 얕은 것은 바람직하지 않다.
집중의 문제다. 규모가 큰 조직이나 성숙한 소프트웨어는 “플랫폼”과 사업부를 만들어 더 많은 리소스를 적용할 수 있지만 작은 회사는 한꺼번에 너무 많은 것을 하면 안 된다.
그러나 대규모 조직에도 “좁고 깊게” 원칙은 필요하다. 조직 또는 플랫폼의 각 부분에 대한 원칙으로 두어야 한다. 개별적인 폭이 모여 넓게 될 수는 있지만 각각의 요소는 깊어야 한다.
6a. 최소 비용(운영의 탁월성)
6b. 최고의 제품(제품 리더십)
6c. 최고의 토털 솔루션(고객 친밀성)
“최고의” 또는 가장 효과적인 조직은 이 세 가지 전략 중 하나를 추구하는 조직이다. 결과적으로 이러한 조직은 가장 비용이 낮은 조직, 최고의 조직, 또는 최고의 서비스를 제공하는 조직이다.
가장 낮은 비용에 초점을 맞출 경우 그 분야에서 최고의 제품이 될 수 있는 최신 기능 일부를 구현하지 못하게 된다.
최고의 서비스(고객 친밀)를 제공하는 데 초점을 맞출 경우 일반적으로 제품이 여러 방향으로 분산되어 각 고객에 따라 대폭 맞춤 제작된다. 이 경우 혁신과 사용 편의성 측면에서 대가를 치르게 된다.
이 목표 중 규모의 확장이 용이한 것은 두 개뿐이다. 가장 낮은 비용 또는 최고의 제품이다. 원하는 검색 결과를 얻지 못할 때 구글 고객 서비스에 전화를 걸 수 없는 이유가 여기에 있다.
7. 테스트 먼저
현대 IDE에서는 테스트를 가장 먼저 해야 한다. 이는 단위 테스트를 먼저 작성한 다음 여기서 클래스 등을 생성해야 함을 의미한다. 결과적으로 테스트가 용이한 소프트웨어가 되므로 더 높은 품질의 소프트웨어가 만들어진다. 또한 계약에 의한 설계와 같은 다른 설계 원칙을 따르도록 유도하는 효과도 있다.
8. 계약에 의한 설계
각 루틴에 대해 그 루틴이 어떤 작업을 하고 그 작업을 위해 무엇이 필요한지를 알아야 한다. 방법은 계약에 의한 설계(Design by Contract)다. 여기서 계약은 소프트웨어의 각 요소를 위한 형식적이고 간결하며 확인 가능한 인터페이스 사양을 말한다. 이 접근 방법을 사용하면 부작용, 전역 변수 및 기타 여러 가지 잘못된 것들을 피할 수 있다.
9. 경합 조건에 주의
일반적으로 경합 조건은 계약에 의한 설계의 다중 쓰레드 위반을 의미한다.
가장 단순한 형태로 보자. 두 개의 쓰레드가 동일한 변수를 변경할 때 한 쓰레드가 먼저 한다면 문제 없다. 그러나 두 번째 쓰레드가 변수를 먼저 변경하는 경우 오류가 발생하고 이것이 경합 조건이다.
이러한 종류의 설계 결함을 탐지하는 것이 불가능할 때도 있다. 간헐적이며 부하가 큰 경우에만 발생하는 경우가 많으므로 단위 테스트로 포착할 수 없다. 고도의 방어적 설계와 쓰레드 간 협업을 피하는 것이 경합 조건을 방지하기 위한 좋은 방법이다. 그러나 메시징 및 이벤트 지향 소프트웨어에서도 다른 버전의 경합 조건이 발생할 가능성은 있다(다만 확률이 낮을 뿐임). 동시성은 어렵다.
10. 콘웨이의 법칙
콘웨이의 법칙(Conway's Law)이란 팀의 커뮤니케이션 구조를 반영하는 소프트웨어를 개발할 수밖에 없다는 법칙이다. 바꿔 말하면 팀의 근본적인 구조를 바꾸지 않고서는(바꾸기는 무척 어려움) 소프트웨어의 근본적인 구조를 바꿀 수 없다.
11. 빠른 실패
“빠른 실패(Fail Fast)” 원칙은 실리콘 밸리에서 인기 있지만 어디에 적용해도 좋다. 기본적인 개념은 오류가 발생할 경우 소프트웨어는 대놓고, 거침없이 그 오류를 드러내야 한다는 것이다.
아마추어 프로그래머는 모든 변수에서 null을 확인하고, null이 될 수 없는 경우에도 이를 0이나 빈 문자열 등으로 대체한다. 그런 다음 불가능하고 잘못된 상황이 발생했는데도 코드를 계속 실행시킨다. 최고의 개발자는 소프트웨어가 null 포인터 예외를 뱉거나 실제 오류 자체를 내뱉도록 한다.
프로젝트 관리에서 빠른 실패란 존재할 수 있는 정치적 또는 기술적 장벽을 최대한 조기에 찾아내는 것을 의미한다.
비즈니스에서 빠른 실패란 궁극적인 실패를 향해 또는 이른바 ‘라면 수익’을 향해 천천히 투자하기보다 상품이나 비즈니스를 입증하거나 반증하는 대담한 계획을 추진하는 것을 의미한다.
12. 맨먼스 미신
프로젝트 종반에 인력을 추가하면 프로젝트는 더 늦어진다. 고전 ‘맨먼스 미신(The Mythical Man-Month)’은 40년도 넘은 과거의 책임에도 오늘날 소프트웨어 엔지니어링의 많은 오류를 설명한다.
이 용어는 “언제 끝나요?”라는 질문에 냉소적으로 답하는 데도 사용된다. 내 일정은 나도 모른다. 다른 일이 없었다면 신비한 3인일(man-days) 내에 이미 마쳤겠지만, 회의가 6번 더 남았고 그 회의에서도 누군가는 똑 같은 질문을 던질 것이다.
8. 역시, 외부 라이브러리!상용 or 오픈소스? 상용 → 결국 비용의 문제 라이센스 비용 부담 (ex. Highcharts 10 developer $3,320) 오픈소스 → 어떤 라이브러를 사용할 것인가? 결정의 어려움 (많은 고려요소 필요)
9. 다양한 차트 라이브러리어떤 것을 선택할 것인가? [참고] https://bestof.js.org/tags/chart
10. 기술 선택 가이드 성능 중요(빠른 대용량 데이터 처리), 상대적으로 디자인은 덜 중요한 경우 → Canvas (비트맵) 디자인 및 요소별 커스터마이징, 다양한 해상도(Zoom) 중요 → SVG (벡터) [참고] SVG 대 캔버스: 선택 방법
11. 영역별 다른 관점, 디자인 보단 실시간 변화 표현 중요 대용량 트래픽의 실시간(realtime) 변화 확인 수치의 변화가 중요. 기본 디자인 사용에 문제 없음 관리도구 등에 적합. 소수의 참여자(admin)
12. 영역별 다른 관점, 엔드 유저대상, 다양한 디자인/UX 중요 주로 정적인 데이터의 시각화 디자인과 UX 적용의 유연성 필요 대규모의 불특정 사용자(엔드유저)를 대상
13. 그간 네이버에서의 차트서비스들마다 다른 라이브러리를 사용 그리고 그로 인한 다양한 문제
14. 문제들 기술적 know-how 축적 안됨 상용 라이브러리 사용시 비용 문제 경험이 누적되지 않아 차트 적용(디자인/개발)시, 매번 반복되는 리소스의 낭비
15. 물론, 처음엔 자체 개발 그러나, 성공적이진 못했다. 서비스 적용 이후, 메인터넌스 잘 안됨 개발 주체의 부재상황(이직 등) 또는 다른 서비스 개발 등으로 인한 지원 어려움 타 라이브러리 대비 범용성 부족
16. 그렇다면 오픈소스 사용은 어떨까? 지속적 업데이트, 기술적 트렌드 반영, 안정성 등을 기대할 수 있으니 합리적이지 않을까? 향후 오픈소스 업데이트 지속되지 않을 경우, fork를 통한 유지 고려도 가능 공통된 라이브러리를 사용하면, 각각 다른 라이브러리 사용으로 인한 관리 및 기술경험 누적되지 않는 이슈 해결 기대 [참고] 그간 사용되었던 다양한 차트 라이브러리들: , , , , , etc.NVD3 C3.js Chart.js Highcharts echarts
17. 직접 개발도 해봤고, 외부(상용/오픈)의 것도 사용해 봤으니 간접적인 형태로 접근해 보자 라이브러리의 발전은 생태계에 맡기자. 필요한 기능은 PR을 통해 해결 오픈소스는 일정 수준 검증 되었다. 다양한 문서, practice가 존재한다.
18. 그래서, 만들다. C3.JS 확장 라이브러리 개발
19. C3.JS 선정이유 가장 인기있는 D3.js 기반 한정 Popularity 비교: → GitHub star, 써드파티 앱, StackOverflow 질문 수, etc. 간결한 인터페이스 풍부한 문서, 예제 등 → 구글검색 결과: C3.js(22만) Vs. NVD3(6만4천) 네이버 서비스들에서 이미 다수에서 사용 엔드 유저 대상이므로, 디자인/기능 커스터마이징 용이성 중요
20. 개발 시작 고난의 시작
21. 개발시 겪게 되는 문제들 커뮤니케이션 디자인 & 인터렉션 커스터마이징 그리고 또 그리고 수많은...
22. 커뮤니케이션나의 이름은 무엇 인가요? 차트 개발 경험이 많이 없는 경우, 부르는 명칭도 제각각
23. 디자인 가이드 각 요소들의 크기와 위치를 가이드에 맞춰주세요.
24. OMG! SVG TEXT I'm SVG text 텍스트 스타일링은 가능 <br> 같은거 안됨. 줄바꿈은 새로운 노드로 위치(via attributes) 여백 등의 조정이 어려움 → transform:translate 또는 <tspan> 사용
25. 모바일 환경 C3.js는 모바일 환경 미지원 Swipe 제스처를 통한 데이터 확인 UX 필요
27. 최소값y축 기반 값에 따른 up/down 표현 0 1 2 3 4 100,000 100,500 101,000 101,500 102,000 102,500 103,000 103,500 104,000 0 1 2 3 4 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 90,000 100,000 110,000 위의 차트는 모두 동일한 값을 표현하고 있습니다.
28. 데이터는 없지만, 데이터는 표현해야 한다? 데이터가 0인 경우, 표현이 되어야 할까? 안되어야 할까?
29. C3+ C3.JS 확장 라이브러리를 만들다.
30. C3+? C3.js를 확장한 테마 형태의 디자인 차트 생성 C3.JS: 확장 + 기능 보완 + 테마 커스텀 축 지원 범례 템플릿 모바일 지원 테마를 통한 차트 생성 확장 옵션
31. 블로그/포스트 통계 적용[네이버 블로그] 블로그 통계가 새로워졌습니다! [네이버 포스트] 훨씬 좋아진 통계, 지금 제공합니다!
32. C3+ GOAL 매번 다른 기술/라이브러리를 다루는 반복적인 비용 제거 기본적 디자인(테마)을 활용해 커스터마이징(디자인)에 따른 비용 제거 기술적 경험 축적: SVG, D3, C3.js
33. BUT, 현실적 문제직면 장기적 관점에서, C3+ 발전을 위해 외부 공개 목표 하지만, 래퍼/애드온 형태의 지속적 발전과 효용성 의문 기반 라이브러리인 C3.js 지속성 의문 오픈소스의 발전에 기댈 수 있을 것이란 기대는 C3.js의 더딘 발전(또는 중단?)으로 위기 직면
34. Re-usable, easy interface JavaScript chart library based on D3 v4+
35. 차트를 만들어 봅시다.
36. STEP 1 파일을 로딩 합니다.<!-- D3.js를 로딩 --> <script src="https://d3js.org/d3.v4.min.js"></script> <!-- billboard.js와 기본 스타일을 로딩 --> <script src="billboard.js"></script> <link rel="stylesheet" href="billboard.css">
37. STEP 2 차트가 노출될 영역을 설정합니다. <div id="chart"></div>
40. 커스터마이징150개 이상의 제공 SVG 노드: 필요한 경우, 직접 핸들링 가능 CSS로 스타일링 가능 다양한 옵션
41. THE UNKNOWN WAY TO FORK에서 공개까지
42. C3.JS 프로젝트 참여 시도원 개발자 및 커미터에게 메일을 통한 문의
43. 일단 활동하자PR도 보내고 이슈들에 대한 답변도 하고 [참고] https://github.com/c3js/c3/issues/1924#issuecomment-271224192
44. 그렇게 몇 주가 흘렀지만 메일 회신도 없고, 프로젝트 ACTIVITY도 딱히 없는 상태...
45. 공개적 문의issue를 등록해 공개적으로 프로젝트 유지 문의 [참고] https://github.com/c3js/c3/issues/1965
46. 그리고, 그 다음날
47. 그래, FORK 하자'향후 오픈소스의 업데이트 지속 안될 경우, fork를 통한 유지'의 명제 당면한 C3.js의 미해결 과제들: D3 최신버전 v4+ 미지원 모바일 환경에 대한 지원 부족 오래된 개발 스타일 코드 (ES3) SVG polyfill 제거 등등...
48. 합리성, 당위성 & 신뢰 Fork 한다고 해서 사용자가 오진 않는다. 기존 커뮤니티에 당위성이 제시 필요 과연 이 사람(개발자)이 믿을만 한가?
49. THE JOURNEY GOING FROM D3 V3 TO V4 WITHIN TWO MONTHS
50. OOPS~, D3 V4v3 → v4: Breaking Changes 공식 문서( ) 있으나, 마이그레이션 가이드 없고 만들지 않을거임. Changes in D3 4.0 [참고] https://github.com/d3/d3/issues/2893 D3 V4 - What's new?
51. D3 V4로 업그레이드변경된 모듈에 대한 목록을 모두 작성 v3 v4 d3.time.scale d3.scaleTime d3.svg.line() d3.line d3.behavior.drag d3.drag ... 모듈의 behavior 변경되어, 기존과 유사한 것도 있지만 다르게 처리되는 것들이 대다수 이전 버전과 변경된 문서를 읽고 비교하고, 테스트 하고...
52. 그외 작업들 차트 생성 흐름에 따른 오류들의 순차적 해결/변환 ES3 → ES6로 전환 병행 및 개발 환경 변경 API 문서화 ( ) 테스트 코드 업데이트(d3 v4 호환) 및 커버리지 개선 JSDoc
53. RELEASE 3주전 YAY~!, 이제 끝이 보인다.
54. 어느 날, 갑자기 두둥~ 갑작스러운 C3.js 차기 릴리즈 계획과 새로운 커미터 추가 [참고] https://github.com/c3js/c3/issues/2033
55. 고민이미 많은 진전을 통해 릴리즈를 앞둔상황 계획만을 통한 발전에 대한 의문 커미터 추가 후에도 활발한 활동 없어, 빠른 시일 내 D3 v4 지원 어렵다는 판단 계획대로 릴리즈 하자.
56. 오픈소스 네이밍원래는 C3+ 2.0으로 계획, 그러나 C3.js 연관성의 부정적 의견 'billboard'는 음악 차트 의미는 다르지만 '차트'를 연관 오랫동안 친숙한 이름 FE 프로젝트에서는 기 등록된 npm 모듈명 확인 필요 [참고] Open Source Project Name Checker
57. RELEASE!2017년 6월8일, v1.0.0 공개
58. 그러나, 공개한다고 갑자기 관심과 사용자가 몰려오진 않는다. 홍보전략 필요
59. 직접 발로뛰기 다수의 'ECHO' 사이트에 등록하기 JavaScript Live Echo JS Hacker News 많은 곳에서 해당 사이트에 등록된 정보를 활용, 재전파 한다.
60. 뉴스레터 소개 요청하기 JavaScript Weekly [참고] FE 관련 뉴스레터는 사실, 한 곳에서 발행 https://cooperpress.com/
61. 유력 매체 소개 JavaScript Weekly 소개 JavaScript Daily 소개
62. GITHUB TRENDING!JavaScript 언어부문 3위 기록 [참고] https://github.com/trending/javascript
63. GITHUB STAR 공개 후, 첫 6일간 700개 14일 후, 1,000개 도달! Star의 가치는? cdnjs 등록은 최소 200개 요구됨 Vuejs도 첫 6일간 615개 How I Got From 0 to 1 000 Stars on GitHub in Three Months
71. 신규 옵션들과 문서 C3+ 경험들을 통한 신규 옵션 꾸준한 문서 업데이트 API는 한번 작성되면 끝이 아니다. 정확한 의미와 동작을 기술 그리고 지속적 업데이트
72. 오픈소스의 중요한 요소들 안정성, 충분한 문서 그리고 책임감 [참고] http://opensourcesurvey.org/2017/
73. 오픈소스의 어려움누군가의 노력이 대가없이 제공되는 것. 그러나, 쉽게 비난 받기도 한다. https://twitter.com/spf13/status/907403135592878080
74. 의연하게 대처하기 You shouldn’t let strangers on the internet negatively affect your mood or your drive ... The trolls feed on your annoyance and discourse. ― Sindre Sorhus [참고] Between the Wires: An interview with open source developer Sindre Sorhus 1,139 npm Packages
75. WHY DO OPEN SOURCE? 세상에서 내가 도움 받은 것에 대해 다시 기여하는 의미있고 가치있는 행동 [참고] 네이버 오픈소스 가이드 GitHub Open Source Guides
76. SPECIAL THANKSMASAYUKI TANAKA AND ALL OF THE C3.JS CONTRIBUTORS, FOR YOUR GREAT EFFORTS AND WORKS TO THE COMMUNITY!
