banana like sunshine RSS FEED

composer를 update 중에 composer가 뻗어버리는 일이 발생하였습니다. 개발용으로 Virtual server를 이용하고 있는데, 아무래도 메모리가 적어서 그런 것 같습니다.

구글링을 해보니, swap 설정을 해주어야 한다고 하니 오늘은 이 척박한(!) 서버에 스왑으로 일단 돌아가게는 해놔야 하겠습니다.

1. 일단 free 명령으로 swap 파일이 있는지 확인부터 해줍니다. :

sudo free -m

위와 같이 swap이 0 0 이 나옵니다.

2. 그러면 일단, 스왑 파일을 생성하겠습니다. 아래와 같이 해주면 4기가 크기의 파일이 생성됩니다:

sudo fallocate -l 4G /swapfile

이렇게 해주면 /swapfile 이라는 4G짜리 파일이 만들어지겠지요.

3. 이제 이 파일을 swap으로 이용하도록 설정하겠습니다. 그 전에 안전을 위해서 생성한 파일의 permission을 root만 읽고 쓸 수 있게 변경하겠습니다:

sudo chmod 600 /swapfile

4. 이제 이 파일을 swap 파일로 인식하게 해주면 되겠습니다.

sudo mkswap /swapfile

이러면 아래와 같이 반응이 옵니다.

5. 이제 swapon으로 스왑 파일을 활성화시키면 됩니다.

sudo swapon /swapfile

-s 옵션을 주면 이제 스왑이 실행되고 있는지 확인 가능합니다.

sudo swapon -s

Laravel에서 form을 이용할 때에는 다음과 같이 array에 주절주절 다 담아서 이용을 합니다:

{{ Form::open(array(
            'method' => 'post',
            'url' => action('PostingsController@store'),
            'class' => 'form',
            'role' => 'form')
            ) }}

method는 당연히 post냐, put이냐를 지정해주면 됩니다.

url은 helper 명령어인 action()이나 route(), URL::to 등을 이용해서 submit 받을 스크립트를 지정해줍니다. submit 도 같은 스크립트가 받을 거면 생략하셔도 됩니다.

class, role 등 추가적인 내용이 있으면 넣어주면 됩니다. 위는 bootstrap3에서 form에 class, role을 'form'으로 지정해야 해서 위와 같이 썼습니다.

The fundamental failure of most graphic, product, architectural, and even urban design is its insistence on serving the God of Looking-Good rather than the God of Being-Good. – Richard Saul Wurman

여러 명의 웹디자이너, 퍼블리셔 분들과 작업해보면서 느낀 점은, tool에 너무 의존하다 보면 웹페이지의 의미구조에 대해 고민하는 분이 적을 수밖에 없겠구나 하는 것입니다. WYSIWYG로 보이는 대로만 작업하다 보면 그렇게 되는 거지요.

그 다음부터는 작업하면서 꼭 문서구조가 어떻게 되는지 중간중간 확인을 해봅니다. 간단하게는 html5.org에서 운영하는 아래 사이트에서 url만 입력해 보아도 알 수 있지요.

https://gsnedders.html5.org/outliner/

심심하면 평소에 잘 설계되었다고 생각하던 사이트들을 넣어보시면서 결과를 비교해보는 것만으로도 많은 걸 느낄 수 있을 것입니다. 브라우저로 보는 게 아니라 검색엔진들이 페이지를 어떻게 보는지 감이 오니까요. 저는 웹툰 보러 들어가던 사이트를 한번 찾아보았다가 예상외로(!) 의미 구조가 FM대로 정확하게 나와있는 걸 보고 깜놀한 기억이 남네요 ㅋㅋ. 내가 이것보다 못하다니 OTL

HTML5에 도입된 semantic structure와 관련된 요소들로는 section, article, aside 같은 것들이 있습니다. 이 요소들로 문서를 구조화 시키거나, div를 이용한 블록들에 h1, h2, h3 만 잘 붙여줘도 결과가 확실히 달라지는 걸 보실 수 있을 겁니다.

SEO는 단지 meta tag 잘 만들고 title 붙이는 수준이 아니라, 기본적인 구조 설계부터 진행이 되어야 하는 것이구나.. 하는 생각을 설계부터 구현까지 계속 지니고 있어야 하는 것 같습니다. 물론 저도 일정에 쫓기고 클라이언트한테 치이다 보면 신경을 못쓰는 때가 많습니다만;;

Eloquent collection으로 작업하다 보면 항상 헷갈리는 부분이 있습니다. 바로 Eloquent model을 이용하는 collection을 불러왔을 때 결과가 비었는지 아닌지 하는 것입니다.

가령 블로그를 만들면서 특정한 $tag을 가지는 포스트들을 아래와 같이 가져오면..

