분류 전체보기
객체지향 도메인 모델 설계와 멘탈 모델의 연관성
객체지향 도메인 모델 설계와 멘탈 모델의 연관성
2020.12.12최근에 객체지향의 사실과 오해(조영호) 이라는 책을 읽던 중 도메인 모델 설계을 멘탈 모델(심성모형)을 통해 설명하는 부분에서 충격을 받았다. 어떻게 이 두 개념의 연관을 이렇게 지을 수 있었을까? 멘탈 모델(심성모형) 나는 인간중심디자인(Human Centered Design)이라는 수업에서 멘탈모델에 대해 배웠었고, DB 모델링이나 프로그래밍을 통해 설계도 조금은 익숙한데 이 두 개념을 전혀 연관을 짓지 못했다. 멘탈모델에 대해 다시 알아보고 싶어서 구글링을 하던 중 귀여운 사례로 멘탈 모델에 대해 설명하는 글을 발견했다. 아래 글을 요약하자면 멘탈 모델이란 어떤 사물이 어떻게 동작할 것이라는 믿는 사고 방식이고, 개개인마다 동일한 사물에 대해서도 멘탈 모델이 다르기 때문에 발생한 귀여운 해프닝에 대..
Git 브랜치명과 폴더명이 중복되었을 경우
Git 브랜치명과 폴더명이 중복되었을 경우
2020.12.04후... git checkout 를 했더니 수 많은 파일이 overwrriten 되었다. 내 몇 안되는 지식으로는 checkout했을 때 왜 이런 현상이 발생하는 지 애하가 가지 않았다. 커밋이 되지 않은 파일은 체크아웃 된 브랜치로 딸려오고, 커밋된 경우에는 스무스하게 스위칭되야한다고 생각했다. 내가 이해했던 현상과 진짜 원인을 알아보자. 내가 이해했던 현상 로컬 브랜치에 아래 파일들 작업 후 commit - add => new_file.java - delete => deleted_file.java - modify => modified_file.java IDEA를 통해 리모트에 있는 브랜치로 checkout했다가 다시 기존에 작업중이던 브랜치로 checkout 시 에러 발생 git checkout 다른..
Jira와 GitHub 연동
Jira와 GitHub 연동
2020.11.30Jira에 GitHub을 연동하면 Jira 이슈로 인해 어떤 커밋들이 발생했는 지 확인할 수 있다. 이를 통해 개발자는 이 커밋들이 왜 발생했는 지에 대한 비즈니스 히스토리를 알 수 있게 되고, 비슷한 비즈니스 요구사항이 생겼을 때 예전 담당자가 어떻게 작업했는 지 영향도 파악 및 참고 시에도 유용하다. 아래 순서로 포스팅 내용을 진행하겠다. Jira - Github Enterprise 연동 (jira와 github Admin 권한 필요) 참고 문서 : https://support.atlassian.com/jira-cloud-administration/docs/integrate-with-github/ Jira에서 development 사용방법 참고 문서 : Reference issues in your d..
스타트업 채용 공고에 속지 말자
스타트업 채용 공고에 속지 말자
2020.11.28좋은 스타트업은 없다. 나와 맞는 회사, 나와 맞지 않는 회사, 그리고 나쁜 회사만 있을 뿐이다. 채용 공고를 보고 솔깃하기 전에 스타트업에 대한 환상을 깨고 있는 그대로 바라보자. 스타트업도 회사다 유니콘처럼 스타트업에 대한 실체없는 전설은 가득하다. 스타트업은 자유롭고, 직원 복지가 좋고, 능력이 뛰어난 자를 우대하고, 직원의 성과를 보상해주고, 수평적인 문화고, 직원들의 역량 향상을 지원하고, 새로운 기술에 항상 도전적이고, 효율적으로 조직을 운영할 거야! 스타트업이라는 단어 대신 회사를 넣어서 잘 생각해보자. 스타트업과 회사는 같은 조직체를 지칭하는 데, 스타트업에 대해서는 긍정적인 일반화가 가득하고, 회사에 대해서는 부정적인(사실적인) 일반화가 가득하다. 아래는 내가 했던 경험과 약간의 상상력을..
Hibernate에서 제공되지 않는 DB 종속 함수 사용(mysql group_concat)
Hibernate에서 제공되지 않는 DB 종속 함수 사용(mysql group_concat)
2020.11.19Hibernate는 특정 데이터베이스에 종속되지 않고 객체지향스럽게 사용할 수 있도록 추상화해준다. 때문에 특정 DB에 종속된 함수(예를 들면 mysql의 group_concat)는 제공하지 않는다. 되도록 DB 확장성을 위해 특정 DB에 종속된 기능 사용은 고려해볼 필요가 있지만, 그 기능이 비즈니스 요구사항을 풀기에 적절하고 필요하다고 판단된다면 확장성에 너무 얽매일 필요는 없다고 생각한다. 물론 DB를 변경할 예정이라면 어차피 바꿔야 하니 사용하지 말자. 어쨌든 특정 데이터베이스에서만 제공하는 함수, 여기에서는 mysql group_concat을 사용하기 위해 Dialect를 확장하여 커스텀 SQL 함수를 등록해보자. CustomMysqlDialect 클래스 생성 import org.hibernat..
팀문화를 위한 작은 발버둥
팀문화를 위한 작은 발버둥
2020.11.14목마른 자가 우물을 판다. 회사의 대부분이 TF팀 형태로 그때 그때 프로젝트 구성원이 매핑된다(?). 서로 공유하는 업무 체계가 없는 상태에서 다양한 사람들과 일을 하다 보니 자연스럽게(?) 팀문화랄게 딱히 없고, 좋은 노하우와 경험이 전파되지 못하는 상황인 것 같다. 드디어 바쁘게 돌아가던 프로젝트에서 숨구멍이 트였고, 같은 업무를 하는 동료들끼리 힘을 모아 여러 시도를 시작했다. 데일리 스탠드업 미팅 아이스 브레이킹 용이기도 하고, 별다른 커뮤니케이션 비용을 들이지 않고 근황이나 업무 현황을 캐치하기 좋다. 삭막한 TF팀에서 한줄기의 빛 . 매일 5분~10분 정도로 진행하기로 했다. 주간 회고 회고를 통해 자체적인 피드백 시스템을 적용했다. (+속풀이) 현 회사에서 구성하는 묘한 TF팀은 각 팀원이 ..
협업을 위한 작은 발버둥
협업을 위한 작은 발버둥
2020.11.11협업 방식의 중요성을 깨달았다 우리 회사의 독특한 조직문화 입사 6 개월 차, 이 회사는 굉장히 독특한 조직 문화가 있다. 그것은 바로 아무런 문화가 없어 보인다는 점이다. 흔히들 체계가 없다고 말하는데, 우리 회사는 disorder나 mess의 의미가 아니라 그냥 없다. undefined에요. 초반에는 어떤 체계를 만들어가던지 회사 차원에서 시도라도 했으면 좋겠다.라고 생각했었는데, 지금은 오히려 깨끗한 상태라서 팀원 레벨에서 이러한 시도를 할 수 있으니 다행이라고 생각한다. 그리고 이번 TF팀의 동료 개발자분들도 적극적으로 참여해주었다 :) 불편했던 협업 과정, 특히 파편화된 커뮤니케이션 채널 우리 회사는 구두, 구글 행아웃(업무용 메신저), 각종 문서를 통해 협업한다. 모든 회사가 이 정도 채널들을..
IntelliJ 로그파일 확인 (GUI로 요청한 git command 이력보기)
IntelliJ 로그파일 확인 (GUI로 요청한 git command 이력보기)
2020.11.06intelliJ에서 제공하는 GUI를 통해 git 작업을 했는데, 소스가 꼬여서 원인을 찾기 위해 명령어 이력 확인이 필요해졌다. 터미널을 통해 git command를 날리면 터미널 자체적으로 명령어 이력을 지니고 있지만, GUI를 통해 작업했기 때문에 intelliJ 터미널에서 history명령어를 통해 bash 명령어를 확인해도 별다른 정보가 뜨지 않는다. intelliJ라면 내가 실행요청한 Git 이력을 내부적으로 관리하지 않을까 싶어서 구글을 헤엄치다 내가 원하는 정보를 발견했다. 인텔리제이 로그파일 보기 intellij-support.jetbrains.com/hc/en-us/articles/207241085-Locating-IDE-log-files Locating IDE log files The..
Spring JSR 380 Validation 적용과 테스트 코드 작성
Spring JSR 380 Validation 적용과 테스트 코드 작성
2020.11.01유효성(Validation)을 체크하는 Java bean인 JSR 380(또는 Bean Validation 2.0)에 대해 간단히 알아보겠다. Java 8 버전 이상의 버전이 요구되며, 필요한 의존성을 추가해야한다. (의존성에 대해서는 추천자료를 참고하길 바람) Java 8 버전 이상의 버전이 요구되며, Spring boot 2.3 이후부터는 validation 의존성을 추가해야한다. org.springframework.boot spring-boot-starter-validation or implementation 'org.springframework.boot:spring-boot-starter-validation' 유효성 체크 정의 유효성 체크를 하고 싶은 DTO에 검증 어노테이션와 관련 메시지를 정의..
리눅스 메모리 용량 확인과 로그파일 관리
리눅스 메모리 용량 확인과 로그파일 관리
2020.10.28보통 서버가 죽는 이유는 메모리 문제일 가능성이 높다. 프로세스별로 점유하고 있는 메모리가 무척 높거나, 혹은 서버 용량이 거의 다 찼을 때 비정상적으로 종료된다.서버 상태를 확인할 수 있는 간단 명령어df -h : 디스크 사용량ps -ef --sort -rss : 메모리 사용량순 프로세스 조회대체로 로그 파일이 너무 많이 쌓여서 서버가 죽을 때가 많은데, 주기적으로 들어가서 삭제하는 것 보다는 정책을 세워 관리하는 것이 좋다. 예를 들어 개발기 같은 경우 일주일이 지나면 로그파일 압축, 한 달이 지나면 압축된 로그파일 삭제 와 같은 정책이 있다면 이를 자동으로 수행하는 shell 파일을 만들어 주기적으로 수행되도록 배치 등록을 하면 된다. (운영기의 로그는 S3나 별도의 스토리지 서버에 저장해두고 몇 ..
개발자를 존중하는 회사 (feat. 역할별 책임)
개발자를 존중하는 회사 (feat. 역할별 책임)
2020.10.16흔히들 말한다. "우리는 개발자를 존중합니다. (그러니 오세요.)" 나는 개발자를 존중하는 회사에서 일하고 싶다. 사실 기획자든, PM이든, 디자이너든지 본인의 역할과 그에 따른 책임이 존중되는 회사에서 일하고 싶은 것은 당연하다. 서비스는 다양한 역할의 사람들이 협력을 하며 만들어지는 것이다. 서비스를 만들어가는 과정에서 각 역할은 모든 과정에 참여한다. 단지 각 역할의 책임이 다르기 때문에 서비스를 만들어가는 단계에 따라 역할별 중요성이 크고 작다는 차이가 있을 뿐이다. 각 역할을 존중한다는 것은 각자의 책임을 수행하기 위해 주도적으로 의견을 냈을 때, 그것을 긍정적으로 검토하되 그에 대한 사이드 이팩트, 혹은 추가로 고려해야 할 사항에 대해 논의하는 것이라고 생각한다. 즉, 모두 본인의 책임과 다른..
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
2020.10.14특정 기능에 대해 기획자와 PM의 의견이 달라요 최근에 있었던 일을 통해 조직 내에서 특정 책임(기획, PM, 개발)을 수행하는 역할의 구분이 모호할 때, 특히 요구사항 정의하는 기획자의 역할이 모호할 때 생기는 일을 말해보겠다. 일단 각 회사마다 직함이 같더라도 수행하는 업무가 다를 수 있으니, 현 직장에서 내가 바라본 역할과 책임에 대해 정의해보겠다. (현 프로젝트에서는 기획자와 PM을 수행하는 사람이 나누어져 있다.) 기획자 : 사용자의 니즈(건강 관리)를 충족하기 위해 필요한 기능(로그인, 출석체크, 퀴즈 등)을 정의하고, 사용성을 높이기 위해 기능 제공 방식을 요구사항으로서 정의 PM : 프로젝트의 일정과 인력 배분, 구현해야하는 기능의 우선 순위 등 프로젝트 전반을 관리 기획자가 요구사항을 정..