Move to Octopress!

2014. 7. 14. 01:33 from 카테고리 없음

기존에 티스토리에서 운영 중이던 프로그래밍 관련 블로그(devnote.tistory.com)를 Octopress로 이사합니다. 사실 운영이라고 말하기도 뭣할 만큼 오랫동안 방치되어 있었는데, 다시금 분위기를 쇄신하고자 환경을 바꿔볼까 합니다.

기존 블로그를 feedburner 주소로 구독 중이었다면 새로운 블로그로 자동으로 넘어갑니다. 하지만 티스토리 기본 rss 주소를 사용 중이었다면, 이 참에 feed-burner로 갈아타 주세요 ‘ㅁ’)/

feed burder address : http://feeds.feedburner.com/florist_devnote

Octopress는 기존과는 다른 형태의 static engine이라서 호감이 갑니다. 맘에 드는 점을 몇 가지만 꼽아보면

  • vim으로 글을 적을 수 있다는 것
  • 본문 글이 로컬에 text(markdown)파일로 남는 다는 점
  • 블로그 주소에 github.io를 쓴다는 것
  • 기본적으로 큰 글씨를 사용하는 시원한 테마들.

… 등입니다. markdown으로 글을 적게 된다면 하루패드를 사용해야 겠다고 생각했었는데, vim으로 적는 게 더 느낌이 좋네요 :) vim을 무척 잘 쓰는 편은 못되지만, octopress덕에 git이나 vim을 자주 접하게 되면 좀 더 익숙해 지는 계기가 될 테니 그런 점도 마음에 듭니다.

그 외 나머지 추가 기능이나 설정 같은 건 아직 제대로 모르는 상태이지만, 하루 이틀 미루다 보면 너무 늘어져 버릴 것 같아서 우선 이사 공표(?)부터 내지릅니다.

집에 애가 생기고 난 후부터는 개인 시간이 많이 줄어들면서 블로그에도 소홀해지게 되었는데, 앞으로는 굳이 테크니컬한 내용의 글이 아니더라도 개발에 관련된 소소한 글들도 올릴 생각입니다. 이를테면 기계식 키보드에 대한 이야기라던가… 하는 것도요. (글쓰기 연습을 위해서라도 무엇이든 꾸준히 글을 좀 적어야겠다는 개인적인 욕망(?) 때문입니다.)

앞으로 여러 가지 글들 종종 올리겠습니다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요



오늘 모처럼만에 휴가를 내고 집에서 코딩하며 놀고 있다.

작년 말에 처음 시작해서 찔끔찔금 진행하던 티스토리 –> octopress 컨버터를 다시 붙잡고 있었는데, 결국 실패를 선언했다 ㅠㅠ…

작년에 octopress같은 정적(static) 블로그 엔진을 처음보고 호감이 생겨서, 지금 쓰는 블로그(devnote.tistory.com)을 통째로 컨버팅해서 이사 가려고 했는데, 검색을 해봐도 이사를 지원하는 도구가 없길래 직접 만들기로 결심했었다. 컨버터는 더딘 속도지만 조금씩 만들어 나갔고 소스코드와 문서를 수시로 정리해 github에 관리했다.  수백 메가짜리 무식한 xml 백업파일을 일일이 눈으로(...) 파싱해서 문서 구조를 파악하고, 포스팅 본문, 댓글, 첨부파일까지 모두 읽어서 추출해 낸 후 octopress가 읽을 수 있는 폴더 구조와 형식으로 출력했다. 이제 거의 막바지에 이르러 실제로 포스팅 된 글들을 검토하는 단계에까지 이르렀으나.. 티스토리에 올라가 있는 갖가지 케이스의 HTML 본문들을 예쁘게 잘 정리된 markdown 형식으로 일괄 자동 변경하는 것이 쉽지 않겠다는 결론을 내렸다. 아~! 이래서 처음에 구글에서 변환 툴 검색해봤을 때 없었나 보다~! 싶음…;;

티스토리는 그리 나쁘지 않은 블로그 엔진이지만 소스코드를 쉽게 올리거나 읽기 좋게 mark-up하기가 까다롭다는 점이 개인적으로 느끼는 아쉬움이다. 그래서 지난 수년간 포스팅에 소스코드를 올릴 일이 있을 때는 이것 저것 여러 가지 플러그인들을 돌아가며 사용해 왔는데, 아마 그 종류만 해도 7~8가지는 될거다. 이게 이번에 컨버팅 할 때에도 큰 장애사항이었는데, 티스토리는 본문을 html 문서 형태로 저장하기 때문에 서로 다른 플러그인들이 뱉어낸 mark-up결과물만 해도 백업을 까보면 그 방식들이 모두 천차만별이다.

