#9. IT 5분 잡학사전 - 혼돈 상태 해제 '~가 아니다!'

• Day.9
• 오늘 읽은 범위: 챕터 30 ~ 챕터 34
• 오늘의 TIL 3줄 요약

1.  코드는 나만을 위한 것이 아니다.
2.  SQL과 DBMS는 같은 것이 아니다. SQL - DBMS - 데이터베이스를 생각하자
3.  깃과 깃허브는 같은 게 아니다.

---

책에서 기억하고 싶은 내용을 써보자

• 개발자라면 코드를 살아 있는 생명체처럼 대해야 해.(181p)
• SQL은 여러분의 미래에 확실히 큰 도움이 될 수 있는 언어니까 꼭 시간을 투자해서 공부해 봐.(189p)

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적기

[ 혼돈 상태 해제 '~가 아니다!' ]

프로그래밍에 대해 알아보기 시작한 뒤로 정말 헷갈리는 것들이 자주 등장한다.

SQL의 경우 이 책을 읽기 전까지도 그냥 데이터베이스라고만 알고 있었다. DBMS의 존재도 어디서 들어본 거 같긴 한데 정확히 모르고 있었다고 하는 것이 옳겠다. SQL - DBMS - DB의 관계로 이어진다는 것도 어디선가 들어본 것 같기도 한데, 그다지 비중있게 다루지 않아서 정확히 이해하지 못하고 있다가 이번 독서로 깨닫게 되었다.

깃과 깃허브는 최근에 노마드 코더에서 강의를 들으면서 개괄적인 이해를 하고 있었기 때문에 그에 대해 다시 복습하는 느낌에 가까웠다.

버전 정보는 이번에 처음 알게 되었는데, 버전으로 기입하는 숫자에 의미가 있고 그 숫자 작성 방식이 일정한 규칙을 따르고 있음을 이번에 새롭게 알게 되었다.

---

 

ep30. 코로나가 준 레거시 시스템의 교훈

2020년 코로나 확산 때 갑자기 코볼 개발자를 찾았음=>왜?! 갑자기 실업자가 생겨서 지원해야 됐는데 그 시스템을 코볼로 만들었었음.

코볼?! 1959년생, 실업자 시스템도 30년이나 된 사이트였던 것이지 이 사건은 유산(레거시legacy)!

코볼? 지금의 파이썬과 같은 거였어 ( 미국 은행 시스템 43%가 코볼, ATM 95%가 코볼이었음 )

문제점이라면 커뮤니티가 너무너무 적음. 평균 연령도 50세...ㅜ

교훈: 프로그램 책임있게 만들어라, 끊임없이 관리해라

=> 돌아가기만 하면 그만인 코드? NO

=> 한 번 구축하면 끝이 아니다 끝없이 관리해야 한다

 

ep31. 데이터와 단짝 친구, SQL

SQL은 자바, 파이썬만큼 유명한 언어! 데이터 다루기는 중요하고 SQL은 분명 도움이 될 것임

SQL: structured query language 즉, 데이터베이스에 어떤 질문 또는 문의를 하기 위해 어떤 구조를 가진 언어.

== 데이터베이스를 다루는 언어

데이터베이스는 데이터를 보관하는 창고 역할만 함.

직접 정리No처리No=>이건 DBMS 데이터베이스 관리 시스템database management system 이 함.

[ SQL -> DBMS -> 데이터베이스 ]  DBMS를 거쳐서 데이터베이스와 상호작용.

==> SQL은 DBMS와 대화하기 위한 언어임.   SQL != 데이터베이스, 근데 같이 다니니까 편의상 같이 부르는 거임

MySQL, PostgreSQL, SQLite, Oracle, MariaDB 등

상호작용은 어떻게? 엑셀이랑 똑같이 생김. 

엑셀의 시트 == 데이터베이스의 테이블table

<의 187쪽 그림 참고. 테이블 그림>

간단히 선택하는 방법으로 SELECT~ FROM~; 어떤 테이블에서 선택하는 것을 말함. '어떤 열을 선택한다, 어느 시트(테이블)에서!'라는 뜻

SELECT email FROM users WHERE age >21; '이메일열 유저시트에서, 나이 21보다 많은 사람만 선택!'이란 뜻

=> 영어만 알아도 충분히 이해하기 쉬움.

 

But SQL 모르는 개발자 많음. 왜? ORM때문임.

