"바다" 인가??
"안드로이드" 인가?????

Figure: Relationships between classes

Relationships between classes


위에 보시는 클래스 다이어그램의 항목들은 바다의 UI 관련 클래스들 입니다.
근데 안드로이드 UI 관련 클래스를 정리한 것과 똑같아요!!! 하나도 안빼지고 100% 똑같습니다!
오히려 각 플랫폼 위에서 모두 어플리케이션을 개발해야 하는 입장에서는 좋습니다. ㅋㅋㅋ
좀 더 상세한 내용은 여기를 참고하세요!~~~~!!!!

삼성의 모바일 전략은 "Apple + Google" 인 것 같습니다!! ^^
저작자 표시 비영리 변경 금지
신고

'Smart Mobile > Samsung bada' 카테고리의 다른 글

bada Developer Day in Seoul  (0) 2010.03.24
"바다" 어플리케이션 생명 주기  (2) 2010.03.16
바다 Application UI Classes  (0) 2010.03.16
삼성 "바다" Developer Day  (0) 2010.03.10
Posted by 따봉맨

2009년 9월 17일 코엑스에서 NHN에서 주최/주관하는 DeView 2009 행사가 있습니다.

데브피아 "스마트폰 모바일 랩"의 공동작업소 DevForge 를 소개하기 위해서 행사에 참여하게 되었습니다.




스모랩을 처음 시작하면서 저는 뭔가 새로운 개발자 커뮤니티 UX 를 여러분께 제공하고 싶었습니다.

지금까지 개발자 커뮤니티를 지탱해온 것은 Q&A 일겁니다. 가장 힘든 시기에 내가 풀지 못한 숙제를 풀어주는 Q&A 게시판이 개발자들을 위한

최고의 커뮤니티 UX 였습니다. 하지만 이런 단편적인 지식은 막 입문한 개발자나 체계적인 개발 지식을 접하거나 개발 경험을 전달해 주지는 못합니다.

스모랩은 우리나라를 모바일 소프트웨어 강국으로 발전시키는 중요한 디딤돌이 되기를 원합니다. 하여 DevForge 라는 공동 작업소 서비스를 통해서

개발자 여러분의 개발 경험을 DB 화 하고, 어플리케이션 개발에 필요한 기술들을 포럼 주민 여러분과 함께 개발하여

개발 환경 및 개발 인프라를 제공하는 것 입니다.


이런 노력은 모바일 개발 환경에 입문한 개발자 여러분에게 날개가 되어 드릴 것입니다. 이제 시작이라 많이 미흡합니다.

그렇지만 데브피아와 스모랩 주민 여러분과 제가 열심히 노력하고 있이니 언젠가는 개발자 여러분의 든든한 지원자가 될 것이 분명합니다.




여러분!!!!! DeView 2009 에서 꼭 뵐 수 있기를 빕니다.

감사합니다.


저작자 표시 변경 금지
신고
Posted by 따봉맨


애플에 의해 시작된 AppStore 열풍!!!

애플이 시작했지만 이젠 애플 만의 것이 아닙니다. 산업 전반에 걸쳐 많은 사람들이 AppStore 덕을 보게될 것입니다.

AppStore 열풍의 중심에 있는 사람은 개발자들입니다. 덕분에 귀인 대접을 받고 있지요.

SI 인력시장에서는 부속품이지만, AppStore 세상에서는 그 누구보다도 중요한 키플레이어입니다.

근데 모바일 어플리케이션의 특성상 업무용 프로그램 보다는 게임멀티미디어류의 어플이 강세를 보이고 있습니다.

창의적인 기능과 디자인의 어플리케이션이 더 많은 인기를 누리고 있습니다.

그래서 개발자를 비롯해서 디자이너의 능력도 많이 필요한 상황입니다.

디자이너가 많이 참여해야 우리나라 모바일 어플리케이션이 더 많이 발전할 수 있다고 생각합니다.

개발자가 혼자 개발하면 기능적으로 우수할 수는 있어도, 시각적으로는 많이 떨어지게되지요.

저도 개발할 때 어쩔 수 없이 제가 디자인을 했는데요... 개발 시간만 더 늘어나고, 그 결과는 음.... X 입니다.