그래도 그 동안 컨버터를 짜보면서 겪었던 몇 가지들을 정리해 보자면

  1. pandoc의 존재를 알게 됨 : 아마 이런 식의 문서 포맷 변환 작업을 해 본 사람이라면 pandoc을 알고 있을 듯. 특정 문서 포맷을 다른 포맷으로 바꾸어주는 프로그램인데, 무료로 오픈되어 있어 사용이 자유롭다. 사이트에 가보면 지원하는 입력 포맷 & 출력 포맷을 표시한 state transition diagram이 있는데, 보면 깜놀할 것이다. 사실 Tistory Convertor도 pandoc의 변환 능력을 믿고 시작한 프로젝트였지만… pandoc이 출력하는 markdown_github 포맷은 octopress에서 인식하지 못하는 확장 문법도 몇 가지 있고 해서 결국 gg.
  2. C# TPL : 요 앞 프로젝트에서도 써먹어본 C#의 병렬 처리 라이브러리. 가벼운 툴 정도는 손쉽게 멀티 스레딩으로 전환할 수 있어서 좋다.
  3. 하루패드를 알게 됨 : markdown 문서를 제작하기에 아주 좋은 툴이다. 지금은 블로그에 글을 쓸 때 tistory + windows live writer를 쓰고 있지만, octopress로 넘어가면 하루패드가 메인 저작 도구가 되지 않을까 함.
  4. antlr의 string template : 강력한 템플릿 엔진이다. 오리지널은 java로 만들어졌지만 c#으로 포팅된 버전도 아주 쓸만하다. 예전에 회사에서 패킷 파일 제네레이터 만들 때 적용해보고 아주 만족스러웠는데, 이번에 컨버터 만들 때는 그리 많이 쓰진 않았음. 한 번은 정식으로 소개 포스팅을 하고 싶을 만큼 좋은 라이브러리.
  5. 티스토리 백업으로 받는 통짜 xml파일의 구조 파악 : 티스토리 백업은 xml파일로 되어 있는데, 여기에 본문이며 댓글, 첨부파일까지 모두 짬뽕되어 들어있다. 이 파일을 받아도 다시 tistory로 복원하는 것 말고는 직접 읽거나 검색하는게 불가능에 가까워서 마치 압축 못 푸는 zip 파일같은 느낌이랄까. 그래도 이번 컨버터 작업하느라 순수 100% 근성으로(...) 문서 구조를 분석해서 정리해 둔 건 이번 프로젝트의 가장 큰 수확이다. 티스토리가 문을 닫아도 기존의 글들을 최소한 로컬에서 ‘읽을 수 있는 파일’로 백업할 수는 있게 되었다.

… 이 정도 일듯. octopress로 바꿔서 올리는 것 까지는 실패했지만 지금까지 진행된 컨버터는 조금 우회해서 그냥 백업 xml을 로컬에서 읽기 좋은 개별 html 파일로 풀어주는 decoder 수준으로만 정리하고 다른 코딩거리로 넘어가야겠다.

Posted by leafbird 트랙백 0 : 댓글 2

댓글을 달아 주세요

  1. addr | edit/del | reply Favicon of https://devnote.tistory.com BlogIcon leafbird 2014.07.04 23:05 신고

    이렇게 된 이상 기존 글은 놔두고 octopress로 간다.

  2. addr | edit/del | reply BlogIcon zelin 2014.07.06 16:34

    ㅋ 아쉽네. 나도 관심있었는데...

백업한 사진을 보기가 불편하다

image

(퍼온 이미지임. 내 폰 상태는 이렇게 심플하지 않다.)

아이를 가진 아빠가 되고 나서 휴대폰 카메라를 사용하는 일도 전보다 더 많아졌다.

휴대폰의 메모리 용량은 그리 넉넉하지 못한 편이기 때문에 가끔씩 데스크탑으로 백업한 후 비워주어야 한다. 헌데 미디어 파일들을 복사하면 정말 복사만 될 뿐이지, 파일이 전혀 정리되어 있지 않아서, 나중에 찾아보기가 힘들다는 단점이 있다. OS X와 함께 PhotoStream을 사용한다면 더 근사한 방법이 있는지는 잘 모르겠는데, 윈도우 에서는 달리 대안이 없는 듯.

