ui5-table이 깨지는 상황

일요일.

Toy Project로 만들고 있는 녀석은 SAP에서 오픈소스로 제공하고 있는 ui5 web-component를 사용하고 있다.

우선 화면을 하나 보면.

ui5-table-cell.innerHTML에 좀 긴 문자열이 들어가 있지만, 개행되며 정상적으로 Table Layout이 유지되고 있는 것을 볼 수 있다.
ui5-table의 특성중 popin 또한 정상적으로 적용이 되어 size와 M-Day column은 아래쪽으로 내려갔다.

두 번째 화면은 아래와 같다.

동일한 길이의 문자열인데, table이 깨지면서 옆으로 늘어진 것을 볼 수 있다.
차이점은 저 녀석이 ui5-link라는 점이다.

이런 사항은 개발자도구에서 차이점을 아무리 찾으려 해 봤지만 식별하지 못한 부분이다. 다양한 시도를 통해서 차근 차근 알아가는 수 밖에.

Nginx를 활용하는 개발, 테스트서버의 설정(Feat. FastAPI, Vite)

목요일.

Toy Project를 하나 만들고 있는데, 이 녀석을 FastAPI와 Vite로 구성하고 (관리의 편의라는 이름으로) 하나의 git project로 관리하고 있다.

root
   - api
     .gitignore
     - __pycache__
     api.py
   - ui
     .gitignore
     - node_modules
     index.html

개발 할 때는 api 폴더에 들어가서 uvicorn으로 api.py를 구동시켜 http://localhost:8000으로 API서버를 올리고, ui폴더로 들어가서 npm run dev로 http://localhost:3000의 (Static) Web Server를 구동시킨다. 물론 npm run serve도 사용해야 한다.

여기에서 생각해야 하는 사항은

CORS
API Server URL

CORS는 FastAPI에서 가이드하는 부분으로 처리하면 되고, API Server URL부터는 좀 생각을 해야 한다.
나는 프론트와 백앤드를 하나의 오리진으로 서비스 하는 것으로 구성 하려고 하기 때문에, 개발 할 때 API서버의 주소와 운영 할 때 API서버의 주소가 상이한 상황이 발생한다.

var, let, const 그리고 hoisting

목요일.

먼저 알아야 하는 내용

var: 선언 및 초기화 -> 할당
let, const: 선언 -> TDZ -> 초기화 -> 할당

함께 알아야 하는 내용

TDZ: Temporal Dead Zone, What is Temporal Dead Zone
hosting: 끌어올림. (맞다. 호이스트 장비라고 생각하면 쉽다.)

중요한 차이는 var의 경우 전역으로, let, const는 블럭으로 scope를 가진다는 것인데, 어려운 사항은 Java나 C만 하다가 JavaScript를 접하는 사람 입장에서는 hoisting이 발생하는 기준이나 TDZ가 이상한 언어라는 인식을 가지게 되는 것이다.

이렇게 생각하시라

C에는 포인터가 있고 Java Spring Framework에는 Injection이 있는데, 이것을 다른 언어만 아는 사람 입장에서 보면 얼마나 황당하겠는가?

Pretendard Web Font 설정하기

화요일.

점심을 먹고 운동을 하고 와서 개발관련 글을 읽고 있는데 폰트가 이쁘다고 생각하고 확인을 해 보니 Pretendard라는 녀석이어서 당연히 외산일것이라 생각하고 구글에서 검색을 하는데 한국인이 만든것인가 보다.

오전에 적용한 ‘D2Coding Web Font’는 이로서 2시간도 안되어 버려지게 되어 버렸다.

Font/CSS설치

Pretendard Font를 받아서 적당한 Font 폴더에 넣는다.
나는 woff2만 지원 할 것이지만 css를 살펴보니 size에 따라 적당한 폰트가 다 따로 있는듯 해서 static woff2 전부를 받았다.
Pretendard css를 받아서 적당한 css 폴더에 넣고 경로를 변경해준다.

적용하기

이건 자신이 처한 jekyll 테마 환경마다 다를 것이나, minima 2022-01-18기준으로..

D2Coding을 Web Font로 설정하는 작업

화요일.

