골드피처 (Atlassian Partner)

마이크로 서비스를 위한 기능 구현에 Clojure를 선택해야 하는 이유가 몇가지 있습니다.  코드 재사용 : 여러 팀은 이미 구축한 코들 이용할 수 있습니다. 예를들면: 검색, 파일 저장소 혹은 pub/sub 애플리케이션의 기능을 독립적으로 확대축소 할 수 이쓴ㄴ 기능. 기술 선태에서의 자유로움 이 글은 세번째 관점에 대해 이야기 합니다. 기술선택의 자유로움 마이크서비스 기반 구조의 중요한 특징입니다. 마이크로 서비스는 작아야 합니다. 얼마나 작아야 하는지는 회사나 팀의 문화에 따라 달라지지만, 마이크로서비스는 100줄의 코드보다 커서는 안된다고 들었습니다. (만약 자바였다면, 여전히 작다고 할 것입니다) 마이크로서비스는 작아야 하기 때문에, 개발자는 가장 좋은 개발기술이 무엇이든 이용하는데 주저하지 않습니다. 그것이 잘못된 선택이었더라도 상관없습니다. - 선택을 통해 배우고 그것을 새로운 미래 프로젝트에서 고려하는 지식으로 활용합니다. 어떤 경우는 몇백줄의 코드만으로 가능하기 때문에 더 잘 어울리는 언어로 마이크로서비스를 다시 작성할것을 결심할 수도 있습니다. 모두 멋지고 좋은 일입니다. 그렇지만 만약 기술의 선택에서 자유롭다면 현재 당신이 사용하는 언어대신 클로져(Clojure)를 선택해 보는 것은 어떨런지요. 현대의 Lisp "Lisp 는 비밀을 가진 외계이 기술로 만들어졌습니다." —  lisperati.com Clojure 는 자바 가상 머신에 동작하는 현대의 리스프(Lisp) 입니다. JVM을 타겟(기반)으로 하는 것은 많은 이점을 가집니다: JVM 은 인간이 역량으로 수십년간 더욱 빨라져 왔습니다.  문제 도메인의 확장된 범위에서 훌륭한 라이브러리가 있습니다. 새로운 바퀴를 개발하는 것보다 문제 자체에 집중할 수 있습니다. JVM은 작거나 큰 업무영역 모두에서 폭넓게 사용됩니다. JVM이 더욱 적용가능한 범위를 넓히고 있습니다. 그래서,

Runkeeper 팀은 Runkeeper 앱을 통해 매일같이 운동하는 전 세계의 3,000만 사용자의 요구 사항에 빠르게 대응해야 합니다. Olympian 같은 성능을 제공하고 모든 휴대용 OS에서 최적의 수준을 유지하기 위해, Runkeeper는  Confluence , JIRA 및 HipChat을 사용합니다. 이러한 솔루션을 통해 애자일한 팀을 유지해 뒤쳐지는 팀원이 없습니다. 회사가 엄청난 속도로 성장했기 때문에 해결해야 할 과제도 많이 생겨났습니다. 가장 큰 과제 중 하나는 이런 급격한 성장에 상관없이 팀원에게 정보를 똑같이 제공하는 것이었습니다. 처음에는 Google Docs를 사용하여 요구 사항 및 프로젝트 업무를 협업했지만 확장성이 없었습니다. 팀원들은 효과적인 솔루션, 즉 확장성이 있고 신속하게 움직일 수 있으면서 전체 회사 차원에서 업무를 공유하고 찾는 데 필요한 구심점을 제공할 수 있는 무언가가 필요했습니다. "전체 회사 차원에서 Google Docs를 검색하고 공유하는 것은 힘든 일이었습니다. 우리는 협업을 위해 사용할 수 있는 지식 기반으로 활용할 수 있으며, JIRA와 연동되는 무언가를 원했습니다." 도전은 성공했습니다! Confluence가 이런 요구사항을 충족시켰습니다. Confluence는 전체 회사 시스템에서 지식 기반으로 활용할 수 있으며, 아주 간편하게 JIRA와 연동되는 툴입니다. 기사 전문을 읽어 보면,  Runkeeper가 어떻게 Confluence, JIRA 및 HipChat을 조합하여 애자일 개발을 확장하고, 팀 간 협업을 통해 회사 전체의 생산성을 증대시켰는지 확인할 수 있습니다.  기사 전문 RunKeeper에 대해 따로 소개할 필요는 없다. 스마트폰을 가지고 있는가? 운동하려고 생각해본 적이 있는가? 그렇다면, 전 세계 3,000만 명이 사용 중인 Runkeeper를 사용해 보기 바란다. 메사추세츠 주 보

