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