오늘 문득 세바시에 공신으로 유명한 강성태씨의 발표영상을 본 후 이와 관련해서 공감가는 부분이 많아 글을 쓰고 싶어 졌다.


강성태씨가 10년간 공부 비법을 연구하던 중 하는 말이 학생들이 공부를 안한다는 것이다.

그 해결책으로 습관을 언급하였다. 런던이 어느 연구팀에서 연구결과 사람이 습관을 자기 몸에 베이게 하려면 최소 66일이라는 시간이 든다고 하더라.


이 애길 들으니 2010년도 내가 생각났다.

2007~ 2010년도 근무한 회사에서 팀장을 포함한 프로그래머들이 총 5명인 회사였다

팀장은 전국 올림피아드 전국 3위 출신의 천재였고, 나머지 팀원들도 모두 입사할때 2시간에 할당된 프로그램 코딩 시험을 통과해야지 입사 할수 있는 회사에서 난 운좋게 입사를 하였다(당시 문제 수준이 서든어택, 카트라이더, 메이플스토리 등으로 유명한 게임회사 넥슨과 비슷한 수준이었다). 난 대학교때 공모전 입상 경력도 있었고 대학교때 학부에서 프로그래밍 2년간 도는 족보도 남겼을정도로 남겼을 정도였고 학부에서 내 이름을 언급하면 교수님이든 학우들이든 프로그래밍 좀한다는 인식에 사실 자만을 하고 있었다. 하지만 그 회사에서는 그냥 평범한 수준이었다. 전부다 나 보다 잘하는 애들 같았다. 그중에 한명은 안철수 연구소를 거쳐서 현재는 넥슨 아메리카(미국 LA 지사)에 있을정도로 실력들이 좋았다. 그때 느겼던것은 잘하는 사람들의 공통점은 잘 할수 밖에 없는 습관을 가지고 있더라는 것이었다. 


난 그들에서 배운것은 단순히 단편적인 기술적인 지식보다 그들의 습관을 보고 배웠다. 그리고 그 습관을 내것으로 만드는데는 몇 개월이란 시간이 걸렸다. 강성태씨가 애기한 66일 얼추 비슷한 시간 인것 같다. (시간을 일일이 재어 보진 않았지만..) 


어떤 일이든지 그 쪽 분야에서 잘 할수 밖에 없는 습관 즉, 잘 할수 밖에 없는 DNA을(후천적인 노력으로 만든 습관) 가지게 된다면 그 사람은 잘 하는 사람이 될 수 밖에 없다고 되는것이 아닌가? 라고 생각해 본다.


하지만 사람이 습관을 바꾼다는것은 엄청난 고통이 따른다. 나도 어떤 계기가 있어서 그런 고통을 감당해 낼 수 있었던것 같다.


조엘 온 소프트웨어에서 프로그래머 한 명의 기술적인 차이가 23배라고 한다.

근데 어느 IT회사에 재직중에 어느 팀원으로 부터 이런 애길 들은 적이 있다.

아무리 노력해도 천재 개발자를 못이긴다고? 그 천재 개발자의 일하는 것을 잘 관찰 해 보길 바란다. 잘 할 수 밖에 없는 DNA을 가졌을 확율이 높을것이다. 


Posted by 모과이IT
,

13 Simple Rules for Good Coding (from my 15 years of experience) 번역한 글입니다.

나는 15 이상의 경력을 가진 프로그래머이며 많은 여러 언어, 패러다임, 프레임워크를 사용해봤고 많은 삽질을 해봤다. 그리고 나는 좋은 코딩을 작성하기 위한 나만의 규칙들을 여러분에게 공유하고자 한다.

 

1.      최적화 VS 가독성. 최적화보단 가독성

코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라. 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다. 최적화가 필요하다면, DI (의존성 주입)을 사용해 독립적인 모듈로 만들고, 100%의 테스트 커버리지를 유지하여 최소 1년간은 건들지 않아도 되도록 만들어라.

2.      아키텍처 우선

나는 “우리는 빨리 개발을 해야하기 때문에 아키텍처를 설계할 시간이 없다”라고 말하는 사람을 많이 봐왔다. 그리고 그 중 99%가 이러한 생각 때문에 큰 문제를 겪었다.

아키텍처를 생각하지 않고 코드를 작성하는 것은 목표 달성을위한 계획없이 자신의 욕망을 꿈꾸는 것처럼 쓸모가 없다. 코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.

3.      테스트 커버리지

테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다.

테스트가 필요한 경우:

·         최소 한 달간은 건들지 않아도 될 모듈이나 마이크로서비스를 개발하는 경우

·         오픈소스 코드를 작성하는 경우

·         핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성하는 경우

·         코드를 업데이트 하는 것과 동시에 테스트를 업데이트 할 수 있는 충분한 비용이 있는 경우

테스트가 필요하지 않는 경우:

·         스타트업인 경우

·         팀이 작고 코드가 빠르게 변하는 경우

·         출력값을 보고 간단하게 수동으로 테스트가 가능한 스크립트를 작성하는 경우

나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.

