개 발 일 지 017

잠시 밝혀 두지만 내 블로그는 실시간으로 올리는 것이 아니다.

쌓아 둔 글을 시간 날 때 한꺼번에 올리는 식이다.

!--0 기술 면접이 있었다. 면접관 알바가 잦다.

1. 유치원생과 대학생 설명. 설명에서 가장 먼저 고려되어야할 사항은 용어의 명확화 입니다. 내가 쓰는 단어와 상대방이 쓰는 단어의 뜻, 그리고 그 단어에 대하여 서로가 이해하는 부분을 완전히 일치시키지 않으면 이해가 어렵습니다. 이것을 꿰뚫은 답안이 2건 있었습니다. 대학생은 인터넷에서 편히 찾을 수 있는 용어들로 일반적인 설명을 하면 되겠습니다.

2||3. class, object 설명. 메모리에 대한 말이 나와야 합니다. new에 대한 설명이 나오면 정답입니다. 더 나아가 static 키워드까지 나왔으면 가점 입니다.

4. 상속 : 공통적인 부분을 추상화하여 코드양을 줄이면 됩니다. 예제로 든 객체 타입과 추상화 할 때 공통점을 뽑아내는 부분들이 채점 포인트 입니다.

5. 다형성 : 객체 배열, C와 연관 설명(void 포인터), Object 클래스 중 소스에 하나라도 들어 있거나 설명이 있으면 만점 입니다.

6. 인터넷 검색 유도를 위해 만든 설문 입니다. 정답은 모든 것은 API로 설명이 됩니다. 나와 있지 않지만 Instruction Set도 정답입니다. http://www.intel.co.kr/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf

7. 이름을 쓰는 것은 사실 가장 중요한 문항이었습니다. 배우는 단계에서는 잘못 아는 것을 바로 잡으면 더 효과적입니다.. 그러나 배우고 싶지 않은 부분은 제가 도와 드릴 것이 없어요. 그러나 이해 합니다. 왜 이해하는지 제 경험을 말씀해 드리면 학창시절 서울대학, 카이스트 석박사 하시고 영어로 프로그래밍 강의하시던 교수님께 코딩 못한다고 대놓고 말했던 적이 있습니다. 막노동 해서 번 돈으로 IT쪽 유명한 사람들 세미나 들으러 다니던 자존심 때문도 있었지만 결국은 제 인성이 문제였지요. 물론, 그 교수님은 집에도 안 가시고 코딩에 몰두하셔서 나중에는 알고리즘 코딩 분야에 독보적인 분이 되셨습니다. 사실 전, 관심없는 수업 시간에는 좋아하는 프로그래밍 서적을 펴놓고 보며 교수님의 말씀에도 이 수업에는 관심없다던 학생이었고, 두려울게 없던 시절이었습니다. 대신, IT, 임베디드 관련 수업은 타과 청강도 하고 전필도 듣곤 했습니다. 하지만 교수님 사이에 좋지 않은 인성평으로 어떤 교수님은 졸업을 안 시키시려고 전필을 F 주셨지요. 과제는 다 해서 D를 주셔도 될 법도 한데 말이죠. 어떤 교과목은 A+ 3명에 나머지 20명은 전부 F인 과목도 있었으니 이해는 갔습니다. 카이스트 교수님들이 좀 geek한 면이 있으시더라구요. 그러나 졸업을 해야 해서 사정 설명을 드리니 내가 내어주는 산업공학 알고리즘 하나를 3일내에 프로그래밍 해 오면 졸업 시켜주겠다고 해서 48시간동안 물만 먹고 열심히 짜서 겨우 졸업했더랬습니다. 퓨처스 인력중에 자기 과 교수님께도 멋지게 버틸 수 있는 인력이 있다면 저의 학창시절 생각이 나서 정말 좋긴 하겠고, 애착도 많이 갈 것 같습니다. 그러나 살아보니 실력보다 배울려는 자세가 먼저라는 것을 알 수 있었습니다. C, C++, JAVA 등 모든 언어를 하나로 연결시키는 개념을 모르면 스스로 공부하기가 많이 힘이 들고 겉핥기, 테크닉만 배우다가 끝이 날 것입니다. 테크닉이 나쁜 것은 아닙니다. 이해하기 쉽게 해킹으로 따지면 스크립트 키들이라고 보면 되겠습니다.

끝으로, 로테이션이 가능한 기술 분과장 자리를 신설하려고 합니다. 제가 먼저 가르쳐 드리고 기술 전파를 하면 됩니다. 기술 분과장은 계속 바뀔 것이고 2인으로 구성됩니다. 지원자 받습니다.

!--1 double calc = ((total - b) / total);

논리 오류가 났다. real number division error 인데
double calc = ((double)((double)total - (double)b) / (double)total);
드러운 캐스팅 이 후 잘 된다. -> 업 캐스팅 연산으로 해결

!--2 미래 먹거리로 통합 시스템의 DB 로 결국 postgresQL을 선정했다. 운영체제는 당연히 iOS,
RDBMS가 아닌, noSQL로 안 가는 이유는 너무 단순하기도 하고 내가 바로 보는 사업 자체가 NoSQL을
쓸 만큼 큰 건은 없기 때문이다. Dapp 처럼 점 조직으로 나눠야 사회가 제대로 돌아간다는 생각이라...
물론, 나중에 AI로 모든 것을 통합하게 되면 noSQL 쓸 것인데 그것도 아마 나눠서 계산하고 모델만 모으는 것이지.
DB로 통합하는 형태는 아닐거라 생각한다. 

간만에 SQL을 쓰니 구조로 해결 안하고 inner join 만 쌓인다. 

inner join file b on b.num_file=a.numf and b.segnum=a.segfile \
inner join --- c on c.c-----=b.---- and c.----=a.----- \
inner join ------ d on d.-----=a.---- and d.-----=a.------ \
inner join ------ e on e.----=a.----- and e.------=a.-------- \
inner join ---- f on f.-----=a.----- \
where a.------like '%@%%' and a.------ like '%@%%' and a.------ like '%@%%' \
and a.--------- like '%@%%' %@ %@ %@ %@ %@\
order by a.------, a.----- desc, a.-----, a.-------;"