마이애미 비치시에서 사용하는 우리 제품

분류없음 2009.01.16 13:32
꽤 오래된 고객이고, 초기에는 문제도 많았지만, 지금은 잘 사용하고 있다.
내가 경험한 보안 제품의 문제점은 다른 보안 제품과의 충돌이다. 우리 제품도 예외가 아니다. 특히 두세개의 AV를 돌리는 고객들은 정말로 밉다...다른 AV와의 호환성을 위해서 들인 나의 시간을 돌려 받을 수도 없고... 똑같은 놈들이 똑같은 짓을 하려고 하면 충돌이 날 수 밖에 없다. 다만 회피할 수 있는 방법을 찾는 수 밖에...
 
The Answer: eEye's Integrated Threat Management Solution

Martinez and the city of Miami Beach eventually turned to eEye. The eEye solution represents a new class of security product: integrated threat management. eEye detects vulnerabilities and threats, prevents intrusions, protects all of an organization's key computing resources, from endpoints to network assets, all while providing a centralized point of security management and network visibility.
 
eEye's research team is consistently the first to identify new threats in the wild, and its products leverage that research to deliver on the goal of making network security as easy to use and reliable as networking itself.

Posted via email from bugtruck's posterous

신고

[애자일] 내가 이해한 애자일

분류없음 2009.01.16 13:20
애자일을 나는 사랑한다. 왜냐하면 나를 "자유롭게" 해주기 때문에...
 
탑다운 방식의 소프트웨어 개발론은 모든 것이 통제 가능하다는 전제하에 시작한다. 하지만, 실제로 모든 것은 통제 가능하지 않다. 또한 위에서 열심히 전체의 모든 디자인을 구상하고 만들는 긴 시간동안 밑에서는 코드 한줄 안 쓰고, 펑펑 놀아야 된다. 그러다가 프로젝트가 반쯤 진행 될 무렵 전체적인 그림과 설계서가 나오면 이제 납기일을 맞추기 위해서 밤을 새고, 코피를 흘리며 코딩을 해야 하는 지옥과도 같은 시간이 오는 것이다.
 
그 부분에 애자일의 강점이 있다.
탑다운으로 모든 것을 설계를 끝내고 코딩에 들어 가는 것이 아니라 스프린트라는 작은 단위로 프로젝트 기간을 쪼개고 감당 가능할 정도의 태스크를 만들어서 전체 프로젝트를 작게 구현해 보는 것이다. 물론 스프린트 하나에 모든 것을 이루려는 것은 아니다. 다만 시험 가동해 보는 것이다. 그렇게 한 스프린트가 지나고 나면 이제 개발 조직의 효율성이나 능력이 나오게 된다. 이제 그렇게 산출된 숫자들을 가지고 다음 스프린트를 계획한다. 그 다음 스프린트는 이제 조금 더 정확하게 예상을 맞출 수 있을 것이다. 그런 식으로 iteration을 계속하면 이제 언제 쯤에 원하는 정확한 산출물이 나올지 "산술"적으로 계산이 가능하게 되고, 또한 정해진 납기일까지 나올 수 있는 산출물이 어느 정도인지 측정하는 것이 가능하게 된다.
 
따라서 납기일 일주일 전에 "못할 것 같습니다"라는 폭탄 선언은 하지 않아도 되는 것이다. 만약 납기일을 못 맞춘다면, 납기일 아주 오래 전에 그러한 "선언"을 하는 것이 가능하고, 협상의 여지를 가질 수도 있겠다. 그리고, 납기일까지 가능한 기능을 구체적인 수치를 가지고 신뢰성 있게 제시할 수 있다.
또한 코딩 인력들이 디자인 끝나는 것 기다리느라 펑펑 노는 일을 방지하고, 나중의 밤샘 코딩도 방지할 수 있는 방법이라고 할 수 있겠다.
 
여기까지 이론적인 내용이고, 실제 적용은 이론과는 정말 다르고 다르다. 왜냐하면 인간이라는 존재가 하도 복잡한 존재라서....
그리고, 왜 서두에 말한대로 애자일이 나를 자유롭게 해주는지에 대해서도...
 
그것은 다음 번에 다시...

Posted via email from bugtruck's posterous

신고

컴퓨터 언어의 히스토리

