이 블로그는 방문자 통계를 위해 티스토리 기본 기능과 Woopra를 사용합니다. 원하지 않으신다면 사용하시는 웹 브라우저에 내장된 DNT 헤더를 켜고, JavaScript를 끄셔도 무방합니다.
이 블로그 방문자의 약 60%는 네이버 검색을 사용하십니다. 을 이용하시면 더 유용한 정보를 쉽게 얻게 되실 수도 있습니다. [mediatoday]
« 2018/07 »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
블로그 이미지
제가 주제인 블로그... 그냥 주제 없는 블로그입니다. 전공 분야나 예전 관심 분야 등등에 관한 글이 우선입니다만, 두어 문단을 넘길 만한 글이라면 대강 정리해 기록합니다. 학부생입니다. 트위터에서 볼 수 있습니다. http://aurynj.net/ 어­리


 
 

장고는 반쪽 MVC이다

Sablog Models/인터넷·웹 | 2013.12.01 02:13 | Posted by 어­리

요 며칠 간 프로젝트를 진행하면서 장고(Django)를 쓰기 시작했다. 사실 장고 자체를 접해 본 건 다소 오래 된 일이었던 것으로 기억한다. 아마 서버를 겸해 공부한답시고 설치한 리눅스가 너무 어려워서 날리면서 한동안은 리눅스와 거리를 두고 살았고, 파이썬도 잊었을 것이다. 그 이후 호스팅 업체를 알아보면서 윈도우 기반으로 PHP+MySQL이 돌아가는 APM을 쓴 적도 있다. 지금은? 만약 지금의 내가 과거의 내게 충고할 수 있다면, PHP를 가능한 대안으로 생각할 여지를 만들도록 놔 두지 않을 것이다. 요즘은 멀티부팅을 밥 먹듯 한다.

장고는 MVC 웹 프레임워크이다. 구체적으로는 DBMS에 대한 파이썬 클래스 ORM 래핑이 M이고, HTTP Request-Response를 수행하는 파이썬 객체 래핑이 V이며, URL 패턴에 따라 V를 적용(dispatch)하는 파이썬 코드와 그 밖의 데코레이터 기능이 C에 들어간다. 잘 보면 C의 의미가 MVC에 비해 다소 다른데, 이 떄문에 장고는 MVC의 변종인 MTV라고도 한다. 그러나 장고처럼 백엔드가 M과 V를 구성하기 위한 유틸리티가 되는 상황에서, 다 만들어진 M과 V에 대해 C가 또 한 번의 추상화를 하는 건 MVC 모두의 코드를 늘리는 퍽 불필요한 짓이다. 이런 건 대강 MVC가 맞다고 해도 되지 않나 싶다.

아무튼 올해에야 장고를 잡은 건 PHP를 버린 이후로 내가 서버 프로그래밍을 게을리 했다는 걸 방증하긴 하는데... 그 외에도 내가 장고를 잡기 꺼리고 레일즈나 스프링 MVC를 건드린 이유가 몇 가지 있었을 것이다. 파이썬 패키지 관리가 단연 첫째 문제였는데 (그래서 이번 서버는 우분투로 하고 pip만을 썼다) 다른 프레임워크에 비하면 파이썬은 몇백 배 나은 배포사용(deployment) 환경을 가지고 있었다... 그 다음 문제가 뭐였는지 기억도 잘 안 나고, 그냥 장고를 쓰기로 했다. 적절한 결정 덕분에 지금까지 별 난관 없이 장고로 그럭저럭 서버 하나를 완성해 나가고 있다. 유일한 문제라면 장고가 슬슬 마음에 안 든다는 것이다.

장고의 문제는 MVC 모두에 존재한다. 우선 M에서 가장 큰 문제는 장고 ORM이 정책적으로 DBMS에 구현된 기능에 대한 래퍼라는 것이다. 아무리 Enum의 구현이 RDBMS마다 다르기로서니 장고 규모의 프레임워크에서 models.EnumField가 없는 게 말이 되는가. 무조건 serial로 PK를 만드는 문제는 또 어떤가! 이런 정책은 ORM과 RM 모두에 해악이다. 한편 V에서 가장 큰 문제를 꼽자면, M과는 역설적으로 장고의 규모가 너무 크다는 점일 것이다. 나는 왜 @csrf_exempt가 데코레이터(decorator)여야 하는지 이해할 수 없다. 분명 장고의 액션 기반 HTTP 뷰 모델은 성공한 모델이고, 여타의 웹 프레임워크와 함께 놓고 보아도 꽤 성숙한 축에 속한다. 그러나 장고의 V를 이용해 좀 더 복잡한 일을 하려고 하면 반드시 문제가 생긴다. 거기 당신, 장고를 이용해 코드 중복 없이 XML과 JSON으로 된 API를 모두 제공하는 서버를 객체지향적으로 짤 수 있는가?

