sosa0sa.com

결국 했다.

아무래도 사진 백업 용도로만 써도 충분히 연 회비를 감당할 수 있을 거라는 생각에서다.

그리고 좀 더 고민이 필요하겠지만 블로그의 사진을 따로 웹 호스팅 서버에 저장하지 않고 flickr의 사진을 쓸 수도 있으리라.

확실히 Pro계정을 사용하니 용량 제한이 없어 좋긴 하다.

근데 하드에 있는 저 몇 십기가 사진을 언제 다 올리지?

그리고 어떻게 관리하는 것이 좋을까?

Flickr 활용기

삽시다.  아니 일합시다.

월요일 아침부터 황당한 메일.

무슨 일을 시키는데 담당자의 동의는 아니더라도 사전에 이야기는 해줘야 하는 것 아닌가?

이런 이런 일이 있으니까 내가 좀 해라.

아니면 지나가는 말로라도 이런 이런 일이 있어서 널 담당자로 정했다.

최소한 정말 최소한 이런 언질은 있어야 하는 거 아닌가?

뭔 회사가 일하는데 꼭 황당하게 일을 시작하냐. 대화가 없는 조직 문화 만든 사람은 반성을 좀 해야 한다.

회식자리 있으면 한 번 이야기를 해야 할 듯. 하지만 요즘은 이런 생산적인(회식때 이런 이야기를 서로 터놔야 하는 거 아닌가? 늘 보던 사람들이 술만 먹고, 평소대로 농담따먹기나 하는 회식은 뭐하러 하남) 대화를 하는 회식도 없으니 더 암담하다.

월요일 아침부터 까칠모드다. -_- ㅈㄱ

SDK가 제공되기 때문이지 않을까? 혹은 애플의 공식적인 개발환경이 제공되지 않더라도 많은 사용자에 의해 다양한 “쓰임새”가 개발된 다는 것이 아닐까?

제품을 생산하는 곳에서 아무리 멋진 라인업이나 펌 업 계획을 제시해도, 회사 한 군데에서 일방적으로 일정을 세우고, 기능을 정의한 것보다는 실제 사용자나 다양한 third-party 업체가 다양한 아이디어를 바탕으로 쓸모있는 프로그램이 만들어질 확률이 높다.

이를 위해서는 개발환경의 공개가 필수적일 것이다. 그래야 일반인이나 third-party에서 생산된 프로그램의 안정성이 높아질 수 있다.

지금은 아이팟 터치를 해킹하면 불안한 구석이 많다고 하지만 시간이 가면 불안함은 수정될 수 있다.

그렇게 리눅스가 개발되어 왔고, 그렇게 오픈소스가 성장해 왔으니 터치나 아이폰의 미래는 우리가 상상하는 것 이상으로 밝다고 생각한다.

하는게 바로 RSS reader 이다.

근데

Another biggie for me is RSS feeds. Google Reader on mobile Safari is great, but again, it’s not very helpful when offline. Thankfully, the hacker community has stepped in with RSS.app. It works exactly as an offline RSS reader should. Add in the feeds you want, and it polls them at regular intervals. Whenever you have a little downtime on the road, use it to catch up on your favorite news.

출처: http://www.macworld.com/news/2007/10/21/ipodtouch/index.php

요거 괜찮겠네.

S/W 품질 향상을 주제로 한 세미나에서 나온 질문들

개발자가 시험을 책임지는 게 맞죠?”

경력 5년쯤 된 개발자는 얼마 정도 라인의 코드를 작성하는 게 맞을까요?

우리 회사에서 개발자와 검증인력의 비율이 CISCO랑 비슷하니까 된 거죠?

다 그런 것은 아니지만 위 질문들이 S/W 개발을 책임지고 있는 분들 에서 나온 말이다.

개발자가 시험을 책임지는 게 맞죠?”

두 분의 발표자(SE 전문가)가 3시간 넘게 이야기한 내용 중 상당부분이 바로 Tester의 역할이었다. Tester가 단순히 시험만 진행하는 것이 아니라 개발자와 Tester 모두 쉽게 시험할수 있도록 환경을 만들고, 시험의 효율화를 위해 자동화 툴을 만드는 역할을 한다(그렇게 해야 하고, 선진사의 tester는 그렇다고 한다)

이 말을 듣고 저 질문을 하신 분은 “혹시나 오해할까봐 그러는데 개발자들가 시험을 안해도 되는 것이 아니다”란다. 아마도 개발자들이 블럭 시험조차도 tester에게 떠넘길까봐 노파심에 저런 질문을한 듯하다. 개발자를 유치원생으로 아는 것도 아니고 -_-

경력 5년쯤 된 개발자는 얼마 정도 라인의 코드를 작성하는 게 맞을까요?

숫자 놀음의 극치 중의 하나가 SLOC(Source Line of Code)일 게다. 답변도 그렇게 나왔지만 숫자를 가지고 뭔가를 평가한다는 것은 정말 위험한 일이다. “SLOC가 많으면 능력있는 사람이다”라고 하면 개발자들은 불필요하게 코드를 늘릴 수 있다. 성능 떨어지는 것은 무시하고, component 나 하나의 함수로 만들어 재사용할 수 있는 것을 굳이 별도의 함수로 만들거다.

고객 상담원을 평가할 때 접수 상담 수가 많아야 한다고 하면 될까? 만일 그렇게 한다면 상담원 대대수는 고객의 항의에 대해 “예, 죄송합니다. 조치해 드리겠습니다”라고할 것이다. 그래야 빨리빨리 전화를 끊고 새로운 고객와 상담할 수 있을 것이니까. 이는 곧 회사에 불필요한 지출을 유발할수 있다. 반대로 접속 상담수가 적어야 한다면 어떨까? 그렇다면 가능한한 많은 말을 통해 고객을 설득하려고할 것이다. 이는 회사의 지출을 줄일수 있을 것처럼 보인다. 하지만이 경우 회사에 대해 고객들이 갖는 인상은 나빠질 것이다.

우리 회사에서 개발자와 검증인력의 비율이 CISCO랑 비슷하니까 된 거죠?

첫번째 질문에 대한 답을 들었음에도 이런 질문을 한다.  엑셀의 숫자만 보는 사람들이 갖는 가장 큰 문제점이 바로 이것이다. 얼마나 있냐가 아니라 무얼 하느냐가 중요한 데 엉뚱한 곳에 집중하고 있다. 유치원생들 모아놓고 tester라는 직함만 주면 되나? 어떻게 작업의 효율화를 높이기 위해 노력하는 tester 10명과 일반 tester 10명을 어떻게 같은 숫자라고 할 수 있을까?

멀었다. 한참 멀었어

엄마 : 혜승아~ 얼른 자 혜승 : 난 엄마 있어야 잘 수 있는데 엄마 : 엄마 없어도 혼자 잘 줄 알아야지 혜승 : 알아요. 노력하고 있어요 T_T

사촌언니랑 싸운 혜승이. 엄마에게 엄마~ 고모부한테 사촌언니 왜 그렇게 키웠냐고 물어봐~ -_-

사고 싶은 음반들

• Love Actually OST
• The Corrs unplugged
• Once OST

추가) Love Actually, Once OST는 구입했습니다. The Corrs 만 남았네요.