HAMA 블로그

패턴은 추상적인 "의도"를 보다 명확한 의미로 "규정" 을 짓습니다. 패턴을 사용하는 이유와 공부하는 이유는 아래와 같습니다. - 그로 인해 선배로 부터 값진 경험을 물려 받게 해 줍니다. - 그로 인해 의사소통을 원할하게 만들어 줍니다. - 그로 인해 자신의 생각에 확신을 갖게 합니다. - 그로 인해 장점과 단점을 드러내 줍니다. 모든 패턴에는 장점과 단점이 있습니다. (모든 기술도 마찬가지) - 그로 인해 연관 패턴들과의 계층적 구조를 보여주어 큰 규모에서의 설계를 가능하게 합니다. - 그로 인해 시야가 넓어집니다. - 그로 인해 이름 짓기 능력을 발전 시킬 수 있습니다. - 그로 인해 추상화 & 모듈화 능력을 발전 시킬 수 있습니다. 이제 다양한 패턴들에 대한 이름과 의도에 대해서 정리 해 보겠습니..

이라는 후배의 질문에.....그냥 이 얘기 저 얘기 두서없이 주절거려 봅니다. ------------------------------------------------------------------------ 세상은 하나를 얻으면 하나를 버려야 한다고 합니다. 다 사람사는 곳이라.. 여러 생각들이 바람처럼 부드럽헤 흐르다가도 부딪히기도 하고 그렇습니다. 회사는 먼저 동호회가 아닙니다. 가족같은 회사, 친구같은 회사는 결국 문제만 생깁니다. 따라서 아래 원칙만 지키시고, 중심을 잡으세요. (저도 못하는 것들 이고 저에게 하는 말이기도..) 1. 모두에게 친절하고 상냥하게 대한다. 조금은 손해보고 살자. 2. 일과시간엔 적어도 6시간은 일에 초집중 하고 공유한다. (다만 일을 더 잘하기 위한 휴식같은건 필요..

현대 프로그래밍에서 가장 중요한 오류들인 동기화 문제( 레이스컨디션이나 데드락등 )는 C++같은 언어로 개발한 제품들에서 굉장히 많은 문제를 발생시키곤 한다. 윈도우즈 오류의 대부분이 동기화문제, 메모리관리 문제라니까.. 그중 동시성에서 레이스컨디션 문제는 1. 가변변수인데 게다가 동시접근가능 할 때 발생된다. 즉 2. 가변변수가 없거나 ㅡ 순수함수형 3. 동시접근예방 ㅡ Actor패턴 , CSP (예방이지 불가는 아님) 둘 중 하나만 충실 하면 근본적으로 없앨수 있다는 얘기이다. 1번 경우는 뮤텍스등을 통해 직접 보호 장치를 해야 하는데 , C++,Java, Go 같은 착한 (방종 or 자유로운) 부모하에서 인간의 실수는 비일비재 하다. 배움이 모자르고 막나가는 아이들도 생겨남. 근데 러스트는 엄한부모..

예) 블록체인에서 블록을 받아서 처리하기 - 명령적 0. 서버에 클라이언트들을 등록하고 초기화 한다. 서버는 현재 running 상태이다. 1. 입,출력 채널을 초기화하고 시작시킨다. 현재 connected 상태이다. 2. Recv 이벤트를 event 쓰레드풀의 쓰레드 하나를 얻어서 등록한다. 3. Recv 이벤트를 기다린다. 4. Recv 이벤트가 오면 읽을 수 있을 만큼 읽어서 버퍼에 저장해 두고, 채널은 다시 이벤트를 기다린다. 5. Recv 한 데이터가 너무 많으면 버퍼는 자동으로 증가 하고 적으면, 이미 읽은 버퍼의 앞쪽으로 이동해서 채워진다. 6. 채워진 버퍼는 유저 Handler에 세션정보와 함께 보내진다. 7. 유저는 어떤 세션에서 데이터가 왔는지 확인하고 버퍼에서 데이터를 4바이트 읽어서..

1. 시작하면서 언어에 대한 벤치마크에 있어서 보편적, 절대적이란것은 없으며, 팀의 숙련도, 제품의 특징등에 따라서 성능/개발속도는 천차만별 일 것이다. 이 포스트는 그 동안 블록체인 연구만 하느라 잊어버린 코더라는 나의 정체성을 일 깨우고, 각 언어에 대해서 일단 빠른 시간내에 손가는 대로 만들면 어떻게 되는지 재미로 만든 것이며, 옵티마이징에 대한 부분은 전혀 신경 쓰지 않았기 때문에 객관적 지표로 삼을 수는 없을 것이다. 특히 CPU점유율 같은건 신경도 안썼다. 락을 안걸고 CPU 펌핑시키면 성능은 엄청 올라 간다. (참고로 코드 품질은 안드로메다) 이 벤치마크는 주로 생산자-소비자 패턴에 대한 테스트이며, 쓰레드끼리 데이터를 주고 받는 과정을 시뮬레이션 하였다. 현재 Future등을 통한 비동기 ..

