Posts

IntelliJ를 사용하는 개발자라면 알고있어야 할 실무에서 많이 사용되는 필수적인 단축키들을 정리해보았다. 여기 나오는 단축키들만 마스터해도 생산성이 팍팍 올라가고 어디가서 IntelliJ 좀 쓸 줄 안다고 어깨에 힘줘 볼 수 있을것이다. 추가로 단축키 외에도 아래 내용 중에 소개하는 scratch 기능을 이용하면 간단한 코드들을 빠르게 작성하고 테스트 볼 수 있어서 생산성을 많이 올릴 수 있으니 사용해 보는것을 강력히 추천한다. CMD + N : 제네레이트 (컨스트럭터, 게터 셋터) CMD + SHIFT + N (scratch 파일 생성) 사용예: 코드 선택된 상태로 누르면 해당 영역이 그대로 복사됨 간단하게 언어 특성이나 코드 실행결과를 빠르게 테스트 보는데 좋음 사용예: json 생성 후 CMD + OPT + L 하면 auto formating 실행/디버깅 CTRL + D : 디버깅 CTRL + OPT + D : 여러 configuration들이 존재할때 특정 configuration 선택할 수 있는 창을 띄움 CTRL + SHIFT + D : 현재 커서가 있는 파일 또는 유닛테스트를 build & debug 참고: 위 세가지 단축키의 D 대신 R을 입력하면 디버깅 대신 실행 모드로 동작 F8: 디버깅 중에 누르면 next line으로 진행 CMD + OPT + R : 현재 브레이크포인트에 멈춰있는 어플리케이션을 Resume CMD + F8 : 현재 커서에 브레이크 포인트 토글 CMG + , : InterlliJ 전체 설정 CMD + ; : 프로젝트 설정 OPT + ENTER : 밑줄친 곳에서 추가액션 lint 적용, 오타 보정, error correction 등등 다양한 액션 가능 아이템 찾기 CMD + (SHIFT or OPT) + O : find symbols, files CMD + SHIFT + a : find actions (인텔리제이의 수많은 메뉴와 기능들을 찾기 힘들때는 이곳을 통해서 검색할것) SHIFT 2회 : find all CMD + E : 최근 열었던 파일 목록 텍스트 찾기 CMD + SHIFT + F text 전체 찾기 scope 지정 가능 CMD + SHIFT + R text 전체 Replace CMD + F12 : current file’s structure 코드 찾기 OPT + F7 : find usage CTRL + OPT + H: call hierachy CTRL + H: type hierachy CMD + Click: Jump to definition CMD + OPT + Click: Jump to Implementation interface를 구현한 구현체들을 검색해서 이동 CMD + DELETE : 현재 커서가있는 한줄 삭제 OPT + F1 → 1 : 현재파일 프로젝트 트리에서 열기 SHIFT + F6 : 이름 바꾸기 (refactor) CMD + SHIFT + V : 클립보드 히스토리 보기 네비게이션 CMD + [ : 뒤로 이동 CMD + ] : 앞으로 이동 윈도우 분할해서 사용중일때 (단축키 없음) Move to Opposite Group 현재 열려있는 파일을 반대편 윈도우로 옮긴다.

윈도우에서 열심히 개발을 하다가 맥을 처음 쓰는 개발자라면 맥 환경이 개발자에게 편하다라는 말은 많이 들었을 것이다. 하지만 막상 맥으로 옮기고나서 익숙했던 윈도우용 필수 유틸리티들의 대체품을 빨리 찾지못하면 작업 효율이 오르지 않아 답답할 것이다. 이런 답답함을 풀어드리기 위해 이 포스트를 작성해 보았다. 물론 맥을 원래 부터 쓰고있었지만 새롭게 개발을 시작하는 분들에게도 유용하리라 믿는다. (덧: 여기서 소개한 앱 외에도 개발 관련해서 좋은 맥 앱들이 있으면 댓글로 추천부탁합니다! 제가 직접 써본 후 글을 업데이트 하겠습니다.) ...

AWS의 Application Load Balancer(LB)를 통해 실제 서버가 연결되어있을 때 서버가 죽어서 응답을 해주지 않으면 LB에서 대신 502 Gateway Error로 응답을 해준다. 이때 502 HTTP status code와 함께 LB의 디폴트 에러페이지가 응답으로 나가게된다. 개발을 하다보니 이 디폴트 에러를 보여주는 대신 customize 한 응답을 내려줘야 할 필요가 생겨서 리서치를 해보았으나, 안타깝게도 설정이 불가능 하다는 것을 확인했다. LB에서 request URL path에 따라서 리디렉션이나 포워딩 또는 정해진 스태틱 응답을 내보내는 것은 설정 가능하지만, 특정 에러코드에 대해서 에러 응답 내용을 변경하는 것은 불가능하다. ...

