준영의 지식 블로그 준영의 지식 블로그

들어가며위키백과에 따르면, 전세계에는 약 7,139 개의 언어가 있다고 합니다.다양한 언어를 사용하는 유저들을 타겟으로 하는 서비스라면, 국제화는 빼놓을 수 없는 요소입니다.그리고 그런 서비스가 성장할수록, 서비스 내에서 제공해야 하는 다국어 텍스트도 많아질 수밖에 없는데요.점점 많아지는 다국어 텍스트가 사용자 경험과 개발자 경험에 어떤 영향을 미칠 수 있는지를 알아보고,다국어 텍스트를 효율적으로 관리할 수 있는 방법을 소개합니다.TL:DR자주 추가, 수정될 여지가 있는 다국어 텍스트는 소스 코드와 별개의 장소에서 관리하자. (for 개발자 경험)그러나 웹앱이 실행될 때에는 실행 환경과 가까운 곳에 위치해야 한다. (for 사용자 경험)따라서 웹앱의 빌드 타임에 다국어 텍스트를 불러와 소스 코드에 위치하..

들어가며현재 개발중인 서비스에서, 이미지와 관련된 프론트 개발을 여럿 진행했습니다.그중 개발 과정에서 고생도 많이 하고, 배운 점도 많았던 기능이 바로 이미지 크롭 기능이었는데요.이번 포스트에서는 이미지 크롭 기능을 서비스에 도입하면서 배운 점들과 고민했던 것들, 고려해야 했던 것들, 마지막으로 개선할 점들을 적어보고자 합니다.TL:DR라이브러리는 요구사항을 충족하면서 가능한 용량이 작은 것을 선택하자.이전 페이지와 독립적이라면 페이지, 아니라면 모달로 구현하자. 이미지 크롭의 경우에는 모달이 적절하다.이미지와 캔버스는 픽셀 단위의 래스터 이미지로, width 나 height 값으로 소수점을 갖지 않음에 주의하자.이미지 크롭의 역할은 로컬 이미지 선택과 이미지 적용의 중간에 있다. 사이드 이펙트 뿐만 아..

들어가며글쓰기 모임 글또를 시작하면서 글을 자주 쓰게 되었다. 모임에서 요구하는 글에 정해진 형식은 없지만, 기술적으로 좋은 글을 쓰고 싶다는 개인적인 욕망이 있었다. 그런데 유데미에서 글또 회원들을 대상으로 무료로 강의를 제공해주셔서, 테크니컬 라이팅 관련 강의를 보게 되었다. 이 글은 해당 강의를 토대로, 나름대로 이해한 바를 덧대어 작성한 글이다. 테크니컬 라이팅의 정의와 특징테크니컬 라이팅이란 우리말로 직역하면 기술적 글쓰기로, 독자에게 기술적인 정보를 전달하는 것이 목적인 글쓰기를 말한다.따라서 독자에 따라 다양한 해석이 가능한 문학과는 다르게, 독자가 글을 자의적으로 해석할 여지를 남기지 않아야 한다.이외의 테크니컬 라이팅과 문학 글쓰기의 차이점은 아래와 같다.분류문학 글쓰기테크니컬 라이팅내용..

언제부터인지는 기억나지 않지만, 저에게 리눅스는 개발자라면 꼭 한 번은 배워두어야 하는 이미지로 자리 잡혀 있었습니다. 또 비교적 최근에는 AWS 의 클라우드 서비스의 운영체제가 리눅스로 되어 있다는 것을 알게 되고, 컴퓨터에 있는 여러 파일들을 스크립트를 통해 관리할 필요성을 느끼게 되는등 언젠가는 리눅스를 배워야겠다는 생각을 갖고 있었습니다. 이 책은 리눅스를 처음 접하거나, 리눅스를 다루고 있지만 개념을 잘 모르는 사람을 대상으로 하는 책입니다. 책은 크게 두 파트로 나뉘어 있는데, 파트1 은 리눅스라는 운영체제를 이해하는 데에 중점을 두고 있고, 파트2 는 리눅스를 활용하기 위한 기술적인 측면(Bash, 프로그래밍, …)에 중점을 두고 있습니다. 파트 1에서 특히 좋았던 건, 프로세스에 대한 개념..

HTML - 웹에서 표현하는 3가지 방법 1. DOM, 2. SVG 일반적인 HTML 문법으로 그릴 수 있다. CSS 적용 계층적 구조를 가지기 때문에, 내부 엘리먼트들에 이벤트들을 부착할 수 있다. (click, hover, ...) 웹표준 / 웹접근성 (screenReadableText, alt, ...) SEO 검색엔진 최적화 Cmd + F 로 텍스트를 찾을 수 있다 SVG 는 벡터 기반이라서, 다양한 해상도에서 선명하고 깨끗한 상태 유지 SVG 는 정확한 오브젝트 영역 탐지 가능 3. Canvas javaScript 로 그릴 수 있다. 픽셀 기반 성능이 좋다. 1000~10000개 넘는 오브젝트를 그릴 때 좋은 성능을 보임 2D, 3D(WebGL) 표현 가능 R3F 환경 설정 vite + reac..

SOLID 5대 원칙이란, 객체 지향 프로그래밍을 할 때 지켜야 할 원칙으로 자주 언급되곤 한다. 오늘은 그 중 Single Responsibility Principle, 단일 책임 원칙에 대해 알아보자. 하나의 모듈은 하나의 책임을 가져야 한다 이런 단언에 가까운 문장을 볼 때, 반례를 떠올려 보는 것이 해당 주장에 힘을 실어준다고 생각하는 편이다. 그래서 위의 문장과 반대되는 예시를 떠올려보자. 새로운 게시글을 저장하는 경우를 예시로, 최대한 간소화해서 표현하면 다음과 같다. 1. 입력된 데이터가 게시글 저장에 필요한 데이터 형식에 맞는지 검사한다. 2. 저장소에 게시글을 저장한다. 만약 위 두 로직을 작성한 코드가 하나의 함수 안에 들어가 있다면, 아래와 같은 모습일 것이다. class Articl..

리액트에서 체크박스의 체크 여부에 따라 카운트 상태를 +1 Or -1 해줄 일이 있었다. 변경 전 const handleCheck = () => { setIsChecked(!isChecked); } return ( ) useEffect(() => { isChecked ? setSelectedIssues(selectedIssues + 1) : setSelectedIssues(selectedIssues - 1); }, [isChecked]); 체크박스가 체크될 때마다 `isChecked`(boolean) 의 상태를 바꾸고, useEffect는 `isChecked`를 지켜보다가 isChecked의 true/false에 따라 `SelectedIssues`(number) 의 상태를 +1 / -1 해주었었다. 문제..

웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인이다. 서버와 클라이언트 사이에 위치해있기 때문에, 서버이면서 클라이언트이기도 하다. 따라서 프락시를 구현할 때에는 둘의 역할을 모두 해내도록 구현해야 한다. 게이트웨이와의 차이점은, 게이트웨이는 클라이언트와 서버가 다른 프로토콜로 통신하더라도 호환성을 맞춰주는 책임을 지는 반면, 프락시는 중개 대상인 클라이언트와 서버가 같은 프로토콜을 사용하는 경우를 처리하는 책임을 진다. 그러나 현실 세계에서의 필요에 의해 프로토콜 호환성을 맞춰주는 게이트웨이로서의 기능을 제공하기도 하므로, 사실상 둘의 차이점은 모호하다. 프락시를 사용하는 이유 프락시는 중개자로서의 역할을 갖고 있기 때문에, 중개자의 책임이기만 하다면 어떤 일이든 할 수 있는데, 주로..