Try & Error

Last Christmas I bought my wife and myself a Synology NAS to store our pictures on. Given that I’d spent a lot of time over the last few years working on Git LFS, I always thought it would be pretty cool if you could use the NAS as an LFS server.

Like everything else these days, the thing can run apps. I looked around for what it would take to make an app for it and what I found seemed to be mostly a bunch of flaming hoops to jump through. I’m pretty lazy, so I dropped it.

The other day I was checking out Home Assistant and noticed it could be installed on the Synology via Docker. Wait … what? You can run Docker on it‽ Far out! It is Linux, so I guess that makes sense. Now it should be easy to set up an LFS server on it. We have a reference server that’ll do just fine for this.

To get running, first install the Docker app from Package Center. Start the app and head to the Registrytab. It’s hooked up to DockerHub by default. The search seems to love returning results for things you didn’t ask for, so it’s best to just search for rubyist. Searching for rubyist/git-lfs-server is far too specific, I guess, but that’s what you’re looking for. Click Download for download.

Once it’s downloaded, it’ll appear in the Image tab. Click Launch to launch.

This brings up the Docker app’s container wizard. It’s actually quite nice. Click the Advanced Settingsbutton. Set the following options in their respective tabs:

• Advanced Settings: Enable auto-restart
• Volume: Add a folder on the drive at a Mount Path of /var/git-lfs
• Network: Select “Use the same network as Docker Host”
• Environment: Configure any environment vars for the server

The full set of supported environment variables can be found in the lfs-test-server README, here are the ones you’ll need to set:

• LFS_HOST: The host name of your NAS
• LFS_ADMINUSER: The username of the admin user
• LFS_ADMINPASS: The admin password

When setting LFS_HOST you’ll need to include the port that the LFS server is running on, which will be ":8080". For example, "foobar.localdomain:8080".

Once you’re done there, close the advanced settings and click the Next button. You’ll see a summary of the config. Click Apply.

Your LFS server is now running! Configure LFS by adding the following to the .lfsconfig file in the root of your repo:

[lfs]
	url="http://foobar.localdomain:8080/rubyist/myrepo"

If you have questions, tweet at @rubyist, I might answer.

[출처] https://killring.io/post/synology-for-lfs/

어느날 소스트리를 켰는데 실행이 안되는 것이었다.

그래서 아래와 같이 해보았다.

1. 프로그램 추가제거에서 삭제 후 재설치

2. 관리자 권한으로 실행

3. CMD창에서도 실행

4. 폴더삭제 ( C:\Program Files (x86)\Atlassian )

그래도 결론은 실행이 안된다!

그래서 결론은

혹시나 하는 마음에 아래의 경로를 삭제해보니 이후로는 실행이 된다.

C:\Users\name\AppData\Local\Atlassian\SourceTree.exe_Url_xx..xx

다만 단점이라면 소스트리의 초기 설정값들과 Local 저장소데이터가 다 날아간다는점이 있을 수 있겠다.

출처: http://soulduse.tistory.com/37 [프로그래밍좀비]

[출처] 게임코디 Rh님

[Link] https://www.gitkraken.com/

[링크] https://trello.com/b/UTc6X4FS/-

개발 흐름

이 프로세스 문서의 현행화는 Github에서 진행되니 추후에는 Github을 방문해 주시면 고맙겠습니다.

개발 프로세스(Trello, Github, Slack)

1. Trello Card 만들기
1.1 기본적인 Trello 흐름

• 먼저 Trello에서 개발해야 할 기능을 [To Do(Story)]라는 이름의 리스트에 카드로 만들고,
• 해당 스토리(카드)를 개발자가 구현에 들어가면 [Doing(WIP)] 리스트에 카드를 옮기고,
• 리뷰에 들어가면 [Review(Sprint1)] 리스트로 옯기고,
• 개발 브랜치가 병합하여 테스트를 완료하면 [Done(Sprint1)] 리스트에 카드를 옮기고 해당 기능을 클로즈한다.

