Categories
Development

Declarative UI 찬양

Flutter 쓰기 시작한지 1년이 되간다. 초반 두세달은 Declarative UI 적응하고 Dart 적응하고 Flutter 적응하느라 러닝커브가 심했지만 익숙해질수록 고통없이 빠르게 화면을 찍어낼 수 있게됐다. 곰곰히 생각해보니 이건 숙련도의 문제라기보다 선언적 UI의 긍정적 부수효과인 거였다.

Kotlin Anko 쓸때도 왜 이렇게 기분이 좋은지 잘 몰랐다. 그저 이름과 발음이 내 취향이라 그런줄로만 알았는데 지나고나서 생각해보니 비슷한 효과였다.

이름을 짓느라 시간을 허비하지 않아도 된다!

대충 지은 이름은 그 존재를 인식하는 것만으로도 굉장히 불쾌한데, 요즘처럼 가져다 써야하는 라이브러리가 백만개쯤 되면 얘네들 때문에라도 자꾸 이름 짓기를 강요받게 되고, 그러다보면 서로 어울리지 않는 애들이 모여 collocation 엉망진창 되고 코드를 읽는자도 그에 동화되서 머리속이 더러워진다. 이름 지은 애들끼리 하이러키 똥망되고 족보 꼬이면 코드 볼 때마다 고통받는 것이다. 논리적으로 서로 딱히 연결될 이유가 없음에도 불구하고 레퍼런스가 필요하다는 이유로 불필요한 이름 짓느라 얼마나 괴로웠는지 말도 못한다.

불필요한 참조를 만들지 않아도 되는 모든 것들에게 감사한다. 파이썬의 list comprehension 도 그래서 행복하고, Rx도 구독 핸들러만 들고 있으면 독립된 다른 공간에서 복작복작해서 최종 결과물만 콜백으로 주니까 나는 이름을 안지어도 되는 거다. 백앤드면 하나하나 다 의미있는 경우가 많겠지만 내가 왜 padding wrapper 따위한테 이름을 지어줘야하냔말이다. 키스토로크 하나하나가 아깝다.

선언적 UI 트리내에 동적으로 변경해야하는 부분이 있으면 React.createRef 같은 것을 쓰거나 잦은 화면갱신를 피하기 위해 별도 state를 가지는 컴포넌트를 새로 만들어야하는데 아니 변수명 짓기도 싫다는데 클래스명을 지으란 말입니까. 물론 어떤 화면에서 잦게 변경되는 부분이 있다면 논리적으로 별개의 것일 확률이 높고 그렇다면 분리하는게 맞지만 살다보면 안그런 경우도 많은 것이다. 이런 상황에서 이름 안짓고 성능도 떨어지지 말라며 BLoC 가 또 나를 구원해줬다.

추적해야할 레퍼런스가 적고 생존주기가 짧을수록 행복해진다. 다음 글에서는 이 글을 까는 글을 써야겠다.

Categories
Daily Development

주말에는 잉여 개발을

아내의 학교 프로젝트를 돕기 위해 Raspberry PI를 하나 샀다. Model B 하나에 33.78 유로다. 이 프로젝트에서 Raspberry PI가 해야할 일은 Coin Acceptor 에 동전이 하나 들어오면 이 신호를 GPIO로 받아서 하위 노드들(집에 남아도는 Microsoft Surface RT, Android, iOS 잉여기기들) 에게 신호를 보내 뭔가를 하게 만드는 것이다. 할 일이 거의 없다. Model A로도 충분했다. B 타입 메모리가 512고 A 타입이 256인데 128이여도 널럴할 뻔했다. RPi.GPIO가 단순하기도 하지만 나는 coin counter 포트 하나만 감시하다가 tcp 소켓으로 1바이트 write만 하면 끝나는 거라 목표는 금새 달성되어버렸다.

Raspberry PI로 본 목적을 달성하였으니 이제 잉여를 한다. ARMv6 머신이 생겼다 하하하. 몇달전에 심심해서 구매한 Arduino를 가지고 놀 때는 괜히 led에 불이나 켜고 오오오- 했었는데 Raspberry PI는 그런 맛이 없다. 그냥 펜티엄2급의 리눅스 박스다. 3달전에 올라온 Raspbian 이미지를 썼는데 커널도 3.10.25+고 gcc 4.6, Python은 2.7.3이 기본이지만 Python 3.2도 repo에 있다. Ruby는 1.9.3p194고, Java도 1.7.0_40이 있는데 Hotspot Client VM만 번들된걸보니 X 에서 자바 GUI 돌리려는 목적이 아닌가 싶었다. nginx 최신 버전(1.4.7)을 포함하여 내가 좋아하는 오픈소스들은 컴파일이 다 잘 된다. OS 부터 모든 것이 sd 카드에서 돌아가므로 i/o가 몹쓸 수준인데, 모델 B의 512 메모리를 놀리지 말고 ramdisk로 300메가 정도를 잡아 그 안에서 노는 맛도 솔솔하다. 초간단 http api 서버를 만들 때는 flask를 쓰곤 했는데 Raspberry PI는 느리니까, 괜히 falcon으로 갈아탔다.