소프트웨어 아키텍트는 무엇인가? (개나 소나 다 자기 생각이 있는데 대충 끄젹꺼려 봄...) 보통 아키텍트 - 디자인 - 개발로 구성되는데 하이퍼레저 패브릭으로 설명 해 보면 (분야 및 조직규모등에 따라서 달라 질 순 있다) 소프트웨어 아키텍트는 "정체성" 을 확립하고 "균일성" 을 보장하는 롤을 갖는다. 즉 이 소프트웨어는 도대체 뭘 하는 것인가? 각 기업들이 서로 간의 신뢰성을 갖는데 최소의 비용으로 그것을 처리하게 하는게 목적이다. 성능 및 컨트랙트 활용성에 중점을 두고, 보안은 xxx 이상의 수준 이상으로 올리고..유저신원이 discolose 되야하고 플러그인 방식으로 컴포넌트 유연성을 갖추고..등등 이 솔루션이 커져가는데 있어서, 지켜야할 선과 확장되는데 있어서 중구난방하지 않게 사용자들이 혼동..

개인적으로 400여권의 책을 소장하고, 도서관에서 빌린 책만 수백권.... 교보문고는 나의 마음의 안식처로 생각하는 북 콜렉터로써....책은 항상 문고 가서 읽어보고 사는 편인데.. 에이콘 출판사는 거른다.... (아 몇권 산거 같긴 하다. 토비의 스프링같은 명저와 함수형류의 괜찮은 번역책들...) 이 출판사는 바퀴XX같은 매대 장악력과 수준 낮은 편집능력을 보유하고 있는데.. 한빛,길벗,인사이트 처럼 수준높은것은 바라지도 않고...제이펍 ,위키북스등에 비해서도 유독 에이콘의 편집 수준은 그 모양인지.. 굳이 찾자면 마이너한 소재에 대한 책도 빠르게 번역 출판해 준다는 감사한 면도 있긴 한데 그 감사함을 희석시킬 정도의 편집 수준... 덕분에 다른 출판사가 출판 할 기회가 없어지기나 하고.... (물론 ..

개발자처럼 하위,상위간의 차이가 심한 직업군에서의 "인사"란 정말 중요한 것이라 볼 수 있는데, 현재 면접관의 일방적인 질문은 1. 면접관 본인이 급조 공부한 질문 리스트를 물어보는데, 이건 면접관 본인과 회사에 아무 도움이 안된다. 그냥 우쭐거릴 수 있다 정도. (질문 오픈북을 강추 한다. 오픈북에 대한 준비 상태를 보면 회사,분야에 대한 열정&노력이 보이고, 그들은 진짜 믿을만하다.) 자신이 알고 있는 것을 아는 사람도 좋지만 모르는 것을 아는데 서로 협동 가능한 사람을 뽑으면 시너지가 나겠지요. 2. 면접자는 자신의 머리에 있는 진짜 자신의 지식(어떤것들을 구글링 하여 비교 평가 한다도 포함)에 대해 어필할 기회를 박탈 당합니다. 면접관의 위에서 내려다보는 시각에 의한 (일방적) 발언에 반박 내지는..

관련 기사: http://www.zdnet.co.kr/view/?no=20190212162100 관련 기술: SNI 를 이용한 HTTPS 모니터링 요즘 소위 https 차단(?) 문제로 시끄럽다. 이건 기술적으로는 아무 문제도 없는 것인데.. 내용 살펴보겠다는 것도 아니고..대중들은 이 기술에 대해 깊숙히 알 수는 없을 것이고, 그냥 먼가 자유를 침해 당한다고 판단하게 만드는 것 같다. 나쁜놈이 사용하면 큰일 나는 것으로...그러니 부정적인 여론 일색 일 수 밖에 없고 진짜 해야 할 논의 진행이 되질 않는다. 그럼 진짜 논의 해야 할 것은 무엇일까? 누구나 알지만 말하지 않는 것인데성인에게 포르노에 대한 개방을 할 때가 되지 않았냐는 거다. 이런것도 자유롭게 못보게 하니...빡칠수 밖에.. 결국 이런 중..

그거 정말 별거 없는데...ㅎㅎ 이렇게 쉬운 걸 쓸때없이 어려운 용어/사상/구분짓기로 떡칠을 해서, 오히려 개발자들에게 짐을 지우는게 아닌가 싶은.. 그냥 객체(모듈,개체,구조체등등) 이 있다고 할 때, 특정 역할을 외부에서 객체/포인터/함수등 무엇이든 주입받아서 해결하는 방식(근데 애들 관리가 힘들어 질 수도..숨박꼭질 하는 애들 종적찾기란..) 주입받는 방식은 기술,언어마다 다를 수도 있으며 생성자를 이용하던, 세터를 이용하던 채널을 이용하던 소켓이나 파이프를 이용하던, 설정파일에 적혀있던 리플렉션을 이용하던 뭐던간에 자신이 다 구현해서 하드코딩되는 것보다 유연해지겠지요. 이게 특정 프레임워크나 언어에서 유행했다고 해서, 그것이 정답 및 진정한 xxx 류가 될 수 없으며 그냥 유연하게 설계 하기 위한..