11월, 2022의 게시물 표시

Windows의 기본 VPN설정으로 Netplix접속시 주의사항

목적 외국에서 한국 Nexplix를 보고 싶다. 하지만 유료 VPN은 별로 사용하고 싶지 않다. 수시로 접속 거부를 당하면서 요금을 지불하고 싶지는 않다. 해결책 부모님 댁에 VPN서버를 지원하는 무선공유기를 한대 설치해 드리고 나는 외국에서 VPN으로 접속하여 Nexplix를 감상한다! 상황 공유기에 설정한 VPN에 iPad, Macbook으로 접속하면 문제 없이 한국 Netplix로 접속되는것을 확인했다. Windows11에서는 기본 VPN으로 iptime의 VPN에 접속하면 일본 Netplix로 접속 된다. 원인 처음에는 VPN의 Split Tunneling 문제가 아닐까 싶었다. Windows의 VPN설정에서는 Split Tunneling설정이 보이지 않았으므로 Power Shell에서 확인해 보았지만 Split Tunneling은 설정되어 있지 않았다.  결론부터 말하면 원인은 DNS서버였다. 이유는 모르겠지만 MacBook에서는 VPN접속시, DNS서버도 VPN서버의 DNS가 자동으로 설정되었는데 Windows11에서는 DNS서버가 변경되지 않아 한국 지역으로 인식되지 않았던 것으로 추측. Solution Windows11의 VPN접속 설정에서 접속시의 DNS서버를 한국의 공유기 IP로 지정을 해주었다. 그리고 IPv6이용설정을 해제하여 IPv4만 이용하도록 설정하니 문제 없이 접속되었다. 다음 문제 미니PC를 한대 구매하여 모든 설정을 마쳤지만 매번 키보드/마우스로 조작하는게 귀찮아 Remote Desktop으로 접속하는 것을 생각했다. 미니PC에 접속할때는 iPad를 이용할 계획인데 현재 찾아본 바로는 Console접속을 지원하는 Application이 없는 듯 하다. RemoteDesktop으로 접속하면 현재 TV에 연결해 놓은 세션은 꺼져버리니 Console로 접속가능한 어플리케이션이 필요하다. TeamView를 이용하니 어느정도 문제가 해결되긴 했지만 여기저기 조그마한 문제점들이 있어 고민중.

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것" (twitter.com/jasoncwarner)

 geeknews에서 가져온 내용. 원본 링크는 아래에 기재. https://news.hada.io/topic?id=7839 지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것 "Monolith > apps > services > microservices" 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음 둘째, 단계가 중요함 5-50인 회사라면 그냥 Monolith로 가세요 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면.. 먼저 정의(Definition) 부터 monolith - xyz.com apps - abc.xyz.com services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리) microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함 Why ? : 기본적으로 "Speed & Risk" 때문 #1 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움 #2 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움 #3 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함 #4 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함 이론적으로는 이게 맞고, 일이십개 ...

일런 머스크의 '미친 생산성을 위한 6가지 법칙' (twitter.com/LiamKircher)

 이 또한 geeknews에 올라온 내용이다. 원문 링크는 아래에 기재하고 개인용도로 관련내용을 이곳에 옮겨적는다. https://news.hada.io/topic?id=7860&utm_source=slack&utm_medium=bot&utm_campaign=T13KRBZU4 #1 대규모 미팅은 피하라 참여자가 많은 미팅은 시간과 에너지의 낭비 토론을 방해 사람들을 방어적으로 만듦 모든 사람이 기여하기엔 시간이 부족 모든 사람에게 가치를 주는게 아니라면 대규모 미팅을 잡지 말 것 #2 미팅에 기여하는게 없다면 중간에라도 나가라 미팅이 당신의 "자료나 정보(Input), 가치, 의사결정"을 필요로 하지 않는다면 미팅에 참여할 이유가 없음 미팅 중간에 나가는 것은 무례한게 아님. 사람들의 시간을 낭비하는게 무례한 짓 #3 명령 체계(Chain of Command)는 잊어라 동료들과 직접 대화할 것 슈퍼바이저나 매니저를 통하지 말 것 빠른 소통이 빠른 의사 결정을 만듦 빠른 의사결정은 곧 경쟁 우위임 #4 똑똑해 보이려 하지말고, 명확히 할 것 기술 용어(Technical Jargon)와 이상한 단어(넌센스)는 피할 것 이런 것들은 의사소통을 느리게함 간결하고(Concise), 요점을 설명하는(To the Point), 이해하기 쉬운 단어를 선택할 것 똑똑해보이려 하지 말고, 효율적으로 일할 것 #5 미팅을 자주하지 말 것 모든 사람의 시간을 낭비하는 데 이것보다 좋은게 없음 미팅은 '협업하고, 직면한 문제를 돌파하고, 긴급한 문제를 해결할 때" 사용할 것 이슈가 해결되었다면, 자주 미팅하는 것은 더 이상 필요없음 대부분의 이슈는 미팅없이도 해결가능. 미팅 대신 '문자나 이메일을 보내거나, 슬랙/디스코드 채널에서 얘기할 것' 필요한게 아니라면 팀의 워크플로우를 방해하지 말 것 #6 상식적으로 해라 만약 회사 규칙이: 말이 안 되거나 일을 진행하는데 도움이 안되거나 당신의 특정 상황에 맞지 않는 다...