노는 HDMI 포트를 주체하지 못해 반정도 억지로 건축학개론을 감상했다. 처음엔 멋모르고 ffplay와 mplayer로 재생을 시도했었는데 얘네들이 GPU를 쓰지 못한다는 것을 깨닫는데는 그리 오랜 시간이 걸리지 않았다. user cpu 100% 먹으면서도 초당 1프레임도 안나왔기 때문. Raspberry PI에서 GPU 활용할 수 있는 플레이어는 omxplayer 밖에 없다고 한다.

Raspberry PI 이야기 끝.

그 아내의 학교 프로젝트로 Microsoft Surface RT 위에서 원격으로 동영상 재생을 해야했다. Surface 2.0 SDK를 받아서 설치를 시도했다. 충격이 대단했다. Visual Studio 2010이 필요하다는 것이다. 나는 2013인데… 좀 어이가 없었다. 하위호환성 잘 지켜주는 Microsoft는 어디로 갔을까. 지가 아무리 Surface 라고 해봐야 ARM Cortex A15 위에서 돌아가니까 어떻게든 되겠지- 하며 Qt 5.2로 개발을 시작했다. 몇시간의 삽질이 필요했고 Qt 위에서 h264 동영상 재생하기를 성공했다. 그리고 또 깨달았다.

“QMediaPlayer 품질은 개똥망이구나.”

Windows 7 KN 클린인스톨 (나는 Visual Studio Professional with MSDN 구매자) 후 미디어플레이어도 없는 상태에서 시도하면 QMediaPlayer::ServiceMissingError 가 발생한다. 그래서 윈도우미디어플레이어를 설치하니 잘된다. 그렇다면 QMediaPlayer는 각 플랫폼에서 제공하는 코덱과 서비스에 의존한다는 결론이 나온다. 그런데! 윈도우미디어플레이어에서 잘 재생되는 동영상이라 해도 QMediaPlayer로 하면 재생실패하는 케이스가 엄청나게 많다. QVideoWidget을 붙이기만 하면 QMediaPlayer::ResourceError가 터지는 것. 웃기는건 Qt 사이드에서 비디오 레이어를 꺼버리면 오디오는 잘 재생된다는 것이다. 아무튼 mp4 파일 10개중에 9개는 이런식으로 재생이 안된다. 특징도 모르겠다. 포기.

여기에도 구원자가 하나 있었으니.. 이 거지같은 QMediaPlayer를 참지 못한 어느 오픈소스 개발자가 ffmpeg 백엔드로 QtAV라는 프로젝트를 만들었다. 돌려보니 잘된다. 만세.

Qt는 오늘 하루 나한테 육성으로 엄청나게 욕을 먹었지만, 참지 못할 수준은 아닌 것 같다. 그래서 앞으로도 쭉 써주기로 했다. 이번에 검토하면서 정말 큰 소리로 웃음이 나온 적이 있었는데, Qt 5 부터 icu dll이 QtCore, QtGui만 써도 항상 링크되는 것이였다. 맥이나 리눅스에서는 icu 라이브러리가 어떤 형태로든 os에서 제공을 해줄테니 괜찮지만 윈도우즈에는 그런게 없나보다. 그래서 23KB 짜리 Hello world.exe를 만들어도 의존성이 40MB 정도(icu만 25MB) 된다. 큰 소리로 웃었다. 니가 자바야, 닷넷이야, 왜이래.

신나게 욕을 했지만 나는 개발할 때마다 항상 욕을 하기도하고 QMediaPlayer의 비디오 병맛사건만 빼면 Qt API 스타일도 내 마음에 들고 signal/slot 개념도 괜찮았다. Qt 5부터 새로 등장한 iOS/Android 도 나중에 시간내서 써봐야겠다. 가장 큰 걱정은 배포본 크기인데 요새는 바이너리 사이즈에 둔감한 유저들이 많아졌기도 했고  Ruboto 처럼 사용자한테 Ruboto Core를 따로 설치하게 하는 과정에서 생기는 이상한 경험(해보면 안다. 견딜 수 없다)을 제공하지는 않을테니까 괜찮을 것 같다. Ruboto는 요새 활발히 개발되고 있으니 사용자경험은 많이 나아질거라 기대한다.

Microsoft는 마우스랑 키보드, 그리고 오피스랑 개발툴을 아주 잘 만드는 회사라고 생각한다. 오랜만에 Visual Studio 쓰면서 매우 쾌적하다는 느낌을 받았다. 그래서 맥이나 리눅스용 C/C++ 프로그래밍을 할 때도 Visual Studio를 쓰기로 했다. VisualGDB USD 349