image

데스크탑으로 복사하면 왼쪽 스샷처럼 정체 모를 이름의 폴더에 파일이 생성된다. 폴더 이름은 iOS 내부에서 사용하는 hash 값? 일 듯 하지만 윈도우로 복사해온 이상 크게 의미가 없다. picasa같은 프로그램을 사용하면 폴더가 어떻게 되어있건 상관없이 날짜 분류를 할 수 있겠으나, 다른 프로그램을 쓰지 않고 윈도우 탐색기 만으로도 어느 정도 파일 분류가 가능하면 좋겠다는 생각이 들었다. 백업을 하더라도 파일을 찾아보기가 힘드니까 사진을 찾아보는 것도 꺼려지게 된다.

처음엔 수작업으로 사진 파일을 분류해 봤다

그래서, 이 미디어 파일들을 찍은 날짜 별로 정리해보자고 마음먹었다. 뭐 어차피 나중에 다시 보려고 찍은 사진이니 감상도 할 겸 하나하나 정리해 보자. 사진을 하나 열어보고, 폴더를 만들고, 옮기고, 다시 다른 것 열어보고, 만들고, 옮기고, … 열어보고…, 만들고…, 옮기고…

image

처음 한두 번 정도는 할 만 했다. 그래 이 날은 참 즐거웠어.. 이 때는 정말 고생했지.. 사진으로 찍어두길 잘했어 하하.. 이러면서 한참을 작업하고 보면 정리한 파일은 겨우 전체 분량의 1~2% 정도 될까 한 수준. 게다가 내 폰 사진 정리가 끝나면 와이프 폰도 하려고 했는데… 아 참 아이패드로도 사진 찍은 게 좀 있지…이 생각을 하니 앞이  깜깜해졌다.

그래서 차라리 파일 정리를 자동화 해주는 툴을 짜기로 결심한다.

사진을 분류해주는 툴을 만들어서 돌려보자

언어는 윈도우 프로그래밍에 가장 무난한 C#을 사용했다. 예전에 비슷한 동작을 하는 툴을 한 번 짠 적이 있었는데, 그 땐 간단하게 만든다고 그냥 싱글스레드로 돌렸더니 CPU는 많이 노는데 실행 시간이 너무 오래 걸렸던 적이 있었다. 그래서 이번에는 멀티 스레딩으로 처리하기 위해 TPL(Task Parallel Library)의 Parallel.ForEach를 이용했다.

카메라로 촬영한 사진에는 Exif 메타 데이터를 읽으면 촬영 날짜를 확인할 수 있는 걸 알고 있었지만 동영상 파일에도 이런 메타 데이터가 있다는 걸 이번에 알았다. 파일 수정날짜로 우선 분류해보고 잘 안되면 mediainfo라는 라이브러리를 써보려고 했는데,  다행히 수정날짜 만으로 적당히 나쁘지 않게 동작해서 그냥 패스. 사진의 exif를 읽는 건 검색해서  적당한 방법을 긁어와 사용했다.

이렇게 사진, 동영상을 날짜 기준으로 한 달치씩 모아 한 폴더에 넣고, 다시 1년치의 폴더를 따로 묶어 보았더니 제법 마음에 들게 정리 되었다.

image

이렇게 쉽게 끝날 것을.

약간의 메모 - TPL

C#에서 멀티스레딩 처리를 해본 것이 처음이었는데, TPL은 정말 심플하고 사용하기 쉬워서 인상적이었다. C++에서 스레딩 처리를 위해 작성해야 하는 코드들과 비교해 보자면 정말 깔끔하다.

처음엔 스레드간 job passing을 위한 큐로 IOCP를 사용하려고 했는데, 아주 당연하게 있을 거라고 생각했던 IOCP API가 C#에 없었다. 대신 ThreadPool이 이 역할을 대신 해주고 있어서 써봤는데 잡다한 것 신경 쓸 필요 없이 job만 던져 넣으면 알아서 실행해주니 무척 편리하다. 요청한 모든 job이 끝났는지 확인해서 다음으로 진행하는 thread join 처리만 조금 신경 써주면 되었다.

그러다가 Parallel.ForEach도 괜찮아 보여 분산처리를 이것으로 다시 변경했다. 정말 감동이었다. 이건 join조차 신경 써줄 필요가 없다. 그냥 For루프 만들듯이 코딩 할 뿐인데 잡다한 분산처리 노가다가 알아서 다 되니 거의 손 안대고 코 푸는 느낌이다.