일이 이상하게 돌아가고 있다.(그냥 적용해본 구글 Web Font “Noto Sans KR"가 마음에 안든거다.)

무슨 생각이었을까? 갑자기 D2Coding Font를 이 웹페이지에 적용해야 겠다고 생각하고 구글링을 해 보니 먼저 시도 한 사람이 있다.

알아야 할 사항

woff2, woff, ttf (브라우저 지원을 위한 선택)
full, subset (Size를 줄이기 위한 선택)

웹 폰트 사용과 최적화의 최근 동향을 읽어보면 브라우저 지원을 위해서는 woff2와 woff까지 가지고 있어야 할 거 같은데, 그냥 woff2만 지원하기로 한다. (현재 Edge에서 테스트 해보니 woff2를 사용했기 때문에 나머지 브라우저에서 이상하게 보이는건 어쩔수없다.)

Github Page에 Web Font를 적용하기 위한 설정

월요일.

Github Page를 사용하기로 하고 글을쓰는것에서 다 좋은대 PC로 봤을 때 font가 마음에 안든다.(모바일에서 보는 것은 좋았다.)

Google에서 제공하는 Web Font를 설정하려고 봤더니 간단하게 해결될 문제가 아니라는 생각이 들었다. 사실 이 문제는 공개되어 있는 테마중에 미려한 녀석을 선택해서 사용하면 간단하게 해결된 문제지만, 나는 그럴 생각이 없음으로 내 손으로 해결을 해야한다.

이런 작업을 하기에 2가지 사항을 해결해야 했다.

Jekyll의 기본테마인 minima에 Web Font를 적용시키는 방법
Local에서 작업을 했더라도 Github Page에 Push했을 때 의도대로 동작하도록 환경을 일치시키는것

jekyll 버전일치

일단 Github Page에서 Jekyll을 사용해서 서빙을 하고 있기 때문에 Github이 제공하는 환경과 내가 가진 환경의 차이점을 없애는 부분을 먼저 검토해보니 Jekyll버전부터가 다르다.
~~sudo gem install jekyll -v 3.9.0~~
~~gem도 install을 지원하기 때문에 적당한 버전의 jekyll을 다시 설치 해 준다.~~

WSL에서 port개방이 안될때

월요일.

개발환경을 WSL에 설정하면서 서버를 구동하고 웹브라우저로 확인을하던 디버깅을 하던 필연적으로 WSL과 Host Window사이의 port를 개방해야 하는 문제에 직면하게 된다.

당연히 구글에 찾아보면 PowerShell로 만들어진 스크립트를 손쉽게 입수 할 수 있지만, 그 어디에도 (그렇게 해도) 안될때에 대한 이야기나 추가적인 사항에 대해서 언급한 포스팅은 본적이 없어 잠시 해메다가 이 글을 적어본다.

먼저 아래에 기술한 Script를 확장자 ps1으로 저장을 하고 스크립트의 내용을 살펴보자.

$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"

여기에서 중요한 부분은 bash.exe가 의미하는것이 Window말고 Linux에서 실행할것이라는 의미이다. 그러니 뒤쪽에 있는 파라메터중 ifconfig는 linux command이다. 불행하게도 Ubuntu기준으로 저 녀석은 기본설치가 아니고 net-tools에 포함되어 있다. linux에서 apt로 설치해줘야 한다.

무엇이던지 시작은 미미했을 수 있다.

금요일.

아침에 사무실에 출근해서 전날 저녁에 설정하던 WSL에서 Python Debug하는 것을 계속하려다 이상하게 Java 아니 정확하게는 Eclipse상에서 개발되고 있던 회사 인트라넷 개발환경을 VSCode로 설정하는 것을하는 하는 쪽으로 바꾸게 되었는데.

문제는 설정을 어느정도 한 뒤에 이 녀석에 관련된 북마크만 남겨둘 것이 아니라 간단하게나마 내용을 적어놓자 싶은 생각이 들어, 요즘 젊은 친구들은 어디다 무엇을 적고 있는지 페이스북에 물어본것이 화근이 되어 지금 Jekyll로 설정을 하고 GitHub Page에 push를 하는 상황이 벌어지고 있다.

피할수 없으면 즐겨라! (어! 이건 아닌가?)

Maven 명령어 실행에 따른 파일 갯수의 변화

Maven을 사용하여 컴파일을 하고 테스트를 하면 당연히 프로젝트 내부에 있는 파일의 변화가 발생합니다. (누가 이런거에 관심을 가지겠냐마는… :')

위 표는 Maven archetype 112번 sample로 테스트 한 것으로… (하여간)

위 에서 주시하는 내용은

compile 명령은 target의 class를 생성합니다.
test 명령은 target의 class와 test-class를 모두 생성합니다. 그리고 Test Result를 .txt, ,xml File로 생성합니다.
package 명령은 test까지 포함하는 작업을 수행하고 .jar와 .properties File을 생성합니다.
clean 명령은 다시 깨끗하게 지워주는 군요 :')

생각해 보면 당연한 것이데… :')