오랜만에 목적없이 글을 써봤다. 내 라이프스타일과 참 어울린다.

Categories
Development

기획자님들, 개발을 배우세요

소프트웨어 개발, 당신들이 생각하는 것만큼 어렵지 않아요. 소프트웨어 개발은 여전히 어려운 것으로 알려져있고 실제로도 그렇지만, 당신들이 공포감을 가지고 있는 부분은 완전히 다른 부분이에요.

소프트웨어 개발 바닥은 잉여에너지가 넘친지 오래되서, 고객(개발자)이 학습해야할 내용을 최대한 줄이면서 좋은 가치를 주도록 흘러가고 있어요. 만약 어느 기술을 선택했는데 공부해야할 것이 너무나도 많다면 바로 버리세요. 공부를 위해 어느 책을 집었는데 열라 어려워보이고 권위가 느껴진다면 바로 버리세요, 그 저자는 자신의 권위를 높이기 위해 책을 집필했지 독자의 성장을 위해 쓴 것이 아니랍니다.

쓸만한 소프트웨어 개발자 품귀 현상 때문에 개발자 몸값도 엄청 비싸진걸로 알고 있어요. 아, 물론 당신들이 개발 공부안하고 간단한 것들까지 개발자들한테 시켜준다면 저도 그렇고 다른 개발자들도 그렇겠지만 돈 벌기 쉽고 인생 편하고 좋아요. 그런데 좀 너무 심해진 거 같네요. 저도 개발자지만 개발자들 하고 다니는 꼴들이 너무 우스워요. 웬만한건 기획자 선에서 해결했으면 좋겠어요. 이거 되냐고 안되냐고 개발자한테 묻지 마세요. 꼭 필요하면 해야죠. 그쵸?

당신의 기획을 스스로의 손으로 다 완성하고 나서, 나중에 확장성 문제가 생기거나 성능 이슈가 생기면 그때 개발자를 찾으세요. 확장성이나 성능 이슈가 생길때쯤이면 당신네 회사는 이미 절반쯤 성공한 거니까요. 당신들의 기획이 괜찮은지 아닌지는 이 시점에서는 이미 검증된 것이므로 좋은 개발자를 찾기도 이전보다 훨씬 수월할 겁니다. 이 시점에서는 돈 아끼지 말고 아낌없이 내주세요. 가끔 못나보이고 유치하고 우스워 보이는 개발자도 보이겠지만 그냥 자존심도 좀 지켜주시고 그러면 잘 해결해줄꺼에요.

어디서부터 시작해야할지 모르겠다고요? 아시겠지만 지식은 값싸고 얻기 쉽지만 판단력을 얻으려면 시간이 필요하잖아요. 스스로의 판단력을 사용하여 길을 찾으시고 시행착오 겪으세요. 주위에 잘한다고 소문난 개발자들한테 묻지 마시고. 저한테도 묻지 마시고.

제발 부탁이에요. 그래야 기획자도 살고 개발자도 살고 대한민국도 살아요.

Categories
Development

내가 소프트웨어 개발을 즐기는 이유

중력을 비롯한 온갖 물리적 제한들이 존재하지 않는 세상이기 때문이다.

마법을 시전할 수 있다는 말이지!

마법은 현실보다 어렵다. 용어도 생소하고 2-30년간 현실세계에서 학습해왔던 스킬들이 통하지 않고 새로운 것을 공부해야만 한다. 현실세계에서 생명이 위급해지면 엠뷸런스를 부르면 된다는 것은 누구나 알고 있지만, 소프트웨어가 맛이 갔을 때 이를 어떻게 해야하는지 진단하고 치료할줄 아는 사람은 매우 적다.

하지만 얼마나 어렵느냐는 내가 알 바 아니다.

열심히 노력하다보면 언젠가는 마법을 시전할 수 있다는게 중요한 것이다. 현실세계에서 내가 죽기전까지 중력이 없어지진 않을것 같거든!

Categories
Books Development

‘괴테와의 대화’ 1825년 3월 27일 일요일 에서

소프트웨어 이야기인줄 알았다.

이렇게 멋진 극장에는 아름다운 무대 장식과 지금까지보다는 더 나은 의상이 필요할 거라고 누군가가 말했다. 그리고 또 단원들의 수도 점차 부족해져 가고 있는 실정이므로 연극을 하든 오페라를 하든 간에 젊고 실력 있는 단원 몇 명을 새로 채용해야 한다는 것이 자리에 모인 사람들의 대체적인 의견이었다. 그러나 이런 일을 하기 위해서는 상당한 비용이 들어야 했다. 현재까지의 재정 수입으로는 충분치 못하다는 견해도 있었다.