분류없음 2009.01.16 11:44
 버그트럭에서 C언어에 대한 논의가 나와서 언어의 족보를 찾아 보았다.

논의 중에 나온 스몰토크가 얼마나 다른 언어에 영향을 미쳤나가 궁금해서 찾아 보니.

Smalltalk-80(1980) -> Oak(june 1991) -> Java -> C#

Smalltalk-80(1980) -> Objective-C(1983) -> Objective-C 2.0(august 7, 2006)

C#이나 Objective-C 가 우리가 가장 많이 사용하는 OS들(윈도우즈,Mac OS X)에 사용된다는 것을 감안하면 SmallTalk이 꽤 우리 삶에 영향을 미치고 있는듯 하다.

스몰톡에 대한 간략한 설명은 이경문님의 설명을 참고하시기 바란다.

 

Posted via email from bugtruck's posterous

신고

[영어] 'Text'는 동사이다.

분류없음 2009.01.16 11:06
영어에도 신조어라는 것이 많다.
 
그런데 그 신조어는 새로운 단어를 만들어 내어서 사용하기도 하지만, 기존의 단어의 품사를 바꿔 버리는 방법으로 이뤄지기도 한다.
 
가장 쉽게 접할 수 있는 예가 바로 'text'라는 단어이다.
'text'는 당연히 명사이다. 명사 이외의 용도로 과거에도 어떻게 사용되었는지는 모르겠다. 하지만 최근에 이 단어는 확실하게 동사가 되었다. 이제 'text'는 명사/동사인 셈이다.
 
'text'의 뜻은 텍스트 메시지를 보내다라는 뜻이다. 즉 SMS를 보내는 행위를 일 컫는다. SMS 보내는 행위를 "send text" 라는 식으로 표현하지 않는다. 그냥 "text"라고 표현하고, 'texting'이라는 단어는 그 행위를 일컫는 명사이다.
 
그리고, 고유명사가 동사가 된 사례는 너무 많다. xerox라든지 google이라든지...
 
그렇게 보면 우리가 알고 있는 많은 동사들도 사실은 명사로만 쓰였을 가능성이 있다. 예를 들어 호텔 등에 예약하는 booking이라는 단어는 동사 book에서 나왔고, 동사 book은 명사 book에서 유래한 것이라고 추측할 수 있다. 즉 책에 기입해 넣는 것을 booking이라고 하는 것이다.
 
한국말은 "~하다"로 끝나면 동사가 되지만 영어는 명사를 그냥 동사로 만들어 버리는 경우가 많다라고 생각하면 될 것 같다.

Posted via email from bugtruck's posterous

신고

윈도우즈를 위한 Strings 커맨드

분류없음 2009.01.16 11:01
UnxUtils에 이상하게도 strings.exe가 없다.
 
그래서 찾아 보니 정말 괜찮은 툴을 마이크로스프트에서 배포하고 있다.
 
바로 Strings !
 
이 툴의 장점은 유니코드도 보여 준다는 것인데, 옵션으로 아스키나 유니코드만 보여주게 할 수도 있다.
 
바이너리 안에 들어 가 있는 스트링을 보기 위해서 번잡한 툴 열 필요가 이제 좀 줄어들었다. 악성 코드들도 특정 문자열을 가지고 있는 경우가 많기 때문에 그러한 경우에 간단하게 확인하기 위해서 꽤 쓸만한 툴인 것을 생각된다. 더우기 와일드 카드를 파일이름으로 받을 수도 있기 때문에 여러 파일을 한 번에 처리할 수 있는 장점이 있다.

Posted via email from bugtruck's posterous

신고

[맥] Mac OS X Security 웹캐스트 리뷰

분류없음 2009.01.16 10:35
웹캐스트한것을 다시 들을 수 있겠네요. Mac OS X 보안에 대해서 전반적으로 쫙 훑어 주기 때문에 꽤 유익합니다.

---------- Forwarded message ----------
From: Webcast Notification <notifier@on24.com>
Subject: Webcast is now available for your review in the archives

Thank you for attending!

Mac OS X Security

Presented by Black Hat

The original event was broadcast on:
Date: Thursday, January 15, 2009
Time: 1:00 PM PST
Duration: 60-minutes

http://w.on24.com/r.htm?e=128064&s=1&k=3F843DBF6E877F085F4395413D3FD660