4.      간단하고 단순하게

복잡한 코드를 작성하지 말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다. 코드는 수많은 추상화 및 기타 객체지향적인 문제 (특히 Java 개발자와 관련이 있음) 없이 딱 필요한 일만을 수행해야하며, 추후에 간단한 방법으로 코드를 업데이트하기 위해 필요한 것의 20%를 수행해야한다.

5.      주석

주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다. 그러면 새로운 개발자를 위해 시간을 절약하기 위해 해야 할 일은 무엇인가? — 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 문서를 작성하라. 이는 이해를 위한 많은 시간을 절약해 줄 것이며 — 더 많은 사람들에게 메서드를 더 잘 구현할 수 있는 기회를 제공해준다. 또한 이는 글로벌 코드 문서화를 위한 좋은 시작점이 될 것이다.

6.      강한 결합 VS 느슨한 결합

항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다. 마이크로서비스는 여러분의 소프트웨어를 여러 서버로의 분산뿐만 아니라 가끔은 하나의 머신에서의 분산처리 (프로세스 분산을 의미한다)도 할 수 있는 가능성을 제공해준다.

7.      코드 리뷰

코드 리뷰는 좋을 수도 있고 나쁠 수도 있다.

여러분의 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라. 이 외의 경우에는 단지 시간 낭비가 될 수 있으며 모두가 이를 싫어하게 될 것이다. 이 부분은 많은 질문을 가져오기 때문에 이를 좀 더 깊게 살펴보자.

많은 사람들은 코드 리뷰가 새로운 사람이나 코드의 다른 부분을 작업하는 팀원을 가르치는 좋은 방법이라고 생각한다. 그러나 코드 리뷰의 주요 목표는 코드 품질을 유지하는 것이지 가르치는게 아니다. 여러분의 팀이 원자로 또는 우주 로켓 엔진 냉각 시스템을 제어하는 코드를 작성했다고 가정해보자. 그리고 여러분은 아주 어려운 로직에서 큰 실수를 저질렀고, 이를 새로운 사람에게 코드 리뷰를 위해 제공했다고 해보자. 이 경우 여러분은 사고 위험에 대해 어떻게 생각하는가? — 내 대답은 70% 이상이다.

좋은 팀은 각자가 자신의 역할을 가지고 있으며 일의 한 부분에 대해 완전한 책임감을 갖고 있는 팀이다. 만약 누가 코드의 다른 부분을 이해하고 싶으면 해당 부분을 담당하고 있는 사람에게 찾아가 질문을 하면된다. 모든걸 아는건 불가능하며 전체보다는 코드의 작은 부분을 (하지만 적어도 30%) 완전히 이해하는것이 더 낫다.

8.      리팩토링은 작동하지 않는다

나는 일하는 동안 “나중에 리팩토링 할거니까 걱정하지마라”라는 말을 많이 들었다. 그리고 나중에 이는 큰 기술적 부채로 돌아오거나 모든 코드를 다 삭제한 후 처음부터 다시 작성하게 되었다.

따라서 처음부터 여러번 소프트웨어 다시 개발할 수 있는 자금이 있는게 아니라면 부채를 만들지 말라.

9.      피곤하거나 컨디션이 좋지 않을때 코딩하지 말라

개발자들이 피곤할 땐 평소보다 2-5배 더 많은 버그와 실수를 만들어낸다. 따라서 과업은 매우 나쁘다. 그렇기 때문에 하루의 업무시간을 약 6시간으로 고려하는 국가가 점점 더 많아지고 있으며, 일부 국가에서는 이미 실천하고있다. 정신적인 일은 육체적인 일을 다루는 것과 같지 않다.

10.  모든걸 한꺼번에 작성하자 말라 - 반복적으로 개발하라

코드를 작성하기 전에 우선 여러분의 고객과 클라이언트가 정말로 필요로 하는걸 분석하고 예측하고, 짧은 기간동안 개발할 수 있는 MVF(Most Valuable Features)를 추려내라. 품질 업데이트를 배포하기 위해 이러한 반복을 사용하도록 하고 무리한 요구사항과 품질 희생에 시간과 자원을 낭비하지말라.

11.  자동화 VS 수동

자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라. 5 분 밖에 걸리지 않는데, 왜 자동화 해야해?”라고 생각할 수도 있다. 하지만 한 번 계산해보자. 예를 들어 5명의 개발자로 이루어진 팀의 일상적인 작업을 들어보자. 5 * 5 * 21 * 12개월 = 6,300 = 105시간 = 13.125 ~ 5,250$. 직원이 40,000명일 경우엔 비용이 얼마나 커질까?

12.  나가서 취미를 갖자

일의 차별화는 정신 능력을 향상시키며 새롭고 신선한 아이디어를 제공한다. 따라서 잠시 쉬고 신선한 공기를 마시거나 친구들과 이야기를 하거나 기타를 연주하는등의 취미를 가져라.

13.  여유 시간에 새로운걸 배워라

학습을 중단하면 퇴화하기 시작한다.

 

