pchero on August 24th, 2016

도대체 누가 이런 생각을 했을까? 완전 멋짐!!! 🙂

Tags: , , ,

pchero on April 4th, 2016

원글 : https://www.facebook.com/groups/codingeverybody/permalink/1178978255476042/

 

신입사원을 뽑기 위해 이력서를 보고 있습니다. S/W 개발자가 선호할만한 회사가 아니기에 고스펙 지원자는 찾아볼 수도 없지만 이력서를 보면 과연 개발자로 지원을 한건지 생각을 하게 하는 이력서가 태반입니다.
이력서를 검토하고 추리고 연락해서 면접을 보는데 드는 시간과 노력이 취업준비생이 취업하기 위해 하는 노력에 비하면 아주 작지만 그래도 꽤 많은 시간을 들여야 해서 이력서를 검토하고 지원자를 가려 내는 나름의 노하우가 생겼는데, 모든 경우에 맞지는 않겠지만 참고 하시기 바랍니다.

1. 첫번째 검토시 성장과정이니 성격 등 장황하게 써 놓은 문장은 보지 않습니다. 지원동기도 일반적인 얘기인지 우리 회사나 제품을 한번이라도 찾아 보았는지, 내가 원하는 기술에 대한 경험이 있는지 빠르게 훑어 봅니다. “개발자에게 가장 필요한 덕목은 의지와 인내라고 생각합니다”류의 문장이 있으면 바로 접습니다.

2. 정보처리기사니 하는 각종 자격증은 쳐다 보지도 않습니다. 1종 운전면허 자격증 같은 경우는 쓰지 않느니만 못합니다. 운전기사를 뽑는 게 아니잖아요. 정성스럽게 쓴 이력서를 기업 담당자가 꼼꼼히 읽어 보리란 생각은 버리세요. 저는 하루에 많게는 100개 이상의 이력서를 봐야 할 때도 있습니다. 10분씩 잡아도 야근까지 해야 가능합니다. 내가 내세우고 싶은 것이 눈에 띄도록 해야 하며 그러기 위해서는 불필요한 것들은 최대한 배제해야 합니다. 어찌 보면 사진 찍는 것과 비슷합니다.

3. 특히 S/W개발자가 되려는 사람은 본인이 경험한 언어와 플랫폼, OS 등에 대해 눈에 띄게 정리할 필요가 있습니다. 단순히 C, C++, C#, JAVA 등으로 나열하는 것은 큰 의미 없습니다. 어느 정도 수준이고 어떤 프로그램을 작성해 봤는지를 어필할 필요가 있습니다. (1차를 통과하기 위해서는 제일 중요합니다)

4. 개인의 포트폴리오가 있으면 한번 더 보게 됩니다. 포트폴리오를 작성할 때에는 목차에서 전체를 한눈에 볼 수 있도록 하세요. 목차에는 해당 프로젝트의 제목, 팀인지 개인인지, 간략한 설명40자 미만)과 사용한 기술 등이 들어가야 하며, 상세 페이지에서는 사진을 곁들인 프로젝트에 대한 설명을 넣어 주세요. 어려웠던 점과 극복 과정 등을 간략하게 추가해 주시고 팀 프로젝트인 경우에는 각 팀원이 맡은 역할을 적어 주셔야 합니다. 그리고 폰트는 고딕체를 사용하세요. 샘물체니 특이한 폰트는 눈길을 끄는 것이 아니라 짜증을 부릅니다. 하지만 너무 많은 프로젝트는 역효과가 있을 수도 있습니다. 지난번 어느 지원자는 학교 수업시간 과제까지 모두 정리해서 제출을 했더군요. 그 노력은 가상했지만 그 중에서 우리 회사에 맞는 것들만 좀 추려서 냈으면 어땠을까 싶습니다.

5. 지원을 하시기 전에 그 회사에 대해 먼저 알아 보십시오. 입사했다가 생각했던 것과 달라서 후회할 수도 있고 이력서에 그 회사나 그 회사 제품에 대한 언급을 하고 이를 자신이 입사하고 싶은 이유와 연결시키면 우선 좋은 인상을 줍니다. 반면에 다른 회사에 지원했던 이력서를 복사해서 갖다 붙였구나 하는 생각이 들면 서류 통과 힘듭니다.

Tags: , ,

pchero on March 23rd, 2016

내가 버그 패치한 Asterisk가 릴리즈 됐다!!! 🙂

2015-12-08 13:04 +0000 [fe8011cc50]  sungtae kim <pchero21@gmail.com>

	* AMI: Fixed OriginateResponse message

	  When the asterisk sending OriginateResponse message,
	  it doesn't set the "Uniqueid".
	  And it didn't support correct response message for
	  Application originate.

	  ASTERISK-25624 #close

	  Change-Id: I26f54f677ccfb0b7cfd4967a844a1657fd69b74d

 

