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

누구나 실수/실패의 상황을 마주하게 되며, 이것은 당신의 실수일 경우도 있고, 타인의 실수 있을 수 도 있으며, 서버/네트워크상에서 일어나는 실패(장애)일 수 도 있다. 이런 다양한 실수/실패는 개발자의 삶과 항상 함께 하는 것이기 때문에, 어떻게 이것을 다루는지가 관건이 된다. 이 글에서는 어떻게 실수/실패등 의도치 않은 상황을 처리하는지, 다양한 패턴들과 함께 살펴보겠다. 1. 디폴트값 처리 val value = getValue() val gretting = value?: "hi" 정상적인 상황하에서 값을 얻지 못하였을 경우 우리는 디폴트값을 할당하여 사용 할 수가 있다. 디폴트을 사용할 수 없는 경우에는 대개 예외를 던져서 상위에서 처리하길 기대 할 수 밖에 없다. 2. 예외 상황 무엇인가 원하는 ..

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

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

패턴은 추상적인 "의도"를 보다 명확한 의미로 "규정" 을 짓습니다. - 그로 인해 선배로 부터 값진 경험을 물려 받게 해 줍니다. - 그로 인해 의사소통을 원할하게 만들어 줍니다. - 그로 인해 자신의 생각에 확신을 갖게 합니다. - 그로 인해 장점과 단점을 드러내 줍니다. 모든 패턴에는 장점과 단점이 있습니다. (모든 기술도 마찬가지) - 그로 인해 연관 패턴들과의 계층적 구조를 보여주어 큰 규모에서의 설계를 가능하게 합니다. - 그로 인해 시야가 넓어집니다. Gof 디자인패턴 Creational 패턴명 의도 기타 Factory Method Abstract Factory Builder Prototype Singleton Sturctural 패턴명 의도 기타 Adapter Bridge Composite..

이라는 후배의 질문에.....그냥 이 얘기 저 얘기 두서없이 주절거려 봅니다. ------------------------------------------------------------------------ 세상은 하나를 얻으면 하나를 버려야 한다고 합니다. 다 사람사는 곳이라.. 여러 생각들이 바람처럼 부드럽헤 흐르다가도 부딪히기도 하고 그렇습니다. 회사는 먼저 동호회가 아닙니다. 가족같은 회사, 친구같은 회사는 결국 문제만 생깁니다. 따라서 아래 원칙만 지키시고, 중심을 잡으세요. (저도 못하는 것들 이고 저에게 하는 말이기도..) 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 되야하고 플러그인 방식으로 컴포넌트 유연성을 갖추고..등등 이 솔루션이 커져가는데 있어서, 지켜야할 선과 확장되는데 있어서 중구난방하지 않게 사용자들이 혼동..