좋은 코드 작성에 대한 아이디어와 관행에 대한 의견을 공유해준다면 매우 감사하겠다.

 

[출처]

https://mingrammer.com/translation-13-simple-rules-for-good-coding

 


'모과이 > 스크랩' 카테고리의 다른 글

폰갭, 자마린, 네이티브앱 개발 경험담  (0) 2015.11.07
IIS 계정 추가  (0) 2015.10.24
SVN보다 Git가 더 좋을까?  (0) 2015.08.03
소스분석 방법  (0) 2014.12.31
각종 오픈소스 제약사항 관련  (0) 2014.10.12
Posted by 모과이IT
,

출처 : http://nancom.tistory.com/238


오류내용 :

VMware Workstation unrecoverable error: (vcpu-0)


vcpu-0:VERIFY

vmcore/vmm/main/physMem_monitor.c:1123


A log file is available in "D:\Virtual Machines\OS X 10.10\vmware.log".


You can request support.  


To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.


You can also run the "vm-support" script in the Workstation folder directly.


We will respond on the basis of your support entitlement.


해결방법:


config 파일에 한가지 내용만 추가 해주면된다.

경로는 OS별로 상이한데, 다음경로로 각각 맞춰서 들어가시면 됩니다.


윈도우(windows): %PROGRAMDATA%\VMware\VMware Workstation\config.ini

리눅스(Linux): /etc/vmware/config

맥(OS X): /Library/Preferences/VMware\ Fusion/config


추가해야할 내용은 아래와 같습니다.


smc.version = "0"

Posted by 모과이IT
,

저도 웹앱, 하이브리드앱 도구인 PhoneGap으로 실제로 실무에서 사용해 보면 뭔가 이상하다 싶고 결국에는 시스템을 제어하려면 Native쪽을 처리를 해주어야 되고 제약도 많고 레퍼런스도 없어서 개발할때 정말 애 먹었습니다. 아래 글은 너무나 공감이 가서 공유합니다. 

제가 이렇게 공유하는 이유는 하이브리드앱 의도 자체는 정말 좋습니다. 폰갭은 HTML5, JavaScrit, CSS 자마린은 C# 등으로 상위언어(비교적 쉬운언어)로 안드로이드, 아이폰 앱을 동시에 만들어 낸다는 컨셉인데 개인적으로 저의 프로그래밍 경험과 상식으로는 이런게 나올수가 없다고 봅니다. 

폰갭으로 예를 들면 HTML5, JavaScript, CSS 로 UI와 전반적인 앱을 만듭니다. 그리고 시스템 관련 제어를 할려면 Native로 안드로이드, 아이폰의 모듈을 작성해 주어야합니다. 결론적으로 퍼온글 말미에도 언급이 되었지만 결국에는 네이티브쪽의 안드로이드, 아이폰의 개발 경험한 사람이 그 모듈을 만들어 주어야합니다. 그러니 폰갭을 할려면 폰갭의 구조와 네이티브 쪽의 안드로이드, 아이폰도 다 알아야 한다는 것입니다. 폰갭 관련해서 자료도 별로 없었고 샘플 소스 조차도 없어서 굉장히 힘들게 개발을 했던 기억이 나네요. 그때 아예 네이티브로 개발하는게 속편하지 괜히 뭐 하는짓인지란 생각이 들더군요.

이런 실제 속사정을 모르고 자금력이 여유가 없는 스타트업이나 벤처회사들에서는 무조건 하이브리드앱을 맹신하는 결과가 나온것 같습니다. 

개인적인 생각은 이런 하이브리드앱의 개발방식은 벤더사(구글,애플)와의 긴밀한 협조 없이는 상식적으로 불가능하며 너무 많은 개발방식으로 인해서 개발환경에 파편화가 일어나서 실무에 작업하는 개발자들만 힘들게 하는거 같습니다. 애초에 이런 하이브리드앱 개발도구들의 컨셉이 맞는 100% 원소스 크로스플랫폼 개발도구가 나오지 않은 이상은 개발방식의 파편화만 초래 할 것같습니다.이러한 개발 방식은 이제 좀 지양이 되었으면 하는 바램에서 아래 퍼온글을 공유합니다. 만약에 진정한 100% 원소스 크로스플랫폼 개발도구가 나온다면 대환영입니다. 하지만 현재는 그렇지 않고 결국에는 프로젝트 진행 어느정도 진행된 상태에서 필연적으로 네이티브 해야하는 상황인데 이런상황은 체크해 보지 않고 무조건적인 원소스 크로스플랫폼이란 말만 믿고 프로젝트 진행이나 외주 맡기려하는 대표님 임원분들에게 저의 경험담과 아래의 경험담을 공유 하고 싶습니다.



출처 : http://blog.naver.com/synchrog/220196854844

(퍼온글 입니다)


초딩때부터 대학시절까지 내 모든것이 였던 개발자.

 

2002년 월드컵을 기점으로 개발자를 포기하고 모터스포츠로 넘어가 개발에 개자도 쳐다도 안보다가 필요에 의해서 다시 DEV LIFE를 시작했다. 정확히 말하면 2013년 9월 부터다. 

 

