이메일 첨부 파일이나 JWT 토큰, Data URI 같은 곳에서 빠지지 않고 등장하는 글자가 있는데요. 바로 끝에 =가 붙는 영문과 숫자가 뒤섞인 그 문자열, Base64입니다. 이번 포스팅에서는 Base64가 무엇이고 왜 만들어졌는지부터 짚어보겠습니다. 어떤 원리로 동작하는지, 그리고 오늘날 어디에 자주 쓰이는지도 함께 살펴보겠습니다. Base64란? Base64는 임의의 이진 데이터를 64가지 ASCII 문자로만 표현하는 인코딩 방식입니다. 이름 그대로 "기수(base) 64"의 표기 체계인데요. 우리가 평소에 쓰는 10진수가
웹 페이지나 데이터베이스에서 멀쩡하던 한글이 다른 사람에게서는 검색이 안 된다거나, macOS에서 만든 파일을 윈도우에 올렸더니 같은 이름인데도 다른 파일로 인식되는 경험이 있으실 텐데요. 이런 문제 대부분의 뿌리에는 유니코드(Unicode)와 정규화(normalization)라는 개념이 자리잡고 있습니다. 이번 포스팅에서는 UTF-8과 자주 헷갈리는 유니코드의 정체부터 짚어보겠습니다. 한글이 유니코드에서 어떻게 표현되는지, 같은 글자가 왜 두 가지 방식으로 저장될 수 있는지도 함께 살펴보겠습니다. 유니코드는 인코딩이 아닙니다 유니
웹 페이지에서 갑자기 한글이 ���처럼 깨져 보인 경험이 한 번쯤은 있으실 텐데요. 파일을 메모장에서 다른 에디터로 열었더니 모든 글자가 외계어로 변하거나, JSON API에서 받은 한글이 전혀 다른 모양으로 나오는 경우 말입니다. 이런 문제 대부분의 뿌리에는 UTF-8이라는 문자 인코딩이 자리잡고 있습니다. 이번 포스팅에서는 UTF-8이 어떻게 전 세계 모든 문자를 담아내는지부터 짚어보겠습니다. 한글이 어떻게 바이트로 변환되는지, 그리고 글자가 깨질 때 무슨 일이 벌어지는지도 함께 살펴보겠습니다. UTF-8이란? UTF-8은 Un
컴퓨터로 텍스트를 다루다 보면 "ASCII 코드"라는 용어를 종종 마주치게 됩니다. URL 인코딩을 설명할 때나 한글이 깨지는 문제를 디버깅할 때마다 ASCII가 빠지지 않고 등장하는데요. 이번 포스팅에서는 ASCII가 무엇이고 왜 만들어졌는지부터 짚어보겠습니다. 문자표가 어떻게 구성되어 있는지, 오늘날 UTF-8과는 어떤 관계를 가지는지도 함께 살펴보겠습니다. ASCII란? ASCII는 American Standard Code for Information Interchange의 약자로, 영문자와 숫자, 그리고 일부 특수 문자를 0
개발하다 보면 API 키, 데이터베이스 비밀번호, 토큰 같은 민감한 정보를 다룰 일이 많은데요. 이런 값들을 .env 파일이나 설정 파일에 평문으로 저장해두면 실수로 Git에 커밋하거나 다른 사람에게 노출될 위험이 있습니다. macOS에는 이런 민감한 정보를 안전하게 보관할 수 있는 **키체인(Keychain)**이라는 시스템이 내장되어 있는데요. 보통은 키체인 접근(Keychain Access) 앱을 통해 GUI로 사용하지만, 터미널에서 security 명령어를 사용하면 키체인을 훨씬 효율적으로 다룰 수 있습니다. 이번 글에서는
알림 규칙을 공들여 만들어 놨다고 해 볼게요. 그런데 알림이 채팅 채널 하나에 전부 쏟아지고 있습니다. 낮에는 누군가 보고 반응하지만 새벽에는 아무도 안 봐요. 반대로 팀 전원에게 전화가 가도록 해 둔 팀도 있는데 다들 "누가 보겠지" 하고 다시 잠듭니다. 😅 규칙은 제대로 발동했는데 사람에게 닿지 않은 거죠. 알림이 발동한 순간부터 누군가 대응을 시작하는 순간까지, 그 사이의 경로를 설계하는 게 이 글의 주제입니다. 알림을 어디로 보낼지, 누가 받을지, 못 받으면 어떻게 할지, 그리고 알림이 너무 많아지면 무슨 일이 생기는지를
![[ES2015] 기본 매개변수 (Default Parameters)](https://img.daleseo.com/cdn-cgi/image/width=800,height=450,fit=cover,format=auto,onerror=redirect/7q4oTYVT.webp)
ES2015는 자바스크립트의 근간이 되는 함수에도 여러 가지 변화를 가져왔습니다. 이번 포스팅에서는 그 중 기본 매개변수(Default Parameters)에 대해서 알아보도록 하겠습니다. 매개변수를 무시한 함수 호출 다음과 같이 사용자의 아이디의 배열을 매개변수를 받아서 사용자의 상세 정보를 돌려주는 함수가 있다고 가정해봅시다. 아래와 같이 정상적인 배열을 넘기면 함수는 예상하는 것처럼 잘 돌아갑니다. 하지만 다음과 같이 인자 없이도 위 함수를 호출하면 어떻게 될까요? 문법이 엄격한 다른 언어라면 분명히 함수 호출이 불가능했을텐데
이번 포스팅에서는 ES2015에서 let과 함께 자바스크립트에 추가된 const 사용법에 대해서 알아보도록 하겠습니다. let 사용법에 대해서는 아래 포스팅들을 참고바라겠습니다. let으로 변수 선언하기 1 let으로 변수 선언하기 2 매직 넘버 아래 코드에서 findUser 함수는 안자로 받은 id 값이 100보다 작은지 여부에 따라서 로직이 분기되어 있습니다. 그리고 id 값이 100보다 큰 경우, 가짜 사용자 객체를 생성 후, name 속성값의 길이가 50보다 큰지 여부에 따라 다시 한 번 로직이 분기되고 있습니다. 예제와 같
이전 포스팅에서 ES2015의 let 키워드에서 대해서 알아보았습니다. 이번 포스팅에서는 for 문에서 let이 어떻게 사용될 수 있는지 살펴보겠습니다. 예제 코드 다음 코드는 사용자 아이디를 받아 가짜 사용자를 담든 후 콜백 함수를 호출하는 비동기 함수입니다. 마치 DB 연동처럼 setTimeout 함수를 이용하여 1초의 지연을 주었습니다. setTimeout() 함수에 대한 좀 더 자세한 내용은 관련 포스팅을 참고바랍니다. 그리고 아래 코드는 사용자 아이디의 배열을 받아 여러 사용자의 정보를 출력해주는 함수입니다. findUse
본 포스팅에서는 ES2015를 통해 자바스크립트에 추가된 let 키워드에 대해서 알아보도록 하겠습니다. 문제의 코드 먼저 다음 예제 코드를 살펴보시죠. findUser 함수는 사용자 아이디가 0보다 크면 성공 메시지를 출력하고 아니면 실패 메시지를 출력합니다. 그리고 if-else 문을 빠져나온 후, 실패 메시지를 다시 한 번 출력하고 있습니다. 자, 그럼 다음과 같이 1을 인자로 이 함수를 호출하면 마지막에 출력하는 실패 메시지는 뭐라고 출력이 될까요? 다음과 같이 오류가 발생하지 않고 undefined가 출력이 됩니다! 첫 개발
많은 자바스크립트 강좌에서 가급적 var 대신에 let이나 const 키워드를 사용하여 변수를 선언하라고 가이드하고 있는데요. 본 포스팅에서는 var의 어떤 문제점 때문에 그런건지 알아보도록 하겠습니다. 아리송한 코드 먼저 다음 코드를 살펴보도록 하겠습니다. 무엇이 출력이 될지 예상이 되시나요? 첫번째 console.log(n)에서 오류가 발생할 것 같기도 하고, 1과 2가 출력될 것 같기도 한데요. 의외로 정답은 다음과 같습니다. 왜 이런 예상치못한 결과가 얻어지는 걸까요? 원인은 var 키워드를 사용할 경우, 변수 Hoistin
새벽 3시에 결제 API가 죽었는데 아침 9시에 출근해서 대시보드를 열어 보고서야 알았던 경험, 혹시 있으신가요? 😅 대시보드는 있었습니다. 그래프도 정확했고요. 오류율이 치솟은 시각까지 그대로 그려져 있었죠. 문제는 그 여섯 시간 동안 아무도 그 화면을 보고 있지 않았다는 겁니다. 이런 일을 겪고 나면 "대시보드를 더 잘 만들어야겠다"는 결론으로 가기 쉬운데요. 사실 대시보드가 아무리 좋아져도 문제는 해결되지 않습니다. 대시보드와 알림은 하는 일이 다르기 때문입니다. 이 글에서는 둘의 역할이 어떻게 나뉘는지, 알림 규칙이 무엇으
멋진 테스트 코드를 작성하도록 돕는 AssertJ 라이브러리에 대해서 알아봅시다. AssertJ의 장점 메소드 체이닝을 지원하기 때문에 좀 더 깔끔하고 읽기 쉬운 테스트 코드를 작성할 수 있습니다. 개발자가 테스트를 하면서 필요하다고 상상할 수 있는 거의 모든 메소드를 제공합니다. 라이브러리 의존성 설정 Java8 이상 기반 프로젝트는 3.x 버전을, Java7 이하 기반 프로젝트는 2.x 버전을 사용하셔야 합니다. Gradle Java8 Java7 Maven AssertJ 메소드 임포트 다음과 같이 정적 임포트를 하면 Assert
Optional을 좀 더 Java8 API 설계자의 의도에 맞게 쓰는 방법에 대해서 알아봅시다. 이전 포스팅를 통해서 Optional에 대해서 소개드렸습니다. 또한 Optional을 Optional답지 않게 사용할 경우, 어떤 부작용이 발생하는지도 살펴보았는데요. 이 번 포스팅에서는 어떻게 코드를 작성해야 Optional을 Optional답게 쓸 수 있는지 알아보도록 하겠습니다. Stream처럼 사용하기 Optional을 제대로 사용하려면, Optional을 최대 1개의 원소를 가지고 있는 특별한 Stream이라고 생각하시면 좋습니
Java8의 Optional API를 통해 어떻게 null 처리를 할 수 있는지 알아봅시다. 이전 포스팅를 통해 Java8 이 전에는 얼마나 null 처리가 고통스러웠는지 살펴보았습니다. 그리고 문제의 본질이 null 참조를 통해 "값의 부재"를 표현하는 자바 언어의 초기 설계에 기인한다라는 것도 말미에 언급하였습니다. null 관련 문제 돌아보기 이 전 포스팅의 예제 코드를 통해 살펴본 null과 관련된 문제들을 크게 2가지로 요약됩니다. 런타임에 NPE(NullPointerException)라는 예외를 발생시킬 수 있습니다. N
Java8이 나오기 이 전에는 얼마나 힘들게 null 처리를 했었는지 살펴봅시다. null 창시자가 스스로 인정한 null 탄생의 실수 우선 null이라는 개념은 언제 누구에 의해 만들어졌을까요? null 참조는 1965년에 Tony Hoare라는 영국의 컴퓨터 과학자에 의해서 처음으로 고안되었습니다. 당시 그는 "존재하지 않는 값"을 표현할 수 있는 가장 편리한 방법이 null 참조라고 생각했다고 합니다. 하지만 나중에 그는 그 당시 자신의 생각이 "10억불 짜리 큰 실수"였고, null 참조를 만든 것을 후회한다고 토로하였습니다
본 포스팅는 오라클 자바 튜토리얼의 What Is a Socket?를 번역하였습니다. 소켓 통신 일반적으로 서버는 특정 포트가 바인딩된 소켓를 가지고 특정 컴퓨터 위에서 돌아갑니다. 해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝하면서 그냥 기다릴 뿐이죠. 클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 알고 있습니다. 따라서 클라이언트는 이 호스트 네임과 포트를 통해서 서버와 연결을 시도하게 됩니다. 또한 클라이언트는 서버 상대로 자신을 식별시켜주기 위해서 연결동안 사용될 로컬 포트에
CI 로그에서 exit code 137을 보고 "이게 뭐지?" 싶었던 적이 있는데요. Docker 컨테이너가 OOM으로 죽었을 때, Ctrl+C로 스크립트를 끊었을 때, 명령어 오타가 났을 때, 매번 다른 숫자가 떠도 잘 보지 않으면 의미를 잊기 쉽습니다. 사실 이 숫자들에는 나름의 규칙이 있고, 한 번만 정리해두면 다음에 로그를 볼 때 훨씬 빠르게 원인을 짚을 수 있습니다. 이번 글에서는 종료 코드가 만들어지는 원리부터 자주 마주치는 코드의 의미, 셸과 Node.js, Python에서 다루는 방법까지 정리해보겠습니다. 종료 코드란
본 포스팅는 Dead Code Rising의 Java 8: No more loops를 번역하였습니다. 이전 포스팅통해 자바의 판도를 바꿀 자바8의 새로운 함수형 기능들에 대해서 살펴보았습니다. 자바 개발자들에게는 새로운 세상이 열렸으며, 이제 우리가 그 새로운 세상에 적응해야 할 때 입니다. 이번 포스팅에서는 전통적인 반복문에 대한 몇가지 대안들에 대해서 알아보겠습니다. 자바8의 새로운 함수형 기능의 훌륭한 점은 어떻게 실행하는지 대신에 무엇이 실행되야 할지를 명시할 수 있다는 것입니다. 이런 측면에서 반복문이 탈락되게 됩니다. 물
본 포스팅는 오라클 웹사이트에 Ted Neward가 기고한 Java 8: Lambdas, Part 1를 번역하였습니다. 메소드 참조 (Method Reference) 지금까지 다룬 모든 람다는 사용 시점에 람다를 정의하는 익명 리터럴이였습니다. 이는 1회성 행위를 위해서는 훌륭하지만, 이 행위가 여러 곳에서 사용되어야 하는 상황에서는 별로입니다. 예를 들어 다음 Person 클래스를 생각해봅시다. (지금은 부적절한 캡슐화에 대해서는 무시하시죠.) Person 객체를 SortedSet에 저정하거나 어떤 형태로든 리스트 내에서 정렬될