항상 충실하게

https://www.youtube.com/watch?v=eL9xupU7Bwc 

1. 시간은 기록할 것.

3. 내시간 대시보드 만들 것.

4. 안되는 진짜 이유 찾을 것.

시간관리 --> 목표 달성하려는 것.

https://youtu.be/2eSeegqvdjw

1. 목표를 가진 계획 설정

2. 사용한 시간에 등급 매기기

3. 피드백하기.

최근 딥마인드에서 알파코드를 발표하였다. 알파코드란, 알고리즘 문제를 풀어주는 ai로 알고리즘 대회에서 중간정도 속하는 수준이다. 아마 추측컨대 3년안에 알파코드는 알고리즘 문제 영역에서 만큼은 탑티어 개발자 수준으로 발전할 것이다. (알파제로가 그러했듯이) 개발자로 일을 막 시작한 사람으로서 약간은 초조하지만, 그럼에도,, 어차피 올 파도라면 서핑이라도 타야하지 않겠는가? 마인드로 책을 읽기 시작했다.

사실 책 내용이 그리 깊이가 있다거나 하지는 않았고, 인공지능 전반에 대한 설명이 되어있었다. 사실 여러가지 사례들을 읽으면서 든 생각이 홍보용이 아니라 진짜 그렇게 잘되고있을까? 이게 진짜 여기서 홍보하는대로 잘된다면 이미 세계가 다 인공지능으로 가득차있어야하지 않겠는가?

개발자로서 인공지능을 찍먹해보면서 느낀것은, 인공지능이 잘되는 분야는 굉장히 잘되지만, 아닌 분야는 아직 갈 길이 멀다는 점이다. 필자는 패션쪽 ai를 바탕으로 프로젝트를 진행해본적이 있는데 (학생 수준) 오픈소스들은 대부분 1~2년전 꺼였고, 생각보다 소개한만큼 잘 작동하지 않았다. (인공지능에서 1~2년 전꺼는 굉장히 오래된 것이다.) 이 것은 패션 쪽 데이터가 굉장히 쌓기 어렵고, 돈이 많이 드는 작업이어서 그런 것을 추측된다. 사실 생각해보면 지금 aI가 잘되고 있는 분야들은 전부 다 데이터를 얻기 쉬운 분야들이다. 바둑은 컴퓨터로 수집시에는 거의 전기값과 하드웨어 값정도만 들고, 알파스타의 경우 게임값과 전기값정도만 들고, 테슬라 자율주행데이터는 테슬라차들이 정보를 수집해주고 있다. 하지만 패션데이터는 단순히 앞면 한장이 아니라 여러각도에서, 여러 착용한 버전으로 찍어야한다는 이슈가 있다. 또한 옷의 색깔이나 재질등을 수치화하기 어려운 점도 있어서 데이터를 수집하기 용이하지 않다.

여튼 이러한 상태에서 인공지능 시대에 적응하려면 어떻게 해야할까?

인공지능이 인간보다 압도적인 효율을 발휘하는 분야는 일정한 rule을 가진 상황인데 데이터가 많은 분야이다. 하지만 뚜렷한 rule이나 목표가 설정되어있지 않다면 학습이라는 것 자체가 애매해지는 상황이 된다. 따라서 인간은 인공지능에게 지시할 수 있는 rule을 만들고 목표를 설정해주는 방향으로 적응해야할 것이다.

산업혁명이 일어나면서 인간은 자원으로 취급 되었고, 기계를 잘 다루는 사람, 분업화가 되면서 중간관리자가 중요해졌다. ai시대에서는 중간관리자까지도 ai가 대체할 수 있다. ai의 판단이 인간보다 정확할 수 있고, 기계는 ai가 훨씬 잘다루기 때문이다. 따라서 인간은 ai에게 잘 지시를 내릴 수 있는 능력, 자기만의 비즈니스를 영위하는 방식으로 적응해나가야할 것이다.

무엇을 배웠는가?

2. 새롭게 시작한 일.

저녁 공부,

일의철학 읽고 적용하기

