back online

Categories 어린 아름다움에 대한 찬가Posted on

메인 SSD를 nvme로 업그레이드 하던 중에
efi 날려 먹고 개뻘짓을 한 끝에 복구했습니다.

현재는 슬롯 부족해서 앙트레포는 뽑혀 있고,
파티션 정리하느라 빈 드라이브가 필요해서 프런트데스크를 다 비웠고,
백업 페어링도 아직 안 돌아가서 백업 드라이브가 비어 있는 상태

뽑아 놓은 E드라이브 하드가 원래 프런트데스크라서
아파치 서버가 있던 유일한 7200rpm 하드인데
이리저리 파일 옮기고 디스크 이름 바꿔놓고 보니 헷갈려서
5400rpm 하드들만 남기고 저걸 뽑아 버렸어요.
(프런트데스크는 분류 전 파일들이 거쳐가는 말 그대로 ‘프런트데스크’라서
그래도 빠른 하드가 필요한데, 다시 본체 뜯고 하드 바꿔 끼우긴 귀찮아요.
sata SSD를 고용량으로 박아넣으면 또 모를까, 굳이 5400/7200차이에…
근데 sata ssd 4테라 제일 싼 게 웨디 블루 35만원인데 이거 맞나?
이제 만드는 곳도 별로 없긴 하겠지만 그렇다고 nvme랑 같은 가격대라고?)
그래서 서버 속도가 미세하게 감소할…. 리는 없죠. 뭐 얼마나 큰 파일을 억세스한다고.

efi 복구하느라 1년간 해체해 놨던 서버 재조립해서 윈도우즈 부팅 USB 만들고 난리 친 덕에…
뭔가 한 건 하나도 없는데 머리가 입력을 거부하는 상태라
드라이브 변경으로 인한 자잘한 오류들은 천천히 고쳐질 겁니다.
뭔가 작동하지 않는 게 있다면 이 글에 리플로 알려주세요.

+
기존 sata ssd를 새 nvme로 클론해서 부팅할 때는 멀쩡했는데,
sata ssd 시스템 파티션 날리고 포맷할 때 efi가 날아간 거 같은데…
솔직히 왜 날아간 건지도 잘 모르겠고,
부틀로드 새로 써서 복구한 지금도
부팅할 때 뭔가 한 단계 더 거치는 것 같은 게 제대로 복구한 게 아니라
내가 새로 쓴 부틀로드가 기존 설정을 오버라이드하고 있는 느낌이다.
efi랑 부트렉은 진짜 모르는 분야라서
뭔가 문제 생길 때마다 그냥 내가 이해한대로 투닥투닥 필요한 명령어 찾아다 고치는데…
내가 해놓은 게 제대로 짜깁거나 완전히 밀고 새로 만들었다기보단
더덕더덕 패치워크 기워 붙이는 거라서 괜히 그렇게 느끼는지도.
오늘은 이건 부트렉으로 복구가 왜 안 되나요? 검색해보고
다양한 원인이 있을 수 있으니 확실한 건 다 지우고
부틀로드를 아예 새로 써서 올리는 거예요 하는 마소 기술 답변 보고
한 땀 한 땀 흩어져 있는 것들 다 지우고 새로 부틀로드를 쓴 거라
저 지워야 하는 것 중에 뭐 빼먹었을 수도 있고.

+
예전에 엑박 one x에 물려 놨던 1테라 sata ssd가 하나 있다는 생각이 나서
여기저기 탈탈 털어보니 외장 케이스에서 나오네.
프런트데스크를 이 ssd로 교체함.
그럼 이제 i드라이브가 생기는 건데-_-
i는 이름을 뭐라고 하지?

워드프레스 이 새끼들 장난하나?

Categories 이모젠식 정의Posted on

정식으로 올리긴 했지만,
아직 리비전 검토 기능을 제대로 갖추기 전이었는데,
아침부터 워드프레스가 테마 업데이트를 하는 바람에
리비전부터 뚝딱 뚝딱 올리기 시작해서
이제야 완성하고 테스트 끝냈다.

그리고는 이 새끈하게 잘 뽑은 리비전 검토 기능으로
업데이트된 테마 파일을 비교해서
대체 테마 업데이트가 뭐가 됐는지 보니…

