글쓴이 ·[개발]ChoGa(코드와 가사)의 시작 댓글 닫힘
  1. 동기: 종종 아이폰에서 코드와 악보 어플을 잘 써왔는데, 추가/편집 기능이 없더라. 여기저기 수소문해서 기타와 노래책 어플을 추천 받아서 써봤는데, 관리가 안되는 것 같더라. 그!래!서! 내가 만들어 쓰자!!!
  2. 기존 프로그램들:
  3. 입력 텍스트 형식: 내가 새로 정의할까 하다가, ChordPro 형식이 생각보다 많이 쓰이고 나쁘지 않을 것 같아서 이를 바탕으로 해야겠다.
  4. 기능 설계
    • 간단한 코드와 가사 텍스트를 입력하면 연주 시 보기 좋게 아이폰 화면에 출력한다.
    • 코드 변환 기능
    • 자동 내림 기능
    • 웹 페이지로 개발
  5. 기존 코드 악보의 가장 큰 문제는 코드의 길이. 마디 표시를 해주면 좀 낫긴 하지만 근본적인 해결책이 필요. 그런면에서 정간보를 참조하면 도움이 되지 않을까?
  6. 자동 내림 기능보다는 한 화면에 잘 보여주는 게 더 나을 듯.(다단 전환 기능?)
    화면은 iPad를 기준으로 하되, iPhone에서도 확인해보자.
  7. Source Code 공개: https://github.com/ddolgi/Choga

2016-07-15

블루투스 페달이 있었구나!!