난 천재이기 때문에 다 할줄아는게 좋다. 이왕 할꺼 재대로 만능으로 가자 싶어서 데스크톱에서 스마트폰, 웹에 이르기까지 소비자들과 맞닿아 있는 모든 영역을 다 섭렵하고 싶었다. 과욕이 아니라고 생각 했었(?)던 이유는 역시 IT업계엔 대천재들이 상주하고 있거니와 이들은 온갖 종류의 코스트를 극단적으로 줄일 수 있는 통합 솔루션을 양산(?)해 내고 있었다. 

 

모르는 사람들을 위해 약간의 설명을 하자면, 기본적으로 프로그래밍을 하려면 C라는 가장 유명한 언어를 공부한뒤에, 각각 영역에 맞는 언어를 하나 하나 다시 공부해야한다. 집이나 사무실에 있는 데스크톱 컴퓨터에서 돌아가는 프로그램을 만들고 싶을 때, 아이폰용 앱을 만들고 싶을 때, 안드로이드용, 맥용등등 모두 다 다른 언어를 쓴다. 심지어 지금 이 글을 읽고 있는 '웹사이트'를 만드는 언어만도 3가지 이상의 언어로 만들어졌다.(HTML,CSS,JAVASCRIPT등 - 거기에 서버쪽 언어는 또 별도다.)

 

참고로 본좌가 싱크로지닷컴을 만드는데 사용된 언어만 HTML5, CSS, JAVASCRIPT, PHP, mySQL정도이며 여기에 이 언어들을 다루는 툴 사용법은 또 별도.그래서 MS에서 나오는 PPT나 워드, 그리고 adobe에서 나오는 포토샵이니 일러니 하는 '툴'같은건 기본적으로 다 공부해두라고 늘 강조하는것

 

아무튼 요는 학습하는 시간을 줄여보고자 했던게 그간의 가장 큰 이슈였다.언어는 계속 바뀌고 업그레이드되며 새언어가 나오면 또 공부하는게 싫었고(하지만 숙명이다) 뭔가 지금 당장 만들고 싶은게 생겼을때 만들 수 있는 능력을 갖추고 싶었다. 웹은 이제 그게된다. 상상하면 바로 만들 수 있다. 뭐든지. 그런데 스마트폰 앱만큼은 그게 안된다. 온갖 종류의 꼼수를 다 찾아봤고 위에 나열된 웹사이트를 만드는 언어들만으로도 만드는 기술을 찾기까지 했다. 그런 기술이 있다 실제로! 그러나 이제 모든 것을 알아버렸으니 뒷사람을 위해서 정리해준다. -심지어 이 글을 쓰기 6시간전에 나는 아마존에서 전설의 찰스 페졸드가 쓴 자마린 책을 구입해 읽었다!

 

*이제부터 개발을 모르는 사람은 못알아 들을태니 위 결론만으로 더는 읽을 필요 없다.(하지만 내가 글을 워낙 재밌게 쓰니 읽어 보고 싶을껄!)

*아래 정리는 윈스마츠닷컴이라는 해외 블로거가 잘 정리해 준것을 내 경험을 양념쳐서 정리했다.

 

먼저 HTML5

 

1. 웹사이트를 만드는 마크업 언어로써 가장 쉽고 대부분 언어인줄 모르고 많이들 쓴다. 가령 <img src ="쑹님천재.jpg"> 이런거나 유투브나 비메오 링크 딸때 <iframe 어쩌구>하는 그런걸 말한다. 암튼 이것만으로는 스마트폰 앱이라 불리울 수 도 없고 싸파리나 인터넷접속후 웹앱정도로 보는(웹사이트인데 앱처럼 작동되는) 수준밖에 안된다.

 

2. 푸쉬알람기능이 불가능하다. 연출이 네이티브 앱처럼 가능하긴한데 뭔가! 네이티브 같은 느낌은 절대 구현할 수 없다.

 

3. 웹사이트 개발 레벨이기 때문에 한번 만들어 놓으면 어떤 스마트폰에서도 똑같이 보인다.특별한 타겟팅 재개발 따윈 필요치 않다.

 

4. 안드로이드의 경우엔 덜한데 iOS의 경우 업데이트될 때마다 개병신 처럼 보일 수 있다.

 

5. 어쨋든 이건 "앱"이라고 불리울 수 없다. (일반인들에게)

 

다음은 HTML5를 진짜 앱처럼 만들어주는 Phonegap - 처음 나의 시도는 이녀석이였다.

 

1. HTML로 한번만 만들면 진짜 앱으로 토출되긴 하나 애플 앱스토어에 올리려고 하면 빠꾸먹는 일이 비일비재.

 

2. 앱 입장에서 볼 때는 외부 서버와의 통신이 원활하다. 웹사이트와 서버 간의 데이터 송수신만 할줄알면 간단히 끝.

 

3. 문제는 서버사이드쪽 개발이 복잡해진다는거.

 

