DEV Community: Daytona

Balancing Speed and UX: Making Reasoning AI Work for Users

Nikola Balic — Sun, 09 Feb 2025 00:00:00 +0000

Large Language Models (LLMs) are advancing beyond simple parameter scaling, incorporating complex architectures like mixtures of experts and enhanced reasoning capabilities.

Model makers such as OpenAI, Anthropic, Mistral, Google, and even DeepSeek are progressively releasing these reasoning models, which are now considered state-of-the-art (SOTA). These models excel at tackling complex, multi-step tasks, enabling solutions to challenges that were previously out of reach.

However, this advancement comes with a significant user experience (UX) challenge: increased response times.

The Power and Limitations of Reasoning Models

Reasoning models offer substantial benefits by providing detailed, accurate answers to intricate problems.

For example, while a standard LLM might succinctly answer, "The capital of France is Paris," a reasoning model would elaborate on the reasoning process: "Let me think. I remember learning in school that Paris is a major city in France. It's known for things like the Eiffel Tower, the Louvre museum, and the Seine River..."

This enhanced capability is invaluable for tasks such as debugging complex code, solving advanced mathematical problems, and navigating intricate dependencies.

Recently, I encountered persistent errors related to Pydantic validations imposed by dependencies. While multiple models struggled with these issues, the o1-mini model resolved them on the first attempt.

In such scenarios, the quality and reliability of the response outweighed the inconvenience of a longer wait time.

The UX Challenge: Speed vs. Quality

Despite their superior performance, reasoning models introduce latency due to the additional computational steps required for complex reasoning.

Users today expect immediate feedback, and any noticeable delay can be perceived as a weakness or inefficiency in the system. This perception poses a significant UX challenge: how to deliver high-quality, accurate responses without compromising on speed.

Instantaneous interactions have become the norm in digital communications, and users are likely to abandon or lose trust in tools that introduce delays, even if those delays result in better outcomes.

Balancing the need for quick responses with the demand for detailed, accurate information is crucial for the widespread adoption of reasoning models.

Leveraging Smart Model Routing

One effective strategy to address this challenge is smart model routing. This approach dynamically selects the most appropriate model based on the complexity of the user's query:

Simple Queries : For straightforward tasks such as summarization, translation, or basic question-answering, faster, less resource-intensive models can be employed. These models provide instant responses, ensuring a seamless user experience.
Complex Tasks : When faced with intricate problems that require deep reasoning, the system can route the query to more powerful reasoning models. Although these models may take slightly longer to respond, the accuracy and depth of their outputs justify the additional wait time.

Smart model routing ensures users receive a tailored balance of speed and intelligence, enhancing overall satisfaction while maintaining problem-solving quality.

Integrating Advanced Tools for Enhanced Workflows

In addition to model routing, integrating specialized tools can further mitigate UX concerns associated with reasoning models. Daytona SDKexemplifies how tool integration can enhance AI workflows:

Ephemeral Environments : Daytona SDK allows AI workflows or agents to create temporary, full-fledged environments—similar to throwaway laptops—for executing any piece of code. This capability enables models to handle tasks requiring real-time computation without significant delays.
Tool Adaptability : Agents can develop their own tools or install and invoke existing ones, providing flexibility in addressing a wide range of challenges. This adaptability ensures that the system remains responsive and efficient even when leveraging powerful reasoning models.

By incorporating such tools, developers can create a more responsive user experience in their AI products and service that leverages the strengths of reasoning models without compromising on the perceived speed.

Future Directions: Combining Strategies for Optimal Performance

The path forward involves integrating smart model routing with advanced toolsets like Daytona SDK. This combination can create a robust AI framework capable of:

Adaptive Responsiveness : Seamlessly switching between models based on task complexity ensures optimal performance and user satisfaction.
Scalable Problem-Solving : Leveraging specialized tools within ephemeral environments allows the system to tackle diverse challenges efficiently.
Enhanced User Trust : Delivering accurate, high-quality responses without unacceptable delays builds user confidence in AI systems.

Tools to the Rescue

The development of reasoning LLMs marks a significant advancement in AI, offering remarkable capabilities to solve complex problems. However, the associated increase in response times presents a UX challenge that cannot be overlooked.

By implementing smart model routing and integrating powerful tools like Daytona SDK, it is possible to harness the full potential of reasoning models while maintaining the immediacy that users expect. Striking this balance is essential for advanced AI systems' continued adoption and success in real-world applications.

How to Set Up Dev Environment on a Remote Machine

Nikola Balic — Tue, 16 Apr 2024 00:00:00 +0000

In this step-by-step guide, we'll walk you through setting up a dev environment with Daytona on a remote machine. Daytona is a powerful tool for creating and managing development environments on local or remote machines.

In this example, we'll use an Azure ARM machine with 8 vCPUs, 16 GB of RAM, and 300 GB of storage. You can play around with different server specifications or utilize whatever is accessible to you, maybe a homelab machine or that server you have tucked away in a corner. This will affect the number of workspaces you can have concurrently and the overall user experience.

TLDR:

Prepare Remote Machine: Install Docker and set permissions.
Configure Daytona Target: Add a remote machine as a target in Daytona.
Integrate Git Providers (Optional): Add GitHub or other providers to Daytona.
Create and Access Workspace: Use Daytona to create and open a workspace in VS Code.

Prerequisites:

Daytona daemon running on a local machine
A remote machine with Docker installed
SSH access to the remote machine
A GitHub account with a personal access token

Step 0: Set Up Daytona on Your Local Machine

Before you can start using Daytona with a remote machine, you need to ensure that Daytona is properly set up on your local machine. If you haven't installed Daytona yet, don't worry! We've got you covered with a simple one-liner that will get you up and running in no time.

Installing Daytona

To install Daytona on your local machine, open a terminal and run the following command:

(curl -sf -L https://download.daytona.io/daytona/install.sh | sudo bash) && daytona server -d

This command will download the Daytona installation script from the official Daytona website and execute it using sudo privileges. The script will guide you through the installation process, ensuring that all the necessary dependencies are installed and configured correctly.

Starting the Daytona Server

Once the installation is complete, the command will automatically start the Daytona server in the background using the -d flag. This means that you can continue using your terminal for other tasks while Daytona runs in the background.

If you ever need to stop the Daytona server, you can do so by running:

daytona server stop

And to start it again, simply run:

daytona server start

Verifying the Installation

To verify that Daytona is installed and running correctly on your local machine, you can run the following command:

daytona version

This command will display the currently installed version of Daytona, confirming that the installation was successful.

With Daytona now set up on your local machine, you're ready to move on to the next step and prepare your remote machine for use with Daytona. In the following steps, we'll guide you through the process of installing Docker on the remote machine, configuring the necessary permissions, and adding the remote machine as a target in Daytona.

Step 1: Prepare the Remote Machine

Install Docker on the remote machine if it's not already installed.
Add your user to the Docker user group by running the following command:

sudo usermod -aG docker $USER

Set the appropriate permissions for the Docker socket by running:

sudo chmod 666 /var/run/docker.sock

Step 2: Set Up the Target

Daytona utilizes the concept of targets, allowing you to add remote machines for deploying and managing development environments. By default, Daytona includes a Docker provider, enabling you to spin up environments on your local or remote machine inside Docker container.

Open the Daytona CLI and run daytona server target list to view the available targets.
Set a new target by running daytona server target set and selecting the desired provider (e.g., Azure).
Provide the necessary information, such as the IP address, username, and SSH key path.
Verify that the target was successfully added by running daytona server target list again.

Step 3: Add Git Providers (Optional)

This step is optional since you can simply paste the public Git URL to create a workspace from it.

If you want to use your own Git repositories directly with Daytona, you need to add a Git provider. We will use GitHub, but you can use GitLab, Bitbucket, Gitea, or Codeberg. You can also check our guide on how to select Git provider.
Go to your GitHub settings and navigate to the Developer settings.
Create a personal access token with the necessary permissions (repositories access).
Add the GitHub provider to Daytona using the generated access token and command daytona git-providers add.

Step 4: Create a Workspace

Run daytona create to create a new workspace.
Choose the desired Git repository, by pasting the repo URL or selecting it from the list of your repositories, and select the target on which you wish to run your workspace.
Wait for Daytona to pull the necessary images and set up the workspace.
Once the workspace is created, you can view it by running daytona list.

Step 5: Open the Workspace in VS Code

Set your preferred IDE by running daytona ide and selecting VS Code. You can also use web IDE powered by OpenVSCode or any of the JetBrains IDEs.
Run daytona code to open the workspace in VS Code.
VS Code will establish an SSH connection to the remote machine and set up the remote server.
Once the connection is established, you can start working on your files within the workspace.

Step 6: Open the Workspace from a Development Container Specification (Optional)

If your workspace includes a dev container specification, you can rebuild the container from it.
VS Code will download the necessary images and start the container.
Once the container is running, you can access the workspace and make changes on your code.

Conclusion

Congratulations! You have successfully set up Daytona with a remote machine and created a workspace. You can now work on your projects seamlessly, whether locally or on a remote machine.

If you encounter any issues or have further questions, feel free to contact the Daytona team in our Slack or add an issue to the Daytona GitHub repository.

How We Missed #1 on Product Hunt but Still Won Big

Nikola Balic — Fri, 29 Mar 2024 00:00:00 +0000

When we decided to launch our open-source dev environment management tool, Daytona, on Product Hunt, we had no idea what we were getting ourselves into. With just a week to prepare, we began an unusual trip that normally requires weeks of strategic planning.

TL;DR

Launching on Product Hunt with just a week's notice, we faced challenges and learned valuable lessons about authenticity, engagement, and measuring success beyond vanity metrics. Despite missing the #1 spot, we still reaped significant benefits and discovered the true value of a Product Hunt launch.

Following our project's successful launch on GitHub as open-source under the Apache license, we were riding a wave of success. With stars in our eyes and a week to prepare, we dove headfirst into the world of Product Hunt launches. But here's the twist - we gave ourselves just one week to prepare. Crazy? Maybe. Educational? Definitely.

Little did we know that our quest for Product Hunt glory would lead us down a path of epic struggle, valuable lessons, and ultimately, a newfound appreciation for the true value of launching on the platform.

But, reaching 5,000 GitHub stars in just three weeks secured us an engaged community and momentum, which we capitalized on to our advantage.

It's not about the numbers or the vanity metrics – it's about the connections you make, the lessons you learn, and the impact you have on your community.
Ivan Burazin, CEO and founder of Daytona

Debunking the Product Hunt Myths

Let's begin by debunking a few widespread myths regarding Product Hunt.

"You need a month to prepare for a Product Hunt launch." - False. We did it in less than a week, and you can too. It's all about focus, determination, and a healthy dose of caffeine.
"You need a fancy video and polished graphics." - Nope. While great visuals help, what matters most is showcasing your product's value and engaging with the community. We prepared our materials by repurposing the assets already available in our team's Figma and reusing an existing YouTube video.
"You need to know someone to succeed." - Absolutely not. We didn't have any insider connections, or hunters, just a genuine desire to share our project with the world.

Obstacles of Our Time-Constrained Product Hunt Launch

Our accelerated approach came with its own set of challenges:

Limited Time for Preparation: With only a week to prepare, we had to be laser-focused and prioritize our efforts.
Leveraging Existing Assets: Instead of creating entirely new assets for the launch, we had to be resourceful and repurpose what we already had. This meant adapting our existing content, graphics, and messaging to fit the Product Hunt format and audience.
Building Buzz on Short Notice: Typically, companies spend weeks or even months building anticipation for their Product Hunt launch. We had to compress this process into just a few days, which required a lot of creative thinking.

How We Epically Failed to Reach #1 on Product Hunt

The Epic Failure:

When our highly anticipated product launch on Product Hunt fell flat, it was a humbling and eye-opening experience. Here's three main reasons:

Underestimating the Competition: We thought we had a killer product, a solid strategy, and enough caffeine to power a small nation. But we quickly learned that the competition on Product Hunt is no joke. We were up against some seriously impressive products and teams with deep pockets and even deeper connections. To make matters worse, we found ourselves competing with trendy AI startups popping up left and right, promising to revolutionize every industry.
Overestimating Our Influence: We thought our existing community and open-source success would give us an advantage. Boy, were we wrong. Everything requires more effort than you might anticipate. Remember, communities are made up of individuals who can be forgetful or preoccupied with urgent matters of their own.
Ignoring the Subtle Art of Upvote Hunting: We naively believed that if we built it, they would come (and upvote). Little did we know that there's an entire art form dedicated to the subtle (and not-so-subtle) art of the deal on Product Hunt. We were like a bunch of amateurs trying to play chess against Hans Niemann.

The Brutal Honesty:

Despite our best efforts, we ended up at #2 on Product Hunt. And you know what? It was one of the best "failures" we've ever experienced. Here's why:

Exposure, Exposure, Exposure: We reached thousands of potential users, investors, and partners that we might never have reached otherwise.
Valuable Connections: Through our launch, we connected with countless developers, entrepreneurs, and industry leaders who shared our passion for making development environments more accessible and efficient.
Lessons Learned: Our "failure" taught us more about marketing, community building, and perseverance. We learned what works, what doesn't, and how to approach our next launch.

5 Key Benefits of Launching Your Dev Tool on Product Hunt

The Value of Being #2 (or #3, or #4...): While the allure of being #1 on Product Hunt is undeniable, the true value lies in the exposure, connections, and lessons learned along the way. Here are five reasons why being #2 (or any other spot on the top 10 leaderboard) is still a massive win:

Widespread Exposure: Despite being the second-ranking product, we were highlighted in Product Hunt's daily newsletter (top 10 gets in), which boasts an estimated reach of over 750,000 subscribers.
Social Proof: Being at the top on Product Hunt serves as a powerful social proof, validating your product's value and attracting potential users and investors.
Social Media Boost: Due to our massive social media presence on the launch day, we saw a 50% increase in Twitter impressions and a 10% increase in followers.
Multiplication Opportunities: Top products on Product Hunt often catch the attention of other creators, journalists, and influencers, leading to potential additional coverage.
Community Engagement: Topping the charts on Product Hunt can spark conversations and engagement within the tech community, providing valuable feedback and insights.

And one bonus point: Bragging Rights - Let's be honest – being able to say your product was ranked top on Product Hunt is a pretty cool feat.

The Product Hunt Launch Day Frenzy

On the day of the launch, the energy was palpable, like a scene straight out of a heist movie. Our team, was ready to jump on any opportunity to engage with the Product Hunt community. I, fueled by a steady drip of caffeine, was answering questions and comments with the speed of a speeding bullet. We even had a secret weapon: a stash of memes, ready to be deployed at a moment's notice, adding an element of playfulness to our interactions.

Throughout the day, I dedicated 20 hours to responding to messages, comments, and publishing updates across our social media channels. Although exhausting, this experience taught me the invaluable lesson of being present and responsive during a product launch.

Worthy mention — One of the great tools that helped us track our launch progress throughout the day was Hunted Space. It gave us a clearer understanding of how to understand the leaderboard mechanics and the fluctuations in upvotes.

As the day drew to a close, we were left in the #3 spot, which left us perplexed for a few hours. Unbeknownst to us, one of the other products had gained an astounding number of upvotes in the final minutes, propelling them to the coveted #1 position. This sudden shift caught the attention of the watchful team at Product Hunt, who promptly investigated and corrected the anomaly in the upvote count.

After the final tally, we were delighted to discover that we had safely landed in the second-place spot, earning the silver medal. This outcome was a testament to the hard work and dedication our team had poured into the launch, as well as the recognition from the Product Hunt community.

Step-by-Step Launch Preparation Guide

To those considering launching on Product Hunt, we encourage you to define success holistically, focus on authenticity, engage with the community, leverage your existing audience, and learn from the experience.

Set your launch date and commit to it, even if it is in two days. No backing out now!
Gather your assets. Screenshots, GIFs, and a concise description of your product are essential.
Craft your pitch. Tell your story, highlight your product's unique value, and don't be afraid to show some personality.
Rally your troops. Notify your existing community about the upcoming launch and ask for their support.
Get some rest. Trust us, you'll need it.
Launch day: Buckle up and enjoy the ride! Block off some time in the team's calendar to ensure everyone participates in engaging with your social media posts, giving them an initial boost.

One End Game Tip for Winning Product Hunt

If you pushed me into a corner and forced me to share just one genuine tip, it would be this:

Cross-promote like crazy: Share your Product Hunt link on every relevant platform, from social media to industry forums. You never know where your next upvote will come from.

Our Product Hunt Launch Adventure with Daytona Ends (for now)

Launching on Product Hunt in just one week was a wild ride, but we wouldn't have it any other way. We learned valuable lessons that success isn't just about vanity metrics, but about the connections we make, the lessons we learn, and the impact we have on our community.

So, if you're considering a Product Hunt launch, don't let the myths hold you back. Embrace the unconventional, stay true to yourself, and most importantly, have fun!

Ready to Try Daytona? If you're a developer looking to streamline your development environment setup, head over to our GitHub repository and give Daytona a try. We're excited to continue building this open-source tool alongside our growing community.

Where to Look for More Inspiration and Tips

For more insights and inspiration on launching your product on Product Hunt, be sure to check out some of the fantastic resources we've read through while prepping our launch.

We highly recommend the comprehensive guide by Product Hunt themselves, which covers everything from crafting your launch strategy to engaging with the community.

For a fresh perspective, don't miss the recent post by Steven Tey, detailing how his startup Dub.co achieved #1 Product of the Day and #1 Product of the Week. Steven shares his step-by-step playbook, emphasizing the importance of building a strong community, creating stellar launch assets, and staying engaged throughout the launch process.

Also, for another firsthand account of achieving 'Product of the Day' with a dev tool, check out Daniel Bass's insights on growth tips and community engagement during Permit.io's launch.

Other noteworthy articles include Plausible's honest account of their successful launch, Softr's tips for reaching the top, and the insightful behind-the-scenes look at Klever Suite's Product Hunt journey.

How to Write A 4000 Stars GitHub README for Your Project

Ivan Burazin — Tue, 12 Mar 2024 00:00:00 +0000

The README is the most important file in your project. It's visitors' first impression, which can significantly impact whether they decide to star, become a user, contributor, or just close the browser tab.

Before open-sourcing our project Daytona — a first for us — I aimed to ensure everything was perfect, aside from the code, which is another story unto itself.

TL;DR

Key strategies for a successful GitHub README learned from the open-source project Daytona that gained 4.000 stars in the first week.
Impactful Header: Logo, badges, one-liner, visuals, and quick start guide.
Engaging Content: Explain the project's purpose, backstory, and detailed getting started guide.
Project Hygiene: Include contributing guide, license, code of conduct, and ensure no broken links or empty sections.

I'm excited to share with you the learnings for crafting README.md that we employed to achieve nearly 4.000 stars in the first week.

I began by examining the 100 most popular repositories on GitHub and was surprisingly underwhelmed by their READMEs. Extending my search to other projects within the same domain yielded similar results. It appears that successful projects often originate from companies or individuals who already have substantial followings, making the basics seem less critical to them. Atlassian's recent "Pragmatic drag and drop" project is a glaring example, a repo with just a readme, yet due to Atllasian’s popularity still got to trending page on GitHub for a day.

However, I decided not to leave anything to chance, so I did extensive research to uncover what truly matters. Here's what I discovered.

Heading Overview

This segment is critical as it captures most readers' attention. Fail to engage them here, and you risk losing them forever. Use this opportunity wisely. Here are my suggestions:

The Logo Beckons

Begin with your project's logo. It may seem obvious, yet many overlook it. This space is valuable real estate for making a strong first impression. In our situation, we decided our initial logo needed a redesign, and after some stress about the timing, we successfully now have a shiny new logo.

Badges Convey Trust at a Glance

Badges convey vital information about your project's health, build status, and overall quality. Strategically placed beneath your logo, these badges instill confidence in potential contributors, reassuring them that your project adheres to industry best practices.

The Elevator Pitch

Start with a catchy one-liner that encapsulates what your project is about, followed by a subtitle that provides additional context. Craft a concise, one-liner that encapsulates the essence of your project, followed by a compelling sub-title that provides additional context. This initial hook is crucial in piquing the interest of those browsing GitHub's vast repository landscape. Despite dedicating considerable effort to crafting this line, we still feel it misses the mark.

Create A Visual Feast

Humans are inherently visual creatures, and a well-executed image, GIF, or animation can convey the functionality and value of your project more effectively than words alone. Showcase your project's capabilities in a visually captivating manner, leaving a lasting impression on your audience. For this task, LiceCap remains a classic favorite for many, undoubtedly standing the test of time.

Feature Highlights

Once you've captured their attention, it's time to list your project's most compelling features. Highlight the unique value propositions that set your project apart, leaving your audience eager to explore further.

The Quickstart

Provide a quick start guide. Once users have a basic understanding of the project, offer a streamlined guide. With as few commands as possible, show how users can begin utilizing your project.

Main Body of the README

This section is for people seeking further information and more detailed insights; here are the strategies that have proven effective for us.

The Why?

Clarify from the reader's perspective why they should engage with your project. This helps in establishing a connection by directly addressing their needs or challenges.

Backstory

Not every project may have one, but if yours does, it's highly recommended to share it. People are naturally drawn to stories — sharing your motivation and the journey behind the project can make it more relatable and memorable for your audience.

Getting Started

This section is an extended version of the Quick Start guide, where you delve deeper into the how-tos, akin to mini-documents. It's essential for explaining your project's utility and application comprehensively.

Keep it Concise

Avoid unnecessarily long README files, as they can detract users and contributors who may perceive the project as overly complex.

Project Hygiene Essentials

While captivating narratives and visually stunning presentations are essential, true sustainability in the open-source realm hinges on impeccable project hygiene. These fundamental elements serve as the backbone of a thriving, collaborative ecosystem.

Contributing

A well-crafted Contributing Guide ensures that contributors follow your project's best practices, raise useful issues, and submit well-formed pull requests, making it easier for maintainers to manage the project:

Organize Steps: Ensure that the steps for contributing code are clearly organized and easy to follow.
Specific Commands: Use specific commands (e.g., git add ) instead of greedy commands like git add . to avoid adding unwanted files to commits.

License

Clearly articulate your project's licensing terms, safeguarding both your intellectual property and the rights of contributors. A well-defined license instills confidence and mitigates potential legal complications down the line.

Code of Conduct

A Code of Conduct defines how the project will engage and interact with the community, setting expectations for respectful contributions. While the wording of the Code of Conduct is outside the scope of this article, it's essential to have one in place to ensure a positive and inclusive community.

You can also take inspiration and guidance from the community, for example, our Code of Conduct is adapted from the Contributor Covenant.

The Support Network

Provide clear channels for users and contributors to seek assistance, report issues, or provide feedback. Responsive and accessible support mechanisms not only enhance the user experience but also foster a sense of community and long-term engagement.

Final README Review Checklist

Ensure every item in the README adds value. Consider moving detailed items to a separate docs folder as the file grows and referencing them in the README. Ensure your README is free from broken links and empty sections, and maintain standardized formatting to achieve a neat and professional appearance.

Maintain consistent naming conventions throughout the README and the repository. Remove empty sections from the README to keep it clean and concise. Create issues with appropriate labels for sections that need content.

Enhancing Project Hygiene Beyond the README

Security

Create a SECURITY.md file in your project's root directory, outlining the process for reporting vulnerabilities.

About

Ensure all sections are completed thoroughly:

Description - Summarize your project in a concise one-liner.
Website - Provide a link for additional information and include relevant topic tags.
On the homepage, include relevant information and deselect any of these three options—Releases, Packages, Deployments—if they're not applicable to save space effectively.

Releases

For Releases , utilize GitHub's releases feature to enable users to gauge the project's activity level based on the most recent release date.

Issues

Custom Labels: GitHub automatically provides default labels, but don't hesitate to create additional ones tailored to your project's needs. Create custom labels such as "Staff Only," "Blocked," "Awaiting Triage," and "Ready for Dev" to categorize issues, manage expectations, and create a triage flow.
Encouraging Community Contributions: At the outset, it's beneficial to populate your repository with several beginner-friendly issues to kickstart community engagement. Use the "good first issue" label to mark these tasks, encouraging new contributors. For example, apply this label to select issues in your project like so:good first issue.
Issue Templates: To ensure that reported issues follow a consistent structure, employing templates is wise. While GitHub offers default templates, customizing them allows for unique and creative approaches to issue reporting.

That's all! While it sounds straightforward, it required substantial research and testing. To see an example, please visit our repository. Additionally, if you have any suggestions, don't hesitate to open an issue - we welcome your input!

Remember, the README is visitors' first impression of your project, so investing time and effort into creating a well-structured and comprehensive file can significantly impact its visibility, adoption, and community engagement.

Gaining traction and accumulating GitHub stars is not a final goal but a

journey, one that requires dedication, responsiveness, and a relentless pursuit of excellence. By meticulously crafting each aspect of your open-source project, from the captivating header to the robust contribution guidelines, you'll create an irresistible gravitational pull that attracts contributors, fosters engagement, and propels your project to the pinnacle of the open-source community.

Best of luck with your project, and here's hoping it becomes a trending success too!

Daytona Goes Open Source: Embarking on a Bold New Journey

Nikola Balic — Tue, 05 Mar 2024 00:00:00 +0000

Daytona is leaping into the open source. It's a decision that feels akin to sending our beloved brainchild into the world, allowing it to grow beyond the confines of our aspirations.

We've nurtured Daytona with love and dedication. But the time has come for us to share our creation with the community that has been the backbone of our industry. Today marks not just another product release, but a heartfelt invitation to developers everywhere to join us in shaping Daytona's future.

Why Open Source?

The decision to go open source stems from a simple truth: innovation thrives in collaboration. By opening up Daytona's codebase, we're inviting developers to co-create the future of development environments with us. The tools that shape our digital world will no longer be confined behind proprietary walls. Instead, they will be shaped by the people who use them, in full view of the community that needs them.

Why Now?

Since Daytona's inception, our primary goal has been to address the challenges that enterprises encounter with their development environments. We have concentrated our efforts on enhancing code security, scaling and orchestrating environments efficiently, and streamlining the experience for developers when initiating development environments. We take pride in the significant progress we have made in these areas.

We recently began to wonder why this experience isn't shared by every developer across the globe. It's already 2024, yet setting up development environments still requires an average of at least 30 minutes and involves numerous steps. More often than not, developers encounter issues that impede their progress. We've discussed this in detail in a full article, which you can read here.

Our team quickly got to work. They skillfully extracted the core of Daytona, the development environment manager, and transformed it into a standalone binary that is now freely accessible for anyone to use.

But, What Does It Do?

Daytona is a radically simple open-source development environment manager. With Daytona, you need only to execute a single command daytona create.

Daytona automates the entire process: provisioning the instance, interpreting and applying the configuration, setting up prebuilds, establishing a secure VPN connection, securely connecting your local or a Web IDE, and assigning a fully qualified domain name to the development environment for easy sharing and collaboration.

While this is the alpha release, it represents the first step towards realizing our vision of a completely automated development environment.

As a developer, you can immediately start focusing on what matters most—your code.

What Can I Do With It?

Daytona can be downloaded and executed as a binary and you can just use it in your everyday life. Daytona is extendable by design, allowing you to create plugins that meet your specific needs. Moreover, it is genuinely open source under the Apache 2.0 license, providing you with unlimited freedom to modify and use Daytona as you see fit.

Promise of Open Source Project Sustainability

Daytona, the company, already generates revenue with an expanded product lineup that addresses orchestration, scalability, and security needs, catering to large enterprises while also focusing on enhancing the developers' experience.

Additionally, as previously noted, since Daytona is licensed under Apache 2.0, the community has the safeguard to create a fork should the project veer off course.

Join the Open Source Movement

We believe in a world where every developer can access the best tools, regardless of background or resources. By going open source, we're committing to that world. Whether you're an individual coder, part of a small startup, or leading a large enterprise team, Daytona is now your tool to shape as you see fit.

We invite you to join us on this journey. Contribute to the codebase, share your ideas, and help us build a tool that reflects the diverse needs of the global developer community.

Ready to Dive In?

Visit our GitHub repository (https://github.com/daytonaio/daytona) to start contributing today, sign up for our newsletter updates, and follow our voyage on social media.

The open source waters are warm, and the winds of change are favorable. Here's to the open source. Here's to Daytona—by developers, for developers.

DIY Guide to Transform Any Machine into a Codespace

Nikola Balic — Mon, 26 Feb 2024 00:00:00 +0000

Setting up any Dev Environment is usually painful, but the pain instantly doubles when you have to set it up on a remote machine. But why should you work on a remote machine?

There are many reasons: the size of the machine (for complex builds, dependencies, data locality, or running large ML/AI models), security, your employer needs the code in their data center, you're on the go with your iPad or Chromebook, or you're just tinkering with a Raspberry Pi.

No matter your reason, we wanted to make an easy step-by-step guide to let you set up a standardized, collaborative, and secure dev environment – essentially giving you a Codespaces-like experience on any machine.

Setting up a remote development environment can streamline your workflow and enhance collaboration. Instead of relying on a proprietary service like Codespaces, this guide will walk you through the process of creating your own custom remote dev environment on a Linux server.

There are many ways to go about it, but for this guide, we will assume you will use Visual Studio Code and leverage Docker containers to isolate dependencies and services needed for development.

Prerequisites

To follow this guide and set up your own remote dev environment, you will need:

A Linux server running Ubuntu 20.04+ with at least 2 GB of RAM and 2 CPU cores. This can be a virtual private server (VPS) from a cloud provider or maybe even a Raspberry Pi.
Admin/root access to the server to install software.
We will assume your local machine runs a MacOS or Linux variant (maybe even a WSL), if you are using Windows be sure to adapt some commands but everything should work as advertised.
A Visual Studio Code on your local machine.
Basic knowledge of command line interfaces and experience with Docker is helpful.
Some courage.

Step 1a - Provision Linux Server

First, you'll need to provision a Linux server that will host your remote development environment.

While you can repurpose an existing server, starting fresh helps avoid conflicts. Provision an Ubuntu 20.04 server with at least 2 GB RAM and 2 CPU cores from your preferred hosting provider.

Many cloud providers like AWS, GCP, Azure, and DigitalOcean allow instant provisioning of Ubuntu VPS instances at reasonable prices. Some of them even provide a complimentary initial credit; for instance, Digital Ocean offers credit for the first 60 days.

For example, Oracle offers a free-tier cloud account that allows you to utilize 4 cores ARM machine and up to 24GB of memory. Just prepare to be patient, as registering and setting up your account will require some effort.

A Raspberry Pi also works well if you want to save costs and don't need significant compute resources. Install the latest Raspberry Pi OS (formerly Raspbian) on compatible Pi hardware. To be honest, we haven't attempted it, but if you decide to try it, please let us know.

Once your Linux server is up and running, SSH into it to begin setup.

Step 1b - Generate SSH Keys (optional)

If you haven't already configured your SSH keys, we'll need to create them to establish a secure connection to the remote server.

Based on the remote server you're using, you'll need to prepare your SSH keys for the provisioning process so that you can input them into the dashboard of your preferred cloud provider. Alternatively, you can initially configure your server using a password and then add the SSH keys by following the instructions in the second section below.

### On your local machine:

# Open a terminal and generate a keypair:
ssh-keygen -t rsa

# Save the private and public keys in the default location.

# Copy the public key:
cat ~/.ssh/id_rsa.pub

### On the remote server:

# Log in and create an .ssh folder:
mkdir .ssh

# Create an authorized_keys file and paste your public key:
nano .ssh/authorized_keys

# Set permissions:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Now, you can SSH into the server without a password using the private key.

ssh user@your-server-ip

Step 2 - Install Docker

Since we will leverage Docker to isolate and run services needed for development, Docker Engine is essential. Follow the official Docker install directions for Ubuntu to get up and running.

With SSH set up, let's install Docker on the remote server:

# Update package lists
sudo apt update 

# Install Docker prerequisites
sudo apt install apt-transport-https ca-certificates curl software-properties-common

# Add Docker's GPG key 
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Set up the Docker apt repository
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu focal stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

Check it worked:

docker --version
docker run hello-world

This should successfully download a test container image and print a confirmation message. If the last command encounters a permission error, attempt to run it again using sudo before the command.

While optional, Docker Compose makes working with multi-container apps much easier. We'll use it later to orchestrate our dev environment services.

First things first, ensure Docker Compose is properly installed by confirming the version number.

docker compose version

If that is not the case, install Docker Compose it with the following commands.

sudo apt-get update
sudo apt-get install docker-compose-plugin

Add your user to the docker group by using a terminal to run:

sudo usermod -aG docker $USER

Please log out and then log back in to ensure that the changes to the settings are applied.

Adding your username to the Docker group in a Linux system is a common practice to allow non-root users to run Docker commands without needing to use sudo each time. By default, Docker requires elevated privileges, and running Docker commands as a regular user without proper permissions would result in permission-denied errors.

Step 3 - Connect Visual Studio Code to Remote Environment

To allow connecting to your remote dev environment from Visual Studio Code, we need to install VS Code Server. The Visual Studio Code Server is a service designed to operate on a remote development environment, such as your cloud virtual machine (VM). This will run on the remote host and communicate with the VS Code client on our local machine.

Back on our local machine, launch VS Code and install the Remote - SSH extension.

Use the Command Palette (Ctrl/Cmd+Shift+P or F1) in VS Code to run Remote-SSH: Connect to Host... and enter your server info user@your-server-ip from the last step.

Once connected, VS Code will automatically install the VS Code Server on your remote machine.

You now have full VS Code functionality on the remote server, you can open folders and work directly on the remote server!

Step 4 - Clone Sample Project

With our base environment setup, let's clone the repository of a sample web project to use for development.

Feel free to use your own project repository here if you already have code to work on. For our example, we will use the Astro web framework git repository.

You can use the file explorer button and option to "Clone Repository" :

You will be prompted: "Cloning a repository in a Dev Container may execute arbitrary code." to confirm.

Or you could use the VS Code terminal and execute the commands directly.

# Git clone the project 
git clone https://github.com/my-user/my-project.git  
# Change directory 
cd my-project

Open the project folder by clicking on the pop-up alert or using File > Open Folder and select the folder you cloned previously.

For the Astro repository, you will be offered to install a set of helpful extensions for your Visual Studio Code, such as language support for Astro, the Prettier code formatter, EditorConfig, and ESLint.

Step 5 - Standardizing Your Development Environment with Dev Container

The Astro repository contains multiple devcontainer.json files, enabling you to set up and run a standardized development environment tailored to your needs. Whether you're contributing to the Astro project, contributing to documentation, or working within a particular framework like React, these configurations facilitate a seamless development experience.

Understanding and Harnessing Dev Containers

Development Containers is an open standard designed by Microsoft to enhance containers with content and settings tailored specifically for development purposes.

Dev Containers are defined using devcontainer.json files, which specify the environment's settings, extensions, and Docker configurations necessary for development. This approach ensures that all developers working on a project have a consistent set of tools and runtime environments, minimizing the "works on my machine" problem.

Dev Containers will ensure a seamless development experience across different machines, similar to what one might expect from using a platform like Codespaces, but with the flexibility and control of a custom setup. This setup is particularly beneficial for collaborative projects or when working in diverse environments, as it abstracts the underlying system configurations and focuses on providing a unified development experience.

Dev Container Basic Example from Astro

The following JSON snippet is an example of an Astro Basics devcontainer.json configuration.

{
  "name": "Basics",
  "build": {
    "dockerfile": "../examples.Dockerfile"
  },

  "workspaceFolder": "/workspaces/astro/examples/basics",

  "portsAttributes": {
    "4321": {
      "label": "Application",
      "onAutoForward": "openPreview"
    }
  },

  "forwardPorts": [4321],

  "postCreateCommand": "pnpm install && cd /workspaces/astro && pnpm run build",

  "waitFor": "postCreateCommand",

  "postAttachCommand": {
    "Server": "pnpm start --host"
  },

  "customizations": {
    "codespaces": {
      "openFiles": ["src/pages/index.astro"]
    },
    "vscode": {
      "extensions": ["astro-build.astro-vscode", "esbenp.prettier-vscode"]
    }
  }
}

Let's break down its components:

build: Here, "dockerfile": "../examples.Dockerfile" points to a Dockerfile relative to the location of the devcontainer.json file. This Dockerfile contains instructions for building the Docker image that the development environment will use.
portsAttributes: Defines attributes for ports used by the container. The configuration for port 4321 includes the label "Application" and specifies that when this port is auto-forwarded, a preview should be opened automatically ("onAutoForward": "openPreview").
forwardPorts: Lists the ports that should be forwarded from the container to the host machine, allowing access to services running inside the container.
postCreateCommand: Specifies a command to run after the container is created but before a user connects. Here, it installs project dependencies using pnpm install, then builds the project with pnpm run build, ensuring the environment is ready for development.
postAttachCommand: Defines commands to run after a user attaches to the container. This example specifies that the Server should start using pnpm start --host, preparing the Astro development server for use.
customizations: Contains environment-specific customizations. Under codespaces, it automatically opens the file src/pages/index.astro upon starting, which is useful for getting straight to editing the main page. The vscode section lists recommended extensions (astro-build.astro-vscode for Astro support and esbenp.prettier-vscode for code formatting with Prettier) to enhance the development experience within VS Code.

Each part of this configuration ensures that the development environment is tailored to the project's needs, from the Docker build process to the setup and ready state of the development server, including the developer's workspace setup in Visual Studio Code.

Open Project in Dev Container

To open your project folder in a dev container:

Open the command palette again.
Select "Remote-Containers: Open Folder in Container..."
Choose your project folder.

VS Code will start the dev container, install extensions, and connect automatically.

The setup time for your development environment will vary based on the configuration specified in your devcontainer.json file, so anticipate a short wait. While prebuilds can often mitigate this delay, that is a subject better suited for a separate discussion.

You now have a fully featured, standardized remote development environment accessible through VS Code on your local machine!

Step 6: Run Preview Dev Server

In VS Code, once the container is ready, and if the dev container of your choice didn't run the server, open a new terminal within VS Code and start your application.

You can execute a command to start the preview if your project is web-based. In the case of our Astro project, the command is as follows. However, your specific command may vary.

pnpm run dev

Step 7 - Securely Share and Expose Your Projects on the Internet Behind a Domain

To share your environment or collaborate with others, we can expose services securely over the internet. There are reverse proxy services that allow this to function without a public IP and even behind a firewall. For instance, in our example, we are using ngrok.

First, retrieve your ngrok authentication token from the ngrok dashboard.

Install Ngrok from their site, and authenticate it with your account auth token:

# Download and extract Ngrok  
curl -s https://ngrok-agent.s3.amazonaws.com/ngrok.asc | \
  sudo tee /etc/apt/trusted.gpg.d/ngrok.asc >/dev/null && \
  echo "deb https://ngrok-agent.s3.amazonaws.com buster main" | \
  sudo tee /etc/apt/sources.list.d/ngrok.list && \
  sudo apt update && sudo apt install ngrok

# Add authtoken 
ngrok config add-authtoken <TOKEN>

To give internet access to our app container from earlier at port 4321, run:

ngrok http 4321

Copy the ngrok tunnel URL provided in the output.

Your application should now be running and accessible via the Ngrok tunnel URL.

Paste the Ngrok tunnel URL into your browser to access your application. If you encounter a connection refused error, ensure that the necessary port is open on your server's firewall.

To maintain a consistent URL for each ngrok session, set up a static domain via your dashboard. Once you've created it, you can instruct the ngrok agent to utilize this domain using the --domain flag. Begin by halting the current ngrok process with Ctrl+C, and then restart ngrok to apply the changes.

ngrok http 4321 --domain jumpy-red-mollusk.ngrok-free.app

If you prefer to limit access to your application, you can easily implement authentication with ngrok without modifying your app. For instance, if you use the Google account alan@example.com, you can restrict access to yourself alone by executing ngrok with the following command:

ngrok http 4321 --oauth=google --oauth-allow-email=alan@example.com

When someone attempts to use your app, they must sign in using Google, and access will be exclusively permitted to your account. Please be aware that each time you restart ngrok without using the --domain flag, your app's URL will change.

If you wish to go a step further, ngrok also enables the use of your own custom domain. By leveraging CNAME records, ngrok hosts an endpoint on your custom domain and offers comprehensive management of the TLS certificate lifecycle on your behalf.

Step 8 - Code on the Go with a Web IDE on Any Device (optional)

After setting up your application and ensuring it's accessible via Ngrok, you might want to take advantage of the OpenVSCode Server, an open-source project licensed under MIT and maintained by Gitpod, for a full web IDE experience, which allows you to run a web version of VS Code on your server and access it through your web browser.

Here's how to set it up and run it:

Start the OpenVSCode Server : Within your remote server, install the OpenVSCode Server by running the following Docker command.

docker run -it --init -p 3000:3000 -v "$(pwd):/home/workspace:cached" gitpod/openvscode-server

Configure Inbound Port Rules : To access the OpenVSCode Server, you need to configure the network settings to allow traffic on the port it's running on. If you're using a service like Azure, navigate to the network settings and set an inbound port rule to allow TCP traffic on port 3000. Ensure that you review the firewall configurations on your server, utilizing tools such as ufw or iptables.
Test the Connection : Once the port is open, try accessing http://remote_server_ip:3000 in your web browser. Replace remote_server_ip with your server's actual IP address. If you encounter a security warning about the connection not being private (which may happen in some browsers like Chrome), try using a different browser like Safari that may not present this issue. Please note that configuring HTTPS falls outside the scope of this guide.
Access web IDE VS Code : If everything is configured correctly, you should see the OpenVSCode Server interface in your browser. You can now access your project straight from the Docker image without additional configuration.

Now, you'll have a powerful, browser-based web IDE to access from anywhere, making your development process even more flexible and accessible.

Conclusion

Congratulations! You've successfully set up your own fully-featured remote development environment without being locked into a proprietary platform!

You can now develop directly inside a container, ensuring a consistent development stack isolated from your local environment. With Ngrok, you have also secured your development environment with a tunnel to be shared with your team for collaboration.

Key aspects included:

Provisioning a Linux server to host your infrastructure
Installing Docker Engine and Docker Compose to define environments
Getting Visual Studio Code Server running to enable remote coding
Using Docker containers to encapsulate infrastructure dependencies
Adding security through SSH, HTTPS encryption, authentication
Scripting setup steps to allow automation and portability
Exposing services securely over the internet with Ngrok

You can now develop from anywhere using this robust, self-managed environment tailored to your needs!

Some additional pointers:

Commit the .devcontainer folder to source control to share with the team.
Use Docker Compose for multi-service applications.
Install the Remote - Containers extension to use dev containers locally.
Read the docs of each tool we have used for more advanced configuration and troubleshooting.
Remember to delete any temporary accounts or services you no longer need to maintain security and avoid unnecessary charges.

Let me know if you have any other questions.

Step 9 - Can we automate this?

This is the process you'll undergo for setting up each remote development environment you create, and it's no simple task.

As an engineer, you might often find yourself thinking, "Could I automate this task with some scripts?" While the answer is yes to some extent, it's important to remember that any modifications you make will necessitate script updates. Eventually, you may find that you have to perform the task manually once more.

For consistency and portability across projects, we can automate the process using provisioning scripts.

First, create a setup script setup.sh that executes our past commands:

#!/bin/bash

# Add Docker's official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add Docker repository
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update and upgrade the system packages
sudo apt update && sudo apt upgrade -y

# Install necessary packages for Docker installation
sudo apt install apt-transport-https ca-certificates curl software-properties-common -y

# Install Docker Engine, CLI, and containerd
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

# Add current user to the Docker group to run Docker commands without sudo
sudo usermod -aG docker ${USER}

# Print Docker version to verify installation
docker --version

# Install and configure Ngrok
echo "Installing Ngrok..."
curl -s https://ngrok-agent.s3.amazonaws.com/ngrok.asc | \
  sudo tee /etc/apt/trusted.gpg.d/ngrok.asc >/dev/null && \
  echo "deb https://ngrok-agent.s3.amazonaws.com buster main" | \
  sudo tee /etc/apt/sources.list.d/ngrok.list && \
  sudo apt update && sudo apt install ngrok

echo "Please enter your Ngrok auth token (You can find it on your Ngrok dashboard):"
read NGROK_AUTH_TOKEN
ngrok config add-authtoken $NGROK_AUTH_TOKEN
echo "Ngrok installed and configured."

# Install OpenVSCode Server using Docker
echo "Installing OpenVSCode Server..."
docker run -d --init -p 3000:3000 -v "/workspace:/home/workspace:cached" gitpod/openvscode-server
echo "OpenVSCode Server is running on port 3000. Access it at http://your_server_ip:3000"

# VS Code Server installation instructions
echo "To connect Visual Studio Code to this remote environment:"
echo "1. Install the Remote - SSH extension in VS Code on your local machine."
echo "2. Use the Command Palette in VS Code to run 'Remote-SSH: Connect to Host...' and enter this server's SSH credentials."

echo "Setup complete. Please log out and back in for group changes to take effect."

Run the script:

Copy the script above into a file named setup.sh on the server.
Make the script executable with chmod +x setup.sh.
Execute the script with ./setup.sh.

Consider wrapping them into a simple CLI tool to simplify further.

Frankly, the situation is quite chaotic. The script is horrible and unlikely to function effectively because it requires customization to fit the particular system in question. Moreover, it doesn't address the routine tasks and interactions with repositories, workspaces, and the public preview, among other elements.

Perhaps there's a better way.

Follow Daytona on GitHub

Stay tuned for the imminent launch of Daytona on GitHub, our open-source project designed to automate development environment management. The aim to save developers and their teams substantial time by seamlessly standardizing dev environments across any machine, solving this challenge once and for all.

Join us in our mission to transform and accelerate the development process.

Redefining Success in the Engineering Organization

Nikola Balic — Fri, 16 Feb 2024 00:00:00 +0000

Over the past decade, the image of the lone “rockstar” coder has become pervasive in engineering culture. The rockstar represents the pinnacle of achievement – a virtuoso developer capable of single-handedly architecting complex systems and cranking out flawless code at superhuman speeds. This archetype holds powerful sway in the minds of many engineers, shaping identities and perceptions of success.

But as tech leaders, we must look honestly at the implications of idolizing this myth:

What behaviors and mindsets does it promote or suppress?
How might it impact diversity, collaboration, and sustainability in our organizations?
Are we setting realistic expectations or inadvertently fostering burnout and imposter syndrome?

At Daytona, we’ve worked to redefine engineering success by creating an environment optimized for developer empowerment. Through this experience, I believe sustainable high performance requires abandoning the rockstar model for a more nuanced definition – one rooted in collaboration, continuous learning, and resilience.

Collaboration, rather than solitary effort, is frequently the source of genuine innovation.

The Allure and Risks of the Rockstar Engineer

The trope of the rockstar coder has been glamorized in media, perpetuated through industry hype, and stubbornly persists in engineering culture. Qualities typically associated with this image include raw technical brilliance, an anti-social streak, extremely long hours in intense solitary focus, and often shunning documentation or “boring” tasks.

This archetype holds undeniable allure – the software magnate crafting ingenious code in a feverish haze of Red Bull and brilliance. Their heroic efforts seem to singlehandedly save the day. It’s a narrative that fuels many engineers' aspirations and egos.

But this myth also carries significant downsides at both individual and organizational levels. Internalizing it can fuel anxiety and burnout as developers stretch themselves thin trying to live up to unrealistic expectations. It encourages siloed work and discourages collaboration or mentoring. It often dismisses the less glamorous but crucial work of documenting systems, reviewing code, or interviewing users. The rockstar attitude also tends to disdain entry-level tasks beneath their abilities – depriving newcomers of mentoring and growth opportunities.

This mindset rewards raw individual performance over sustainability, diversity, or team success. It inhibits the cross-pollination of skills and institutional knowledge sharing vital for organizational resiliency. Ultimately, the lone rockstar represents a high-risk, low-scalability model. Their abilities become single points of failure and bottlenecks as systems grow more complex.

So, how can leaders reshape engineering culture to move past this limiting myth?

Redefining Success as a Team Sport

Transitioning from the rockstar model requires reorienting from individual heroics toward collaborative team success.

This starts with the reconceptualization of projects as complex, multifaceted endeavors that draw on diverse skill sets. A healthy engineering culture values specialists ranging from user researchers to security auditors and generalist coders. It recognizes documentation, QA processes, and DevOps as integral to delivering robust, scalable systems.

With this breadth of contributors, stellar outcomes become team achievements earned through coordination. We must assess performance based on aligned cross-functional metrics versus raw individual output. Shared ownership and collective responsibility should be instilled at all levels.

Incentive structures also require rethinking. Rewarding individual metrics like lines of code can incentivize destructive practices like copy-pasted code or cruft accumulation. Consider incentives for cross-training, mentorship, documenting systems, or volunteering for unglamorous tasks that advance the project. Make collaboration and knowledge sharing part of performance reviews.

We tend to underestimate the value of simplicity in solutions, mistakenly equating complexity with superiority.

Platforms like Daytona enable the transition toward team success by removing tedious configuration and maintenance tasks. Automating these distractions immerses developers in collaboration and core engineering work. Streamlined coordination frees attention toward higher-order team dynamics that enable breakthrough innovations.

Embracing Continuous Learning and Growth

Sustainable excellence requires continuous skills development, not just innate genius. The myth of the 10x rockstar coder rests on the idea of innate brilliance – that mastery stems from raw talent rather than practice. But engineering evolves rapidly – today’s hot skill fades into obsolescence within a few years. The lone coding cowboys of yore stranded themselves on soon-outdated islands of expertise.

Organizations seeking sustained excellence foster a culture of continuous learning and growth. With support for conferences, online courses, and skill-stretching assignments, veteran engineers avoid becoming dinosaurs. Regular retention-focused training and mentorship opportunities are crucial for upskilling staff and transferring institutional knowledge.

Rotational programs allowing developers to shift across focus areas prevent siloed knowledge and cultivate empathy between teams. Hackathons, open-source Fridays, and casual skill shares encourage enriching side projects and serendipitous discoveries.

Daytona’s automated dev environment provisioning helps enable continuous learning. Spinning up sandboxed environments for experimentation allows risk-free tinkering. Quick reproducibility makes replicating and debugging learning scenarios faster. Built-in collaboration capabilities support interactive training across locations.

Rewarding Resilience and Grit

Sustainable excellence requires resilience and grit. The rockstars’ apparent one-shot success hides their dependence on fickle inspiration. But true engineering prowess reveals itself when persevering through protracted debug cycles, integrating complex legacy systems, or grinding through regulations.

Resilience emerges as a theme across many high-performing teams. MIT research found the highest-achieving software teams were often internally mediocre at cooperation or technical skills. Their advantage lies in sheer grit to push through challenges. Members leaned on and learned from each other during demoralizing setbacks.

Leaders should assess performance under adversity – how developers respond to tangled dependencies or tight deadlines reveals character. Reward signs of resilience include carefully considering alternative approaches, seeking help appropriately, and implementing post-mortems.

Part of resilience involves minimizing needless adversity in the first place. Daytona’s development environment automation reduces frustrations from manual configuration and repetitive tasks. Its integrated tools remove painful context-switching. The platform aims to amplify human potential by eliminating unnecessary self-imposed obstacles.

Final Thoughts

Redefining engineering success requires examining assumptions and incentives permeating tech culture today. The mythic rockstar represents an antiquated archetype mismatched to the complexity of modern systems—sustainable excellence springs from collaborative teamwork, continuous learning, and resilience when facing inevitable challenges.

As leaders, we shape culture through the metrics, processes, and narratives we endorse. Daytona offers a development environments management platform designed to bring out the best in engineering teams beyond individual heroics. Our automated environments empower developers with the space and support structure to reach new levels of productivity and innovation.

The future belongs not to the lone coding cowboys but to the empowered, cross-trained engineering teams equipped to tackle exponentially growing complexity. By redefining success beyond outdated myths, leaders can foster cultures where every contributor can creatively thrive, and organizations can sustainably excel.

Dev Container: The Path to Standard Dev Environments

Chad Metcalf — Mon, 12 Feb 2024 00:00:00 +0000

Startups and software companies aligning with the Development Container specification can significantly streamline their development processes. By aligning with established standards and leveraging existing reference implementations, such as those from Microsoft, startups can ensure compatibility and meet user expectations.

The adoption of Dev Container Specification not only reduces the need to reinvent the wheel but also fosters a uniform experience across various platforms, benefiting both business and open-source communities.

TL;DR

Microsoft's reference implementations for Dev Container are not open source, except for the Dev Container CLI.
There's an advantage for other startups supporting Dev Container as it encourages adherence to specifications, revealing areas where the specification may need improvement.
Multiple implementations of a specification, as seen with Docker and OCI specs, are beneficial but can be challenging for users.
Daytona aims to align user experiences across different platforms (VS Code, Codespaces, Daytona), benefiting both business and open source communities.
This alignment will enable a standardized development environment experience, which is seen as powerful and beneficial for all users.

The Evolution of Dev Container Integration

The journey of integrating with the Dev Container specification is one of learning and adaptation. Initially setting out to create a unique solution, it became apparent that the gap between independent efforts and the established Dev Container specification was vast. This realization underscores the importance of leveraging reference implementations and adhering to industry standards to minimize duplication of effort and ensure compatibility.

The Challenges of Divergence

Creating a custom solution that deviates significantly from the Dev Container specification can lead to increased workload and a disjointed user experience. Reference implementations, particularly those from Microsoft, have set user expectations for functionality and performance. Deviating from these expectations can create unnecessary hurdles for users.

Lessons Learned: Embracing Established Standards

The experience highlights the value in closely integrating with the Dev Container CLI and other extensions. This approach not only taps into the benefits of existing, robust tools but also ensures that users have a consistent experience, whether they're working in Visual Studio Code, Codespaces, or other environments supporting Dev Container.

Rising Tide: The Collective Benefit of Specification Adoption

The broader adoption of the Dev Container specification is akin to a rising tide that lifts all boats. It encourages a shared understanding of how development environments should operate. As more implementations of the spec emerge, it can shine a light on areas that may need further refinement, drawing from lessons learned during Docker's evolution with the OCI spec and others.

The Challenge for Users: Navigating Multiple Implementations

While having multiple implementations of a specification can be beneficial, it can also pose challenges for users. They may find themselves navigating a fragmented landscape of development environments, which can impede productivity and lead to confusion.

Daytona's Strategic Alignment: Bridging User Experiences

Daytona's approach to closely align with what users expect from Dev Container implementations will bridge the gap between disparate user experiences. This alignment ensures that actions performed in one environment will seamlessly translate to others, whether in VS Code, Codespaces, or Daytona.

The Power of Standardization for Open Source Communities

Open-source communities benefit significantly from standardization. With contributors using various platforms, a standard development environment facilitates collaboration and reduces friction. Daytona's commitment to standardization of dev environments is poised to offer a consistent development experience for all users, regardless of their platform of choice.

Conclusion: The Significance of Alignment with Dev Container

The lessons learned from integrating with the Dev Container specification emphasize the importance of alignment and standardization. For dev tools companies like Daytona, this alignment promises developers a flow state and an uniform and powerful development environment experience for users across different platforms. It is through this standardization that the open-source community, as well as business users, can enjoy a cohesive and efficient workflow, reinforcing the collective strength of the software development ecosystem.

The Dream Dies: Why Cloud IDEs Failed Developers

Ivan Burazin — Fri, 09 Feb 2024 00:00:00 +0000

For years, developers have been tantalized by the dream of coding entirely through their web browser—no more installing bulky programs or configuring local environments. Just open your online IDE and start programming from anywhere, on any device. Major players like Google and Amazon poured millions into making this vision a reality.

But the much-hyped promise of cloud IDEs has largely failed to materialize. While they've found niche uses, developers overwhelmingly still prefer native desktop tools. As an industry veteran who built some of the first browser-based coding tools back in 2009, I've watched the cloud IDE hype cycle unfold firsthand. From my vantage point today, in 2024, I can definitively say the sun is setting on the dream of cloud-based integrated development environments.

Don't get me wrong - remote development capabilities still have an important role to play. However, trying to force the entire coding experience into a web browser is a fool's errand. The cloud IDE model does not align with what most professional developers need and want in their daily workflows.

What Developers Want

To understand why cloud IDEs miss the mark, you have to consider the developer's perspective. What do coders care about most when choosing tools and environments? From my experience, three key factors rise above all else:

Speed and performance
Customizability and flexibility
Integration with existing tools

Let's explore why these factors present major challenges for the browser-centric approach of cloud IDEs.

First and foremost, developers cherish speed and native performance. They want fluid UI interactions and near-instantaneous feedback when editing code. Even small lags quickly become intolerable frustrations. Unfortunately, browser-based apps still cannot match the raw speed of compiled native programs.

Next, developers demand deep customizability to optimize their workflows. They want to configure fonts, themes, keyboard shortcuts, and layouts. They want to install plugins and extensions that add new capabilities freely. Browser IDEs restrict them to built-in options.

Finally, developers rely on tight integration with other indispensable tools like version control, debuggers, package managers, and more. They expect seamless interoperability. Again, the closed ecosystems of current cloud IDEs make this difficult.

Paradise Lost

Cloud Development Environment providers promise developers paradise - a utopian coding environment accessible anywhere through the web. But in reaching for heaven, they abandon the practical realities of what developers need to do their jobs effectively each day. By forcing everything through the browser, they create a walled garden that strips away the flexibility and power that programmers have come to depend on in their local toolchains.

This false paradise comes at an unacceptable cost for professional developers building and maintaining complex applications. The lure of "one IDE to rule them all" makes for a nice headline, but utterly fails the test of real-world developer experience.

Rebirth From Failure

As we move beyond the limitations of cloud IDEs, it's clear that a new approach is necessary—one that builds on the lessons learned from past failures. Seve Kim's insight captures this transition beautifully:

Newer developer tools present a paradigm shift that solves all the existing problems current tools present. However, these new paradigms seem to be designed in a vacuum and lack a bridge from the old world. Interoperability is table stakes. We need to meet developers where they are today.
Seve Kim, Spotify, Backstage PM

This perspective underscores the importance of not just innovating for the sake of novelty, but ensuring that new tools seamlessly integrate with existing workflows and technologies. The future lies not in discarding the old completely, but in creating a symbiotic relationship between the tried-and-true and the cutting-edge.

Does this mean the vision of remote development is dead? Not at all. The CDE hype cycle produced important lessons that can guide smarter tools in the future. The way forward recognizes that the browser is better positioned as one piece of the environment rather than the whole.

Instead of replacing all developer tools with a web-only IDE, the future lies in building desktop-native performance and flexibility augmented by cloud capabilities. Open ecosystems and community extensibility will also be critical, avoiding the walled-garden limitations of proprietary cloud IDEs. VS Code combined with a DEM platform like Daytona, enhanced by integrations for collaboration and AI assistance, exemplifies this new direction. It's about augmenting, not replacing, the tools developers already rely on.

The popularity of emerging tools like Zed show early promise in disbursing this cloud bubble. By focusing first on high-performance native editing, Zed's creators are charting a path beyond the cloud IDEs. Will native tools supported by platforms like Daytona finally unlock the long-awaited dream of remote development done right? We certainly believe so.

The CDE hype cycle produced more smoke than fire. But from the ashes, space now exists for a rebirth guided by lessons learned. The browser will play an important assisting role, while leaving the coding experience centered firmly on the desktop.

By upholding the principles developers truly care about - performance, customizability, and integration - the next generation of tools can avoid repeating mistakes. The CDE dream may have died, but developers are poised for something better today.

Embracing Open-Source Alignment

Ivan Burazin — Tue, 23 Jan 2024 00:00:00 +0000

Open-source software has long been the bedrock of innovation, offering tools and frameworks that have propelled the digital era. In a landscape marked by rapid digital transformation, aligning with open-source methodologies is not merely a forward-thinking strategy but a requisite for businesses aiming to ship quality customer experiences frequently.

Guided by insights from respected experts like Milin Desai, CEO of Sentry and our investor, the path to success for modern companies lies in aligning with open-source principles.

The Shift Toward Open-Source Alignment

Open-source alignment goes beyond using and supporting open-source software; it encompasses a company-wide ethos that contributes time, resources, and innovation back to the community.

Customer and Enterprise Perspectives

From the consumer's viewpoint, open-source solutions offer compelling advantages like speed, flexibility, and cost-effectiveness. Enterprises embrace open source to catalyze development, evade vendor lock-in, and diminish costs. With organizations like Walmart and Porsche leading the charge, the trend is gaining momentum across various sectors.

Software Providers Respond

Companies are responding to this demand by integrating open-source platforms into their service offerings. This strategy allows them to extend beyond mere product provision to a more engaged, contributory role in the development community.

The Case for Open-Source Sustainment

The escalation of open-source software use underscores the industry's responsibility to support the underlying projects and contributors. This commitment grows increasingly important given the pivotal nature of open-source software in modern innovation.

However, sustaining open-source projects in the face of commercial exploitation remains challenging. Companies like MongoDB and Elastic have experienced difficulties when large commercial entities use their open-source projects. MongoDB's shift to the Server Side Public License (SSPL) in response to these challenges illustrates the complexities of balancing open innovation with the need for sustainable development. This situation underscores the importance of finding equitable solutions that protect the interests of open-source creators while maintaining the spirit of open collaboration.

Sentry's Advocacy

Sentry has established an impressive support model for the open-source community by allocating substantial funds for project maintenance, security enhancements, and long-term sustainability. Their funding approach includes smaller-scale sponsorships and larger contributions, showcasing a versatile strategy to nurture the open-source environment.

Acknowledging the vital influence of open-source initiatives in software development, Sentry has generously funded various key projects and organizations. Among the prominent beneficiaries are rrweb, receiving $15,000, which underlies Sentry's Replay feature; the PHP Foundation and Ruby Foundation, granted $10,000 and $6,000 to support these essential programming languages; and SvelteKit, awarded $1,750, selected by Syntax for their website redesign. These donations reflect Sentry's dedication to empowering the open-source ecosystem that drives technological progress.

The Industry's Collective Responsibility

The narrative of Sentry reveals an industry at a crossroads. As reliance on open-source software intensifies, the imperative to contribute will become an industry-wide mandate.

Open-Source as a Norm

For startup companies and enterprises, open-source alignment should be woven into the fabric of their business models. Beyond financial incentives, contributing to open-source projects can drive internal innovation and quality enhancement.

Cultural Shift Towards Sponsorship

The movement toward open-source sponsorship must intensify. Entities such as FOSS Funders are mobilizing companies to support this culture shift, advocating for open-source projects as an industry norm.

Open-Source Alignment as the Strategic Pillar

For contemporary businesses, particularly in the tech sector, aligning with open-source principles is transitioning from an advantageous strategy to an operational imperative. Companies like Sentry exemplify this shift, showcasing the necessity and benefits of open-source alignment.

Daytona's Open-Source Journey

Daytona's journey as an open-source project is just starting. We are currently focused on developing an open-source strategy that guarantees its long-term viability while reflecting our dedication to community contributions.

Licensing Model Deliberations

At Daytona, we are carefully evaluating our approach to open-source licensing. We aimed to find a sweet spot that substantially benefits developers and supports the developer community long-term.

Though the code has not yet been published, watch closely our Daytona Core repository for upcoming updates and releases, expected in Q1 2024.

Looking Ahead

While Daytona is transitioning towards a fully open-source strategy, it's important to acknowledge that this approach may not suit everyone.

However, there are alternative ways to support the community. One notable example is Sentry, which demonstrates its commitment through financial and developmental assistance. This sets a clear path forward for technology companies. True to Desai's vision, the future favors those who recognize open-source alignment as a strategic cornerstone for fostering innovation, enhancing competitiveness, and achieving success.

In this pursuit, contribution and collaboration are not just ethical choices but strategic ones that will define the leading enterprises of tomorrow. The call to action is simple yet profound: embrace open-source either directly or through alignment.

After all, it's important to recognize that our work wouldn't be possible without the solid foundation of open source.

Meeting Developers Where They Are

Toma Puljak — Mon, 22 Jan 2024 00:00:00 +0000

Innovation is rapid, with new tools and frameworks emerging constantly. As a result, developers today have more choices than ever in how they build applications. This fragmentation presents opportunities and challenges for companies building developer tools and platforms. To be successful, you must meet your users where they are rather than requiring them to conform to your ideals.

It's worth considering integrating your product's core functionality into the tools developers commonly use, such as their IDE or the terminal for compiling code and executing commands. Consider the tools and applications developers frequently use; a significant portion of their time—around 80%—is spent within an Integrated Development Environment (IDE). This is why companies should consider porting functionality into CLI binaries or extensions for VS Code, JetBrains, etc.

TL;DR

Meet developers where they are by integrating into existing tools like IDEs, not requiring them to adopt new ones.
Leverage standards like OpenAPI to create clear APIs that enable ecosystem contributions.
Embed functionality directly in UIs developers spend time in to reduce context switching.
API-first thinking reduces friction, future-proofs for new platforms, and promotes customization and community loyalty.

Leveraging Standards for Innovation

The prevalence of APIs has opened up possibilities for integrating with the environments and workflows developers already use. Rather than solely providing your own bespoke interface, you can embed functionality in the IDEs, browsers, terminals and other interfaces developers spend most of their time in. For example, Atlassian's Jira offers a complex web UI for issue tracking. But to reduce context switching, Jira also provides a Visual Studio Code extension so developers can access issues without leaving their editor.

At Daytona, we've embraced this by carefully considering the developer workflow and all the touchpoints with our product. We are working on a CLI binary and a VS Code extension that allows users to manage workspaces and perform all the actions available in the web UI, as well as integration with the JetBrains ecosystem through their JetBrains Gateway tool.

These supporting tools align with the principle of meeting developers where they are, as they spend most of their time coding in their IDE. Integrating tools into the IDE reduces friction and enhances developer velocity and satisfaction. It can be frustrating to switch between the IDE and the browser, especially when managing multiple profiles and trying to open links from different sources. Extensions like Daytona's in VS Code simplify this process by keeping everything within the primary tool and minimizing distractions.

For instance, with Daytona's tools, you can manage workspaces, switch teams, and profiles, which is particularly useful if you have multiple Daytona installations. This approach not only reduces friction but also caters to developers' preferences.

The OpenAPI Specification: A Standard for Innovation

At Daytona, we use the OpenAPI specification to create a clear, standardized API that developers can easily interact with, generating API clients in the appropriate language for different tools. This standardization is not only efficient but also enables new features such as AI interactions, where AI agents using OpenAPI spec can easily understand and interact with your API.

This approach also ties into open-source initiatives, allowing any developer to create supporting tools. For example, someone could integrate Daytona with other platforms or create a Raycast extension for macOS without Daytona having to develop it in-house. By publishing the OpenAPI spec, you empower developers to create tools that suit their needs.

But also it is important to consider the complexities that come with opening up platforms for external contributions. While it adds work, it's an investment that pays off by enabling innovation and collaboration.

The Rise of Intelligent Development Environments

The integration of artificial intelligence (AI) into IDEs is transforming them into Intelligent Development Environments, as forecasted by Manjunath Bhat from Gartner. Local Language Models (LLMs) serve as co-pilots today, but the future may see them become commoditized pilots, integral to the development process. This transition is a testament to the industry's dynamic nature, with IDEs like Cursor and extensions like CodeGPT leading the charge in creating new development workflows.

This constant evolution of developer workflows underscores the importance of creating standardized, extensible infrastructure. Companies that build open and flexible platforms will be best positioned to anticipate and adapt to future changes in the developer experience. Modular architecture based on common standards allows new capabilities like AI to be smoothly integrated over time. The pace of innovation will only accelerate, so developer tools must be designed for interoperability and evolution from the start. Standardization and extensibility will future-proof products as developer needs and environments continue rapidly transforming.

The Compounding Benefits of API-First Thinking

For example, at Daytona we are working on native integrations with VS Code, JetBrains IDEs, our CLI and more. When new platforms gain traction, the community can build clients using well-documented APIs and SDKs. We don't have to build every integration ourselves.

An API-first approach has compounding benefits:

Reduce friction by meeting developers where they already are
Enable community contributions to clients and integrations
Future proof for new platforms by letting the community build for emerging tools

Opening up your platform does require giving up some control. You need processes to curate community integrations before they are published to marketplaces. But done thoughtfully, an API-first approach unlocks contributions and creativity from your user community. Developers want to customize their environment in ways that may not occur to you.

The market will only continue fragmenting as developers gravitate to specialized tools for different tasks. Companies that embrace this reality will thrive. Meet your users where they are now, not where you want them to be. Building in the open creates feedback loops and community ownership that strengthens your product. API-first thinking future proofs you for the next wave of innovation across the incredibly diverse software development landscape.

Key Takeaways

Rapid innovation leads to fragmentation in developer tools
Reduce friction by integrating into environments where users already spend time
Well-documented APIs and SDKs enable ecosystem integrations
Give up some control, but gain creativity from the user community
Meet developers where they are, not where you want them to be
API-first thinking future proofs you for ongoing waves of innovation

The integration ecosystem around developer tools will only grow more complex. Companies that provide the components for others to build on top of will thrive. This means investing in developer experience and documentation for your APIs. When you empower others to extend your platform, it becomes stronger and more adaptable to future needs.

Relying solely on your bespoke interfaces and portals locks users into your narrow worldview. Exposing capabilities through integrations and APIs shares ownership with your community. Developers will reward companies who understand their desire for customization and meet them where they are.

2024: The Year CDEs Go Mainstream

Ivan Burazin — Tue, 16 Jan 2024 00:00:00 +0000

At the end of 2022, I reflected on my career's direction. During this time, I stumbled upon an article proclaiming 2023 as the "Year of the Cloud Development Environment." Reading through it, I couldn't help but wonder: Could it be true? Could the era of CDEs finally be upon us?

I've been immersed in this space since 2009, even co-founding what might have been the first cloud development company. But as the article quipped, "So 2023 is the year of the cloud development environment (CDE)." That sounded like one of the longest-running jokes in tech — "The year of Linux on the desktop." I chuckled, pondering if this was just another tongue-in-cheek.

However, the more I read, the more it resonated. Then, another piece caught my eye – Gartner's hype cycle — now featuring CDEs, including our former product, a veteran of 14 years in the industry. What was happening? Were CDEs finally stepping into the limelight after years of lurking in the shadows?

Evaluating CDEs’ Industry Momentum

As I delved deeper, seeking further validation, I started receiving inbound interest for a new CDE product. Despite my position on a unicorn company's executive board, following the sale of another venture, I felt drawn to explore this. These new signals and encounters were a nudge in a direction I've always found deeply meaningful.

What caught me off guard even more was the increasing interest from industry analysts. For someone who had never briefed an analyst before, I suddenly found myself amid these inquiries, sharing insights and data that reinforced the argument for CDEs.

But a nagging question remained: was this just another bubble? Analysts, after all, have been known to be off the mark. Could I risk my career on a second venture into cloud development?

Validation from Leading Technology Companies

As my investigation into the state of Cloud Development Environments (CDEs) deepened, clear evidence emerged: leading technology firms were not only discussing CDEs but actively embracing them. The adoption was tangible, backed by data and case studies from prominent players in the tech world.

LinkedIn, for example, made significant strides in cloud-based development, demonstrating scalable and effective environments. Shopify's story revealed an evolutionary approach to CDEs, adapting their processes to leverage cloud capabilities fully. Similarly, both Stripe and Palantir have been trailblazers in utilizing CDEs to enhance their operations, setting benchmarks in the industry.

What struck me most was Slack's strategy. Their focus on remote development has set a new standard for team collaboration and efficiency. These examples solidified my belief that CDEs were indeed the future of development, not just a fleeting trend. The data and case studies from these tech giants provided the concrete evidence I needed to confirm that CDEs were here to stay and thrive.

Highlighting Achievements by Uber and Airbnb with CDEs

In addition to Shopify and Stripe, other tech giants have made significant strides with CDEs. Uber, for instance, saw a remarkable improvement in their internal developer NPS score, leaping from a -50 to a commendable +8 after introducing a CDE. This dramatic shift underscores the positive impact that efficient development environments can have on developer satisfaction and productivity.

Similarly, Airbnb celebrated the introduction of CDEs as their biggest success in 2023. This milestone highlights the importance of CDEs in modernizing development workflows and enhancing overall efficiency in software engineering teams.

These achievements by Uber and Airbnb further validate the growing significance of CDEs. They stand as a testament to the transformative potential of cloud-based development environments, not just in improving workflows but in fostering developer satisfaction and organizational success.

Daytona and the Confirmation of a Cloud Development Era

A year has passed since the RedMonk article on CDEs first caught my attention — a piece that, until recently, had slipped from my immediate memory. Interestingly, a casual coffee meet-up with James Governor in December not only brought me full circle but also reminded me of the gratitude I owe him for that initial spark of insight.

The catalyst for this flashback was a recent article by The New Stack titled "Web Development in 2023." Reading it, an entire year flashed before my eyes. I remember initially encountering that prediction with a mix of curiosity and skepticism. Now, almost to the day, a year later, a respected media outlet like The New Stack was confirming what was once just a forecast: 2023 indeed marked the year when CDEs firmly established themselves.

This isn't just about a prediction coming true. The enthusiastic embrace of CDEs across the industry marks just the beginning of an extensive transformation. At Daytona, we feel that we have actively shaped the journey of CDEs. But, as we move beyond acknowledging the emergence of CDEs, it is time to shift our focus toward the management of these environments. This critical phase underlines a maturing market, where Development Environment Management (DEM) comes into play, meeting the growing need for a secure and scalable approach to development workflows.

Through exceptionally thought-out DEM practices, we're set to harness the full capacity of CDEs and push the bounds of innovation and productivity. This journey is far from over; in fact, we are set to embark on the consequential next chapter: refining, optimizing, and elevating the cloud development experience to unparalleled heights with Development Environment Management.