테마 펑션에서 font_url을 불러 오는 항목 변수 종류가 지정 안 되어 있었는데
스트링으로 지정.
뭐, 저기에 숫자 값이 들어가서 오류를 일으킬…. 리가 없는데?
소스를 아무리 뜯어봐도 저기에 스트링 말고는 들어갈 여지가 없는데?
폰트 url이 전부 숫자라면 몰라도, url이 전부 숫자일 수는 없잖아?
아, 동일한 폴더 안에 있거나, 이름이 숫자로만 이루어진 하위 폴더 내의,
파일명이 숫자로만 이루어진 폰트 파일을 상대주소로 호출한다면 가능하겠네.
폰트 폴더 이름이 2424254598 따위고 폰트 파일 이름이 383896282.243 따위라서,
상대주소로 2424254598/383896282.243로 호출하면 개판 나겠네.
근데 폰트파일 확장자 안 맞춰줘도 인식하나?
하겠….지? 할 것 같긴 해.
그런 병신짓을 해본 적 없어서,
상상도 안 해봐서 모르긴 하지만…
………………..

css 업데이트 관련 된 날짜 어레이 처리.
이건 어차피 css 파일들이 안 바뀌었으면 안 바뀌는 거고.

readme 파일 정보 수정.
이것도 어차피 바꾼 거 없으면 안 바꾸는 거고.

메인 css 파일 버전 수정.
이것도 바꾼 거 없으면 안 바꾸는 거고.

에딧블록 css 파일 separator 섹션 구분 주석에 seperator로 오타 난 것을 수정.
…… 어. 고치는 김에 오타는 고쳐줘야지.

블록파일에 탑마진 2em 추가.
….. 음? 뭔가 출력 되는 게 줄이 틀어져서 살짝 마음에 안 드셨나봄?

블록 css 파일 separator 섹션 구분 주석에 seperator로 오타 난 것을 수정.
뭐. 그렇지. 하는 김에….

끝.

?????????????????????????

뭐?

….

그러니까,
저거 하나란 거지?
‘동일한 폴더 안에 있거나, 숫자로만 이루어진 하위 폴더 내의,
파일명이 숫자로만 이루어진 폰트 파일을 상대주소로 호출할 경우,
파일 로딩을 못하고 오류를 일으키기 때문에,
폰트 호출 라인을 텍스트로만 인식하도록 선언’
저거 하나 고쳤다는 거지?
그러니까…. (string) 띄어쓰기까지 9바이트 추가 하자고….
내가…
그러니까….
그러고는 오타나 고치자고.
아침부터.
일 제쳐두고.
리비전 시스템을 완성하느라.
시발.
그러니까.

아니 시발 폰트 파일 파일명을 숫자로만 만들고 쓰는 미친놈이 세상에 어디 있어요!?
폰트 파일을 테마 루트, 혹은 이름이 숫자로 된 하위 폴더에 두는 미친놈이 세상에 어디 있어요?
폰트 파일 따위를 호출하는데 절대 주소를 안 쓰고 상대 주소를 쓰는 미친놈이….
어, 이 정도 미친놈은 많은 거 같긴 하네.
어쨌든, 저 셋을 동시에 하고 자빠진 미친놈은 세상에 어디 있냐고!

+
이거 생각해보니까, 회원별로 폰트를 따로 쓰게,
직접 업로드 하게 하면 숫자로만 이루어진 하위폴더와 파일명은 이상하지는 않은 것 같긴 하다.
폴더명, 파일명 전부 회원 번호가 되게 된다면 말이지.
근데 그러면 대체 왜 상대주소를 써요?
아니 그러게? 대체 왜 상대주소를 씀?
테마 폴더 자체를 복사해서 다른 위치로 보낼 일이…
아… 저렇게 파일을 테마 폴더 안에 넣은 상태로
테마 버전 관리하려면 상대주소 써야하는 거구나.
난 파일 업다운할 때마다 드는 자원 아까워서
애초에 절대 주소로 파일을 올리고 절대주소로 파일을 호출하겠지만,
‘이 폰트는 이 테마에 쓰이는 거니 이 테마 폴더 아래에 있어야 해요’ 같은 식으로
사고하는 애들, 그리고 테마 버전별로 다른 폰트를 쓸 수 있게 하는 경우에….

