Flat-UI logo

얼마 전에 반짝했던 Flat-UI를 한번 써 보려고 GitHub 저장소를 열어봤다. 이전에 뜯어봤을 때는 지레짐작으로 Twitter Bootstrap을 수정해서 만든 걸로 생각하고, 그러니 코드도 Bootstrap처럼 LESS로 되어 있겠거니 했었는데, 의외로 Sass 파일들이 있는 걸 발견. 혹시 sass-twitter-bootstrap 같은 걸 쓴 건가 했지만, 좀더 뜯어보니 Bootstrap은 그냥 레이아웃 등을 위해 CSS로만 불러오고, 수정된 디자인을 그 위에다 덮어쓰는 식으로 만들어놓은 것 같다.

Bootstrap을 끄고 나니 깨져버린 Flat-UI 예제 페이지의 모습

그렇다고 bootstrap.css 파일을 아예 제외시켜 버리면 이런 일이 발생. 그리드 레이아웃을 조금 고쳐서 쓸 계획이라 Bootstrap에서 레이아웃 관련 코드만 바꿔서 쓸까 생각 중이다.

(Reblogged from xymz)
(Reblogged from clouded-leopard)

If you wish to make an apple pie from scratch, you must first invent the universe

※ 문단 사이에는 순서가 없음.

  • 오래 전부터 머릿속에서만 맴도는 채 종이 위로 올라오지 못하는 세계가 있다. 보통은 비슷한 또래에 다들 비슷한 짓을 시도하는 모양이고, 개중 대다수는 소위 ‘철이 들면서’ 결국 밖으로 꺼내는 걸 포기하거나 심지어 그조차 잊어버리곤 한다. 나도 그러고 있었다고 생각했고, 최근까지 그런 과정을 착실하게 밟아 왔다고 생각해 왔다.

  • 하지만 역설적이게도, 평범하게 먹고 살고 짝을 만나 행복하게 살다 죽는 계획의 일환으로 추진했던 운전면허를 마침내 따낸 오늘, 어쩌다 우연히 집힌 아시모프 단편들을 헤집으면서 묻어뒀던 세계를 다시 들춰내고 말았다.

  • 터무니없는 목표일 수도 있고, 어쩌면 유치한 짓거리일지도 모른다. 먹고 사는 문제에 치여서 결국 제대로 손도 못 댄 채 다시 버려질지도 모른다. 그래서 좀더 현실적인 목표, 예컨데 뛰어난 프로그래머 같은 게 되는 걸 대신 인생의 목표로 삼기도 했다.

  • 철이 없던 시절에는 그 세계를 게임으로 만드는 걸 꿈꿨었지만, 지금 와서 돌이켜보면 터무니없이 비현실적일 뿐더러 만든다고 그렇게 잘 팔릴 것 같지도 않다. 어쨌거나 게임은 영화만큼이나, 아니 그 이상으로 자본 집약적인 산업이니. 그림도 시도해 봤지만 독자한테 납득시킬 만큼의 실력을 키우기엔 지나치게 많은 시간이 들 것 같아서 포기. 게다가 지금 와서 그래봤자 나이트런 짝퉁밖에 더 되겠나.

  • 더군다나 나는 참 글재주가 없다. 비단 글재주뿐만이 아니라 말, 몸짓, 표정 등 대부분의 소통 방법에 대해 매우 소질이 없다. 머릿속에서 그럴싸하게 맞춰진 것처럼 보이는 생각을 글자 쪼가리로 다시 재조립하는 게 그렇게 불편할 수가 없다. 덕분에 글쓰기 자체를 연습할 기회가 매우 부족했고, 보시다시피 개판인 작문 실력을 가지고 말았다.

  • 불행히도 그런 이유로 나는 글을 쓰는 게 매우 귀찮다. 내가 프로그래밍에 흥미를 가지고 아직까지도 계속 붙잡고 있는 이유도 무슨 일을 벌이기 위해 누군가를 붙잡고 똑같은 이야기를 계속 되풀이하는 게 도저히 내 성미에 맞지 않기 때문이다. 근데 그마저도 귀찮아서 나는 여전히 코딩 속도도 무지하게 느리고, 발표자료 만드는 것도, 심지어 여자친구한테 쓸 편지조차 계속 밀리고 앉아 있다.

  • 그래서 지금까지 써 왔던 방법이란 게, 주변에서 아무 정보나 닥치는 대로 끌어와서 머릿속에서 적당히 뒤섞고 짜맞추기를 반복하는 것이었다. 그 와중에 매우 자잘한 편린만이 부산물로 몇 문장 튀어나오고 나머지는 여전히 머리 속에, 대다수는 그러다 그대로 묻히기 일쑤였다.

  • 어쨌거나 내가 만들고자 하는 목표는 결국 세계관이고, 이야기나, 그림, 소스 코드 같은 것은 그걸 표현하기 위한 도구로 간주할 수 있을 것이다. 이 매체를 무엇으로 선택하는지에 따라 표현할 수 있는 규모나 표현력, 거기에 드는 인력과 자본 따위가 결정될 텐데, 소통 능력이 부족하니 내가 이걸 누구와 같이 해보자고 설득하기도 힘들겠고, 기본적인 프로토타입이라도 있어야 뭘 해볼 만 하겠는데, 그럼 결국 개인 규모로 때울 수 있는 정도로 선택할 수 있는 매체가 제한된다. 바로 글이다.

  • 결국 목표가 세계관이니, 그걸 정리할 수 있는 수단이 필요하다. 내가 이 꼬라지인 이상 평범하게 정리할 수 있는 수단으론 부족하다. 그나마 행운인 건, 아이디어를 정리한답시고 두터운 노트를 끼고 다니고, 주인공 이름 하나 바꾸려고 원고지를 마구 헤집을 필요가 없는 시대에 내가 태어났다는 것이다. 문제는 여전히 솔루션이 없다는 것인데, 다행히도 솔루션을 만들 수 있는 능력은 이미 가지고 있다. 심지어 비슷한 꿈을 꾸고 있는 사람들도 알고 있다. 뭔가 실마리를 잡을 수 있을 것이다.

  • 안다. 아이작 아시모프는 17세부터 글을 쓰기 시작했고, 평생에 걸쳐 몇백 권에 달하는 책을 썼다. 아니 굳이 멀리 갈 필요도 없이 평범한 수준의 작가도 나보단 글을 훨씬 잘 쓸 거다. 역시 그냥 프로그래밍이나 하면서 먹고 살아야 하나? 하지만 여전히 못다핀 세계들이, 이야기가, 사람들이 머릿속에서 맴도는 걸 멈출 수가 없다. 적어도 죽기 전까지는 시도해 볼 만한 가치가 있지 않을까? 그래도 나는 아직 만 24세다. 시간은 충분하겠지.

  • 칼 세이건이 말하길, 애플 파이를 처음부터 만들고 싶다면 먼저 우주를 만들어야 한단다. 그럼 우주를 만들기 위해서는 무얼 만들어야 할까?