3. 누구를 도왔는가?

희열랜드 사람.

4. 무엇을 발견했는가?

나는 먼가 조금씩 풀려나가는것을 좋아한다.

나쁜 코드란?

1. 성능이 떨어지는 코드

2. 의미가 모호한 코드

3. 중복된 코드

나쁜 코드를 쓰면 안되는 이유

1. 깨진 유리창의 법칙

2. 생산성 저하 --> 팀생산성까지, 기술부채

3. 수정하려해도 새로운 시스템도입 필요

나쁜 코드를 생산하는 이유

1. 일정 촉박해서

2. 고쳤다가 다른 곳에 영향을 미칠까봐

그렇다면 좋은 코드란?

1. 성능이 좋고

2. 의미가 면확하고

3. 중복이 없는 코드

한가지를 제대로하는 코드를 쓸것.
잘 쓴 문장처럼 읽히게 할 것.

보이스카웃룰 지키기.

스니펫: 특수한 목적을 위한 코드

디자인: 문제에 대한 해결책

스탠다드: 문제를 해결하는 대표적인 방식 포괄적임

패턴: 유효성이 검증된 효율적이고 확장 가능한 해결책

참가자: 디자인 패턴에서 사용되는 클래스

비기능적 조건: 메모리 최적화와 사용성, 성능등이 여기에 속함. 솔루션 전체에 영향을 미치는 핵심적인 요소

생성패턴

- 객체가 생성되는 방식을 중시

- 객체 생성관련 상세 로직을 숨긴다

- 코드는 생성하려는 개체형과 독립적

구조 패턴

- 클래스와 객체를 더 큰 결과물로 합칠 수 있는 구조로 설계

- 구조를 간결화하고 클래스와 객체간의 상호관계 파악

- 클래스 상속과 컴포지션을 중시

행위패턴

- 객체간의상호작용과 책임을 중시

- 객체는 상호작용하지만 느슨하게 결합돼야한다.

- 파이선 디자인 패턴 출처.

1.1 읽기 쉬운 코들르 만드는 것이 왜 중요한가?

• 코드는 한번 작성되면 여러번 읽힘.
• 나중에 읽는 사람이 훨씬 편해지고, 관리가 쉬워짐
• 이를 위해서 지켜져야하는 원칙들
  • 축약적이거나 함축적인 변수명은 피한다
  • 함수 인자의 이름들은 꼭 써준다
  • 클래스와 메서드를 문서화한다
  • 코드에 주석을 꼭 달도록 한다
  • 재사용 가능한 함수 또는 메서드 안에서 반복되는 코드들은 리팩터링을 해둔다
  • 함수와 메서드는 가능한 한 작은 크기를 유지한다. 어림잡아 스크롤 없이 읽을 수 있는 길이가 적합하다

적용해볼점:

1) 그냥 변수명 길게 쓰자.

2) 문서화 꼭 하자.

3)주석,,,?흠... 추후에 더 살펴보도록하자.

4) 리팩토링 노력해보자

1.2 pep8

flake8을 이용하도록하자.

1.3 import들

pep8에 따르면

1) 표준라이브러리

2) 연관외부 라이브러리

3) 로컬 애플리케이션 또는 라이브러리에 한정된 임포트

이 책에 따르면

1) 표준라이브러리

2)코어 장고 임포트

3)서드파티

4)프로젝트앱임포트

1.4 명시적 성격의 상대 임포트 사용하기 (explicit relative import)

• 명시적 상대 임포트:
  • from .models import WaffleCone
• 앱의 이름을 변경할 일이 생기거나, 이름이 충돌되는 경우를 피할수 있다.
• 재사용하는 경우 바로 사용할 수 있게됨.
• anti-pattern
  • from cones.models ~~
  • from models import ~~ (implicit relative import 이것도 안티패턴임.)

1.5 import *은 피하자

이유: 다른 python module의 namespace들이 우리가 작업하는 module의  namespace에 추가로딩되거나, 기존것에 덮여쓰이는일이 발생할 수있다.

