개인적으로 시의적절하고
맘에 드는 구성이다 ✨️
다 기억하기도 어렵고
이해가 다 될 리도 없으니
스트레스 많이 받지 말고
이런 게 있구나 하면서 눈에 익히고 넘어가기
대신 가급적 의식을 날리지는 말고 끝까지..
한두 번 더 읽어야 할 것 같은 책은 사자
인덱스
지성사의 가장 위대한 발명품, 색인의 역사
데니스 덩컨(지은이), 배동근(옮긴이)
arte(아르테)
도판 차례 008
서문 011
1장 서열화의 취지: 알파벳순 배열에 대하여 037
2장 색인의 탄생: 설교와 교육 081
3장 그것이 없었더라면 어떻게 되었을까?: 쪽 번호가 만든 기적 133
4장 지도냐 실제 영토냐: 시험대에 오른 색인 173
5장 “토리당 녀석에게는 절대 내 『영국사』 색인을 맡기지 마오!”: 색인을 둘러싼 논쟁 209
6장 소설에 색인 달기: 작명은 늘 그렇듯 어려운 기술이다 261
7장 ‘모든 지식으로 향하는 열쇠’: 보편 색인 309
8장 루드밀라와 로타리아: 검색 시대의 책 색인 349
마지막 장: 독서 기록 보관소 397
주 413
감사의 말 435
옮긴이의 말 440
부록: 컴퓨터가 생성한 색인 447
색인 453
웹개발자 로드맵
수치와 데이터로 증명하는 가이드북
양동준(지은이)
비제이퍼블릭
서문
이 책을 쓴 이유
들어가며
ChatGPT 걱정하시나요?
01 어떤 프론트엔드 개발자가 되어야 할까요?
02 ChatGPT를 프론트엔드로 사용하면서 느낀 점
03 어떤 백엔드 개발자가 되어야 할까요?
04 ChatGPT를 백엔드로 사용하면서 느낀 점
05 마무리 정리
이 책에서 어떤 것을 배울 수 있나요?
나는 프론트엔드? 백엔드?
01 프론트엔드를 택할 때 고려할 점
02 백엔드를 택할 때 고려할 점
Part 1 프론트엔드 개발자
1장 프론트엔드 로드맵 - 타임라인
[필수] 빠른 취업을 위한 타임라인
[옵션] 최신 기술 맛보기
[참조] 초보자를 위한 프론트엔드 로드맵
2장 프론트엔드 신입 채용 조건
3장 프론트엔드 로드맵 자세히 알아보기
01 The odin project
02 React 튜토리얼 공부하기
03 Harvard CS50
04 React + MUI로 프로젝트 만들기
05 Vercel, Netlify, AWS amplify 배포
06 Git + AWS S3 + AWS cloudfront 배포
07 Harvard CS50 web(option)
08 AWS serverless REST API 설계
09 업비트 REST API 서버리스로 만들기
10 React+MUI+D3js+로그인+redux (크립토 앱 만들기
4장 전공지식 더 깊게 공부하기
01 프론트엔드 부트캠프 추천
5장 CSS 정복하기
01 유명 라이브러리
02 추천 공부 방법
03 실용적인 팁
04 더 실용적인 팁
6장 프론트엔드 면접에 자주 나오는 질문
Part 2 백엔드 개발자
1장 백엔드 로드맵 - 타임라인
[필수] 빠른 취업을 위한 타임라인
[옵션] 최신 기술 맛보기
[참조] 초보자를 위한 백엔드 로드맵
2장 어떤 언어를 선택해야 할까?
01 Node.JS의 성장
02 Java의 MSA, Spring Cloud
3장 백엔드 신입 요구사항
4장 백엔드 로드맵 자세히 알아보기
01 The odin project
02 Harvard CS50
03 하나의 언어에 집중하자
04 사이드 프로젝트에 참여하자
05 AWS EC2 배포해 보자
06 AWS serverless 경험해 보자
07 PostgreSQL 사용하자
08 MongoDB를 사용하자
09 VueJS로 프론트 개발하자
5장 전공지식 더 깊게 공부하기
01 공부에 도움이 되는 책들
02 ERD 설계
03 부트캠프 추천
6장 백엔드 면접에 나오는 질문들
Part 3 부록
1장 코딩 테스트 통과하는 방법
01 언어 선택
02 테스트 유형
03 유의사항
04 준비할 수 있는 사이트
2장 사이드 프로젝트 구하는 방법
3장 이력서 작성법
01 좋은 이력서란 어떤 걸까요?
02 포트폴리오의 중요성
03 포트폴리오 추천과 팁
04 간단하고 명확하게 작성하기
05 간단한 자기소개서
06 경험을 정량화해서 강조하기
07 기술 스택
08 포트폴리오를 문제와 해결책으로 쓰는 법
09 각 지원 분야에 맞게 이력서 맞춤 설정
10 요약
4장 실시간 상담에서 나온 프론트엔드 Q&A
5장 실시간 상담에서 나온 백엔드 Q&A
수학퍼즐
프로그래머의 뇌를 단련하는
마스이 토시카츠(지은이), 노슬기(옮긴이)
프리렉
제1장 입문편 ★ 프로그램으로 주어진 문제를 풀어보자
2진수와 10진수
01 앞뒤가 같은 10진수 만들기
02 수열의 사칙연산
03 카드를 뒤집어라!
04 막대 자르기
05 아직도 현금으로 계산하다니!
06 콜라츠 추측
07 날짜의 2진수 변환
08 똑똑한 로봇 청소기
09 남녀 불균형
10 룰렛의 최댓값
제2장 초급편 ★★ 간단한 문제를 풀어 알고리즘의 효과를 실감해 보자
비용 대비 효과 생각하기
11 피보나치 수열
12 제곱근의 숫자
13 복면산을 만족하게 하는 것은 몇 가지일까?
14 월드컵 출전국 끝말잇기
15 계단에 서서 수다 떨기
16 끈 세 개로 만드는 사각형
17 30인 31각에 도전!
18 케이크 자르기
19 친구의 친구는 친구?
20 수난의 파사드 마방진
21 배타적 논리합으로 만드는 삼각형
22 엉키지 않는 실 전
23 블랙잭으로 대박!?
24 완벽하게 꿰뚫은 스트럭아
25 운동화 끈 멋지게 묶기
26 효율적인 입체 주차
27 우회전을 못해도 괜찮다고?
28 적절한 동아리 활동 배분
29 합성 저항으로 만드는 황금비율
30 멀티 탭으로 만든 문어 다리 배선
제3장 중급편 ★★★ 알고리즘을 연구하여 고속 처리를 구현하자
빅오 표기법과 계산량
31 최단 경로의 계산
32 직사각형 타일을 깔아보자!
33 운명적 만남은 몇 가지?
34 0과 7로 만든 대칭수
35 주사위 뒤집기
36 7세그먼트 코드의 반전
37 ‘흰색’으로 채워라!
38 재배열 반복
39 아름다운 IP주소
40 하나의 숫자로 만드는 1234
41 카드를 뒤섞어 역순 만들기
42 유리컵 속 물을 반으로
43 소수 매트릭스
44 정렬의 교환 횟수 최소화하기
45 오직 하나뿐인 ○×
46 그레이 코드의 루프
47 반전으로 만드는 엇갈리게 놓기
48 급할수록 돌아가라
49 퍼펙트 셔플
50 동시에 끝나는 모래시계
51 과자로 장난하기
52 같은 숫자로 협공하기
53 게으른 주판
54 공평하게 나눈 케이크
제4장 고급편 ★★★★ 시점을 바꾸어 고속화를 노려보자!
소스 코드의 개성
55 사다리 타기의 가로 선
56 가장 빠른 비상연락망
57 수건 돌리기의 총 달린 거리
58 셀의 병합 패턴
59 같은 크기로 분할하기
60 교차하지 않고 한붓그리기
61 달력의 최대 직사각형
62 미로에서 만나기
63 귀찮은 캐치볼
64 한붓그리기로 도형 그리기
65 십자말풀이 퍼즐을 만들어라!
66 옆자리를 비우는 게 매너?
67 남녀 평등한 자리 바꾸기
68 청백 노래대결
데이터 엔지니어를 위한 97가지 조언
크고 작은 데이터를 관리하기 위한 강력한 실제 모범 사례와 다양한 핵심 원칙
토비아스 메이시(지은이), 임혜연(옮긴이)
길벗
01_서점 재고관리 시스템으로 알아보는 최종 일관성
02_A/B 테스트, 어떻게 해야 할까?
03_스토리지 계층에 대하여
04_분석: 마이크로서비스 아키텍처의 숨겨진 접착제
05_인프라스트럭처를 자동화하라
06_파이프라인 테스트를 자동화하라
07_데이터 파이프라인의 배치 모델을 신중히 검토하라
08_은탄환 신드롬을 경계하라
09_데이터 엔지니어 경력 쌓기
10_데이터 파이프라인을 보여주는 비즈니스 대시보드
11_주의: 데이터 과학 프로젝트가 벌거벗은 임금님 이야기가 되지 않으려면
12_변경 데이터 캡처
13_계약으로 기능하는 컬럼 이름
14_합의된 개인 정보 보호 데이터 수집
15_데이터 소비자와 원활한 업무 관계를 구축하라
16_데이터 엔지니어링은 스파크와 같지 않다
17_자율성 및 신속한 혁신을 돕는 데이터 엔지니어링
18_데이터 과학자 관점에서 보는 데이터 엔지니어링
19_재사용 및 확장 가능한 코드를 만드는 데이터 파이프라인 디자인 패턴
20_데이터 엔지니어를 위한 데이터 품질
21_데이터 엔지니어를 위한 데이터 보안
22_요약 통계 이상의 데이터 유효성 검증
23_과거에도 현재에도 미래에도 존재하는 데이터 웨어하우스
24_로그 중심 아키텍처에서의 메시지 정의 및 관리 방식
25_데이터 생성 과정 정보를 파악해서 파이프라인을 이해하기 쉽게 하라
26_코드뿐만 아니라 커뮤니티를 개발하라
27_클라우드 세상의 효율적인 데이터 엔지니어링
28_데이터 레이크 아키텍처를 받아들여라
29_데이터 사일로를 받아들여라
30_재현 가능한 데이터 과학 프로젝트 엔지니어링
31_안정적인 데이터 처리를 위한 5가지 모범 사례
32_유지 보수에 집중하고 ETL 작업을 분리하라
33_동료에게 이중 기록을 권하지 마라
34_기본 지식
35_구조화를 SQL로 되돌리기
36_데이터 프로덕트에 잠재적인 문서를 포함한 프런트엔드를 제공하라
37_데이터 파이프라인의 진화
38_제품처럼 데이터 플랫폼을 구축하는 방법
39_데이터 반란을 방지하는 방법
40_관리하는 데이터의 바이트당 가격을 파악하라
41_처리 지연 속도를 의식하라
42_RDBMS와는 다른 NoSQL 데이터베이스 사용법을 배워라
43_로봇을 이용해서 규칙을 강제하라
44_사용자 의견을 듣되 지나치게 따르지 마라
45_저가형 센서와 데이터 품질
46_기계 동작 방식에 대한 공감력을 유지하라
47_데이터 그 이상의 메타데이터
48_데이터 플랫폼의 핵심 요소인 메타데이터 서비스
49_데이터 레이크는 ACID를 제공하지 않으므로 조심하라
50_모던 데이터 스택을 위한 모던 메타데이터
51_상당수의 데이터 문제는 빅데이터 없이 풀 수 있다
52_소프트웨어 엔지니어링에서 데이터 엔지니어링으로 전환하기
53_데이터 엔지니어를 위한 관측 가능성
54_완벽함은 적절함의 적이다
55_파이프의 꿈
56_데이터 레이크가 지옥이 되지 않으려면
57_메시징 시스템에서 사용자 경험의 우선순위 높이기
58_개인 정보 보호 문제는 남의 일이 아니다
59_QA에 대한 흥미로운 사실
60_데이터 엔지니어가 머신 러닝 프로젝트에 관여할 때 주의할 7가지 사항
61_분석용 데이터 웨어하우스 선택을 보는 6가지 관점
62_빅데이터 세상의 작은 파일
63_스트리밍은 배치와 다르다
64_늦게 도달하는 데이터
65_데이터 프로젝트를 성공시키려면 기술이 뒤로 물러서야 한다
66_데이터 엔지니어링 프로젝트에서 필수적으로 확인해야 하는 10가지
67_데이터 파이프라인의 관건은 속도가 아니다
68_데이터 엔지니어링의 할 일과 하면 안 되는 일
69_모두가 아는 ETL의 종말
70_시조 작성 방식으로 소프트웨어 작성하기
71_데이터 입출력에 숨어 있는 비용
72_독점 소프트웨어와 오픈 소스가 전쟁 중이라는 거짓말
73_CAP 정리의 영향
74_데이터 계보의 중요성
75_데이터 누락이 갖는 여러 가지 의미
76_경력을 망치는 한 문장
77_데이터 품질 테스트에 오픈 소스를 사용하여 얻는 3가지 이점
78_데이터 엔지니어링에서 중요한 3R
79_두 부류의 데이터 엔지니어링과 데이터 엔지니어
80_빅데이터 확장성의 음양
81_데이터 프로세싱에서의 스레드 사용 및 동시성
82_분산 프로그래밍에서 중요한 개념 3가지
83_의미론적인 시간은 기다려주지 않는다
84_도구가 아니라 패턴과 관행이 중요하다
85_총 소유 기회비용
86_가지각색의 데이터 도메인에서 문제를 해결하는 방법
87_데이터 엔지니어란 어떤 직종인가? 힌트: 데이터 과학의 조력자
88_데이터 메시와 메시를 망치지 않을 방법
89_빅데이터란 무엇인가?
90_인정받지 못할 때 해야 할 일
91_데이터 과학 팀이 가치를 창출하지 못했다면
92_잘 모르면서 대충 접근하지 말아야 하는 경우
93_데이터 공유에 주의해야 하는 경우
94_발언할 때와 경청할 때
95_데이터 과학 팀에 전문가 대신 제너럴리스트가 필요한 이유
96_엄청난 데이터에 따르는 엄청난 책임
97_데이터 검증 실패! 그 다음은?
개발자의 글쓰기
변수 네이밍부터 릴리스 노트, 장애 보고서, 기술 블로그까지, 프로그래머의 글쓰기 고민 끝!
김철수 (지은이)
위키북스
▣ [프롤로그] 개발자의 글쓰기는 달라야 한다
개발자는 글을 못 쓴다?
개발자 글쓰기의 특징: 정확성, 간결성, 가독성
개발자의 글쓰기
▣ 1장: 개발자가 알아야 할 글쓰기 기본
01 문장과 단락을 구조화하는 법
___문장을 구조화하는 법
___서술식, 개조식, 도식의 차이
___개조식 서술 방식과 글머리 기호
___단락을 구조화하는 위계
02 쉽게 쓰는 띄어쓰기와 문장 부호
___가장 쉬운 띄어쓰기 원칙
___오해하기 쉬운 문장 부호(큰따옴표, 작은따옴표)
03 영어 단어 선택과 외래어 표기법
___비슷한 듯 다른 듯, 단어 선택
___외산 제품 표기와 외래어 표기법
▣ 2장: 개발 시간을 줄여주는 이름 짓기와 주석 쓰기
01 네이밍 컨벤션, 이유를 알고 쓰자
___개발자의 가장 큰 고민은 이름 짓기
___이름 짓기는 창조가 아니라 조합
___코드의 네이밍 컨벤션은 영어 표기법을 상속받았다
___파스칼 표기법으로 클래스 이름 짓기
___카멜 표기법으로 함수·변수의 이름 짓기
___상수는 모두 대문자로 쓴다
___패키지와 모듈은 모두 소문자로 쓴다
___BEM 표기법
___가독성과 소통이 먼저다
02 변수 이름을 잘 짓는 법
___i는 변수 이름이지만 d는 아니다
___긴 이름? 짧은 이름? 검색 잘 되는 이름!
___복수형을 나타내는 s를 붙일까 말까?
___약어를 쓰는 것이 좋을까? 안 쓰는 것이 좋을까?
___중요한 단어를 앞에 쓴다
___함수 이름 짓는 순서
03 좋은 이름의 기준, SMART
___한 번에 좋은 이름을 지을 수는 없다
___좋은 이름이 가진 5가지 특징
___easy to Search: 검색하기 쉽게 이름 짓는 법
___easy to Mix: 조합하기 쉽게 이름 짓는 법
___easy to Agree: 수긍하기 쉽게 이름 짓는 법
___easy to Remember: 기억하기 쉽게 이름 짓는 법
___easy to Type: 입력하기 쉽게 이름 짓는 법
04 좋은 코드에는 주석이 없다?
___이름을 잘 지으면 주석을 줄일 수 있다
___처음부터 주석 없이 코딩하는 연습을 하자
___주석이 필요한 때도 많다
05 다른 개발자를 배려하는 주석 쓰기
___코드는 의미를, 주석은 의도를
___주석의 반복
___주석의 발췌와 요약
___주석도 코드다
▣ 3장: 사용자와 소통하는 에러 메시지 쓰기
01 에러 메시지를 쓰기 전에 에러부터 없애자
___친절한 404, 불친절한 404
___404 에러가 죄송할 일인가?
___깨진 링크는 개발자의 책임이다
___개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자
02 사용자 에러 메시지를 제대로 쓰는 법
___사용자 에러에 대처하는 메시지
___에러 메시지를 보여주는 순서
___오락가락 메시지와 버튼 메시지
03 사용자의 에러를 줄이는 메시지 구조화
___버튼의 순서
___사용자의 반복 에러를 막는 법
04 에러 메시지 대신 예방 메시지를 쓰자
___서비스를 이해하면 에러를 예방할 수 있다
___사용자를 이해하면 에러를 예방할 수 있다.
___닭이 먼저? 알이 먼저?
▣ 4장: 독자 관점에서 릴리스 문서와 장애 보고서 쓰기
01 체인지 로그를 분류, 요약, 종합하는 법
___체인지 로그의 양과 만족도의 관계
___1단계: 선정하기
___2단계: 분류하기
___3단계: 요약하기
___4단계: 종합하기
02 고객에게 유용한 정보를 쓰자
___개발자 관점과 고객 관점
___과거를 리뷰하고 미래를 보여주자
___Semantic Versioning(유의적 버전)
03 릴리스 문서는 문제 해결 보고서처럼 쓰자
___문제와 문제점을 구별하자
___문제, 문제점, 해결책, 후속 계획 순으로 적자
___법적인 문제를 고려해서 쓰자
04 비즈니스를 이해하는 장애 보고서 쓰기
___장애 보고서의 특징
___질문에 대답하는 신속한 글쓰기
___원인과 이유를 찾는 분석적 글쓰기
___상사를 고려하는 비즈니스 관점의 글쓰기
___원하는 것을 얻는 정치적 글쓰기
▣ 5장: 설명, 묘사, 논증, 서사로 개발 가이드 쓰기
01 서비스 개념을 범주, 용도, 특징으로 설명하자
___범주, 용도, 특징
___범주를 정확하고 적절하게 선택하자
___용도를 범주의 핵심 기능으로 기술하자
___특징을 장점과 강점에서 뽑아 쓰자
02 정확히 이해하도록 그림과 글로 묘사하자
___글에 묘사를 더하면 이해가 빠르다
___글과 그림의 내용을 일치시키자
___객관적 묘사와 주관적 묘사 둘 다 하자
03 논증으로 유용한 정보를 제공하자
___의견을 쓰려면 근거를 대자
___거칠게도 공손하게도 쓰지 말자
___주장과 이유의 거리를 좁혀서 쓰자
___문제와 답의 거리를 좁혀서 쓰자
04 서사를 활용해 목차를 만들자
___개발과 서사
___독자의 수준 대신 기술의 범용성을 기준으로 쓰자
___순서에서 단계를, 단계에서 목차를 만들자
▣ 6장: 수주를 돕는 SI 제안서 쓰기
01 개발자가 알아야 할 제안서 작성 원칙
___개발자와 제안 PM의 차이
___시스템 구성도의 본질은 그림이 아니다
___첫째, 제안요청서 분석
___둘째, 논리적 완결성
02 고객의 문제 인식과 제안사의 문제 해결 능력
___문제 인식과 문제 해결 능력
______① 경쟁사와 비교하여 제안하라
______② 일단 동감하고 다른 방안을 제시하라
______③ 고객이 문제를 중대하게 인식하게 만들어라
______④ 경쟁사의 전략을 확인해서 대처하라
03 고객의 요구사항은 변할 수밖에 없다
___개발은 고객 요구 실현
___요구사항을 분석하지 말고 제시하라
___변화하는 요구사항에 대비하라
04 고객의 총 만족도를 높이자
___요구라고 다 같은 요구가 아니다
___카노 모델로 본 요구의 세 가지 종류
▣ 7장: 기술 블로그 쉽게 쓰고 운영하기
01 기술 블로그를 쉽게 쓰는 방법 3가지
___개발자가 기술 블로그를 잘 못 쓰는 이유
______첫째, 주제 의식을 버리고 소재 의식으로 쓰자
______둘째, 독자 수준이 아니라 자기 수준으로 쓰자
______셋째, 재미있게 글을 쓰자
02 글의 종류별로 목차 잡는 법 I - 저술
___기술 블로그의 4종류, 저, 술, 편, 집
______저: 개발기는 목차를 잘 잡아서 본문부터 쓰자
______술: 원전을 비교하고 실험해 풀이해서 쓰자
03 글의 종류별로 목차 잡는 법 II - 편집
______편: 순서를 요약하여 쓰자
______집: 글쓰기가 두렵다면 자료를 모아 핵심을 엮어서 쓰자
04 기업의 기술 블로그 운영 팁
___기술 블로그는 회사의 가치를 높인다
___기술 블로그도 투자를 해야 살아난다
___개발자의 글쓰기는 회사의 문화를 반영한다
___협업해서 글쓰기, 짝 글쓰기를 해보자
▣ [에필로그] 회사가 개발자 글쓰기 교육을 하자
정보처리기사
필기(2020 이기적), 실기(2030 시나공)
책이 두껍지만, 준비하고 있는데 이쯤은 보면 좋을 것 같아서 중고로 구매함
ㅎㅇㅌ
되새기면서 보려고
'개발자의 글쓰기'는 종이책으로, ☆ ☆ ☆ ☆ ☆
'수학퍼즐'은 종이책 중고로 구입함
'데이터 엔지니어를 위한 97가지 조언'은 e-book으로 구매할 예정
'웹개발자 로드맵'은 내용이 다양하게 수록되어서 재밌게 봄
중간중간 유용한 내용들도 있어서 내용을 별도로 기록해 두었다.
'인덱스'는 예쁜 책 모양에 비해 내용이 논문이어서......
그래도 흥미로운 주제고 은은하게 재밌는 책이었다.
앞으로 인덱스는 더 중요해지지 않을까 하는 생각도 왠지(?) 들었다.
역사가 대개 그렇듯이 울퉁불퉁 어이없는 과정도 거쳐 여기까지 도달한다 ㅋㅋㅋ
(아래 이미지는 챕터 지날 때마다 인용된 글들 중 일부다. )
