HAMA 블로그

https://brunch.co.kr/@leehosung/40 Who is CTO: Roles, Responsibilities, and Personas Chief technology officer is a complex role that lies at the intersection of business and technology. A CTO is usually seen as a seasoned professional with a combined knowledge of a solutions architect, programmer, DevOps, team leader ncube.com

map이라는 추상화... reduce라는 추상화.. iterator라는 추상화.. future/promise라는 추상화... async/await라는 추상화.. journal 이라는 추상화.. expression이라는 추상화.. vistor / Facade라는 추상화.. Traits라는 추상화.. match 라는 추상화.. executePlan이라는 추상화.. InvocationFilter라는 추상화.. Try 라는 추상화.. Composition이라는 추상화.. Channel이라는 추상화.. 딱 봐도 저건 이것들을 보편화/간략화 한것이다라고 실체를 바로 판단 가능한 추상화가 있고, 대략적인 느낌 하에 세부 설명을 듣거나 해부해 봐야만, 실체에 대해 판단 가능한 추상화가 있다. 피카소의 황소그림 추상화(..

"코딩을 잘하는 사람" 보다는 ooo 사람이 되라.

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

이라는 후배의 질문에.....그냥 이 얘기 저 얘기 두서없이 주절거려 봅니다. ------------------------------------------------------------------------ 세상은 하나를 얻으면 하나를 버려야 한다고 합니다. 다 사람사는 곳이라.. 여러 생각들이 바람처럼 부드럽헤 흐르다가도 부딪히기도 하고 그렇습니다. 회사는 먼저 동호회가 아닙니다. 가족같은 회사, 친구같은 회사는 결국 문제만 생깁니다. 따라서 아래 원칙만 지키시고, 중심을 잡으세요. (저도 못하는 것들 이고 저에게 하는 말이기도..) 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등을 통한 비동기 ..