1.6 장고 코딩 스타일

https://docs.djangoproject.com/en/4.0/internals/contributing/writing-code/coding-style/

이것을 따르도록하자.

1.6.2 

(이 파트는 Two scoops of Django 3.x 영어판을 참고함)

실제 매핑되는 url은 대시를 써도된다.( Dashes in actual URLs are fine (e.g. route=’add-topping/’ )  

#안티패턴
  patterns = [
       path(route='add/',
           view=views.add_topping,
           name='add-topping'),
       ]
       
#good pattern
patterns = [
       path(route='add/',
           view=views.add_topping,
           name='toppings:add_topping'),
       ]

더보기

(이 글 작성자 주.

장고 초심자를 위해서 (나다. ) name은 도대체 언제 쓰이는지 알아봤다.)

https://docs.djangoproject.com/en/4.0/topics/http/urls/#:~:text=Reverse%20resolution%20of%20URLs%C2%B6

 

URL dispatcher | Django documentation | Django

Django The web framework for perfectionists with deadlines. Overview Download Documentation News Community Code Issues About ♥ Donate

docs.djangoproject.com

from django.urls import path

from . import views

urlpatterns = [
    #...
    path('articles/<int:year>/', views.year_archive, name='news-year-archive'),
    #...
]



##########################
<a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a>
{# Or with the year in a template context variable: #}
<ul>
{% for yearvar in year_list %}
<li><a href="{% url 'news-year-archive' yearvar %}">{{ yearvar }} Archive</a></li>
{% endfor %}
</ul>

#########################
from django.http import HttpResponseRedirect
from django.urls import reverse

def redirect_to_year(request):
    # ...
    year = 2006
    # ...
    return HttpResponseRedirect(reverse('news-year-archive', args=(year,)))

+

그 name에 언더스코어를 써야하는 이유가 이게 더 pythonic하고, IDE랑 text editor에 친화적이라서.라고 되어있어서 실험을해봤다.

직접 해보니 대시를 마이너스로 인식하는 경우가 있더라.

1.8 통합개발환경이나 텍스트 편집기에 종속되는 스타일의 코딩은 지양한다.

(다른 에디터를 쓰는 사람들도 있기 때문.)

 일단 당연히 트랜잭션의 무결성을 유지하도록 설계가 되어야한다.

이러기 위해서는 원자성, 일관성, 고립성, 지속성이 유지가 되어야한다.

1) 원자성이 보장되기 위해, atomic을 수행한다.

기본적으로 장고는 auto_commit이다.

이에 따라 해당 계좌에 가서,  잔액을 바꾸고, 거래내역을 등록하는 이 2가지 행위가 각각 이루어질 우려가 있으므로,

with transaction.atomic()을 넣어줘야 한다.

참고:

https://brownbears.tistory.com/573

https://docs.djangoproject.com/en/4.0/topics/db/transactions/

2) 일관성 같은 경우는 테이블이 생성될 때  명시되므로, 크게 신경 쓸 필요없다.

3) 고립성을 보장하기 위해, 동시성 제어를 한다.(concurrency control)

-은행이니 만큼, 최고수준의 격리를 하여서 안정성을 확보해야한다.

-main db 와 replication db로 나누어서, write, update는 main에서만 하고, read는 replication db 에서만 가능하게 한다.

-쓰기와 관련된 충돌은 select_for_update()를 통해서 방지한다.

-읽기/읽기와 관련된 충돌은 고립수준을 serializable 모드로 하여서 방지한다.

**TMI:

main -replica db로 나뉘어져 있는 상황에도 isolation을 신경써야할까?

- 그렇다. 왜냐하면 main db가 다운되면 replica가 maindb가되기 때문이다.

4.  지속성 역시 aws에서 로그기록을 남기도록 설정하였다.

추가적으로 aws-rds에서 multi-az를 활성화하였다. 

이를 통해 혹시나 생길 db instance 중단에 standby replica로 대체하도록 하였다.

https://support.bespinglobal.com/support/solutions/articles/16000038897--aws-rds-multi-az-