셩잇님의 잡동사니

2020년의 마지막 주간 인프런! #20 에서는 직접 온갖 게임 강의를 들어본 인프런 팀원의 학습기(!)를 소개합니다. 자타공인 게임 덕후였던 고트가 그 주인공인데요. 게임 개발을 배우기 위해 지난 몇 년간 고트가 직접 듣고 공부해본 게임 강의들을 소개하고, 어떤 기준으로 강의를 공부하고 평가했는지를 살짝 공개해 봅니다. 희노애락이 듬뿍 담긴, 솔직한 게임개발 강의 리뷰! 게임 개발에 도전하는 분들은 물론, 어떻게 강의를 고르면 좋을지 막연한 분들에게도 하나의 길잡이가 될 수 있기를 바라요. 🎮 *이 리뷰는 2020년 4월에 쓰여, #20으로 새로 편집해 공개하는 리뷰입니다. 더 읽어보기 & 출처 : https://www.inflearn.com/pages/weekly-inflearn-20?utm_sour..

#취업 #채용 #공채 #자소서 #이력서 #포폴 선선한 가을, 어느덧 하반기 공채 시즌이 돌아왔습니다! 코로나19로 인해 채용 시장은 지난 해보다 위축됐는데도, 막 첫걸음을 떼려는 사회초년생 분들의 열기는 변함없이 후끈후끈하죠. 🔥 저번 에서는 비전공자 출신으로 서버 개발자가 된 지식공유자 김병욱 님을 인터뷰했어요. 신입 개발자가 포트폴리오를 통해 어필할 수 있는 방법에 대한 병욱님의 생각을 들어보았는데요. #15에서는 지난 호에 이어 취업을 준비하고 계신 분들에게 도움이 될 만한 소소한 팁을 소개하려 합니다. 어려운 시기지만, 각자 원하는 성과를 거둘 수 있도록 인프런이 응원할게요. (화이팅!) 더 읽어보기 & 출처 : https://www.inflearn.com/pages/weekly-inflearn-..

‘꼭 만들어야 할까?’ 🤔 시간이 많이 들 것 같아 망설여지는 포트폴리오 제작. 쉽고 멋지게 만든 포트폴리오로 높은 서류 합격률을 자랑한 1년차 개발자 병욱님께 물어봤습니다. 이번 인터뷰는 원격 화상 인터뷰로 진행해 보았는데요. 직접 만나뵙진 못했지만 화면으로도 충분히 병욱님의 마음이 전해졌어요. 신입 개발자 포트폴리오, 어떻게 만들면 좋을까요? 더 읽어보기 & 출처 : https://www.inflearn.com/pages/weekly-inflearn-14?utm_source=pinpoint&utm_medium=email&utm_campaign=weekly-inflearn&utm_content=14 신입 개발자 포폴로 취업하기 - 인프런 | 스토리 [주간 인프런 #14]인프런이 만난 사람 - 김병욱 ‘..

5~6년 차 즈음부터 개발자 채용에 조금씩 관여하기 시작했고 현 회사에서는 면접관으로 활동한지 5년이 넘은 것 같다. 면접은 1차 면접에 해당하는 기술 면접이었고 팀의 채용 프로세스를 개선하거나 사전과제, 라이브 코딩 문제 출제에 주도적으로 참여했다. 그간 다양한 개발자들을 만났고 운 좋게도 좋은 개발자들을 많이 채용할 수 있었다. 채용 과정에서 좋은 개발자도 만났지만 그렇지 못했던 개발자도 많았고, 아쉬웠던 개발자도 있었다. 아쉬웠던 개발자들은 노력을 하고 있지만 “어느 정도”로 “어떤 방향”으로 해야 하는지 모르는 경우였고 채용에 대한 준비가 부족했던 경우도 많다. 이런 분들에겐 면접이 끝나기 전에 선배 개발자로서 몇 가지 조언을 해주고 싶었지만 채용 과정에서는 조심스러운 일이기도 하고 최소한의 범위..