“나도 잘 알고 있어요.” 하고 괴테가 중간에 끼어들어 말했다.

“돈을 절약한다는 이유로 임금이 싼 배우들 몇 명을 고용할 테지요. 하지만 그런 조처로 재정에 도움이 되리라고 생각하는 건 어림없는 일이오. 그와 같은 필수적인 비용을 절약하겠다고 나서는 것보다 더 재정에 해로운 일은 없을테니까. 그보다는 매일 저녁 극장을 관객으로 가득 메울 방법을 생각해 내야 하는 것이오. 그러기 위해서는 젊은 남녀 가수 각각 한 사람에다가 유능한 주연급 남자 배우 한 사람, 그리고 뛰어난 재능과 상당한 미모를 갖춘 주연급 젊은 여배우 한 사람이 있으면 크게 도움이 될 테지요. 말이 나왔으니 말이지 내가 아직 극장 운영을 책임지는 자리에 있다면 재정 상태를 최대한으로 호전시키기 위해 한 걸음 더 나아간 조치를 취할 것이고, 그렇게 되면 필요한 비용이 모자란다는 소리는 더 이상 나오지 않게 될거요.”

… (중략) …

이어서 배우에 대한 문제가 화제에 올랐고, 그들의 능력을 제대로 활용하거나 오용하는 문제를 둘러싸고 많은 이야기가 오갔다. 괴테가 말했다.

“나의 오랜 공연 경험에 비추어 보건대 중요한 사실은 연극이든 오페라든 몇 해 동안에 걸쳐 어느 정도 성공을 거두리라고 분명하게 예상되지 않는 작품이라면 결코 연습시켜서는 안 된다는 것입니다. 5막 짜리 연극이라든지 그와 같은 길이의 오페라를 연습하는데 얼마나 많은 힘이 드는지를 제대로 생각하는 사람은 드뭅니다. 그렇습니다. 여러분, 한 사람의 가수가 모든 장면과 막에 걸쳐서 자기가 맡은 배역을 완전히 소화하려면 많은 노력이 듭니다. 또한 합창단이 제대로 궤도에 오르기까지는 엄청난 노력이 필요한 것입니다. 나는 가끔 어떤 오페라의 성공 여부에 대해 아무 예측도 못하면서 몇몇 불확실한 신문기사만을 믿고 경솔하게 연습 명령을 내리는 사람들이 있다는 소리를 들으면 섬뜩한 마음이 들기도 합니다. 이제 우리 독일에도 그런대로 쓸 만한 역마차 제대로 완비되어 있고 심지어 급행 역마차까지 운행이 시작되었지요. 그러므로 다른 지방에서 새 오페라가 공연되어 호평받았다는 소식이라도 들려오면, 나는 연출가나 믿을 만한 단원을 현장으로 보내 실제 공연을 직접 보고 확인토록 할 것입니다. 즉 찬사를 받고 있는 새 오페라 작품의 좋은점과 유용한 점이 무엇인지 그리고 우리의 능력으로 공연이 가능한지 아닌지를 확인하여 알아 오게 할 것입니다. 이러한 여행에 들어가는 경비는, 그로써 얻게 될 막대한 이익이나 혹은 불행한 실패를 사전에 방지함으로써 얻게 되는 이익과 비교한다면 아무 문제도 아닌 것이지요.”

“그리고 공연 연습을 끝낸 좋은 작품이나 좋은 오페라가 관객들의 호응을 받아 극장의 좌석이 가득 메워진다면 며칠씩 짧게 간격을 두고 계속 공연해야 할 테지요. 나온지 오래된 좋은 작품들의 경우도 마찬가집니다. 그러한 작품들은 오랜 기간 동안 공연되지 않고 묵혀져 있었으니까, 이제 그것들을 무대에 올려 다시 성공을 거두자면 마찬가지로 적잖은 연구가 필요할 테지요. 물론 이러한 작품들의 공연도 관객들이 관심을 보이는 한 짧은 간격을 두고 되풀이하여 공연해야 합니다. 항상 새로운 것만 찾는다든지, 각고의 노력으로 연습한 좋은 연극 작품이나 오페라를 단 한 번 아니면 고작 두 번만 보고 만다든지, 또 이러한 작품의 공연 간격을 주에서 8주 정도로 길게 잡아놓고 그 사이에 다른 작품을 새로 연구하는 일을 반복한다면, 이런것들이야말로 연극을 망치는 일이며 참여하고 있는 사람들의 힘을 남용케 하는 것으로서 도저히 용납할 수 없는 일이지요.”

괴테는 이 문제를 아주 중요하게 보고 있고 또 절실하게 가슴에 담아두고 있는 것 같았다. 그래서 이런 말을 하며 흥분하는 모습을 보였는데, 그것은 평소에 너무도 침착한 그로서는 보기 드문 일이었다.