물론 VC++에도 ThreadPool도 있고 parallel for loop도 있다. ThreadPool은 비스타 부터 win32 api 자체에 지원되기 시작했고, PPL을 사용하면 parallel for도 쓸 수 있다. 헌데 C++로 만드는 프로그램이라면 왠지 정석대로 win32 Thread를 직접 생성/관리 해주어야 할 것 같은 느낌적인 느낌이 있어서 좀 꺼려진다. 개발 언어가 C#이라면 그런 부담감이 좀 덜함.

성능에 크게 민감하지 않으면서 병렬처리가 필요한 코드를 짜야 한다면 C#의 TPL을 쓰는 게 좋겠다. 나중에 기회가 되면 좀 더 제대로 써먹어 봐야지.

 

활용

파일을 정리한 것과 다소 개연성은 좀 떨어지지만(…), 이제 이렇게 정리된 사진 파일을 Synology Nas에 넣는다. 그러면 백업 후 파일을 모두 날려버린 휴대폰에서도 문제없이 사진을 볼 수 있고

Screenshot_2014-05-09-13-12-00

웹에서도

image

TV에서도 똑같이 사진을 볼 수 있게 되었다.

20140509_071622

20140509_071655

사진을 찍을 때마다 백업하고 정리하는 것이 부담이었는데 이제는 툴을 만들어뒀으니 부담 없이 애기 사진 열심히 찍어야지.

IMG_2500

2014년 4월. 신구대 식물원. 1년 전 꼬맹이와 함께.

'잡담' 카테고리의 다른 글

아이폰에서 백업한 사진, 동영상을 정리해보자  (0) 2014.05.07
WikidPad  (0) 2014.04.11
화살표 주석 달기  (0) 2013.12.24
자료 정리  (0) 2013.11.18
최근의 장난감  (0) 2013.06.12
chocolatey  (0) 2013.03.20
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

WikidPad

2014. 4. 11. 20:26 from 잡담

image

얼마 전 승훈이형 블로그에 갔다가 WikidPad라는 걸 알게 됐는데, 잠깐 사용해보고 아주 마음에 들어 적극 사용하기로 마음먹었다.

WikidPad는 그냥 데스크탑 어플리케이션 형태로 돌아가는 위키 엔진이다. python으로 만들어서 exe로 랩핑만 되어있다. 별도의 웹서버가 필요하지도 않고, DB같은 걸 셋팅할 필요도 없다. 글은 내가 작성한 형태 그대로 텍스트 파일로 저장된다. 글 편집 모드와 읽기 모드의 전환도 엄청나게 빨라서 무척 마음에 든다. 단축키가 잘 붙어있어서 글 적는 중간 중간 포매팅을  preview하기도 쉽다.

public internet에 공개할게 아닌 개인 자료라면 WikidPad에 글을 적고, 이렇게 생성된 로컬 파일을 DropBox나 Google Drive같은 클라우드 솔루션에 넣어 보관하면 개인 컴퓨터 에서만 공유되는 환경을 쉽게 만들 수 있다. 나는 WikidPad + Synology Nas의 조합으로 사용 중.

프로그래밍 관련 개인 자료를 정리하는 솔루션을 moniwiki에서 phpbb로 옮긴지가 얼마 안되었는데, 이걸 다시 WikidPad로 이사 중이다(…). phpbb는 데이터를 mysql에 담는 것이 좀 불만이었기 때문에 안 그래도 다른 솔루션을 찾고 있는 중이었다. 마땅한 녀석이 없으면 octopress로 작성하고 bitbucket에 넣으려고 했는데, WikidPad를 써보니 내가 하려했던 구성보다 훨씬 간편하고 심플하게 처리가 가능하다. (승훈이형 쌩유!)

WikidPad는 글이 그냥 plain text 형태로 저장되니까, 나중에 또 다른 솔루션으로 다시 갈아탄다고 하더라도 포팅을 자동화하기도 쉽다. MySql에 있는 것도 자동으로 포팅 하려고 하면 물론 툴을 짜서 돌릴 수야 있겠으나 그쪽 도메인은 좀 생소해서 꺼려지는데, 윈도우 폴더 안에 남는 텍스트 파일이라면 그까짓 것 손에 익숙한 C#으로 손쉽게 스윽 만들 수 있겠지.

