메뉴 건너뛰기

박영식 홈페이지

[화장] CSS는 화장(makeup)하기?

[원문보기]

이 주제에 대해 다뤄보고 싶었다.


디자인은 화장하기(makeup)와 비슷한 것 같다.


개인적으로 화장을 안 하기 때문에 정확히는 알 수 없지만, 예뻐보일 때까지 계속하고, 남들 것을 모방하고 수정이 계속된다.


완전한 만족이란 없다. 80~90% 정도까지, 또는 시간이 허락될 때까지 계속 하는 것이다.


그리고 별로 일이 없는 날 연습도 한다.


화장하는데 많은 시간이 걸리는 것에 대해 조금이나마 이해할 수 있는 작업이다.


기능도 기능이지만 디자인도 이젠 높일 시기가 왔다.



[도서] 위풍당당, 프랑스 와인 여행자

[원문보기]

[위풍당당] 성석제

사자는 토끼 한 마리를 잡을 때도 최선을 다하는 법이다. 181쪽


[프랑스 와인 여행자]


샴페인은 프랑스 샹파뉴 지방에서 만드는 거품 있는 와인을 말한다. 그러나 많은 사람들은 거품이 있으면 모두 샴페인이라고 부른다. 제대로 구분해서 와인을 즐기고 싶다면 이점을 명심하기 바란다. 즉, 샹파뉴 지방에서 만든 거품 와인만이 샴페인이고, 샹파뉴 이외 지방에서 만들면 샴페인이 아니다. 물론 프랑스가 아닌 다른 나라에서 만든 거품 와인은 샴페인이 아니다. 이런 와인들의 총칭은 그저 스파클링 와인이다. 샴페인은 그 자체가 하나의 상품이다. 그래서 고유명사가 일반 명사화되었다. 샴페인이 되기 위한 조건이 하나 더 있다. '샹파뉴 방식'에 의거하여 거품 와인을 만들어야 한다. 샹파뉴 방식이란 곧 병 속에서 2차 발효를 하는 것이다. 거품을 병 속에 인위적으로 집어넣는 것은 샹파뉴 방식이 아니다. 결국 샴페인은 샹파뉴 방식으로 양조할 때에만 샴페인이라고 부를 수 있다. 그 외에는 샴페인 이름을 사용할 수 없다. 231쪽


생테밀리옹에서 전해 오는 이야기는 1620년 한 수녀원에서 마카롱이 탄생했다는 것이다. 단조롭고 심심한 수녀원에서 배꼽 빠지게 웃고 싶어서 그랬는지 몰라도 마카롱은 배꼽을 닮았다.~중략~

마카롱은 밀가루로 만드는 게 아니니 과자가 아니다. 계란 흰자와 아몬드 가루, 그리고 설탕으로 만든 머랭을 샌드위치처럼 포개고 그 사이에 잼이나 크림을 채우면 완성된다. 아몬드 맛이 주류를 이루는 이유는 이 때문이다. 320~321쪽


낼, 도서관 휴관이려나?

[잡담] '리얼'의 의미 퇴색

[원문보기]

10~20년 전 '원조'라는 말이 안 붙으면 2차로 가공된 또는 품질이 떨어진다는 의미가 부여되었다.

이제는 '리얼'이라는 말이 붙지 않으면, 가짜의, 짝퉁의 라는 이미지를 갖을지도 모른다.

오히려, '리얼'이란 단어를 써서 자신만, 해당 제품만 진짜고 나머지는 가짜라는 의미를 전가시키고 있다.

많은 가상화된 시스템과 환경이 나와 실제가 아닌 가상이 더 많아지고 있지만, 실제(리얼, real)는 가상(버추얼, virtural)에 상응하는 말이지, 진짜(true, pure)와 가짜(false, mixed or processed, not natural)과 대응하지는 않는다고 생각한다.