그러나 이와는 비교도 안 되는 문제가 바로 C의 문제이다. 운을 떼자면, 나는 SOAP/REST 양시론자이다. MVC냐 아니냐의 문제는 차치하더라도 여기서 문제가 발생한다. 장고의 URL dispatcher는 REST에만 대응한다. 그러나 그마저 반쪽 REST이다! 그 이유는 간단한데, URL만 신경쓸 뿐 Method에 따른 dispatching이 전혀 없기 때문이다. URL에 따라서만 뷰가 달라지는 프레임워크는 다시 말해 URL 패턴에 따라 뷰가 달라지는 환경에서만 사용 가능하다. 이 방식은 같은 자원에 대해 메서드와 헤더에 민감하게 반응하기 어렵고 따라서 OPTIONS나 Accept를 놓치기 쉽기 때문에 REST 의미론과 배치되는 경향이 있다. 그렇다고 장고에서 무리해서 메서드를 먼저 걸러내자니 뷰를 자원 객체처럼 만들게 되고 여러 URL 패턴을 하나의 뷰에 대응시키면서 지저분한 코드만 남는다.[각주:1] 아마 이것이 앞으로 장고에서 고쳐지는 일은 없을 것이다. 참고로 URL과 Method dispatching을 모두 해 주는 프레임워크도 있다. 스프링 MVC가 대표적이다.

그래서 어떻게 할 거냐고? 물론 다음에 웹 서버를 만든다고 해도 여전히 파이썬을 쓸 생각이다. 하지만 새로운 프레임워크를 배울 시간이 모자라지만 않다면 다른 라이브러리로 건너갈 생각이 강하다. Flask같은 마이크로프레임워크는 영 취향이 아니고, 데이터 모델로는 SQLAlchemy를, 웹 서비스 모델에는 Werkzeug를 고려할 것이다. 아무래도 장고의 한계를 느꼈기 때문이다. 물론 장고는 좋은 웹 프레임워크이다. 그러나 연장 탓을 많이 하는 프로그래머에게는 남이 만든 프레임워크가 맞지 않는지도 모르겠다.


추가(2013-12-1 16:07). Class-based view를 어떻게 생각하느냐는 의견을 전달받았다. 일단 "괜찮지 않나, 잘 모르겠다" 정도로 대답했는데, 아무래도 장고를 더 써 봐야 알 것 같다. 클래스 기반 뷰 자체는 REST와 잘 상통하는 면이 있지만, 사실 이상적인 웹 서비스에서 REST의 자원 객체는 데이터베이스 ORM 객체와 크게 다를 게 없기 때문에 개념적으로 생각하자면 같은 모델을 두 번 정의하는 게 된다. 굳이 중복을 없애자면 데이터 모델을 만들고 DB나 HTTP API를 위한 데코레이터를 작성하는 방식이 나은데 이건 장고 프레임워크의 장점을 완전히 깎아 먹자는 말이므로 패스. 그리고 사족이지만 WebDAV같은 프로토콜은 django.views.generic.View를 평범하게 써서는 구현할 수 없다...

  1. 구체적인 예를 들자면, 회원 가입에 쓰이는 POST /account와 회원 열람에 쓰이는 GET /account/(id)가 있다고 하자. 이들은 사실상 같은 자원에 대한 다른 접근이기 때문에 URL에 따라 뷰를 바꾸기보다는 메서드로 먼저 걸러내고 (id)를 뜯어내는 쪽이 훨씬 적절하다. GET /account에서 어떤 오류를 돌려줘야 할지를 생각해 보면 명확하다. 그렇다고 r'^account$'와 r'^account/(?P<_id>d+)$'로 나눌 수 있는 뷰를 r'^account(?:/(?P<_id>d+))?$'로 하나의 뷰에 넣어야 하는가. [본문으로]
시험 기간이 끝나자마자 포스팅을 시작한다. 이러니 성적이 좋을 수가 있나.


2010년 7월 2일, SyntaxHighlighter 3.0.83이 배포되기 시작했다. (사본 다운로드)
티스토리용 파일은 글 하단에 있지만 수정된 파일 하나만 올려 놓았기 때문에 이 파일도 받아야 한다.
- SyntaxHighlighter 웹 사이트 바로가기