현재 공식페이지에 올라온 stable version은 2.2인데, Windows 8에서는 제대로 호환이 안 되는 것 같다. 베타버전인 2.3을 설치하면 Windows8에서도 무난하게 사용할 수 있다.

사실 개인자료(wiki)와 공개형 자료(blog)모두 plain text 형태의 솔루션으로 이사하고 싶은데, 여기 이 devnote 블로그는 octopress로 이사하려고 생각 중이다. 그래서 C#으로 데이터 컨버터를 조금 만들어보다가 말았는데, 조만간 다시 재개해서 완성하려고 한다. 컨버터가 완성되면 블로그도 이사하고, 툴 제작 후기도 포스팅할 예정. 언제가 될지 모르겠으나 그 날이 하루빨리 오기를 바란다;;

'잡담' 카테고리의 다른 글

아이폰에서 백업한 사진, 동영상을 정리해보자  (0) 2014.05.07
WikidPad  (0) 2014.04.11
화살표 주석 달기  (0) 2013.12.24
자료 정리  (0) 2013.11.18
최근의 장난감  (0) 2013.06.12
chocolatey  (0) 2013.03.20
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

일전에 이 블로그에서 Interlocked Singly Linked List(이하 SList)를 소개하는 포스팅을 한 적이 있다. 윈도우 XP 버전부터 지원된 기능이지만 존재 사실을 뒤늦게 알고 블로그에 적어두었다.

그리고는 그 바로 다음 포스팅으로 ABA Problem에 대해 정리하면서, SList도 ABA문제에 대한 대비가 되어 있지 않으니 사용할 때 주의해야 한다고 적어놓았다. 하지만 내용이 틀렸다. SList는 ABA문제를 내부에서 자체 방지하도록 처리되어있으므로 사용하는 입장에서는 신경 쓸 것이 없다.

변명을 좀 하자면 처음에 잘못 알고 있게 된 계기는 GPG Study의 락프리 관련 스레드에서 읽은 내용 때문이다. 스레드 가장 하단에 어느 분이 SList를 소개하면서 아래처럼 적어두셨기 때문.

…Windows API 중에 최근에 추가된 다음 API는 Lock-Free로 구현된 Single Linked List를 제공합니다. 그런데 Lock-Free에서 악명 높은 문제 중의 하나인 ABA 문제로 인해 범용 linked list로 사용하기 어려운 제약사항을 가지고 있습니다…(후략)

그래서 정말 위의 말이 사실인지 MSDN을 열심히 찾아봤었지만 ABA문제에 대한 언급을 찾지 못했다. 그래서 위에 인용한 말을 그대로 믿고 있었는데 – 사실 저도 피해자 입니다 ㅜㅜ – 우리 팀에서 SList를 아주 요긴하게 잘 사용하고 있어서 이 물건이 ABA 걱정 없이 사용 가능하다는 걸 알게 되었다 ㅎ 그러고는 블로그에 잘못된 정보를 올려놓은 게 마음이 쓰여서 정정 포스팅을 해야겠다고 마음먹은 지는 한참이 지났건만 이제야 글을 올린다…;;

꼬꼬마 시절의 몇 년 전에는 MSDN 안에서만 조금 뒤적이다가 포기했지만 구글에서 다른 글들을 검색 해보면 SList를 야무지게 잘 사용하고 있는 많은 사례들을 찾을 수 있다. 그리고 레이몬드 첸의 The Old New Thing에서는 보다 확실한 증거를 찾을 수 있는데, SList 사용시의 제약사항인 메모리 정렬이 32bit와 64bit간에 서로 다른 이유에 대해 적은 포스팅 Thy are the alignment requirements for SLIST_ENTRY so diffrent on 64-bit Windows?를 보면 아래 내용이 나온다.

Why are the alignment requirements greater than the natural word size? To avoid the ABA problem. A standard workaround for the ABA problem is to append additional information (a "tag") to the pointer so that when the value changes from B back to A, the tag ensures that the second A still looks different from the first one…(후략)

글 자체의 주제는 지금 내가 하려는 말과는 조금 다르지만, 아무튼 ABA 현상의 해결을 위해 여분의 공간을 사용해야 하고, 이 때문에 MEMORY_ALLOCATION_ALIGNMENT크기로 정렬을 해야 한다는 말이 나온다.