그러나 사람들은 real 이 진짜만을 의미하는 듯, 이게 붙지않으면, 모두 가짜라고 생각하게 만들고 있다.

natural 이라는 말이 나와서 그런데, '자연산'이란 단어가 역시 매우 저속하게 쓰이고 있어 안타깝다. 사실 양식과 구분하기 위해 쓰였던 말인데, 성형에 대응해 쓰이고 있어, 이런 말을 쓰는 사람들과 대화하게 되면 기분이 나빠진다.


원조, 리얼, 자연산


다음은 어떤 단어가 희생양이 될 것인가!

현실에 충실하자

[원문보기]

 누군가로 부터 배려가 과도하다는 말을 들었다. 개인적으로 그런 배려 섞인 말을 하고, 행동을 하는데, 처음에는 좋은 인상으로 다가갈 수 있지만, 나중에는 과도함으로 남게될 수 있다고 느낀다.


 얼마 전에도 그런 말과 행동을 했음을 인정하고, 어떻게 바꿀 것인가에 대해 생각해봤다. 과도한 배려심이 오히려 자신을 너무 낮추는 결과를 초래해 인정받지 못 하는 상황이 이어진다면 나만 손해인 것이다. 현실에 충실하며 주장해야할 상황이라면 배려보다는 리딩이 오히려 좋은 결과로 이어질 수 있다고 생각한다.


 최근 새롭게 알게된 이가 자학하며 자신을 너무 낮추는 모습을 보았을 때, 자신감이 없어 보여 좋지 않은 인상으로 이어짐에 나 자신을 깨달을 수 있었다. 과하지 않게, 현실에 맞게 그 모습을 제대로 드러내도록 노력해야겠다.


 항상 살아오면서 이중적인 생활을 하고 있어, 도움이 되기도 하지만 역효과로 이어지는 경우가 많음을 느끼게 된다. 있는 그대로를 보여주지 못하고 가식적이 되어가는 자신을 합리화하고 있어, 항상 그렇게 생각한다. 남들이 날 가식적으로 생각할까? 그렇지도 모른다. 이 글에 여실이 드러나는구나.

[handoff] 아이패드에서 전화 받기

[원문보기]

아이패드를 8로 업그레이드 하고, 갑자기 전화가 되었을 때 놀랐었다.


휴대폰 수리 후 이 기능이 되지 않아, 10분 이상 원인을 찾아봤다.


facetime 설정과 handoff 기능 활성화에도 되지 않았기 때문에 전화를 5번 정도 걸어서 테스트 했는데, 문제는 iCloud 로그인 이었다.


iCloud 쪽에 연락처 공유 기능이 있어서 해당 설정을 로그인으로 활성화 시켜야 전화가 되는 것이다.


이제 다시 아이패드에서도 전화를 걸거나 받을 수 있도록 설정이 되었다.


급 피곤하군...

[CS] Cloud Service 사용

[원문보기]

AWS는 아마존 웹 서비스로 현재 1년 무료로 이용할 수 있다.

HOSTING 서비스처럼 가상 머신으로 활용할 수 있는 EC2는 익숙한 방식이다.


Azure는 MS 에서 제공하는데, 1개월 무료이고 기업은 3년동안 무료로 쓸 수 있는 경로를 제공하고 있다고 하니 조만간 시도해 볼 예정이다.


로컬 PC에 VMware로 이용하는 것보다 유지 부담을 줄일 수 있어, 테스트 환경 활용에 유용할 것으로 기대된다.


다면, aws는 한글화가 좀 더 필요하고, windows azure는 무료 지원이 좀 더 강화되며 좋을 것 같다.


aws 는 터미널 접속에 key 파일을 이용해야하는 약간의 설정이 필요하지만, windows는 rdp로 바로 접근 가능하다.


무료인데, 어떤 불편을 감수하지 못할까. ㅎ



[글쓰기] 나는 테스터다. 단위 테스트는 지양한다.

[원문보기]