디자이너 여러분!!!!!!!!!!! AppStroe 의 열풍의 중심에 서십시요. 개발자와 협업하여 중요한 키플레이어가 되십시요.

개발자와 디자이너가 만날 수 있도록, 데브피아 "스마트폰 모바일 랩"이 앞장서겠습니다.

조금 있으면 시작하는 SKT 모바일 어플리케이션 경진대회에서 디자이너 여러분이 개발자 여러분과 함께 팀을 이뤄 대회에 참석할 수 있도록 노력하겠습니다.

많이 참여해 주세요.
저작자 표시 변경 금지
신고

'DayDayDay...' 카테고리의 다른 글

Google I/O 2010  (0) 2010.01.18
디자이너를 위한 AppStore  (0) 2009.08.20
광고로 벌어 정승같이 돈 쓰는 "Google"  (1) 2009.08.08
완도갑니다.  (0) 2009.07.30
Posted by 따봉맨
Mobile Bootcamp Presentation: Mobile Application Development Platforms
View more presentations from wmworia.


저작자 표시 변경 금지
신고
Posted by 따봉맨
Overview Of Parallel Development - Ericnel
View more presentations from ukdpe.


저작자 표시 변경 금지
신고

'Research' 카테고리의 다른 글

Concurrent and Multicore Haskell  (0) 2009.08.05
Overview Of Parallel Development - Ericnel  (0) 2009.08.05
Patterns For Parallel Computing  (0) 2009.08.05
parallel computing, parallel processing  (0) 2009.08.05
Posted by 따봉맨
드뎌 알파 완성입니다.

이제 외부 공개를 위한 영어 멘트만 달아주면 끝입니다.

코딩은 끝났다고 볼 수 있습니다.

두 달에 걸친 개발의 결과입니다.

더 빨리 끝내려고 했는데...... 나름 열심히 했는데, 두 달이나 걸렸네요.

서버도 구매해야되는뎅... ㅡ.ㅡ

PathTour 서비스를 영어 버젼으로 시작합니다.

한국어는 베타에서 추가할 계획이구요.

한국어 PathTour 서비스가 나오는 그 날 까지~~~ 열심히 하겠습니다.

여러분~

도와줍셔~~~~~~~~~~~~~~~ ㅋㅋ

감사합니다.
신고

'My Service > PathTour' 카테고리의 다른 글

호스팅 업체 타진중...  (0) 2008.07.25
드뎌 PathTour 알파버젼 개발이 완료 되었습니다.  (0) 2008.07.14
PathTour 80% 완성.....즈음..  (2) 2008.07.02
freecore 이야기  (0) 2008.06.24
Posted by 따봉맨


1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
기본 사양은 완성품을 고객이 보고 나서 결정된다.
상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.
하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1+1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
시스템 엔지니어에게 고객은 돈이다.
프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는
것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
영업은 꿈을 말한다.
시스템 엔지니어는 공상을 이야기한다.
프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
깨닫고 빨리 최종요구조건을 확정하는 것이다.
SE가 고객에게 사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
개발비의 10%만이 프로그램의 개발에 사용된다.

출처 : http://gall.dcinside.com/list.php?id=programming&no=69357&page=1

모두 맞는 말입네다~~~!! ㅋㅋㅋ
신고
Posted by 따봉맨
OpenCV 자료를 찾아 인터넷 바다를 헤매다가 발견했습니다.

"SERVO"라고.. 외국 잡지인데...

착하신 분이 스캔떠서 pdf 로 만들어서 친절하게 올려주셨더라구요..

아직 연재가 끝나지 않은 것 같은데.. 다 올라오진 않았네요.

이름하여... "Seeing with OpenCV"

받으세요~~

사용자 삽입 이미지

SERVO Magazine


Part 1. A Computer-Vision Library

Part 2. Finding Faces in Images

Part 3. Follow That Face!

Part 4. Face Recognition With Eigenface.

즐개발하세요~~
신고

'Research' 카테고리의 다른 글

[Arrow English] Actress Christina Ricci  (0) 2007.10.30
[SERVO] Seeing With OpenCV  (0) 2007.10.26
Intelligent Traffic Surveillance  (0) 2007.10.24
[→E] Miss Mexico Priscila Perales  (0) 2007.10.16
Posted by 따봉맨
이전버튼 1 이전버튼

티스토리 툴바