이 블로그를 착실히 읽는 사람이 얼마나 있겠냐 만은 혹시나 예전에 내가 잘못 적어둔 내용 때문에 SList의 사용을 망설이고 있는 사람이 있다면 이젠 걱정 없이 마음 껏 쓰시라. 구글링 해보면 주로 나오는 활용 사례는 스레드 이슈가 많은 IOCP 워커 부분이라든지, 커스텀 메모리 할당자 구현 등이다. 앞에서 말했듯이 지금 회사에서 짜는 코드에서도 잘 써먹고 있음. 메모리 정렬을 신경 써 주어야 하는 게 조금 까다롭지만, 그것만 조심하면 lockfree 자료구조를 얻는 셈이니 그리 나쁘지 않은 흥정이다.



Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

image

얼마 전에 개인 자료 정리 솔루션을 moniwiki에서 phpbb로 이동했다. 개인자료라고 해봐야 대단한 것은 없고 위에 붙인 스샷처럼 간단한 고등학교 수학 수식 따위 들인데, 그냥 인터넷에 공개되는 블로그에 적어두기엔 너무 쉬워서 민망한 수준의 자료들(...)이 주를 이룬다.

그런데 phpbb에는 기본으로 수식을 표현할 수 있는 기능이 없어서 다른 방법을 구글링 해봤지만 마땅한 대안이 없었다. 몇가지 돌아다니는 코드들이 있어서 두어개 적용해 봤지만 제대로 동작하는 놈이 없음…;; 좀 더 찾아볼까 하다가 관두고 그냥 직접 적당히 기존의 플러그인을 수정해서 붙였다.

latex 문법을 수식으로 직접 렌더링해주는 엔진을 서버사이드에 cgi로 붙이거나(mathtex) 브라우저의 javascript로 붙이는 방법(MathJax)도 있는데, 애기아빠 유부남은 이런데 오래 쓸 시간이 없으므로 그냥 수식 렌더링은 외부의 엔진(texify)을 이용하고 링크만 하도록 했다. 엔진까지 로컬에서 포함하도록 바꾸어서 깃허브에 올려야지 생각했지만 그럴 시간도 없고.. phpbb에 그만큼이나 공을 들여야 하는 필요성도 느끼지 못해 그냥 여기서 중단. 다만 개인적으로 쓸 phpbb의 유지보수 시점을 위해 수정 사항을 블로그에 기록해 둔다.

동작 방식과 설치 방식은 googlecode에 있는 phpbb-latex 플러그인과 똑같다. 다만 렌더링 엔진만 texify로 바뀌어서 동작한다.

설치방법:

phpbb/includes 경로에 아래의 코드를 phpbb-latex.php라는 이름으로 집어넣는다.

<?php

    preg_match_all("/\[tex\](.*?)\[\/tex\]/si",$message,$tex_matches);
    for( $i = 0; $i < count($tex_matches[0]); $i++ ) 
    {
        $equation_org = '\LARGE\!'. html_entity_decode( $tex_matches[1][$i] );
        $equation_org = 'http://www.texify.com/img/'.rawurlencode($equation_org).'.gif';
        $equation_org = '<img border="0" src=" . $equation_org . " align="center" />';
        $message = str_replace( $tex_matches[0][$i], $equation_org, $message );
    }
?>

그리고 같은 경로의 bbcode.php를 열어 bbcode_second_pass(…) 함수의 가장 아래쪽에 파일 인클루드를 넣어준다.

include( './includes/phpbb-latex.php' );

그러면 posting 페이지에서 [tex]…[/tex] 문법을 이용해서 수식을 작성할 수 있는데, 좀 더 편하게 입력하려면 관리자 메뉴 POSTING>BBCodes 에서 tex 버튼을 하나 추가해주면 편하다.

    • BBCode usage : [tex]{TEXT}[/tex]
    • HTML replacement : [tex]{TEXT}[/tex]
    • Help line : [tex]{TEXT}[/tex] : using latex.
    • Settings : Diaplay on posting page 항목에 체크.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

며칠 전에 zelon님과 함께 코드리뷰를 하다가 vector의 capacity에 대한 이야기가 나왔는데, 재미있는 일이 있었다. 지난 수년간 나는 vector의 capacity를 줄이기 위해서 clear() 함수 대신 resize(0)를 사용하고 있었는데, 내가 잘 못 알고 있었던 것.

