cloud-native open source developers community
by Justin Yoo in Dotnet · 10 min read
애플리케이션 혹은 시스템 개발 업무는 보통 혼자서 하기 보다는 여럿이서 팀으로 작업하는 경우가 대부분이다. 팀을 꾸릴 때 제일 처음으로 하는 것들 중 하나가 개발환경 설정인데, 이것은 공통의 개발환경을 맞춰서 코드 품질을 높이기 위한 것이기도 하고, "내 컴퓨터에서는 되는데요?" 와 같은 문제를 사전에 방지하기 위한 것이기도 하다. 코드 스타일의 일관성을
by Justin Yoo in Sdk Support-on-azure · 8 min read
레거시 방식의 애저 서비스 버스 SDK(WindowsAzure.ServiceBus)에서는 메시지 전처리 및 후처리를 위해 이벤트 핸들러를 이용한다. 예를 들어 동기식 메시지 전처리를 위해서는 OnSend를 사용하고 비동기식 전처리를 위해서는 OnBeginSend와 OnEndSend를 구현해야 한다. 마찬가지로 메시지 후처리를 위해서도 같은 접근 방식을
by Justin Yoo in Sdk Support-on-azure · 4 min read
애저 클라우드에서 메시징 기반 아키텍처를 구상한다면 반드시 필요한 것이 바로 애저 서비스 버스이다. 이 서비스를 사용하기 위해서는 보통 SDK를 이용하면 되는데, 닷넷 쪽에서 SDK를 찾다보면 두 가지가 보인다. Microsoft.Azure.ServiceBus WindowsAzure.ServiceBus 첫번째 라이브러리는 .NET Standard
by Justin Yoo in Visual Studio-alm · 16 min read
애저 데브옵스에서 CI/CD 파이프라인을 구성하다보면 보통 반복적인 작업들이 많다. 이게 타스크 수준일 수도 있고, 작업 수준일 수도 있고, 스테이지 수준일 수도 있는데, 코딩을 할 때는 반복적인 부분을 리팩토링 한다지만, 파이프라인에서 반복적인 부분을 리팩토링할 수는 없을까? 물론 있다. 파이프라인을 리팩토링할 수 있는 포인트가 최소 여섯 군데 정도
by Justin Yoo in Enterprise Integration · 9 min read
얼마 전에 MS 팀즈가 슬랙을 제치고 기업용 협업 도구 시장의 최강자로 떠올랐다는 신문 기사가 있었다. 여전히 기업용 협업 도구 시장의 파이는 계속 커지는 중이므로 팀즈와 슬랙 중 어떤 것이 더 나은가에 대한 논의는 여기서는 크게 의미가 없다. 둘 다 이 파이의 크기를 키우는데 혁혁한 공을 세운 도구들이기 때문이다. 다른 기업용 협업 도구와 마찬가지로
by Justin Yoo in Enterprise Integration · 11 min read
아웃룩이나 오피스365 메일을 쓰다 보면 항상 고민인 것이 메일 필터링 규칙이 조금 더 나아졌으면 좋겠다는 생각이 많이 든다. 특히나 멀쩡한 이메일이 스팸메일로 분류되는 경우도 지메일에 비해 상당히 많아서, 이런 저런 고민을 하면서 어떻게 하면 좀 더 손쉽게 이 문제를 해결할 수 있을까 하는 방법을 찾아봤다. 개인적으로는 이메일을 받는 즉시 받은 편지함