4. 게다가 웹사이트 개발언어로만 스마트폰 네이티브(틱한)앱을 만들고자 한게 이 방법의 취지임에도 불구하고!!! 결국에는 약간의 네이티브 언어를 추가해야하는 경우가 생긴덴다.

 

5. 네이티브앱에 비해서 무거워지지만 들어가는 시간과 비용대비 비교할 수 없는 장점이지.

 

6. 사후 관리(업데이트등)가 힘들어지고 파이날 퀄리티가 네이티브에 비해 떨어지는 것 역시 부정할 수 없다.

 

Unity3D 유니티... -_-;;

 

1.게임을 만드는 툴이다. 그러나 이걸로 게임만들 생각은 없었으며 앱을만들고자 했다. 그 이유는 이거 하나면 자바스크립트 하나로 모든 환경에서 돌아가는 앱을 만들 수 있다 생각했으니까.

 

2. 하지만 현실적으로 기능에 비해 와이파이 연결설정이 되어 있지 않은 곳에서 다운받을 수 없는 크기의 앱이 토출되는 문제가 발생.(엄청 커진다!)

 

3. 기능에 비해 로딩이 생기고 느려진다.(게임기능이 없는데 해당 라이브러리나 최소 필수 컴포넌트는 들어가기 때문)

 

4. 결국 이러다 게임을 만들겠다 싶어서 잠깐 게임 기획을 했으나 1인 스튜디오로 경제적 승산이 없다 판단. 모터스포츠 보다 많이 벌 확률이 적어서 Drop!

 

그러다 발견하여 요 몇일 매드니스였던 Xamarin

 

1. 비주얼 스튜디오 처럼 잘만들어진 개발환경도 있고 C#하나만 알면 아웃풋도 진짜 네이티브 앱이 나온다.그러나 아직 완벽하다고 볼 수 없는 이유가 실제로 아웃풋을 만나보면 용량도 커지고 실제 네이티브 앱같은 느낌이 나지 않는다. 자원관리나 디바이스에 대한 접근에 대한 문제 역시 제한적이라 좀 더 기다려봐야 할 솔루션.

 

2. iOS를 개발하려면 결국엔 mac을 사야하는건 마찬가지(뭐 나는 세 대나 있으니 문제 없지만)

 