음. 결론은 내가 처음 생각한 것에 비해서 상대적으로 덜 미친놈이긴 한데,
미친놈인건 변함 없네.
저런 식으로 사이트 구성을 왜 해-_-

난색 바탕으로 돌아오니 좋네요.

Categories 어린 아름다움에 대한 찬가Posted on

뭐, 아는 사람은 알겠고,
짐작하고 있는 사람은 짐작하고 있었겠지만,
그동안 Precious Phraſe는 베타 버전으로 제공되고 있었습니다.
페이지에 장식 요소가 하나도 없었던 것은
내가 워드프레스와 이 테마의 구조에 완전히 익숙해지고,
6천줄에 달하는 css를 완전히 제대로 제어할 수 있다는 확신이 들 때까지
그냥 흰 페이지로 내버려두는 게 낫겠다는 생각에서였어요.

그리고 웹폰트를 적용하느라 css를 만지면서,
이제는 베타 딱지를 떼어도 되겠다는 확신이 들었어요.
그래서 지금 이 시점부터 Precious Phraſe 워드프레스판은
정식버전입니다.

뭐… 달라지는 건 딱히 없겠지만요.

+ 아, 달라지는 게 있긴 있네요. 이게 마지막 개발노트입니다.
앞으로는 수정이 표면적인 영역 보다는 기술적인 영역 위주로 될 것이기 때문에
더 이상 수정 사항이 있어도 패치노트를 써서 알리지 않을 거예요.