1.2 Trello카드 내용은 Description란에는 이슈 링크를 걸어주거나 wiki 링크를 걸어줘, 해당 스토리의 정보를 알 수 있도록 해준다. 그리고 Spec을 참조하여 Checklist를 추가해 완료조건을 기술해 개발해가면서 하나씩 처리해 나간다.


1.3 카드 처리 및 이동시 Slack Alert를 줘 실시간으로 처리가 가능하도록 설정한다.


2. Branch 만들고 Pull Request, Merge 하기
2.1 소스 리모트와 동기화

> git checkout master && git pull origin master && git fetch -p origin

2.2 브랜치명을 만들고 브랜치로 이동.

> git checkout -b dev_standard

2.3 작업 후 커밋.

> git commit -a -m "[VOY-201] README git 사용법 추가"
# 커밋 작성은 issue ID를 넣고 내용은 구체적으로 제시한다.

2.4 작업을 완료 후 master branch로 변경하여 remote에 새로운 변경 사항을 master에 반영

> git checkout master
> git pull origin master && git fetch -p origin

2.5 변경사항이 있다면 dev_standard branch에서 rebase를 수행

> git checkout dev_standard
> git rebase master

- rebase 중 충돌이 발생하면 아래 수행하고 아니면 넘어감.

> git add .
> git rebase --continue

2.6 Pull Request 요청하기 전에 Trello 카드도 [Review] 리스트로 옮기고 Checklist 하나를 더 만들어서 Review 내용(리뷰 담당자 포함)을 기술하면 Trello 알림을 통해 담당자가 리뷰어임을 알게 된다. 아니면 Trello 카드를 만들때 Review Checklist를 미리 만들어서 리뷰 대상자를 등록한다.
 

2.7 Pull Request 요청

> git push origin dev_standard

