카테고리 보관물: Life

[캠핑후기] 포천 낭만가족캠핑장

포천 낭만 가족 캠핑장


  • 일정: 2016. 06. 04~2016. 06. 06 (2박 3일)
  • 누구랑: 안지기 아는 사람 가족과
  • 장점: 수영장, 인공 계곡(?)
  • 단점: 화장실과의 거리, 진입로 및 모래언덕

지난 주말 첫째가 캠핑, 캠핑 노래를 불러 다른 가족과 함께 캠핑을 다녀왔습니다.
같은날 캠핑하는 분들이 모두 매너가 좋은 분들만 모여 있었는지 아주 조용하고 편한하게 캠핑을 하고 왔습니다.

오랜만에 별도 많이 보고 나무도 많이 보고 했더니 힐링 되는 듯한 느낌이었습니다. 아이들과 너무 열심히 놀아서인지 몰라도 팔에 근육통도 생기고…^^

한가지 아쉬웠던 점은 진입로 및 캠핑장 내부 도로가 모래로 되어 있고 파인곳도 많아서 아이들이 미끄러지거나 차가 미끄러져서 휠스핀을 하는 것을 많이 봤습니다. 차는 상관 없었지만 아이들이 위험한게 조금 아쉬웠습니다.

그래도 최근에 일에 치여 살다가 나가서 콧바람을 쐬니 아주 좋았습니다.^^

2015년 정리

2015년 정리


2015년 한해는 2015년이 된지 얼마 안된거 같은데 마무리 되는 것처럼 빠르게 지나갔습니다.

블로그에 2015년 초에 게시한 내용을 토대로 정리해봤습니다.

2015년 목표


습관

  • 일반(20권)
  • 전공(10권)
  • 원서(10권)

나를 위한 투자

  • 배드민턴
  • 크로스핏
  • 등산
  • 자전거

가족

  • 아버지와 매달 목욕탕 함께 가기
  • 일주일에 하루는 가족의 날로 정하기

프로그래밍

  • AppStore에 어플리케이션 판매 하기
  • 자료구조
  • 알고리즘 정리
  • C# 개발 해보기
  • Mac용 어플리케이션 만들기

기타

  • 신규 아이템 확인

2015년 결과


습관

달성률 40%

일반서적(10권), 전공서적(5권), 원서(1권)

목표치보다 많은 책을 읽지는 않았지만 전반적으로 2014년에 비해 독서시간이 늘었습니다. 다만 원서 부분은 아직 저조합니다. 원서를 읽는 능력이 아직 많이 부족하기 때문에 초등학생, 중학생 수준의 책을 읽고 있습니다.

전공 서적은 개발 방법론과 소프트웨어 품질 향상을 위한 주제를 주로 읽었습니다.

일반 서적은 여행과 자기계발과 관련된 분야를 읽었습니다.

나를 위한 투자

달성률 20%

배드민턴, 크로스핏, 등산, 자전거등 여러 운동들을 하고 싶었지만 시간이 없다는 핑계와 부상으로 인해 대부분을 포기 했습니다.

그렇지만 약 5개월정도 1주에 3일 정도는 꾸준하게 웨이트 트레이닝을 하였습니다.

가족

  • 아버지와 매달 목욕탕 함께 가기
  • 일주일에 하루는 가족의 날로 정하기

달성률 0%

가족과 함께 하는 부분은 둘째가 나오면서 더욱 신경 써야 되는 부분이지만 가장 못한 것 같습니다. 2016년도는 더욱 노력하여 가족과 함께 하는 시간을 늘려야 될 것 같습니다.

프로그래밍

달성률 40%

[앱스토어 등록]
애플스토어에 개인용 어플리케이션은 총 2개를 등록하였습니다.

1. MERS Korea

한국에 메르스가 퍼지는 시점을 기반으로 개발하여 주춤할 시기에 개발을 완료 하였습니다. 심사중 반려되어 재심사를 요청하는 과정이 생각보다 길어져 출시가 늦었습니다. 그렇지만 서버와 클라이언트를 모두 작성하고 앱 제작 처음부터 끝까지 했기 때문에 재미는 있었습니다.

2. HOW2TOEFL

