http://kr.ahnlab.com/info/noticeView.ahn?num=50068915


"  Windows실행에 필요한 파일이 알 수 없는 버전으로 교체되었습니다. 시스템 안정성을 유지하려면 원본 버전으로 복원해야 합니다. "
라는 문구가 뜨면서 파일을 복원할꺼냐고 묻는 문제가 오늘 오후에 발생했다.

무슨 웜 바이러스가 걸린거지 했는데 ..

안철수 연구소에서  조금전에 발표가 있었습니다.

오진으로 부팅에 관계된 파일을 망가뜨렸군요...



임시 해결책도 공지되었네요

오진이 발생했던 엔진의 배포는 현재 중단된 상태이며,
오진사항을 수정한 엔진을 제작, 금일 중 재배포할 예정입니다.

윈도우 XP 서비스팩 3를 사용하시는 고객님 중 V3의 엔진버전이 2008.07.10.01 인 경우는
시스템 재부팅을 하지 않은 상태에서 아래와 같은 방법으로 해당 파일을 복구해 주시기 바랍니다.
1. 시스템을 절대 재부팅하지 마십시오.
2. V3 실시간 감시 Off 하십시오.
3. [검역소]에서 해당 파일을 선택한 후 '복원하기'을 선택하여 해당 파일을 복원해 주십시오.
오진으로 인해 고객님께 불편을 드린 점 사과드리며,
신속하게 수정된 엔진을 배포하도록 하겠습니다.

감사합니다.
AND


The greatest performance improvement of all is when a system goes from not-working to working


Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters. Most real-world programs run plenty fast enough on today's machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed.

Occasionally there will be parts of a program where performance matters, but you probably won't be able to predict where the performance issues will occur. If you try to optimize the performance of an application during the initial construction you will add complexity that will impact the timely delivery and quality of the application and probably won't help performance at all; in fact, it could actually reduce the performance ("faster" algorithms often have larger constant factors, meaning they are slower at small scale and only become more efficient at large scale). I've found that in most situations the simplest code is also the fastest. So, don't worry about performance until the application is running; if it isn't fast enough, then go in and carefully measure to figure out where the performance bottlenecks are (they are likely to be in places you wouldn't have guessed). Tune only the places where you have measured that there is an issue.


출처 : http://home.pacbell.net/ouster/sayings.html



컴퓨터 공학을 전공한 본인역시 학교 수업을 받을 당시에는 조그만 성능에 무척 신경을 썼었다. 물론 현재도 미비한 실력이니 그땐 오죽이나 어설펐을까.
학교에서 가르치기는 프로그램의 성능이 무척 중요한 요소인것처럼 말하지만,
실제 세계에선 사소한 프로그램 성능은 별 문제가 아니란 것이다. 개인PC, 네트웍, 컴퓨터 하드웨어 들의 발달로 인해 성능 좀 떨어지더라도 사용자가 잘 느끼지 못하기 마련.

실제 프로그래밍 관련 현업에서 3년 넘게 일해보았지만 본인 역시 학교에서 전공으로 학부 2학년때 배웠던 '컴퓨터 프로그래밍' 과목에서 제출하던 숙제에 쓰던 코드들보다 어렵고 복잡한 코드는 현업에서 거의 사용하지 않았던것 같다.
결국 누가보더라도 빠르게 이해할 수 있고, 간단하게 결과물을 빨리 만들어내는게 더 중요한 요소란  생각에 본인도 크게 동감한다.

Tcl/TK 의 개발자인 ousterhout가 그에 대해 조그만 Comment 남긴 것을 그의 개인 홈페이지에서 원문 그대로 인용해왔다.
AND

사용자 삽입 이미지

Congratulations
50th Aniversary Lego

와우..
레고가 벌써 50년이나 됐군요 ^^
단순하면서도 완벽한 인터페이스의 조화
(Software Engineering을 가르치던 교수님이 항상 칭찬하던 장난감인데..)

구글의 센스도 한몫 하는군요
구글, 센스쟁이 녀석
AND