JOIN이 늘면서 복잡한 쿼리를 작성하고 있어 고민입니다.
해야하는 연산이 있을 때 BE에서 하는 것과 DB 쿼리로 하는 것을 어떻게 분배해야 할까요??
검색 총 개수와 슬라이스된 데이터들을 받아와야 하는데 쿼리를 2개 날리는 게 좋을까요 아니면 deprecated되더라도 SQL_CALC_FOUND_ROWS(FOUND_ROWS)를 쓰는 게 나을까요
읽고 쓰기의 성능, 용어, ERD설계 등등 여러가지가 많은 것 같습니다!
어떤 것을 중심으로 공부하면 좋을까요?
uid를 안전한 함수로 해싱하면 보안적인 장점은 잡을 수 있겠으나, 그만큼 속도를 놓치겠죠…?
요구사항을 보고, 데이터베이스 테이블을 설계할 때, 중요하게 보아야하는 점과 사고하는 흐름이 궁금합니다!
다른 SQL DB도 있는데 왜 MySQL이 가장 대중적인 SQL DB가 되었는지 궁금합니다
부스트캠프 과정에는 자바와 스프링이 없는 것 같은데, 부캠을 진행하면서 따로 공부해야할까요?
Access token까지는 발급을 했는데, 이걸 데이터베이스에 저장해놓으면 회원가입을 한걸로 생각하면 될까요?
쿼리문 날리고 값 확인하는 과정이 mysql 워크벤치가 너무 불편한거같습니다..테스팅과정에서 너무 불편한거같은데 추천할만한 다른 테스팅방법이있을까요? (ex 쿼리문을 날리고 확인하는 과정, session테이블 생성 등등)
블로그 글을 보면 다른 사람이 이해하기 쉽게 글을 잘 작성하시는 편이신데, 글을 쓰실 때 팁이 있을까요? 남이 이해하기 쉽게 공부한 내용을 정리하는 것이 너무 어렵네요ㅠㅠ…
개발을 시작하면서 습관을 들이려고 하신건가요?
blocking + async 방식이 맞습니다.
보통 JPA를 많이 씀,js에서는 TypeORM을 쓰지만 유지보수를 하지 않고 있음
무척 자주 쓰지만 정말 복잡한 데이터를 다루는 경우에는 QueryBuilder를 씁니다.
다 골고루 섞어 쓰는 편입니다.,Layered는 항상 쓰는 편
에러를 어떻게 관리할 것인가로 접근하면 좋습니다.
Test는 필요한데 TDD까지는 잘 모르겠다.
회사마다 다릅니다.
- 퍼블리싱 팀이 있는 경우도 있고
- 네이버 같은 경우에는 마크업 개발자가 따로 존재함
- 그런데 프론트엔드 개발자는 마크업에 대한 깊은 지식은 당연히 요구
- 대규모에서는
- 분산 시스템을 구축하고
- apache kafka 같은 스트림 서버를 이용해서 분산 처리
- “스트림으로 처리한다”
- Redis 같은 캐싱 디비를 이용하자.
- 바로 DB에 저장하는게 아니라
- 캐시에 저장 후
- 특정 시점에 DB에 반영
- 라우팅(페이지 이동)을 할 때 토큰 검사 하기
- 라우팅 할 때 토큰이 유효하지 않으면 로그인 페이지로 이동
- 로그인하고 되돌아오기
- 보안은 필요한 개념 정도만 이해하면 좋고
- 실제 구현하는 것들은 구현이 필요한 경우에만 하자
- 백엔드에서의 검증은 할 수 있는건 거의다 해야 한다
- 클라이언트가 브라우저만 되는게 아니라, 서버가 될 수 있다.
- 서버에서 유효성 검증은 필수
- 어떻게 하면 DB 접근을 최소화 할 수 있을까?
- 실시간으로 가져와야 하는 데이터인가?
- 실시간이 필요 없는 데이터인가?
- 실시간으로 필요한 데이터가 아니면 그냥 캐시하면 되지 않나?
- 리프레시를 저장를 하는데, 굳이 똑같은 DB에다 저장할 필요는 없다. ( redis, nosql )
팀원들과 잘 소통하는 방식 그리고 특별한 그라운드 룰 알려주세요
가능한 한 부하가 안 갈 만큼만 여러 개의 게임 엔진을 하나의 서버에서 돌리도록 합시다
그 이상이 필요하면 서버 더 만들어야 합니다
(데디케이티드 서버 방식)
html을 만들 때 원본 데이터를 같이 script 변수 등으로 보내주고, 클라이언트측에서 하이드레이션을 시도해서 데이터를 각 컴포넌트에 부착할 때에는 해당 변수를 참조하는 방식으로 불필요한 DB참조를 줄일 수 있다
1. 회사가 새 언어를 안가르칠려고 귀찮아서 만들었다
2. 한쪽이 터지더라도 나머지는 안터지도록 하려고
개발을 시작하려 했는데, 이제 처음 보는 canvas 관련 로직들 조사하다 보니 토끼굴을 파져서 남는건 블로그 글 뿐…
기획서 → 사용자 입장의 명세
테크스펙 → 개발자 입장의 명세
백로그 → 일의 세분화
- 추론을 해보기
- 면접때 물어봐서 답변하는 것 = 외우는것
- 돌발상황에 대한걸 가정한다면, 나는 문제접근을 어떻게 하고 있는가
client에서 끊는게 아닐까요?
timeout이 있는지 살펴보면 좋을 것 같아요
- 리팩토링을 해도, 사이드이펙트가 없는 경우
- 아직 서비스가 나가지 않은 경우 (사이드 이펙트가 있어도 무방할 때)
- 이 코드를 방치하면 무조건 안 될 것 같을 때
- 리팩토링을 할 때 필수인건 테스트코드
- 테스트코드 없이 리팩토링을 한 다면, 사이드 이펙트 덩어리
- 테스트코드가 있다면, 그냥 진행해도 무방하다고 생각합니다.
client → server
Server Sent Event
ajax → POST
get으로 데이터를 만드는 것 자체는 좋은 방법은 아닌 것 같습니다.
그럼에도 불구하고 그렇게 해야 한다면(앞서말했듯 SSE가 GET만 지원해서 POST는 안 되더라고요), 안전장치를 마련하는게 좋지않을까?
인증과정? 검증과정?
(일단은 로그인된 사용자만 정상적으로 값을 받아올 수 있도록 방어로직이 구성되어 있긴 합니다)
클라이언트에서 보내는 모든 것은 위험하다
- 퇴사해도 문제 없을 것 같아요
- 최대한 빠르게 퇴사를 하는게 서로에게 좋다
- 채용을 한 사람이 좀 책임질 문제이지, 구직자에게는 흠될게 딱히 없다
- 제 주변에서 본건 32? 33?
- 사람마다 선입견이 있을 수 있다
- 빠르면 좋긴 한데, 그럼에도 불구하고 나이와 상관없이 나의 가치를 봐줄 수 있는 사람이 꼭 있다
- “지속성장 가능한 개발자”를 양성하는 것이 부스트캠프의 목표
- 근데 왜, 지속 성장 가능한 개발자가 되어야 하는거지?
- 기업에서 좋은 역할? 도구?를 하기 위해서?
- 나는 회사 없이 살아갈 수 있는 사람인가?
- 나는 회사에 의존적인 사람인가?
- 내가 더 잘 살기 위해서는, 회사를 위한 무언가가 아니라, 나를 위한 무언가를 많이 도전하는게 좋을 것 같다
특정 도메인에 특화된 경우
- 스페셜 리스트 → 특정 도메인에 특화된 사람 (DBMS). 교수님 같은..
- 제네럴 리스트 → 두루두루 다 잘 하는 사람
- 전문가 = master, 장인,
- 필드에서의 전문가 = 밸런스를 맞추는 사람. 답이 없는 상황에서 최선의 판단을 해서 최선의 결과로 만드는 사람
- 경험도 필요하고
- 기술적인 지식도 많이 필요 하고
- 비지니스도 잘 알아야 하고
- 사람도 잘 이끌줄 알아야 하고 (커뮤니케이션 능력)
- …
- 개발 전문가?
- 적어도 프레임워크 하나를 만들 수 있는 사람
- 만들 수 있는 역량
- 나는 아무도 없는 무인도에서 밥을 차려먹을 수 잇나?
- 사냥
- 손질
- 요리
- …
- 나는 개발자야
- 컴퓨터
- 전기/기계
- 추상화
- 프로그래밍 언어
- 컴파일러
- 브라우저
- 서버
- …
개발자가 되지 않을까요? 그런 세상이 오면 좋을 것 같아요
- 보통 한국에서는 매니저를 많이 하는 편
내가 정말 기술로 뭔가를 하고 싶다면
→ 스타트업에 빠져서, CTO를 한다거나, 팀장을 한다거나
→ 50 넘어가고, 60 넘어가면, 개발을 계속 할 수 있을까?
MBTI
→ T → 논리적으로 설득시키기 → 일하는것 자체가 힘들 수 있음
→ F → 기분만 잘 맞춰주면 합의가 잘 됨
개인차
— 서로서로 잘 맞춰가자 —
— 정말 위험한 상황이 될 수 있는 문제는 미리미리 좀 논의를 해서 해결을 하면 좋다
— 해결이 안 되더라도, 인지를 하는게 좋다 ( 사이드 이펙트가 있다는 사실을 남겨두기 )
다른사람들이 이직을 준비할 때, 혼자 이직을 하지 않은 이유
→ 위기를 기회라고 생각했음
→ 내가 이 회사에서 개선할 수 있는 부분이 있는가?
→ 업무프로세스
→ 조직
→ 서비스
→ ….
→ 개선이 될 수 있나?
→ 불편하게 너무 많아서, 차근차근 개선을 하고 있는데, 아무리 봐도 더이상 나아질 것 같지 않아
→ 이제 나갈 때가 되었구나
사업이 잘 안되고 있는 기업에 채용공고가 많이 올라온다는 것은 위험신호
스스로 커리어 설계
나한테 너무 많은 일이 의존되고 있진 않나?
- 이게 분배가 잘 안 되고 있지 않나? (버스팩터)
- 그런데 나는 보상을 잘 받고 있나?
- 할 수 있으면, 하는게 좋다고 생각합니다.
- Facebook (meta)
- aws
- microsoft
- google
- netflix
- 프론트엔드 개발자 채용 공고
- 필수역량: 컴퓨터 공학(CS)
- 알고리즘, 문제해결 능력, 자료구조, 운영체제, …
- 우대역량: 프론트엔드
- 싱가폴
- 영어를 공부해놨다면
- 코틀린을 직접 만든 사람이, 코틀린 강의를 무료로 해주는 곳
오픈소스라는 이름을 지우고, 회사에 들어가서 어떤 프로젝트를 맡아서 일을 한다고 했을때
오픈소스 (보는 사람만 편함)
- 누구나 이용할 수 있어야된다 → 문서화가 잘 되어 있어야 한다
- 의존을 하고 있는 프로젝트가 매우 많기 때문에 → 테스트 코드도 잘 작성되어야 한다
- 리액트 개발자가 아닌 누구라도 이 프로젝트에 기여할 수 있어야 한다 → 코드는 최대한 깔끔하게 작성하는 것을 목표로
기업의 프로젝트 (짜는 사람만 편함)
- 문서화? 그게뭐야?
- 의존? 그게 뭐야?
- 알아서 적응해
나를 되돌아 봤을 때, 언제 성장을 가장 많이했지?
→ 기업에 들어간지 얼마 되지 않았을 때
→ 프로젝트를 파악하면서
→ 어떤 기술 스택이 어떻게 쓰였고, 왜 쓰였고, 어떤 문제들을 해결할 수 있는지 알게 되었을 때
→ 기업에 입사하기전에는 어떻게해야되지?
→ 오픈소스
→ 리액트는 페이스북에서 만들었다
→ 페이스북의 노하우가 그대로 들어있다
→ 리액트라는 프레임워크 자체를 공부해보면 (뜯어보면) 내가 얻어갈 수 있는게 엄청나게 많지 않을까?
→ 처음에는 오픈소스를 보는게 무척 힘들 수 있는데, 내가 그냥 리액트의 개발자다 라고 생각을하고 계속 보다보면, 점차 익숙해지고, 기여할 수 있는 사람이 될 수 있지 않을까?
브라우저라는 것
→ Text → 파싱 ( DOM, BOM, CSSOM) → 데이터를 기준으로 렌더링(레이아웃, 페인팅, 컴포지트)
캔버스
→ HTML Text를 파싱 → 나만의 DOM, CSSOM → canvas에다 직접 렌더링 해보기
번들러 직접 만들어보기
트랜스파일러 직접 만들어보기
→ babel(트랜스파일러)
→ swc(트랜스파일러)
→ babel vs swc → 뭐가다를까?
→ babel은 js로 만들어짐
→ swc는 rust로 만들어짐
babel의 js 코드를 한땀 한땀 분석해서 rust로 그대로 작성 → 성능최적화, …
—————————————————
야생학습 = 지속성장 가능한 개발자
책 → 잘 안 봄(3년 동안… 2권?)
인강 → 잘 안 봄
무언가를 직접 만듬 → 재밌으니까 → 정리하고 → 공유하고 → 어라..? 성장이 되네
- 기술에 대한 것을 강조하고 싶다면
- 우리는 “어떤” 문제가 있어서, “어떤”도구를 이용하여 해결하고 싶었다.
- 이 문제를 해결하기 전 상황
- 해결 후의 상황 (성능, 품질, .., → 수치화)
- WebGL 관련된 포스트를 많이 쓰는 것
- 기업 관계자가 나를 찾아오도록 하는 것
- 알려지는 것
할 수 있으면, 하고 싶은데, 백엔드 말고 프론트엔드로 하고 싶습니다.