You can view the event archive at the link provided above. Please feel free to forward this message to a colleague.



********************
Important: System Setup & Compatibility Check

Test the computer that you will be using and make sure you have the minimum technical requirements to attend this event. Allow sufficient time prior to viewing the event for this test. Test at http://event.on24.com/clients/help/index.html

Posted via email from bugtruck's posterous

신고

[취약점] 멍청한 보안 리포트

분류없음 2009.01.16 10:01
이거 보고 기분이 깨네요.
 
 
sort.exe의 포맷 스트링 버그라, 버그는 맞지만 보안 버그는 아닌데 자랑스럽게 올린 것은 코미디를 하자는 것인지 진짜 심각하게 생각하는 것인지 알길이 없지만.
 
저것이 풀디스크로져 메일링 리스트의 쓰레기 같음을 또 증명하는 것 같아서 안쓰럽습니다.
이미 풀디스크로져 메일링은 무시하기 시작한지 오래...

Posted via email from bugtruck's posterous

신고

농부용 파워 슈트 일본에서 개발

분류없음 2009.01.15 18:32
정말 멋있습니다. 그런데 가격이 일단 $10K(1300만원?). 무게가 55파운드면 근 23킬로가 넘고. 근데 저거 들고 다니려면, 더 무겁고 힘든 거 아닌가?
 

Posted via email from bugtruck's posterous

신고

US Airways: 대단한 기장

분류없음 2009.01.15 18:19
착륙 기술도 기술이지만, 승객이 전원 대피하기 전까지 떠나지 않았다라는 부분이 정말 대단합니다. 게다가 이 사람 경력이 모두 항공기 사고 조사나 분석 쪽으로 맞춰져 있네요. 승객들이 정말 기장을 잘 만난 것 같습니다.
 
"""
His resume -- posted on the Web site for his safety consulting firm, Safety Reliability Methods, Inc. -- lists piloting procedures, technical safety strategies, emergency management and operations improvement, as areas of industry expertise.

He served as an instructor and Air Line Pilots Association safety chairman, accident investigator and national technical committee member, according to a biography on the site. He participated in several USAF and National Transportation Safety Board accident investigations, and worked with NASA scientists on a paper on error and aviation, his site says.

"""

Posted via email from bugtruck's posterous

신고

TDD는 쉽다 하지만 어렵다

분류없음 2009.01.15 17:54
우리회사는 약 1년 반쯤 전에 Agile 을 도입하기는 했지만, 아직 TDD는 도입하지 않았다.
그 이유는 나도 잘 모르겠다. TDD가 맞지 않는 사람이 있는 것일 수도 있고, 그런 세부 사항까지는 간섭을 안하다라는 생각일지도 모르겠다. 하지만 프로젝트 매니저가 스크럼 마스터 Certificate까지 가지고 있는 열렬 신봉자라 Agile 프로세스 자체는 철저하게 지키고 있다. 어느 정도냐 하면 회의 실의 두 벽면을 완전히 화이트 보드지(종이 처럼 된 화이트 보드)로 도배를 하고, 한 벽면은 커다란 보드를 붙여 놓고 카드를 색깔별로 인원별로 붙이는 식으로 진행했다. 물론 지금은 http://rallydev.com을 사용하고 있지만...
 
그런데 개인적으로 버그 없는 코드를 짜보고 싶은 열망에 컴파일러 에러는 컴파일러가 잡아 주는데, 잠재된 에러를 잡아 내는 방법을 애타게 찾던 중에 TDD가 해답이라는 사실을 알게 되었다. 등잔 밑이 어둡다고 TDD라고 들어는 봐도 관심을 안 가진 내가 잘못이다.
 
어쨌든 요 몇일간 TDD 책을 조금 읽어 보고 나니 개념은 잡혔는데 내 개발 생활에 어떻게 적용할지가 영 자신이 서지 않는다. 적용이 좀 억지 스러운 부분도 있고...대부분의 책이 자바를 예로 들고 있는 것도 걸리고...
 
어쨌든 더 연구해 보고 TDD가 과연 생산성 향상을 얼마나 가져 오는지 두고 보려고 한다.
 
 
지금 읽고 있는 책 TDD는 한 챕터 밖에 안된다.

Posted via email from bugtruck's posterous

신고

티스토리 툴바