Brilliant!

littlebigdetails:

SoundCloud - When looking at the console log, you’ll see output for joining their team.

/via gleuch

(Reblogged from littlebigdetails)

Pitfall on the WSGI Middleware in Django

웹 개발에 SCSSCoffeeScript 같은 걸 쓰려고 하면 일일히 SCSS를 CSS로 컴파일하고 있는 게 바보같을 때가 많다. 특정 디렉토리를 계속 지켜보면서 변경된 SCSS 코드를 자동으로 컴파일해 주는 툴 같은 것도 있지만, 일단은 Django를 쓰고 있으니 개발 서버를 돌리는 동안 알아서 SCSS를 컴파일하게 만들고 싶었다. 그게 개발환경 구성하기 더 편하니까.

마침 쓰고 있는 libsass 라이브러리에 sassutils.wsgi.SassMiddleware라는 WSGI 미들웨어가 포함되어 있길래 간단히 적용해 보았다. wsgi.py 파일을 찾아 아래처럼 수정했다:1

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

from sassutils.wsgi import SassMiddleware
application = SassMiddleware(application, {
    'zigm': ('sass', 'static/sass', '/static/sass'),
})

CSS나 JavaScript 같은 정적인 리소스들을 Django 설정의 STATIC_URL에 지정된 대로 /static/ 경로 안에서 제공하게 해 뒀는데, 특별히 /static/sass 경로 아래에 대해서는 SCSS 컴파일러가 작동하게 하려던 거었다. 결과는 아래와 같았다.