나는 clear()는 데이터만 삭제할 뿐 내부 버퍼로 사용하는 메모리는 유지되는 반면 resize(0)는 버퍼까지 모두 정리하는 것이라고 말했는데, zelon님은 내가 반대로 알고 있다고 말했다. 그래서 누가 맞는지를 검색해보자고 찾아봤더니… 둘 다 틀렸음 ㅋㅋㅋ 결론적으로는 두 함수 모두 버퍼를 줄이지 않는다.

ESTL의 챕터 17에서 이에 대한 설명을 찾아볼 수 있다. 그리고 capacity를 사이즈에 맞게 줄일 수 있는 트릭을 제시하고 있는데,

vector<Contestant>(contestants).swap(contestants);

그리 쉽게 눈에 읽히지는 않는다.

헌데, C++11에서 capacity를 줄일 수 있는 새로운 인터페이스 shrink_to_fit() 이 추가됐다. vs2010에서는 ESTL과 동일하게 임시객체를 써서 구현되었다고 하는데, vs2013은 구현도 약간 다르다.

void shrink_to_fit()
{	// reduce capacity
	if (_Has_unused_capacity())
	{	// worth shrinking, do it
		if (empty())
			_Tidy();
		else
			_Reallocate(size());
	}
}

늘어난 버퍼를 줄이고 싶다면 resize()로 먼저 데이터 크기를 줄인 후, (혹은 clear()로 데이터를 비운 후) shrink_to_fit()을 호출해준다.

int _tmain(int argc, _TCHAR* argv[])
{
	std::vector<int> vecData;

	const int max_size = 10000;
	vecData.reserve(10000);

	for (int i = 0; i < max_size; i++)
	{
		vecData.push_back(i);
	}

	vecData.resize(200);
	vecData.shrink_to_fit();

	return 0;
}

'프로그래밍 팁 > C++' 카테고리의 다른 글

vector::shrink_to_fit  (0) 2013.12.24
Reconstructing parameters from x64 crash dumps  (0) 2013.07.17
x64 Stack Frame layout  (0) 2013.07.04
x64 Calling Convention  (0) 2013.07.04
Faux variadics  (0) 2013.06.21
type traits  (0) 2012.02.14
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

화살표 주석 달기

2013. 12. 24. 09:31 from 잡담

얼마전에 트위터에서 센스넘치는 주석 스샷을 본 적이 있는데,

완전 참신하다. 여태 십 년 동안 프로그램 짜면서 이런 주석은 처음 봤어.

그래서 오늘 나도 한 번 따라해봄 ㅎ

image

화살표 몸통은 한글 ㅂ 에서 한자키 눌러서 찍은└ 과 ─ 의 조합이다. 트윗에서 본 것처럼 적는건 너무 거창하고 힘들어 보이는데, 이 정도면 적당히 보기도 좋고 괜찮지 않나?

'잡담' 카테고리의 다른 글

아이폰에서 백업한 사진, 동영상을 정리해보자  (0) 2014.05.07
WikidPad  (0) 2014.04.11
화살표 주석 달기  (0) 2013.12.24
자료 정리  (0) 2013.11.18
최근의 장난감  (0) 2013.06.12
chocolatey  (0) 2013.03.20
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

모음 + 한자키 특수문자 표

2013. 12. 24. 09:22 from 기타

