컴퓨터 vs 책

토요일, 10월 15, 2016

[B급 프로그래머] 10월 2주 소식 정리

(오늘의 짤방) 중간에 건물 안 보이는 분? (via @Remini_scence)

(보너스 짤방) 프로그래머 3 유형 (via @InfoQ)

토요일, 10월 08, 2016

[독서광] 마스터 알고리즘

가을은 독서의 계절이라고 하지만 여전히 더워서 독서량을 늘이지 못하고 있다. 반성하면서 머신러닝 관련 서적 몇 권을 소개드리려 한다. 오늘은 1번 타자인 '마스터 알고리즘'이다.

알파고 사건 이후 요즘 여기저기서 인공지능과 머신러닝이 열풍을 불러일으키고 있다. 며칠 전에 KSC 2016 튜토리얼에 참석했는데, 많은 개발자들이 텐서플로우를 사용한 머신러닝 기법을 열공하는 모습을 보면서 머신러닝이 더 이상 흑마법을 부리는 신기술이 아니라 일반화된 문제 해법의 영역으로 접어들고 있다는 생각이 들었다. 하지만 머신러닝을 제대로 활용하려면 난관이 한두개가 아니다. 가장 먼서 머신러닝에 대한 일반적인 지식을 갖춰야 한다. 다음으로 (프로그램만 잘하면 되므로 불필요하다고 말하는 사람도 있긴 하지만...) 선형대수, 미분, 통계(특히 조건부 확률) 부문에 대한 기초 지식이 필요하다. 그 다음으로 파이썬이나 자바와 같은 프로그래밍 언어 지식이 필요하며, 텐서플로우나 카페와 같은 머신러닝 프레임워크에 대한 지식이 필요하다. 이 모든 조건을 갖췄다고 완성되는 것이 아니다. T_T 엄청나게 노동집약적인 노력을 투입해 학습시킬 데이터를 만들어야 한다(보통 이 부분을 간과하는데, 한 때는 아마존의 mechanical turk 파워의 50% 이상을 이미지넷을 위한 영상 분류에 투입했다는 일화를 기억하기 바란다). '마스터 알고리즘'은 가장 첫 단계인 머신러닝에 대한 일반적인 지식을 소개한다.

마스터 알고리즘이라는 단어가 특이한데, 저자에 따르면 마스터 알고리즘의 정의는 다음과 같다.

세상의 모든 지식, 즉 과거, 현재, 미래의 모든 지식은 단 하나의 보편적 학습 알고리즘으로 데이터에서 얻어낼 수 있다. 나는 이 머신러닝을 마스터 알고리즘(master algorithm)이라 부른다.

즉, 맥락에 맞춰 알고리즘을 매번 새로 개발하는 대신 데이터와 정보만 넣으면 우리가 원하는 통찰을 얻을 수 있는 어떤 절대적이고 궁극적인 알고리즘을 개발한다면 궁극적인 프로그램의 완성을 볼 수 있다고 주장한다. 물론 아직까지는 일부 분야에서만 성공을 거두고 있으며, 정말로 보편타당한 수준에 이를 수 있을지는 여전히 의문이기는 하다.

이 책은 머신러닝 실현을 위한 여러 가지 방법을 기호주의자, 연결주의자, 진화주의자, 베이즈주의자, 유추주의자라는 다섯 종족으로 나눠 설명하고 최종적으로는 이를 통합해 마스터 알고리즘으로 만드는 가능성에 대해 소개한다. The Programs That Become the Programmers에 소개된 그림 한 장이 이 책의 주제를 아주 잘 드러낸다.

각 종족별로 출발점, 기반 이론, 발전해온 경로를 다루며 장단점에 대해 짚어주기 때문에 현재까지 연구된 여러 가지 머신러닝 기법을 비교해가면서 익힐 수 있는 장점이 있다. 수식은 거의 나오지 않으며(베이지안은 예외다!), 코드도 없기 때문에 이 책을 읽고서 수학적인 관점에서 머신러닝을 이해한다거나 프로그램을 바로 만들 수 있으리라 기대해서는 곤란하겠다. (구체적인 사안을 이해하려면 다음 번에 소개하는 책을 읽어야 한다.)

책에서 다루는 내용을 맛보려면 다음 영상을 보면 되겠다. 영어 자막도 있으므로 천천히 시청하면 책에서 어떤 내용을 다루는지 감이 올 것이다.