- push 후 Github의 repository로 이동해서 Compare & pull request 버튼 클릭하고 코멘트[To close VOY-201(jira issue 번호), 혹은 github issue 사용하면 #1234로] 남기고 Create pull request 버튼 클릭한다. 


- 이때 Pull Request 정보가 Slack을 통해 담당자에게 보내지게 되고 리뷰를 수행한다. 


- 리뷰 수행 후 수정사항이 있으면 수정 후 Pull Request를 다시 보내고, 수정 사항이 없으면 Github에서 Merge pull request를 클릭하고 Confirm merge 버튼을 클릭해서 merge를 완료한다. 

- Github에서 merge가 완료되면, Delete branch 버튼을 클릭하거나 아래 로컬에서 커맨드로 원격 브랜치를 삭제한다.(선택사항)

> git push origin :dev_standard

2.8 Review 후 수정사항이 있는 경우 수정한 다음 2.7을 재 수행한다.

2.9 로컬 master 동기화 

> git checkout master && git pull origin master && git fetch -p origin

- 로컬 브랜치 삭제(선택사항)

> git branch -d dev_standard

3. 배포하기
- 테스트 코드를 돌리고, jenkins나 자체 배포 도구를 활용하여 운영 서버에 소스를 배포한다.

4. 배포후 확인
- 기능 테스트를 눈으로 확인하면서 화면의 깨짐, 데이터의 정확성, 브라우저 호환성 등을 점검한다.
- Selenium 도구를 통해 브라우저단에서 테스트를 할 수 있는데, 이 Selenium이 구동한 브라우저의 결과 화면을 아이컨텍해서 봄으로써 어느 정도 테스트 자동화를 할 수 있다.

5. Trello 카드 Done 리스트로 이동
- 배포후 확인에서 이상이 없다면 Trello의 카드를 [Done(Sprint1 - 날짜기간)] 리스트에 이동시키고, 이슈를 close한다.

[출처] http://www.mimul.com/pebble/default/2015/06/08/1433751662702.html

[링크] http://ljs93kr.tistory.com/44

[링크] http://ljs93kr.tistory.com/43

안녕하세요. 오늘도 신선한 '기업 커뮤니케이션' 관련 소식을 전해드리러 온 정은킴입니다 :D

여러분들은 업무를 볼 때 팀원들과 의견을 나누고, 파일을 공유하기 위해 어떤 '메신저' 를 사용하시

나요? 이번 주, 혹은 다음 주에 해야 할 업무와 계획 등을 효과적으로 관리해주는 'To do list' 로는 

어떤 것을 사용하고 계신가요? 우리는 이렇게 우리의 업무를 보다 빠르게, 성공적으로 마치기 위해

다양한 '비즈니스 커뮤니케이션 툴'을 사용하고 있습니다.

'비즈니스 커뮤니케이션 툴' 시장은 최근 몇 년 사이 비약적으로 성장해 좀 더 특별한 강점을 내세운 다양한 도구들이 출시되고 있습니다. 특히 업무를 볼 때, 내가 '해야 할 일'을 효과적으로 관리해주는 GTD(Getting Things Done) 기반의 '할 일' 관리 툴은 요즘 같이 각자의 업무가 많아지고, 복잡한 

업무 상황 속에서 모든 직장인들에게 꼭 필요한 툴이라고 볼 수 있습니다. 이미 해외 시장을 비롯, 

국내에서도 다양한 '업무 관리 툴'들이 등장하고 있는데, 그래서 저는 오늘부터 매주 화요일마다 

'비즈니스 커뮤니케이션 툴'에 대해 하나씩 살펴보는 특집 기사를 포스팅 하려고 합니다. 

지난 8월, 사진 공유 사이트로 유명한 '플리커(flikr)'의 공동 창업자인 스튜어트 버터필드가 업무용 

커뮤니케이션 툴인 '슬랙(slack)'을 공개했습니다. 슬랙은 '느슨한, 늘어진'이라는 의미로, 과중한 

업무를 한 시라도 빨리 처리하려는 현대인들에게 슬랙을 사용함으로써 '느슨한' 여유를 가질 수 있게

하자는 뜻을 내포하고 있습니다. 사용자들은 웹을 포함해 모바일에서도 슬랙을 사용할 수 있는데, 웹에서든, 모바일에서든, 동일한 환경으로 쉽게 슬랙을 사용할 수 있어 언제, 어디서든 사용자의 업무 

반경을 넓혀줍니다. 그럼 이제, 슬랙만이 가지고 있는 색깔을 확인해볼까요?

《 '느슨한' 여유를 가지다 》

[Good Point] 저는 이번에 슬랙을 체험하면서 슬랙이 가지고 있는 많은 기능들 중, 특히 자주 사용

했던 두 가지 기능이 있습니다. 그 첫 번째 기능은 바로 '파일 전송' 기능입니다. 슬랙은 웹에서든 

모바일에서든 자유롭게 대화를 나눌 수 있는 메신저 기반의 '비즈니스 커뮤니케이션 툴'인데요, 이

성격에 맞춘 슬랙의 파일 전송 기능은 사용자들이 쉽고 빠르게 다양한 업무용 파일을 공유할 수 

있게 해줍니다. 웹에서 슬랙을 실행했을 때, 웹 브라우저 창의 왼쪽 영역에서는 팀원들과 대화를 

나누는 동시에, 오른쪽 영역에서는 내가 보냈거나, 찾고자 하는 파일을 바로 찾을 수 있습니다. 

또한, 파일의 제목과 확장자명 등으로도 쉽게 파일 검색이 가능하고, 이미지나 PDF 등이 파일 속성 별로도 내가 찾고자 하는 파일을 바로 찾을 수 있습니다. 아이디어 회의 같은 간단한 회의를 슬랙에서 진행했을 때, 팀원들과 대화를 나누며 다양한 이미지나 업무와 관련된 기사를 공유할 수 있어 편리합니다. 슬랙의 '파일 전송' 기능은 모바일에서도 동일한 구성으로 이용할 수 있어서 사용자들이 

웹과 모바일 등의 디바이스에 상관 없이 쉽게 사용하기 좋습니다. 내가 찾고자 하는 파일의 속성과 제목 등을 검색할 수 있는 세부 검색 아이콘도 상단바에 달려 있어 사용자들의 눈에 익숙합니다.

슬랙은 '비즈니스 커뮤니케이션 툴'답게 업무의 흔적을 남길 수 있는 기능이 존재합니다. 제가 두 번째로 많이 사용했던 '별표 대화(Starred Items)' 기능인데요, 상대방의 아이디 옆에 있는 별 모양

을 누르면, 해당 대화가 별표 처리되어 웹 브라우저의 오른쪽 영역에서 별표 친 대화만 골라서 볼 수 있습니다. 다른 팀과의 협조가 필요한 업무를 진행하거나, 상사의 중요 공지 사항을 한 데 묶어서 볼 수 있어서 편리합니다. 이 기능은 내가 어떤 대화창에서 업무와 관련해 어떻게 말했는지 확인할 수 있기 때문에 향후 업무 상 커뮤니케이션에 문제가 생겨 '나'와 상대방이 어떻게 대화를 나누고, 어떤 방식으로 업무를 처리하기로 했는지 확인할 수 있습니다. 이는 곧 서로간의 업무 기록이 되어 보다 책임감있게 업무를 처리할 수 있는 작은 도움이 되기도 합니다. 

[Bad Point] 슬랙은 '웹 메신저'의 성격을 띄는 업무 관리 도구인만큼, 왠만한 기능 사용에 있어서 

모든 사용자가 동일하게 쓸 수 있습니다. 하지만, 대화방 생성을 아무나 할 수 있고, 각 대화방의 

주제를 설정하는 것도 권한에 상관 없이 바꿀 수 있는 점은 보안에 민감한 회사들이 사용하기에 적당

한 것 같지 않습니다. 또, 대화방 및 파일함 내에 너무 많은 아이콘과 텍스트(첨부 파일 설명 문구, 

댓글 문구)들이 있어 화면이 정돈되어있지 않다는 느낌이 드는 것도 슬랙이 가진 단점이라고 할 수 있겠습니다.

《 '친절함'을 입히다 》

[Good Point] 슬랙은 타 업무 관리 도구와는 다르게, 세세한 기능에도 신경을 많이 써 사용자들이 

최대한 많은 기능들을 많이 써볼 수 있도록 했습니다. 그래서 사용자들이 많이 클릭하는 메뉴 세 개의 하위 메뉴에 'Help&Feedback'이라는 도움말 기능을 넣어 사용자들이 느낀 불편함을 곧바로 찾을 수 있도록 배려했습니다.

사실 슬랙과 비슷한 업무 관리 도구들을 보면, 도움말 기능이 환경설정 메뉴에만 있거나 그 제품의 

해당 홈페이지로 이동해야 도움말을 볼 수 있는데, 슬랙은 세 곳에 있는 주 메뉴에 도움말 기능을 

동일하게 둠으로써 어떤 기능을 사용하더라도 사용자가 도움말을 접할 수 있는 빠른 환경을 제공합니다.

여러분, 여러분들께서는 현재 사용하고 있는 웹메신저를 처음 사용했을 때를 기억하시나요? 상대방과 대화를 나누려면 어떤 아이콘을 눌러야 하고, 어떤 버튼을 눌러야 파일이 전송되는지 조금은 헤매셨을 것입니다. 하지만, 슬랙에서는 사용자가 처음 슬랙을 실행했을 때부터 헤매지 않게 도와주는 '친절한' 기능이 있습니다. 이 기능은 슬랙의 주요 메뉴 세 곳(대화방 개설, 사용자 정보, 대화 전송)에서 '살아 움직이는' 버튼으로 사용자들의 시선을 끕니다. '살아 움직이는' 동그라미 모양의 이

버튼은 사용자가 해당 메뉴를 누를 때까지 계속 움직입니다. 사용자들은 무심코 이 버튼을 눌렀다가

해당 메뉴를 어떻게 사용해야 하는지 학습하게 되는데, 해당 메뉴를 설명해주는 도움말을 읽고 난 후

'Done(마침)'이라는 버튼을 클릭하지 않으면 계속 움직이는 버튼이 사용자의 주의를 끕니다.

이 버튼은 사용자들에게 슬랙의 다양한 메뉴를 어떻게 사용하는지 익혀두고, 이를 업무 관리에 곧바로 도입할 수 있도록 했습니다.

슬랙은 웹메신저를 기반으로 하는 '업무 관리 도구'로서 특별한 기능이 하나 있습니다. 그것은 바로 '대화 내용 수정' 기능입니다. 이 기능에서는 상대방과 대화를 나눈 후, 내가 했던 대화 내용을 수정할 수 있는데, 타 웹메신저에서는 찾아볼 수 없는 특이한 기능입니다. 저는 처음에 이 기능을 써보 

고 의문이 들었습니다. 왜냐하면, 나중에 내 마음대로 대화 내용을 수정할 수 있기 때문입니다.  

사용자들은 수정하고 싶은 자신의 대화의 '설정' 아이콘을 누른 뒤, 'edit' 메뉴로 들어가 곧바로 

해당 대화 내용을 수정할 수 있습니다. 이렇게 대화 내용 수정이 끝나면 해당 대화 옆에 'edited'라는 문구가 뜨면서 언제 대화 내용을 수정했는지 날짜와 시간까지 구체적으로 확인할 수 있습니다. 

제가 슬랙에서 발견한 또 다른 '친절함'은 사용자의 프로필을 설정해주는 '슬랙봇'에서 찾을 수 있었습니다. 슬랙봇은 사용자의 대화자 리스트 내, 첫 번째로 위치하고 있는데 처음 슬랙을 쓰는 사용자 

들과 1:1로 대화를 하는 형식으로 사용자의 프로필을 설정할 수 있도록 도와줍니다. 이름을 비롯, 부서명, 프로필 사진 등을 슬랙봇과 대화하면서 입력할 수 있어 재미있게 프로필 설정을 할 수 있습니다. 웹 브라우저의 오른쪽 영역에서도 친절한 슬랙봇을 만날 수 있습니다.

[Bad Point] 제가 이번에 슬랙을 체험하면서 가장 아쉬웠던 점은 한국어 지원이 안 된다는 것이었습니다. 사용자 이름 및 닉네임, 대화방 이름까지 영어로만 설정이 가능해 조금 불편합니다. 물론 우리나라에 정식 출시되거나, 한국어 버전이 나온다는 말은 없지만, 우리나라의 '업무 관리 툴' 시장도 

더욱 넓어지고 있는 만큼 더 많은 사람들이 슬랙을 많이 사용해봄으로써 우리나라의 색깔에 맞는 

'업무 관리 툴'이 출시되었으면 좋겠습니다.

또 다른 슬랙의 단점으로는 IE(Internet Explorer)에서는 슬랙을 사용할 수 없다는 것입니다. 이 점은

슬랙이 가진 최대의 단점이라고 볼 수 있는데, 특히 우리나라에서는 IE를 기본 웹브라우저를 설정해

인터넷을 사용하는 사람들이 77%에 달하기때문입니다. (자료 출처: StatCounter, 10월 기준)  

IE에서 슬랙을 실행해서 메시지를 입력하고, 엔터를 누르는 순간 연결이 되지 않았다는 메시지가 

뜹니다. 사용자는 분명히 슬랙에 로그인되어있는데도, 슬랙은 오프라인 상태로 인식합니다. 크롬

이나 파이어폭스 등의 다른 웹브라우저들을 사용하지 않는 사람들에게는 큰 불편함을 초래할 것 같네요.

여러분, 슬랙을 자신의 회사에 도입한 고객들은 3일 만에 이메일 수신량이 75%나 감소했다는 놀라운 결과를 얻었다고 합니다. 그만큼 시간이 오래 걸리고 불필요한 이메일 업무를 깔끔하게 정리해

준 '착한' 도구가 되었다는 뜻이겠죠? 과연 슬랙은 점점 더 치열해지고 있는 '비즈니스 커뮤니케이션 툴' 시장에서 선두 자리를 차지할 수 있을까요? 마냥 '착한' 도구로만 있기에는 '비즈니스 커뮤니케이션 툴' 시장은 너무 냉정합니다.

[출처] http://blog.mailplug.com/391