기존 minimal mistake theme는 UI가 심플해서 직접 꾸며줘야 할 것이 많았다. 이곳저곳 둘러보다가 hydejack 테마가 괜찮아 보여서 테마를 변경해보았다. 그런데 로컬에서는 잘 작동이 되는데 저장소에 올리면 테마가 없다며 빌드가 실패하는 문제가 발생한다. 이 것 때문에 _config 파일에서 thme설정, remote theme 설정을 각각 주석 처리했다가 다시 살려놨다 바꿔보면서 삽질을 많이 했다(ex. 로컬에서 잘 작동이 되는데 저장소에 올리면 빌드 실패하는 문제를 해결했더니, 이 번엔 로컬에서 안 돌아감). 그러다 힌트를 얻은, 이 테마를 사용하면서 같은 문제를 겪은 블로그를 발견했는데 이 곳이다. 결론은 깃허브에 의해 hydejack 테마를 보안상의 이유로 거절하는 것 같다. 또한 관련 모듈의 버전도 너무 높아도, 낮아도 안 되는 것 같았다. 뭐 하나 고치니 다른 문제가 생기고 이런 식의 연속이었다.
28p - 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것의 차이: 골프 퍼팅 연습 - 공이 어디로 가는지 전혀 보지 않고 1,000개의 공을 치는 것과 같다.
55p - 꾸준한 반복으로 달인이 되려면 적어도 실력을 개선하려는 동기가 있어야 하고, 구체적인 피드백을 적절한 시기에 받아야 한다.
64p - 세계 대회 수준의 선수는 지역 대회 수준의 선수에 비해 몇 배 더 많은 트리플 악셀을 연습했습니다. 지역 대회 수준의 선수는 자신이 이미 익숙하고 자신 있는 '예술적 표현' 등의 연습에 시간을 더 썼습니다. 그러고는 트리플 악셀을 많이 연습했다고 착각했습니다. 결과적으로는 더 뛰어난 스케이터가 엉덩방아를 더 자주 찧을 수 있다는 것이죠.
72p - A 그룹은 어려운 코딩 문제를 먼저 풀게 한 다음 쉬운 문제를 풀게 했고, 반대로 B 그룹은 쉬운 문제를 먼저 풀고 어려운 문제를 풀게 했습니다. B 그룹이 A 그룹보다 절반 이하의 결함을 만들었습니다. 쉬운 작업을 먼저 할 경우 수행 시간 차이는 없으나 정확도가 높아졌습니다.
77p - 의도적 수련의 일상적 예시 - 실력 조정하기(스스로 핸디캡 만들기 ex 메모장으로 코딩하기), 난이도 조절하기.
83p - 튜토리얼을 읽다가도 이 정도면 그 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작합니다. 이런 것을 적극적 읽기라고 합니다.
91p - 실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요. 반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다.
92p - 실수 관리 문화일수록 회사의 수익성이 더 높습니다. 왜 이런 현상이 나타날까요? 이유는 간단합니다. 실수가 없으면 학습하지 못합니다.
101p - 신뢰가 깨져 있는 맞벌이 부부가 있었습니다. 하루는 남편이 일찍 퇴근을 했습니다. 싱크대에 그릇이 쌓여 있는 걸 보고는 남편은 웬일인지 설거지를 합니다. 여기까지를 몰래카메라로 촬영해서 제삼자에게 보여주면 대부분 남편이 선의의 행동을 했다고 평가를 내립니다. 반전은 부인이 집에 들어오면서부터입니다. 부인은 남편에게 화를 냅니다. "집안일을 제대로 안 한다고 항의하려는 거냐" ...(중략) 신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 것입니다.
104p - 사회적 기술을 훈련한다는 게 막막하게 느껴지기도 합니다. (중략) 간단한 방법은 주변 사람들과 매일 주고받는 마이크로 인터랙션에 신경을 쓰는 겁니다. 그걸 기록하고, 복기하고, 다르게 인터랙션한다고 하면 어떻게 했으면 좋았을까를 생각해 보는 것만으로도 훈련이 될 수 있습니다.
110p - 초기에는 대상에 대한 지식이 거의 없으니 일을 제대로 나눌 수가 없습니다. 사실 일을 가장 잘 나눌 수 있을 때는 프로젝트가 완료되는 시점입니다. 그럼에도 불구하고 이 친구들은 초기에 일을 빨리 나눠버렸던 거지요.
132p - 각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우 신뢰가 유의미하게 증가했습니다. 왜 이런 일이 생겼을까요? 하나 공유나 최고 공유의 경우 우리는 공유 자리에 기대감보다 불안감을 갖고 갈 겁니다. 나의 작품이 하나밖에 없으니 '작업물 = 나'가 되는 것이죠. 나름 방어를 해낸다 해도 자기효능감이 떨어지기 쉽습니다.
160p - 더 높은 품질을 얻기 위해서는 이 사다리(전략 - 범위 - 구조 - 뼈대 - 표면/비주얼)를 오르락내리락 반복하는 것이 필요합니다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길입니다. 특히나 문제와 해결책에 불확실성이 높은 경우.
167p - 뛰어난 팀의 특징을 찾기 위한 구글의 프로젝트(아리스토텔레스 프로젝트) 중 일부 - 1. 팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다. 2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다. 3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
176p - 속도가 빠른 팀은 심리적으로 보호가 되고 있었습니다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았습니다.
177p - 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 학습을 팀의 중대한 목표로 받아들였습니다. 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다. 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다. 학습보다는 단기 퍼포먼스를 중요시했습니다. 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했습니다.
187p - 파킨슨의 법칙 - 교수가 숙제 기한은 일주일 늘려줬을 때 학생들이 숙제를 하는 데 걸리는 시간도 일주일 늘어나는 현상
187p - 정보방열기: 물리적으로나 혹은 가상적으로 어떤 공간에 설치되어 있고 지속적으로 정보를 방사하는 것. 오늘 할 일을 벽에 포스트잇으로 붙여두고 무엇이 완료되었는지 표시하는 스크럼보드 등이 포함됩니다.
188p - 옆자리 동료가 점심시간이라 자리를 뜨면서 화면을 흘긋 보더니 "어? 버전업 작업하시네요? 고생 꽤나 하실 거에요"하면서 나가는 것이었습니다. 그분은 알고 봤더니 그 전주에 버전업 작업을 모두 마쳤습니다. 하지만 옆에 앉아서 동료를 도와줄 생각을 아예 하지를 앉았던 겁니다. 본인이 한번 해봤으면 다른 사람을 도와줄 때 시간이 절반도 안 걸릴 텐데 말이죠. 그러면 그 팀은 결과적으로 개발자 개개인이 동일한 시행착오를 겪어야 하는 팀이라는 뜻입니다.
208p - 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었습니다.
210p - 상위 5%의 탁월한 S/W 엔지니어에 대한 연구에서도 그런 사람과 그렇지 못한 사람을 구별하는 효과적인 요소는, 주어진 업무 외에도 관심을 갖는가 하는 점이었습니다. 탁월한 엔지니어들은 프로젝트 전반에 대한 큰 그림을 가지려고 하고, 경영진에게 더 적극적인 태도로 다가가고, 다른 엔지니어들을 도와줍니다.
201p - 애자일 코치 교육 과정을 10년 가까이 진행하면서 얻은 교훈: (중략) 3. 실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 등이다. 4. 애자일 성숙도가 낮은 조직일수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다. 5. 무섭고 두렵지만 중요한 일이라면 계속 미루지 말라. 6. 뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다. 7. 뛰어난 애자일 코치는 함께 자란다.
깃은 알다가도 모르겠고 또 안다고 생각했는데 잊어먹어서 헷갈리는 경우가 많다. 남에게 가르쳐줄 수 있을 정도로 확실히 안다고 자신하는 게 아닌 상태라면 애매한 부분들에 대해 틈틈이 이런저런 테스트를 직접 해보며 몸으로 기억하는 게 맞는 것 같다. 아래는 내가 확실히 알거나, 직접 테스트해서 알아낸 것들이다.
서버 부하로 인해 서버를 여러 대 구축해놓고 그 앞에 로드 밸런서를 두면 특정 사용자의 a 요청은 server1로 가고, b 요청은 server2로 갈 수 있다. 그런데 이 때 로그인을 서버 1에서 해뒀다면, b 요청이 마침 로그인한 사용자만 접근 가능한 페이지일 경우 사용자 입장에선 로그인을 했지만 로그인을 하지 못한 것으로 처리되어 페이지를 볼 수 없게 된다.
대안으로 sticky session이라 해서 한 번 서버 1에서 로그인한 사용자는 계속 서버 1에 요청하도록 할 수도 있지만, 근본적으로 서버에 부하를 주는 방식인 session을 사용하지 않는 것도 한 가지 대안이다. 그 것이 jwt다.