3. 자마린의 가장 큰 문제라고 지적 당하는게, 자마린 내에서는 코드의 재사용성이 훌륭하지만 자마린 안에서만 통용되는 말이라고 한다. 즉, 그 코드가 외부 솔루션에는 아예 쓸모 없은 코드가 되어버림.(기본적으로 C#이다. 자바도 아니고)

 

4. 그 결과, 구글등에 소스가 별로 없다. 사실 이게 내가 자마린을 버린 가장 큰 이유. 개발자는 자고로 구글에서 모든 정보를 얻고 개발 테크닉을 배우게되는데 구글에서 뭐하나 찾는데 시간이 걸린다면 그것만큼 해비 코스트가 없다. 이것은 스스로 책보고 공부한다고 해결될 문제가 아닌 문제다. 

 

5. 또한가지 자마린이 망작느낌이 나는 이유는 이 마져도 결국엔 안드로이드 개발언어인 JAVA와 아이폰 개발 언어인 오브젝트C를 알아야한다는 것이다. (-_-....)

 

6. 추가적인 단점은 이 솔루션은 월단위 돈이 나가며 비싸다.

 

 

자 이제 마지막으로 네이티브 앱.

 

1. 개발비용은 애플은 라이센스 비용만 1년에 12만원 정도, 안드로이드는 돈이 안들고 마이크로소프트는 (개발할 일이 있을까 싶지만) 정식으로 돈 다주고 사면 뼛속까지 빨아먹는 구조라고 한다.

 

2. 각자의 언어들에 최고의 지원을 하는 편. 아이폰 개발하고자 하는 사람들에게 주어지는 툴과 그 언어에 대한 지원, 마이크로소프트도 마찬가지로 비주얼 스튜디오와 개발지원등. 즉, 상식적으로 아는 그 앱을 만들 수 있다. 단, "그 플랫폼 안에서만 구동되는"이란 조건 하에.

 

3. 상호간 언어적 호환성이 거의 없기 때문에 똑같은 앱을 만들어도 아이폰,안드로이드는 완전히 다시 만드는 수준이 될 수 밖에 없다.호환이 되는건 객체지향언어라는 개념뿐.

 

4. 각각 지역구에는 구글등에 엄청나게 많은 셈플과 자료들이 존재하고 다만들어진 앱의 완성도는 그야말로 "네이티브"이기 때문에 두말할 여지가 없다.

 

 

 

결론이 뭐냐면.

 

결국 모두 다 공부해야한다. 꼼수 부리지마라.

 

...

 

..

 

.

 

라고 결론 내긴 좀 아쉬우니까 평을 좀 하자면...안드 VS iOS 판세를 보면 향후 5년 이내에 둘 중 하나가 무너질 가능성은 제로다. 더욱이 이 둘을 통합할 가능성은 더더욱 없으며 특히 (내 생각에) 애플쪽이 더 외딴 섬으로 노를 저을 가능성이 높다. 심지어 자기네 개발언어였던 오브젝트C까지 집어 치우고 이번에 새로운 언어를 또 출시했을 정도니까. 보안적인 문제나 앞으로 스마트폰이 항상 이모양대로 갈 가능성도 크지 않기 때문에 결국 한 가지 접근법으로 서로 다른 모양의 디바이스를 제어한다는것은 솔직히 쉽지 않은 시도라고 본다. (물론 나는 그것을 이세상의 IT 대천재들께서 해결해주실꺼라 믿었다 씨팔놈들아 배신자들) 최소한 자바스크립트 하나로 지구정복이 가능할꺼라 믿는 나의 신념은 조금 약해졌을 뿐이다........(....) 앱 개발비가 나름 그래도 안드 아이폰 각각 수천만원 단위인게 이해가 간다. 

 

또는 좀 덜 완벽한 앱을 만드는건 어떤가 싶기도한데, 뭔가 대단하지 않아서 싫다. 이 세상에 없는걸 만드는데 버그는 인정해도 대단한 느낌이 없는건 별로야. 지구를 정복한 윈도우도 블루스크린이 뜨는것을 막을 순 없지 않았던가. 어쨋든 단일 언어로 모든 것을 개발할 수 있다는 것이 헛된 꿈이라는것을 알기 까지 1년이 걸렸다.







'모과이 > 스크랩' 카테고리의 다른 글

[번역] 좋은 코딩을 위한 13 가지 간단한 규칙  (0) 2017.04.03
IIS 계정 추가  (0) 2015.10.24
SVN보다 Git가 더 좋을까?  (0) 2015.08.03
소스분석 방법  (0) 2014.12.31
각종 오픈소스 제약사항 관련  (0) 2014.10.12
Posted by 모과이IT
,

http://studyforus.tistory.com/63

Posted by 모과이IT
,

출처 : http://www.allofsoftware.net/2011/10/svn-git.html


요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.
  1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
  2. Github를 써야 한다면 Git를 써라.
  3. 그외에는 모두 SVN을 써라.
기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 
CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 
일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.
  • Folder공유 타입 - RCS, SCCS
  • Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
  • 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs
폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.
또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.
  • Offline에서 자주 개발을 해야 할 때
  • Git 기반의 Open source를 이용한 개발을 해야 할 때
  • Git 기반의 Open source 프로젝트에 참여할 때
  • Github을 써야 할 때
이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.
SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.
SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

[Git 관련 참고자료]


'모과이 > 스크랩' 카테고리의 다른 글

폰갭, 자마린, 네이티브앱 개발 경험담  (0) 2015.11.07
IIS 계정 추가  (0) 2015.10.24
소스분석 방법  (0) 2014.12.31
각종 오픈소스 제약사항 관련  (0) 2014.10.12
폰갭강좌  (0) 2014.06.02
Posted by 모과이IT
,

써니의 오픈소스 분석 가이드 (참고만 하세요~)

한동안 접고 살던 Spring framework오픈 소스를 다시 꺼내 분석한다면 나는 어떻게 할까? 일단 생각해보고 정리를 하자니... 장강의 뒷물의 앞물을 밀어낸다고 - 이게 아닌가? 아무튼 생각이 유실될 우려가 있어 그냥 냅다 적어보기로 한다.

남의 소스를 분석한다는 것은 남의 생각 속을 여행하는 것에 비유할 수 있다. "여행"을 하려면 무엇이 필요한가? 아니, 길을 잃지 않기 위해서는 무엇이 필요한지 생각해보자. "GPS"과 "지도"가 필요할 것이다. 그리고, 내가 가야할 길은 아직 가보지 않은 길이기 때문에 욕심 부리지 않는 '자세'를 준비하자. (무심결에 나침판이라고 적고 보니... 21세기인데.. 라는 생각이 들어 고쳤다.)

항해(navigation)를 시작하기 전에 준비물이 잘 갖추어 있는지 확인해 보자.

1. GPS (Global Positioning System)
프로그래머에게 필요한 GPS는 당연히 실제 물리적인 장치가 아니다. 소스를 분석할 때, 내가 어떤 소스를 분석하고 있으며, 다음으로 어느 소스를 분석해야 하는지를 판단하는데 필요한 도구이다.

내가 생각하는 소스 분석에 필요한 GPS 도구들은 다음과 같다. 프로그래밍 언어론에 대한 기초 지식 혹은 프로그래밍 언어 문법에 대한 정확한 지식이다. 언어를 모르는 사람이 소스를 분석하겠는가 라고 반문하겠지만, 남의 소스를 분석하다 보면 평소에 모르던 키워드나 연산자 혹은 문법을 마주치는 법이 생기게 마련이다. 막다른 골목에 다다르는 것과 같은 현상이 벌어진다. 즉, 머리속이 하얗게 지워진다. 이전까지 분석한 게 다 머리 속에서 지워지고 만다. goto 명령어는 자바에도 있다. 안쓸거라고 생각지 마라. 다중 루프에서 고속으로 탈출하기 위해 사용되는 경우도 간혹 있다. final 이 클래스에 붙어 있을 때 그 의미를 파악하지 못하거나, public 수식어가 없는 클래스의 의미를 모르면 오픈 소스 설계자의 진의를 절대 파악할 수 없다. 문법 공부할 때 뒷장은 건너뛴 사람은 분석하다가 오도가도 못하는 신세에 빠지는 경우가 많다. 언어의 문법을 일부만 알고 오픈 소스를 분석하는 것은 단어 몇개만 배우고, 사전도 없이 뉴욕 한복판에서 엠파이어 스테이트 빌딩을 찾는 것과 같다.

다음으로 상속과 합성에 대한 개념이다. 상속과 합성은 이정표에 해당한다. 객체지향이건 절차지향이건 간에 소프트웨어는 항상 '부품'들이 조립되는 방식으로 구축된다. 그런데, 상속과 합성의 개념을 제대로 모르면 위아래로 이동해야 하는지, 좌우로 움직이야 하는지 모르게 된다. 그리고 코드를 따라가다가 어떻게 되돌아 가야 하는지 모르게 된다. 미로에 빠지고 말 것이다. 그냥 상속만 익히면 된다고 생각지 말라. 인터페이스와 구현체 간의 관계 등을 모르면 지나쳐도 되는 코드와 코드들의 집합인 모듈 단위를 전혀 알아 볼 수 없게 된다. 코드는 단순히 작은 메소드들의 무수한 나열이 아니다. 작은 단위들이 모여 큰 단위를 이루고 작고 큰 구조를 표현하기 위해 인터페이스 상속과 패키지 개념들이 있는 것이다. 모르고 보면 아무리 보고 또 봐도 까만 건 코드, 하얀 건 배경일 뿐이다.

리팩토링은 몰라도 된다. TDD도 필요 없다. 다만, 디자인 패턴은 알아야 한다. 패턴을 이해하는 것은 운전 면허 시험을 배울 때, 교차로와 순환로 등 다양한 도로 형태를 배우는 것과 동일하다. 사람은 익숙한 지형이나 형태를 보면 깊이 생각할 필요도 없이 반사적으로 움직일 수 있다. 소스 분석도 이와 같다. 패턴을 모르면 그만큼 분석하는데 드는 시간이 기하급수적으로 늘어난다.

이클립스 혹은 IntelliJ 같은 IDE 사용 방법에도 능숙해야 한다. 탐색기를 이용해서 소스를 하나씩 열어보거나, notepad++ 로 수많은 소스를 열어 본다면? 노가다로 시간 낭비하지 말자. 상위 클래스, 하위 클래스, 참조 위치 등등 단축키만 알면 아무리 멀고 먼 위치도 워프(warp) 할 수 있는 순간이동 능력을 갖출 수 있게 된다. 다만, 앞서 말한 상속과 합성 개념이 머리에 박혀있지 않으면 금새 지나온 길을 잃어 버리게 된다.

API와 라이브러리에 대한 경험... 코드를 따라가다 보면 자칫 너무 깊이 파서 땅속으로 파고 들 수 있다. 궁금하다고 클릭하다 보면 어느새 JDK 소스를 보고 있다는 사실 조차 모르게 된다. 그럴리 없다고 생각지 말라. JDK를 설치하면 소스도 따라온다. IDE에 decompiler를 설치해두면 클릭 한 번에 지하세계로 떨어진다. 라이브러리도 마찬가지인데, 자칫 내가 프레임워크를 분석하고 있는 건지 라이브러리 코드를 분석하고 있는 건지 혼란에 빠지게 된다. 더 심하면, 프레임워크가 의존하고 있는 라이브러리와 프레임워크를 구분하지 못하는 일체의 경지에 빠지게 된다.

2. 지도 (map)
무턱대고 서울 간다고 지도도 없이 나서면, 어느 산골 구석이나 경찰서 유치장에서 발견될 수도 있다. 오픈소스를 막무가내로 이해하려는 개발자라면, 소프트웨어에 대한 환멸을 느끼고 IT 업계를 영영 떠날 수도 있다.

가급적 분석하고자 하는 오픈소스에 대한 설계에 대해 많은 정보를 제공하는 책을 구해야 한다. 오픈소스를 창작자가 서술한 책이면, 창시자의 철학을 옅볼 수 있기 때문에 가장 좋고, 없다면 가장 두꺼운 책을 사야 한다. 두꺼울수록 다루는 부분이 많기 때문에 분석하면서 낯선 코드를 만나는 경험이 줄어든다. 책을 통해 큰 흐름과 전체 얼개를 파악하면 많은 시간을 절약할 수 있다. 책을 사기 싫다면 해당 오픈 소스의 홈페이지의 introduction, user's guide, 그리고 각종 reference 문서를 최대한 많이 읽어두면 좋다. 책도 안사고, 홈페이지에도 안 가 봤다면 분석을 포기해라. 당신이 수재 이상의 머리를 가지고 있지 않다면... 샹 폴리옹인가? 그럼, 구글 가라.

영어가 싫다면 해당 오픈 소스에 대해 언급된 국내 블로거들의 글을 최대한 검색해서 많이 읽어라. 그 어떤 책이나 블로그 글도 오픈 소스 전체를 설명할 수는 없지만, 부분에 대한 이해만 해도 길을 찾는데 큰 도움이 될 것이다. 그리고, 사전에 해당 오픈 소스에서 많이 쓰이는 클래스/ 메소드 명칭에 익숙해지면 좀 더 소스가 자연스럽게 읽힌다. 인간의 두뇌는 익숙한 것일수록 해석 속도가 매우 빨라지기 때문이다.

마지막으로 종이와 연필을 준비해라. 소스를 분석하면서 눈에 띄는 소스 파일 명칭과 메소드 명칭들을 적고, 클래스 다이어그램과 시퀀스 다이어그램을 그려본다. 직접 지도를 만들라는 것이다. 종이에 적으라는 이유는 우선 컴퓨터 화면에는 소스만 띄워놓아야 집중이 잘되고 덜 산만하다는 것이고, 사람 머리는 손으로 무언갈 쓰거나 할 때 논리회로가 잘 돌아간다. 참고로 Robert C Martin 선생님이 말씀하시길 UML을 그리는데 있어서 가장 좋은 도구는 종이와 연필이라고 했다.

내가 선호하는 오픈 소스 분석 방법은 디버거(debugger) 혹은 로그 분석을 해보는 것이다.어플리케이션을 디버그 모드로 실행하면서 stack trace을 추적해보거나, 분석하고자 하는 위치에 break point를 걸어둔 후에 정지 시키고 나서 해당 위치가 실행되기 이전과 이후를 분석한다. 때로는 일부러 예외를 발생시킨후에 로그를 분석하기도 한다. 대다수의 오픈 소스는 debug, trace 로그 출력을 제어할 수 있기 때문에 상당히 긴 로그를 분석할 각오가 되어 있다면, 로그 출력 수준을 높이고 (TRACE 레벨) 프로그램을 실행시켜 보는 것도 한 방법이다. 당연히 log4j 혹은 logback 환경 설정을 선행하는 것은 필수 작업이다.

출처 : https://www.facebook.com/sunny.kwak.90/posts/372869479504711


'모과이 > 스크랩' 카테고리의 다른 글

IIS 계정 추가  (0) 2015.10.24
SVN보다 Git가 더 좋을까?  (0) 2015.08.03
각종 오픈소스 제약사항 관련  (0) 2014.10.12
폰갭강좌  (0) 2014.06.02
Windows Event Log 서비스 시작안될때  (0) 2014.04.21
Posted by 모과이IT
,


GPL&middot;AGPL&middot;MPL&hellip;한눈에 보는 오픈소스SW 라이선스.pdf


'모과이 > 스크랩' 카테고리의 다른 글

SVN보다 Git가 더 좋을까?  (0) 2015.08.03
소스분석 방법  (0) 2014.12.31
폰갭강좌  (0) 2014.06.02
Windows Event Log 서비스 시작안될때  (0) 2014.04.21
포팅(porting)이란?  (0) 2014.04.12
Posted by 모과이IT
,



영상처리관련프로젝트.pptx




1. 영상인식을 이용한 게임 자동사냥 

㈜아이소프트 

MMORPG “데카론” 게임 자동사냥 예로 설명


2. 스마트폰용 골프 스코어카드 OCR 시스템

경북대학교 산업대학원 석사 졸업 논문

"스마트폰용 골프 스코어카드 OCR 시스템구현"이란 주제로 경북대학교

가상현실연구실(VR Lab) 연구실의 정순기교수님의 지도로 올해 6월에 최종 통과된 논문입니다.

간략한 설명드리자면 골프 스코어카드를 스마트폰 카메라로 촬용을 하면 촬영된 

이미지 파일을 성능좋은 PC 서버로 전송하여 OCR 인식처리(KNN 기계학습사용)을 하여 OCR된

숫자 데이터를 다시 스마트폰으로 소켓으로 보내주어는 시스템입니다. 장점으로는

네트워크화하여 멀티 플랫폼(안드로이드,아이폰 등의 장치)에 동시에 사용할수 있는 독립적인 시스템을 제안하였습니다.

'모과이 > 포트폴리오' 카테고리의 다른 글

iPhone 관련 프로젝트  (0) 2014.10.04
안드로이드 관련 프로젝트  (0) 2014.10.04
전자참고서 프로젝트  (0) 2014.10.04
해외셀프쇼핑브라우저  (0) 2014.10.04
해적사냥꾼(윈도우버전)  (0) 2014.10.04
Posted by 모과이IT
,





'모과이 > 포트폴리오' 카테고리의 다른 글

영상처리 관련 프로젝트  (0) 2014.10.04
안드로이드 관련 프로젝트  (0) 2014.10.04
전자참고서 프로젝트  (0) 2014.10.04
해외셀프쇼핑브라우저  (0) 2014.10.04
해적사냥꾼(윈도우버전)  (0) 2014.10.04
Posted by 모과이IT
,