초보몽키의 개발공부로그

170717-0723_TIL

17 Jul 2017 | TIL 학습과정

7월 23일 (일)

  • 알고리즘 문제를 풀었다.
  • 그림으로 개념을 이해하는 알고리즘 해시테이블 부분을 읽었다. 역시나 쉽게 잘 설명되어 있었다. 나 같은 초보자가 읽기에 적합한 책인 것 같다.
  • 블로그에 정리해둔 컴퓨터공학 강의 노트를 다시 읽었다. 읽을 때마다 매번 새롭다…(어려워..!)

7월 22일 (토)

  • 그림으로 개념을 이해하는 알고리즘 퀵정렬 부분을 읽었다. 재귀에 대해서 쉽게 잘 설명되어 있어서 도움이 많이 되었다. 특히 퀵정렬 구현 코드가 지금까지 봤던 코드 중에 가장 짧고 간단해서 마음에 들었다.

  • 생활코딩 자료구조 배열과 리스트 수업을 들었다. 어쩌다보니 정기적으로 반복해서 듣고 있는데 어쩜 이렇게 매번 새로운지.. 그리고 항상 초보자에게 맞춘 적절한 비유와 설명에 감탄을 하게된다.

  • 오랜만에 메모리공간에 대한 강의 노트를 다시 읽어보았다. 파이썬의 private heap 영역 사용에 대한 자료를 찾다보니, C언어는 malloc 함수를 사용해서 필요에 따라 heap 영역에 메모리를 동적으로 할당할 수 있다는 글을 읽었다(우와..) C언어는 Data, Heap, Stack 영역을 모두 사용할 수 있으니 C 언어를 사용하려면 메모리에 대한 이해가 당연히 필요할 수 밖에 없겠다는 생각이 들었다. 반대로 메모리에 대해서 잘 이해하고 싶으면 C언어를 공부하는 것도 좋은 동기부여가 될 수 있겠다. (하지만 현실은..)

    참고 : Heap은 Stack과 함게 프로세스의 대표적인 메모리 처리 공간, 혹은 기법중 하나인데, 예를 들어, 일반적인 로컬 변수는 Stack에, malloc과 같은 동적 할당 메모리는 Heap에서 주로 사용되기도 합니다. 즉, 처음부터 그 크기가 결정되어 계획하에 잡히는 메모리는 주로 Stack이고, 그 크기가 결정되지 않아 계속 커지거나, 변동하거나, 매우 큰 경우에는 동적 할당 메모리, 즉, Heap을 사용하게 됩니다. (출처)

  • 처음 ArrayList, LinkedList를 접했을 때가 생각났다. 파이썬에 List가 있는데 왜 저런 자료구조를 배워야 할까? Array랑 List가 뭐가 다른 걸까? Javascript에서 Array라고 부르는걸 파이썬에서 List라고 부르는 거 아닌가? 당시에 나는 Python과 Javascript만 접해보았기에 ArrayList, LinkedList의 개념과 필요성이 잘 와닿지 않았다. 사실 지금도 상황은 비슷하지만.. 그래도 최근 Java 문법을 공부하면서 조금은 그 필요성에 대해서 공감할 수 있었다.

    Java의 Array를 사용해보니 처음 선언할 때에 크기를 지정해야 하고, 자유롭게 요소를 추가하고 삭제하는 것이 불가능했다. 그래서 collection framework에서 제공하는 ArrayList, LinkedList를 가져다가 사용해야만 했다.(불편해..!) Java 사용자가 느끼는 자료구조에 대한 필요성은 Python 사용자보다 크지 않을까? 선택지가 많은 만큼 각각의 특성을 잘 이해해야만 제대로 활용할 수 있겠다.

    이고잉님의 강의 중에 무언가를 배울 때는 그것이 없을 때 얼마나 불편할 것인지를 생각해 보는 것이 학습의 동력이 될 수 있다 라는 이야기가 있었다. Python에서는 당연하게 가능한 것들이 다른 언어에서는 가능하지 않은 것을 보면서 이 말에 더 공감을 하게 된다. 나중에 여유가 되면 Python 이외의 언어를 배우면서 불편함을 직접 느껴보는 것도 좋겠다. (결론은 파이썬 만세..!)

7월 21일 (금)

  • 알고리즘 문제를 풀었다.
  • 쉘스크립트 자료를 읽었다. (Bash Shell Script) 예전에 pyenv를 처음 설치 했을때 $ echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.zshrc 같은 명령을 정체도 모르고 입력했었는데 이게 쉘스크립트 중의 하나였구나.
  • 자료가 좀 어려워서 찾아보니 생활코딩 리눅스 카테고리에 쉘 스크립트 소개 강의가 있었다.
    • 쉘스크립트란?
    • 어떤 일을 하고자 사용하는 명령이 여러개일때, 순차적으로 실행되는 명령의 순서(script)를 어딘가에 적어놓고 재사용 할 수 있다면 편리하다.
    • 이처럼 쉘에서 실행되는 명령들을 하나의 파일에 적어두고, 해당 명령의 집합을 한번에 실행하는 방법이 쉘 스크립트이다.
  • 처음 만들어본 쉘 스크립트
    • bak 이라는 폴더가 있는지 확인하고 없으면 폴더를 만든다.
    • log 라는 suffix 를 가진 파일들을 bak 이라는 폴더에 복사한다.
    • chmod +x 파일명 명령을 통해 실행권한 추가