(http://www.airturn.com/)

흠… 어케하지?

2016-09-02

한층을 더 넣어 Segment(1~3절, 전/간/후주 등)을 등록/반복 시켜볼까?

핸드폰은 포기할까?

글쓴이 ·C++ 용 JSON parser 5종 성능 비교 댓글 닫힘

libmongoclient의 JSON parser를 쓰다가 Array에 4096 개라는 제한이 있어서 다른 JSON Parser를 찾아봤다.

속도와 편리성 위주로 고르다 보니 picojson, rapidjson, libjson, vjson 이렇게 넷이 선정되었다.

  • 측정 방법: 2만여 JSON 문서를 Parsing 후 2차원 문자열 배열을 stdout으로 출력
  • 측정 기준: 실행 시간 측정
  • 결과
  시간(분:초)  Destructive  Header-only  Writable  Modifiable
 MongoDB  3:02 (Parsing Failed: 2797/20072)  X  X  O  X
 picojson  6:18  X  O  X  X
 libjson  3:50  X  X  O  O
 vjson  1:45  O  X  X  X
 rapidjson(destructive mode)  1:29  Avail  O  O  O
  • 분석: rapidjson과 vjson은 원본을 복사하지 않고 수정해서 파싱하기 때문에 가장 빨랐다.
vjson을 쓸 수도 있겠지만, 다른 프로그램의 MongoDB 모듈을 모두 대체하려면 Write 기능이 필요해서 rapidjson을 최종 선택하였다.
한 프로그램(JSON parse/modify/write)의 MongoDB 모듈을 rapidjson으로 대체 결과
   전체 실행 시간  파싱 소요시간
 MongoDB  1분1초  29초
 rapidjson  33초  7초

파싱 시간 뿐 아니라 write 시간도 단축 되었음(Building new object -> Modifying).

글쓴이 ·이호종의 ‘거꾸로 배우는 소프트웨어 개발’을 읽고… 댓글 닫힘

읽고 나니 많이 접혀있다;;;

  1. SW는 계속 변한다. 본질적 특성이다.
  2. 단기 속성 개발은 위험!
  3. 관리자는 개발을 orchestrate한다.
  4. 돌발 회의로 시간을 뺏지마라.
  5. 몰입 환경을 조성하라.
  6. Scrum 개발 방법론 소개
  7. 전사적 개발 표준?
  8. 문서화 원칙: 도움이 되나? 최신인가? 아니면 버려라.
  • 좋은 SW 개발을 위한 최소한의 실천 지침
  • SVN 사용
  • 개발 서버와 운영 서버 분리
  • 코딩 Style 및 정적 코드 자동 검사 일상화, 자동 Test 및 자동 deployment 수행
  • 이슈 트래커로 이슈와 오류 기록 및 추적, 작업 할당 및 처리
  • 공통 라이브러리/프레임워크 사용
  • 외부 라이브러리는 개인 독단적 도입 적용 금지.
  • TDD와 Unit Test, Test Automation 적용
  • Scrum으로 팀 내 역할과 책임과 프로세스 정의 및 준수
  • 설계 및 코드 리뷰: 설계 문서 작성 및 설계 리뷰 미팅, 설계 리뷰 없는 코드 리뷰 미팅 비추천
  • TDD(Test-Driven Development )를 도입해야 하는 10가지 결정적 이유
  1. 실행 코드와 테스트 코드의 분리
  2. 입력값 패턴 입력 자동화 처리
  3. 더 철저한 경계 조건 검사
  4. 클래스/ 모듈 결합 테스트 시 오류 발견 용이
  5. 리팩토링의 필수 도구
  6. ‘심리적 불안’을 ‘체계적 확인’으로 해소
  7. 웹 개발은 화면 테스트로는 작동을 100% 확신할 수 없음
  8. 문서화 작업 부담 경감
  9. 디버깅 작업 단축
  10. ‘믿음’ 대신 ‘검사’, ‘전도’ 보다는 ‘입증’
요즘 나의 고민에 대한 해결 실마리를 많이 찾을 수 있었다.
저자의 말대로 프로그래밍 처음 배울 때부터 이런 내용들을 가르치면 참 좋을 것 같다.

글쓴이 ·‘실용주의 프로그래머’를 읽고… 댓글 닫힘

공부 좀 하려고 집어 들었다.

70가지 Tip을 짚어주더라. 다 기억하기엔 너무 많고,

접어 놓는 게… 어디 보자.

  • 망치지 말고 멈추라
#define CHECK(LINE, EXPECTED )            \
{    int rc = LINE;                                \
if (rc != EXPECTED)                        \
ut_abort(__FILE__, __LINE__, #LINE, rc, EXPECTED ); }
void ut_abort(char *file, int ln, char *line, int rc, int exp) {
fprintf(stderr, “%s line %d\n’%s’ : expected %d, get %d\n”, file, ln, line, exp, rc);
exit(1);
}
…
CHECK(stat(“/temp”, &stat_buff), 0);
…

  • Refactoring Tips
    • 기능 추가와 병행하지 않는다.
    • 수시로 테스트한다.
    • 작게 나누어 실시한다.
  • 아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.
    • 필요한 주석: 설명, 인자, 반환
    • 불필요 주석: 연결 파일, 수정 기록, 파일 이름
 xUnit이라는 게 소개되어 있던데… 공부해봐?

글쓴이 ·‘프로그래밍은 상상이다’를 읽고… 댓글 닫힘

제목에 혹했다.

저 제목은 이 책을 이루는 여러 기고문 중 첫 글의 제목이었다.

무에서 유를 만드는 프로그래밍의 특성도 그렇지만, 문제가 생겨서 원인을 찾을 때 가장 상상력이 필요한 것 같다.(도데체 뭐가 문젤까…ㅋ)

호프스태터의 ‘괴델, 에셔, 바흐’ GEB?

메쉬업의 시대 – 모아보기?

하드코어 프로그래머 판별법 – 멀티스레드(get hands dirty, hand-on experience)

Integrated Development Environment(IDE)의 효용

Unit Test는 프로그래머의 운명

프로그래머의 덕목 – 대화

5억 달러짜리 버그

POV-ray!!!!!!

모든 게임은 최적의 패턴을 찾는다는 점에서 일종의 퍼즐 같다.

프로그래밍도 최적의 코드를 만드는 재미난 퍼즐 같다.