학창 시절에는 공부 잘하고 싶죠. 공부 잘하는 친구가 있으면 어떻게 공부하는지 관찰하기도 하고 묻기도 합니다. 회사에서는 일 잘하는 사람들이 늘 부러움의 대상이죠. 나와 경력이나 지식도 크게 차이 없는 거 같은데 유독 일 잘하는 사람이 있습니다. 이번 글에서는 그들의 어떤 점이 달라서 일잘 소리를 듣는지 알아보도록 하겠습니다. 1. 형식에 매몰되지 않는다 일을 할 때 정해진 형식이란 건 없습니다. 형식에 매몰되다 보면 형식 때문에 일이 더디게 진행됩니다. 예를 들어, 아이디어를 보고할 때 굳이 깔끔한 레이아웃의 피피티 문서 작업을 할 필요 없습니다. 문서 작업은 일의 마지막 단계에 정리하면 됩니다. 아이디어를 보고하러 갈 때는 형식을 지키려고 하기보다, 아이디어를 뽑고 전달하는 데 초점을 맞춰야 하는 것..

좋은 동료가 되기 위한 10가지 방법 제가 수구를 처음 배울 때에, 코치가 해줬던 말이 잊혀지지 않습니다. 그는 “뛰어난 선수는 주변 선수들을 뛰어난 선수처럼 보이게 한다.” 라고 했습니다. 뛰어난 선수는 잘못된 던지기를 예상하고 미리 움직여 어떤 패스라도 잡을 수 있습니다. 뛰어난 선수가 공을 다시 패스할 때는 다른 사람이 쉽게 잡을 수 있도록 공을 던집니다. 오늘날의 소프트웨어 개발은 팀 스포츠와 같습니다. 수구에서와 같이 뛰어난 소프트웨어 시스템은 혼자서 만들 수 없습니다. 그래서 처음 10배 뛰어난 엔지니어에 대한 컨셉을 들었을 때는 혼란스러웠습니다. 어떻게 한 명의 뛰어난 사람이 팀웍을 이길 수 있을까? 제 경험상 성공을 위해 각 개인의 뛰어남은 필수 요소지만, 충분 요소는 아니었습니다. 개개인..

1. https://github.com/jojoldu/junior-recruit-scheduler GitHub - jojoldu/junior-recruit-scheduler: 주니어 개발자 채용 정보 주니어 개발자 채용 정보. Contribute to jojoldu/junior-recruit-scheduler development by creating an account on GitHub. github.com 향로님의 깃허브 리포지토리로써 주니어 개발자를 위한 취업 정보를 업데이트하여 자료를 제공해주는 리포지토리입니다. 프론트/백엔드 자료가 위주입니다. 2. https://github.com/JaeYeopHan/Interview_Question_for_Beginner GitHub - JaeYeopHan/..

if와 else int hp = 100; bool isDead = (hp 0) { Console.WriteLive("Hello World"); count--; } for (int i = 0; i < 5; i++) { } while 문에서 사용했던 count를 i로 변경해서 0의 값을 주면 그것이 초기식이 되고, 5번 반복을 지정해야 하는 count--는 i가 0에서 5까지 반복하라는 i < 5로 대체될 수 있다. 마지막으로 값을 감소시키는 것이 아닌 증가시키는 연산자인 후위 연산자를 통해 for문을 while문 처럼 사용할 수 있다. for 문을 처음 사용할 때에는 많이 헷갈릴 수 있으므로, 자주 사용해서 익히는 것이 매우 중요하다. break, continue for 문을 사용하다보면 우리는 특정 상황..

캐스팅(=형변환) [바구니 크기가 다른 경우] int a = 1000; long l = a; // 가능 8 byte 바구니인 long 자료형에서 4 byte 바구니인 int 자료형을 넣는 것은 데이터가 손실 될 일이 없으므로 데이터를 옮기는 것이 가능하다. 즉. 큰 바구니에서 작은 바구니로 물건을 넣는 것은 문제가 없다. int a = 1000; short s1 = a // ❌ 에러 short s2 = (short)a; // 넣을래! 4 byte 바구니인 int 자료형 a에서 2 byte 바구니인 s1에 데이터를 담으려고 하니 에러가 발생한다. 왜냐하면 작은 바구니에 큰 물건을 넣으려고 하기 때문이다. 그래서 아래와 같이 강제적으로 형변환을 해주면 문제가 발생하지 않는다. 단, 데이터를 옮겨 담을 때 데..

데이터 형식 [주석] 주석 : //와 /* ~ */ 형식으로 사용한다. 프로그램 자체에는 어떠한 영향도 주지 않고 메모를 남기는 것 그렇다면 우리는 주석을 왜? 사용해야 할까? > 이는 메모를 남기거나, 다른 프로그래머와 소통, 혹은 먼 미래에 내가 다시금 볼 때 기억하기 위해 등 주석을 사용한다. [데이터의 대표적인 형태] int, float, string, bool이 대표적이다. 각각의 데이터들은 정수형(int = -1, 0, 1, 2, 3, 4 등), 실수형(float = 3.14), 문자형(string = "Rookiss"), 불리언(bool = true/false(참/거짓)) 으로 나타낸다. 예를 들어 체력, 마력, 스탯정보, 퀘스트 정보, 경험치, 자동 사냥 여부 등 여러 게임 요소들의 데이터..

