그누보드 :: 관리페이지는 VISIT COUNT 하지 않기 최근에 그누보드로 된 웹사이트를 좀 봐줄일이 있어서 입맛대로 고치던 중,
관리페이지를 사용해도 페이지뷰 카운트가 올라간다는 사실을 알고 수정한 내용입니다.

그누보드/adm/_common.php에 아래와 같이 상수를 하나 추가합니다.
<?
define("NO_VISIT_COUNT", "YES");
$g4_path = ".."; // common.php 의 상대 경로
include_once ("$g4_path/common.php");
include_once("$g4[admin_path]/admin.lib.php");
?>

그누보드/common.php 에서 방문자수를 증가시키는 부분에 조건문을 추가합니다.
if( NO_VISIT_COUNT != 'YES' )
{
    // 방문자수의 접속을 남김
    include_once("{$g4['bbs_path']}/visit_insert.inc.php");
}

이렇게 하면 관리페이지는 방문자수 기록에서 제외됩니다.

정예 개발자의 조건 제가 생각하는 문제해결 능력이 뛰어난 개발자의 조건에 대해서 얘기한 적이 있다. 정예개발자라고 칭했는데, 아직 더 나은 호칭이 생각이 나지는 않네요.

소규모 초단기 S/W개발 프로젝트를 위한 TFT의 구성

위글에서는 단순히 조건을 아래와 같이 나열하기만 했습니다.

php, c#, javascript, HTML, ajax, mysql, sqlite, linux, windows

왜 이렇게 나열했는지 이야기하려고 합니다.

1. 문제의 해결
우선 개발자의 본질인 '문제의 해결'에 대해서 이야기하겠습니다.
'문제의 해결'이란 '사람이 하는 일의 일부를 시스템으로 대체해 노동량을 줄이려는 과정에서 발생하는 문제의 해결'을 말합니다.
좀 말이 길지만, 개발직군의 목적을 명확히 하는데 도움이 될 것이라 믿어요.

2. 시스템
노동에 있어서 판단력이 필요한 부분만 남기고.
하드웨어,소프트웨어,저장/출력매체를 이용해 자동화하는 것을 말합니다.
사람은 자동으로 한데 모아진 자료를 이용하여 판단하고 결정하면,
그 결과물도 자동으로 생성되고 조회가 가능하도록 분류됩니다.

이 시스템에는 사용자의 PC, 서버 PC 할것없이 그 과정에 사용되는 전자기기는 모두 포함됩니다. 플랫폼이라고 일컬어지는 것들이기도 합니다.

3. 개발자의 역량
개발자는 이 시스템을 설계하고, 구축하는 주체입니다.

전문 웹개발자라면, 달리 말해서 웹으로 모든것을 해결하려는 사람이라면,
웹브라우저의 form,Javascript와 웹어플리케이션 만으로 모든 것을 해결하려고 하겠죠.
결코 이 구성으로 해결을 하지 못하는 일은 얼마든지 있기 마련입니다.
또 다룰수 있는 범위 자체가, 실력이라고 일컬어지기도 하지요.

그래서 개발자는
사용자의 OS에 맞는 어플리케이션 개발부터,
서버의 OS에 맞는 어플리케이션 개발,
모바일의 OS에 맞는 어플리케이션 개발까지 모두 아우르기를 바라는 것입니다.

무작정 많이 익힌다고 좋은게 아닙니다.
asp,jsp,php 등 웹언어만 몽땅 익히는 것은 그다지 도움이 되지 않습니다.
php를 할줄안다면 c#을 익히고, c#을 할줄안다면 javascript를 봐야하는 겁니다.

4. 균형적인 시스템 구성 = 저비용
사용자의 OS와 서버의 OS에 맞는 어플리케이션을 능숙하게 개발할수 있다면, 기능을 적절히 나눠서 단순하고, 저비용의 시스템을 만들어 낼수 있게 됩니다.

예를 들어, 동영상 인코딩 서비스를 제공해줄 경우,

웹기반으로만 한다면,
서버 CPU/메모리 자원의 한계때문에
인코딩용 서버를 대량으로 준비해줄수 밖에 없고,
세션을 유지하기 위해 서버프로그래밍이 보다 정교해져야만 합니다.

사용자 PC의 어플리케이션으로 인코딩하고 결과물을 업로드 한다면,
인코딩용 서버를 준비할 필요도 없고,
세션을 유지할 필요도 없어서
매우 단순하고 효율적이며 저비용의 시스템이 될 수 있게 됩니다.
물론 모든 OS별로 어플리케이션을 만들어야 하지만 말이지요.

후자가 맞습니다.
결정권자가 고집을 부리면 비용이 낭비되고 퇴근시간이 늦어집니다.

5. 팀의 구성
혼자서 모든걸 하기 힘든게 사실입니다.
그렇지만 노동량이 많다는 뜻이지,
한사람이 두개이상의 OS 프로그래밍에 능숙해지는 것이 불가능하다는 말은 아닙니다.

