개발자가 되고 싶은 준개발자

구조 사용자가 UI나 kubectl(커맨드라인 인터페이스)을 통해 명령을 전달하면 마스터가 노드들의 동작을 조정 용어 쿠버네티스 API 다양한 언어(파이썬, Go...)로 API 라이브러리를 제공 kubectl이 마스터 노드 상의 kube-apiserver에게 YAML 또는 JSON 형식으로 목표 상태를 전송하면 이를 토대로 오브젝트 생성, 변경, 제거를 진행 오브젝트 쿠버네티스 클러스터 내부의 엔티티 메타데이터에 기술된 이름에 의해 식별됨 같은 종류의 오브젝트의 이름은 하나의 네임스페이스에서 유일해야 함 네임스페이스 쿠버네티스 클러스터를 논리적으로 분할하여 사용하기 위해 존재하는 기능 kubectl의 유효 범위를 지정한 네임스페이스로 제한 가능 컨테이너 컨테이너는 파드 내에서만 실행 가능 실행 시에만 ..

문제 스트리밍 사이트에서 장르 별로 가장 많이 재생된 노래를 두 개씩 모아 베스트 앨범을 출시하려 합니다. 노래는 고유 번호로 구분하며, 노래를 수록하는 기준은 다음과 같습니다. 속한 노래가 많이 재생된 장르를 먼저 수록합니다. 장르 내에서 많이 재생된 노래를 먼저 수록합니다. 장르 내에서 재생 횟수가 같은 노래 중에서는 고유 번호가 낮은 노래를 먼저 수록합니다. 노래의 장르를 나타내는 문자열 배열 genres와 노래별 재생 횟수를 나타내는 정수 배열 plays가 주어질 때, 베스트 앨범에 들어갈 노래의 고유 번호를 순서대로 return 하도록 solution 함수를 완성하세요. programmers.co.kr/learn/courses/30/lessons/42579?language=python3 코딩테스..

컨테이너의 등장 배경 규모가 있는 프로젝트를 개발할 때는 혼자서 개발하기보다는 팀을 이루어 일하고, 오픈소스 프로젝트를 많이 활용하여 개발의 효율성을 높인다. 그러나 오픈 소스 프로젝트는 빈번하게 버전이 업그레이드되고, 사용하는 오픈 소스가 많아질수록 오픈소스의 버전을 트랙킹하며 모든 팀원들이 동일한 환경에서 개발하기가 어려워진다. 이러한 추세에 따라 컨테이너가 등장하게 되었다. 컨테이너는 1) 오픈 소스를 사용한 개발 생산성 향상과 2) 어플리케이션 안정성을 제공한다. 컨테이너를 사용하는 이유? 인프라의 사용률 향상 쿠버네티스에서 사용되는 컨테이너 기술은 애플리케이션이 정해진 서버에 돌아야 한다는 제약이 없다. 따라서 가동률이 적은 서버의 애플리케이션을 한곳에 모아 가동률을 높일 수 있다. 빠른 기동 ..