이글루스판 Precious Phraſe는 연노랑색(#f7f7f1) 바탕색을 썼고,
사실 링크색인 #06a도 그 바탕색의 보색으로 조정된 색이었죠.
워드프레스판의 바탕색은 좀 더 #06a의 보색에 가까운
연주황색(#f8f4ec)으로 결정했어요.
(+ #fffcf4로 조정했습니다.)
조금 붉어졌고, 조금 어두워졌지만,
어쩄거나 Precious Phraſe의 근본인 난색 바탕색으로 돌아오니
이제 정말로 내 블로그 같네요.

패치노트

Categories 어린 아름다움에 대한 찬가Posted on

1. 그동안 쌓여 있던 자잘한 수정 요망 사항들이 수정 되었습니다.

1-1. 포스틀리스트와 스크롤 버튼이 모바일에 대응하도록 약간의 마진을 뒀습니다.
기본적으로 모바일에서의 사용은 신경 쓰지 않는다는 게 방침이지만,
굳이, 약간의 마진 수정 정도를 하지 않을 이유도 없어서 했어요.
하지만 버튼 반투명화나 버튼 크기를 반응형으로 조정하는 등의
적극적인 모바일 대응은 하지 않을 겁니다.
불편해요? 모바일에서 보지 마세요.
이 블로그는 결코 모바일에서 보는 것을 추천하지 않습니다.
모바일 활용의 모든 요소가 이 블로그의 운영 방침과 대치 돼요.
내가 모바일 접속 관리 경찰봉을 들고 모바일 접속자 뚝배기를 깨고 다니는 거야 불가능하고,
특정 접속을 차단하는 방식 역시 내 운영 방침, 혹은 http에 대한 신앙과 대치 되니
(우회하는 것도 일도 아니니-_-)
‘모바일 접속을 금지’하는 것 따위는 하지 않지만,
할 수 있다면, 했을 겁니다.
+
모바일에서 포스틀리스트와 스크롤 버튼이 표시되지 않도록 수정했습니다.
만약 기존의 포스틀리스트를 켜놔서 포스틀리스트가 계속 나타나는 경우,
기존의 포스틀리스트 토글 버튼 자리에 놓인 퍼지 버튼을 누르면
정상적으로 포스틀리스트가 삭제됩니다.
기능이 정상 작동하지 않는 경우 쿠키를 삭제하거나
와이드뷰 데스크탑 모드로 전환 후 포스틀리스트 토글 버튼을 눌러 포스틀리스트를 꺼주세요.
다시 말하지만 난 모바일 사용을 신경 쓰지 않으며,
이러한 기능의 추가나 삭제로 인해 모바일 사용 환경이 꼬이는 것에
매번 대응을 하지는 않을 겁니다.

1-2. 카테고리와 작성일을 제목 아래로 끌어올렸습니다.
아직 css 스타일은 고민 중이라서 제대로 정비 안 했지만,
어쩄거나 스크립트는 손 봐 놨어요.

1-3. 포스틀리스트 버튼과 포스틀리스트 메뉴를 살짝 정비했습니다.
나열하기 민망할 정도로 자잘한 오류들이 여럿 수정 되었습니다.
아직 정비되지 않은 알려진 오류: 현재 포스틀리스트 링크를 새로고침하면
페이지 내부 오브젝트의 로드 순서가 어긋나는 경우
지정하지 않은 다른 포스트 위치로 이동 되는 문제가 있습니다.
꼼꼼하게 스크립트를 손 봐서 먼저 로드해야하는 파트를
앞으로 옮겨 정렬하면 해결할 수 있는 문제이지만,
굳이 이 정도 소소한 오류를 손 보기 위해
스크립트 순서를 갈아 엎는 미친 짓은 하지 않을 겁니다.

1-4. 폰트가 정비 됐습니다.
원래대로 팔라티노 리노타입과 세고UI, 맑은 고딕을 우선 사용하도록 바꿨고,
해당 폰트가 없는 경우 노토로 지정했습니다.
다만, 한글 세리프는 이롭게 바탕체가 설치되어 있는 경우
해당 폰트를 사용합니다만….
어떤 시스템에서도 기본 폰트가 아니니 웬만해선 신경 안 써도 됩니다.
한글 세리프로도 맑은 고딕을 쓰게 하면서
한글 세리프 폰트를 아예 없애는 것을 고민했는데,
언어별로 폰트 영역을 지정하는 것보다는
그냥 한글 세리프 폰트는 자기 좋을 대로 쓰는 게 낫겠다 싶어서
그냥 serif로 내버려뒀어요.
시스템에 맑은 고딕이 없다면 시스템에 지정된 한글 세리프 폰트로 출력 될 겁니다.
제발 “본문 가시성이 너무 떨어져요. 폰트 좀 바꿔 주세요” 따위의 말 좀 하지마세요.
네가(혹은 웹브라우저 기본 설정이) 지정한 네 기본 세리프 폰트라고요.
세리프 폰트는 원래 본문을 읽기 쉽게 하기 위해 개발 된 폰트예요.
네가 그 가독성이 높아야만 하는
한글 기본 세리프 폰트를 ㅈ같이 가시성이 떨어지는 걸 쓰고 자빠진 게 문제니까,
제발 기본 세리프 폰트를 바꾸라고요.

+
한글 기본 세리프 폰트 엉터리로 지정해놓고 나한테 ㅈㄹ하는 거
아무래도 개같아서 이롭게 바탕체를 웹 폰트로 적용했습니다.
웹 폰트는 내 개발 철학에 정면으로 반하는 거긴 하지만…
뭐 내 리소스 먹는 것도 아니니까.

2. 댐드 시네이터와 project.lejuel이 완전 독립 페이지로 나갑니다.

블로그 페이지 어딘가에 흔적이 남아 있을지도 모르지만
이미 다 비워서 내보냈어요.
관련 권한 플러그인 몇 개도 같이 삭제했기 때문에
서버 속도에 미세한 향상이 있습니다.
(10-15% 정도 나오니 미세하진 않네요.)
하지만 내가 자원이 남는데 엉뚱한데 낭비하지 않을 리가 없으니
곧 다시 미세하게 느려져서 원상 복구 될 겁니다.

3. 메인 페이지 커멘트 로딩에 대해서는 고민 중입니다.

스크립트는 준비가 됐는데,
현재처럼 커멘트를 보고 하려면 싱글 페이지로 들어가야 하는 시스템이
좀 더 장점이 있는 것 같아서 고민 중이에요.
뭐 페이지 로딩에서 자원을 적게 먹는다도 장점이긴 한데,
이 규모의 블로그에서는 사실 신경 안 써도 되는 수준이긴 하죠.
내가 주목하는 장점은 지나가다 뻘 커멘트 하는 비중이 확실히 줄었다는 거예요.

패치 노트

Categories 어린 아름다움에 대한 찬가Posted on

1. 메뉴 스크롤을 최소화 하기 위해 메뉴 목록 구성과 사이트 아이덴티티 요소에 자잘한 수정이 있었습니다. 메뉴가 다 접혀 있는 상태에서 스크롤이 필요 없는 높이의 창으로 사용할 것을 추천하지만 굳이 그렇게 하지 않아도 딱히 별 차이는 없습니다.

2. 우측 하단에 페이지 맨 위로 스크롤, 맨 아래로 스크롤, 좌우 중하단에 이전 페이지 다음 페이지 플로팅 버튼을 추가했습니다. 네, 알았어요. 가벼운 플로팅 메뉴 플러그인 그만 추천해도 돼요.
2-1. 이전 페이지 다음 페이지 플로팅 버튼이 있으니 맨 아래로가 생각보다 필요 없는 느낌이라서 맨 위로 / 현재 문서 길이의 25% 위로 스크롤 / 현재 문서 길이의 25% 아래로 스크롤로 우하단 플로팅 메뉴를 변경했습니다.

+
2-x. 저 스크롤 메뉴가 가볍긴 한데 진짜 주먹구구로 만들어져 있어서 자바스크립트를 미친듯이 손 봤다. 어…. 이럴거면 그냥 내가 만들 걸 그랬나? 사실 제일 만들고 싶은 건 페이지에서 포스트 엔트리를 받아서 다음 포스트까지 스크롤 하는 기능인데, 이걸 하려면 리스트업 된 포스트에 순서에 맞춰 임시 개별 클래스를 지정하는 플러그인을 깔아야 한다. 당연히 저것만으로도 자원 낭비인데, 저런 플러그인들이 이것저것 엮인게 많아서 너무 무겁다. 아니면 포스트 리스트업하듯이 메뉴도 리스트업 해서 각 포스트 바로가기 버튼을 만드는 방법도 있는데…. 그럼 개 난잡하잖아.
++
임시 개별 클래스를 지정하는 게 아니라, 그냥 퍼머링크를 id로 받아 쓰도록 만들어봤더니 개 깔끔하게 잘 돌아가긴 한다. 문제는 이제 저 리스트를 어디다 배치하냐는 거다. 깔끔한 위치 잡기는 불가능해 보인다.
+++
일단 우상단에 앵커 토글로 붙여놓긴 했는데,
개 난잡하다. 일단 이전페이지 다음페이지 플로팅은 치워놓고 더 테스트해봐야겠다.
++++
뭔가 직관적인 기능 설명이 있어야 할텐데
쉽지 않다.

패치노트

Categories 어린 아름다움에 대한 찬가Posted on

1. 검색 엔진 수집 정책이 모두 거부에서 모두 허용으로 바뀝니다.
네, 원래 이 서버가 정상 궤도에 오르는 것을 기다리면서 기존 사이트 정보 찌꺼기들이 삭제되도록 막아둔 거라서, 이제는 풀어놓습니다. 원래대로 다음 검색은 막으려고 했는데, 다음 검색 봇 인식명이 기억 안 나는데 찾아보기 귀찮아서 안 막을게요. 물론 또 ‘ㅅㅂ 이런 검색어로 여기 들어오는 게 맞나?’ 싶은 병신같은 레퍼 잡히면 막을 겁니다. 다음의 전례를 볼 때 그 수준 떨어지는 검색엔진이 얼마 안 가 사고를 칠만한데, 자주 문제를 일으키던 앨범 정리를 더 이상 올리지 않기 때문에 문제가 안 생길 것 같기도 하네요.

2. 일단 PLN 서버는 분리합니다. MLN과 VLN은 일시 중지됩니다.
DLN 원드라이브 루트에 관련 공지가 따로 있습니다. 가서 처 읽으라고 이 강아지들아, 서버 자원만 파 먹지 말고 공지가 있으면 읽으라고! 응?

3. 영향이 댐시에서 프레이즈로 다시 옮겨집니다.
공개 일기장은 결국 완전 공개 되어 있어야 제 기능을 하죠. 요즘 남이 보는 게 두려운 글을 잘 안 쓰다보니 글을 너무 못 쓰는 게 자꾸 밟혀서 이걸 해야겠어요. 다만 검열을 좀 빡쎄게 하고, 기존의 비공개로 작성된 영역이 공개되지는 않을 겁니다.