Spring Framework with JavaFX - 이승철
JavaFX 의 목적은 원소스로 어떤 디바이스에서도 구현하는 것입니다. 현재로서는 툴의 지원도 부족하고 후발주자이기 때문에 Flex나 Silverlight에 비해서 관심을 가지고 있는 사람이 너무 적습니다마나 자바소스로 쉽게 사용할 수 있다는 점에서 매력적인 점이 있습니다.
작년 자바컨퍼런스 갔을때 처음 구견한 JavaFX인데 이렇다할 임팩트는 못주고 있는 듯합니다. 스프링의 대한 얘기는 없었던듯 하고 JavaFX도 아직 단점은 있지만 앞으로 기대해 볼만한 기술이라는 것이 요점이었습니다. 한때 좀 관심가지려고 했지만 RIA는 약간 관심 끊기로 해서...
자바스크립트 삽질(실수?) 베스트 10 - 장동수
JS가 비동기라는 것을 자주 있는다.
항상 This가 같은 것을 가르치지 않는다.
not of not은 not이 아닌 것이 아니다.(a 와 !!a가 드랍니다.)
0, null, false, undefined, NAN에 관한 것들... empty string과 null이 다릅니다.
변수선언, JS는 항상 function스코프를 가집니다.
함수 오버로딩은 없습니다.
escape(), encodeURIComponent(), encodeURI()의 차이 : 모르면 encodeURIComponent를 쓰면 되고 encodeURI에 대해서 알면 쓰고 escape는 그냥 잊으면 됩니다.
String은 캐릭터의 어레이가 아닙니다.
pareseInt()에서 radix를 잊는 문제
배열에서 마지막에 콤마(,)에 대한 실수
Vanilla Javascript 즉 프레임워크를 쓰지 않고 순수 자바스크립트만 쓰는 것이다. JS에 대해 불평하려면 프레임워크를 써보고 불평하세요.
한 브라우져에서 해보고 다른 브라우져에서 해보길 기대하는 것은 실수입니다.
당연한 듯 하면서도 코딩할때 많이 하게 되는 실수를 정말 잘 짚어주신 것 같습니다. 따로 정리해서 강좌로 적어도 될만한 내용이네요. Vanilla Javascript에 대한 말은 크게 공감됩니다. 어떤걸 좋아하는지는 취향이지만 안쓰는건 정말 이해못하겠더군요. 전에 Daum DevDay에서도 뵈었었는데 여기서도 또 뵙는군요. 나중에 개발자의 수다에서도 그렇지만 경험도 많으시고 통찰력이 뛰어나신듯...
timelog 업무 적용 실험기 - 송승렬
어느 일을 어느정도 하는지를 위해서 타임로그를 기록하기 시작했는데 어느 곳이 좋을까 하다가 미투데이를 이용하기 시작했습니다. 시간은 자동으로 찍히고 무슨일을 했는지만 적으면 됩니다. Play와 Work를 나누어서 쉽게 구분할 수 있도록 작성하였는데 머라고 적을 것인가는 많은 고민이 되었습니다.
통계를 내보니 하루에 4시간 이상은 일을 하지 않았습니다. 통계를 내 보니 하루에 5시간 이상은 코딩을 하지 않았습니다.(빨리듣다보니 잘못적었나보네요. ㅎ 요청에 따라 수정합니다.) 그래서 앞으로 일정을 산정할 때 하루 8시간을 잡고 일정을 산정하는 것이 아니라 4시간으로 잡고 해야 하는 것이 아닌가 하는 생각이 들었습니다.
최근에 저도 하고 있는 흥미로운 주제입니다. 저도 저렇게 할려고 했는데 저게 또 만만치 않은 일이라서 timelog관리도 하나의 일이 되어버리죠. 나중에 정리하면 timelog정리가 1-2시간 이렇게 타임로그를 찍어야 되는 아이러니한 상황이 되어버리죠. 그래서 간단히 제가 어느정도 하는지 관심가지고 싶은 일들만 iZepto를 이용해서 기록하고 있습니다. 자동으로 되면 참 좋을텐데요. ㅎ 손글씨의 이쁜 PPT가 상당히 인상적이었습니다.
코드 품질 포탈 SONAR 적용기 - 고경철
코드품질 포탈(SONAR) 적용기에 한 얘기입니다. 이전에는 자신의 PC에 저장하던 정보를 모두의 것으로 공유하는 시대가 되었습니다. 모든 것은 ALM의 형태로 통합되고 있습니다.
sonar 를 쓰면 개발과 관련된 모든 품질 결과를 웹에 모아서 볼수가 있습니다. 테스트 결과 , 오류, 잠재적 위험 등등 maven을 이용해서 레파지토리에서 자동으로 sonar를 사용하게 함으로써 일시적인 것이 아닌 지속적인 품질 검사를 실행할 수 있습니다.
툴에 대해서는 구경해봐야겠습니다만 지속적으로 품질검사를 피드백 받을 수 있다는 것은 꽤 흥미로왔습니다. 시간내서 한번 만져봐야겠습니다. 흥미로운게 너무 많다는게 문제라면 문제지만요. ㅎ
제가 국내 회사내에서 일반적으로 이루어지는 장황한 발표를 별로 안좋아하고 제안서마냥 어차피 다 읽지도 않은 깨알같은 글씨로 빽빽히 찬 PPT는(공기업쪽 사업에서 이런 성향이 강하죠.) 더욱 더 안좋아하기 때문인지 페차쿠차는 상당히 인상적이었습니다. 30초는 꽤 긴것 같으면서도 아주 짧은 시간이었고 딱 전달할 얘기만 하지 해야지 다른 얘기를 하거나 너무 많은 설명을 하게 되면 페이지가 넘어가서 오히려 산만해졌습니다.
시간내에 원하는 내용만 정확히 전달해야하다보니 중요한 얘기로 발표가 집중되고 듣는 사람도 지루하지 않게 들을 수 있었습니다. 짧은 시간내에 다양한 주제의 핵심내용들만 들을 수 있으니 좋았으며 세미나나 발표라고 하면 아주 고급기술이나 어려운 얘기를 해야할 것만 같았는데 페차쿠차는 기술 얘기를 해도 좋지만 그냥 자신이 평소에 관심을 가지고 있는 아무거나 나누어도 좋기 때문에 자유스러운 분위기였습니다. 마치 다음에는 나도 한번 해볼까? 하는 생각이 들 정도로요.
최근에 해외에만 있던 이런 발표형식의 행사들이 많이 생겼습니다. TEDxSeoul이나 페차쿠차랑 비슷한 Ignite Seoul이 있었는데 생각만 있고 못가보고 있었는데 이렇게 페차쿠차를 보고나니 더욱 관심이 가게 되는군요. ㅎ
시간내에 원하는 내용만 정확히 전달해야하다보니 중요한 얘기로 발표가 집중되고 듣는 사람도 지루하지 않게 들을 수 있었습니다. 짧은 시간내에 다양한 주제의 핵심내용들만 들을 수 있으니 좋았으며 세미나나 발표라고 하면 아주 고급기술이나 어려운 얘기를 해야할 것만 같았는데 페차쿠차는 기술 얘기를 해도 좋지만 그냥 자신이 평소에 관심을 가지고 있는 아무거나 나누어도 좋기 때문에 자유스러운 분위기였습니다. 마치 다음에는 나도 한번 해볼까? 하는 생각이 들 정도로요.
최근에 해외에만 있던 이런 발표형식의 행사들이 많이 생겼습니다. TEDxSeoul이나 페차쿠차랑 비슷한 Ignite Seoul이 있었는데 생각만 있고 못가보고 있었는데 이렇게 페차쿠차를 보고나니 더욱 관심이 가게 되는군요. ㅎ
개발자들의 수다
얘기를 들으니 전에는 개발자들의 수다가 테이블별로 몇명끼리 얘기를 진행했다는 것 같은데 이번에는 전체 인원이 그리 많지 않아서 인지 발표자들이 앞으로 나와서 질답(?)형태로 진행이 되었습니다. 얘기하기는 소수끼리 모이기가 좋지만 전체공유하기는 이런 방식이 좋기도 하죠.
질문은 거의 젊은데도 상당한 내공을 가지고 계신 홍민희 님과 창업을 하신 황대산님과 정지웅님에게 집중이 되었습니다. 주요얘기의 주제는 개발자의 자기계발과 스타트업의 이야기였습니다.
자기계발에 대해서는 젊으신 홍민희님께 집중이 좀 됐었는데 초등학교 5학년때부터 개발을 했다고 하더군요. 이른 시기에 시작한 것도 그렇지만 고등학교때 동아리에서 개발에 많은 시간을 투자했다고 하셔서 역시 김창준님이 1만시간 법칙에 대한 오해라는 글에서 얘기한 것처럼 수련의 시간을 얼마나 가졌는가가 중요하구나 하는 생각이 들었습니다.
야크쉐이빙에 대한 얘기도 나왔는데 이날 가장 인상적인 말이었습니다. 야크쉐이빙이란 것은 어떤 사람이 나무를 자르려고 도끼를 구했는데 도끼날이 너무 무딥니다. 그래서 도끼날을 갈려고 돌을 구하는데 어떤 마을에 도끼날을 갈 수 있는 정말 좋은 돌이 있다는 얘기를 듣고 그 마을에 가려고 하는데 마을이 너무 멀어서 야크를 구합니다. 근데 야크의 털이 너무 길어서 야크를 면도(쉐이빙)합니다.
처음에는 원래의 목적을 수행하기 위한거였지만 주객이 전도된 상황을 얘기합니다. 이야기에서도 느껴지듯이 별로 좋은 의미로 하는 것은 아니라고 보여집니다. 개발자는 기본적으로 야크쉐이빙을 좋아하는 성향을 가지고 있으며 야크쉐이빙을 하려면 훨씬 많은 것을 알아야 되기 때문에 개발자에게 도전도 많이 되고 많은 것을 배울 수 있습니다. 이게 개발자는 회사업무에 대해서 동기부여를 별로 느끼지 못끼다 보니 자기계발에 대해서 고민하게 되고 오히려 야크쉐이빙에 관심과 동기가 커지는 상황이라고 할 수 있습니다.
철이 빨리 들면 성장이 멈추고 철이 들지 않으면 무책임해지는 경향이 있다고 합니다. 무슨 말이냐 하면 현실적으로 회사업무가 개발자로써 자신의 관심이나 자기개발에 도움이 되는 경우는 많지 않기 때문에 관심을 야크쉐이빙에 가지게 되고 이 둘사이의 균형이 중요한데 회사업무로 돈을 받기 때문에 철이 들어 거기에 충실하게 되면 더이상 많은 공부를 할 필요가 없어지고 그렇지 않으면 관심없는 업무는 적당히 수행하고 야크쉐이빙에 정말 집중해서 노력하게 되는 것입니다.
좋은 프로그래머가 되는 것과 좋은 프로덕트를 만드는 것은 완전히 다른 방향인 것 같고 때로는 좋은 프로덕트가 아닐때도 있다는 것입니다.
이런한 자기계발과 차후에 스타트업으로 이어져서 성공하는 얘기까지도 자기계발을 하고 평소에 스타트업에 대한 마인드를 가지고 가치를 둘 수 있다는 얘기를 하면서 스타트업에 대한 얘기로 오랫동안 얘기가 오갔습니다만 장동수님이 마지막에 한방에 정리하시면서 모두 마무리 되었습니다. 성공한 개발자와 개발자 출신의 성공한 사업가는 추구하는 바도 다르고 준비해야 하는 길도 다르기 때문에 로드맵이 완전히 다르다는 것이었습니다. 2가지를 같은 것으로 혼동하고 있으면 이야기의 진행도 혼돈될 수밖에 없다는 것이었습니다. 성공한 개발자는 돈이 목적이 아니고 레퓨테이션을 많이 얻는 것입니다. 돈이 목적이라면 성공한 사업가가 되어야 하는 것입니다.
다른 개발자들도 그렇겠지만 제가 고민하고 있는 것과 많이 관련된 부분도 많아서 생각해 볼만한 시간이 되었습니다. 야크쉐이빙에 대한 문제들... 회사 업무가 커리어에 별로 도움이 안된다는 생각을 하다보면 다른 일에 더 관심을 가지고 좋아하게 되고 그러다 보면 아무래도 업무 자체에는 좀 소홀하게 될 수 있는데 막상 내 월급을 주는건 자기계발이 아닌 회사 업무이다 보니 그일에 소홀할 수 만은 없는 노릇이지요. 나중에 저녁 식사자리에서 나온 얘기지만 유명한 대부분의 회사들도 사업가와 개발자라는 듀엣으로 구성되어 있습니다. 애플의 스티브 잡스와 스티브 워즈니악, 스프링소스의 로드 존슨과 유겐 휠러등이 있습니다.
나는 성공한 개발자를 꿈꾸는가 성공한 사업가를 꿈꾸는가는 정리해서 고민해 볼 필요가 있는것 같습니다. 지금은 2개를 딱히 구분하지 않고 있었던 같았는데 이번 기회를 통해서 생각의 정리를 할 필요가 있을듯 합니다.
야크쉐이빙도 참 고민될만한 문제죠. 개발자는 성향상 이런걸 좋아하게 되고 사실 전 이런걸 그다지 좋아하지 않으면 개발자의 자질 자체를 약간은 의심하기도 합니다. 개발자는 좀 오덕기질이 있어야 된다는 생각... ㅋㅋ 어쨌든 야크쉐이빙이나 오버엔지니어링 자체는 안좋은 느낌이지만 적당한 야크쉐이빙은 필요합니다. 사실 그런 야크쉐이빙을 통해서 새로운 혁신적인 기술등이 나온 것도 사실이고요.
어쨌든 저녁도 잘 얻어먹고 즐거운 시간이었네요. ㅎ
나는 성공한 개발자를 꿈꾸는가 성공한 사업가를 꿈꾸는가는 정리해서 고민해 볼 필요가 있는것 같습니다. 지금은 2개를 딱히 구분하지 않고 있었던 같았는데 이번 기회를 통해서 생각의 정리를 할 필요가 있을듯 합니다.
야크쉐이빙도 참 고민될만한 문제죠. 개발자는 성향상 이런걸 좋아하게 되고 사실 전 이런걸 그다지 좋아하지 않으면 개발자의 자질 자체를 약간은 의심하기도 합니다. 개발자는 좀 오덕기질이 있어야 된다는 생각... ㅋㅋ 어쨌든 야크쉐이빙이나 오버엔지니어링 자체는 안좋은 느낌이지만 적당한 야크쉐이빙은 필요합니다. 사실 그런 야크쉐이빙을 통해서 새로운 혁신적인 기술등이 나온 것도 사실이고요.
어쨌든 저녁도 잘 얻어먹고 즐거운 시간이었네요. ㅎ
잘 보았습니다.
예전에 켄트벡 발표 시와 이번 페차쿠차, 두번의 정리해 놓은걸 보지만
같은 곳에서 같이 들었는데 어떻게 이렇게 정리를 잘하실까?
하고 생각해 봅니다. 수고하세요.
p.s 메모의 기술 인가 봐요 ^_^
기억력이 나빠서 열심히 적어놓을 뿐입니다. ㅎㅎㅎㅎ
같은 세미나를 2번이나 들었군요. 다음번에는 인사라도 한번 할수 있기를 바라겠습니다. ^^
만나뵈서 반가웠습니다. 이렇게 정리해주시다니… 다시 한번 복습하고 갑니다.
ㅎㅎ 저도 만나뵈서 반가웠습니다.
많이 배우고 많이 자극받은 것 같습니다. ㅎㅎㅎ
저 저녁식사때 황대산님 건너편에 앉아있던 사람입니다. ^^(친한척~)
제머리가 ... 좋은 사진 망쳤군요;;ㅎ
그나저나 언제 이렇게 다 정리 했어요 ;;ㅋ
대박!!
기억력이 안좋아서 안적으면 까먹어.. ㅋㅋㅋㅋ
그나저나 위치상 회장님 뒷통수가 너무 자주 나와서 약간 죄송하기도.. ㅎ
좋은 글 감사합니다.
덕분에 참석은 못 했지만, 좋은 아이디어를 많이 얻을 수 있었습니다. 꾸벅
도움되셨다니 저도 좋네요.
댓글 감사드립니다.
오. 깔끔하고 자세한 정리 감사합니다.
일이 바빠서 페차쿠차만 끝나고 자리를 떴는데 저런 재미있는 내용이 있었네요^^
제가 발표한 부분의 설명에 한 가지만 바로 잡자면 :
as-is: 통계를 내보니 하루에 4시간 이상은 일을 하지 않았습니다.
to-be: 통계를 내 보니 하루에 5시간 이상은 코딩을 하지 않았습니다.
입니다.^^
다시 한 번 정리 감사합니다!
timelog 발표해 주신 분이시군요.
수정했습니다. ^^
좋은 발표 잘 들었습니다.