1. Computing & Application AWS Lambda 소개: 이벤트 기반의 서버리스 컴퓨팅 서비스 해결문제: 짧은 실행 시간의 작업, 이벤트 처리, API 요청 처리 대체서비스: EC2, ECS, EKS 규모: 최소: 128MB 메모리, 실행시간 제한 15분 최대: 10GB 메모리, 동시실행 1000개 (증설 가능) AWS Fargate 소개: 컨테이너화된 애플리케이션을 위한 서버리스 컴퓨팅 엔진 해결문제: 컨테이너 운영에 따른 서버 관리 부담 제거 대체서비스: ECS/EKS with EC2 규모: 최소: vCPU 0.25개, 메모리 0.5GB 최대: vCPU 16개, 메모리 120GB 2. Integration & Orchestration ...

Looking to choose between UI Bakery and Retool for building internal tools? This comprehensive comparison breaks down the key differences between these popular low-code platforms, focusing on data handling, dashboard creation, and ease of use. Data Handling and Integration Retool Retool excels in data handling and integration, making it a strong choice for operating in-house data[1][4]. It offers: Powerful integration with external data sources, including APIs, databases, and cloud services Support for SQL/NoSQL databases and services like Firebase, MongoDB, and PostgreSQL Real-time data syncing between the UI and data sources UI Bakery ...

AppWrite vs. Supabase: A Comprehensive Comparison for 2024 In this in-depth analysis, we’ll explore the key differences between AppWrite and Supabase, two leading Backend-as-a-Service (BaaS) platforms, to help you make an informed decision for your project needs. Key Differences at a Glance Database: AppWrite leverages MariaDB, while Supabase is built on PostgreSQL Hosting Options: Both platforms provide cloud and self-hosted deployment options Language Support: AppWrite offers extensive support for 10+ languages, while Supabase specializes in TypeScript Performance: AppWrite demonstrates superior performance in stress testing Pricing Model: Both platforms feature free tiers with flexible scaling options Performance and Scalability Benchmarks Our comprehensive performance analysis reveals notable distinctions: ...

What are PostgreSQL Connection Modes? PostgreSQL offers two primary connection modes through connection poolers like PgBouncer: Session Mode (also known as Connection Mode) and Transaction Mode. Each mode serves different use cases and comes with its own set of advantages and trade-offs. Session Mode (Connection Mode) Explained Provides a dedicated database connection for each client throughout their entire session Only releases the connection when the client explicitly disconnects Maintains full compatibility with all PostgreSQL features and session-level commands Offers better reliability and compatibility with all PostgreSQL clients Consumes more database resources due to long-lived connections[2] Transaction Mode Deep Dive Maintains database connections only during active transactions Automatically returns connections to the pool after transaction completion Supports up to 10,000 client connections with minimal pool size Optimizes resource usage by efficiently managing idle connections Particularly effective for applications with numerous low-activity connections[2][3] Key Differences Between Session and Transaction Modes Connection Lifecycle: ...

Summary “고언어 프로젝트 가이드 A-Z"라는 주제로, 작은 프로젝트부터 엔터프라이즈 애플리케이션까지 Go 언어를 사용한 개발 방법론에 대해서 공유해보았습니다. 작은 프로젝트와 큰 프로젝트의 차이점을 설명하고, 작은 프로젝트에 적합한 간단한 코드 패턴을 소개하고, 기능 단위의 프로젝트를 위한 코드 패턴으로 Handler와 HandlerFunc 방식을 비교하고 각각의 장단점을 설명합니다. 엔터프라이즈 애플리케이션을 위한 코드 패턴으로 Domain Driven Design (DDD) 접근 방식을 소개하고, 각 레이어(Presenter, Handler, Usecase, Service, Repository, Recorder)의 역할과 장점을 설명합니다. NoSQL 데이터베이스 (DynamoDB) 사용 시의 모델링 방법을 간략히 소개합니다. 그리고 각 레이어에서의 테스트 코드 작성 방법과 모킹 도구인 counterfeiter의 사용법을 설명합니다. 애플리케이션 릴리즈를 위해 필요한 도구들(APM, 에러 모니터링, 메트릭 수집, 로그 서비스)을 소개하고 그 중요성을 강조합니다. ...

Summary Gophercon Korea 2023에서 발표한 “Go 도입 후, 4년 간의 기록"이라는 주제로 공유했습니다. Go를 도입하여 높은 트래픽을 처리하고 있으며, 주요 이슈와 해결 방법을 공유하고, Go를 통해 더 효율적이고 안정적인 서비스를 제공하기 위한 고민들을 공유합니다. Youtube Slideshare Go 도입 후 4년 간 기록 from Kyuhyun Byun

의사결정과 업무 진행은 프로덕트를 사용하는 고객관점에서 시작한다. 고객관점이라는 말은 많이 하지만 실제로 이게 왜 사용되어야 하는지 두 가지 방면에서 설명한다. 1. 조직에서의 의사결정 측면 이런 상황은 자주 발생했을 것이라 생각한다. 서로의 팀원(혹은 조직)의 생각이 달라서 벌어진 상황이다. 각 팀원은 수단에 대해서 집착을 하게 되고 이야기가 평행선을 달리게 된다. 이때 어떻게 이야기를 하면 문제를 해결할 수 있을까? 고객이 겪는 문제 상황에 대해서 먼저 정확히 이해하는 게 필요하다. 혹은 고객에게 꼭 필요하다고 생각하는 것에 대한 정의가 필요하다. 이를 문서 최상위에 “목표”로 정의를 한다. ...

The word “burnout” is being heard from all directions. It is being expressed as a reason for quitting, changing jobs, taking vacations, and as a way to express difficulties in life. I think everyone has heard it at least once, and I believe there have been times when you’ve wondered if you are experiencing burnout. When I hear people talking about burnout, I often feel a deep sense of sympathy, but I also feel that there is little I can do to help. I can suggest various things to try, but those who are experiencing burnout often don’t seem to hear those suggestions. So, while contemplating what to do, I decided to write this. ...

번아웃이라는 말이 사방에서 들리고 있다. 퇴사 사유로, 이직 사유로, 휴가 사유로, 인생에 대한 어려움을 표현하는 방법으로 표현되고 있다. 다들 한 번씩은 들어봤을 거라 생각한다. 그리고 내가 번아웃인 상태가 아닌지 생각해본 적이 있을 거라 생각한다. 옆에서 번아웃 이야기를 들을 때, 정말 안타까운 마음이 들면서도 크게 도와줄 방법이 없다고 느낀 적도 많다. 여러가지 시도해볼 수 있는 이야기를 하지만 번아웃에 빠진 사람은 이야기가 들리지 않는다. 어떻게 해야할까 고민을 하다가 이렇게 글을 써본다. “나는 번아웃이 온 적이 없다.” ...

배경 AWS re:Invent 2023에서 “A career journey for serverless and container cloud developers” 라는 공통주제로 발표를 준비했다. 여기서 중요하게 다루고자 했던 것은 소프트웨어 엔지니어가 이전의 프로그래머 시대와 어떤 부분에서 노력할 지에 대한 방향이었다. “소프트웨어 엔지니어의 덕목” 이라는 주제로 시장이 변화해감에 따라 엔지니어의 다른 역량들을 더욱 필요로 한다는 점을 표현하고 싶었고, 이런 관점을 공유함으로써 다양한 엔지니어의 성장에 조금이나마 기여하려 하였다. 발표 자료 및 영상 References https://youtu.be/gdqgk17T2Xw?si=sPEVjrg7rIFmeI4S