JHB의 삽질 이야기

좋아하는 글귀가 몇개 있는데 여기에 적어보려 한다. 1. 하는 것이 힘이다. 2. 작은 시도 빠른 실패

차라리 AWS 전용 블로그, Windows 개발 전용 블로그, Java 언어 전용 블로그.. 였다면 좀 더 쉬웠을까 예를 들어 React Native를 이용한 AWS Amplify용 FCM 푸쉬 메세지 개발 이라는 제목으로 글을 포스팅 한다면... 이 글은 Mobile카테고리? JS카테고리? React Native카테고리? AWS Mobile? AWS? AWS Amplify? AWS 개발 관련 된 것이니까 AWS Development? FCM이니까 Android? 이런게 여러개다. CDK를 이용한 EKS 배포 AWS Pinpoint를 이용한 Custom Event의 Raw Log를 S3에 수집하자 등등.. 뭔가 두서없이 글을 막 쓰다보니 카테고리 구분짓기가 너무 어렵다. 내가 정리를 잘 못하기 때문인 것..

아마존(Amazon)의 면접은 14가지 Leadership Principles 에 대한 질문과 응답으로 구성돼 있는것으로 알려져 있다. 각 항목과 질문 예시를 살펴보자. Customer Obsession / 고객에게 집착한다 리더는 고객에서 시작해서 거슬러 올라가며 일한다. 고객의 신뢰를 얻고 유지하기 위해 열심히 일한다. 경쟁자들에게 신경을 쓰기도 하지만, 리더는 오직 고객에게 집착한다. 제프 베조스의 일화를 살펴보면 나온다. 베조스의 제 1원칙 베조스는 항상 말한다. "가장 중요한 것은 고객에 집중하는 것이다. 고객이 앞으로 무엇을 원할지 예측하는 것이 아마존의 존재 이유이다. 경쟁 회사를 볼게 아니라 고객을 보면서 경영을 한다" Q1) 가장 어려운 고객은 누구였나요? Q2) 고객의 기대를 충족시키지..

처음보는 프로젝트의 소스 코드 해독을 위한 팁 모든 이에게 적용된다고 보긴 힘들다. 누구는 탑다운이 편하고 누구는 바텀업이 편하기 때문이다. Unit Test가 있다면 핵심 기능을 하는 TC를 따라가면 해독이 매우 용이하다. 핵심 클래스의 생성자가 어느 클래스로부터 생성되는지 찾는다. A와 B 클래스가 핵심 클래스라고 한다면, 이 클래스의 생성이 어디서 이루어지는지 (new A, new B 로 검색) 확인하면 객체간의 Dependency 관계가 어느정도 눈에 파악된다. 팁으로, 탑다운이 아닌 바텀업으로 소스를 보고자 할때 가장 유용한 기능은 Find Usage 기능이다. 행위의 Trigger가 되는 Method를 찾는다. Command패턴의 경우 Execute를 Override한 메소드를 살펴보면 되고,..

특히 GUI 프로그래밍을 할 때 로직 부분과 GUI 부분을 쉽게 분리하기가 힘들다 또 함수를 짜다보면, 하나의 함수는 하나의 일만 하는게 제일 좋지만코딩이란게 그리 쉽던가, 어쩔때는 데이터를 변경하면서 ui를 바꿔야하는때도 있고ui가 바뀌는 핸들러에서 무언가 값을 조작해줘야하는 일도 있고..결국 다 메소드(함수) 로 분리가 잘 돼줘야 중복 코드 짤 일도 없고 적재 적소에 함수를 적절하게 잘 호출해주게 된다. 그럼 함수를 어떨때 나누느냐? 일단 크게 로직 적인 부분을 짤때를 예로 들어보자 나의 경우는 GUI프로그램을 짤 때 기본적으로 CUI 환경을 염두에 두고 함수 설계를 한다. 이렇게 할 경우의 장점은 로직 함수의 처리에 있어 기본적으로 view와의 분리가 완벽하게 된다. (함수 내에서 ui를 처리할 필..

최근 host - client 시스템 하나를 설계하고 개발하고 있다. host는 당연히 하나고, client는 여러대의 device들이다. 이들은 어떤놈은 wifi로 연결되고, 어떤놈은 tcp/ip (socket)로 연결되고 어떤놈은 serial, 어떤놈은 bluetooth로 연결된다. 연결방식도 복잡하지만, 통신 방법은 더 복잡하다. 단일 규약이 아니다. 어떤건 A규약을 사용하고 어떤건 B규약을 사용한다. 예를 들어 A규약을 쓰는 놈이 메세지를 읽는 방법이 (0x72 0x30) 이라면 B규약을 쓰는 놈은 메세지를 읽을때 (0x23 0x45 0x3a)를 사용한다. host 시스템에 client device를 연결한다. 그리고 어떤 connectivity(tcp/ip, socket 등)를 쓰는지, 그리고 ..

작게 시작한 프로젝트 규모가 점점 커지면서 리팩토링을 하게 됐는데 크고 작은 실수가 몇개 있었다. 덕분에 엄청난 시행착오를 거쳐 오랜 시간걸렸다. 몇가지 실수를 적어 보겠다. 첫번째는 메세지 전달 부분에서의 의존성을 줄이지 못한 부분이다. 각 모듈을 DLL로 쪼개는 리팩토링을 감행 하였는데 여기서 각 DLL 간 의존성을 0으로 하고, 최대한 독립적으로 General 하게 코딩하려 했다. A DLL에서 B DLL로 메세지를 전달 하는 과정에서 상수값을 어쩔 수 없이 공유하게 됐는데, 차라리 A DLL에 SetListener 메소드를 구현하고, B DLL에서 해당 메소드를 콜해서 원하는 핸들러를 등록하게 했어야 했다. 두번째는, Data와 Controller를 완벽하게 분리 하지 못했다. 기본적으로 Data..

삼성소프트웨어멤버십 하던 시절에 진행했던 유니코드의 다양한 이해 세미나