대학 친구가 기획을 하고 그 기획안대로 개발한 앱입니다. 원어민을 통해서 음원을 녹음하고 녹음된 음원 파일을 재생하는 형태로 하였는데 생각보다 시간이 많이 걸렸습니다.

판매 결과는 최악이지만 많은 교훈을 얻을 수 있었습니다.

[자료구조, 알고리즘 정리]

자료구조와 알고리즘은 따로 정리는 못했고 프로젝트오일러을 통해서 지속적으로 공부를 하고 있습니다.

[C# 개발 해보기]

회사에서 필요로 하는 타이머 어플리케이션을 개발했습니다. 간단한 어플리케이션이지만 요청사항에 까다로운 부분이 있어서 애매한 부분이 있었습니다.

다시 느낀 결론은 UI프로그램은 힘들다.

[Mac용 어플리케이션 만들기]

화면이 없는 OSX용 프로그램을 개발했지만 화면이 있는 것은 하지 않아서 안한것으로 간주하겠습니다.

기타

[신규 아이템 확인]

앱 개발의 필요성을 느끼면서 지속적으로 모니터링하고 메모하고 생각하고 있습니다. 이 글을 쓰고 있는 시점에도 어떤 어플리케이션이 좋은 아이템이 될지 생각하고 있습니다. 아마 다음에 개발하는 어플리케이션은 단순한 게임이 되지 않을까 하는 생각입니다.

결론

1년이란 시간은 연초에 보면 참으로 긴 시간인거 같지만 연말에 보면 정말 빠르게 지나가는 시간인거 같습니다. 새삼 시간관리및 자기관리의 필요성을 느낍니다.

2016년은 보다 현실적은 계획과 세운 계획을 철저히 실천하는 것을 목표로 해야겠습니다.

이상입니다.

[후기] 좋은 코딩 나쁜 코딩

읽기 쉬운 코드가 좋은 코드다.

  • 제목: 좋은 코딩 나쁜 코딩
  • 저자: 박진수
  • 출판사: 한빛미디어
  • 기간: 2015.09.28~2015.09.30

키워드

코딩 스타일(Coding Style)

  1. 논리를 표현하는 방식
  2. 알고리즘을 표현하는 방식
  3. 문장을 표현하는 방식
  4. 표현식을 표현하는 방식

본것

  • 함수와 함수 사이는 빈줄을 추가하여 가독성이 좋게 한다.
  • 프로그램의 주석에는 작성자, 파일명, 목적, 사용방식, 사용 파일, 제한사항, 오류처리, 이력사항을 포함하도록 한다.
  • while문의 조건 판별부에 대입 연산을 사용하지 않는다.
  • 연산자 우선 순위만 믿지말고 괄호를 적용하라.
  • 나눗셈 연산에는 주의하라
  • 변수명 및 함수명을 정의 할 때는 주의해서 작성하라.

깨달은것

C언어 스타일의 가이드로 되어 있어 보기도 편했고 모르던 내용도 많이 있어 도움이 되었다.

그렇지만 책이 나온지 10년정도 되어서 코딩 가이드에 약간의 변화가 있을 수도 있을 것 같다. 최근에 본 코딩 스타일 가이드 강좌(https://cleancoders.com/) 에서 나오는 내용과 상반되는 내용이 많이 있다.

책의 저자 및 클린코드의 강사중 어느 쪽을 반드시 따라야 한다는 규칙은 없을 것 같다. 자신 또는 팀의 성격에 맞는 방식을 따르면 좋을 것 같다는 생각이다.

예를 들면 책의 내용중에 버전 변경 이력에 대한 내용을 작성자, 변경일, 변경내용을 기록해야 한다고 설명되어 있다. 그렇지만 클린코드의 저자는 변경 내용에 대한 이력 관리는 버전 관리 시스템에서 하기 때문에 소스코드에 불필요한 내용을 적지 않아도 된다는 내용을 설명한다.

그리고 변수에 대한 주석도 상반된다. 코드를 이해할 수 있다면 별도의 주석을 필요 없다는게 클린코드의 설명이고, 저자는 변수에 주석을 달아 놓으면 다른 사람이 작업할 때 훨씬 편리하다라는 내용이다.

코딩 스타일에 관한 자료를 검색하다가 가장 마음에 와닿는 글을 게시한 블로그가 있었다.(주소는 생각나지 않음)

그 블로그에서는 주석을 달기 전에 자신이 작성한 코드에 혼란을 일으킬 수 있는 부분이 있는가 또는 자신의 코드의 잘못된 부분을 인식시키기 위해 주석을 작성할 것인가를 생각해보고 주석을 추가하라고 한다.

개인적으로 블로그에 나온글이 맘에 든다.

Objc 로 코딩을 하다보니 viewWillDisappear(), viewDidLoaded() 와 같은 함수와 TableView를 구현하기 위해 상속받는 함수들의 이름이 짧지 않고 함수명에 이 함수는 무엇이다라는 것을 정의한 것처럼 작성이 되어 있다. viewWillDisappear() 함수는 뷰가 사라질 것이라는 의미를 함수명에 내포하고 있어서 LifeCycle을 확인하지 않아도 대략적인 시점을 예측할 수 있다.

함수명이 무조건 길어진다고 좋은 것만은 아니지만 가독성에 도움을 준다면 어느정도의 길이는 상관이 없다고 생각이 된다. 그리고 최근에는 IDE 환경이 좋아서 소스 코드 전체를 키보드로만 입력하지 않아도 되기 때문에 가능한 일인것 같다.

적용할 것

  1. 현재 작성중인 코드의 변수명 및 함수명이 어떤 내용을 의미하는지를 내포하고 있는지 확인한다.
  2. 최신의 코딩 스타일이 무엇인지 확인한다.
  3. 본문에 포함된 코드중 이해가 안되는 코드는 실행해본다.
이 글은 read 카테고리에 분류되었고 태그가 있으며 님에 의해 에 작성되었습니다.

[후기] 앱스토어 골드러시

  • 출판사: 이지북
  • 저자: 정태훈
  • 시작일: 2015. 09. 04
  • 종료일: 2015. 09. 07

한줄요약

 모바일 앱이라는 것을 통해 나름의 성공을 할 수 있다는 약간의 성공 신화와 같은 느낌. 

앱은 개발자가 만들지만 누구나 자신만의 아이디어를 이용해서 앱을 만들 수 있다.

내용 정리

저자가 무서운카메라 라는 어플리케이션과 iCan'tTalk 라는 어플리케이션을 출시하면서 스스로 조사하고 프리랜서 개발자와 디자이너를 섭외하는 과정들이 상세하게 기술되어 앱을 만들고 싶은데 어찌해야 되나 다른 사람에게 좋을 것 같다는 생각이다.

개발자로서 책의 내용중에 가장 마음에 와닫는 말은 앱을 기획한 사람이 정확하게 어떤 기능이 있는지와 어떤 디자인을 원하는지 디테일하게 설명하는 부분이다.

파워포인트를 이용해 UI화면을 개발자에 전달하면서 버튼의 상태가 어떻게 변경되고 기능이 어떻게 된다라는 설명이 너무 자세하게 작성되어 개발자로서 볻받아야 된다는 생각이 들었다.

그리고 디자이너에게 전달하는 내용은 샘플 이미지 같은 것을 넣어 디자이너에게 자신이 원하는 바를 정확하게 전달하는 부분이 좋았다.

마지막으로 최고로 좋은 점은 누구나 어플리케이션을 개발할 수 있다는 내용이다.

아쉬운점

책의 후반에 가면 애플 개발자 자격 신청 및 앱 등록하는 절차를 너무 자세하게 적었다는 느낌이 든다. 스크린샷이 많이 첨부되었지만 애플 사이트를 캡처한 내용은 사이트가 자주 바뀌면 있던 메뉴가 사라질 수도 있는거라 차라리 블로그나 출판사 홈페이지를 통해 지속적으로 업데이트 하는게 좋지 않았나 하는 생각이다.

현재 나의 생각

애플이 개발자에게 무한한 시장을 열어줬다는 생각은 내가 앱스토어에 회사용 어플리케이션을 출시하면서부터 들은 생각이다.
이번에 친구와 기획해서 제작한 HOW2TOEFL을 앱스토어에 출시하면서 약간의 돈벌이는 되겠지라는 생각을 했었는데 결과는 처참하다.

책이 쓰여진 시점이 2010년도인데 2015년도인 지금은 앱스토어에 무수히 많은 어플리케이션이 있다. 어플리케이션이 아무리 좋더라도 사용자가 그 어플리케이션이 존재하는지 모른다면 다운로드 하지 않을 것이다.
특히 흥미 유발성 어플리케이션이 아니라면 더욱더 마케팅이 중요하지 않은가 하는 생각이다.

이 글은 read 카테고리에 분류되었고 태그가 있으며 님에 의해 에 작성되었습니다.

Java 웹 개발자의 학습 로드맵

Java 웹 개발자의 학습 로드맵

동영상 정보


강의감상평


이런 강의를 내가 취업하는 시점에 찾아보지 못하고 지금 본게 조금 아쉽다. 만약 내가 이 강의를 듣고 장기 과정의 흐름에 따라 진행 했으면 현재 보다 좋은 프로그램을 작성하는 개발자가 되었을거 같다는 뒤늦은 후회가 든다.

현 시점에서 내가 부족한 부분을 집어보자.

1. Java

자바는 2010년도부터 지금까지 꾸준히 내가 사용하는 언어다. 버전도 1.5에서 1.8까지 정식버전이 릴리즈가 되었고 조만간에 1.9가 릴리즈가 될 것 같다. 관심을 계속 주려고 하지만 현재 업무가 자바와 관련이 없어 뒷전으로 밀려있다. 아직도 볼게 많고 배울게 많이 남아 있다. 아마도 프로그래머라는 직업이 끝날때 까지는 계속 공부해야 될 것 같다.

2. Servlet

웹에서 사용하는 단순 요청 & 응답에 대한 처리만 하는 형식으로 공부하다보니 서블릿 생명주기 또는 구성을 제대로 공부한 적은 없는 것 같다.

3. 개발방법론

어떤 개발 방법론을 적용해서 현재 개발하고 있는지 모르고 과거에도 어떤 방법론을 썼는지 모르는걸 보면 개발 방법론에 대해서는 완전 무지하다.

4. OOP & 디자인 패턴

OOP. 디자인 패턴은 계속 공부를 해야 어느정도 알 수 있을 것 같다. 현시점에서는 감도 안온다.

5. Spring

2.5부터 시작했는데 정확하게 어떤 것을 하는지 모르겠다. 그냥 사용법 그리고 사용하면 편하다 정도로 생각하고 있다. 다시 한번 공부를 해야겠다.

6. ORM

Mybatis만 사용해서 Hibernate또는 JPA를 사용할 기회가 없었다. 개인적으로라도 공부해야겠다. 단순 사용법이 아닌 어떤 구조, 어떤 생각으로 이 프레임워크가 만들어졌는지를 생각하자.

7. 협업도구

지금 개발과정에서는 Mantis를 사용하고 있는데 단순 버그 트래킹 정도로만 사용하고 있다. 기회가 된다면 협업도구를 사용해봐야겠다.



단기과정


취업이 최우선이다.

취업을 먼저 한 후 장기 과정을 진행한다면 문제 없다. 그렇지만 장기과정을 따라하지 않고 현 위치에 머무르는 것은 한심하다.

[무조건 취업을 위해 준비해야하는 것들]

  • Java

  • eclipse

  • Spring framework

  • Mybatis

장기과정


  1. 통합개발도구 (eclipse, Intellij) [**]
  2. Java (최종까지 가장 중요하게 가지고 가야한다.) [*]
  3. Servlet + JSP [**]
  4. Build Tool [*]
    • Ant
    • Maven
    • Gradle
  5. 버전 관리 도구 [**]
    • SVN
    • CVS
    • Git
  6. 개발 방법론
    • TDD(테스트 주도 개발) [*]우선은 원칙대로 따라하고 자신에 맞게 변경하도록 한다.

      TDD가 내 몸에 익히면 야근 시간을 줄일 수 있다.

      TDD는 수영으로 치면 자세로 생각할 수 있도록 한다.

      처음 연습은 기본 기능으로 시작한다. String, Date등

  7. HTML & CSS & JAVASCRIPT [**]서버사이드 웹 개발자라면 기본적인 개념만 알고 있으면 된다.

    그렇지만 JAVASCRIPT를 언어적인 측면에서 접근한다면 도움이 된다.

  8. Model1 방식을 사용하여 웹 페이지 개발
    • Spring 또는 Struts가 나오게 된 계기를 알 수 있다.
    • MVC 패턴이 왜 편한지를 알 수 있다.
  9. OOP & 디자인 패턴 [*]
    • 다른 사람들과 다른 방식의 접근이 가능하다.
  10. Spring framework
    • 기본적인 사상들에 대해 먼저 습득하고 API를 확인한다(Dependency Injection)
  11. 생 JDBC 연결 및 중복 코드를 제거하면서 Spring-jdbc와 비교를 한다. [*]
    • Callback interface
    • Class 이념.
  12. JDBC
    • MyBatis
      • 학습 비용 낮고
      • SI에 사용
      • 테이블 정규화가 불가능
    • ORM(JPA, Hibernate) : 개인적으로 학습을 하여 인지를 하도록 한다.
      • 학습 비용 무지 높다
      • 솔루션, 자체 서비스 개발
      • 테이블 정규화가 가능
      • 생성산 향상이 크다
  13. 협업도구 [*]
    • JIRA
    • REDMINE

Git, 분산버전 관리 시스템 요약

책정보


  • 출판사: 인사이트
  • 저자: 트라비스 스위스굿
  • 번역: 김성안, 이두원
  • 기간: 2015. 08. 06

책 중요 내용 정리


SVN만 사용하다 Git을 회사 버전 관리 시스템으로 사용하면서 온라인의 예제 또는 내용만 읽다 체계적으로 정리된 Git에 대한 내용을 볼 수 있어 좋았습니다.
책 내용중 상당 부분이 예제를 통해 명령어를 설명하는 부분인데 기본 기능을 설명하기에는 부족함이 없었습니다.

Git방식으로 버전 관리하기


[무엇을 저장해야 하나?]
프로젝트를 진행하는 데 필요한 전부, ‘X가 없어도 프로젝트에서 작업하는 데 지장이 없는가?’ 라고 판단을 했을때 스스로 질문하고 문제가 있다면 프로젝트 관리에 포함한다.

[커밋 로그 메시지에 어떤 내용을 넣어야 할까?]
커밋 메시지는 메시지만으로도 의도를 드러내도록 커밋의 ‘이유’를 설명하는 모든 메타데이터를 포함해야 한다.

잘 작성된 커밋 메시지의 예
– 가동성을 위해 중첩된 if/elseif 구문을 switch 구문으로 변경
– 유용하지 않다고 검증한 실험 코드 삭제
완벽한 로그 메시지를 만드는 데는 장인정신이 필요한다.

브랜치(Branch) 이해


기본적으로 하나의 브랜치 즉 마스터 브랜치만 사용해도 버전 관리 시스템이 제공하는 모든 이점을 얻을 수 있다. Git을 사용하면 이력을 추적하고 다른 개발자와 협업할 수 있다. 또한, 갑자기 중요한 파일이 지워지는 상황도 대처 할 수 있다. 하지만 이 정도로 Git을 사용한다면 마치 경주용 자동차를 타고 출퇴근을 하는 것과 같다. 목적지에 도착은 하겠지만, 출근시간인 오전 8시에는 결코 경주용 차의 성능을 제대로 끌어낼 수 없다.

[브랜치 생성시 고려사항]
– 실험적인 변경 사항
– 새로운 기능
– 버그 수정

[브랜치 간의 변경 사항 합치기 ]
– 바로 합치기(Straight Merge): 하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합치기
– 커밋 합치기(Squashed Commit): 한 브랜치의 이력을 압축하여 다른 브랜치의 최신 커밋 하나로 만드는 방법
– 선택하여 합치기(Cherry-picking): 다른 브랜치에서 하나의 커밋을 가져와서 현재 브랜치에 적용하는 방법

태그 (Tag)


서브버전 사용자에게 익숙한 태그와 달리 Git의 태그는 읽기 전용이다. 읽기만 가능하다는 말은 브랜치와는 다르게 태그의 내용을 변경할 수 없음을 의미한다. (물론 Tag에서 새로운 브랜치를 생성하는 것이 가능하다.)

이 글은 read 카테고리에 분류되었고 태그가 있으며 님에 의해 에 작성되었습니다.