[새창]

"탄저균 실험" 이라고 기사를 쓰다니..ㄷㄷ
미군 보도자료에서는 규정상 탄저균은 죽은것 또는 비활성화 된것만 다른곳으로 배송할 수 있으니 본토에서 받은걸 가지고 탄저균에 대한 대처 훈련에 사용했는데 알고보니 실수로 활성화된 탄저균을 보냈더라. 라고 되어 있습니다.

"탄저균에 대한 대처 훈련" 과 "탄저균 무기 실험"은 천지차이죠...

4506 2015-05-27 13:04:11 0

API 동영상 강의를 구매하는 편이 좋을까요? [새창]

그런 이유라면 굳이 유료 강의까지 들으면서 배울 필요 없을텐데요...

4505 2015-05-27 13:01:48 0

최근 잘 된것들 [새창]

절벽 맵에서 평소대로 미듐들이 중앙 보고 있었다면 아무리 잘해도 2~3000...

4504 2015-05-27 13:00:58 0

최근 잘 된것들 [새창]

요즘처럼 기동전 위주로 게임이 돌아가면 만딜은 힘들겠네요...
5900도 우연찮게 적 헤비들이 헤비라인 아닌 곳으로 기어나와 측면 노출한 상태로 고착되고 우리팀 미듐들이 다른라인으로 몰려가는 바람이 겨우 한건데.

4503 2015-05-26 22:38:38 0

API 동영상 강의를 구매하는 편이 좋을까요? [새창]

윈도 API를 공부하시는 목적이 뭔가요? 그냥 지금 하고 있는 커리큘럼에서 C/C++ 다음 과목이라 하시는건가요?
윈도 API를 가지고 개발을 하셔야 해서 정말 잘 알아야 한다면 유료 강의를 듣는것도 좋겠죠.
그냥 이유는 없이 API가 다음 과목이라고 해서 하시는거면 굳이....

4502 2015-05-26 22:36:02 2

개발자분들게 여쭙고 싶은게 있습니다. [새창]

Case by case.

4501 2015-05-26 22:35:31 2

[개발자 암세포 공유]프로그래머들은 왜 안되는게 많을까요? [새창]

역시나 비공감 받네..ㅡㅡ
기간이 부족해서 안되는거면 "그 기능은 구현하려면 xx만큼 걸리는데 시간이 부족해요" 라고 해야죠...
"안돼요. 각각이 키값을 가지고 있고, 고유값이기 때문에... 어쩌구..." 는 "그냥 하기 싫어요."를 길게 말하는 것 뿐인데.

4500 2015-05-26 19:21:24 0

심심한데 논란이나 일으켜 볼랍니다. [새창]

https://namu.wiki/w/수증기%20응축현상

4499 2015-05-26 17:35:46 1

[개발자 암세포 공유]프로그래머들은 왜 안되는게 많을까요? [새창]

요구사항도 "동시에 업로드"가 아니라 "창 한번만 띄우게"잖아요..
내부적으로는 하나씩 올려도 파일 선택하는 창을 한번만 띄우면 되는걸...

4498 2015-05-26 17:33:31 1

[개발자 암세포 공유]프로그래머들은 왜 안되는게 많을까요? [새창]

저건 걍 일하기 싫은건데요...
불가능한걸 요구한 게 아니라 할 수 있는걸 안하겠다고 버티는 거잖아요.
그러니 뒤로 갈수록 시키는쪽도 반응이 안좋아지죠.

4497 2015-05-26 11:50:43 0

C++ 함수 파라미터 데이터 타입 질문있습니다. [새창]

hoistyler // void*를 써서 swap 구현이 가능한가요?
믿습니다.마멘 // C++에서는 템플릿을 쓰면 컴파일타임에 처리가 됩니다. 오버로드보다 템플릿 처리가 더 나을거에요.

4496 2015-05-26 11:47:10 0

C++ 함수 파라미터 데이터 타입 질문있습니다. [새창]

http://codepad.org/QZp6HaoT

템플릿을 쓰세요.

4495 2015-05-26 11:37:12 0

어떤 사실적인 조각들.jpg [새창]

나무였어요?
석고나 대리석인줄...

4494 2015-05-26 11:31:59 0

아 리팩토링하는데 미촤버리겠네여.. [새창]

본인 담당 코드라면 그저 안습(...) 자기가 유지보수 하는 코드라면 맘에 들때까지 고쳐야죠 뭐.
저도 외주업체가 짜놓고 간 막장 코드나 서울대 출신(...) 이라던 병사가 짜놓은 2천줄짜리 함수 같은걸 겪다보니...ㅠㅠ
왜 고치냐고 하는 분이 남의 코드에 참견하는 쪽이었군요.

4493 2015-05-26 09:54:27 0

아 리팩토링하는데 미촤버리겠네여.. [새창]

지금 잘 돌아가고 있고 본인 담당 코드가 아니라면 건드리지 마세요. 나중에 버그라도 나오면 어떻게 책임지려고 그러세요?
case문을 길게 쓰면 당연히 문제가 있지요. 문제가 있는데, 그건 그걸 유지보수할 사람이 책임지는거지 옆에서 이래라 저래라 해봐야 괜한 참견이에요.
소프트웨어 공학에 주화입마에 빠지기 쉬운 두가지가 있는데 바로 객체지향병과 리팩토링병입니다. 리팩토링이라는것 자체가 반드시 해야 하는것도 아니고 "시간이 남을 때" 또는 "도저히 이대로는 안되겠다 싶을 때"에나 하는겁니다.

나중에 몰래 고친다? 들킨 다음에는 더 큰 싸움을 하겠군요. 버전관리 시스템에 기록이 다 남을텐데 그 사람이 자기 코드 커밋하려면 언젠가는 발견할테니.