이래저래 취업 준비하고 계신 분들과 이야기 나누고, 실제로 회사에서도 채용에 어느 정도는 관여를 (안할 수가 없어서) 하다보니 드는 생각이 있어서 글을 몇개 가져와봅니다. HP 에서 조사한 결과에 보면 남성은 채용 공고의 자격 요건을 60% 정도만 맞으면 지원해보는데, 여성은 100% 다 충족해야 지원하는 경향이 있다고 하는데요. 저 수치가 맞냐 틀리냐를 떠나, 어느 정도 저런 경향을 저도 직간접적으로 체험하긴 했던 거 같아요. https://www.thewomens.network/blog/the-resume-gap-is-real 근데 또 한편으로는 "이걸 남녀 자신감의 차이라고 단순히 후려칠 수 있지만, 다른 측면이 더 크다"는 주장도 봤는데요. 위 HP 연구 결과에 의문을 갖고 1000명을 대상으로 ..

(번역) 주니어가 되는 것을 그만두세요. 아마 개발자로 일을 한지 2~3년 차 시절 때였습니다. DEVIEW에 참관하러 나갔다가 저의 멘토님이시자 스승님이 발표하신다기에 응원을 하러 갔었죠. 아무렇지 않게 동기들과 맨 앞자리에 자리를 잡고 기다리다 인사할 기회가 생겼는데 그분은 저에게 이런 말씀을 하셨습니다. "이제 발표할 때 되지 않았니? 준비는 잘 하고 있지?" 이제 막 회사에 적응해서 코딩을 하는데 겨우 재미가 들던 시절 발표라니... 너무도 충격적인 기억이라 아직도 생생한데요. 지나고 보면 경험이나 연차가 많아야지만 그런 무대에 올라 발표를 해야 하는 룰은 없으니 스스로 제 자신의 울타리를 친 건 아닌가 생각을 해본 기억이 있습니다. 주니어 개발자의 정의는 무엇일까요? 그렇다면 시니어 개발자는요?..

코드 리뷰는 조직의 상황에 따라 실행하는 목적도 방식도 목표도 다르다. 그렇기에 정답이 없다. 그래서 내가 코드리뷰에 관한 글을 시작하기 앞서 내가 처한 상황을 설명하지 않는다면, 읽는 사람도 글을 이해하기 쉽지 않을 것이다. 나와 함께 일하는 조직은 아래와 같았다. * 열 명 이하로 구성된 개발 조직이었다. * 대부분의 개발자가 신입 사원이거나 경력이 2년이 채 되지 않는 주니어 개발자였다. * 간혹 10년~20년 경력의 시니어 개발자가 있었으나 코드 리뷰 경험이 없었다. * 실력 있는 개발자를 채용하기 어려웠다. * Git을 SVN(Subversion)처럼 쓰고 있었다. * 이슈 기반의 개발을 하고 있지 않았다. 코드 리뷰어로서 내 목표는 세 가지였다. * 최소한의 코드 품질 유지 * 개발 코칭을 통..