Page not found error

이게 뭐야! 혹시나 해서 미들웨어를 이리저리 뜯어 봤지만, 무슨 짓을 해 봐도 저 페이지만은 꿋꿋하게 404 에러를 내뿜었다. 이쯤 돼서 뭔가 이상한 생각이 들기 시작했는데, 심지어 미들웨어를 무조건 뻗게 만들었는데도 404 페이지를 찍어준다는 건 애초에 모든 요청이 저 WSGI 앱을 통해 처리되는 한 말이 안 되지 않은가?

반나절을 날려가며 코드를 뜯어본 결과 내 의심이 맞았다는 걸 확인했다. manage.py runserver를 실행할 때, 정적 파일만을 위한 전혀 별개의 WSGI 앱이 하나 더 돌아간다. 그리고 STATIC_URL에 지정한 경로로 시작하는 요청은 전부 그 전용 WSGI 앱으로만 흘러들어가게 되어 있었다. 따라서 wsgi.py에 있는 application 객체에 아무리 미들웨어를 씌워 봐야 전혀 먹히지가 않았던 것.

정공법으로 뚫어버리는 방법이 있을 것 같긴 한데 일단 접어두고, /static/sass 대신 /static_sass 경로를 쓰는 방법으로 일단 문제를 우회하기로 했다.

오늘의 교훈:

  1. Django에서 /static/을 조작할 목적으로 WSGI 미들웨어를 쓰지 말자. 사실 정적인 리소스들은 production 환경에서도 어차피 Django를 통하지 않을 테니 이게 오히려 맞는 접근법이다.
  2. 정 하고 싶으면 그냥 staticfiles finder 같은 거나 알아보자.2 아니면 차라리 Django 자체 미들웨어를 써보는 게 낫겠다.
  3. 죽어라 Django

P.S: 우회책을 쓰니 새로운 문제가 생겼는데, 이제 {% static %} 태그와 {{ STATIC_URL }} 변수를 쓸 수가 없다. -_-


  1. Django 설정 파일의 WSGI_APPLICATION이라는 항목이 개발 서버를 실행할 때 사용할 WSGI 객체를 지정하게 되어 있는데, 기본값이 보통 이 파일 안의 application 객체로 되어 있다. 물론 변경도 가능하다. 

  2. 문제는, 이거 만드는 방법이 문서화가 안 되어 있다. -_- 

내가 도구 무용론이 잘못됐다고 생각하는 이유가 이런 점에서다. PHP도 잘 쓰면 훌륭한 도구라고? PHP를 잘 쓸 수 있는 능력이 있는 사람은 더이상 PHP를 쓰지 않는다. PHP로 똥을 싸는 사람만이 똥 냄새를 맡지 못하니까 PHP에 눌러앉아 있을 뿐이다. (쉬벌, 인권 영화 찾아가서 굳이 보는 사람들은 인권 영화를 볼 필요가 없고, 봐야할 사람들은 인권 영화를 결코 안 본다는 얘기랑 완전히 똑같다.)
(Reblogged from hongminhee)

해야 할 일은 많고 배워야 할 것은 더욱 많다.
그러니 더 이상 낭비할 시간이 없다.