거의 모든 조직에서 팀원들은 협업을 통해 업무를 완료합니다. 소프트웨어 팀에서는 일반적으로 코드 개발,  코드 검토 , 테스트 같이 업무가 서로 다른 직원 간에 작업(문제)을 이전합니다 (모두 같은 팀 소속이어도 마찬가지). 팀원 간 문제를 이전할 때는 이전받는 사람이 문제에 대해 완벽히 이해하는 데 필요한  램프업(ramp-up) 양을 최소화 하는 것이 중요합니다. 작업(문제) 이전은 팀원 한 명이 아닌 두 명의 시간이 필요하므로  많은 비용이 들 수 있습니다 . 하지만 코드 검토는 소프트웨어 팀 사이에서 모범 사례에 해당합니다.   코드 검토는 코드베이스의 정보를 배포하여 팀이 더욱 유연해지고, 기민해지며, 결함 포용력이 강화되는 데 도움이 됩니다. 코드베이스 지식이 팀 전체에 배포되기 때문에 팀이 코드베이스 전반에 걸처 진전을 이루는 데 팀원 중 누구도 장애물이 되지 않습니다. 코드   검토는   개별   지식을   보다   강력한   배포된   지식으로   바꿉니다 . 그렇다면 어떻게 하면 팀원들이 다른 팀원에게 새로운 문제에 대해 효율적으로 쉽게 소개할 수 있을까요? 해결책은 적절한 문제 추적 관행입니다.  잘 알려진 문제는 모든 이력을 한 곳에 보관하여 모든 팀원들이 문제를 그 작업 항목에 대한 대시보드로 볼 수 있습니다. 이 대시보드를 만들고 팀원 간 이전 시간을 최소화하는 다섯 가지 핵심 관행을 살펴보겠습니다. 1. 완료에 대한 명확한 정의를 내려야 함 완료에 대해 일관성 있는 정의를 내리면 코드 작성자와 코드 검토자 사이에 명확한 경계가 생깁니다. 개발자들은 개발을 진행하며 보통 서로 협업합니다. 이는 좋은 일이며 팀이 문제를 해결하도록 권장되어야 합니다. 코드 완료의 의미에 관한 명확한 측정 기준이 있으면 검토자가 검토할 때 일관성 있는 기준과 품질 잣대를 갖게 됩니다. 결과적으로 JIRA로부터 검토를 요청하는 알림을 받는 사람은 해당 코드가 이

잘 구성된 커맨드라인 인터페이스를 구성하는 것은 매우 어렵습니다. --help 입력없이 사용자가 도움말을 잘 얻고 관련 문서도 확인하도록 하는 것은 쉽지 않은 일입니다. 아마도 명령어가 기억나지 않아 --help 를 입력한 경험이 많을 것입니다. Atlassian에서는 CLI 툴을 이용하여 내부 서비스를 이용하는데 사용합니다. 이것은 Go 로 제작되었으며 CLI 라이브러리인  Kingpin  에서 제공하는 모든 기능을 이용합니다. 이 글에서는 Shell completion 힌트를 제공하는 CLI를 어떻게 제작하는지 기술할 것입니다. 툴에 대한 Bash 자동완성은 툴의 사용을 더욱 빠르게 도와줍니다. 하지만, Kingpin은 shell 자동완성을 지원하지는 않습니다. 그렇지만 여기 기능을 구현하였고 Kingpin 에 해당 기능을   pull request  를 통해 기여하였습니다. 이 글에서는 어떻게 CLI 가 Shell 자동완성 힌트를 제공하게 만드는지 설명합니다. Go 프로젝트 생성에 익숙하다고 가정하겠습니다. 이제 Go를 시작하셨다면,  Golang Getting Started  문서를 확인하십시요. 시작하기 CLI를 위한 새로운 go 패키지를 생성합니다.  package main import (      "os"      "gopkg.in/alecthomas/kingpin.v2" ) func main() {      app := kingpin.New( "my-app" ,  "My Example CLI Application With Bash Completion" )      kingpin.MustParse(app.Parse(os.Args[1:])) } 이것은 런타임시에 전달되는 명령행을 파싱하는 kingpin CLI 앱을 구성합니다. 아래와 같이 실행합니다. $>