작년에 진행했던 애자일 코리아 2013 컨퍼런스 발표 영상을 공개하려 합니다.

첫번째 영상은 켄지 상의 발표입니다.

 




http://www.youtube.com/watch?v=s72ElNxaGPE


저작자 표시 비영리 변경 금지

멤버변수 타입과 클린코드

Work & Study/TechTalk 2014/03/31 11:48 posted by k16wire

코드를 리팩토링하다가 배운것 하나를 정리해 봅니다. 아래와 같은 이메일 발송을 위한 VO가 있습니다.

public class MailContents {

private String[] to;

private String subject;

private String text;

private boolean isHtml = true;


public MailContents(String[] to, String subject) {

this.to = to;

this.subject = subject;

}


public MailContents(String from, String[] to, String subject) {

this.from = from;

this.to = to;

this.subject = subject;

}


public MailContents() {

}


}


메일을 받게될 to가 Stringp[] 으로 되어 있네요. 이 객체를 만드는 서비스는 DAO를 호출한 결과로 이 값을 설정하는데 반환값이 List<String> 이어서 아래와 같은 형변환이 일어납니다.

private String[] getMailRecipients(Long projectId) {

        String[] recipients memberRepository.findRecipients(projectId);

  return recipients.toArray(new String[recipients.size()]);

}


문제는 이와 같은 형변환이 이 객체를 사용하는 곳곳에서 일어난다는데 있습니다. 반드시  String[] 배열을 사용해야 하는게 아니라면 데이터를 반환하는 메소드의 반환타입(여기서는 List<String>) 쓰는게 간결한 코드를 만들수 있습니다. 변환이 필요하다면 가능한 중간에 변환하지 말고 마지막까지 변환을 미루는게 좋습니다.



저작자 표시 비영리 변경 금지

빌드배포 시스템 JARVIS

Work & Study/TechTalk 2014/02/26 11:10 posted by k16wire

작년은 회사에서 사용할 빌드/배포 시스템을 만드느라 보낸거 같습니다. 모든 내용은 아니지만 간단하게 이 시스템을 만들면서 고민했던 내용을 정리해서 회사 블로그 README에 올렸습니다.


http://readme.skplanet.com/?p=7148


빌드 배포 시스템에 관심있는 분들 한번씩 읽어보세요.



저작자 표시 비영리 변경 금지

git 레파지터리를  가지고 통계 데이터를 뽑아줍니다. 


설치

