git .gitignore 를 적용시키기

.gitignore를 수정했는데, 이게 적용되는 시점 이전에 파일을 add했거나 했을때!

$ git rm -r --cached .
$ git add .
$ git commit -m ".gitignore is now working"

Bubble-sort with Hungarian ("Csángó") folk dance

nginx가 허용하는 파일 사이즈는 1메가

디폴트가 1메가 입니다 여러분!!!이메가 아님.

그래서 어떻게 고치냐...

client_max_body_size 100m;

이걸로 고쳐집니다..100메가로....

당신의 조직에서 당장 시작해야할 단 한가지의 조직개편

스크럼에는 여러가지 아이디어들이 있는데, 그중에서 가장 효과적인 한가지를 꼽으라 한다면 주저 없이 나는 이것이라 말하겠다.

Feature Team

 대충 설명하자면 이거다. 이게 일반 적인 팀의 구성이다.
편하지 않은가? 마음이 정화되는 것 같고 막.. 정리되어 있다는 느낌도 들고..
우리가 당연하다고 생각하는 조직 구성인데, 이 조직 구성에는 몇가지 치명적 문제가 있다.

1. 커뮤니케이션 로스(loss)
   대장은 개발보스와 개발 보스는 쫄짜들 개개인과 태스크(task)를 주고 받는다. 내가 쫄짜1인데, 로그인 화면을 만들라는 오더가 내려왔다고 치자. 나는 일단 디자인 팀에서 누가 로그인 화면을 만드는지 파악해야하고, 그외 팀중에 DB팀에 가서 누가 데이터 모델을 만드는지 알아야 한다. 자신들의 팀이 괜찮은 팀이라고 착각하는 팀들은 이 "다른팀의 누가"를 중간 보스들이 파악하고 있어서 바로바로 대답해 주는 경우가 많다. 어쨌든 나는 건너건너 누군가와 일을 해 나가야 한다. 자리도 멀리 떨어져 있어서 잡담도 못한다.
2. 개개인은 조직의 일보다, 자신의 일에 집중함
   내 일만 하면 된다. 옆에 쫄짜2가 어떤 일을 하는지 알 필요도 없으며 알아도 내가 해줄 것도 없다. 그저 위에 보스가 최대한 옆에 있는 놈이랑 나랑 비슷한 태스크를 주길 바랄 뿐이다. 당연히 프로젝트가 어떻게 되는지 나는 잘 알지 못한다.
3. 슈퍼맨 리더를 찾을 필요가 있음
   슈퍼맨 리더의 능력이 그 팀의 능력을 좌우한다. 그런 사람을 찾는 것이야 말로 프로젝트를 성공시키는 첩경이다. 찾는거도 일이다. 아니, 너무 힘든 일이다
4. 리더는 결국...
   이 상태에서 리더는 결국 "하얗게 불태웠어.."라고 읖조리며 조직을 나간다. 내 할 일도 많아 죽겠는데 밑에 애들 관리도 해야지 위에 보고도 해야지, 가장 Hot한 영역이기 때문이다.
5. 결국 팀의 시너지 효과는 기대하기 힘들다.

그럼에도 대부분 이런 구성으로 조직을 이끌어 나가는 건, 장점이 있기 때문이다. 그건 바로,

파악하기 쉽다. 그리고 해라고 하는 것만 하면 된다.

이걸로 연결된다. 내가 대장이면, 밑에서 중간 보스들이 들려주는 얘기만 들으면 대충 다 파악된거 같은 기분이 든다. 그리고 더 큰 장점이 있는데, 밑에 사람입장에서는 위에서 해라고 하는 것만 하면 된다는 거다. 인간이 살아가는데 가장 편한 방법이다. 위에서 해라고 하는거 그대로 하고 주는 돈 그대로 받고.. 그 돈 받아서 남들이 하는거 하면서 사는거..

