매일 꾸준히, 더 깊이

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. Web 어플리테이션을 만들 때, 유저의 권한에 따라 액세스 할 수 있는 페이지나 페이지 안에서 표시되는 항목을 제한하고 싶은 경우가 있다. 예를 들면, 관리자만 접근할 수 있는 페이지의 생성이나 일반 회원과 프리미엄 회원의 화면에 표시되는 항목 차이등 말이다. 이러한 액세스 제어를 Django에서 만든 Web 어플리케이션에서 구현하기 위해서는 기본적으로 제공되는 "인증 기능"을 사용하면 간단하게 가능하다. 이번 포스트에서는 Django의 인증 기능을 쓴, 유저별 액세스 제한을 구현하는 방법에 대해 알아보도록 하겠다. 참고로 Django의 인증기능에 대해서는 Django 공식 페..

※ 일본의 포스트를 번역한 글 입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. Django 튜토리얼에는 함수 베이스 뷰로 작성되어 있지만 실제로 사용하는 것은 클래스 베이스 뷰인 경우가 대부분이다. 이 포스트에서는 이 두 가지에 대해 간단히 알아보고 왜 클래스 베이스 뷰가 주로 사용되는지에 대해 설명하도록 하겠다. 클래스 베이스 뷰와 함수 베이스 뷰 클래스 베이스 뷰는 말 그대로 view.py에 Class로 처리를 기재하는 것을 의미하며, 함수 베이스 뷰는 함수는 처리를 함수로 기재하는 것을 뜻한다. 클래스 베이스 뷰는 Django에 이미 정의되어 있는 django.generic.view에서 View 클래스를 상속받거나 믹스인하여 작성하는 것이 특징이다. View..

※일본의 한 블로그 글을 번역한 포스트입니다. 의역 및 직역, 오역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. Django에서는 표준 User 모델이 정의되어 있다. 그러나 대부분은 만드는 Web 어플리케이션에 맞게 User 모델을 커스터마이즈할 필요가 있다. User 모델을 커스터마이즈하는 방법은 몇 가지 있으나 여기서는 가장 자유도가 높은 AbstractBaseUser을 상속받는 방법에 대해서 구체적으로 설명하도록 하겠다. 주의점 : 커스텀 User 모델을 이용할 경우 Django의 프로젝트 생성 후 바로 설정할 필요가 있다. 이미 migrate한 후에 User을 변경하려고하는 것은 매우 어렵다. 표준(디폴트) User모델 앞서 말했듯 Django에서는 기본적으로 User 모델이 존재..

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 직역, 의역이 있을 수 있으며, 틀린 내용은 지적해주시면 감사하겠습니다. 이 포스트는 프로그래머가 영어 명명법으로 고민할 때 지침서가 되어 줄 명영을 플로우 차트 형식으로 해설하기 위해 작성됐다. 다만, Vue.js 의 프로젝트에서 윤용되는 룰을 기반으로 작성했으므로 본인의 개발 환경 룰에 맞게 변경하길 바란다. 결론 플로우 차트를 모두 표시하자면 다음과 같다. (A) 형용사 + 명사 boolean이 아닌 값을 대입할 경우 거의 이 룰을 따른다. // 예 // 형용사 + 명사 specialCategory // 특별한 카테고리 // 형용사는 동사의 수동형(~ed)혹은 ing형이어도 OK importedPlayerNames // 임포트된 여러명의 플레..

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 밒 직역, 의역이 있일 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. Django 개발에 대해서 알아보던중, Django로 개발할 때 의식하면 좋은 최적의 구성이 있다는 사실을 알게 됐다. 이번 포스팅에서는 이와 관련된 얘기를 하고자 한다. 목차는 다음과 같다. 설정 파일을 config등 알기 쉬운 명칭으로 한다. static 디렉토리를 생성한다. 시크릿 변수나 환경 의존 변수는 .env 파일에 쓴다. 단계별로 설정 파일을 전환할 수 있도록 한다. 어플리케이션 마다 urls.py를 배치한다. 베이스 템플릿을 사용한다. 이 목차를 모두 거치면 다음과 같이 디렉토리 구성이 변경된다(첫 번째가 변경'전', 두 번째가 변경'후'이다). 참고로 프로젝트명..