https://github.com/colinbjohnson/aws-missing-tools/tree/master/ec2-automate-backup 위 스크립트를 이용하여 다음과 같은 명령어를 cron이나 jenkins job으로 등록하여 매일 한번씩 호출되게 해준다. ec2-automate-backup.sh -n -p -r ${region} -v ${ebs_volume_id} -k ${delete_after_days} -n 스냅샷 백업시에 태그에 있는 내용들을 name 필드에도 설정 -p 스냅샷에 태깅된 시간보다 현재시간이 더 큰경우 스냅샷 삭제(purge) -r 지역 설정 (ex: ap-northeast-1) -v 백업하려는 EBS volume ID (ex: vol-00cb123456789) EC2 콘솔에서 확인 가능 -k 스냅샷 생성시 며칠 후 까지 보관하면될지 시간을 태깅 (ex: 7, 7일) 예를 들어, 아래와같은 스크립트를 매일 한번 실행하면, ap-northeast-1에 있는 vol-00cb123456789 스토리지에 대한 스냅샷을 매일만들면서, 7일 이상 된 스냅샷은 자동으로 삭제해 준다. ...

AWS에서 Elastic Beanstalk나 EC2에서 직접 오토스케일링 설정해서 사용하다보면 트래픽이 늘었을 때 인스턴스의 갯수가 늘어났다가(scale out) 트래픽이 줄어들면 불필요해진 자동으로 인스턴스를 shutdown하게 된다(scale in). 이때 shutdown 될 인스턴스에 연결되어서 진행중인 요청(in-flight request)이 있다면 어떻게 될까? 먼저 해당 인스턴스로 새롭게 추가 요청이 가지 않도록 연결된 로드밸런서(Load Balancer, LB)에서 shutdown 될 등록 해제 프로세스(Deregistration process)를 시작한다. 이때 LB에서 인스턴스로의 연결이 열려있는것이 있다면 설정된 시간동안 연결이 자연스럽게 종료 되도록 기다려준다. (이를 connection draining 또는 deregistration delay라고 부른다.) 이 시간을 초과하면 열려있는 연결이 있더라도 강제로 종료한 후 LB에서 완전히 제외되며 인스턴스를 종료시킨다. ...

원격 서버에 ssh로 접속한 후 실행시간이 긴 명령어를 수행중에 ssh 연결을 끊거나 네트워크 오류로 인해 연결이 끊어지게되면 실행중이던 명령어도 같이 종료되어버린다. ssh를 통해 실행된 shell에서 실행한 프로세스는 shell의 child 프로세스로 연결되어있기 때문에 이런 현상이 발생하는데, 이를 방지하려면 child 프로세스를 parent에서 detach하여 독립된 프로세스로 만들면 된다. 이를 위해 해당 명령어를 nohup 등의 명령어를 이용할 수도 있지만 tmux 명령을 사용하면 가장 손쉽게 해결 할 수 있다. 설치 Ubuntu에서는 다음 명령어로 설치가 가능하고, 다른 계열의 OS에서는 해당 OS에맞는 패키지 매니저를 사용하면 된다. ...

iOS/Android 모바일 디바이스들 사이에서 P2P 형태로 데이터 전송을 하는 방법에 대해 리서치 할 일이 있어서 알아본 내용을 간단히 공유합니다. 네트웍 타입별 Android/iOS P2P 연결 가능성 체크 Bluetooth 애플 MFi인증 디바이스만 iPhone/iPod과 Bluetooth 연결 가능 MFi는 apple에서 accessary 제조업체들이 만든 하드웨어를 인증하는 제도 (안드로이드는 인증되지 않음) Bluetooth Low Energy BLE는 애플 MFi인증 제약이 존재하지 않아서 안드로이드/iOS간 연결 가능 BLE는 말그대로 저전력으로 설계된 spec이기때문에 전송 속도가 매우 느림 iOS는 모두 지원하지만 안드로이드 디바이스별로 지원 스펙이 다름 (제대로 지원안하는 경우도 있음) BLE의 최대 전송속도 Apple guide line을 따르는 BLE 디바이스라면 디바이스에따라 이론적인 최대 전송속도 8~32kbps 정도가 한계 packet interval, MTU size 파라메터에 맞춰 application이 전송하는 데이터를 완벽하게 fit 시켰을때 나올 수 있는 이론적인 수치. 실제로는 더 느릴것 같음 https://devzone.nordicsemi.com/question/3440/how-do-i-calculate-throughput-for-a-ble-link/ WiFi 동일 네트워크 라우터에 접속한 디바이스들사이에서 P2P 연결 가능 multicast를 지원하는 라우터인경우 mDNS(ex: Apple Bonjour)를 이용하여 자동으로 동일 네트웍상의 디바이스를 찾아 주는 것이 가능 개인적으로 사용하는 office/home wifi가 아닌 WiFi hotspot 같은 공용 라우터의 경우 P2P 연결이 안될 가능성이 높음. 뮤직 서버에서 P2P연결 시작만 중계하는 NAT 뒤에 연결된 디바이스들도 연결이 가능하긴 함 UDP 홀펀칭 등의 방식을 사용하면 어느정도 커버가능하긴하지만 100% 연결 보장은 힘듦 참고자료 Android/iOS Local Radio Interop 3rd party frameworks Google Nearby Bluetooth, BLE, WiFi 등의 연결방식을 상황에따라 적절히 조합해서 근처에 있는 device를 찾아서 연결해주는 framework 아래 두가지 API set이 있는데 상황/용도에따라 다르게 사용 Message API iOS/Android small payload only through google server (devices do have to be connected to the Internet). 음원전송은 불가능 Connection API Android ONLY P2P connection: message, file, stream transfer support 음원전송에 적합 http://p2pkit.io 유료 framework $0.01/ MAU Android/iOS 둘다 서포트 하지만 GoogleNearBy 와 동일하게 대역폭한계로 음원전송에는 부적합해보임 20 messages per second and cannot exceed the size of 100KB