#&*@§※☆★○●◎◇◆□■△▲▽▼→←↑↓↔〓◁◀ ▷▶♤♠♡♥♧♣⊙◈▣◐◑▒▤▥▨▧ ▦▩♨☏☎☜☞¶† ‡↕↗↙↖↘♭♩♪ ♬㉿㈜№㏇™㏂㏘℡ ªº
─│┌ ┐┘└├ ┬ ┤ ┴ ┼ ━┃┏┓┛┗┣ ┳ ┫┻ ╋┠ ┯ ┨┷ ┿ ┳
ⅰⅱ ⅲ ⅳ ⅴ ⅵ ⅶ ⅷ ⅸⅹⅠⅡⅢ ⅣⅤⅥ Ⅶ Ⅷ Ⅷ Ⅸ Ⅹ
+-<=>±×÷≠≤≥∞∴♂♀∠⊥⌒∂∇≡≒≪≫√∽∝∵∫ ∬∈∋⊆⊇⊂⊃∪∩∧∨¬⇒⇔∀∃∮∑∏
스페이스 !',./:;?^_`| ̄、。·‥…¨〃­―∥ \∼´~˘ˇ˝˚˙¸˛¡¿ː
㉠㉡㉢..㉭ ㉮㉯㉰...㉻ ㈀㈁㈂...㈍ ㈎㈏㈐...
"( )[ ]{ }‘’“ ”〔 〕〈 〉《 》「 」『 』【 】
ⓐⓑⓒⓓⓔⓕ...ⓩ ①②③④⑤...⑮ ⒜⒝⒞...⒵ ⑴⑵⑶..⒂
$ % ₩ F ′ ″ ℃ Å ¢ £ ¥ ¤ ℉ ‰ ㎕ ㎖ ㎗ ℓ ㎘ ㏄ ㎣ ㎤ ㎠ ㎡ ㎢ ㏊ ㎍ ㎎ ㎏ ㏏ ㎈ ㎉ ㏈ ㎧ ㎨ ㎰ ㎱ ㎲ ㎳ ㎴ ㎵ ㎶ ㎷ ㎸ ㎹ ㎀ ㎁ ㎂ ㎃ ㎄ ㎺ ㎻ ㎼ ㎽ ㎾ ㎿ ㎐ ㎑ ㎒ ㎓ ㎔ Ω ㏀ ㏁ ㎊
ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩαβγδ εζηθικλμνξοπρστυφχψω
ㄱㄲㄳㄴㄵㄶㄷㄸㄹㄺㄻㄼㄽㄾㄿㅀㅏㅐㅑㅒㅔㅘㅙㅝㅞㅟㅢ
ㅥㅦㅧㅨㅩㅪㅫㅬㅭㅮㅯㅰㅱㅲㅳㅴㅵㅶㅷㅸㆂㆃㆄㆅㆆㆇㆈㆉ ㆊㆋㆌㆍㆎ
½⅓⅔¼¾⅛⅜⅝⅞¹²³⁴ⁿ₁₂₃₄

[출처] 한글자음+한자=특수문자|작성자 개믈기린


이게 별것 아닌 거 같아 보여도 가끔씩 필요한 경우가 있다.

오늘처럼 ㅎ


'기타' 카테고리의 다른 글

모음 + 한자키 특수문자 표  (0) 2013.12.24
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

Timing Wheel

2013. 12. 18. 17:25 from 프로그래밍 팁/기타

a4438aed0a7eea5a7840df89fe4cfdb6.png

Timing Wheel은 타이머를 구현할 때 유용하게 활용할 수 있는 자료구조다. 블로그에 한 번 정리해 둬야지 하고 미루기만 하다 이제야 끄적임. 정리라고 해봐야, 나중에 다시 검색할 때 키워드를 까먹지 않도록 자료구조 이름이라도 남겨두자는 것 뿐이다. NHN(이제는 Naver가 되어버린)의 hello world 블로그에 한글로 잘 정리된 포스팅이 있다. Timeing Wheel Data Structure를 구글링해도 자료는 많이 있음.

예전에 내가 직접 만들었던 서버 엔진에는 구조가 심플했고 독립적으로 정리된 타이머 모듈은 없었다. 이후에 간단한 타이머를 직접 만들어본 적은 있으나 그것도 boost::timer를 이용해서 대충 뚝딱 만들어본 단순한 구조였는데, 대량의 작업을 처리하기 위한 효율적인 타이머를 구현하려면 타이밍 휠을 이용해 만드는 것이 좋겠다.

Hello World 블로그의 글에 잘 설명되어 있지만 간략히 재정리 하자면, 배열을 이용해 일반적으로 만들면 O(n) 으로 처리해야 할 일들을 타이밍 휠을 써서 O(1)로 처리할 수 있게 된다. 타이머로 처리해야 할 task가 많다면 보다 효율적인 처리가 가능하다. 효율을 얻는 대신 감수해야 하는 단점도 있다. 메모리 사용량의 증가라든지, 고정된 단위시간 이하의 정밀한 시간 컨트롤이 어렵다든지, 미리 잡아놓은 circular-array 크기 * 단위시간 이상의 긴 시간에는 타이머를 걸 수 없다든지 하는 것들.

이 중 긴 시간을 쓸 수 없는 문제는 여분의 대기버퍼를 하나 더 마련하여 해결할 수 있다. 타이밍 휠에 바로 들어갈 수 없는 긴 시간의 task는 대기 버퍼에서 잠시 대기시키다 집어넣으면 됨. 나머지 단점 들이야 필요한 케이스에 맞춰 적절히 조절해주면 큰 문제랄 것도 없을 것 같다. 적어도 내가 겪어본 게임 서버 개발 시에는.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요