ORM object relational mapping SQL 번역기 같은 도구인데, 개발자한테 익숙한 언어로 바꿔주니까 자꾸 SQL 공부를 안 하게 됨. 예를 들어서 파이썬에서는 장고, node.js는 시퀼라이즈, 타입ORM 등이 있음

문제가 있다면 여기에 지나치게 의존적이게 됨. 근데 문제는 나중에 ORM으로 안되는 상황이 생길 수 있다는 거임.

시간 투자 해보면 더 뛰어난 개발자가 될 수 있을 것!

 

ep32. NoSQL이 뭐죠?

NoSQL은 SQL과 성격 자체가 다름. NoSQL은 되게 많은데 도큐먼트 데이터베이스, 키값 데이터베이스, 그래프 데이터베이스를 살펴보자

- 도큐먼트 데이터베이스 예) 몽고디비(mongoDB)데이터를 JSON 도큐먼트 형태로 저장함.

[
	{"id": 1, "name":"개사료", "price": 30000},
    {"id": 2, "name":"고양이똥", "price": 10000},
]

이런 모양임. 아까 봤던 엑셀같은 모습이랑은 완전 다름.

SQL은 표 형태라서 매우 정적인데, JSON 도큐먼트는 대괄호, 중괄호로만 구성되고 모양, 종류 상관 없이 저장 가능하다는 장점.

 

- 키값 데이터베이스 예) 카산드라디비CassandraDB, 다이나모디비DynamoDB

한 행의 열이 엄청 넓은 데이터베이스 느낌. 읽고 쓰는 속도가 정말 빠름!!!

대용량 데이터를 빠르게 저장해야 하거나 읽어야 한다면 카산드라디비!

 

- 그래프 데이터베이스  열, 도큐먼트는 필요 없지만 노드는 필요. 

 

특별히 어떤 데이터베이스가 더 좋다 아니다는 말할 수 없음. 결국 자신에게 필요한 것을 사용하는 게 베스트

 

ep33. 깃&깃허브 똑같은거냐고?

깃Git과 깃허브Github가 같냐? 연관은 았지만 다름.

 

깃은 파일 이력을 관리하는 프로그램: 마치 조선시대의 사관처럼 항상 지켜보며 기록하는 역할임. 특히 같은 파일도 다른 버전으로 보관까지 함 대박. 도르마무 가능하다는 거임

동료와 함께 쓸 때도 매우 유용함. 같은 파일을 복사해서 각자 컴퓨터에 저장해서 작업한 뒤에 다른 사람이 변경한 곳과 내 변경점을 비교해서 다시 하나로 만들수도 있음.

 

깃허브는? 깃이 내용 갖고 있는 것을 어디서든 접근할 수 있게 해둔 저장소임.

깃허브==파일클라우드 서비스와 같다고 볼 수 있음. 차이점은 파일만이 아니라 파일 변경 이력도 같이 공유한다는 점임.

깃헙에 깃 이력들 올리는 거 : 푸시 내려받는거 : 풀

깃헙 외에도 깃랩, 비트버킷도 비슷한 기능을 제공함!!

 

ep34. 버전을 표기하는 방법도 있어요?

대충 여기저기 프로그램 보면 1.4.6이런거 본 적 있지? 사실 이 버전 숫자 자리에는 의미가 있음.

이렇게 세 개의 숫자로 표기하는 버전 표기 방식을 시맨틱 버저닝(semantic versioning specification) SEM .

예를 들어서 4. 0. 5라고 하자

4이 있는 자리의 수는? 엄청나게 큰 변화가 있었을 때 : 새 집으로 이사한 수준

0이 있는 자리의 수는? 마이너한 업데이트 : 예쁜 카페트 깐 정도의 수준

5가 있는 자리의 수는? 패치나 버그 수정을 의미함. 기존 프로그램의 오류 수정

4.0.25는 오류 25번 수정했다는 뜻도 됨.

개발자는 꼭 맥북을 사용해야 하나?
Q. 시간을 많이 절약해 줄 수 있는 물건인가? 
Q. 동기 부여를 할 수 있는 물건인가?
Q. 방해 요소를 줄일 수 있는 물건인가?
이 3가지 질문을 통해 도구가 나에게 필요한지 알아보도록 하자.

 

---

궁금한 내용, 잘 이해되지 않는 내용

• 궁금한 내용