그리고 보너스로 Quora에서 머신러닝을 어떻게 적용하는지 소개하는 자료도 올려드리겠다. 이 책을 읽고서 다음 자료를 읽어보면 머신러닝에 대해 한층 이해도가 높아진 자신을 발견할 것이다. :)

10 more lessons learned from building Machine Learning systems from Xavier Amatriain

결론: 머신러닝에 대한 기초를 쌓고 싶다면 이 책을 읽어보면 되겠다. 하지만 번역상태가 좋지 않고(중간중간 오역도 보인다), 추상적인 내용이 많아서 읽기가 쉽지는 않을 것이다.

EOB

토요일, 10월 01, 2016

[B급 프로그래머] 9월 4주 소식 정리

오늘의 짤방: IT 관계자(특히 시스템 관리자)의 비애 (via @pigori)

애독자 여러분들을 위해, 연휴 기간 동안 충분할만큼 읽을거리를 넉넉하게 챙겨드리겠다.

(마무리 그림: Today’s Venn Diagram. Programming != Computer Science via @jsshauma)

토요일, 9월 17, 2016

[독서광] 관저의 100시간: 후쿠시마 원전 사고, 재난에 대처하는 컨트롤 타워의 실상을 파헤친다

작년에 구입해놓고 차일피일 미루다 이번에 지진을 직접 느끼고 나서 갑자기 후다다닥 읽어버린 '관저의 100시간'에 대해 정리해보았다. 우선 이 책의 가장 큰 특징은 프롤로그에 너무나도 잘 드러난다.

논평과 추측은 배제했다. 나는 오로지 팩트로 말하겠다.

저자가 취재 도중에 상당히 열 받았으리라고 추측이 가능한 부분이 많았지만 잘도 참았다는 생각이 들었다. 가장 마지막 나오는 후주에는 누가 어떤 경위로 언급했는지 빽빽하게 적혀 있었고, 도쿄 전력 쪽에서 소송을 걸 경우를 대비해 반론이 있을 경우 취재원을 공개할 용의가 있다는 문구가 여러 차례 나왔다. 다양한 채널로부터 압력이 들어왔을 것 같다. 한국 같으면 이런 책이 나올 수 없지 않을까 하는 생각이 들었다.

이 책은 부제에서 잘 표현하듯이, 후쿠시마 원전 사고를 수습하기 위한 관가의 움직임을 중심으로 어떤 일이 있었는지를 상세하게 소개한다. 한국이야 "청와대는 재난 컨트롤 타워가 아니다"라는 공식 입장 표명이 있었기 때문에 어떨지 모르겠는데, 일본의 경우에는 후쿠시마 원전 사고가 발생했을 때 총리 관저에 컨트롤 타워가 만들어졌다. 따라서 여기서 어떤 일이 있었는지를 파악하는 작업이 무척 중요하다. 그리고 바로 이 책의 목표이기도 하다.

지진에 대한 재난 대응 절차가 체계적으로 잡혀 있는 일본조차도 원전 문제에 대해 속수무책인 상황인데, 책을 읽는 도중에 한국은 과연 어떨지 생각했다가 어느 순간 더 이상 생각을 하지 않기로 했다. 국민안전처 관계자의 최근 발언을 보면, 한국에서 후쿠시마 원전 사고에 필적하는 사고가 터지면 어떻게 될지 안 봐도 블루레이기 때문이다.

북한이 핵실험을 감행하면서 지표 밑으로 충격파가 영향을 미쳤을 가능성도 있다.

최대한 정보를 숨기면서 수동적으로 움직이는 관료 집단, 정작 중요한 정보를 제공하지 않으며 어떻게든 손실을 피하려는 전력 회사, 이권이 있을 때는 번개처럼 등장하다가 책임질 상황에서는 사라지는 학계 인사들이 앙상블을 이루면서 파국으로 치닫는 상황을 읽고 있으려니 많이 괴로웠다. 그래도 중간에 일본이 과연 선진국이라는 생각이 들게 만드는 일화가 나와서 깜짝 놀랐다. 계획 정전을 실행할 경우 집에서 요양하는 환자들의 목숨이 위태롭기 때문에 개별로 연락할 시간을 벌기 위해 필사적으로 노력하는 모습이나 이재민들의 대피와 불편함을 최대한 줄이기 위해 휘발유 보급까지 걱정하는 모습을 보면서 일본과 한국 사이에 벌어진 격차(not 경제적)가 얼마인지 갸늠조차 하기 어렵다는 생각이 들었다.