엑스코드 플레이그라운드(Xcode Playground)에서 간단하게 코드를 테스트 해보고 싶은데 해당 코드가 특정 cocoapod 라이브러리에 의존성이 있는 경우 cocoapods-playgrounds 명령어 도구를 사용하면 편리하다. 설치 및 사용 방법 설치 sudo gem install cocoapods-playgrounds 플레이그라운드 프로젝트 생성 cocoapods playgrounds podName 위 명령어를 실행하면 위 라이브러리가 연결된 워크스페이스가 자동으로 생성되고, 해당 워크스페이스 안에 우리가 사용할 수 있는 playground 파일까지 포함되어있으니 여기서 마음껏 테스트 해보면 된다. 여러 라이브러리 동시 참조 여러개 라이브러리에 의존성을 가지는 플레이그라운드 프로젝트를 만들고 싶을 경우, 라이브러리 이름을 컴마로 구분하여 붙여 써 둔다. ...

PAKE (password authenticated key exchange) PAKE는 두명 이상의 참여자가 패스워드 기반으로 암호화된 채널을 만들어서 서로 통신할 수 있게 해주는 암호학 적인 방법을 말한다. Balanced PAKE 참여자들이 서로 암호화된 채널을 만드는 과정을 위해 동일한 패스워드를 사용하는 방법 Augmented PAKE server/client 시나리오에서 많이 사용된다. 서버는 어떤 password-equivalent 데이터도 저장하지 않는다. (서버는 password로 부터 계산된 값을 보관하고 있지만 이 값으로는 원래 password를 역추론할 수 없다. 이 외에도 password를 역추론 해 낼 수 있는 관련 정보는 저장하지 않는다.) 클라이언트가 서버에 인증을 시도할 때도 password를 역추론 해 낼 수 있는 직접적인 정보는 클라이언트에서 서버로 절대로 전송되지 않는다. 때문에 공격자가 서버의 데이터를 접근 권한을 탈취했다고 하더라도 해당 데이터로 부터 password를 brute force로 찾아내기 전에는 client를 impersonate 하는 것이 불가능하다. SRP (Secure Remote Password) Protocol SRP 프로토콜은 기존 특허를 피해서 만들어진 augmented PAKE의 한 종류이다. 인증 과정에서 password를 유추할 수 있는 직접적인 정보가 원격지로 전달되지 않아서 안전하다는 뜻으로 이름을 이해하면 될 것 같다. (이 이름이 지어진 정확한 기원은 찾지 못했다) SRP protocol은 여러번 수정되어왔고 현재는 revision 6a 버전이다. ...

쿠키(cookie)를 이용한 세션기반의 인증의 경우 특정 웹서버에서 세션 상태(session state)를 유지해야 하기 때문에 stateless 하지않다. 서버 로직이 Stateless가 아닌 경우 더 많은 요청을 처리하기 위해 동일한 서버의 숫자를 늘리는 스케일 아웃(scale out)에 적합하지 않다. 또한 도메인이 다른 서버에 대해서는 해당 세션 쿠키가 공유되지 않기 때문에 도메인이 다른 서버에 요청하기 위해서는 매번 새롭게 인증을 해야하는 불편함도 존재한다. 이 문제를 해결하기 위해 매번 http 요청마다 http header에 인증 토큰(authorization token)을 같이 보내는 형태의 방법을 많이 사용한다. 일반적으로 토큰 안에는 어떤 유저가 보내는 요청인지 구분하기 위해서 유저 ID값이 포함된다. 이 방법을 사용하면 서버쪽에서 세션 상태를 유지할 필요가 없어서 스케일 아웃에 적합하며, 도메인이 다른 서버에 요청하는 경우에도 동일한 토큰을 그대로 사용할 수 있다. 이러한 토큰기반의 인증을 적용하는 경우 악의적인 유저가 다른 유저ID를 사칭하는 것을 방지하기 위해서 토큰에 서명(signature)을 포함하거나, 대칭키 암호화를 적용한다. ...