개발자 입장에서 실제 사용자는 어떤 식으로 입력할지, 기능을 사용할지 알 수 없다.


물론 초기에 "A는 B에 입력하고, C를 D와 같이 사용하세요." 라고 하더라도, " A?, B?, C?, D? == 가, 나, 다, 라 "로 흘려 들을 수 있다. 사실 제품 제작자가 아닌 내 자신이 사용자가 된다면, 설명서에 집중하여 최대한 시행착오를 줄이려 노력한다 해도 결국 한 두가지를 간과하여 실패에 이른다.


자주 짧은 코드를 작성하고, 간단한 단위의 배포 소스를 수정해 적용하는 업무를 하고 있다. 아무리 코드의 양이 적더라도 단위 테스트 등을 통해 품질을 관리할 필요가 있다. 이는 확장성에 닿아 있기 때문이다. 그러나 나는 게으르기 때문에 테스트를 위한 코딩은 하지 않는다. 단지 디버깅 로그를 사용할 뿐이다. 또한 핑계를 하나 더 붙여서 사용자의 입력과 행동이 단위 테스트 범위를 넘어서는 경우가 많아 차라리 사용자 테스트를 통해 버그를 수정하고, 축적된 데이터를 분석하는 것을 선호한다.


그동안은 나의 게으름을 완전히 숨겨왔지만, 이를 정당화(?)해 줄만한 글을 읽었기에 옮겨 놓는다.


테스트는 해야 한다. 테스트, 테스트, 테스트. 하지만 나는 단 한번도 (a) 설정하는 데 걸리는시간이 100 시간/사람 이상 걸리지 않거나 (b) 수많은 공학적 자원을 빨아들이지 않거나 (c) 실제로 상관이 있는 버그를 발견하는 구조적인 테스트 프로그램을 본 적이 없다. 단위 테스트라는 것은 수많은 엔지니어에게 지루함을 견디고 아무것도 찾아내지 않는 것의 대가로 급여를 지급하는 수단에 불과하다 - 윌 쉬플리-


개인적으로 나는 테스트 주도 개발이라 생각했다. 작은 코딩을 하고 테스트하여 원하는 결과를 얻고, 같은 방식으로 새로운 함수를 만들거나 확장하는 식으로 코딩을 하기 때문이다. 그러나 적확하지는 않음을 깨달았다. 이런 개발방식은 차라리 주먹구구식에 가까울지도 모른다. 그래도 설계가 어느 정도 포함되어 있고, 규모 자체가 워낙 작기에 효율적이다.


보안 점검에서 좀 더 과격한 테스터의 관점을 더한다면 아래의 조언을 받아들일 수 있다.


과감하게 말하겠다. 당신의 망할 프로그램을 반드시 테스트해야 한다. 실행하라. 사용하라. 이상한 일들을 해보라. 키보드를 망가뜨려라. 지나치게 많은 항목을 더해보라. 2MB 짜리 텍스트 파일을 넣어보라. 그것이 어떻게 오동작하는지 발견하라. 이렇게 하는 것이 매우 중요하기 때문에 나는 지금 고함을 지르고 있다. - 윌 쉬플리 -


한국은 너무과도한 테스트를 했는지도 모른다. 정말 2MB 를 넣었더니 디버깅이 불가능한 수준으로 갔다. IT 테스트베드로 좋다는 것은 인정하지만, 실험정신이 너무 강했는지도 모른다.


내가 제작한 프로그램은 사용자가 IT 관련이 아니다. 물론 이것은 중요하지 않을 수도 있다. 정말 생각지도 못한 사용이 일어나기도 하여, 끔찍한 결과가 나온 적도 있다.(그렇게 끔직하진 않다.) 아무튼 난 단위 테스트라기 보다는 사용전 테스트와 사용자 테스트를 통해 코딩을 한다. 이건 단순 테스트 주도 개발이 아닌 "주먹구구식 사용자 테스트 주도 개발" 정도로 불러본다.