보통 개발자가 많은 회사에서는 웹전문 따로 어플리케이션 전문 따로 팀을 구성하는데, 그다지 좋아보이지는 않습니다.

모두에 능한 사람들을 몇 모아서 팀을 만들고,
프로젝트에 따라 다른 역할을 주는 것이 더 효율적이고 훌륭한 결과물을 만들어 낼수 있다고 봅니다.

6. 결론
시스템은 수단방법을 가리지 않고 잘작동해야만 하며, 그 비용이 사람을 고용하는 것보다 커서는 안됩니다.
고로, 저비용이어야 한다는 얘깁니다.

저비용의 필수조건으로는 개발기간이 짧아야하고,
시스템이 필요이상으로 크거나 복잡해서는 안됩니다.

이런 조건에 부합하는 시스템을 만들려면,
개발자는 사용자PC, 서버OS 모두에 능해야 합니다.

HELO HELO는
SMTP 프로토콜에서 시작을 알리는 명령입니다.

쉘에서 직접 메일을 보낼때 이렇게 합니다.

$ nslookup
> set querytype=MX
> hanmail.net
Server:        211.233.28.41
Address:    211.233.28.41#53

hanmail.net    mail exchanger = 10 mx4.hanmail.net.
hanmail.net    mail exchanger = 10 mx5.hanmail.net.
hanmail.net    mail exchanger = 10 mx6.hanmail.net.
hanmail.net    mail exchanger = 10 mx7.hanmail.net.
hanmail.net    mail exchanger = 10 mx8.hanmail.net.
hanmail.net    mail exchanger = 10 mx9.hanmail.net.
hanmail.net    mail exchanger = 10 mx10.hanmail.net.
hanmail.net    mail exchanger = 10 mx1.hanmail.net.
hanmail.net    mail exchanger = 10 mx2.hanmail.net.
hanmail.net    mail exchanger = 10 mx3.hanmail.net.
$ nc mx4.hanmail.net 25
MAIL FROM: <sng2nara@mabook.com>
RCPT TO: <sng2nara@hanmail.net>
DATA
From: sng2nara@mabook.com
Subject: Hello

helo
mail test
.
$

HELO!!

키워드 인접 범위 추출 특정한 문자들이 중복없이 가까이 있는 범위를 추출하는 알고리즘.

검색결과 요약에 유용.

부,명예,지식,지혜 이제 갓 서른이지만,
가진 것이 없어서 오히려 고민이 없었던, 하나하나가 나의 재산이 된다고 생각했던 어린시절을 지낸 나로써는, 요즘이 너무나 감회가 새롭다.

어느순간 좀 가졌다는 자각이 생기면서, 소유에 대한 집착이 생기고,
즐길것 다 즐겨놓고, 다른 사람이 가진것과 비교하며 시기하고 미워하고,
내 탓을 하지 못했다.

가진 놈이 더 독하다. 부자가 더 부자된다. 집안이 부자라서 느긋하다. 뒤가 든든하니까 일도 즐기면서 한다. 하다가 떄려치고 놀아도 되니까.

이런 말을 할줄만 알고, 내가 독하지 못한것, 내가 더 노력하지 않은것, 내가 치졸한 욕심을 이겨내지 못한것, 일을 즐기지 못한것, 내가 결단을 내리지 못하는 것을 탓하지는 못했다.

그럼 지금 가진 것이 좀 있으니까 더 여유롭나?
아닌 것 같다. 가지니까 잃지 않으려고만 한다. 누가 뺏어간다고 한적도 없는데, 괜히 마음만 치졸해지고, 소심해지고, 예민하게 군다.

왜 물질과 명예를 소유하는 것과, 지혜와 지식을 소유하는 것은 다를까.
물질은 물론이고 명예조차도 영원히 내 것이 아니기 때문이다.

지혜와 지식은 내 것이라 추구할수록 풍요로와 지지만,
물질과 명예는 커질수록 잃었을때의 상대적 박탈감을 견딜 자신이 없는 것이다.
지혜와 지식은 몸을 움직이게 해서 소유물을 만들어 내는데 비해서,
물질과 명예는 몸을 편안하게 하지만 점차 소멸해갈 뿐이다.

아무도 뺏아갈수 없고 빛이 바래지 않는 지식을 쌓는 재미로,
누구도 쉽게 흉내낼수 없는 경험을 통해 얻은 값진 지혜로
지금의 물질과 명예를 얻게 되지 않았던가.(보잘것 없지만 예전에 비하면 엄청나다)

내가 부끄럽다.
고작 뭣모르고 날뛰던 망아지 시절에 앞뒤없이 얻은 지식과 경험에 기대어 아무것도 하지 않으면서 한숨만 쉬었으니 말이다.

부와 명예는 더러운 군것질이다.

나의 지난 경험들과 고민의 순간들, 결정을 책임져야 했던 그 모든 순간들이 헛되지 않도록 정진해야겠다.

개발자의 길