사이트(http://gitstats.sourceforge.net/)에서 압축파일을 다운받아 적당한 위치에 압축을 해제하면 됩니다.

파이썬으로 되어 있어 별다른 설치가 필요없지만 내부적으로 gnuplot(http://www.gnuplot.info/)을 사용합니다. 그래서 gnuplot도 설치해 줍니다.

brew update

brew install gnuplot

설차하다 중간에 libpng를 찾을수 없다는 에러가 떠서 brew(http://brew.sh/)를 업데이트 한 다음 다시 설치하니 정상적으로 끝났습니다.


실행

gitstats를 실행하려면 분석할 git 레파지터리를 clone 받아야 합니다. 

gitstats [options] <gitpath..> <outputpath>

gitpath는 미리 로컬에 clone 해놓은 위치를 명시해주면 됩니다. 실행하면 결과는 html 형식의 레포트로 나옵니다. gitstats 사이트에 가보면 레포트 샘플을 확인할수 있습니다.


http://gitstats.sourceforge.net/examples/dokuwiki/activity.html


저작자 표시 비영리 변경 금지

PMI 회고

Work & Study/애자일 개발 2013/12/15 23:32 posted by k16wire

PMI 회고는 가장 흔하게 많이 사용하는 회고입니다. 사용하기 쉽지만 Minus를 쓰라고 하면 주저하는 사람들이 많습니다. Minus를 내려면 훈련이 필요합니다. Minus에 익숙치 않은 사람들에게 어떤 말을 해주면 좋을까요.

Minus는 비판이 아니라 제안입니다. 현재 상태를 개선하고자 하는 제안이자 아이디어입니다.

개선을 하려면 문제의식이 있어야 하고, 제안을 하려면 유심히 살펴봐야 합니다. 건성으로 아무 생각없이 보면 어떤 제안도 떠오르지 않습니다. 회고를 해보세요. 그러면 평소 주의깊게 관찰하고 문제의식을 갖고있는 사람이 누구인지 알게될겁니다.

 

저작자 표시 비영리 변경 금지



애자일 방법론의 하나인 스크럼에는 크게 3가지 역할이 존재합니다.:제품책임자, 스크럼마스터, 스크럼 팀  스크럼 프로세스 모델 어디에도 팀장의 역할은 없습니다. 


스크럼팀의 궁극적인 형태는 자기 조직적인 팀(Self Management Team) 입니다. 자기 조직화된 팀이 무엇입니까? 팀장이 업무를 일일이 할당하는것이 아니라 각자가 직접 자기가 할일을 플래닝하고 진행하는 팀입니다. 자기 조직적인 팀은 팀장이 없는 팀일까요.


스크럼뿐 아니라 애자일 조직에서는 전통적인 형태의 관리 팀장은 설 자리를 잃어버립니다. 애자일 조직에 맞는 팀장 리더십은 섬김의 리더(Servant Leader)입니다. 과거처럼 통제하고 관리하려 든다면 애자일의 장점은 살릴수 없을뿐더러 효과도 볼 수가 없습니다. 


스크럼 도입시 실무를 진행하는 사람에게 최대한의 권한을 주는게 중요합니다. 하지만 권한 위임은 어렵습니다. 흔히 이렇게 말하죠.

권한은 위임할 수 있지만 책임은 위임할 수 없다.

 기존 조직구조는 그대로 남겨둔채 권한만 위임한다면 팀장은 책임만 떠안게 될 확률이 높습니다. 이런 상황에 팔짱끼고 가만히 앉아있을 팀장은 어디에도 없습니다. 프로젝트에 적극적으로 개입하게 됩니다. 

그래서 가능하다면 조직구조를 프로젝트에 맞게 바꿔야 합니다. 평가체계도 바꿔야 합니다. 개인평가보다는 스크럼 팀단위 평가가 이루어져야 합니다.


스크럼과 같은 애자일 개발을 적용한다면 팀장은 손 털고 나가야 할까요? 아닙니다. 오히려 더 고도의 교묘할 정도의 관리능력을 발휘할 수 있어야 합니다. 팀원에게 (일을) 시키고 쪼고 (했는지 안했는지) 일일히 체크해서 성과를 내는게 아니라 (팀원 각자가) 스스로 알아서 일을 챙기고 꾸려나가도록 만들어야 합니다. 비유를 하자면 공부 열심히 하라고 다그치는 부모에서 스스로 공부하도록 배려하는 부모가 되야 하는 것이죠.


어렵죠. 팀장의 역할이 사라지는게 아니라 한 차원 높아지는거라고 생각합니다.

  


저작자 표시 비영리 변경 금지



요즘 사내에서 애자일 교육을 진행하면서 몇가지 스크럼에 대한 단상이 떠올랐습니다. 


스크럼 프로젝트에서는 매 스프린트마다 누가 무슨일을 할지를 스스로 정하라고 이야기합니다. 하지만 모두가 이런 방식에 익숙한것은 아닙니다. 그래서 처음 이런 방식으로 업무배정을 하게되면 팀원들은 매우 불안해 합니다. 편안함을 느끼지 못합니다. 내가 할수 있을까. 해도 되나. 


팀의 리더도 불안해 합니다. 우리 팀에는 숙련된 팀원외에 아직 경험이나 역량이 부족한 팀원들이 많은데..이런 방식으로 일하는게 맞을까? 


자율이 오히려 부담으로 작용하는 것 입니다.

이런 부분을 배려하는게 필요합니다.


저작자 표시 비영리 변경 금지


출처: http://blog.jr0cket.co.uk/2010/08/my-favourite-estimation-technique.html


어느 팀장님이 개발자에게 물어봅니다. 


이 스토리 개발하려면 얼마나 걸릴까? 

한 3일이면 될거 같은데요.


정말 3일이면 될까요? 이런 경우는 2가지 입니다. 

정말 개발을 잘하는 슈퍼 개발자이거나 개발을 많이 안해본 초보 개발자이거나

여러분이 프로젝트에 참여했다고 했을때 여러분 주변의 개발자가 슈퍼 개발자일 경우가 많을까요? 아니면 보통내지는 초보 개발자인경우가 많을까요? 당연히 후자의 경우가 많을겁니다.

이런 개발자들이 말하는 개발완료는 무엇을 의미할까요? 좀 심하게 말하면 코딩 다했고 자기 로컬 PC에서 잘 동작하면 개발완료라고 말할수도 있습니다. 하지만 이게 다가 아니죠.

  • 테스트도 해야하고
  • 개발서버 내지는 운영서버에 배포하기 위해서 빌드/배포도 해야합니다. 
  • 정적분석으로 코딩 표준은 지켰는지 
  • 잠재결함은 없는지
  • 보안진단
  • QA의 제3자 테스트
한달이라는 기간이 긴것 같지만 주말 제외하면 20일입니다. 여기에 생산성 지표를 70%로 잡는다면 약 14일이죠. 여기에 앞서 이야기한 작업들이 선행되다거나 후행된다면 실제 개발에 쓸수있는 기간은 더 줄어듭니다. 이런 상호간의 차이를 줄이기 위해서는 개발완료(Definition of Done)에 대한 의미를 프로젝트에 참여하는 사람들이 똑같이 이해하도록 하는게 중요합니다.

팀장님들 개발자가 3일 걸린다고 말하면 최대 한달 걸릴지도 모른다고 생각하세요.


저작자 표시 비영리 변경 금지

오는 9월7일 토요일 열리는 애자일 코리아 컨퍼런스 2013의 참가 신청을 받고 있습니다. http://onoffmix.com/event/18754


자세한 프로그램은 아래 포스터를 참고하세요.




저작자 표시 비영리 변경 금지



오늘 지인분과 테스트 커버리지에 대해 나눈 이야기를 간단하게 정리해봤습니다.


테스트 커버리지를 측정하는게 필요할까요?

저는 필요하다고 생각합니다. 커버리지를 측정하지 않으면 현재 가진 문제점이 드러나지 않습니다. 현재 얼마나 테스트 코드를 작성하고 있는가에 대한 대답을 할 수 있어야 합니다.


테스트 커버리지를 어떻게 가이드 해야 할까요?

N사에 있을때는 80% 이상이면 Gold, 70% 이상이면 Silver 이런식으로 등급을 나누어서 이를 각 조직에서 달성하도록 했습니다. 그러면 각 팀이 현재 어느수준에 와있고 어떤 노력을 해야 하는지 조금은 명확해 집니다. 아래 그림은 CI 서버를 이용해 자동으로 커버리지를 계산하여 등급을 보여주는 화면입니다.



테스트 커버리지를 높히기 위해서 경쟁하게 될거 같은데요

맞습니다. 그래서 커버리지를 측정한다고 해도 이를 강요해서는 안됩니다. 커버리지는 현재 테스트 코드 수준을 판단하는 한가지 지표일 뿐입니다. 


그럼 얼마나 높은 수준을 유지해야 할까요?

80%. 사실 테스트 코드를 작성하는 수준이 높아지면 테스트 커버리지는 의미가 없어집니다. 테스트 커버리지로 테스트 코드의 질을 평가할수는 없기 때문입니다. 어떻게 하면 좋은 테스트 코드를 작성할 수 있을까를 고민하는 개발자에게 '너 왜 코드 커버리지가 이렇게 낮아. 이 부분을 보강해.' 이런 식의 강요는 의미없죠.


너무 테스트 코드가 많으면 테스트 코드를 유지하느라 많은 비용이 들거 같아요.

소스가 변경되었을때 테스트가 실패하는것은 당연합니다. 그게 바로 테스트 코드가 해야하는 일입니다. 테스트 코드를 수정하는 일을 비용으로 보는것은 잘못된 시각입니다. 깨지는것, 버려지는것을 테스트 코드의 라이프 사이클로 보세요.


테스트 커버리지에 대한 논란이 있다는건 아직 테스트 코드 작성에 대한 마인드가 개발조직에 자리잡지 못했다는 징후라고 생각합니다. 숫자에 얽메이지 마세요. 

버그를 막아주는 좋은 테스트 코드를 작성하는데 집중하세요. 


참고자료

[1] http://googletesting.blogspot.kr/2010/07/code-coverage-goal-80-and-no-less.html


저작자 표시 비영리 변경 금지

glu 모델

Work & Study/TechTalk 2013/05/27 00:42 posted by k16wire

glu는 배포에 필요한 작업을 모델에 정의합니다. 이 모델은 json 형태로 되어있으며 모델이 갖는 정보는 3가지입니다.: 애플리케이션을 배포하기 위해서 무엇을, 어디에, 어떻게 할것인지  

튜토리얼에 들어있는 샘플 모델을 보겠습니다.


{
  "fabric": "prod-chicago",
  "entries": [
  {
   "agent": "node01.prod",
   "mountPoint": "/search/i001",

   "script": "http://repository.prod/scripts/webapp-deploy-1.0.0.groovy",
   "initParameters": {
      "container": {
        "skeleton": "http://repository.prod/tgzs/jetty-7.2.2.v20101205.tgz",
        "config": "http://repository.prod/configs/search-container-config-2.1.0.json",
        "port": 8080,
      },
      "webapp": {
        "war": "http://repository.prod/wars/search-2.1.0.war",
        "contextPath": "/",
        "config": "http://repository.prod/configs/search-config-2.1.0.json"
      }
   }
  }
  ]
}
  • 위 예에서 어디에 해당하는것이 agent와 mountPoint 이며 
  • 어떤 스크립트를 이용해서 배포를 하겠다는 부분이 script 이며 
  • 마지막으로 무엇을 배포하겠다는 정의가 initParameters 입니다.

glu 오케스트레이션 엔진은 이 모델파일을 읽어서 다음과 같은 작업을 진행합니다.

  1. 현재 배포되어 있는 상태와 모델에 정의된 상태를 비교한다.
  2. 실행 명령을 가지고 배포 계획을 만든다.
출처: http://pongasoft.github.io/glu/docs/latest/html/index.html

저작자 표시 비영리 변경 금지

glu는 무엇인가

오픈소스 배포 모니터링 자동화 플랫폼


glu로 무엇을 할수 있는가

- 많은 노드에 애플리케이션을 배포하고 모니터링 할 수 있다.

- 배포 시간때문에 발생하는 불일치를 막아준다.

- 문제가 발생했을때 이를 재빨리 알아내서 해결할 수 있게 해준다.


어떻게 동작하는가

glu는 필요한 작업을 model에 정의해 놓으면 이를 바탕으로 동작한다. glu가 동작하는 방식을 나눠보면

- 어플리케이션을 배포/업그레이드하는 일련의 작업을 계산한다.

- 일관성을 유지하기 위해 얼마나 시간이 걸리는지 확인한다.

- 배포가 잘못되면 확인해서 알려준다.


glu 아키텍처

glu는 크게 ZooKeeper, glu 오케스트레이션 엔진, 에이전트로 구성된다. ZooKeeper는 glu 에이전트가 보내주는 정보를 받아서 애플리케이션이 배포된 서버가 살아있도록 유지해주는데 사용한다. glu 에이전트는 애플리케이션이 배포될 서버에 설치되어 실행된다. glu 엔진이 이 시스템이 중요한 부분이다.



출처: http://pongasoft.github.io/glu/docs/latest/html/index.html

저작자 표시 비영리 변경 금지



2012년 9월1일에 열렸던 Agile Korea 2012 영상을 모두 공개합니다. Agile Korea Conference에 대해 잘 모르시는 분은 컨퍼런스 사이트(http://agilekorea.org/event/2012)를 참고하세요.

  1. 애자일을 실천하는 사람들이 격는 어려움(최보나)
  2. Lean Startup in Practice(정지웅)
  3. 애자일하게 스펙 작성하기(황상철)
  4. OEC facilitation Season2(채홍미)
  5. Traditional vs Agile(경기원)
  6. 애자일을 통하여 얻은것(황순삼)
  7. 협업도구를 활용한 Agile Practice 활용사례(한문근)
  8. 개인이 조직을 바꾸는 법(김창준)
  9. 유니콘 목장(정기원)
  10. User stories workshop(박준표, 최보나)
이번에 공개된 영상들은 발표자 분들로부터 사전에 영상촬영 및 공개에 대한 허락을 받은 영상들입니다. 컨퍼런스 프로그램에 있으나 영상이 없는 발표들은 다음과 같은 사항때문에 영상 자체가 없습니다.
  • 발표자 분이 영상촬영 거부하신 경우
  • 촬영 자체를 진행하지 못한 경우
  • 촬영을 했으나 잘못되어 제대로 촬영되지 못한 경우
2012년 행사에 참석하지 못하신 분들은 본 영상을 통해서 뒤늦게나마 행사를 즐기셨으면 좋겠습니다. 그리고 2013년 8월말에 개최될 Agile Korea 2013도 많은 성원과 도움 부탁드립니다. 

ps) 애자일 코리아 페이스북 그룹(https://www.facebook.com/groups/267408126612451/)에도 많이 참여해 주세요. 참석자 수가 많은것도 행사를 진행하는데 큰 힘이 됩니다.



저작자 표시 비영리 변경 금지

GTAC 2013

Work & Study/TechTalk 2013/05/07 22:55 posted by k16wire

GTAC은 Google Test Automation Conference 입니다. 지난 4월23~24일 양일간 뉴욕에서 열렸는데요. 이 멋진 컨퍼런스의 모든 발표자료와 영상이 무료로 공개되었습니다. 

GTAC 2013 WrapUp

GTAC2013: Presentations

제목만 봐도 끌릴만한 발표들이 즐비합니다. 잘 준비해서 내년에는 직접 한번 가보고 싶네요.


저작자 표시 비영리 변경 금지

'Work & Study > TechTalk' 카테고리의 다른 글

glu 모델  (0) 2013/05/27
배포 모니터링 자동화 플랫폼 glu  (0) 2013/05/20
GTAC 2013  (0) 2013/05/07
Play2 특징을 소개하는 영상  (0) 2013/05/01
나는 프로그래머로서 어느정도 수준인가  (0) 2013/04/25
초간단 웹서버 띄우기  (0) 2013/04/18

Play2 특징을 소개하는 영상

Work & Study/TechTalk 2013/05/01 16:29 posted by k16wire

이전에 NHN에서 진행했던 테크 브리핑 영상입니다. 사내행사를 녹화한것입니다만 어차피 시간이 지나면 의미없으니 공개하려고 합니다. 40분동안 Play2 Framework의 특징에 대해 설명합니다. 

샘플을 가지고 시연하는 부분도 사이사이 들어있으니 부담없이 보세요.



저작자 표시 비영리 변경 금지

팀원분이 공유해주신 Programmer Competency Matrix를 보면서 궁금해 졌습니다. 

나는 프로그래머로서 어느정도나 되는걸까? 

많은 개발자분들이 저와 같은 고민을 하고 있지 않을까요. 아래 링크를 따라가시면 Computer Science, Software Engineering, Programming, Experience, Knowledge 영역별로 Level0 ~ Level3 까지 정의되어 있는 매트릭스를 보실수 있습니다. 


http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm


내용이 모두 마음에 드는것은 아닙니다. 특히 SE는 너무 내용이 빈약하네요. 하지만 Computer Science와  Programming은 괜찮은거 같습니다. 한번쯤 재미로라도 본인의 수준을 확인해보시죠.


저는 영역에 따라 다르기는 한데 Level2 ~ Level3를 왔다갔다 하네요.



저작자 표시 비영리 변경 금지

'Work & Study > TechTalk' 카테고리의 다른 글

GTAC 2013  (0) 2013/05/07
Play2 특징을 소개하는 영상  (0) 2013/05/01
나는 프로그래머로서 어느정도 수준인가  (0) 2013/04/25
초간단 웹서버 띄우기  (0) 2013/04/18
Play에서 사용할수 있는 모듈들  (0) 2013/04/12
좋은 API 디자인 하기  (0) 2013/04/09

2012년 애자일 현황

Work & Study/애자일 개발 2013/04/23 00:19 posted by k16wire


애자일 프로젝트 관리 도구 및 교육을 진행하는 버전원(VersionOne)에서 2012년 애자일 현황에 대한 설문조사 결과를 2013년 2월 26일 발표했습니다. 설문조사 결과 전문은 아래 URL에서 다운로드 가능합니다.

http://www.versionone.com/state-of-agile-survey-results/


애자일 강의를 준비하다보면 '트렌드'에 대한 자료가 필요한데 전 이 설문조사를 자주 애용합니다. 특히 이번에는 인포그래픽으로 만들어져서 깔끔하니 좋네요. 몇가지 흥미로운것만 추렸습니다.

  • 애자일 도입에 실패한 이유는? 적절한 사람을 찾지 못해서, 팀 문화를 정착시키지 못해서
  • 애자일 도입에 성공한 이유는? 경영진의 스폰서쉽(23%), 교육/워크샵(18%), 공통의 도구 사용(13%)
  • 어떤 애자일 방법론을 사용하는가? 스크럼(54%), 스크럼과 XP(11%), 자체(9%)
  • 사용하는 애자일 기법은? 일일스크럼(85%), 단위 테스팅(74%), CI(56%), CD(23%)
  • 애자일 도입의 걸림돌은? 조직문화에 대한 변화(52%), 변화에 대한 저항(41%)

자료를 전부 살펴보기 싫으신 분들은 설문조사를 분석한 IDG의 "애자일 개발의 발목을 잡는 것은 문화와 사람"을 읽어보세요.


저작자 표시 비영리 변경 금지

초간단 웹서버 띄우기

Work & Study/TechTalk 2013/04/18 17:58 posted by k16wire

맥에는 python이 기본으로 설치되어 있습니다. 이 python으로 초간단 웹서버를 띄우는 방법입니다. 

python -m SimpleHTTPServer 8081


저작자 표시 비영리 변경 금지

플레이 프레임워크가 뜨지 못하는 이유중 하나를 저는 서드파티 모듈이 부족해서라고 생각합니다. 

RoR, GRails, Play와 같이 빠른 개발을 지향하는 기술에서는 굉장히 중요한 부분이죠. 부족하다고 말했지만 그래도 2.0을 지원하는 모듈이 꽤 많이 개발되고 있습니다. 아래 링크에서 한번 확인해보세요. 


http://www.playframework.com/documentation/2.1.1/Modules





저작자 표시 비영리 변경 금지

좋은 API 디자인 하기

Work & Study/TechTalk 2013/04/09 17:25 posted by k16wire

KTH 개발자 블로그에 올라온 좋은 API 디자인하기, 왜 그것이 중요한가? 를 읽다가 내용이 너무 좋아서 원본 동영상을 공유합니다. API를 코드로 바꿔도 손색이 없을만큼 좋은 내용이네요.

역시 좋은 발표는 시간이 흐른다고 흐트러지는게 아니네요. 꼭 한번씩 감상해보세요. (영어자막도 있으니 잘 안들리면 키고 보셔도 좋습니다.)



저작자 표시 비영리 변경 금지

DevOps 레퍼런스

Work & Study/애자일 개발 2013/04/04 09:19 posted by k16wire

DevOps에 대한 내용이 궁금해서 좀 찾아봤습니다. 


KTH 개발자 블로그 & H3 Conference

미물님 블로그
DevOps와 NoOps에 대하여 유용한 링크가 많이 들어있습니다.

공감 세미나 2회

한빛미디어:디봅스(DevOps, 개발운영) 이란?

아름프로 블로그: Continuous Delivery vs Continuous Depoyment 

DevOpsDay 
DevOps 관련 컨퍼런스인 DevOpsDay 사이트(http://devopsdays.org/)에도 좋은자료가 많군요. 컨퍼런스 발표영상을 공개해놓은것도 있는데 전부인지는 모르겠습니다.

컨설팅
Chef에 대한 호스팅과 컨설팅을 제공하는 회사: http://www.opscode.com/

외국 사례

한동안은 DevOps 구축에 매진할거 같습니다. 재밌을거 같네요.


저작자 표시 비영리 변경 금지

SKP에 오자마자 가이드를 만드는 일을 맡아서 오랜만에 코딩 표준을 좀 찾아봤습니다. 

그런데 몇년전에 비해 하나도 변한게 없네요. 안드로이드쪽은 많이 다를거라 생각했는데 의외로 코딩에 대한 기준은 차이가 없더군요. 그러다 구글링으로 찾은 슬라이드에서 우연히 본 내용이 마음에 들어 공유합니다.

출처: http://courses.coreservlets.com/Course-Materials/pdf/android/Android-Coding-Style.pdf


코드에 달린 주석을 살펴보면 쓸데없는 주석이 많습니다. 그런 주석중 대표적인 형태가 이런겁니다.

"이 클래스는 사용자 관리를 위한 클래스 입니다." 있으나 마나한 주석이죠. 

그 보다는 어떤 동작을 하는지 설명하는 주석이 좋은데 잘 안 와닿습니다. 그럴때는 3인칭 관점에서 주석을 써보시죠. 좀 더 의미있는 주석이 나올거 같습니다.



저작자 표시 비영리 변경 금지

이런 서비스 하나 있으면 좋겠다 하는 생각은 누구나 합니다. Programmable Web에 올라오는 수많은 오픈 API들을 보면서 이런 서비스들을 잘 엮어주는 서비스 없나. 그런것 있으면 참 좋을거 같은데..하는 생각을 했습니다. 있네요. ^^;


Zapier(https://zapier.com/)는 코딩 한줄 안해도 원하는 서비스를 엮을수 있도록 해줍니다. gmail에서 메일을 받아서 evernote로 남기는 작업을 어떻게 통합하는지 한번 보시죠.



통합작업이 아무리 쉬워도 내가 원하는 서비스가 없다면 소용없죠. Zapier를 이용해 통합할수 있는 서비스에 어떤것들이 있는지는 https://zapier.com/zapbook/에서 확인 가능합니다. 제가 아는 서비스는 이미 대부분 지원하는군요. 와우!


UX도 깔끔하고 정말 맘에 드는 서비스네요.


저작자 표시 비영리 변경 금지

Yalp Framework

Work & Study/TechTalk 2013/03/12 09:15 posted by k16wire

Play 1.2.x에서 파생되어 나온 프레임워크입니다. 메일링 리스트에서 계속 논란이 있더니 결국에는 새로운 프레임워크가 등장했네요. 어떻게 발전해나갈지 궁금합니다.


https://github.com/yalpframework/yalp



저작자 표시 비영리 변경 금지

지난해 중순부터 사용해 오던 Play Framework에 대한 책을 쓰기로 마음 먹었습니다. 

출판계약은 오랫동안 번역으로 인연을 맺어온 에이콘 출판사와 했구요. 현재 어느정도 목차도 확정되어 한창 원고 작업을 진행중에 있습니다. 다음은 제가 이책을 쓰게된 기획의도 입니다.

몇년전부터 자바 웹 어플리케이션에 대한 표준 프레임워크는 스프링이 되었다.

스프링이 좋은 프레임워크이긴 하지만 꼭 스프링이 아니어도 되는 서비스를 스프링으로 개발하는것은 낭비라고 말할 수 있다. 스프링과 비교하기에는 부족해도 또 다른 강점을 가진 프레임워크로 Grails, Play를 들수 있다. 높은 개발 생산성을 위해 만들어진 이런 프레임워크가 널리 쓰이지 못하는것은 왜일까?


여러가지 이유가 있겠지만 이런 기술을 실제로 쓰고 싶을때 참고할수 있는 제대로된 참고서나 가이드라인이 없는것도 그 이유로 불수가 있다. 만약 본서가 출간된다면 Play를 이용해 빨리 원하는 서비스를 만들어 보고 싶은 사람들에게 큰 도움이 될거라 예상된다.


제가 생각하는 이 책의 독자는 다음과 같습니다.

  • 아이디어를 빨리 서비스화 하고 싶은 스타트업
  • 웹서비스를 빨리 프로토타이핑 하고 싶은 사람
  • Play를 이용해 웹 서비스를 개발하고 싶은 사람
  • 자바기반 웹 어플리케이션을 개발을 배우고 싶은 사람


책은 아마도 5월은 되어야 나올거 같습니다. 책에서 다루어졌으면 하는 내용이 있다면 댓글로 의견주세요. 좋은 의견 주신 분에게는 나중에 책으로 보답하겠습니다.


그리고 현재도 Play for Scala 책을 가지고 스터디 그룹을 운영하고 있습니다. 이미 이 스터디는 끝나가는데 관심 있는 분들이 더 생기면 2번째 스터디를 진행할 의향이 있습니다. 스터디 참석을 원하시면 아래 URL로 페북 그룹에 가입신청 하세요.


https://www.facebook.com/groups/400984499987421/


저작자 표시 비영리 변경 금지