정전사태와 매뉴얼이라는 글을 적으면서도 한숨을 쉬었지만, 한국에서는 매일 큰 사고 없기를 바라면서 정화수 떠놓고 기도하는 기복신앙을 넘어서긴 틀렸다(털썩). 트위터에서 읽은 문구 하나를 소개하며 마무리한다(via @hjm4606).

미국: 새로운 매뉴얼을 창조
일본: 매뉴얼대로만 움직임
한국: 매뉴얼이 없음

결론: 한국에서 대형 사고가 터지면 어떻게 되는지 이미 수차례 목격하셨지만, 바닥 아래 지하실이라고 더 큰 대형 사고가 터질 경우 어떤 일이 벌어질지 궁금하신 분들이라면 이 책을 꼭 읽어보시기 바란다. 그리고 Managing the Unexpected도 읽으면 정말 많은 도움이 되리라 확신한다.

EOB

토요일, 9월 10, 2016

[B급 프로그래머] 9월 1주 소식 정리

시원한 맥주짤을 올리면서 소식을 정리해드리겠다(via https://twitter.com/DANIEL_AeHoBak).

웹/앱 소식
- cookies.js - Interactive and easy cookies from your browser in javascript
- Understanding and using CORS
개발/관리도구 소식
고성능 서버/데이터베이스 소식
- "2018년, 기업 워크로드 60%가 클라우드에서" 451 리서치 조사
- 리디북스 서비스 장애 복구 후기
- Me, too: 마이크로소프트 익스체인지 서버가 터질뻔한 사고 후기
- MHA Quick Start Guide
빅데이터/인공지능 소식
기타 읽을거리

마무리 짤방 하나: 노르웨이 사진가 셀 산베가 나비 무늬에서 찾아낸 알파벳(via https://twitter.com/waitoreke)

EOB

토요일, 9월 03, 2016

[B급 프로그래머] 6월 2주 소식(예전 소식)

(오늘의 짤방: "만약 천재성이 어떠한 공통 분모가 있다면, 나는 관심의 폭과 여러 분야 사이에서 유용한 유사성을 이끌어 내는 능력을 우선 꼽고 싶다." via @John_Grib)

계속해서 지난 6월 2주에 정리한 소식도 올려드린다.

[B급 프로그래머] 8월 마지막주 소식 정리

(코드 리뷰 중인 야옹이 via https://twitter.com/laynts/status/769496963528011776/photo/1)

한 동안 게으름을 부리고 있었는데, 정신을 차리고 다시 소식 정리 작업에 나서겠다. 일단 일주일치 정보부터 정리해보았다.

EOB

토요일, 8월 27, 2016

[독서광] 생각하는 뇌, 생각하는 기계

그 어느 때보다 무더운 여름도 지나고 이제 가을로 접어들고 있으니 슬슬 블로그도 다시 시작해야겠다는 여유가 생긴다. 오늘은 간만에 서평을 하나 올려드리겠다. 팜 파일럿으로 유명한 제프 호킨스가 인공 지능과 관련해 많은 생각거리를 제공하는 '생각하는 뇌, 생각하는 기계'가 오늘의 주인공이다.

몇 년 전에 [일상다반사] 호프스태터와 인공지능이라는 글을 하나 올려드렸는데, 사람이 생각하는 방식 그대로를 컴퓨터에게 가르치려고 시도하는 사람이 호프스태터 뿐만이 아니라는 사실을 알게 되었다. 제프 호킨스는 그 당시 누구도 생각하지 못했던 그래피티라는 손쉬운 필기 입력 수단을 제공함으로써 PDA 세상을 싹슬이 해버린 팜 파일럿의 엄청난 성공을 뒤로 하고 뉴멘타라는 회사를 설립해 진정한 기계지능(Machine Intelligence) 연구에 집중하고 있다. 먼저 책을 읽기 전에 다음 동영상을 한번 감상해보시기 바란다(그러면 '생각하는 뇌, 생각하는 기계'가 어떤 내용으로 전개될지 확실하게 알게 될 것이다).

(한국어 자막이 담긴 영상은 테드의 '제프 호킨스 - 어떻게 뇌과학이 컴퓨터를 바꿀까' 참조)

이 책은 지능(원서 제목이 'On Intelligence'라는 사실을 기억하고 있으면 좋겠다)과 관련해 이 책을 지을 시점까지 연구된 최신 결과들을 알기 쉽게 설명하고 있다. 요즘 딥러닝으로 엄청나게 뜨고 있는 신경망을 시작으로 사람의 뇌와 관련해 여러 가지 지식을 정리한다. 그리고 나서 가장 중요한 기억의 비밀을 파헤친 다음에 지능의 새로운 기본 틀인 예측으로 넘어간다. 그거고 나서 피질의 동작 원리와 의식/창조성에 대해 집중한다. 마지막으로 지적 기계의 가능성과 장점에 대해 소개하면서 막을 내린다.

일반적인 인공지능 서적과는 달리 이 책은 철저하게 사람의 두뇌에 집중한다. 청각/촉각/시각 등 모든 감각을 동원해 세계에 대해 끊임없이 예측을 하며 각 예측들이 대단히 완벽하게 통합된다는 사실(예: 걸으면서 발을 내딛일 때마다, 뇌는 발의 움직임이 언제 멈출지 발에 닿은 물질이 얼마나 많은 반응을 줄지를 예측하며, 계단에서 발을 헛디디는 순간 예측에 뭔가 문제가 생겼음을 깨닫는다. 익숙한 멜로디를 들을 때, 다음 음이 들리기 전에 이미 머리 속에서 다음 음을 듣는다), 뉴런은 밀리초 단위로 동작하므로 나노초 단위로 동작하는 CPU에 비해 엄청 느리다는 사실, 기억에는 순서가 중요하므로 알파벳을 역순으로 발음하거나 노래를 거꾸로 부르기 어렵다는 사실, 여러 감각에서 나온 패턴들이 사실상 두뇌 내부에서는 동일하다는 사실은 이 책을 읽으면서 다시 한번 깜짝 놀란 내용이다.

책 후반부에 나오는 창조성에 대한 이야기는 기존 고정 관념에 정확하게 반하는 내용을 담고 있다.

창조성은 고도의 지능과 타고난 재능을 필요로 하는 비범한 특성이 아니던가? 그렇지 않다. 창조성은 그저 유추를 통해 예측을 하는 것이라고 정의할 수 있으며, 피질의 어디에서든 나타나고, 깨어 있을 때 당신이 계속 하는 일이기도 하다. 창조성은 낮은 수준의 것부터 높은 수준의 것까지 하나의 연속체를 이루고 있다.

창조성에 버금가는 인간의 중요한 특성인 상상 역시 예측을 입력으로 돌리는 신경 메커니즘으로 설명한다.

6층의 세포들은 계층 구조의 하위 영역으로 발을 뻗고 있지만, 거꾸로 4층의 입력 세포들로도 발을 뻗고 있다. 따라서 한 영역의 출력이 다시 자신의 입력이 될 수도 있다. 눈을 감고 하마를 상상해보면, 피질의 시각 영역은 실제로 하마를 보고 있을 때와 똑같이 활성을 띌 것이다. 당신은 상상하는 것을 본다.

인문학을 중요하게 여기는 분들께서 이 책을 읽으면 위와 같은 기계론적인 설명에 씩씩거릴지도 모르겠지만, 최근 딥러닝을 필두로 사람보다 더 나은 실리콘(?) 사람들이 출현함에 따라 사람도 아주 특이하고 이상한 생명체가 아니라는 결론에 도달할지도 모른다.

결론: 인공지능과 기계지능에 관심이 있는 분이라면 반드시 읽어보기 바란다. 강력 추천!

EOB

월요일, 7월 25, 2016

[일상다반사] 프론트엔드 엔지니어 구인

최근에 여러 가지 바쁜 일이 많아서 블로그에 거미줄이 많이 쳐진 상황이다. 다시 일상에 복귀했으므로, 기념으로 글을 하나 올려본다. 놀랍게도 오늘 주제는 구인이다. 블로그를 열고 나서 구인글은 처음이지 않나 싶다.

다름이 아니라, 엑셈에서 SaaS 형 성능관리 소프트웨어인 APM(Application Performance Management) 제품 개발을 진행하고 있는데, 함께 작업할 수 있는 호기심과 상상력이 풍부한 프론트엔드 엔지니어를 모시려고 한다. 혹시나 다음 조건을 읽어보시고 마음이 동하시는 프론트 엔드 엔지니어분들께서는 jrogue 에뜨 gmail.com 으로 지원을 부탁드리겠다. 노파심에서 말씀드리지만 울트라 초사이언인 개발자를 뽑을 의도는 없으므로 각 조건을 빠짐없이 AND로 연결할 필요는 없다.

HTML/CSS 명세를 밑줄 그어가면서 읽어보신 분
자바스크립트 완벽 가이드와 HTTP 완벽 가이드를 완독하신 분
자바스크립트의 메모리 관리 방법, 단일 스레드에 따른 콜백 매커니즘, 가베지 컬렉션 알고리즘, 스코프 규칙을 이해하시는 분
D3 등 차트 관련 라이브러리를 사용하다가 불편해서 직접 코드를 열어 손을 본적이 있는 분
시각적인 웹 페이지 구성을 넘어서 웹 애플리케이션 관점에서 큰 틀을 잡고 작업을 하시는 분
디자인 가이드라인에 따라 다양한 브라우저, 다양한 해상도, 다양한 폰트 렌더링 엔진을 고려해 설계와 구현을 하시는 분
AJAX를 넘어서 JSON 형태의 데이터 전송에 Websocket을 사용해보신 분.
SPA(Single Page Application)이 무엇이며, 어떤 이유로 이런 기술이 등장했는지 이해하시는 분
HTTP/2가 HTTP/1.1에 비해 개선된 사항을 정리하실 수 있는 분
CORS(Cross Origin Resource Sharing)를 고려하면서 XSS(Cross Site Scripting)와 CSRF(Cross Site Request Forgery) 공격을 방어할 수 있는 분
클라이언트 쪽에서 자바스크립트 성능을 높이기 위해 여러 가지 다양한 시도를 해보신 분
브라우저의 개발자 도구에 능숙하며, 메모리 누수와 자원 활용을 점검하고 자동화된 단위 테스트와 헤드리스 브라우저를 사용해 테스트를 하시는 분
필요에 따라 자바스크립트 전처리 도구와 의존성 관리자를 활용하시는 분
다양한 자바스크립트 오픈소스 라이브러리에 대한 경험이 풍부하신 분
크롬 캔버스 등을 활용해 그리기 성능을 높여보신 분
사용자 중심의 개발 철학을 중요하게 생각하시는 분

아무쪼록 훌륭한 프론트엔드 엔지니어분들께서 지원해주시기를 학수고대하고 있겠다.

EOB

토요일, 5월 21, 2016

[B급 프로그래머] 10가지 성능 실수

Top 10 Performance Mistakes라는 글이 있어 독자 여러분에게 간략하게 요즘을 소개해드리겠다. 내용은 다름이 아니라 우리가 자주 저지르는 성능 관련 실무 목록이다.

10. 업그레이드하지 않음: 많은 회사들이 시스템이 충분히 빠르지 않다고 불평을 하며, 더 나은 알고리즘과 자료 구조를 찾지만, 실제로는 "업그레이드"가 필요한 경우가 많다. 운영체제, JVM이나 CLR 등을 업그레이드해야 하는데, "새로운 버전에 버그가 있을지도 모른다"며 변명을 댄다.
9. 중복된 작업: 웹 페이지를 서비스하는 시스템이 아주 느린 바람에, 개발자들이 데이터베이스 문제로 생각해서 실제로 튜닝 작업에 들어갔다. 하지만 프로파일러를 돌려보니 ORM을 7000번 호출하는 루프가 존재했기에 페이지 읽기가 느렸다. 루프를 수정하고 나니 시스템이 정상으로 돌아왔다.
8. 데이터 적재: 메모리 관련 연산은 유형에 따라 다르다. 다양한 자료 구조의 성능에 대한 기초 지식이 있어야 한다. 예를 들어, 2GB 이상의 자료인 경우 자바의 HashMap이 .Net의 Dictionary보다 10배 이상 느리다. 물론 .Net이 자바보다 느린 경우도 있다.
7. 너무 많은 할당: 메모리를 너무 많이 할당할 경우 가베지 컬렉터가 대규모 데이터 집합을 처리하느라 상당한 시간을 소비한다.
6. 병행 프로그래밍: 특정 알고리즘에서는 병행 프로그래밍이 아주 매력적이지만, 한계와 부하가 존재한다. 암달의 법칙과 USL(Universal Scalability Law)를 생각해야 한다. 특히 병행 시스템에서 구성 요소 사이의 통신과 관련한 성능에 특히 주의해야 한다.
5. TCP에 대한 이해 부족: TCP를 제대로 이해하지 못한 상태에서 마이크로서비스를 고려하는 실수가 의외로 많다. Nagle 알고리즘을 비활성화하기 위해 TCP_NODELAY를 고려하고, 여러 작은 패킷을 차례로 전송하자.
4. 동기식 통신: 클라이언트와 서버 사이의 동기식 통신은 빠른 통신이 필요한 시스템에서 문제로 등장한다. 더 비싸고 빠른 하드웨어 대신 비동기식 통신을 고려하자.
3. 텍스트 인코딩: JSON이나 XML과 같은 텍스트 인코딩 형식을 사용해 데이터를 전송하는 방법을 택하는 이유는 "인간이 읽을 수 있기" 때문이다. 하지만, 두 시스템 사이에서 통신이 일어날 때 사람이 읽는 경우는 없다. 물론 텍스트 편집기로 디버깅은 편하겠지만, CPU를 많이 소비하게 된다. 이진 형식을 고려하자.
2. API 설계: 성능에 가장 부정적인 영향을 주는 몇 가지 실수는 API와 관련이 있다. API만 제대로 설계되더라도 불필요한 메모리 복사와 추가 처리가 필요하지 않다.
1. 로깅: #1 성능 문제의 주범은 로깅에 소비되는 시간이다. 스레드를 아무리 많이 사용하더라도 로깅에 필요한 시간은 선형적으로 증가한다. 로거는 시스템에서 찾을 수 있는 최고 병목 중 하나다. 해법은 비동기식 로거 사용이다. 또한 동일한 오류를 계속해서 저장하는 방법도 피해야 한다. 처음 오류가 발생했을 때 한 번만 찍는 방안을 고안하자.

EOB

토요일, 5월 14, 2016

[B급 프로그래머] 조엘 스폴스키가 말하는 모든 개발자가 알아야 할 세 가지 기술

Stack Overflow founder Spolsky: The three skills every software developer should learn라는 글을 읽다보니 재미있는 이야기가 나와서 독자 여러분들께 요약 정리해드린다.

조엘 스폴스키에 따르면 모든 개발자다 알아야 하는 세 가지 기술은 다음과 같다.

경제학: 프로그래머들은 종종 경제학을 잘 모르며, 비즈니스에 가치를 더하는 방법을 이해하지 못하기 때문이다.
글쓰기: 근본적으로, 가장 성공적인 사람들은 자신의 아이디어를 가장 잘 표현하는 사람들이며, 이 능력이 뒷받침되어야 팀에서도 제대로 일할 수 있다.
C 프로그래밍 언어: 개발자의 이해를 높이기 위한 기술적인 토대를 제공하기 때문이다. C로 코딩하면 프로그래머에게 컴퓨터가 실제로 동작하는 방식을 더 잘 이해할 수 있게 만든다. C는 고수준 프로그래밍 언어보다 컴퓨터의 CPU가 수행하는 명령어에 더 가깝게 흉내내기 때문이다.

스폴스키에 따르면 프로그래머들은 일반적으로 두 가지 경력 계발 경로를 따르게 된다. 하나는 알고 있는 특정 프로그래밍 언어와 관련 기술에 초점을 맞추는 방법이며, 다른 하나는 전산학의 기본 원리를 이해하고 새로운 기술을 빠르게 습득하는 태도를 획득하는 데 초점을 맞춘다. 구글이나 페북 같은 전세계 최상위 기술 회사는 회사가 일하는 속력으로 인해 더 깊고 특정 기술에 매달리지 않는 유연성을 요구한다. "1년 안에 첨단 기술 회사들은 당신에게 심지어 아직 고안되지 않은 뭔가를 작업하게 만들지도 모릅니다."

스폴스키가 소프트웨어와 개발자를 바라보는 관점으로 마무리한다.

소프트웨어는 세상을 잡아먹고 있으며, 개발자들이 만든다. 프로그래머들은 미래의 스크립트를 작성하기 때문에 아주 중요하다.

EOB

토요일, 5월 07, 2016

[B급 프로그래머] 5월 1주 소식

오늘의 짤방: 문제 해결을 위한 알고리즘에 대한 지침 via @arasatasaygin

문제 해결에 사용될 수 있는 표준적인 기법(또는 기교)가 있는지 확인
이미 알고리즘이 개발된 문제를 살짝 변형한 문제인지 확인. 그렇다면 해당 알고리즘을 적용
분할-정복 기법: 문제가 하위 문제로 분해될 수 있는지 확인.
문제의 단순화된 버전을 개발하고 단순화된 문제를 위한 알고리즘 개발. 그런 다음에 원래 문제에 적합하게 이 알고리즘을 각색.

(짤방: 프로그래밍 언어들의 '잘못되었을때'에 대한 특성 맵 @ndc 16)