1. 소개
3.0은 매우 많은 개선점을 컨셉으로 만들어졌다.

[SH 3.0의 특징] 잡소리가 많아서 30줄 정도 되지만 관심이 있다면 볼 만합니다.



2. 삽질 내용

티스토리라든지 텍스트큐브 기반 사용자를 위한 삽질보정.
블루앤라이브 님께서 자주 해 주시던 일이다. 약간의 거대한 조언을 얻었다. 말하자면 방문자 도둑질.

이 삽질의 결과가 아래 shCore.js 파일이다.
  • 텍스트큐브/태터툴즈 계열 (티스토리도) 치환자 입력 지원.
    [#\\#_(치환자)_#\\#]
    라고 입력하면
    [#\#_(치환자)_#\#]
    라고 출력된다.
    티스토리 새관리의 버그, <pre> ~ </pre> 내의 무한 <br /> 제거도 병행한다.

    방법 보기

  • 소스 앞뒤의 <br /> 또는 빈 줄 제거.

    방법 보기

  • 아래 파일에는 별도의 언어 파일을 추가하지 않았다.


3. 결과물
블루앤라이브 님은 속도 빨라지라고(?) 친절하게 인크립션까지 해 주시지만... 저는 그러지 않아요
2010.12.2. 원활한 작동을 위해 컴파일된 파일로 교체했다.


4. 설치 방법

압축을 풀고 모든 브러시 파일(/scripts/)과 사용할 테마 파일(/styles/)을 업로드해야 한다.
shCore.js는 수정본으로 교체한다.
1.x 시절부터 SyntaxHighlighter를 textarea 태그로 사용했다면 한 줄이 더 필요하다.
<script type="text/javascript" src="./images/shLegacy.js"></script>

[1] 전통적인 방법

설치 방법 보기


강조된 두 줄 중 아래 한 줄이 테마에 직접 관여한다. 두 줄을 이렇게 한 줄로 바꿔도 된다.
<link type="text/css" rel="stylesheet" href="./images/shCoreDefault.css"/>

[2] 오토로더를 사용하는 방법

설치 방법 보기

SyntaxHighlighter 웹 사이트에 나온 사용법을 거의 그대로 옮겨 왔다.
아무래도 소스가 길어지는 것은 구조적인 한계인 듯하다.
브러시에 있는 .aliases 설정을 가져오려면 애초에 브러시 파일을 불러와야 하는데,
그러면 오토로더를 쓸 필요가 없기 때문.

[3] SyntaxHighlighter 페이지 호스팅을 이용하는 방법

설치 방법 보기

최신 판 소스를 직접 가져올 수 있다.
SyntaxHighlighter 웹 사이트에 나온 사용법을 거의 그대로 옮겨 왔다.
JavaScript에는 import 기능이 없다.

알다시피 함수를 만들어 모듈화하는 것은 중요하다.
그 과정에서 소스가 길어지면 라이브러리를 몇 조각으로 쪼개게 되며,
한 파일에서 다른 파일을 불러와 함수를 사용할 필요가 있다.
파일 간에 의존성이 생기는 것이다.

C에 #include가 있듯이,
CSS에는 @import, PHP에는 @require나 @require_once, JSP에는 @include file이 있다.
그러나 JS에서는 이런 동적 링크 함수가 없어서,
HTML에서 직접 script 태그를 이용하지 않으면 추가가 안 된다.

그러나 직접 불러오는 것이 불가능하다면 HTML에 script 태그를 집어넣으면 된다.
실행문 중간에 넣으려면, 가장 간단한 형태는 다음과 같다.
document.write('<script type="text/javascript" src="첨부할 파일"></script>');
그러나 script 태그를 head의 하위에 넣을 것이 권고 사항이므로 이렇게 쓰는 것이 가장 나을 것이다.
function importScript(filename)
{
    document.getElementsByTagName('head').item(0).innerHTML
        += '<script type="text/javascript" src="' + filename + '"></script>'
}
정석대로라면 Element를 만들고 Attribute를 부여해서 appendChild를 써야 하지만 귀찮았다.

그리고,
  1. 당연히 이 함수 원본은 라이브러리에 있으면 안 된다.
  2. 다른 언어처럼 함수 밖에 그냥 쓰면 에러 먹는다. document.body.onload에 추가해 줘야 한다.
"블로그에 새로운 글감을 찾았다."
라기보다는 그냥 가내수공업으로 JS로 이것저것 만드는 도중에 함수를 만들고 있다.

최근에 JS를 새로 익히면서 DOM 따위는 순식간에 이해했지만(이미 XML을 충분히 배운 덕분에),
역시 골치를 썩이는 건 이 함수 놈들.
표준 함수들은 그나마 용법이 잘 정리되어 있지만...
사용자가 만들어서 널리 쓰이는 함수들 때문에 헷갈리기 일쑤다.
확장 함수 이름을 다 똑같이 쓰다 보니 표준 함수인지 헷갈리기 시작하면 2시간 삽질은 기본이다.

그래서 나는 표준 함수 말고 일단 확장 함수들을 정리할 생각이다.
이 글을 읽는 사람이 DOM, 노드 구조 등에 관한 기본 지식이 있는 초보 개발자라고 가정하고,
상세한 설명은 하지 않겠다.


첫 번째 대상은 insertAfter()이다.
이 자식은 표준 함수인 insertBefore()와 비슷하다. insertBefore()의 일반적인 용법은,
"부모 노드".insertBefore("삽입 대상", "대상을 이 앞에 넣을 위치");
이렇다. 이와 비슷하게 insertAfter()는 이런 용법으로 쓰일 목적으로 만들어진다.
insertAfter("삽입 대상", "대상을 이 뒤에 넣을 위치");

insertAfter() 함수는 웹 사이트에 이미 널리 알려져 있는 확장 함수라서,
이와 같은 소스를 찾기 쉽다.
function insertAfter(newNode, referenceNode) {
    document.body.insertBefore(newNode, referenceNode.nextSibling);
}
그리고 나는 이 때문에 "여기 삽질 1시간 추가요!"를 불렀다.

알다시피 위 함수는 insertBefore()를 사용한다.
대상 노드 뒤에 끼워야 하기 때문에, 이 때 대상 노드의 뒤 노드를 찾아 앞에 끼우는 것이다.
그러나 내가 위 함수의 문제를 발견한 까닭은, 내가 마지막 노드 뒤에 끼우려 했기 때문이다.
마지막 노드에는 다음 형제 노드(.nextSibling)가 없다.
그럼 위 명령 자체가 성립이 안 되고 작동도 당연히 불가능하다.

따라서 위치 참조 노드가 마지막 노드인지 알아보고,
마지막 노드인 경우에는 노드를 뒤에 추가(append)해야 한다.
function insertAfter(newNode, referenceNode) {
    refParentNode = referenceNode.parentNode;
    if (referenceNode != refParentNode.lastChild)
        refParentNode.insertBefore(newNode, referenceNode.nextSibling);
    else
        refParentNode.appendChild(newNode);
}

보다시피 참조된 노드가 마지막 노드가 아니라면 위의 경우를 그냥 적용하면 된다.

(이 글에는 쓰이는 시점의 네이버 블로그 시스템이 반영되어 있으므로,
여기서 소개하는 지침은 나중에 사용 불가능할 수도 있습니다.)


저작권을 준수하는 사람으로서 이런 걸 올리면 안 되지만,
기본적인 (X)HTML 예의마저 안 지키는 네이버는 종종 엿먹이고 싶은 상대다.

일단 마우스 우클릭 방지 스크립트를 무력화하는 프로그램에는

  • IETOY
  • Spell
  • 알툴바-_-

등등이 있다. 최근에 네이버에서 이것들을 거의 모두 막았다.

자바스크립트에서는 아래 툴이 잘 알려져 있다. 물론 이걸 무력화시키기도 한다.

javascript:
function r(d) {
    d.on-contextmenu=null;
    d.on-selectstart=null;
    d.on-dragstart=null;
    d.on-keydown=null;
    d.on-mousedown=null;
    d.body.on-contextmenu=null;
    d.body.on-selectstart=null;
    d.body.on-dragstart=null;
    d.body.on-keydown=null;
    d.body.on-mousedown=null;
};
function unify(w) {
    r(w.document);
    if(w.frames.length>0) {
        for(var i=0; i<w.frames.length; i++) {
            try {
                unify(w.frames[i].window);
            }
            catch(e) {}
        }
    }
};
unify(self);
alert('ok');
javascript:function r(d) {d.on-contextmenu=null;d.on-selectstart=null;d.on-dragstart=null;d.on-keydown=null;d.on-mousedown=null;d.body.on-contextmenu=null;d.body.on-selectstart=null;d.body.on-dragstart=null;d.body.on-keydown=null;d.body.on-mousedown=null;};function unify(w) {r(w.document);if(w.frames.length>0) {for(var i=0; i<w.frames.length; i++) {try {unify(w.frames[i].window);}catch(e) {}}}};unify(self);alert('ok');

이걸 주소창에 붙여넣고 실행시키며, 아예 즐겨찾기/책갈피에 등록하기도 한다.

뭐 이건 창과 방패의 싸움이라,
법적으로 클라이언트가 리버스 엔지니어링하는 것 자체를 금지하거나, (뭐 금지한다고 못하나..?)
HTML을 보내지 않고 미리 렌더링된 데이터를 보내지 않는 이상 해결할 수 없다.


네이버 블로그 포스트가 일반적인 방법으로 검색당하지조차 않는 현상은,

네이버 블로그 틀이 프레임셋 + 아이프레임 이중 구조를 갖고 있어서
일반적인 봇이 무시하기 때문에 일어난다.

하지만 브라우저의 모든 데이터는 클라이언트에 저장된다.
화면에 보이는 내용은 사실 컴퓨터가 네이버에서 가져왔던 것이란 말.

HTML 데이터를 읽을 수만 있으면 블로그 속살-_-로 들어갈 수 있다.

(이 포스트에 대한 간단한 설명은 http://blog.naver.com/wonderjune/10051716507에)


샘플은 내 네이버 블로그로 하려 했으나...
나는 우클릭 방지가 필요한 건 애초에 올리지를 않으니까 의미가 없다.

고로 희생양을 하나 만들었다.
http://blog.naver.com/shinyunho
예의상 모르는 사람을 공개처형할 수는 없고, 친구 블로그를 골랐다.

일단 블로그 글을 보려면 네이버에서 제공하는 포스트 고유 URL에 접속해야 한다.

타겟은 http://blog.naver.com/shinyunho/60092671785로 골랐다.


1. HTML Source 보기.

네이버 블로그는 메인에서 접속하든 포스트 URL로 접속하든 프레임셋으로 만들어져 있다.


내용이 없는 프레임을 하나 추가하는 것은,
브라우저 외의 프로그램에서 내용물을 인지하지 못하게 하는 전통적인 방법이다.

여기에서 필요한 것은 mainFrame뿐이니 이 주소로 들어가도록 하자.



2. NBlogMain.nhn

mainFrame이 가리키는 NBlogMain.nhn에서도...
링크의 원활한 이용을 위해 포스트의 내용은 iFrame을 통해 표시된다.

포스트 내용이 있는 iFrame은 "post-area"라는 div 태그 안에 들어 있다.
(각각의 div 태그 디자인은 블로그 디자인에 따라 CSS에서 조정되지만, 넘어가자.)
<div id="post-area">를 찾은 후 그 안의 iFrame이 가리키는 src(source)에 들어간다.

참고: 포스트의 내용을 담는 iFrame의 name/id는 "papermain"이지만,
이것을 타겟으로 삼는 앵커가 많으므로 div 태그를 찾는 것이 안전하다.

그런데 참고로 예전에 저 div 태그의 id는 "post-view"였다.
자동화 로봇을 막으려고 계속 바꾸는 거다. 모를 줄 알고? +_+
하는 수 없다. 또 달라지면 그냥 PostView.nhn을 찾아야지.


3. PostView.nhn

포스트에서 가져오고 싶은 그림이 있는데 포스트 내용이 방대하면 이건 대책이 없다.
이 때에도 그냥 찾기 기능을 애용한다.

다만 <img ... 태그를 찾고 다니는 건 별 효과가 없는 짓이다.
그 대신 그림에 인접한 글의 내용을 찾아 가는 노하우.


찾아낸 글 내용의 왼쪽에 <img> 태그의 일부가 보인다.


막상 말로 설명하니까 상당히 긴 글이 되어 버려서 그냥 동영상을 준비했다.
따로 만든 건 아니고 위의 과정을 그대로 녹화한 것이다.



여기까지... 복사 방지된 네이버 블로그 포스트 내용 보기는 끝난다.

이 포스트를 따라함으로써 생기는 저작권상의 문제에 본인은 책임질 수 없다.

다만 네이버 블로그에 깃든 이상한 문화가 사라지기를 빌 뿐이다.

구글 신의 도움을 받아 거미줄(web-_-)을 산책하던 중 이런 페이지를 발견했다.


젠장.

ActiveX 설치를 권고하려면 브라우저가 MS IE인지 검사라도 하란 말이다.



저렇게 위험 요소가 득시글거리는 사이트에 들어가는 사람은,
혹은 애초에 저 사이트를 이용하는 사람들은 대개 IE를 사용하겠지.
파폭을 사용한다면 이 창을 보고 액티브엑스 설치인 줄은 알 테고.

하지만 기본적으로 원칙에 어긋나지 않는가.


방법. 자바스크립트의 navigator.userAgent를 이용한다.
자바조차 작동하지 않는 OS에는 상당히 미안하지만, 간단한 방법이다.
<head> ~ </head> 사이, <title>...</title> 뒤에 이 코드를 붙여 넣으면 된다.
<script language="JavaScript"><!--
var userAgentMSIEIndex = navigator.userAgent.indexOf("MSIE");
if ( userAgentMSIEIndex == -1 || userAgentMSIEIndex < 5)
 window.location.replace("index.php");
--></script>

여기서 나오는 index.php가 싫다면 다른 페이지로 바꿔도 된다.
인터넷 익스플로러가 있어야 한다는 안내 페이지일 것이다.


크롬이나 사파리 사용자들을 화나게 하고 싶으면 Conditional Comments를 이용한다.
이것은 웹 브라우저에서 직접 렌더링할 때 점검하기 때문에 플랫폼에 덜 의존적이다. (<-이봐)
사실 IE랑 FF에서만 지원해 주는 기능이다. (아닐 수도 있다. <-뭐야)
<body> ~ </body> 사이를 이렇게 하면 된다.
<!--[if IE]>
IE에서 표시될 웹 페이지의 내용
<![endif]-->
모든 브라우저에서 표시될 내용


너무 영양가가 없는 글이었나.
미친소 잡는 날

남았습니다.

<img src="http://cfs9.tistory.com/upload_control/download.blog?fhandle=YmxvZzE2MDMyNkBmczkudGlzdG9yeS5jb206L2F0dGFjaC8wLzM4LmpwZw==" width="60" align="left"><b>미친소 잡는 날</b><br  />
<font color="#669900"><script src="http://qaos.com/MadBulls.php?type=waste&op=text&encoding=utf-8" type="text/javascript"></script></font><br  />
남았습니다.

저는 도아 님의 글에서 가져온 이 배너 원본을 상당히 오랫동안 달고 있었습니다.

(HTML 표준만 아주 약간 수정했습니다.)
­
얼마 전에 좀 더 수정했는데, 다른 분들을 위해 소스를 이 부분만 따로 올려 드리려고 합니다.

MB = Mad Bulls
미친 소 잡는 날

남았습니다. ㅠㅠ
See more...
<img src="http://cfs9.tistory.com/upload_control/download.blog?fhandle=YmxvZzE2MDMyNkBmczkudGlzdG9yeS5jb206L2F0dGFjaC8wLzM4LmpwZw=="align="left" width="60" />
<small><strong>MB</strong> = <strong>M</strong>ad <strong>B</strong>ulls</small> <br  />
<strong>미친 소 잡는 날</strong><br  />
<font style="color: #669900"><script src="http://qaos.com/MadBulls.php?type=waste&op=text&encoding=utf-8" type="text/javascript"></script></font> <br  />
남았습니다. ㅠㅠ<br  />
<small><a href="http://offree.net/entry/Disuse-LEE-MungBak-Mad-Bulls" alt="See more...">See more...</a></small>

Mad Bulls에 대한 간략한 설명과,

이 배너의 원본을 제공해 주신 도아 님의 글로 가는 링크가 추가되었습니다.
지금 제 블로그에 SyntaxHighlighter를 설치해 놓고,

별도의 확장 코드를 만들어서 어셈블리어 코드를 올리는 중입니다.



일단 당장 SH에서 어셈블리어를 못 올리는 게 아쉬워서 파일을 올리긴 했지만,
-_-;

이건 뭐 걸레입니다.


SyntaxHighlighter의 구조를 완전히 이해했으니 시험 끝나고 재개발 들어갑니다.

(오늘 시험 첫 날이었습니다. 이게 뭐 하는 짓이지... 4일까지 시험인데)


목표는:

1) 이름만 8086이지 명령어 등등 x86 예약어까지 모조리 있는 문제 해결
2) SH 2.0 패키지에서 도입된 형식으로 가독성 향상
3) MASM, GAS 따로 만들어 지원하고, aliases 수정. (게시 원본은 NASM)


참고. 저도 2.0.320으로 업그레이드 완료했습니다.