#!/bin/bash
if ! [ -d bak ]; then
        mkdir bak
fi
cp *.log bak

7월 20일 (목)

  • 오늘은 알고리즘 문제 하나를 갖고서 오전 내내 고민을 하면서 보냈다. 재귀는 여전히 나에게 미지의 영역이고, 어떻게든 꾸역꾸역 풀어 냈지만 여전히 풀이가 마음에 들지는 않는다. 평소에 꾸준히 공부 좀 할걸!
  • 오랜만에 패스트캠퍼스 자료구조 수업 선생님을 만나서 치맥을 했다. 3시간 넘게 개발 이야기로 아무말 대잔치를 했는데 재미있고 신기한 경험이었다.
  • 해커톤에 함께 참여할 동생을 만나서 회의는 안하고 꿀팁만 잔뜩 얻었다.
  • Jayjin 님이 3년 전에 쓰신 지식의 곱셈 – 찌랭이, 중수, 짱이라는 글을 격하게 공감하면서 읽었다.

    같은 찌랭이를 만나든, 중수를 만나든, 짱을 만나든 모든 사람에게 배우니 찌랭이는 얼마나 행복한 단계인가.

7월 19일 (수)

  • 8퍼센트 두숟갈 스터디에 참여했다.
    • 데이터베이스 정규화를 다루었는데 아직은 막연한 개념이라 잘 이해하지는 못했다. 그래도 모델 설계를 잘 하기 위해서는 정규화가 필요하다는 것은 알았다. 최근 도서관리 사이트의 모델을 만들 때 모델 1개에 많은 정보를 담으려고 했었다. (1:ㅜㅜ1, 1:N, M:N 관계로 나누면 DB 조회시 중복 쿼리가 많이 발생했었기에..) 하지만 오늘 배운 내용을 적용하면 모델을 나눌 수 있는 여지가 많겠다는 생각을 했다.
    • 정규화 : 관계형 데이터베이스(테이블간에 관계를 맺을 수 있는 상황)에서 중복을 최소화 하기 위해서 데이터를 구조화 하는 작업 (위키, 참고글)
  • 간단한 알고리즘 문제를 풀었다.

7월 18일 (화)

  • 사내 도서관리 사이트 연습 프로젝트를 진행했다. 연습내용
    • 도서 구매신청, 도서 대여 및 반납 기능을 구현했다.
    • Fat models, thin views, stupid template 3가지를 기억하고, view 보다는 model에 로직을 구현하려고 신경쓰고 있다.
      • 대여, 반납, 연체여부를 확인 기능을 Book 모델의 인스턴스 메소드로 추가
      • 월별 도서구매 신청금액 확인 기능을 WishBook 모델의 클래스 메소드로 추가
    • 월별로 도서 구매신청 총액을 구하기 위해서 Django ORM의 aggregate를 활용하는 연습을 할 수 있었다. (엑셀만큼 쉬운) Django Annotation/Aggregation 글이 많은 도움이 되었다.
    • include를 활용해서 중복 코드를 줄일 수 있었다. include 'include/book.html' with type='wish'와 같이 전달하는 context 값에 따라서 조금씩 다르게 화면을 구성할 수 있었다.
    • 도서 대여기능을 넣다 보니까 datetime, timezone 을 활용하게 되었는데, DB에는 timezone Asia/Seoul 에 맞게 저장되지만, django shell에서 확인하면 UTC 기준으로 DateTime 필드정보를 가져오는 문제가 있었다. 아직 원인을 잘 이해하지 못했는데 내일 아래 글을 읽고 천천히 다시 살펴봐야겠다.

내일 할 일

  • UTC timezone 문제 관련 글 읽기
  • 8퍼센트 스터디 참여하기
  • 별점, 한줄평 기능 추가하기

7월 17일 (월)

  • 사내 도서관리 사이트 연습 프로젝트를 진행했다. 연습내용
    • api를 활용한 도서 검색기능, 신규도서 DB 등록기능 구현
  • User 모델 확장에 대한 Django 공식문서를 읽었다. Customizing authentication in Django 목적에 따라서 User 확장방식을 적절하게 선택할 수 있어야겠다고 생각했다.
    • Proxy Model : User 모델에 필드, 인증방식 이외의 추가 정보 (ex. ordering) 적용
    • User Profile 모델 : Default User Model 과 1:1 관계
    • AbstractBaseUser 상속 모델 : Default User Model 오버라이딩, 인증방식 변경, 필드 추가
    • AbstractUser 상속 모델 : Default User Model 오버라이딩, 필드 추가 (User Profile 모델과 목적은 유사, 모델 분리의 여부)

Related Posts