HTTP(Hyper Test Transfer Protocol) 요청(Request)과 응답(Response)으로 구성됨 클라이언크가 요청하면 서버가 응답 하는 구조 비연결식: 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료함 (FTP, Telnet-연결식) HTTP의 발전 HTTP 0.9 웹사이트가 기본적이어서 HTTP 0.9가 느렸음에도 불구하고 문제가 없었음 GET, POST, HEAD와 같은 기본 기능을 제공 HTTP 1.0 PUT, DELETE, LINK, UNLINK 기능을 지원 HTTP 1.1 HTTP 1.0이 발표되고 나서 1년만에 또 프로토콜이 나옴 당시에 Internet landscape이 급변하고, 웹사이트들이 무거워지고 동적(dynamic we..

TCP(Transmission Control Protocol) reliable: 모든 세그먼트가 전송되고, 에러가 일어나지 않음을 프로토콜이 보장 connection-oriented: 데이터 전송 전에 connection이 만들어졌는지 확인(3단계), 커넥션을 닫기 전에 전송 후에 데이터가 잘 보내졌는지 확인(4단계) UDP에 비해 더 많이 사용되는 프로토콜 Web, telnet, FTP, email 등에 사용됨 Header UDP(User Datagram Protocol) unreliable: 데이터가 도착하는지 확인 안함 connectionless: 커넥션을 만들지 않음. (물론 커넥션 전/후의 handshake도 안 함). 데이터가 출발하면, 데이터가 잘 도착하는지 여부는 확인 할 수 없음. 하지만..

Lyft의 아키텍쳐 변천사 1. Monolithic - 리프트도 처음에는 monolithic하게 출발했다. 그런데 모노리틱한 구조에도 불구하고 어디서 문제가 발생하는지 원인을 트래킹하는 것이 어려웠다. 2. Micro Service - 점점 사용자가 많아지면서 microservice architecture로 전환하게 되었다. - haproxy, load balancer, service discovery, 2 DB, 20~30개의 마이크로 서비스를 도입 - 이전 아키텍쳐보다 더 복잡해면서, 어디서 문제가 발생하는지 트래킹하는게 더 어려워졌다...! - 마이크로 서비스로 전환하며 겪은 문제들... 사용하는 언어, 프레임워크, 프로토콜(HTTP/1, HTTP/2, gRPC, databases, caching...

의도를 분명히 밝히기 int d; // 경과 시간(단위: 날짜) 위의 예시처럼 주석이 따로 필요하다면 변수명에 의도를 충분히 담지 못했다는 뜻이다. 아래처럼 변수명 자체로 그 용도를 알 수 있도록 작성해야 한다. int elapsedTimeInDays; 의도를 분명히 밝힐 수 있다면 이름이 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 그릇된 정보를 피하기 다른 프로그래머가 읽었을 때 오해할 수 있는 내용을 코드에 남기면 안 된다. 예로 accountList라는 이름은 계좌리스트가 List로 구현되었다는 오해를 낳을 수 있으므로 accountGroup처럼 명명하는 것이 좋다. 의미 있게 구분하라 다른 사람이 두 변수명을 읽었을때, 다른 정보 없이 두 변수명이 담는 정보를 알아차릴 수 ..

한줄 평: 작가가 꼰대인 줄 알았는데 생각보다 멋있는 사람이었다. 합정에 놀러갔다가 중고서점이 보여서 들렸다. 내가 좋아하는 '출간일 1년 신간' 코너에서 재미있어 보이는 책을 한 권 집으로 데려왔다. 스튜디어 룰루랄라에서 와썹맨과 워크맨을 총괄했던 CP가 쓴 책이다. 집으로 돌아오는 길에 지하철에서 조금 읽어보았는데 얼핏 보기에는 '나 이만큼 잘 났고 꽤 성공했어. 내가 인생의 레슨을 알려줄게.'라 하는 자기계발서의 느낌이 살짝 났다. '뭐야, 이 사람 꼰대 아니야? 아 나 이런 거 안 좋아하는데..' 생각했다. 그런데 읽다 보니 첫 인상과는 달리 멋있는 사람이었다. 후배들에게 공을 돌리기도 하고, 90년대생인 나조차도 고민해 본적이 없는 90년대생들에 대해 고민해 보고, 새로운 것에 도전하는 것이 멋..

문제 주어진 두 개의 트리가 같은 트리인지 확인해라. 풀이 이 문제는 각 하위 트리마다 모든 노드들이 같은지 확인해 주면 되므로 깊이우선탐색(DFS)으로 간단하게 풀 수 있다. 코드 # Definition for a binary tree node. # class TreeNode(object): # def __init__(self, val=0, left=None, right=None): # self.val = val # self.left = left # self.right = right class Solution(object): def isSameTree(self, p, q): """ :type p: TreeNode :type q: TreeNode :rtype: bool """ if not p and no..

문제 레벨 별로 다른 순서(왼쪽->오른쪽, 오른쪽->왼쪽)로 이진 트리(Binary Tree)를 순회하라. 풀이 쉬울 줄 알았는데 생각보다 통과하기가 어려웠다. 기본적인 알고리즘은 이전 포스트인 이진 트리를 BFS(너비 우선 탐색) 방식으로 레벨별로 순회하는 알고리즘과 비슷하다. (june-coder.tistory.com/16?category=913762) [LeetCode] 102. Binary Tree Level Order Traversal 풀이 및 코드 문제 트리를 level 순으로 순회하여 각 레벨 별 노드의 값을 리턴한다. 풀이 이 문제는 트리를 level 순으로 순회하는 문제이기 때문에 BFS(너비 우선 탐색)가 적합하다. 트리의 루트부터 leaf까지 순� june-coder.tistory.c..