※ 일본의 한 블로그 글을 번역할 글입니다. 오역 및 직역, 의역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. 시작하기에 앞서 RDBMS의 데이터 베이스 설계(논리)의 작성법에 대해서 설계할 때에, 이러한 부분을 생각하면서 하면 좋을 것 같은 부분에 대해 설명하고자 한다. 그러나 DB 설계에서는 "이것이 정답"이라는 것은 별로 없으며, 요건의 필요조건을 만족하는 DB설계가 정답이라고 할 수 있다. 그렇다고 해도, 고려하는 것이 좋은 부분과 주의점 등이 있으므로 무엇 부터 시작하면 좋을지 고민하고 있는 사람에 참고가 되길 바란다. DB 설계에 있어서의 포인트 DB 설계할 때에 중요하다고 생각되는 포인트는 다음과 같다. 요건/사양을 이해하고 있는가? (요건을 만족하는 테이블/칼럼이 준비되어 있..

※ 일본의 한 블로그 글을 번역한 것입니다. 오역 및 직역, 의역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다. README이란? README이란 리포지토리를 방문한 사람에게 "이 프로젝트는 무엇인지"를 알기 쉽게 전달하기 위하 설명서와 같은 것이다. 읽는 입장에서는 갑자기 소스 코드를 보는 것은 괴로우므로 먼저 README를 읽어 개요를 파악하는 것이 중요하다. 즉, 사람의 첫 인상이 중요하다면 GitHub 리포지토리의 README가 중요하다. 처음 리포지토리를 방문한 사람이 흥미를 가질지 아닐지 자신의 프로젝트를 써줄지 아닐지 는 README에 걸려있다고 해도 과언이 아니라는 것이다. 그렇다면 어떤 README가 사람을 끄는 멋진 REAME이란 무엇일까? 멋진 README란? 어떻게 써야..

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있일 수 있으며 틀린 내용은 지적 부탁드립니다. DB의 실행 $ psql -d 데이터베이스명; postgres를 먼저 실행한다. $ psql -d postgres; 만약 비밀번호에서 에러가 발생한 경우 아래의 커맨드와 같이 관리자를 지정하여 패스워드 postgres를 입력하자. $ psql -d postgres -U postgres DB의 생성과 삭제 DB의 생성 기본 구문이다. # CREATE DATABASE 데이터베이스명; 예를 들면 kenko이라는 이름의 DB를 작성한다면 다음과 같다. # CREATE DATABASE kenko; 참고로 이 커맨드로 DB의 목록을 확인할 수 있다. # \l List of databases Nam..

※ 이 포스트는 일본의 한 블로그 글을 번역한 것입니다. 의역 및 오역, 직역이 있을 수 있으며 틀린 내용있으면 지적해주시면 감사하겠습니다. 이 포스트는 누구라도 헤매지 않고 팀 개발에 참가할 수 있도록 팀 개발의 흐름을 매뉴얼로 만들기 위해 작성했다. 복잡한 사용법은 전혀 없다. 개발의 흐름 Github에서 관리하는 리포지토리에서는 아래의 흐름으로 코드를 갱신한다. 먼저 master 브랜치에서 시작하기 로컬 리포지토리에 master 브랜치를 넣기 리모트 리포지토리에 master 브랜치의 갱신이 있는지 확인하기 feature 브랜치로 개발하기 feature 브랜치로 변경하기 개발하기 변경점을 로컬 리포지토리에 commit하기 리뷰 리모트 리포지토리에 push하기 Pull Request 보내기 PR으로 리..

※ 일본의 한 블로그 글을 번역한 포스팅입니다. 오역 및 직역, 의역이 있을 수 있으며 틀린 내용은 지적 부탁드립니다. Figma 서비스에는 편리한 퀵 액션과 단축키가 존재한다. 그리고 퀵 앤션을 열면, 검색으로 메뉴를 찾거나 "Shortcut"라고 검색해서 단축키 리스트에 액세스해서 단축키를 확인하는 것이 가능하다. 이 포스트에서는 "커맨드를 기억하자"보다는 "이런 커맨드가 있구나" 와 "이렇게 사용하면 편리하구나"라고 생각할 수 있는 내용을 설명할 생각이다. 퀵 액션 표시하기 Command + / 'XX는 어떻게 하더라?'라고 생각이 들면 일단 커맨드 파레트를 열어 검색하면 대부분 나온다. 최근에 사용한 메뉴나 플러그인도 리스트에 뜨기 때문에 편리하다. 편리한 잔기술 종류 단축키 확인 Control ..