덥다. 요즘은 뜨거운 물로 샤워를 해야 잠이 온다.
AION.. 나무에서 닥사로 21렙까지 올리고 왔다. 재미있다.

IT버블이 터진지 10년째고, 그 거품이 걷힌지 5년 가량 되어간다.
거품의 결과로 과공급이 있었고, 오히려 지금은 공급부족인 상태인 것 같다. 오히려 미래가 없는 듯이 생각하는 것이 원인일지도 모르겠다.

소프트웨어 개발자의 미래는 어둡지 않다.

예를 php를 오랜시간 한 개발자는 php가 사라지거나 웹이 변화하면 모두 실직을 하고 말것만 같은데, 사실은 그렇지 않다.

운전에 비유해보자.
대형트럭 운전사로써 베테랑이라면 대형트럭의 기어위치나 정비능력을 말하는 것일까, 전국도로망에 대한 지식과 안정된 운전습관을 말하는 것일까?

내가 생각하는 개발자되기는 특정 플랫폼과 개발툴에 빠삭해지는 것만을 말하는 것이 아니다. 요구사항의 파악능력과 해결방법의 확보능력을 가진 사람이 되어야 한다.

다양한 문제에 스스로를 노출시켜 해법을 찾는 노력을 하고, 영문문서를 읽는 노력을 통해 인터넷에서의 정보수집능력이 키우는 것이, 진정한 능력을 키우는 방법이다.

자라나는 세대들은 모르는걸 엄마한테 안물어봅니다. http://durl.kr/sgk

쟤네들이 크면, 인터넷에서 다 되게끔 할거 같음.

소규모 초단기 S/W개발 프로젝트를 위한 TFT의 구성. 구시대의 산업과 사업체의 수익모델이 온라인과 조합되면서,
모든 사업이 S/W개발 전문가를 필요로 하게 되었다.

그중 소매업종에서는 온라인 거래와 온라인 매체를 활용하여 마켓플레이스를 넓히거나, 새로운 수익모델을 갖추는 것이 당연하게 되었다.

이는 디지털 원주민이 구매력을 갖기 시작하면서 폭발되기 시작한 것이다.
지금은 30대 초반 이상의 디지털 이주민들이 그들을 위한 시장을 열어주고 있는 것이다. 아날로그적 경험이 뒤섞여 통합되지 못한채 힘겹게 말이다.

향후 10년내로, 디지털 원주민이 더 나이를 먹으면, 동네 옷가게도 온라인으로 주문을 받고, 분식점에서 할인 쿠폰을 발행하고 시식권 추첨을 하며, 미용실간 제휴로 적립포인트를 공유하게 될것이다.대리기사는 아이폰으로 자신의 위치를 회사에 알리고, 주로 이용하는 코스를 확인하게 될것이다.

디지털캠,카드리더기, 휴대용장비, 바코드인식기등이 온라인과 연계되면서, 각종 소매업종의 경영/마케팅혁신을 가져올 것이라 생각된다.

조금 달라진다. 조금 더 좋게 달라진다.
그러나 S/W개발과정이 없다면, 이루지 못할 일이다.
컴퓨터와 인터넷없이는 하는 것보다 안하는게 이득이 큰 일들이다.

앞으로 빈번하게 나타날 프로젝트들은
초단기 프로젝트이고, 소규모 예산으로 집행되며, 그 난이도는 작업량이 방대하지는 않지만, 하드웨어나 아날로그 데이터와 직결되어서 그리 쉬운 난이도는 아닐것이다.

그렇다면 소수정예로 TFT를 구성하고, 유지보수는 따로 분리해야 한다.
유지보수가 쉬운 널리쓰이는 플랫폼을 선택하는 것이 무엇보다 중요하다.

그리고 TFT의 구성원은 적게는 개발+디자인 2인.
많게는 백엔드+프론트엔드+디자인 3인 정도가 적당하고,
시나리오/요구사항 분석은 반드시 디자이너와 함께 해야, 편리한 UI 를 구성할수 있다.

이때 정예 개발자의 요건은 꽤 까다롭다.
php, c#, javascript, HTML, ajax, mysql, sqlite, linux, windows
적어도 서버쪽과 클라이언트쪽 OS의 프로그래밍을 함께 할수 있어야 한다.
그래야 보다 효율적인 방법과, 짧은 시간안에 목적을 이룰 수 있다.

디자이너는 사실 프로젝트의 전체흐름을 누구보다도 잘 파악해야하고,
실제 시나리오를 디자이너가 가장먼저 파악해서 UI 를 구성해야한다.
의뢰자의 요구사항을 개발자와 함께 파악해야 하는 이유이다.
그리고 의뢰자의 취향도 작업초기부터 맞춰줄수 있어서 더욱 좋다.

디자이너는 개발자와 시나리오를 검토하면서 구현이 간편한 쪽으로 선택을 해야하기때문에, 개발자와 디자이너가 따로 작업한다는 건 시간을 낭비하거나, 퀄리티를 떨어뜨리겠다는 이야기이다.
이 둘사이에는 누구도 중계해선 안된다.