🤝 Sponsor - Rocanews

At the end of 2020, the 3 co-founders of RocaNews quit their jobs because they hated the news. Don't we all?

The news was negative, partisan, and alarmist. They wanted news that didn't obsess over politics. They wanted to know what was going on in the world, but wanted facts – not opinions. So they created RocaNews.

Now 1.2M+ people start their morning with RocaNews. Join them by reading Roca’s free daily newsletter, designed to make you the most interesting person at Happy Hour in 5 minutes.

Subscribe Today!

🏗️ Projects

LiveTerm

Build terminal-styled websites in minutes! Highly customizable, easy-to-use, and minimal terminal styled website template, powered by Next.js.

language: TypeScrpit, stars: 1,817, issues: 0, last commit: May 20, 2022
repo: github.com/Cveinnt/LiveTerm
site: liveterm.vercel.app

Immich

Immich is an open-source, self-hosted Google Photos alternative that can backup photos and videos directly from your mobile phone. Features include auto-backup, multi-user support, object detection, and many more. Works with Android and iOS.

language: Dart, stars: 1,222, issues: 17, last commit: May 20, 2022
repo: github.com/alextran1502/immich
developer: github.com/sponsors/alextran1502

LocalStack

LocalStack is a cloud service emulator that runs in a single container on your laptop or in your CI environment. With LocalStack, you can run your AWS applications or Lambdas entirely on your local machine without connecting to a remote cloud provider.

language: Python, stars: 40,935, issues: 336, last commit: May 20, 2022
repo: github.com/localstack/localstack
site: localstack.cloud

🎤 Interview With Waldemar of LocalStack

Hey Waldemar! Thanks for joining us! Let’s start with your background. Where are you from, how did you learn to program, where have you worked in the past, and what languages or frameworks do you like?

Originally from Vienna/Austria, started to program in BASIC and Perl at the age of 13, and got my degree in Computer Science at TU Vienna. Later worked as team lead at Atlassian (Sydney/AU), as tech lead and architect at IBM (NY/US), and as CTO in a Swiss fintech startup (Zurich/CH), among other roles.

What’s your most controversial programming opinion?

I usually put a strong emphasis on the DRY (don't repeat yourself) principle - trying to introduce abstractions to reduce redundancy and duplication. I’ve been involved in several interesting technical discussions with people who disagree with DRY or don’t give it as much importance as I have.

What are you currently learning?

Learning to build a scalable product, community, and business from a successful open source project.

What have you been listening to lately?

The latest tracks in my playlist right now are from Thievery Corporation, J.S. Bach, and Khruangbin.

How do you separate good project ideas from bad ones?

Mostly by looking at the people behind the ideas, how they convey the story, and how much passion they have for the project and the domain. Also, it can help if there are some numbers or early indications of the traction of a project/idea (e.g., community adoption).

Where did the name for LocalStack come from?

LocalStack is a portmanteau that combines “local development” with “cloud stack”. It ended up being a reasonably catchy name that was easy enough for most people to remember and associate with. Also, I used to experiment with OpenStack a couple of years ago, so that may have influenced the name as well. :) 

Who, or what was the biggest inspiration for LocalStack?

Allowing people to work - literally - offline when developing their cloud applications (e.g., during their daily commute on the train). 

Are there any overarching goals of LocalStack that drive design or implementation? If so, what trade-offs have been made in LocalStack as a consequence of these goals?

We strive to become the leading platform for local emulation of cloud APIs and managed services. The design of LocalStack is focused on plug-ability/extensibility, compatibility, and ease of use. One of the biggest trade-offs we need to make on a daily basis is prioritization - solidifying, refactoring, and optimizing the existing codebase versus implementing new features and APIs. Another tradeoff is the choice of programming language - LocalStack is predominantly written in Python, which is a fantastic language for quickly delivering new value and applying very flexible programming mechanisms (e.g., runtime patching), but it certainly comes with its tradeoffs in terms of performance, code structure, and scalability.

What is the most challenging problem that’s been solved in LocalStack, so far?

One challenge is certainly to achieve maximum parity with AWS cloud APIs, allowing users to deploy arbitrary applications and cloud workloads on their local machine, while keeping the stack reasonably lightweight and performant.

Are there any competitors or projects similar to LocalStack? If so, what were they lacking that made you consider building something new?

There are a couple of open source projects that we build upon and integrate with. In general, there are quite a few cloud development frameworks that allow one to develop apps locally (e.g., Serverless, or Architect framework) but they are usually quite opinionated about how apps should be developed (whereas LocalStack is more generic and works on the level of cloud APIs). There are also a few really nice frameworks for serverless application observability and debugging (e.g., Thundra) - they are not competitors per se, but rather orthogonal and integrate nicely with LocalStack.

What is your typical approach to debugging issues filed in the LocalStack repo?

The first step is usually to create a small project or integration test that replicates the user issue. We then use different debugging mechanisms to inspect the requests and response messages exchanged between the client application and the LocalStack APIs. We then implement new functionality or contribute a bug fix to the repo, making sure that it is covered by some tests, to avoid regressions. When it comes to debugging LocalStack issues, the “devil is often in the details” - so it is important to pay attention to even the smallest details like case sensitivity, schema/date formats, HTTP header mismatches, etc.

What is the release process like for LocalStack?

LocalStack is shipped as a Docker image which can be easily started on any system with Docker installed. We’ve been using semantic versioning (with tagged releases every ~2 weeks), but we’re planning to adopt CalVer in the near future, as we have a fairly linear change history with a strong focus on backward compatibility.

Is LocalStack intended to eventually be monetized if it isn’t monetized already? If so, how? If it’s already monetized, what is your main source of revenue?

Yes, in addition to the open-source community version, we’re also offering a Pro and Enterprise version with advanced APIs, team collaboration features, a Web UI to manage local resources, as well as dedicated tech support.

What is the best way for a new developer to contribute to LocalStack?

Browsing through the backlog on Github and trying to pick up an issue/bug fix to work on (we try to attach the good-first-bug label to some of the simpler issues). Also, contributing new demos and sample apps can be a great way to become familiar with the framework and the community.

Are there any other projects besides LocalStack that you’re working on?

I’ve been working on a framework called ModelOps - enabling DevOps pipelines to manage the end-to-end lifecycle of AI models (didn’t have too much time to work on it recently, though). Also, I’ve been involved in CognitiveXR (cognitivexr.at), a platform to enable smart-city-scale cognitive applications by seamlessly integrating augmented reality, edge computing, and AI.

Do you have any suggestions for someone trying to make their first contribution to an open-source project?

Don’t be shy, try to follow the policies and best practices of the open-source project, and start with a simple task (even adding some documentation can often be super helpful!). React positively and proactively to PR feedback - don’t take criticism personally, always keep a friendly tone, and stay professional and to the point. Also, try to be as clear as possible, and leave no room for interpretation in your communication - everyone is extremely busy, and the more points you can clarify upfront, the more efficient the process becomes overall.

Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!

Leave a comment

Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at console.substack@gmail.com or mention us @ConsoleWeekly!