http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.8.0-rc1

Tags: , ,

pchero on March 22nd, 2016

요즘 들어 나태한 나를 느낀다…

이제는 일이 손에 좀 익었다고 대충대충 하려고 하는 나를 느낄 수 있다. 건성건성 얼마든지 처리할 수 있다는 근거없는 자신감, 태만감.. 등이 오늘의 일을 만들었다.

오늘 무슨일이 있었냐면…

간단한게… 그동안 단한번도 우리 테스터한테 테스팅을 부탁하지 않았다는게 뽀록났다. -_-;;;;;

순전히 나만의 자만심으로 “이건 테스터가 테스트할 수 없는 부분이야!” 라고 생각했던 것이다. 백엔드(Server-side) 개발이기에 아무래도 테스터로서는 접근하기 힘들 것이라고 생각하고 같은 팀 동료에게만 심플 테스트를 부탁하고 바로 Deploy 시켜 버렸던 것이다.

도대체 무슨 생각이었던 것일까? 영어로 부탁하기가 어려웠던 것이었을까.. 많은 이유들이 있었겠지만.. 뭐라 변명의 여지가 없었다. 그냥 동료를 안 믿었던 것이다. 동료의 실력을 과소평가하고 평가절하했다.

오늘 커밋에 대해 크리스와 이야기를 하다가 붉어져 나온 상황이었다. 그동안 테스트하지 않은 코드들이 delploy 되었던 것이었다… 하아.. 무슨 생각이었던 것일까.

이게 큰 문제를 만들었던 것은 아니다.

다만 기본 바탕에 깔려있던 나름 동료를 무시(?)했던 나의 사고방식이 뽀록났던 것이다.

얼마나 부끄럽던지.. 처음엔 문제를 파악못하다가 나 스스로 상황을 파악하면서 내가 무슨일을 저지르고 있었는지 알게 되었다.. 맙소사..

정말 부끄러웠다.. 다시는 이런일이 없을 것이라고 다짐하고, 이야기했다..

지금와서 생각하니 또 얼굴이 화끈거리네…

Tags: , , , ,

pchero on March 18th, 2016

BMP 파일을 열어보면 파일안의 내용이 상하반전되어 저장되어 있다. 그 이유는 다음과 같다.

처음에 IBM(OS/2)에서 좌표 체계 만들 때, 윈도우, 그래픽, 비트맵 등 전부다 통일성을 가지길 원했다.
이에 다같이 모여 회의를 했는데, 프로그래머를 비롯한 대부분의 사람들은 위쪽에서 아래쪽으로 데이터를 나타내길 원했다. 하지만 하드코어 그래픽 개발자들은 수학적 방식에 의한 Bottom up 방식을 원했다. 많은 논의 끝에 결국은 하드코어 그래픽 개발자들이 원하는 방식대로 되었다.

Bottoms Up!

Like most bitmap formats, the pixel bits in the DIB are organized in horizontal rows, sometimes also called “scan lines” from the terminology of video display hardware. The number of rows is equal to the bcHeight field of the BITMAPCOREHEADER structure. However, unlike most bitmap formats, the DIB begins with the bottom row of the image and proceeds up through the image.

Let’s establish some terminology here. When I say “top row” and “bottom row,” I mean the top and bottom of the visual image as it appears when correctly displayed on the monitor or printer page. The top row of a portrait is hair; the bottom row of a portrait is chin. When I say “first row,” I mean the row of pixels that is found directly after the color table in the DIB file. And when I say “last row,” I mean the row of pixels at the very end of the file.

So, in DIBs, the bottom row of the image is the first row of the file, and the top row of the image is the last row in the file. This is called a bottom-up organization. Because this organization is counterintuitive, you may ask why it’s done this way.

Well, it all goes back to the OS/2 Presentation Manager. Someone at IBM decided that all coordinate systems in PM—including those for windows, graphics, and bitmaps—should be consistent. This provoked a debate: Most people, including programmers who have worked with full-screen text programming or windowing environments, think in terms of vertical coordinates that increase going down the screen. However, hardcore computer graphics programmers approach the video display from a perspective that originates in the mathematics of analytic geometry. This involves a rectangular (or Cartesian) coordinate system where increasing vertical coordinates go up in space.

In short, the mathematicians won. Everything in PM was saddled with a bottom-left origin, including window coordinates. And that’s how DIBs came to be this way.

출처 :

https://kldp.org/node/154866

https://www-user.tu-chemnitz.de/~heha/petzold/ch15b.htm#bottoms%20Up

 

Tags: ,