$posts = Post::where('tag', $tag)->get();

결과값이 있는지를 봐야겠지요.. 무의식적으로 아래와 같이 빈 결과인지 아닌지를 체크한다고 해놓고 지나가면 나중에 뭐가 문제인지 모르는 경우가 생깁니다:

if (empty($posts)) { … }

if (!$posts) { … }

if (isset($posts) { … }

이럴 때에는 아래처럼 해주시면 됩니다:

if ($result->isEmpty()) { … }

if ($result->count()) { … }

오늘은 SQL query문 중 기초적인 부분에 대해서 써볼까 합니다. 물론 오늘 한 작업 중 한 가지 소스이지요 ㅋㅋ

DATETIME 필드를 기준으로 현재로부터 6시간 이내에 발생한 record를 불러오는 겁니다.

MYSQL에는 DATE_ADD()라는 함수가 있습니다. 이 함수를 이용하는 거지요.

SELECT * FROM foo WHERE created_at > DATE_ADD(now(), INTERVAL -6 HOUR)

지금 현재 시각 now() 에서 6시간의 INTERVAL을 빼주었으니 현재에서 6시간 이내가 되는 거지요.

HOUR 대신에 MINUTE, SECOND, DAY 등으로 할 수도 있으니 (쓰다 보니 DAY를 이용한 거는 예전에 포스팅을 했던 것 같기도..) 응용해서 쓰시면 됩니다.

파일을 업로드 전송받는 경우 파일 MIME type을 결정해주어야 하는 경우가 종종 생깁니다.

오늘은 이미지를 데이터베이스에 blob으로 넣는 작업을 하면서 클라이언트 요청으로 MIME TYPE도 같이 저장해주도록 하였습니다.

시작하면서는 Fileinfo function이 있으니 별거 아니겠네.. 하였는데 역시나 제가 하는 일은 쉽게 끝나는 법이 없군요. OTL

일단 서버 PHP 버전이 5.2라 Fileinfo 가 이용 불가능한 상태였고, mime_content_type 함수는 depreciated 입니다.

요새 제 프로젝트의 프레임워크로 이용하는 laravel에는 mime type을 guessing하는 부분이 있긴 한데..

오늘은 할 수 없이 업로드되는 파일 확장명을 기반으로 mime type을 리턴해주는 함수를 구글링해서 이용하였습니다:

http://www.brightcherry.co.uk/scribbles/php-alternative-to-the-depreciated-mime_content_type-function-and-fileinfo-functions/

물론 이 방식은 이용자가 전송하는 파일의 확장명을 의심없이(?) 받아들여서 처리하기 때문에 보안상 문제의 여지는 있습니다.

이런 문제를 해결해주는 것이 맞는 것이긴 한데.. 성격상 서버 PHP 버전만 업그레이드 해주면 되는 문제를 굳이 시간을 들여가면서 하고 싶진 않기도 하고.. 어차피 DB에 있으니 보안상 문제는 그나마 조금 덜하니 차라리 DB에서 꺼내주는 과정만 신경을 써주면 되겠구나 하면서 마무리하였습니다.

Laravel과 angularjs를 같이 이용하려고 하다 보니.. laravel의 template engine인 Blade와 angularjs 모두 이 double curly braces를 이용하는 문제가 있네요. ㅋㅋ

이럴 때에는 blade의 template에서 angularjs의 {{ }} 를 이용할 때 앞에 @를 붙여주면 간단히 해결됩니다. 아래처럼 말이지요.

@{{ 앞에 @가 있으면 blade가 치환을 안합니다  }}

오늘은 간단한 명령이지만 정작 쓰려면 긴가민가 하는 명령을 하나 설명드립니다.

서버를 운영하다 보면 (따로 관리자 없이) 로그파일이나 더이상 이용하지 않는 임시 파일들이 많이 생깁니다. 저 같은 경우는 네이버 신디케이션을 이용하면서 네이버쪽에 ping 요청하면서 신디케이션 문서를 xml로 생성해 놓는데요, 몇 천개를 하다 보니 ping 요청을 한다고 중국집 마냥 바로 와서 가져가는게 아니니 서버에 계속 쌓이게 되더군요. 생각없이 있다가 디렉토리를 보니 파일이 너무 많아졌습니다. -_-;;

삭제를 하려고 해도 이게 네이버에서 가져간 건지 아닌지 모르니 - 경험상 며칠씩 걸리는 경우도 있더군요 - 10일 정도 기간을 두고 그 이전 xml 파일만 삭제할 필요가 생겼습니다.

이럴 때에는 아래와 같이 하면 됩니다 :

find *.xml -mtime +10 -exec rm {} \;

find 명령은 다들 아시지요? 첫번째 인수는 디렉토리 이름이나, * 등 아무거나 들어가도 됩니다.

두번째 인수 -mtime은 기간을 일 단위로 정해줍니다. 한 달로 하려면 -mtime +30 하면 되겠지요.

세번째 -exec는 다음 명령으로 전달하는 부분입니다. 저는 삭제를 하려고 하니 rm 명령어를 이용하겠습니다. 그 뒤에 나오는 {} 과 \; 는 꼭 입력해주셔야 합니다.

Update: 명령이 실행된 파일들을 보고 싶으시면 -print 옵션을 추가하시면 됩니다.

find *.xml -mtime +10 -print -exec rm {} \;

지난번에 '키위'라는 네이버와 다음 블로그 검색 순위를 보여주는 서비스에 대해서 포스팅을 하였었습니다.(네이버와 다음 블로그 검색순위)

처음 써본지 3주 정도 되어 가는 것 같은데, 이 시점에서 키워드 랭킹에 대해서 잠시 살펴보고 싶어졌습니다.

사실 새로 포워딩을 하면, 처음부터 상위 검색 순위에 머무르면서 동시에 유입도 잘 해주는 효자 키워드가 있습니다. 그런 경우 갑자기 유입 경로에서 상당 부분을 차지해주면서 기분이 좋다가, 어느 정도 시간이 지나가면 유입이 점점 줄어들어 마침내 아예 없어지게 됩니다. 한마디로 수명이 다한 키워드가 되는 거지요.

이 수명을 관리는 못하더라도, 관심을 가지고 계속 봐주면 좋을텐데.. 맨 처음에 포스팅 올리고는 몇 등하지? 하고 찾아보고 할 때만 한번씩 찾아보지, 그 다음에는 유입량이 줄면 등수가 떨어졌나 보구나 하는 정도로 무관심해지지요. 그래서 이 '키위'라는 서비스를 이용하게 되었습니다.

검색 랭킹 변동을 살펴보니 상당히 다이나믹하네요. 한달도 안되는 사이에 상위권에서 100등 밖으로 사라져버리는 키워드도 있고, 상위권을 꾸준히 유지해주는 검색어도 있습니다. 물론 키워드에 대한 검색 경쟁이 얼마나 심하냐 같은 것도 무시 못하겠지요.

아래는 방금 제가 관심 가지고 포스팅하였던 글들의 검색 순위 변동 그래프입니다:

검색 1위를 차지하는 포스팅은 꾸준히.. 잠시 2위로 떨어졌다가 다시 1위를 탈환하였고.. 그다음 포스팅은 널을 뛰고 있습니다. ㅋㅋ

살펴보니 아.. 정말 키워드가 수명이라는게 있구나, 하는 생각이 드네요. 저야 블로그로 먹고사는 게 아니지만 기왕이면 정성껏 쓴 글이 많은 사람들에게 보여지면 좋겠다는 생각입니다. 제 독자적인 영역도 만들어 보고 싶고.. 시간이 되면 조금 더 연구를 해보아야겠습니다.

php라는 언어 자체가 상당히 헐렁(loose. 비하는 아님)한 언어이기 때문에 편하기도 하지만, 가끔 가다가는 결과값이 어떻게 올지 불확실할 수 있다는 점 또한 받아들여야 하는데.. 삽질 열심히 하다 원인을 알게 되면 너무 허무합니다.

오늘의 삽질은.. 처음에 손대면서는 30분이면 되겠지 하고 시작한 처음은 미미하였던 일이.. 시간이 지나면서 해결도 안되고 점점 창대해지는 사태를 거치는 상황이었습니다.

요는. array_unique를 써서 array 내의 중복값을 없앤 다음에 json_encode로 다른 app에 넘겨주면 끝나는 일이었습니다.

뭐 간단하네. 요거만 하고 자야지 했는데 이게 왠걸;; 어디서 났는지 모를 에러들이..

원인을 찾아보니 array_unique로 정리를 할 때, 그냥 예쁘게 이렇게 되는 걸 바랬는데 :

['Series A', 'Series B']

가끔 가다 그렇게 안되고 이렇게 되고 마는 것입니다.

[{"0":"'Series A","1":"Series B"}]

뒤져보다 보니, array_unique로 중복값을 정리하면서 어떤 경우에는 숫자로 인덱싱된 array가 남지 않는 경우가 생긴다는 거였습니다. 즉 json_encode해주면 위의 경우처럼 숫자 인덱싱이 남아버리는 거지요. ㅡ.ㅡ

원인을 알고나니 방법은 의외로 간단히..

json_encode 해주기 전에 array_values로 numerically indexed array를 강제로 만들어주는 것으로 해결되었습니다.

array_values(array_unique($data))

php를 다시 한번 돌아보게 해주는 하루였습니다. ㅋㅋ