software-development

소프트웨어 개발, 당신들이 생각하는 것만큼 어렵지 않아요. 소프트웨어 개발은 여전히 어려운 것으로 알려져있고 실제로도 그렇지만, 당신들이 공포감을 가지고 있는 부분은 완전히 다른 부분이에요. 소프트웨어 개발 바닥은 잉여에너지가 넘친지 오래돼서, 고객(개발자)이

연차가 늘면 늘수록 장점이든 단점이든 크게 돋보이게 된다. 대부분의 사람들은 단점이 더 많기 때문에, 통상적으로 연차 많은 개발자를 만나면 아무런 희망도 가질 수 없다. 게다가 사람들의 학습의지는 큰 계기 없이는 평생을 두고 변하지 않는다.  학습하려는 의지가 없는

중력을 비롯한 온갖 물리적 제한들이 존재하지 않는 세상이기 때문이다. 마법을 시전할 수 있다는 말이지! 마법은 현실보다 어렵다. 용어도 생소하고 2-30년간 현실세계에서 학습해왔던 스킬들이 통하지 않고 새로운 것을 공부해야만 한다. 현실세계에서 생명이 위급해지면

언젠가부터 만든 프로그램을 외부에 노출하지 않기 시작했다. 제작년에 만들었던 Android 용 MSN 클론 때문이다. public release 는 대단히 고통스럽고 에너지가 많이 소모되는 일이다. Total Installation 수는 360만정도였고,

작년말에 Neospeech 에서 TTS 엔진을 구매했다. 한국어 Voice 인 유미, 준우 이렇게 2개를 구매했고 Voice 당 USD $138 를 줬다. Windows 전용이라 (리눅스 + API 버전은 가격이 정해져있지 않고, 마케팅 담당자를 계속 괴롭혀봤으나

안드로이드가 가끔씩 날 못살게 군다. 친구들끼리는 싸우면서 친해진다고 하지 않았나. 안드로이드랑도 싸울 때마다 조금씩 친해지는 기분. 하지만 요새는 싸울 일이 그다지 생기지 않는다. 나이 먹고 어른이 되면 친구들이랑 덜 싸우잖아. 서로 같은 의견을 가지고 있을리도

프로젝트 진행상황을 명확하게 말할 수 없다면 설계를 안했거나 설계를 개판으로 했거나 설계하면서 코딩하고 있거나 거짓말 하는 능력이 부족한 것. 진행상황을 명확하게 (진실을 담아) 얘기했으나, 나중에 틀어지는 경우 설계에 오류가 있어서 다시 설계를 했음 설계에

지금보다 더 개념없던 시절에는 아는 것이 없어 코딩을 빨리 할 수 있었다. 예외 처리는 e.printStackTrace() 일단 넣고 넘어가면 그만이었다. 그저 생각나는대로 일단 만들어서 결과물이 돌아가면 그만이다 . 경험이 늘어갈수록 하나의 사건에서 파생될 수

우연히 박영록이 쓴 안드로이드를 하면서 다시 생각해본 OOP를 읽고 OOP에 대한 단상들을 뱉어내기로 했다. 영록이가 쓴 글의 문맥과는 거리가 멀다는 점을 염두해두시라. 나는 OOP를 상당히 좋아한다. 그저 객체 지향- 을 좋아하는 것이다. 다른 동물들에 비해

나는 TDD를 제대로 공부해본 적이 없다. 테스트 코드 작성하는 것을 무지 싫어한다. 하지만 테스트 하기는 무척이나 좋아한다. 그 이유는 두려움을 경감시켜 창의력을 발현하는데 도움을 주기 때문이다. 새로운 시도를 해보고 싶으면 dummy 프로젝트를 하나 만들어 단위

쇼펜하우어는 그의 저서 문장론에서 독서란 스스로 해야할 생각을 타인에게 떠넘기는 행위라 하였다. 독서는 글을 읽는 것이지만 소스코드를 읽는 것으로 확장하여 사상해보겠다. 프로그래머는 읽어야 할 책이 대단히 많다. 남의 만들어놓은 플랫폼 위에서 노는 것이 프로그래머의

이분법적 사고를 가지고 프로그래머를 크게 두 그룹으로 나눠본다면, 개념이 충만하고 아키텍트 레벨을 다루고, 글을 잘 읽고, 잘 쓰고, 계층화된 구조를 좋아하며, 논리적인 사고를 잘하고, (숙련되지는 못하더라도 최소한 잘하려는 욕심이 있고) 구현에 급급하기보다는

나는 프로그래밍 할 때 모든 주의력과 정신을 지금 하고 있는 프로그램에 집중하는 편이다. 내 모든 것을 걸었다는 기분에, 기능이 잘 구현되거나 버그를 잡으면 기분이 좋아지고, 문제가 생겨서 계속 digging을 하고 있으면 아드레날린이 솟구친다. 서비스를 런칭했는대

그날 그날 기분에 따라 쉽게 환호하고 쉽게 무시하기도 하는 성격이긴 하지만, Software Creativity 2.0 아휴 버릴 게 없다. 버릴 게 없어.  Effective Java 1판 이후로 이렇게 임팩트 넘치는 책을 읽어본 적이 없다.  저자의 의도를

요즘 세상엔 리팩토링이나 설계를 바꾸는 일들조차 너무나 쉽기때문에 처음 코딩을 시작할 땐 구현에만 신경써도 된다. 마치 영향력있는 누군가가 자신에게 "이런 기능 구현 가능한가요??" 라고 물었을 때 자존감을 올리기 위해 앞뒤 안보고 구현하는 아가 마인드를

Kent Beck이 쓴 Implementation Patterns을 보다가 Cost(total) = Cost(develop) + Cost(maintain) Cost(maintain) = Cost(understand) + Cost(change) +

assertTrue()의 Turn off your step-thru debugger를 보다가 어딘가 옮겨놓고 싶어서, 옮겨봅니다.  상황  나는 디버거 없이는 살 수 없는 초보 프로그래머. 내가 짠 코드에서 버그가 생겼다. 사수한테 도움을 요청했다. 상황을

블로그에 기술적인 내용을 쓰는 것은 어떤 의미가 있을까. 내가 요즘 적용하고 있는 규칙은 기술적인 내용을 최대한 피하는 것이다. 인기 있는 패스트푸드를 만드는 일이 아니라면, 앞뒤 내용이 거의 생략될테고 그 결과 독자로 하여금 문맥을 거의 따라갈 수 없게 만들

믿거나 말거나, 사람들은 자기가 어떤 일을 하게 된 이유를 그 일을 하고난 후에서야 알 수 있다고 한다. 일을 마친 후에는 전후 사정을 고려하여 이야기를 만들어 내기가 쉽다. 그래서 '나 이거 공부해봐야지!' 하는 어떠한 포스팅이나 announce 없이 JavaFX를

공부 중이라 많은 코멘트는 없고, 간단히 소식만 전합니다.  Qt 4.5 가 드디어 릴리즈 되었습니다.   RC 버전 다운로드는 벌써부터 사용가능했지만, 릴리즈가 가지는 의미가 꽤 큽니다. LGPL 2.1로 풀리는 것 뿐만 아니라 Qt