본문 바로가기
반응형

분류 전체보기714

함께 자라기 개요 워낙 유명한 김창준 님이 쓰시기도 하셨고, 협업에 관심이 많았던 찰나에 회사에서 구매하여 읽게 되었습니다. 책이 그렇게 두껍지 않고 어려운 내용들이 있던 것은 아니라 읽는데 부담은 없었습니다. 사례 중심의 이야기가 많기도 하지만 여러 조사를 통해 근거를 가지고 설명해주는 부분들이 인상 깊었습니다. 최근에 학습 방법과 교육, 협업에 관심이 많았는데 이미 알고있던 부분도 있었지만 새롭게 알게되고 적용해보면 좋겠다고 생각한 부분들이 있었습니다. 가령 전문가에게는 방법을 묻기보다 실제로 과제나 사례를 제시하며 옆에서 어떻게 생각하는지, 해결하는지, 접근하는지 전 과정을 관찰하는 것이 훨씬 도움이 됩니다. 또한 팀이 서로 투명한 공유와 신뢰가 쌓여 있을 때, 환경 변화에 대처하기 쉬우며 같은 작업을 하더라도.. 2022. 9. 9.
커밋 메세지 본문은 "어떻게"보다 "무엇을", "왜"에 맞춰 작성하기 커밋 메세지 작성의 중요성 개발자의 개발 능력 못지 않게, 협업 능력이 중요하다는 것은 이제 모든 개발자들이 공감하는 부분 일 것입니다. 좋은 협력이란 핵심을 딱딱 짚는 좋은 커뮤니케이션 능력과 부드럽고 협조적인 대화스킬도 있겠지만, 커밋 메세지 작성의 견고함도 포함된다고 생각합니다. 코드로 승부하는 IT 세계에서, 다른 동료들과 협업할 때 나의 작업물의 의도를 커밋메세지로 잘 드러내는 것 만큼, 다른 동료들의 업무 향상성을 높이는 길이 없습니다. 좋은 커밋 메세지를 작성하기 위한 여러가지 가이드라인이 있습니다. 대표적으로 Chris Beams의 How to Write a Git Commit Message 글에서 7가지를 소개하고 있는데, 그 중에 커밋 메세지의 본문은 어떻게보다 무엇을, 왜에 맞춰 작성.. 2022. 9. 8.
TIL_2022.09.07 1. Facts(사실, 객관) - 견적서 개선 - gitFlow vs Github Flow 차이 개념 2. Feelings(느낌, 주관) 현업이 수정해달라고 요청한 내용들을 수정했습니다. 사실 대면 미팅이 좋습니다. 같은 시간이라도 좀 더 많은 내용을 정확하고 확실하게 전달 할 수 있습니다. 그럼에도 온라인으로 소통을 열심히 해서 잘 취합된 내용으로 개선을 했습니다. 항상 개발은 끝나면 추가 요구사항이나 개선사항이 있습니다. 이에 대해 유연하게 생각하려고 노력합니다, 3. Findings (배운 점) - git flow와 달리 github flow는 main, feature 브랜치 2개로 운영한다 - 세상에 모든 기술들은 다 trade-off가 있다. 4. Action (구체적 계획) - github f.. 2022. 9. 8.
GitHub Flow vs Git Flow 개요 평소에는 Git Flow만 알고 있었는데, 강의를 통해 GitHub Flow도 있다는 사실을 알았습니다. 따라서 Git Flow와 GitHub Flow를 비교해보고자 합니다. 각 팀의 상황에 따라서 적절한 전략을 선택하는 데 도움이 될 것입니다. Git-Flow feature, develop, release, hotfix, master 5가지의 브랜치 전략을 가지고 있습니다. 기능을 개발하기 위해서 feature 브랜치를 만들고, 브랜치를 이동할 때 check out 명령어를 사용하면 됩니다. feature 브랜치는 개발을 동시가 아닌 별도로 진행하여 충돌을 막습니다. 기능 개발이 모두 끝나면, develop 브랜치에 머지합니다. develop 브랜치는 마치 master 브랜치와 비슷합니다. 왜냐하.. 2022. 9. 7.
TIL_2022.09.06 1. Facts(사실, 객관) - 피해보상 화면 테스트 및 개선 - A/S화면 테스트 및 개선 - 견적서 테스트 및 개선 - Github의 기능들 알아보기 2. Feelings(느낌, 주관) 테스트를 일괄적으로 실시하고 개선건을 취합했습니다. 주어진 기능을 만들고 끝이 아니라, 어떻게하면 사용자가 좀 더 편하고 알차게 이용할 수 있을지를 고민하는 시간이 됐습니다. 현업에서 추가요청을 할 때, 구현방식을 잘 아는 것이 아니므로 가끔은 불가능한 기능 개발건들을 요청합니다. 그럴 때, 최대한 만족스러운 기능이 될 수 있도록 적절히 타협하는 방법도 배우고 있습니다. 현업이 한번만 보이면 그 날은 더이상 기능을 안보고 싶다고 하는데 이것은 하루동안 그만 보기 기능이었고, 가끔 사진을 한번에 여러장을 띄워달라고 이.. 2022. 9. 6.
TIL_2022.09.05 1. Facts(사실, 객관) - API 호출시, TLS 적용하기 - 피해보상 화면 테스트 및 개선 2. Feelings(느낌, 주관) Teams API를 연동할 때, HTTPS 통신을 하다보니, 일반적인 통신 시도 시, 계속 handshake가 실패했다는 내용이 나왔습니다. 그래서 검색을 한 결과, TLS 인증이 있어야 한다는 것을 알게 되었고, jdk 1.7버전에서 TLS 인증을 추가했습니다. 3. Findings (배운 점) - TLS/SSL 차이점 공부 4. Action (구체적 계획) 나의 하루 [출근시간 + 업무시작 전까지] JdbcTemplate 사용 예시 데이터베이스에서 테스트환경 만들기 [오전 업무시간] 피해보상 업무 테스트 (조회 조건 수정, 리스트에 수정자 추가) Teams 알람 예시.. 2022. 9. 5.
대칭키 vs 비대칭키 암호화는 허용되지 않는 접근이나 조회로부터 정보를 보호 할 책임이 있습니다. 암호화는 인증된 사용자만 복호화가 가능한 방식으로 데이터를 암호화합니다. 어떠한 노출과 공격에도 써드 파티의 접근을 허용해서는 안됩니다. 일반적으로 암호화 과정은 일반 텍스트를 암호화된 텍스트로 바꾸는 과정입니다. 알고리즘을 이용해서 특별한 키를 사용합니다. 우리가 암호문을 가지고 있어도 알고리즘과 키가 없다면 우리 또한 데이터를 읽을 수 없습니다. 대칭 암호화 대칭 암호화는 정보를 암호화하고 복호화하기위해 하나의 키를 사용하는 알고리즘입니다. 다른 말로, 전송자는 데이터를 암호화하기 위해 비밀키를 사용합니다. 그리고나서, 수신자는 데이터를 복호화하고 읽기 위해서 같은 키를 사용합니다. 그래서, 키는 데이터를 복호화하기 위해 관.. 2022. 9. 5.
TLS/SSL HTTP와 HTTPS 사람들은 인터넷에서 웹사이트 데이터를 전송하기 위해 HTTP를 사용합니다. HTTP는 데이터를 명시적인 텍스트 형식으로 전송합니다. 단, 이 명시적인 텍스트 형식의 전송은 인터넷에서 민감한 개인정보, 카드번호, 비밀번호 등을 보내지 않는 경우를 말합니다. 만약에 데이터가 송신자에 의해서 암호화되지 않는다면, 해커는 중간에 민감정보를 탈취합니다. HTTPS는 HTTP의 보안 문제를 해결하기 위해 등장했습니다. HTTPS에서 클라이언트와 서버 사이에 데이터를 암호화할 수 있습니다. 그러므로, 해커는 데이터를 가로채도 암호화된 데이터만 볼 수 있습니다. 기본의 메세지를 보려고 하더라도, 해커는 복호화 키가 필요합니다. 요즘에는, 웹사이트가 민감정보를 보내지 않더라도 보안을 위해서 HTTP.. 2022. 9. 5.
할 일이 아닌 한 일을 기록하라 말만 번지르르 "당신이 할 거라고 말하는 일 말고 당신이 하는 일이 당신이다" - 카를 융- 이번에 책을 읽으면서, 저자의 글도 너무 인상 깊었지만, 사실 조그맣게 주석으로 나온 카를 융의 위 문장이 가장 기억에 남습니다. 우리는 항상 계획을 그럴듯하게 세웁니다. 마치 다음처럼 말이죠 하지만, 계획은 정말 계획일 뿐 실전은 다릅니다. 누구나 그럴듯한 계획은 정말 잘 세웁니다. 저는 가끔 하루종일 놀고나서 죄책감에(?) 다음날 2일치 분량의 공부 계획을 열심히 짜곤 했습니다. 물론 결과는 실패입니다. 맨날 아침형 인간으로 살고 새벽시간을 활용하겠다고 다짐한들, 그렇게 실천하지 못하면 못한 겁니다. 어렸을 때는 참 이 핑계, 저 핑계 많이 만들려고 했습니다. 소위 요즘말로 세상이 나를 억까한다고 말이죠. 그.. 2022. 9. 5.
반응형

티스토리툴바