자, 당신이 만약에 경영자라면 여기서 어? 라고 생각해야 한다. 뭐냐고? 아니 당신이 월급을 주는 아랫것들이 편하게 일하고 돈받아 간다는거다. 안그러냐? 더 쥐어짜야지. 어떻게 쥐어 짜냐고? 대부분 이 부분에서 특별한 고민없이 아랫것들을 쥐어짜기 위해 하는 짓이 집에 안보내기인데. 그런 짓을 했다가는 짜봤자 아무것도 안나올거기 때문에 당신(경영자)도 해피할 수 없고, 짜지는 쫄짜들도 어차피 하는 것 똑같은데 집에만 못가기 때문에 불만만 쌓인다. 그럼 어떻게 하느냐.

 

프로덕트 오너와 스크럼 마스트는 무시하고 아래의 팀 구성만 보자. 팀 하나가 하나의 기능을 온전히 만들 수 있는 단위로 되어 있다. 그냥 섞어 놓은 것 아니냐고? 맞다 섞어 놓은 것. 이 구성에서의 장점은

1. 자연스럽게 다른 종류의 팀원들과 대화를 할 수 있다.
   개발자와 개발자는 그냥 놔둬도 둘이서 잘논다. 디자이너와 디자이너도 그냥 놔두면 둘이서 짝짜꿍한다. 그럼에도 그들을 붙여놓음으로 인해 조직은 벽이 생긴다. 일부러 섞음으로 구성원들이 커뮤니케이션을 좀더 다양한 방법으로 할 수 있게 된다.
2. 팀 하나가 하나의 기능을 온전히 구현할 수 있다.
   이제 로그인 화면을 만드는데 쫄짜1이 여기 저기 돌아다닐 필요가 없다. 팀 하나가 하나의 기능을 완전히 구현할 수 있는 구성이 되어 있다.
3. 팀들간, 같은 종류의 구성원들이 문제를 해결해 나간다.
   팀1과 팀2,3에 속해있는 디자이너 들은 정기적인 미팅을 통해 자신들의 팀에서 일어난 일들을 공유하고, 자신들만의 해결책을 생각한다. 그리고 자신들의 팀으로 돌아가 그걸 실행한다.

물론, 이런 팀을 구성하고 운영해 나가는 건 힘들다. 그런데 자신들의 조직이 좀 더 빠르고, 효율적으로 움직이길 원한다면 그만한 노력은 해야 한다. 

(쓰다가 막판에 오니 해야할일이 생각나서..급하게 접습니다...기회되면 또 편집하겠습니다. )

git 에서 리모트 리포지토리를 로컬로 덮어쓰기

실서버 소스를 약간 수정한 뒤 git pull을 했더니, conflict가 일어나서 패닉상태가 되었을때.. 이 두 커멘트면 해결이 가능하다.

$ git fetch origin
$ git reset --hard origin/master

참고로 인터넷상에, git pull 커멘드를 이용해 강제로 pull을 받는 방법이 소개되어 있는데, pull은 git fetch와 git merge origin/master를 동시에 해주는 커멘드로써, 로컬에서 소스와 merge할 일이 없으면 되도록이면 쓰지 않는게 좋다.

git 에서 특정 파일을 되돌리기

특정파일을 되돌리고 싶을때 쓰는 커멘드

$ git log filepath
commit 1234512345
Author: ********
Date:   Mon Mar 21 22:24:08 2016 +0900

$ git checkout 1234512345 filepath

더 이상 설명은 필요 없겠죠??

한글url이 브라우저에 따라서 엑세스가 안될때..

지금 개발하고 있는 사이트에서, 한글파일명의 파일을 AWS s3를 통해 서비스한다.

그런데 크롬으로 접속을 하면 다운로드가 되는데 사파리에서는 안되는 현상이 발생..

원인은, 크롬에서는 알아서 조합형으로 인코딩해주는데 반해서, 사파리에서는 완성형으로 인코딩하는데서 오는 '것 같다'..

암튼 주소를

window.encodeURI(input)

해주는것으로 해결.