비록 멍청하게 1번으로 출제된 왼쪽으로 시프트해서 미는 문제에 (i+1)%5 를 n[ ] 대괄호 안에 답을 작성하지 않았고, switch 문제를 250을 30으로 나눈걸 80이라고 착각 안했으면 더욱 확실하게 합격했다고 생각했을 수 있었다. 그럼에도 불구하고 어려운 문제에서 기타 자잘한 부분 점수를 맞아서 턱걸이로 합격할 것 같다. 두근두근거려서 9월 1일까지 어떻게 기다려야 할 지 모르겠다. 🤣

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 11-89 ~ 12-27 ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * 개발환경 인프라 구성 방식 (온클하 > 온프레미스, 클라우드, 하이브리드 방식) * 스토리지 시스팀 유형 (다나쓰 > DAS, NAS, SAN) * 제품 SW 패키징, 매뉴얼(설치/사용자), 배포본의 개념 및 차이 * 릴리즈 노트의 개념 * 디지털 저작권 관리(DRM)의 개념 및 구성요소 * 암호화 및 보안 기능 중심 패키징 도구 기술 활용 (암키식저 파정크인 > 암호화, 키, 식별, 저작권, 암호화 파일 생성, 정책관리, 크랙 방지, 인증) * 백업의 유형 (전차증 > 전체, 차등, 증분 백업) ​ 3. 공부하면서 이해하지 못한 용어 * 없음

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 11-68 ~ 11-88 ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * 패킷 교환 방식, 서킷 교환 방식의 개념 * 패킷 교환 방식의 종류 및 방식 (X.25, 프레임릴레이, ATM / 데비가연 > 데이터그램 - 비연결성, 가상회선 방식 - 연결성) ​* 애드 혹 네트워크 개념 및 특징 * 근거리 통신망(LAN)의 네트워크 설치구조 (버트링성 > 버스, 트리, 링, 성형 구조) * 다중화기 개념 및 종류 (주시코 > 주파수, 시간, 코드 분할 다중화) * 기타 신기술 용어들 등 ​ 3. 공부하면서 이해하지 못한 용어 * 없음.

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 11-41 ~ 11-68 ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * OSI 7 계층 개념 (아파서 티내다 피봤다 = APS TNDP > 응용, 표현, 세션, 전송, 네트워크, 데이터 링크, 물리) * OSI 7 계층별 전송단위 (데세패프비 = 데이터(5~7), 세그먼트(4), 패킷(3), 프레임(2), 비트(1)) * 근거리(LAN), 무선랜 통신망(WLAN), 원거리 통신망(WAN)의 개념 * 원거리 통신망의 연결 기술 (전회패교 > 전용 회선, 회선, 패킷 교환 방식) * 전송 매체 접속 제어 (CSMA/CD, A > D(=Detection), A(=Avoidance)) * 각 계층별 장비 * 프로토콜의 개념 및 구성 요소 (구의타..

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 11-2 ~ 11-40 ​ ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * 윈도즈 운영체제의 특징 (지선자 오 > GUI 사용, 선점형 멀티태스킹 방식 제공, 자동 감지 기능 제공, OLE 사용) * 유닉스/리눅스 운영체제 개념 및 특징 (대다 사이계 > 대화식 운영체제, 다중 작업&사용자 기능, 이식성, 계층적 트리 구조 파일 시스템 제공) * 유닉스/리눅스 운영체제 파일 접근 권한 관리 * 메모리 관리 기법 (반배할교 > 반입, 배치, 할당, 교체 기법) * 관리 기법 중 배치 기법의 유형 (초적악 > 최초, 최적, 최악) * 관리 기법 중 할당 기법의 유형 (연단다 분페세 > 연속 할당 기법 단일 = 다중 분할 할당 기법, 분산 할당 ..

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 10-41 ~ 10-72 ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * 통합 테스트 수행 방법 간 비교 (빅뱅, 상향(테스트 드라이버), 하향(테스트 스텁), 샌드위치) * 테스트 실행 도구 (데이터, 키워드 주도 접근 방식) * 테스트 하네스 개념 및 구성요소 (드스슈 케시스목 > 테스트 드라이버, 스텁, 슈트, 케이스, 시나리오, 스크립트, 목 오브젝트) * 결함 개념 및 관련 용어 (오결버고 > 오류/에러, 결점, 버그, 고장) * 결함 관리 프로세스 (계기검수 재추최 > 결함 관리 계획, 기록, 검토, 수정, 재확인, 상태 추척 및 모니터링 활동, 최종 결함 분석 및 보고서 작성) * 결함 생명 주기 (등검할수 확종재보 > 결함 등..

1. 오늘 공부한거 인증용 간단한 사진 * 실기 책: 10-2 ~ 10-40 ​ 2. 공부하면서 개인적으로 중요하다고 생각하는 용어 * SW 테스트의 원리 (결완초집 살정오) * SW 테스트의 유형 (실행 여부, 상세 기법, 시각, 목적, 종류) * 화이트박스 테스트 유형 및 각 개념, 상세 동작 (구결조 조변다 기제데루) * 블랙박스 테스트 유형 및 각 개념, 상세 동작 (동경결상 유분페원비오) * 검증 및 확인 (검개확결 > 검증 - SW 개발과정, 확인 - SW 결과) * 테스트 목적에 따른 분류 (회안성 구회병 부스스내 > 회복, 안전, 성능, 구조, 회귀, 병행, 부하, 스트레스(=강도), 스파이크, 내구성) ​* 테스트 오라클 개념 및 종류 (참샘휴일 > 참, 샘플링, 휴리스틱, 일관성 검사)..