[진리] 보이는 영역과 보이지 않는 영역

[원문보기]

세상은 너무 복잡화 되었다.


그래서 보이는 영역과 보이지 않는 영역은 명확해 보이는 보이면서도 알 수 없다.


시각화를 통해 보이도록 했지만, 보이도록만 했는지 가공을 통해 보여주고 싶은 부분만 시각화 했는지는 알 수 없다.


더럽거나 혐오스러운 부분을 가리기 위해 커튼이나 가림막, 덮개를 사용한 것 뿐이다.


덮개를 여는 것이 쉽다면 열어서 실체를 보면 된다.


그러나 덮개를 열 수 있는 방법을 제공하지 않거나 보여주고 싶은 부분만 보이도록 덮개를 열도록 한다면 그 문제는 심각해 진다.


두려운 부분을 가리고 싶은 욕구를 내재하고 있기 때문에 덮개를 열었을 때 친화적인 부분만 노출된다면 문제를 제기하지 않는다.


그러나 덮개를 열었을 때, 예상치 못한 내용을 보게 된다면 두려움에 쌓이게 된다.


덮개가 쌓여진 보이지 않는 영역에, 덮개를 열었을 때 보이는 영역이 노출된다면 그대로 받아들일 것인가?


현재는 무조건 yes로 되어있다. 덮개에 대한 검증도 할 수 없는 복잡한 시대에 접어들었기 때문이다.


덮개에 대한 검증. 또 하나의 "고양이 목에 방울 달기"가 되었다.


덮개에 대한 고민이 필요하다.

[구매] 노트북 업그레이드

[원문보기]

SSD, 추가 RAM, 하드디스크 확장, ODD 케이스


SSD 를 추가하고, RAM을 확장했다.


기존 HDD는 SHB로 ODD 대신 장착할 수 있어서 작업을 마무리했다.


전면 베젤이 맞지 않아, 외장 ODD 케이스를 주문하면서 추가로 신청했는데, 12.5mm 와 9.5mm 에서 잘 맞을지 모르겠다.


SHB 는 전면 베젤이 없는 상태로 끼워져 있어, 살 수 밖에 없었는데, 1TB의 노트북에 뭔가 빠진 듯한 것을 채우는게 맞을 것 같아서 이다.


노트북 구매 비용과 거의 비슷하게 들었지만, 고성능 대용량이라는 점이 이번 작업의 성과다.

[광고] 가치를 만들자

[원문보기]

https://www.youtube.com/watch?v=PJwVp3--8uA


이 광고를 보며, 인생을 낭비하고 있는 자신을 반성하게 되었다.

세상에 할일이 많은데 할 게 없다고, 인터넷 서핑으로 시간이나 죽이고 있는 자신이 부끄러웠다.

공부할 것도 많고, 세상을 바꿀 수 있는 소소한 것도 많은데 해봤자 소용 없다고 부정했던 과거를 떠올리면 고통스럽다.


오늘 푸트코트에서 자가 배식을 위한 식판을 옮기지 못하는 장애인을 보았다.

직원은 쟁반위의 담긴 음식을 갖다 주었는데, "고맙습니다."가 아닌 "미안합니다" 였다.

왜 미안해야 하는 걸까? 퇴식은 도와줄까 생각했으나, 그 장애인은 정리만 해 놓고 그냥 떠났다.

나도 정리하시는 아주머니들이 있어 자리를 떠났다.

스스로 옮기다가 쟁반위의 식기들이 떨어진 선례가 있었는지는 몰라도, 직접 이동시키지 않는 것은 키작은 사람이나, 장애인의 입장을 배려하지 못한 푸드코트의 이기적인 설계를 드러나게 하였다.


불평은 그만하고 가치를 만들기 위해 노력하자.


이전 1 ... 40 41 42 43 44 45 46 47 48 49... 56다음
첨부 (0)
위로