Podcasts about dockerfile

Join Dan Vega and DaShaun Carter for the latest updates from the Spring Ecosystem. In this episode, Dan and DaShaun are joined by Montreal JUG organizer and buildpack expert, Anthony Dahanne. At the end of this episode, you will understand why “Friends don't let friends use Dockerfile.” You can participate in our live stream to ask questions or catch the replay on your preferred podcast platform.Show NotesCloud Native BuildpacksPaketo Buildpacks

In this episode, hosts Lois Houston and Nikita Abraham, along with senior OCI instructor Mahendra Mehra, discuss how Oracle Cloud Infrastructure Registry simplifies the development-to-production workflow for developers.   Listen to Mahendra explain important container registry concepts, such as images, repositories, image tags, and image paths, as well as how they relate to each other.   OCI Container Engine for Kubernetes Specialist: https://mylearn.oracle.com/ou/course/oci-container-engine-for-kubernetes-specialist/134971/210836   Oracle University Learning Community: https://education.oracle.com/ou-community   LinkedIn: https://www.linkedin.com/showcase/oracle-university/   X (formerly Twitter): https://twitter.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, Radhika Banka, and the OU Studio Team for helping us create this episode.   --------------------------------------------------------   Episode Transcript:   00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we'll bring you foundational training on the most popular Oracle technologies. Let's get started! 00:26 Nikita: Hello and welcome to the Oracle University Podcast. I'm Nikita Abraham, Principal Technical Editor with Oracle University, and I'm joined by Lois Houston, Director of Innovation Programs. Lois: Hi there! This is our second episode on OCI Container Engine for Kubernetes, and today we're going to spend time discussing container registries with our colleague and senior OCI instructor, Mahendra Mehra. Nikita: We'll talk about how you can become proficient in managing Oracle Cloud Infrastructure Registry, a vital component in your container workflow.  00:58 Lois: Hi Mahendra, can you explain what Oracle Cloud Infrastructure Registry, or OCIR, is and how it simplifies the container image management process? Mahendra: OCIR is an Oracle-managed registry designed to simplify the development-to-production workflow for developers. It offers a range of functionalities, serving as a private docker registry for internal use where developers can easily store, share, and manage container images.  The strength of OCIR lies in its high available and scalable architecture. Leveraging OCI to ensure reliable deployment of applications, developers can use OCIR not only as a private registry but also as a public registry, facilitating the pulling of images from public repositories for users with internet access. 01:55 Lois: But what sets OCIR apart? Mahendra: What sets OCIR apart is its compliance with the Open Container Initiative standards, allowing the storage of container images conforming to the OCI specifications. It goes a step further by supporting manifest lists, sometimes known as multi-architecture images, accommodating diverse architectures like ARM and AMD64. Additionally, OCIR extends its support to Helm charts. Security is a priority with OCIR, offering private access through a service gateway. This means that OCI resources within a VCN in the same region can securely access OCIR without exposing them to the public internet. 02:46 Nikita: OK. What are some other key advantages of OCIR?  Mahendra: Firstly, OCIR seamlessly integrates with the Container Engine for Kubernetes, ensuring a cohesive container management experience. In terms of security, OCIR provides flexibility by allowing registries to be either private or public, giving administrators control over accessibility. It is intricately integrated with IAM, offering straightforward authentication through OCI Identity. Another notable benefit is regional availability. You can efficiently pull container images from the same region as your deployments. For high-performance, availability, and low-latency image operations, OCIR leverages the robust infrastructure of OCI, enhancing the overall reliability of image push and pull operations. OCIR ensures anywhere access, allowing you to utilize container CLI for image operations from various locations, be it on the cloud, on-premises, or even from personal laptops.  03:57 Lois: I believe OCIR has repository quotas? Is there a cap on them?  Mahendra: In each enabled region for your tenancy, you can establish up to 500 repositories with a cumulative storage limit of 500 GB. Each repository is capable of holding up to 100,000 images. Importantly, charges apply only for stored images. 04:21 Nikita: That's good to know, Mahendra. I want to move on to basic container registry concepts. Maybe we can start with what an image is. Mahendra: Image is basically a read-only template with instructions for creating a container. It holds the application that you want to run as a container, along with any dependencies that are required. Container registry is an Open Container Initiative-compliant registry. As a result, you can store any artifacts that conform to Open Container Initiative specifications, such as Docker images, manifest lists, sometimes also known as multi-architecture images, and Helm charts. 05:02 Lois: And what's a repository then? Mahendra: It's a meaningfully named collection of related images which are grouped together for convenience in a container registry. There are different versions of the same source image, which are grouped together into the same repository.  You can have multiple images stored under this repository. The only thing that you need to keep changing is the image version. Every image version is given a tag. And the tag uniquely identifies the image. 05:33 Lois: Is it possible to make the repository public or private? Mahendra: Depending upon your need, a repository can be made private or public. One important thing to note is that the user needs to have an OCI username and authentication token before being able to push/pull an image from the OCIR. 05:52 Nikita: There are so many terms that you come across when working with repositories and container registry, right? Could you take us through them and explain  how they relate to each other? I've heard of the region key and tenancy namespace. Mahendra: The region key identifies the container registry region that you are using. A tenancy namespace is an auto-generated random and immutable string of alphanumeric characters. The tenancy namespace can be retrieved from the value of your object storage namespace field. Repository name is the name of a repository in container registry, to and from which you can push and pull images. Repository names can include one or more slash characters and are unique across all the compartments in the entire tenancy. You should note that although a repository name can include slash characters, the slash does not represent a hierarchical directory structure. It is simply one character in the string of characters. As a convenience, you might choose to start the name of different repositories with the same string. A registry identifier is the combination of your container registry region key and the tenancy namespace.  07:07 Lois: What about an image tag and an image path? How do they differ from each other? Mahendra: A tag or an image tag is a string used to refer to a particular image in a known registry. The term "image name" is sometimes used as a shorthand way to refer to a particular image in a particular repository. A tag can be a numerical value or it can be a string. An image path is a fully qualified path to a particular image in a registry. It extends the repository path by adding tags associated with the image.  07:46 Do you want to stay ahead of the curve in the ever-evolving AI landscape? Look no further than our brand-new OCI Generative AI Professional course and certification. For a limited time only, we're offering both the course and certification for free. So, don't miss out on this exclusive opportunity to get certified on Generative AI at no cost. Act fast because this offer is valid only until July 31, 2024. Visit https://education.oracle.com/genai to get started. That's https://education.oracle.com/genai. 08:24 Nikita: Welcome back! Mahendra, from what you've told us, OCIR seems like such a pivotal tool for modern containerized workflows, with its seamless integration, robust security measures, regional accessibility, efficient image management. So, how do we actually manage OCIR?  Mahendra: Managing OCIR can be done in three ways. Starting with managing the repository itself, followed by managing the images within the repository, and, last but not the least, managing the overall security of your repository alongside the images. 08:58 Nikita: Can we dive into each of these approaches in a little more detail? How does managing the repository itself work? Mahendra: You can create an empty repository in a compartment and give it a name that's unique across all the compartments in the entire tenancy. There is a limit to the number of repositories you can have in a given region in a tenancy. So, when you no longer need a repository, it makes sense to delete it from the Oracle Cloud Infrastructure registry. Make a note that when you delete a repository, it can take up to 48 hours for the deletion to take effect and for the storage to actually be released. When you create a new repository in Oracle Cloud Infrastructure Registry, you specify the compartment in which you want to create it. Having created the repository in one compartment, you can subsequently move it to a different compartment. The reasons can be many. It can be to change the users who are authorized to use the repository or to change how the billing for a repository is charged. 09:52 Lois: OK. And what about managing images within the repository?  Mahendra: You can view the images stored on OCIR using the OCI Console or using Docker images command from your Docker client after logging in to the OCIR repo. To push an image, you first used the Docker tag command to create a copy of the local source image as a new image. As a name for the new image, you specify the fully-qualified path to the target location in your container registry where you want to push the image, including the name of a repository. In order to pull an image, you must be logged in into the OCIR registry using the auth token and use the Docker pull command followed by a fully-qualified name of the image you wish to download on your Docker client. 10:36 Nikita: What happens when you no longer need an old image or you simply want to clean up the list of image tags in a repository? Mahendra: You can delete images from the Oracle Cloud Infrastructure Registry. You can undelete an image you've previously deleted for up to 48 hours after you deleted it. After that time, the image is permanently removed from the container registry. You can set up image retention policies to automatically delete images that meet particular selection criteria. 11:02 Lois: What sort of selection criteria? Mahendra: Criterias can be images that have not been pulled for a certain number of days or images that have not been tagged for a certain number of days. It can also be images that have not been given particular Docker tags specified as exempt from the automatic deletion. There's an hourly process that checks images against the selection criteria, and any that meet the selection criteria are automatically deleted. In each region in a tenancy, there's a global image retention policy. The default criteria of the policy is to retain all images so that no images are automatically deleted. However, you can change the global image retention policy so that the images are deleted if they meet certain criteria that you specify. A region's global image retention policy applies to all the repository within that region unless it is explicitly overridden by one or more custom image retention policies. Only one custom image retention policy at a time can be applied to a repository. If a repository has already been added to a custom retention policy and you want to add repository to a different custom retention policy, you have to remove the policy from the first retention policy before adding it to the second one. 12:15 Lois: Mahendra, what should we keep in mind when we're dealing with the global image retention policy? Mahendra: The global image retention policy are specific to a particular region. To delete images consistently in different regions in your tenancy, you need to set up image retention policies in each region with identical selection criteria.  If you want to prevent images from being deleted on the basis of Docker tags they've been given, you need to specify those tags as exempt in a comma-separated list. When you want to clean up the list of images in a repository without actually deleting the images, you can remove the tags from the images in OCIR. Removing images is referred to as untagging. 12:53 Nikita: OK…and the last approach was managing the overall security of your repository alongside the images, right?  Mahendra: While managing security, you are given fine grained control over the operations that users are allowed to perform on repositories within the Container Registry. Using the concept of users and groups, you can control repository access by setting up identity access management policies at the tenancy and at the compartment level.  You can write policies to allow inspect, read, use, and manage operations on the repository based on the requirements. You can set up Oracle Cloud Infrastructure Registry to scan images in a repository for security vulnerabilities published in the publicly available common vulnerabilities and exposure databases. To perform image scanning, container registry makes use of the Oracle Cloud Infrastructure vulnerability-scanning service and vulnerability scanning REST API. 13:46 Nikita: What do I need to have in place before I can push and pull Docker images to and from Oracle Cloud Infrastructure Registry? Mahendra: The first thing is, your tenancy must be subscribed to one or more of the regions in which the container registry is available. You can check the same within the Oracle documentation. The next thing is, you need to have access to the Docker command line interface to push and pull images on your local machine. The third thing is, users must belong to a group to which a policy grants the appropriate permission or belong to a tenancies administrator group, which by default have access permissions on the container registry. Lastly, user must already have an Oracle Cloud Infrastructure username and an authentication token, which enables them to perform operations on the container registry. 14:29 Lois: Thank you, Mahendra, for sharing your insights on OCIR with us. To watch demos on managing OCIR, visit mylearn.oracle.com and search for the OCI Container Engine for Kubernetes Specialist course. Nikita: Mahendra will be back next week to walk us through the basics of Kubernetes. Until then, this is Nikita Abraham… Lois: And Lois Houston, signing off! 14:53 That's all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We'd also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.

Welcome to a new season of the Oracle University Podcast, where we delve deep into the world of OCI Container Engine for Kubernetes. Join hosts Lois Houston and Nikita Abraham as they ask senior OCI instructor Mahendra Mehra about the transformative power of containers in application deployment and why they're so crucial in today's software ecosystem.   Uncover key differences between virtualization and containerization, and gain insights into Docker components and commands.   Getting Started with Oracle Cloud Infrastructure: https://oracleuniversitypodcast.libsyn.com/getting-started-with-oracle-cloud-infrastructure-1   Networking in OCI: https://oracleuniversitypodcast.libsyn.com/networking-in-oci   OCI Identity and Access Management: https://oracleuniversitypodcast.libsyn.com/oci-identity-and-access-management   OCI Container Engine for Kubernetes Specialist: https://mylearn.oracle.com/ou/course/oci-container-engine-for-kubernetes-specialist/134971/210836   Oracle University Learning Community: https://education.oracle.com/ou-community   LinkedIn: https://www.linkedin.com/showcase/oracle-university/   X (formerly Twitter): https://twitter.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, Radhika Banka, and the OU Studio Team for helping us create this episode.   ---------------------------------------------------------   Episode Transcript:   00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we'll bring you foundational training on the most popular Oracle technologies. Let's get started! 00:26 Lois: Hello and welcome to the Oracle University Podcast! I'm Lois Houston, Director of Innovation Programs with Oracle University, and with me is Nikita Abraham, Principal Technical Editor.  Nikita: Hi everyone! Welcome to a new season of the Oracle University Podcast. This time around, we're going to delve into the world of OCI Container Engine for Kubernetes, or OKE. For the next couple of weeks, we'll cover key aspects of OKE to help you create, manage, and optimize Kubernetes clusters in Oracle Cloud Infrastructure. 00:58 Lois: So, whether you're a cloud native developer, Kubernetes administrator and developer, a DevOps engineer, or site reliability engineer who wants to enhance your expertise in leveraging the OCI OKE service for cloud native application solutions, you'll want to tune in to these episodes for sure. And if that doesn't sound like you, I'll bet you will find the season interesting even if you're just looking for a deep dive into this service. Nikita: That's right, Lois. In today's episode, we'll focus on concepts of containerization, laying the foundation for your journey into the world of containers. And taking us through all this is Mahendra Mehra, a senior OCI instructor with Oracle University. 01:38 Lois: Hi Mahendra! We're so glad to start our look at containerization with you today. Could you give us an overview? Why is it important in today's software world? Mahendra: Containerization is a form of virtualization, operates by running applications in isolated user spaces known as containers.  All these containers share the same underlying operating system. The container engine, pivotal in containerization technologies and container orchestration platforms, serves as the container runtime environment. It effectively manages the creation, deployment, and execution of containers. 02:18 Lois: Can you simplify this for a novice like me, maybe by giving us an analogy?  Mahendra: Imagine a container as a fully packaged and portable computing environment. It's like a digital suitcase that holds everything an application needs to run—binaries, libraries, configuration files, dependencies, you name it. And the best part, it's all encapsulated and isolated within container. 02:46 Nikita: Mahendra, how is containerization making our lives easier today?  Mahendra: In olden days, running an application meant matching it with your machine's operating system. For example, Windows software required a Windows machine. However, containerization has rewritten this narrative. Now, it's ancient history. With containerization, you create a single software package, a container that gracefully runs on any device or operating systems. What's fascinating is that these containers seamlessly run while sharing the host operating system. The container engine is like a shadow abstracted from the host operating system with limited access to underlying resources. Think of it as a super lightweight virtual machine. The beauty of this, the containerized application becomes a globetrotter, seamlessly running on bare metal within VMs or on the cloud platforms without needing tweaks for each environment. 03:52 Nikita: How is containerization different from traditional virtualization? Mahendra: On one side, we have traditional virtualization. It's like having multiple houses on a single piece of land, and each house or virtual machine has its complete setup—wall, roofs, and utilities. This setup, while providing isolation, can be resource-intensive with each virtual machine carrying its entire operating system. Now, let's shift gears to containerization, the modern day superhero. Imagine a high-rise building where each floor represents a container. These containers share the same building or host operating system, but have their private space or isolated user space. Here's the magic. They are super lightweight, don't carry extra baggage of a full operating system and can swiftly move between different floors. 04:50 Lois: Ok, gotcha. That sounds pretty efficient! So, what are the direct benefits of containerization?  Mahendra: With containerization technology, there's less overhead during startup and no need to set up a separate guest OS for each application since they all share the same OS kernel. Because of this high efficiency, containerization is commonly used for packing up the many individual microservices that make up modern applications. Containerization unfolds a spectrum of benefits, delivering unparalleled portability as containers run uniformly across diverse platforms. This agility, fostered by open source container engines, empowers developers with cross-platform flexibility. The speed of containerized applications known for their lightweight nature reduces cost, boosts efficiency, and accelerates start times. Fault isolation ensures robustness, allowing independent operations without affecting others. Efficiency thrives as containers share the OS kernel and reusable layers, optimizing server utilization. The ease of management is achieved through orchestration platforms like Kubernetes automating essential tasks. Security remains paramount as container isolation and defined permissions fortify the infrastructure against malicious threats. Containerization emerges not just as a technology but as a transformative force, redefining how we build, deploy, and manage applications in the digital landscape. 06:37 Lois: It sure makes deployment efficient, scalability, and seamless! Mahendra, various components of Docker architecture work together to achieve containerization goals, right? Can you walk us through them? Mahendra: A developer or a DevOps professional communicates with Docker engine through the Docker client, which may be run on the same computer as Docker engine in case of development environments or through a remote shell. So whenever a developer fires a Docker command, the client sends them to the Docker Daemon which carries them out. The communication between the Docker client and the Docker host is usually taken place through REST APIs. The Docker clients can communicate with more than one Daemon at a time.  Docker Daemon is a persistent background process that manages Docker images, containers, networks, and storage volumes. The Docker Daemon constantly listens to the Docker API request from the Docker clients and processes them. Docker registries are services that provide locations from where you can store and download Docker images. In other words, a Docker registry contains repositories that host one or more Docker images. Public registries include Docker Hub and Docker Cloud and private registries can also be used. Oracle Cloud Infrastructure offers you services like OCIR, which is also called a container registry, where you can host your own private or public registry. 08:02 Do you want to stay ahead of the curve in the ever-evolving AI landscape? Look no further than our brand-new OCI Generative AI Professional course and certification. For a limited time only, we're offering both the course and certification for free. So, don't miss out on this exclusive opportunity to get certified on Generative AI at no cost. Act fast because this offer is valid only until July 31, 2024. Visit https://education.oracle.com/genai to get started. That's https://education.oracle.com/genai. 08:39 Nikita: Welcome back! Mahendra, I'm wondering how virtual machines are different from containers. How do virtual machines work? Mahendra: A hypervisor or a virtual machine monitor is a software, firmware, or hardware that creates and runs virtual machines. It is placed between the hardware and the virtual machines, and is necessary to virtualize the server. Within each virtual machine runs a unique guest operating system. VMs with different operating systems can run on the same physical server. A Linux VM can sit alongside a Windows VM and so on. Each VM has its own binaries, libraries, and application that it services. And the VM may be many gigabytes in size. 09:22 Lois: What kind of benefits do we see from virtual machines? Mahendra: This technique provides a variety of benefits like the ability to consolidate applications into a single system, cost savings through reduced footprints, and faster server provisioning. But this approach has its own drawbacks. Each VM includes a separate operating system image, which adds overhead in memory and storage footprint. As it turns out, this issue adds complexity to all the stages of software development lifecycle, from development and test to production and disaster recovery as well. It also severely limits the portability of applications between different cloud providers and traditional data centers. And this is where containers come to the rescue.  10:05 Lois: OK…how do containers help in this situation? Mahendra: Containers sit on top of a physical server and its host operating system—typically, Linux or Windows. Each container shares the host OS kernel and usually the binaries and libraries as well. But the shared components are read only. Sharing OS resources such as libraries significantly reduces the need to reproduce the operating system code. A server can run multiple workloads with a single operating system installation. Containers are thus exceptionally lightweight. They are only megabytes in size and take just seconds to start. What this means in practice is you can put two or three times as many applications on a single server with containers than you can put on a virtual machine. Compared to containers, virtual machines take minutes to run and are order of magnitude larger than an equivalent container measured in gigabytes versus megabytes. 11:01 Nikita: So then, is there ever a time you should use a virtual machine? Mahendra: You should use a virtual machine when you want to run applications that specifically require a new OS, also when isolation and security are your priority over everything else. In most scenarios, a container will provide a lighter, faster, and more cost-effective solution than the virtual machines. 11:22 Lois: Now that we've discussed containerization and the different Docker components, can you tell us more about working with Docker images? We first need to know what a Dockerfile is, right?  Mahendra: A Dockerfile is a text file that defines a Docker image. You'll use a Dockerfile to create your own custom Docker image. In other words, you use it to define your custom environment to be used in a Docker container. You'll want to create your own Dockerfile when existing images won't meet your project needs to different runtime requirements, which means that learning about Docker files is an essential part of working with Docker. Dockerfile is a step-by-step definition of building up a Docker image. It provides a set of standard instructions to be used in Dockerfile that Docker will execute when you issue a Docker build command. 12:09 Nikita: Before we wrap up, can you walk us through some Docker commands? Mahendra: Every Dockerfile must start with a FROM instruction. The idea behind this is that you need a starting point to build your image. It can be from scratch or from an existing image available in the Docker registry.  The RUN command is used to execute a command and will wait till the command finishes its execution. Since most of the images are Linux-based, a good practice is to set up a directory you will work in. That's the purpose of work directory line. It defines a directory and moves you in. The COPY instruction helps you to copy your source code into the image. ENV provides default values for variables that can be accessed within the containers. If your app needs to be reached from outside the container, you must open its listening port using the EXPOSE command. Once your application is ready to run, the last thing to do is to specify how to execute it. You must add the CMD line with the same command with all the arguments you used locally to launch your application. This command can also be used to execute commands at runtime for the containers, but we can be more flexible using the ENTRYPOINT command. Labels are used in Dockerfile to help organize your Docker images.   13:20 Lois: Thank you, Mahendra, for joining us today. I learned a lot! And if you want to learn more about working with Docker images, go to mylearn.oracle.com and search for the OCI Container Engine for Kubernetes Specialist course. The course is free so you can get started right away. Nikita: Yeah, a fundamental understanding of core OCI services, like Identity and Access Management, networking, compute, storage, and security, is a prerequisite to the course and will certainly serve you well when leveraging the OCI OKE service. And the quickest way to gain this knowledge is by completing the OCI Foundations Associate learning path on MyLearn and getting certified. You can also listen to episodes from our first season, called OCI Made Easy, where we discussed these topics. We'll put a few links in the show notes so you can easily find them.  Lois: We're looking forward to having Mahendra join us again next week when we'll talk about container registries. Until next time, this is Lois Houston… Nikita: And Nikita Abraham signing off! 14:24 That's all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We'd also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.

Topics covered in this episode: pacemaker - For controlling time per iteration loop in Python. PyPI suspends new user registration to block malware campaign Python Project-Local Virtualenv Management Redux Python Edge Workers at Cloudflare Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: pacemaker - For controlling time per iteration loop in Python. Brandon Rohrer Good example of a small bit of code made into a small package. With speedups to dependencies, like with uv, for example, I think we'll see more small projects. Cool stuff Great README, including quirks that need to be understood by users. “If the pacemaker experiences a delay, it will allow faster iterations to try to catch up. Heads up: because of this, any individual iteration might end up being much shorter than suggested by the pacemaker's target rate.” Nice use of time.monotonic() deltas are guaranteed to never go back in time regardless of what adjustments are made to the system clock. Watch out for pip install pacemaker-lite NOT pacemaker pacemaker is taken by a package named PaceMaker with a repo named pace-maker, that hasn't been updated in 3 years. Not sure if it's alive. No tests (yet). I'm sure they're coming. ;) Seriously though, Brandon says this is “a glorified snippet”. And I love the use of packaging to encapsulate shared code. Realistically, small snippet like packages have functionality that's probably going to be tested by end user code. And even if there are tests, users should test the functionality they are depending on. Michael #2: PyPI suspends new user registration to block malware campaign Incident Report for Python Infrastructure PyPi Is Under Attack: Project Creation and User Registration Suspended — Here's the details I hate medium, but it's the best details I've found so far Brian #3: Python Project-Local Virtualenv Management Redux Hynek Concise writeup of how Hynek uses various tools for dealing with environments Covers (paren notes are from Brian) In project .venv directories direnv for handling .envrc files per project (time for me to try this again) uv for pip and pip-compile functionality Installing Python via python.org Using a .python-version-default file (I'll need to play with this a bit) Works with GH Action setup-python. (ok. that's cool) Some fish shell scripting Bonus tip on using requires-python in .pyproject.toml and extracting it in GH actions to be able to get the python exe name, and then be able to pass it to Docker and reference it in a Dockerfile. (very cool) Michael #4: Python Edge Workers at Cloudflare What are edge workers? Based on workers using Pyodide and WebAssembly This new support for Python is different from how Workers have historically supported languages beyond JavaScript — in this case, we have directly integrated a Python implementation into workerd, the open-source Workers runtime. Python Workers can import a subset of popular Python packages including FastAPI, Langchain, numpy Check out the examples repo. Extras Michael: LPython follow up from Brian Skinn Featured on Python Bytes badge A little downtime, thanks for the understanding We were rocking a 99.98% uptime until then. :) Joke: C++ is not safe for people under 18 Baseball joke

Docker und sein Ökosystem haben wir im März auf einem programmier.bar-Meetup näher kennengelernt. Dass wir mit Dennis Oehme einen Experten dazu zu Gast hatten, ist ein guter Anlass, um nun auch im Podcast detailliert über die Vorzüge von Dockers neuer Build-Engine „BuildKit“ zu sprechen.Dennis erklärt uns nicht nur die wesentlichen Unterschiede von BuildKit und seinem Vorgänger, sondern beschreibt auch den tatsächlichen Nutzen für den Arbeitsalltag von Entwickler:innen.Neben den ganzen Neuerungen berichtet Dennis auch aus seinem Arbeitsalltag mit Docker und gibt Tipps und Tricks im Umgang mit und in der Erstellung von Docker Images und berichtet über Best Practices aus Security-Perspektive.Wir sprechen über den Einsatz von Docker in der lokalen Entwicklung, in CI/CD-Pipelines und im Deployment – und sogar über Use Cases von Images, die gebaut werden, ohne jemals deployed zu werden. Wenn euch das genau so verwundert wie Jan, dann solltet ihr diese Folge auf keinen Fall verpassen.Picks of the Day: Jan Gregor: ASCII Star Wars – Wer sich schon immer einmal „Star Wars - Episode IV“ (also einen der guten Filme ;)) in ASCII Art auf der Konsole anschauen wollte, hat jetzt die Gelegenheit dazu. Mittels dem Command `nc` (netcat) kann man einen ASCII Stream des Films schauen indem man einfach `nc towel.blinkenlights.nl 23` im Terminal eingibt. Sollte der Server des Hobbyprojekts gerade einmal nicht zur Verfügung stehen, gibt es auch eine Webversion zum Anschauen. Dennis: just - a command runner – Wem `make` zu archaisch ist und wer keine Lust auf den Syntax von unzähligen Bash-Skripten hat, für den ist `just` das Tool der Wahl. Das in Rust geschriebene Tool ermöglicht euch projektspezifische Tasks zu skripten und steht sowohl für Windows, als auch macOS und Linux zur Verfügung. Es bringt nützliche Features wie Unterstützung für Umgebungsvariablen, Command Line Arguments und vieles weitere von Haus aus mit. Darüber hinaus könnt ihr sogar mit Sprachen wie Python, JavaScript oder Ruby hantieren, wenn ihr nicht (nur) im nativen `justfile`-Format arbeiten wollt. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik: Hanimo

Über kaum eine Container-Technologie wird so viel geschimpft wie über Kubernetes. Die Orchestrierungslösung wird oftmals als „komplizierteste Abstraktion überhaupt“ verschrien. Grund genug für uns, das Thema mit einem Experten zu beleuchten.Garrelt und Jan haben deshalb Ilja Bauer ins Podcaststudio nach Bad Nauheim eingeladen. Der Mitgründer von Entwicklerheld betreibt Deutschlands größte Coding-Plattform für 40.000 Entwickler:innen schon länger mit Kubernetes und hat schon diverse Cloud-Migrationen hinter sich.Gemeinsam besprechen wir, warum Kubernetes sinnvoll sein kann und zeigen auch für kleinere Projekte passende Kubernetes-Distributionen auf. Eine dieser Distributionen ist K3s, auf das wir im Detail eingehen.Ilja berichtet uns von Tipps und Tricks aus seiner jahrelangen Praxiserfahrung und erklärt uns, wie man auch jedes noch so kleine Projekt mit K3s angehen kann und warum das der bessere Ansatz sein mag.Insbesondere Jan ist von dieser Folge inspiriert und nimmt für seine eigenen Server viel mit. Er wird wohl bald eine Migration angehen.Picks of the Day: Jan Gregor: Terms of Service, Didn't read – Wahrscheinlich hat niemand da draußen so wirklich einen Überblick darüber, welchen Geschäftsbedingungen, Terms of Service und AGBs er oder sie schon so alles zugestimmt hat. Ganz davon zu schweigen, was man damit überhaupt alles zugestimmt und abgenickt hat. Diesem Problem will sich „Terms of Service, Didn't read“ annehmen, indem es einfach und verständlich aufbereitet, was in den Geschäftsbedingungen größerer Plattformen und Anbietern alles so steht. Außerdem gibt es noch ein Benotungssystem, das helfen soll, auf einen Blick zu verstehen, wie anwendungsfreundlich die Bedingungen sind. Garrelt: The Grug Brained Developer – "grug once think big brained but learn hard way" Unter dem Pseudonym „Grug Brained Developer“ gibt ein Softwareentwickler einen Einblick in seine Denkweise und Arbeit. Auf humorvolle und selbstreflektierte Art lernt er (und die Leser:innen) dabei Bescheidenheit und Weitsicht. Ilja: PGlite - Postgres in WASM – PGlite ist ein Postgres Build in WebAssembly. Das Ganze ist dann noch als ein handliches Package verfügbar, sodass ihr es bequem in euer Node/Bun/Deno Projekt importieren könnt. Alternativ könnt ihr es auch im Browser direkt verwenden. Somit steht euch unter jeder Umgebung eine potente Datenbank zur Verfügung, die ihr einfach programmatisch instanzieren könnt. So lassen sich zum Beispiel leicht (offline) Caches oder Test-Datenbanken realisieren. Ohne, dass ihr dafür auf eure bekannten Postgres-Kenntnisse verzichten müsstet. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik:

This Friday we're doing a special crossover event in SF with of SemiAnalysis (previous guest!), and we will do a live podcast on site. RSVP here. Also join us on June 25-27 for the biggest AI Engineer conference of the year!Replicate is one of the most popular AI inference providers, reporting over 2 million users as of their $40m Series B with a16z. But how did they get there? The Definitive Replicate Story (warts and all)Their overnight success took 5 years of building, and it all started with arXiv Vanity, which was a 2017 vacation project that scrapes arXiv PDFs and re-renders them into semantic web pages that reflow nicely with better typography and whitespace. From there, Ben and Andreas' idea was to build tools to make ML research more robust and reproducible by making it easy to share code artefacts alongside papers. They had previously created Fig, which made it easy to spin up dev environments; it was eventually acquired by Docker and turned into `docker-compose`, the industry standard way to define services from containerized applications. 2019: CogThe first iteration of Replicate was a Fig-equivalent for ML workloads which they called Cog; it made it easy for researchers to package all their work and share it with peers for review and reproducibility. But they found that researchers were terrible users: they'd do all this work for a paper, publish it, and then never return to it again. “We talked to a bunch of researchers and they really wanted that.... But how the hell is this a business, you know, like how are we even going to make any money out of this? …So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. Do you want like a deployment platform for deploying models? Do you want a central place for versioning models? We were trying to think of lots of different products we could sell that were related to this thing…So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day.”The team graduated YCombinator with no customers, no product and nothing to demo - which was fine because demo day got canceled as the YC W'20 class graduated right into the pandemic. The team spent the next year exploring and building Covid tools.2021: CLIP + GAN = PixRayBy 2021, OpenAI released CLIP. Overnight dozens of Discord servers got spun up to hack on CLIP + GANs. Unlike academic researchers, this community was constantly releasing new checkpoints and builds of models. PixRay was one of the first models being built on Replicate, and it quickly started taking over the community. Chris Dixon has a famous 2010 post titled “The next big thing will start out looking like a toy”; image generation would have definitely felt like a toy in 2021, but it gave Replicate its initial boost.2022: Stable DiffusionIn August 2022 Stable Diffusion came out, and all the work they had been doing to build this infrastructure for CLIP / GANs models became the best way for people to share their StableDiffusion fine-tunes:And like the first week we saw people making animation models out of it. We saw people make game texture models that use circular convolutions to make repeatable textures. We saw a few weeks later, people were fine tuning it so you could put your face in these models and all of these other ways. […] So tons of product builders wanted to build stuff with it. And we were just sitting in there in the middle, as the interface layer between all these people who wanted to build, and all these machine learning experts who were building cool models. And that's really where it took off. Incredible supply, incredible demand, and we were just in the middle.(Stable Diffusion also spawned Latent Space as a newsletter)The landing page paved the cowpath for the intense interest in diffusion model APIs.2023: Llama & other multimodal LLMsBy 2023, Replicate's growing visibility in the Stable Diffusion indie hacker community came from top AI hackers like Pieter Levels and Danny Postmaa, each making millions off their AI apps:Meta then released LLaMA 1 and 2 (our coverage of it), greatly pushing forward the SOTA open source model landscape. Demand for text LLMs and other modalities rose, and Replicate broadened its focus accordingly, culminating in a $18m Series A and $40m Series B from a16z (at a $350m valuation).Building standards for the AI worldNow that the industry is evolving from toys to enterprise use cases, all these companies are working to set standards for their own space. We cover this at ~45 mins in the podcast. Some examples:* LangChain has been trying to establish "chain” as the standard mental models when putting multiple prompts and models together, and the “LangChain Expression Language” to go with it. (Our episode with Harrison)* LLamaHub for packaging RAG utilities. (Our episode with Jerry)* Ollama's Modelfile to define runtimes for different model architectures. These are usually targeted at local inference. * Cog (by Replicate) to create environments to which you can easily attach CUDA devices and make it easy to spin up inference on remote servers. * GGUF as the filetype ggml-based executors. None of them have really broken out yet, but this is going to become a fiercer competition as the market matures. Full Video PodcastAs a reminder, all Latent Space pods now come in full video on our YouTube, with bonus content that we cut for time!Show Notes* Ben Firshman* Replicate* Free $10 credit for Latent Space readers* Andreas Jansson (Ben's co-founder)* Charlie Holtz (Replicate's Hacker in Residence)* Fig (now Docker Compose)* Command Line Interface Guidelines (clig)* Apple Human Interface Guidelines* arXiv Vanity* Open Interpreter* PixRay* SF Compute* Big Sleep by Advadnoun* VQGAN-CLIP by Rivers Have WingsTimestamps* [00:00:00] Introductions* [00:01:17] Low latency is all you need* [00:04:08] Evolution of CLIs* [00:05:59] How building ArxivVanity led to Replicate* [00:11:37] Making ML research replicable with containers* [00:17:22] Doing YC in 2020 and pivoting to tools for COVID* [00:20:22] Launching the first version of Replicate* [00:25:51] Embracing the generative image community* [00:28:04] Getting reverse engineered into an API product* [00:31:25] Growing to 2 million users* [00:34:29] Indie vs Enterprise customers* [00:37:09] How Unsplash uses Replicate* [00:38:29] Learnings from Docker that went into Cog* [00:45:25] Creating AI standards* [00:50:05] Replicate's compute availability* [00:53:55] Fixing GPU waste* [01:00:39] What's open source AI?* [01:04:46] Building for AI engineers* [01:06:41] Hiring at ReplicateThis summary covers the full range of topics discussed throughout the episode, providing a comprehensive overview of the content and insights shared.TranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space podcast. This is Alessio, partner and CTO in Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:14]: Hey, and today we have Ben Firshman in the studio. Welcome Ben.Ben [00:00:18]: Hey, good to be here.Swyx [00:00:19]: Ben, you're a co-founder and CEO of Replicate. Before that, you were most notably founder of Fig, which became Docker Compose. You also did a couple of other things before that, but that's what a lot of people know you for. What should people know about you that, you know, outside of your, your sort of LinkedIn profile?Ben [00:00:35]: Yeah. Good question. I think I'm a builder and tinkerer, like in a very broad sense. And I love using my hands to make things. So like I work on, you know, things may be a bit closer to tech, like electronics. I also like build things out of wood and I like fix cars and I fix my bike and build bicycles and all this kind of stuff. And there's so much, I think I've learned from transferable skills, from just like working in the real world to building things, building things in software. And you know, it's so much about being a builder, both in real life and, and in software that crosses over.Swyx [00:01:11]: Is there a real world analogy that you use often when you're thinking about like a code architecture or problem?Ben [00:01:17]: I like to build software tools as if they were something real. So I wrote this thing called the command line interface guidelines, which was a bit like sort of the Mac human interface guidelines, but for command line interfaces, I did it with the guy I created Docker Compose with and a few other people. And I think something in there, I think I described that your command line interface should feel like a big iron machine where you pull a lever and it goes clunk and like things should respond within like 50 milliseconds as if it was like a real life thing. And like another analogy here is like in the real life, you know, when you press a button on an electronic device and it's like a soft switch and you press it and nothing happens and there's no physical feedback of anything happening, then like half a second later, something happens. Like that's how a lot of software feels, but instead like software should feel more like something that's real where you touch, you pull a physical lever and the physical lever moves, you know, and I've taken that lesson of kind of human interface to, to software a ton. You know, it's all about kind of low latency of feeling, things feeling really solid and robust, both the command lines and, and user interfaces as well.Swyx [00:02:22]: And how did you operationalize that for Fig or Docker?Ben [00:02:27]: A lot of it's just low latency. Actually, we didn't do it very well for Fig in the first place. We used Python, which was a big mistake where Python's really hard to get booting up fast because you have to load up the whole Python runtime before it can run anything. Okay. Go is much better at this where like Go just instantly starts.Swyx [00:02:45]: You have to be under 500 milliseconds to start up?Ben [00:02:48]: Yeah, effectively. I mean, I mean, you know, perception of human things being immediate is, you know, something like a hundred milliseconds. So anything like that is, is yeah, good enough.Swyx [00:02:57]: Yeah. Also, I should mention, since we're talking about your side projects, well, one thing is I am maybe one of a few fellow people who have actually written something about CLI design principles because I was in charge of the Netlify CLI back in the day and had many thoughts. One of my fun thoughts, I'll just share it in case you have thoughts, is I think CLIs are effectively starting points for scripts that are then run. And the moment one of the script's preconditions are not fulfilled, typically they end. So the CLI developer will just exit the program. And the way that I designed, I really wanted to create the Netlify dev workflow was for it to be kind of a state machine that would resolve itself. If it detected a precondition wasn't fulfilled, it would actually delegate to a subprogram that would then fulfill that precondition, asking for more info or waiting until a condition is fulfilled. Then it would go back to the original flow and continue that. I don't know if that was ever tried or is there a more formal definition of it? Because I just came up with it randomly. But it felt like the beginnings of AI in the sense that when you run a CLI command, you have an intent to do something and you may not have given the CLI all the things that it needs to do, to execute that intent. So that was my two cents.Ben [00:04:08]: Yeah, that reminds me of a thing we sort of thought about when writing the CLI guidelines, where CLIs were designed in a world where the CLI was really a programming environment and it's primarily designed for machines to use all of these commands and scripts. Whereas over time, the CLI has evolved to humans. It was back in a world where the primary way of using computers was writing shell scripts effectively. We've transitioned to a world where actually humans are using CLI programs much more than they used to. And the current sort of best practices about how Unix was designed, there's lots of design documents about Unix from the 70s and 80s, where they say things like, command line commands should not output anything on success. It should be completely silent, which makes sense if you're using it in a shell script. But if a user is using that, it just looks like it's broken. If you type copy and it just doesn't say anything, you assume that it didn't work as a new user. I think what's really interesting about the CLI is that it's actually a really good, to your point, it's a really good user interface where it can be like a conversation, where it feels like you're, instead of just like you telling the computer to do this thing and either silently succeeding or saying, no, you did, failed, it can guide you in the right direction and tell you what your intent might be, and that kind of thing in a way that's actually, it's almost more natural to a CLI than it is in a graphical user interface because it feels like this back and forth with the computer, almost funnily like a language model. So I think there's some interesting intersection of CLIs and language models actually being very sort of closely related and a good fit for each other.Swyx [00:05:59]: Yeah, I'll say one of the surprises from last year, I worked on a coding agent, but I think the most successful coding agent of my cohort was Open Interpreter, which was a CLI implementation. And I have chronically, even as a CLI person, I have chronically underestimated the CLI as a useful interface. You also developed ArchiveVanity, which you recently retired after a glorious seven years.Ben [00:06:22]: Something like that.Swyx [00:06:23]: Which is nice, I guess, HTML PDFs.Ben [00:06:27]: Yeah, that was actually the start of where Replicate came from. Okay, we can tell that story. So when I quit Docker, I got really interested in science infrastructure, just as like a problem area, because it is like science has created so much progress in the world. The fact that we're, you know, can talk to each other on a podcast and we use computers and the fact that we're alive is probably thanks to medical research, you know. But science is just like completely archaic and broken and it's like 19th century processes that just happen to be copied to the internet rather than take into account that, you know, we can transfer information at the speed of light now. And the whole way science is funded and all this kind of thing is all kind of very broken. And there's just so much potential for making science work better. And I realized that I wasn't a scientist and I didn't really have any time to go and get a PhD and become a researcher, but I'm a tool builder and I could make existing scientists better at their job. And if I could make like a bunch of scientists a little bit better at their job, maybe that's the kind of equivalent of being a researcher. So one particular thing I dialed in on is just how science is disseminated in that all of these PDFs, quite often behind paywalls, you know, on the internet.Swyx [00:07:34]: And that's a whole thing because it's funded by national grants, government grants, then they're put behind paywalls. Yeah, exactly.Ben [00:07:40]: That's like a whole, yeah, I could talk for hours about that. But the particular thing we got dialed in on was, interestingly, these PDFs are also, there's a bunch of open science that happens as well. So math, physics, computer science, machine learning, notably, is all published on the archive, which is actually a surprisingly old institution.Swyx [00:08:00]: Some random Cornell.Ben [00:08:01]: Yeah, it was just like somebody in Cornell who started a mailing list in the 80s. And then when the web was invented, they built a web interface around it. Like it's super old.Swyx [00:08:11]: And it's like kind of like a user group thing, right? That's why they're all these like numbers and stuff.Ben [00:08:15]: Yeah, exactly. Like it's a bit like something, yeah. That's where all basically all of math, physics and computer science happens. But it's still PDFs published to this thing. Yeah, which is just so infuriating. The web was invented at CERN, a physics institution, to share academic writing. Like there are figure tags, there are like author tags, there are heading tags, there are site tags. You know, hyperlinks are effectively citations because you want to link to another academic paper. But instead, you have to like copy and paste these things and try and get around paywalls. Like it's absurd, you know. And now we have like social media and things, but still like academic papers as PDFs, you know. This is not what the web was for. So anyway, I got really frustrated with that. And I went on vacation with my old friend Andreas. So we were, we used to work together in London on a startup, at somebody else's startup. And we were just on vacation in Greece for fun. And he was like trying to read a machine learning paper on his phone, you know, like we had to like zoom in and like scroll line by line on the PDF. And he was like, this is f*****g stupid. So I was like, I know, like this is something we discovered our mutual hatred for this, you know. And we spent our vacation sitting by the pool, like making latex to HTML, like converters, making the first version of Archive Vanity. Anyway, that was up then a whole thing. And the story, we shut it down recently because they caught the eye of Archive. They were like, oh, this is great. We just haven't had the time to work on this. And what's tragic about the Archive, it's like this project of Cornell that's like, they can barely scrounge together enough money to survive. I think it might be better funded now than it was when we were, we were collaborating with them. And compared to these like scientific journals, it's just that this is actually where the work happens. But they just have a fraction of the money that like these big scientific journals have, which is just so tragic. But anyway, they were like, yeah, this is great. We can't afford to like do it, but do you want to like as a volunteer integrate arXiv Vanity into arXiv?Swyx [00:10:05]: Oh, you did the work.Ben [00:10:06]: We didn't do the work. We started doing the work. We did some. I think we worked on this for like a few months to actually get it integrated into arXiv. And then we got like distracted by Replicate. So a guy called Dan picked up the work and made it happen. Like somebody who works on one of the, the piece of the libraries that powers arXiv Vanity. Okay.Swyx [00:10:26]: And the relationship with arXiv Sanity?Ben [00:10:28]: None.Swyx [00:10:30]: Did you predate them? I actually don't know the lineage.Ben [00:10:32]: We were after, we both were both users of arXiv Sanity, which is like a sort of arXiv...Ben [00:10:37]: Which is Andre's RecSys on top of arXiv.Ben [00:10:40]: Yeah. Yeah. And we were both users of that. And I think we were trying to come up with a working name for arXiv and Andreas just like cracked a joke of like, oh, let's call it arXiv Vanity. Let's make the papers look nice. Yeah. Yeah. And that was the working name and it just stuck.Swyx [00:10:52]: Got it.Ben [00:10:53]: Got it.Alessio [00:10:54]: Yeah. And then from there, tell us more about why you got distracted, right? So Replicate, maybe it feels like an overnight success to a lot of people, but you've been building this since 2019. Yeah.Ben [00:11:04]: So what prompted the start?Alessio [00:11:05]: And we've been collaborating for even longer.Ben [00:11:07]: So we created arXiv Vanity in 2017. So in some sense, we've been doing this almost like six, seven years now, a classic seven year.Swyx [00:11:16]: Overnight success.Ben [00:11:17]: Yeah. Yes. We did arXiv Vanity and then worked on a bunch of like surrounding projects. I was still like really interested in science publishing at that point. And I'm trying to remember, because I tell a lot of like the condensed story to people because I can't really tell like a seven year history. So I'm trying to figure out like the right. Oh, we got room. The right length.Swyx [00:11:35]: We want to nail the definitive Replicate story here.Ben [00:11:37]: One thing that's really interesting about these machine learning papers is that these machine learning papers are published on arXiv and a lot of them are actual fundamental research. So like should be like prose describing a theory. But a lot of them are just running pieces of software that like a machine learning researcher made that did something, you know, it was like an image classification model or something. And they managed to make an image classification model that was better than the existing state of the art. And they've made an actual running piece of software that does image segmentation. And then what they had to do is they then had to take that piece of software and write it up as prose and math in a PDF. And what's frustrating about that is like if you want to. So this was like Andreas is, Andreas was a machine learning engineer at Spotify. And some of his job was like he did pure research as well. Like he did a PhD and he was doing a lot of stuff internally. But part of his job was also being an engineer and taking some of these existing things that people have made and published and trying to apply them to actual problems at Spotify. And he was like, you know, you get given a paper which like describes roughly how the model works. It's probably listing lots of crucial information. There's sometimes code on GitHub. More and more there's code on GitHub. But back then it was kind of relatively rare. But it's quite often just like scrappy research code and didn't actually run. And, you know, there was maybe the weights that were on Google Drive, but they accidentally deleted the weights of Google Drive, you know, and it was like really hard to like take this stuff and actually use it for real things. We just started talking together about like his problems at Spotify and I connected this back to my work at Docker as well. I was like, oh, this is what we created containers for. You know, we solved this problem for normal software by putting the thing inside a container so you could ship it around and it kept on running. So we were sort of hypothesizing about like, hmm, what if we put machine learning models inside containers so they could actually be shipped around and they could be defined in like some production ready formats and other researchers could run them to generate baselines and you could people who wanted to actually apply them to real problems in the world could just pick up the container and run it, you know. And we then thought this is quite whether it gets normally in this part of the story I skip forward to be like and then we created cog this container stuff for machine learning models and we created Replicate, the place for people to publish these machine learning models. But there's actually like two or three years between that. The thing we then got dialed into was Andreas was like, what if there was a CI system for machine learning? It's like one of the things he really struggled with as a researcher is generating baselines. So when like he's writing a paper, he needs to like get like five other models that are existing work and get them running.Swyx [00:14:21]: On the same evals.Ben [00:14:22]: Exactly, on the same evals so you can compare apples to apples because you can't trust the numbers in the paper.Swyx [00:14:26]: So you can be Google and just publish them anyway.Ben [00:14:31]: So I think this was coming from the thinking of like there should be containers for machine learning, but why are people going to use that? Okay, maybe we can create a supply of containers by like creating this useful tool for researchers. And the useful tool was like, let's get researchers to package up their models and push them to the central place where we run a standard set of benchmarks across the models so that you can trust those results and you can compare these models apples to apples and for like a researcher for Andreas, like doing a new piece of research, he could trust those numbers and he could like pull down those models, confirm it on his machine, use the standard benchmark to then measure his model and you know, all this kind of stuff. And so we started building that. That's what we applied to YC with, got into YC and we started sort of building a prototype of this. And then this is like where it all starts to fall apart. We were like, okay, that sounds great. And we talked to a bunch of researchers and they really wanted that and that sounds brilliant. That's a great way to create a supply of like models on this research platform. But how the hell is this a business, you know, like how are we even going to make any money out of this? And we're like, oh s**t, that's like the, that's the real unknown here of like what the business is. So we thought it would be a really good idea to like, okay, before we get too deep into this, let's try and like reduce the risk of this turning into a business. So let's try and like research what the business could be for this research tool effectively. So we went and talked to a bunch of companies trying to sell them something which didn't exist. So we're like, hey, do you want a way to share research inside your company so that other researchers or say like the product manager can test out the machine learning model? They're like, maybe. And we were like, do you want like a deployment platform for deploying models? Like, do you want like a central place for versioning models? Like we're trying to think of like lots of different like products we could sell that were like related to this thing. And terrible idea. Like we're not sales people and like people don't want to buy something that doesn't exist. I think some people can pull this off, but we were just like, you know, a bunch of product people, products and engineer people, and we just like couldn't pull this off. So we then got halfway through our YC batch. We hadn't built a product. We had no users. We had no idea what our business was going to be because we couldn't get anybody to like buy something which didn't exist. And actually there was quite a way through our, I think it was like two thirds the way through our YC batch or something. And we're like, okay, well we're kind of screwed now because we don't have anything to show at demo day. And then we then like tried to figure out, okay, what can we build in like two weeks that'll be something. So we like desperately tried to, I can't remember what we've tried to build at that point. And then two weeks before demo day, I just remember it was all, we were going down to Mountain View every week for dinners and we got called on to like an all hands Zoom call, which was super weird. We're like, what's going on? And they were like, don't come to dinner tomorrow. And we realized, we kind of looked at the news and we were like, oh, there's a pandemic going on. We were like so deep in our startup. We were just like completely oblivious to what was going on around us.Swyx [00:17:20]: Was this Jan or Feb 2020?Ben [00:17:22]: This was March 2020. March 2020. 2020.Swyx [00:17:25]: Yeah. Because I remember Silicon Valley at the time was early to COVID. Like they started locking down a lot faster than the rest of the US.Ben [00:17:32]: Yeah, exactly. And I remember, yeah, soon after that, like there was the San Francisco lockdowns and then like the YC batch just like stopped. There wasn't demo day and it was in a sense a blessing for us because we just kind ofSwyx [00:17:43]: In the normal course of events, you're actually allowed to defer to a future demo day. Yeah.Ben [00:17:51]: So we didn't even take any defer because it just kind of didn't happen.Swyx [00:17:55]: So was YC helpful?Ben [00:17:57]: Yes. We completely screwed up the batch and that was our fault. I think the thing that YC has become incredibly valuable for us has been after YC. I think there was a reason why we couldn't, didn't need to do YC to start with because we were quite experienced. We had done some startups before. We were kind of well connected with VCs, you know, it was relatively easy to raise money because we were like a known quantity. You know, if you go to a VC and be like, Hey, I made this piece of-Swyx [00:18:24]: It's Docker Compose for AI.Ben [00:18:26]: Exactly. Yeah. And like, you know, people can pattern match like that and they can have some trust, you know what you're doing. Whereas it's much harder for people straight out of college and that's where like YC sweet spot is like helping people straight out of college who are super promising, like figure out how to do that.Swyx [00:18:40]: No credentials.Ben [00:18:41]: Yeah, exactly. We don't need that. But the thing that's been incredibly useful for us since YC has been, this was actually, I think, so Docker was a YC company and Solomon, the founder of Docker, I think told me this. He was like, a lot of people underestimate the value of YC after you finish the batch. And his biggest regret was like not staying in touch with YC. I might be misattributing this, but I think it was him. And so we made a point of that. And we just stayed in touch with our batch partner, who Jared at YC has been fantastic.Ben [00:19:10]: Jared Friedman. All of like the team at YC, there was the growth team at YC when they were still there and they've been super helpful. And two things have been super helpful about that is like raising money, like they just know exactly how to raise money. And they've been super helpful during that process in all of our rounds, like we've done three rounds since we did YC and they've been super helpful during the whole process. And also just like reaching a ton of customers. So like the magic of YC is that you have all of, like there's thousands of YC companies, I think, on the order of thousands, I think. And they're all of your first customers. And they're like super helpful, super receptive, really want to like try out new things. You have like a warm intro to every one of them basically. And there's this mailing list where you can post about updates to your products, which is like really receptive. And that's just been fantastic for us. Like we've just like got so many of our users and customers through YC. Yeah.Swyx [00:20:00]: Well, so the classic criticism or the sort of, you know, pushback is people don't buy you because you are both from YC. But at least they'll open the email. Right. Like that's the... Okay.Ben [00:20:13]: Yeah. Yeah. Yeah.Swyx [00:20:16]: So that's been a really, really positive experience for us. And sorry, I interrupted with the YC question. Like you were, you make it, you just made it out of the YC, survived the pandemic.Ben [00:20:22]: I'll try and condense this a little bit. Then we started building tools for COVID weirdly. We were like, okay, we don't have a startup. We haven't figured out anything. What's the most useful thing we could be doing right now?Swyx [00:20:32]: Save lives.Ben [00:20:33]: So yeah. Let's try and save lives. I think we failed at that as well. We had a bunch of products that didn't really go anywhere. We kind of worked on, yeah, a bunch of stuff like contact tracing, which turned out didn't really be a useful thing. Sort of Andreas worked on like a door dash for like people delivering food to people who are vulnerable. What else did we do? The meta problem of like helping people direct their efforts to what was most useful and a few other things like that. It didn't really go anywhere. So we're like, okay, this is not really working either. We were considering actually just like doing like work for COVID. We have this decision document early on in our company, which is like, should we become a like government app contracting shop? We decided no.Swyx [00:21:11]: Because you also did work for the gov.uk. Yeah, exactly.Ben [00:21:14]: We had experience like doing some like-Swyx [00:21:17]: And the Guardian and all that.Ben [00:21:18]: Yeah. For like government stuff. And we were just like really good at building stuff. Like we were just like product people. Like I was like the front end product side and Andreas was the back end side. So we were just like a product. And we were working with a designer at the time, a guy called Mark, who did our early designs for Replicate. And we were like, hey, what if we just team up and like become and build stuff? And yeah, we gave up on that in the end for, I can't remember the details. So we went back to machine learning. And then we were like, well, we're not really sure if this is going to work. And one of my most painful experiences from previous startups is shutting them down. Like when you realize it's not really working and having to shut it down, it's like a ton of work and it's people hate you and it's just sort of, you know. So we were like, how can we make something we don't have to shut down? And even better, how can we make something that won't page us in the middle of the night? So we made an open source project. We made a thing which was an open source Weights and Biases, because we had this theory that like people want open source tools. There should be like an open source, like version control, experiment tracking like thing. And it was intuitive to us and we're like, oh, we're software developers and we like command line tools. Like everyone loves command line tools and open source stuff, but machine learning researchers just really didn't care. Like they just wanted to click on buttons. They didn't mind that it was a cloud service. It was all very visual as well, that you need lots of graphs and charts and stuff like this. So it wasn't right. Like it was right. We actually were building something that Andreas made at Spotify for just like saving experiments to cloud storage automatically, but other people didn't really want this. So we kind of gave up on that. And then that was actually originally called Replicate and we renamed that out of the way. So it's now called Keepsake and I think some people still use it. Then we sort of came back, we looped back to our original idea. So we were like, oh, maybe there was a thing in that thing we were originally sort of thinking about of like researchers sharing their work and containers for machine learning models. So we just built that. And at that point we were kind of running out of the YC money. So we were like, okay, this like feels good though. Let's like give this a shot. So that was the point we raised a seed round. We raised seed round. Pre-launch. We raised pre-launch and pre-team. It was an idea basically. We had a little prototype. It was just an idea and a team. But we were like, okay, like, you know, bootstrapping this thing is getting hard. So let's actually raise some money. Then we made Cog and Replicate. It initially didn't have APIs, interestingly. It was just the bit that I was talking about before of helping researchers share their work. So it was a way for researchers to put their work on a webpage such that other people could try it out and so that you could download the Docker container. We cut the benchmarks thing of it because we thought that was just like too complicated. But it had a Docker container that like, you know, Andreas in a past life could download and run with his benchmark and you could compare all these models apples to apples. So that was like the theory behind it. That kind of started to work. It was like still when like, you know, it was long time pre-AI hype and there was lots of interesting stuff going on, but it was very much in like the classic deep learning era. So sort of image segmentation models and sentiment analysis and all these kinds of things, you know, that people were using, that we're using deep learning models for. And we were very much building for research because all of this stuff was happening in research institutions, you know, the sort of people who'd be publishing to archive. So we were creating an accompanying material for their models, basically, you know, they wanted a demo for their models and we were creating a company material for it. What was funny about that is they were like not very good users. Like they were, they were doing great work obviously, but, but the way that research worked is that they, they just made like one thing every six months and they just fired and forget it, forgot it. Like they, they published this piece of paper and like, done, I've, I've published it. So they like output it to Replicate and then they just stopped using Replicate. You know, they were like once every six monthly users and that wasn't great for us, but we stumbled across this early community. This was early 2021 when OpenAI created this, created CLIP and people started smushing CLIP and GANs together to produce image generation models. And this started with, you know, it was just a bunch of like tinkerers on Discord, basically. There was an early model called Big Sleep by Advadnoun. And then there was VQGAN Clip, which was like a bit more popular by Rivers Have Wings. And it was all just people like tinkering on stuff in Colabs and it was very dynamic and it was people just making copies of co-labs and playing around with things and forking in. And to me this, I saw this and I was like, oh, this feels like open source software, like so much more than the research world where like people are publishing these papers.Swyx [00:25:48]: You don't know their real names and it's just like a Discord.Ben [00:25:51]: Yeah, exactly. But crucially, it was like people were tinkering and forking and things were moving really fast and it just felt like this creative, dynamic, collaborative community in a way that research wasn't really, like it was still stuck in this kind of six month publication cycle. So we just kind of latched onto that and started building for this community. And you know, a lot of those early models were published on Replicate. I think the first one that was really primarily on Replicate was one called Pixray, which was sort of mid 2021 and it had a really cool like pixel art output, but it also just like produced general, you know, the sort of, they weren't like crisp in images, but they were quite aesthetically pleasing, like some of these early image generation models. And you know, that was like published primarily on Replicate and then a few other models around that were like published on Replicate. And that's where we really started to find our early community and like where we really found like, oh, we've actually built a thing that people want and they were great users as well. And people really want to try out these models. Lots of people were like running the models on Replicate. We still didn't have APIs though, interestingly, and this is like another like really complicated part of the story. We had no idea what a business model was still at this point. I don't think people could even pay for it. You know, it was just like these web forms where people could run the model.Swyx [00:27:06]: Just for historical interest, which discords were they and how did you find them? Was this the Lion Discord? Yeah, Lion. This is Eleuther.Ben [00:27:12]: Eleuther, yeah. It was the Eleuther one. These two, right? There was a channel where Viki Gangklep, this was early 2021, where Viki Gangklep was set up as a Discord bot. I just remember being completely just like captivated by this thing. I was just like playing around with it all afternoon and like the sort of thing. In Discord. Oh s**t, it's 2am. You know, yeah.Swyx [00:27:33]: This is the beginnings of Midjourney.Ben [00:27:34]: Yeah, exactly. And Stability. It was the start of Midjourney. And you know, it's where that kind of user interface came from. Like what's beautiful about the user interface is like you could see what other people are doing. And you could riff off other people's ideas. And it was just so much fun to just like play around with this in like a channel full of a hundred people. And yeah, that just like completely captivated me and I'm like, okay, this is something, you know. So like we should get these things on Replicate. Yeah, that's where that all came from.Swyx [00:28:00]: And then you moved on to, so was it APIs next or was it Stable Diffusion next?Ben [00:28:04]: It was APIs next. And the APIs happened because one of our users, our web form had like an internal API for making the web form work, like with an API that was called from JavaScript. And somebody like reverse engineered that to start generating images with a script. You know, they did like, you know, Web Inspector Coffee is Carl, like figured out what the API request was. And it wasn't secured or anything.Swyx [00:28:28]: Of course not.Ben [00:28:29]: They started generating a bunch of images and like we got tons of traffic and like what's going on? And I think like a sort of usual reaction to that would be like, hey, you're abusing our API and to shut them down. And instead we're like, oh, this is interesting. Like people want to run these models. So we documented the API in a Notion document, like our internal API in a Notion document and like message this person being like, hey, you seem to have found our API. Here's the documentation. That'll be like a thousand bucks a month, please, with a straight form, like we just click some buttons to make. And they were like, sure, that sounds great. So that was our first customer.Swyx [00:29:05]: A thousand bucks a month.Ben [00:29:07]: It was a surprising amount of money. That's not casual. It was on the order of a thousand bucks a month.Swyx [00:29:11]: So was it a business?Ben [00:29:13]: It was the creator of PixRay. Like it was, he generated NFT art. And so he like made a bunch of art with these models and was, you know, selling these NFTs effectively. And I think lots of people in his community were doing similar things. And like he then referred us to other people who were also generating NFTs and he joined us with models. We started our API business. Yeah. Then we like made an official API and actually like added some billing to it. So it wasn't just like a fixed fee.Swyx [00:29:40]: And now people think of you as the host and models API business. Yeah, exactly.Ben [00:29:44]: But that just turned out to be our business, you know, but what ended up being beautiful about this is it was really fulfilling. Like the original goal of what we wanted to do is that we wanted to make this research that people were making accessible to like other people and for it to be used in the real world. And this was like the just like ultimately the right way to do it because all of these people making these generative models could publish them to replicate and they wanted a place to publish it. And software engineers, you know, like myself, like I'm not a machine learning expert, but I want to use this stuff, could just run these models with a single line of code. And we thought, oh, maybe the Docker image is enough, but it's actually super hard to get the Docker image running on a GPU and stuff. So it really needed to be the hosted API for this to work and to make it accessible to software engineers. And we just like wound our way to this. Yeah.Swyx [00:30:30]: Two years to the first paying customer. Yeah, exactly.Alessio [00:30:33]: Did you ever think about becoming Midjourney during that time? You have like so much interest in image generation.Swyx [00:30:38]: I mean, you're doing fine for the record, but, you know, it was right there, you were playing with it.Ben [00:30:46]: I don't think it was our expertise. Like I think our expertise was DevTools rather than like Midjourney is almost like a consumer products, you know? Yeah. So I don't think it was our expertise. It certainly occurred to us. I think at the time we were thinking about like, oh, maybe we could hire some of these people in this community and make great models and stuff like this. But we ended up more being at the tooling. Like I think like before I was saying, like I'm not really a researcher, but I'm more like the tool builder, the behind the scenes. And I think both me and Andreas are like that.Swyx [00:31:09]: I think this is an illustration of the tool builder philosophy. Something where you latch on to in DevTools, which is when you see people behaving weird, it's not their fault, it's yours. And you want to pave the cow paths is what they say, right? Like the unofficial paths that people are making, like make it official and make it easy for them and then maybe charge a bit of money.Alessio [00:31:25]: And now fast forward a couple of years, you have 2 million developers using Replicate. Maybe more. That was the last public number that I found.Ben [00:31:33]: It's 2 million users. Not all those people are developers, but a lot of them are developers, yeah.Alessio [00:31:38]: And then 30,000 paying customers was the number late in space runs on Replicate. So we had a small podcaster and we host a whisper diarization on Replicate. And we're paying. So we're late in space in the 30,000. You raised a $40 million dollars, Series B. I would say that maybe the stable diffusion time, August 22, was like really when the company started to break out. Tell us a bit about that and the community that came out and I know now you're expanding beyond just image generation.Ben [00:32:06]: Yeah, like I think we kind of set ourselves, like we saw there was this really interesting image, generative image world going on. So we kind of, you know, like we're building the tools for that community already, really. And we knew stable diffusion was coming out. We knew it was a really exciting thing, you know, it was the best generative image model so far. I think the thing we underestimated was just like what an inflection point it would be, where it was, I think Simon Willison put it this way, where he said something along the lines of it was a model that was open source and tinkerable and like, you know, it was just good enough and open source and tinkerable such that it just kind of took off in a way that none of the models had before. And like what was really neat about stable diffusion is it was open source so you could like, compared to like Dali, for example, which was like sort of equivalent quality. And like the first week we saw like people making animation models out of it. We saw people make like game texture models that like use circular convolutions to make repeatable textures. We saw, you know, a few weeks later, like people were fine tuning it so you could make, put your face in these models and all of these other-Swyx [00:33:10]: Textual inversion.Ben [00:33:11]: Yep. Yeah, exactly. That happened a bit before that. And all of this sort of innovation was happening all of a sudden. And people were publishing on Replicate because you could just like publish arbitrary models on Replicate. So we had this sort of supply of like interesting stuff being built. But because it was a sufficiently good model, there was also just like a ton of people building with it. They were like, oh, we can build products with this thing. And this was like about the time where people were starting to get really interested in AI. So like tons of product builders wanted to build stuff with it. And we were just like sitting in there in the middle, it's like the interface layer between like all these people who wanted to build and all these like machine learning experts who were building cool models. And that's like really where it took off. We were just sort of incredible supply, incredible demand, and we were just like in the middle. And then, yeah, since then, we've just kind of grown and grown really. And we've been building a lot for like the indie hacker community, these like individual tinkerers, but also startups and a lot of large companies as well who are sort of exploring and building AI things. Then kind of the same thing happened like middle of last year with language models and Lama 2, where the same kind of stable diffusion effect happened with Lama. And Lama 2 was like our biggest week of growth ever because like tons of people wanted to tinker with it and run it. And you know, since then we've just been seeing a ton of growth in language models as well as image models. Yeah. We're just kind of riding a lot of the interest that's going on in AI and all the people building in AI, you know. Yeah.Swyx [00:34:29]: Kudos. Right place, right time. But also, you know, took a while to position for the right place before the wave came. I'm curious if like you have any insights on these different markets. So Peter Levels, notably very loud person, very picky about his tools. I wasn't sure actually if he used you. He does. So you've met him on your Series B blog posts and Danny Post might as well, his competitor all in that wave. What are their needs versus, you know, the more enterprise or B2B type needs? Did you come to a decision point where you're like, okay, you know, how serious are these indie hackers versus like the actual businesses that are bigger and perhaps better customers because they're less churny?Ben [00:35:04]: They're surprisingly similar because I think a lot of people right now want to use and build with AI, but they're not AI experts and they're not infrastructure experts either. So they want to be able to use this stuff without having to like figure out all the internals of the models and, you know, like touch PyTorch and whatever. And they also don't want to be like setting up and booting up servers. And that's the same all the way from like indie hackers just getting started because like obviously you just want to get started as quickly as possible, all the way through to like large companies who want to be able to use this stuff, but don't have like all of the experts on stuff, you know, you know, big companies like Google and so on that do actually have a lot of experts on stuff, but the vast majority of companies don't. And they're all software engineers who want to be able to use this AI stuff, but they just don't know how to use it. And it's like, you really need to be an expert and it takes a long time to like learn the skills to be able to use that. So they're surprisingly similar in that sense. I think it's kind of also unfair of like the indie community, like they're not churning surprisingly, or churny or spiky surprisingly, like they're building real established businesses, which is like, kudos to them, like building these really like large, sustainable businesses, often just as solo developers. And it's kind of remarkable how they can do that actually, and it's in credit to a lot of their like product skills. And you know, we're just like there to help them being like their machine learning team effectively to help them use all of this stuff. A lot of these indie hackers are some of our largest customers, like alongside some of our biggest customers that you would think would be spending a lot more money than them, but yeah.Swyx [00:36:35]: And we should name some of these. So you have them on your landing page, your Buzzfeed, you have Unsplash, Character AI. What do they power? What can you say about their usage?Ben [00:36:43]: Yeah, totally. It's kind of a various things.Swyx [00:36:46]: Well, I mean, I'm naming them because they're on your landing page. So you have logo rights. It's useful for people to, like, I'm not imaginative. I see monkey see monkey do, right? Like if I see someone doing something that I want to do, then I'm like, okay, Replicate's great for that.Ben [00:37:00]: Yeah, yeah, yeah.Swyx [00:37:01]: So that's what I think about case studies on company landing pages is that it's just a way of explaining like, yep, this is something that we are good for. Yeah, totally.Ben [00:37:09]: I mean, it's, these companies are doing things all the way up and down the stack at different levels of sophistication. So like Unsplash, for example, they actually publicly posted this story on Twitter where they're using BLIP to annotate all of the images in their catalog. So you know, they have lots of images in the catalog and they want to create a text description of it so you can search for it. And they're annotating images with, you know, off the shelf, open source model, you know, we have this big library of open source models that you can run. And you know, we've got lots of people are running these open source models off the shelf. And then most of our larger customers are doing more sophisticated stuff. So they're like fine tuning the models, they're running completely custom models on us. A lot of these larger companies are like, using us for a lot of their, you know, inference, but it's like a lot of custom models and them like writing the Python themselves because they've got machine learning experts on the team. And they're using us for like, you know, their inference infrastructure effectively. And so it's like lots of different levels of sophistication where like some people using these off the shelf models. Some people are fine tuning models. So like level, Peter Levels is a great example where a lot of his products are based off like fine tuning, fine tuning image models, for example. And then we've also got like larger customers who are just like using us as infrastructure effectively. So yeah, it's like all things up and down, up and down the stack.Alessio [00:38:29]: Let's talk a bit about COG and the technical layer. So there are a lot of GPU clouds. I think people have different pricing points. And I think everybody tries to offer a different developer experience on top of it, which then lets you charge a premium. Why did you want to create COG?Ben [00:38:46]: You worked at Docker.Alessio [00:38:47]: What were some of the issues with traditional container runtimes? And maybe yeah, what were you surprised with as you built it?Ben [00:38:54]: COG came right from the start, actually, when we were thinking about this, you know, evaluation, the sort of benchmarking system for machine learning researchers, where we wanted researchers to publish their models in a standard format that was guaranteed to keep on running, that you could replicate the results of, like that's where the name came from. And we realized that we needed something like Docker to make that work, you know. And I think it was just like natural from my point of view of like, obviously that should be open source, that we should try and create some kind of open standard here that people can share. Because if more people use this format, then that's great for everyone involved. I think the magic of Docker is not really in the software. It's just like the standard that people have agreed on, like, here are a bunch of keys for a JSON document, basically. And you know, that was the magic of like the metaphor of real containerization as well. It's not the containers that are interesting. It's just like the size and shape of the damn box, you know. And it's a similar thing here, where really we just wanted to get people to agree on like, this is what a machine learning model is. This is how a prediction works. This is what the inputs are, this is what the outputs are. So cog is really just a Docker container that attaches to a CUDA device, if it needs a GPU, that has a open API specification as a label on the Docker image. And the open API specification defines the interface for the machine learning model, like the inputs and outputs effectively, or the params in machine learning terminology. And you know, we just wanted to get people to kind of agree on this thing. And it's like general purpose enough, like we weren't saying like, some of the existing things were like at the graph level, but we really wanted something general purpose enough that you could just put anything inside this and it was like future compatible and it was just like arbitrary software. And you know, it'd be future compatible with like future inference servers and future machine learning model formats and all this kind of stuff. So that was the intent behind it. It just came naturally that we wanted to define this format. And that's been really working for us. Like a bunch of people have been using cog outside of replicates, which is kind of our original intention, like this should be how machine learning is packaged and how people should use it. Like it's common to use cog in situations where like maybe they can't use the SAS service because I don't know, they're in a big company and they're not allowed to use a SAS service, but they can use cog internally still. And like they can download the models from replicates and run them internally in their org, which we've been seeing happen. And that works really well. People who want to build like custom inference pipelines, but don't want to like reinvent the world, they can use cog off the shelf and use it as like a component in their inference pipelines. We've been seeing tons of usage like that and it's just been kind of happening organically. We haven't really been trying, you know, but it's like there if people want it and we've been seeing people use it. So that's great. Yeah. So a lot of it is just sort of philosophical of just like, this is how it should work from my experience at Docker, you know, and there's just a lot of value from like the core being open, I think, and that other people can share it and it's like an integration point. So, you know, if replicate, for example, wanted to work with a testing system, like a CI system or whatever, we can just like interface at the cog level, like that system just needs to put cog models and then you can like test your models on that CI system before they get deployed to replicate. And it's just like a format that everyone, we can get everyone to agree on, you know.Alessio [00:41:55]: What do you think, I guess, Docker got wrong? Because if I look at a Docker Compose and a cog definition, first of all, the cog is kind of like the Dockerfile plus the Compose versus in Docker Compose, you're just exposing the services. And also Docker Compose is very like ports driven versus you have like the actual, you know, predict this is what you have to run.Ben [00:42:16]: Yeah.Alessio [00:42:17]: Any learnings and maybe tips for other people building container based runtimes, like how much should you separate the API services versus the image building or how much you want to build them together?Ben [00:42:29]: I think it was coming from two sides. We were thinking about the design from the point of view of user needs, what are their problems and what problems can we solve for them, but also what the interface should be for a machine learning model. And it was sort of the combination of two things that led us to this design. So the thing I talked about before was a little bit of like the interface around the machine learning model. So we realized that we wanted to be general purpose. We wanted to be at the like JSON, like human readable things rather than the tensor level. So it was like an open API specification that wrapped a Docker container. And that's where that design came from. And it's really just a wrapper around Docker. So we were kind of building on, standing on shoulders there, but Docker is too low level. So it's just like arbitrary software. So we wanted to be able to like have a open API specification that defined the function effectively that is the machine learning model. But also like how that function is written, how that function is run, which is all defined in code and stuff like that. So it's like a bunch of abstraction on top of Docker to make that work. And that's where that design came from. But the core problems we were solving for users was that Docker is really hard to use and productionizing machine learning models is really hard. So on the first part of that, we knew we couldn't use Dockerfiles. Like Dockerfiles are hard enough for software developers to write. I'm saying this with love as somebody who works on Docker and like works on Dockerfiles, but it's really hard to use. And you need to know a bunch about Linux, basically, because you're running a bunch of CLI commands. You need to know a bunch about Linux and best practices and like how apt works and all this kind of stuff. So we're like, OK, we can't get to that level. We need something that machine learning researchers will be able to understand, like people who are used to like Colab notebooks. And what they understand is they're like, I need this version of Python. I need these Python packages. And somebody told me to apt-get install something. You know? If there was sudo in there, I don't really know what that means. So we tried to create a format that was at that level, and that's what cog.yaml is. And we were really kind of trying to imagine like, what is that machine learning researcher going to understand, you know, and trying to build for them. Then the productionizing machine learning models thing is like, OK, how can we package up all of the complexity of like productionizing machine learning models, like picking CUDA versions, like hooking it up to GPUs, writing an inference server, defining a schema, doing batching, all of these just like really gnarly things that everyone does again and again. And just like, you know, provide that as a tool. And that's where that side of it came from. So it's like combining those user needs with, you know, the sort of world need of needing like a common standard for like what a machine learning model is. And that's how we thought about the design. I don't know whether that answers the question.Alessio [00:45:12]: Yeah. So your idea was like, hey, you really want what Docker stands for in terms of standard, but you actually don't want people to do all the work that goes into Docker.Ben [00:45:22]: It needs to be higher level, you know?Swyx [00:45:25]: So I want to, for the listener, you're not the only standard that is out there. As with any standard, there must be 14 of them. You are surprisingly friendly with Olama, who is your former colleagues from Docker, who came out with the model file. Mozilla came out with the Lama file. And then I don't know if this is in the same category even, but I'm just going to throw it in there. Like Hugging Face has the transformers and diffusers library, which is a way of disseminating models that obviously people use. How would you compare your contrast, your approach of Cog versus all these?Ben [00:45:53]: It's kind of complementary, actually, which is kind of neat in that a lot of transformers, for example, is lower level than Cog. So it's a Python library effectively, but you still need to like...Swyx [00:46:04]: Expose them.Ben [00:46:05]: Yeah. You still need to turn that into an inference server. You still need to like install the Python packages and that kind of thing. So lots of replicate models are transformers models and diffusers models inside Cog, you know? So that's like the level that that sits. So it's very complementary in some sense. We're kind of working on integration with Hugging Face such that you can deploy models from Hugging Face into Cog models and stuff like that to replicate. And some of these things like Llamafile and what Llama are working on are also very complementary in that they're doing a lot of the sort of running these things locally on laptops, which is not a thing that works very well with Cog. Like Cog is really designed around servers and attaching to CUDA devices and NVIDIA GPUs and this kind of thing. So we're actually like, you know, figuring out ways that like we can, those things can be interoperable because, you know, they should be and they are quite complementary and that you should be able to like take a model and replicate and run it on your local machine. You should be able to take a model, you know, the machine and run it in the cloud.Swyx [00:47:02]: Is the base layer something like, is it at the like the GGUF level, which by the way, I need to get a primer on like the different formats that have emerged, or is it at the star dot file level, which is model file, Llamafile, whatever, whatever, or is it at the Cog level? I don't know, to be honest.Ben [00:47:16]: And I think this is something we still have to figure out. There's a lot yet, like exactly where those lines are drawn. Don't know exactly. I think this is something we're trying to figure out ourselves, but I think there's certainly a lot of promise about these systems interoperating. We just want things to work together. You know, we want to try and reduce the number of standards. So the more, the more these things can interoperate and, you know

We're back! Jason Hall joins the show to tell Justin & Autumn all about how Chainguard builds hundreds of containers without a single Dockerfile.

I break down why Dockerfile frontends exist and how Docker's build engine "BuildKit" is giving us updated Dockerfile features.The TL;DR of this podcast is to add this to your Dockerfiles as the first line, always and forever.# syntax=docker/dockerfile:1It'll ensure your Dockerfile will have access to the latest v1.x features of the "Dockerfile frontend" feature of BuildKit.★Topics★My newsletter on Dockerfile frontends (including links and references)Creators & Guests Beth Fisher - Producer Bret Fisher - Host (00:00) - (00:36) - Understanding Docker Files (00:47) - The Evolution of Docker Files (01:05) - The Importance of Docker File Versions (02:20) - The Impact of Dockerfile Standards (03:41) - The Benefits of Using the Latest Dockerf ile Parser (04:16) - The Challenges of Docker Engine Versions (05:18) - The Advantages of Docker Front Ends (07:56) - The Role of OCI in Dockerfiles (10:18) - Exploring New Features in Docker File Front Ends (15:27) - Conclusion: The Future of Docker Files You can also support my free material by subscribing to my YouTube channel and my weekly newsletter at bret.news!Grab the best coupons for my Docker and Kubernetes courses.Join my cloud native DevOps community on Discord.Grab some merch at Bret's Loot BoxHomepage bretfisher.com

It's been a long time (again) between recording/discussions, but finally, for the end of the year, we locked some time to record. Java 9 Outdated Ideas About Java - Azul | Better Java Performance, Superior Java Support Hidden gems in Java 19, Part 1: The not-so-hidden JEPs JDK 20: The new features in Java 20 | InfoWorld JDK 21: The new features in Java 21 | InfoWorld Java 21 to drop generational Shenandoah GC Why Your Choice of Java Virtual Machine (JVM) Matters More Than Ever - Azul | Better Java Performance, Superior Java Support JDK 22: The new features in Java 22 | InfoWorld The Java Playground - Dev.java JEP draft: Null-Restricted Value Class Types (Preview) JEP draft: No longer require super() and this() to appear first in a constructor Minborg's Java Pot: Java 20: Colossal Sparse Memory Segments Golang What's New in Go 1.21 a Comprehensive Notes | by Younis Jad | Lyonas | Medium Go 1.20 Release Notes - The Go Programming Language [Go 1.21 Release Notes - The Go Programming Language](https://tip.golang.org/doc/go1.21 Go 1.22 Release Notes - The Go Programming Language (soon to be released) Misc GitHub - MichaelMure/git-bug: Distributed, offline-first bug tracker embedded in git, with bridges So you want to write a package manager | by sam boyer | Medium Versioning non-project repositories (config, pipelines) Semverbot looks good, but I found a bug: blang/semver only supports "v" prefix's · Issue #58 · restechnica/semverbot · GitHub DORA - Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog Software Design and Maintainability On bad advice Why DevOps is failing: It's Not You, It's The Tools - GigaOm An architect's journal -Embracing Simplicity in Software Architecture Diagramming | by Asanka Abeysinghe | architect2architect Building Great Teams dagger.io | Replacing your Dockerfile with Go code Replace a Dockerfile with Go | Dagger Dagger Java SDK examples: sample Healing The Poisoned Repository | Theory In Practice

2023-11-21 Weekly News — Episode 207Watch the video version on YouTube at https://youtube.com/live/1aeDZ7q5Y2E?feature=share Hosts: Eric Peterson - Senior Developer at Ortus Solutions Daniel Garcia - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: Buy Tickets to Into the Box 2024 in Washington DC https://www.intothebox.org/ Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review AND WE WILL READ IT ON THE SHOW Sign up for a free or paid account on CFCasts, which is releasing new content regularly BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Books 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Now on Amazon! https://www.amazon.com/dp/B0CJHB712M Learn Modern ColdFusion (CFML) in 100+ Minutes - Free online https://modern-cfml.ortusbooks.com/ or buy an EBook or Paper copy https://www.ortussolutions.com/learn/books/coldfusion-in-100-minutes   Patreon Support (flabbergasting)We have 42 patreons: https://www.patreon.com/ortussolutions. News and AnnouncementsNCC Group - Technical Advisory: Adobe ColdFusion WDDX Deserialization GadgetsAdobe ColdFusion allows software developers to rapidly build web applications. Recently, a critical vulnerability was identified in the handling of Web Distributed Data eXchange (WDDX) requests to ColdFusion Markup (CFM) endpoints. Multiple patches were released by Adobe to resolve the vulnerability, and each has been given its own CVE and Adobe security update.https://research.nccgroup.com/2023/11/21/technical-advisory-adobe-coldfusion-wddx-deserialization-gadgets/ Ortus End of the Year Sale is Finally Here!The much-anticipated Ortus End-of-the-Year Sale has arrived, and it's time to elevate your development experience! Whether you're a seasoned developer, a tech enthusiast, or someone on the lookout for top-notch projects, Ortus has something special in store for you. Brace yourself for incredible discounts across a wide array of products and services, including Ortus annual events, books, cutting-edge services, and more.https://www.ortussolutions.com/blog/ortus-deals-are-finally-here New Releases and UpdatesAdobe November Updates - Security FixesAdobe for ColdFusion 2023 (update 6) and 2021 (update 12)Previous versions no longer receive security updates!!!CommandBox has already been updatedSecurity updates available for Adobe ColdFusion | APSB23-52 - https://helpx.adobe.com/security/products/coldfusion/apsb23-52.html https://community.adobe.com/t5/coldfusion-discussions/now-live-adobe-coldfusion-2023-and-2021-november-security-updates/m-p/14233917#M196421 Note: Reported WDDX related issues by some customersMore details from Charlie Arehart: https://www.carehart.org/blog/2023/11/14/cf_security_updates_nov_2023#more ICYMI - 10/23/2023- Added Java installers for Java 17.0.9, Java 11.0.21 & JDK/JRE 8u39110/10/2023- Refreshed the Server ZIP and GUI installers, Lockdown installer, and Add-on installer for ColdFusion (2023 release).https://helpx.adobe.com/coldfusion/kb/coldfusion-downloads.html#download0Avoid issues with Update thanks for Brian for this post: https://www.hoyahaxa.com/2023/10/coldfusion-connectors-and-cfadmin.html The new connectors in ColdFusion 2023 Update 5 and ColdFusion 2021 Update 11 perform the following actions: normalize the request URI block any requests with .. in the URI path (which could be attempts to exploit directory traversal vulnerabilities) block any requests in which the normalized URI path starts with a case-insensitive /CFIDE  ColdBox 7.2.0 ReleasedWelcome to ColdBox 7.2.0, which packs a big punch on stability and tons of new features.Includes lots of updates for all the core products: ColdBox, WireBox, CacheBox, and LogBox.ColdBox, 10 new features, 6 improvements and 4 bug fixesLogBox has 3 new features, 4 improvements, 2 bug fixes and a taskWith WireBox including a new feature and CacheBox has an Improvement.https://coldbox.ortusbooks.com/readme/release-history/whats-new-with-7.2.0 Webinar / Meetups and WorkshopsICYMI - MMCFUG - How to containerize CFML apps for the cloud with Nick Kwiatkowski from Michigan StateNovember 13th, 2023Nick Kwiatkowski from MSU Telecom is going to show us how to containerize CFML apps for the cloud at the next meeting of the Mid-Michigan tonight at 7 pm eastern time. Docker, Tanzu, Kubernetes and more.https://youtu.be/fYQ-BBKir7Q Hawaii ColdFusion Meetup Group - InertiaJS and ColdFusion with Eric PetersonNovember 24thInertiaJS is a new JavaScript framework made for people who don't really need an API but want to use a modern JavaScript framework like React or Vue as their view layer. Inspired by libraries like Turbolinks, InteriaJS makes your app behave like a SPA while still being a fully sever-rendered app.https://www.meetup.com/hawaii-coldfusion-meetup-group/events/294771761/ ColdFusion Security TrainingWriting Secure CFML with Pete FreitagA hands-on CFML / ColdFusion Security Training class for developers. Learn how to identify and fix security vulnerabilities in your ColdFusion / CFML applications.Where: OnlineWhen: Tuesday December 12, 2023 @ 11am-2pmEST & Wednesday December 13 @ 11am-2pmPrice: $899 per studenthttps://foundeo.com/consulting/coldfusion/security-training/ The class will be recorded, so if you cannot attend it fully online you will have access to a recording.CFCasts Content Updateshttps://www.cfcasts.comRecent ReleasesInto the Box 2023 Videos are now available for all Paid Subscriptions https://cfcasts.com/series/itb-2023 Coming Soon Mastering CBWIRE v3 from Grant ColdBox Elixir from Eric On hold for a bit Conferences and TrainingInto the Box LATAMNovember 30thUniversity of Business in El Salvador.https://latam.intothebox.org/Speakers and Schedules availableAdobe ColdFusion India Summit 2023December 2nd, 2023Register for FreeLocation: Bengaluru, Indiahttps://cf-indiasummit-2023.attendease.com/ ITB 2024 Location: Optica in Washington, DC Announcement Blog Post: https://www.ortussolutions.com/blog/our-into-the-box-2024-venue-and-dates-are-set Dates: May 15-17, 2024 Get Blind Tickets Now: https://www.eventbrite.com/e/into-the-box-2024-the-new-era-of-modernization-tickets-663126347757 Call for Speakers: https://www.ortussolutions.com/blog/call-for-speakers-into-the-box-2024-share-your-expertise More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/Blogs, Tweets, and Videos of the Week11/20/23 - Blog - Julian Halliwell - Reading Large CSV Files with CFMLAs its name suggests, the Spreadsheet CFML library is focused on working with spreadsheets, in either binary or XML format.But there's a third format which is often used for the same kind of data: CSV.For a while now, the library has provided a few convenience methods for working with CSV which allow conversion to and from spreadsheets and CFML queries.I'll admit though that these methods don't perform very well when dealing with large CSV files. For various reasons, the reliance on CFML query objects means that large amounts of CSV require large amounts of memory.https://blog.simplicityweb.co.uk/138/reading-large-csv-files-with-cfml 11/15/23 - Blog - Brian Reilly - Critical Variable Mass Assignment Vulnerability in Adobe ColdFusion (CVE-2023-44350)Adobe ColdFusion is vulnerable to a Mass Assignment vulnerability that can result in an attacker being able to modify the value of any variable in any scope within the context of remote CFC methods.  A mass assignment vulnerability occurs when application code allows a user to set or modify arbitrary objects or values without verifying that the user is authorized to do so.  Modifying values related to authorization checks, security controls, or other important functions may permit a malicious user to access sensitive data or perform other unexpected actions.  Mass assignment vulnerabilities are not unique to ColdFusion and have affected other languages including ASP.NET, PHP, and Ruby on Rails. https://www.hoyahaxa.com/2023/11/critical-variable-mass-assignment.html 11/15/23 - Tweet - Brad Wood - I found a CommandBox Cheat SheetCame across this cool CommandBox cheat sheet by @djgarcia76 today:https://cheatography.com/garciadev/cheat-sheets/commandbox/ #ColdFusion #CFML #CLIhttps://x.com/bdw429s/status/1724863039281807808?s=20 11/13/23 - Blog - Nolan Erck - ColdFusion Summit 2023 RecapA few weeks ago was the annual ColdFusion Summit in Las Vegas. And as expected, the event was very worth the trip! Overall I think everything ran very smoothly — food, sessions, staff, the party, and all the other things you'd expect at CF Summit were the same quality as previous years.https://southofshasta.com/blog/coldfusion-summit-2023-recap/CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 108 ColdFusion positions from 65 companies across 45 locations in 5 Countries.1 new jobs listed in the last few weeksFull-Time - Sr. Software Engineer - Coldfusion Developer at Delhi, Delhi.. - India Posted Nov 15https://www.getcfmljobs.com/jobs/index.cfm/india/Sr-Software-Engineer-Coldfusion-Developer-at-Delhi-Delhi/11620 Other Job LinksThere is a jobs channel in the CFML slack team, and in the Box team slack now tooForgeBox Module of the WeekLogBox Logging LibraryVersion 7.2.0 just released - 4,501 installs in the last 12 monthsLogBox is an enterprise ColdFusion (CFML) logging library designed to give you flexibility, simplicity, and power when logging or tracing is needed in your applications. LogBox is also part of the ColdBox Platform suite of services and libraries. It allows you to easily build upon it's logging framework to meet any logging or reporting needs your applications have. LogBox surpasses ColdFusion's very basic cflog tag. LogBox allows you to create multiple destinations for your loggings and even configure multiple destinations or change them at runtime.Almost every application needs logging and/or tracing capabilities, and we have developed LogBox to satisfy these needs. Although you should not over-use logging as it can slow down an application, LogBox allows you to filter out or cancel logging noise.Great integrations available on ForgeBox like Sentry etchttps://logbox.ortusbooks.com/https://www.forgebox.io/view/logbox VS Code Hint Tips and Tricks of the Week11/23/23 Docker - v1.28.0Lots of updates since we last covered this extension in 2019!!!!The Docker extension makes it easy to build, manage, and deploy containerized applications from Visual Studio Code. It also provides one-click debugging of Node.js, Python, and .NET inside a container. You can get IntelliSense when editing your Dockerfile and docker-compose.yml files, with completions and syntax help for common commands. Docker Compose lets you define and run multi-container applications with Docker. Our Compose Language Service in the Docker extension gives you IntelliSense and tab completions when authoring docker-compose.yml files. Press Ctrl+Space to see a list of valid Compose directives. The Docker extension contributes a Docker Explorer view to VS Code. The Docker Explorer lets you examine and manage Docker assets: containers, images, volumes, networks, and container registries. If the Azure Account extension is installed, you can browse your Azure Container Registries as well. The right-click menu provides access to commonly used commands for each type of asset. You can run Docker commands to manage images, networks, volumes, image registries, and Docker Compose. In addition, the Docker: Prune System command will remove stopped containers, dangling images, and unused networks and volumes. https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker Thank you to all of our Patreon SupportersThese individuals are personally supporting our open source initiatives to ensure the great toolings like CommandBox, ForgeBox, ColdBox,  ContentBox, TestBox and all the other boxes keep getting the continuous development they need, and funds the cloud infrastructure at our community relies on like ForgeBox for our Package Management with CommandBox. You can support us on Patreon here https://www.patreon.com/ortussolutionsDon't forget, we have Annual Memberships, pay for the year and save 10% - great for businesses everyone. Bronze Packages and up, now get a ForgeBox Pro and CFCasts subscriptions as a perk for their Patreon Subscription. All Patreon supporters have a Profile badge on the Community Website All Patreon supporters have their own Private Forum access on the Community Website All Patreon supporters have their own Private Channel access BoxTeam Slack https://community.ortussolutions.com/Top Patreons (flabbergasting) John Wilson - Synaptrix Tomorrows Guides Jordan Clark Gary Knight Giancarlo Gomez David Belanger  Dan Card James Moberg & Jeffry McGee - Sunstar Media  Dean Maunder Kevin Wright Doug Cain  Nolan Erck  Abdul Raheen And many more PatreonsYou can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors Don't forget the ORTUS DEALS when you are hunting Black Friday and Cyber Monday DealsThanks and Happy Thanksgiving everyone!!! ★ Support this podcast on Patreon ★

When should you start caring about data security? Today. Evervault's mission is to encrypt the web. Hear from Shane Curran, CEO of Evervault, on why he's dedicating his career to making encryption incredibly easy for all software developers. In this episode, Shane introduces Evervault's newest product, Cages. Built on AWS Nitro enclaves, Cages are the easiest way to build, deploy and scale Secure Enclaves, allowing you to go from a Dockerfile to a trusted execution environment in less than 15 minutes. AWS Nitro Enclaves: https://go.aws/3J9S6zx Cages - Secure Enclaves: https://bit.ly/3mIP8e0 AWS Podcast Audio Feedback: https://bit.ly/3mDc3Y1

In deze aflevering bespreken Jan en Ronald wat een Docker file is en hoe je hiermee een container kunt maken.  Daarnaast gaan ze in op de functionaliteiten van Ingress NGINX en cert-manager. Commando's:kubectl ingress-nginx conf - laat de config zien. kubectl ingress-nginx lint - contoleert alle config in het clusterkubectl ingress-nginx logs - laat alle logging zien. Handige links:https://docs.docker.com/engine/reference/builder/https://docs.docker.com/develop/develop-images/dockerfile_best-practices/https://kubernetes.io/docs/concepts/services-networking/ingress/https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/https://kubernetes.github.io/ingress-nginx/https://kubernetes.github.io/ingress-nginx/kubectl-plugin/https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.mdhttps://cert-manager.io/

Victor is a software consultant in Tokyo who describes himself as a yak shaver. He writes on his blog at vadosware and curates Awesome F/OSS, a mailing list of open source products. He's also a contributor to the Open Core Ventures blog. Before our conversation Victor wrote a structured summary of how he works on projects. I recommend checking that out in addition to the episode. Topics covered: Most people should use Dokku or CapRover But he uses Kubernetes anyways Hosting a Database in Kubernetes Learning technology You don't really know a thing until something goes wrong History of Frontend Development Context from lower layers of the stack and historical projects Good project pages have comparisons to other products Choosing technologies Language choice affects maintainability Knowing an ecosystem Victor's preferred stack Technology bake offs Posting findings means you get free corrections Why people use medium instead of personal sites Victor VADOSWARE - Blog How Victor works on Projects - Companion post for this episode Awesome FOSS - Curated list of OSS projects NimbusWS - Hosted OSS built on top of budget cloud providers Unvalidated Ideas - Startup ideas for side project inspiration PodcastSaver - Podcast index that allows you to choose Postgres or MeiliSearch and compare performance and results of each Victor's preferred stack Docker - Containers Kubernetes - Container provisioning (Though at the beginning of the episode he suggests Dokku for single server or CapRover for multiple) TypeScript - JavaScript with syntax for types. Victor's default choice. Rust - Language he uses if doing embedded work, performance is critical, or more correctness is desired Haskell - Language he uses if correctness and type system is the most important for the project Postgresql - General purpose database that's good enough for most use cases including full text search. KeyDB - Redis compatible database for caching. Acquired by Snap and then made open source. Victor uses it over Redis because it is multi threaded and supports flash storage without a Redis Enterprise license. Pulumi - Provision infrastructure with the languages you're already using instead of a specialized one or YAML Svelte and SvelteKit - Preferred frontend stack. Previously used Nuxt. Search engines Postgres Full Text Search vs the rest Optimizing Postgres Text Search with Trigrams OpenSearch - Amazon's fork of Elasticsearch typesense meilisearch sonic Quickwit JavaScript build tools Babel SWC Webpack esbuild parcel Vite Turbopack JavaScript frameworks React Vue Svelte Ember Frameworks built on top of frameworks Next - React Nuxt - Vue SvelteKit - Svelte Astro - Multiple Historical JavaScript tools and frameworks Underscore jQuery MooTools Backbone AngularJS Knockout Aurelia GWT Bower - Frontend package manager Grunt - Task runner Gulp - Task runner Related Links Dokku - Open source single-host alternative to Heroku Cloud Native Buildpacks - Buildpacks created by Heroku and Pivotal and used by Dokku CapRover - An open source PaaS-like abstraction built on top of Docker Swarm Kelsey Hightower's tweet about being cautious about running databases on Kubernetes Settling the Myth of Transparent HugePages for Databases Kubernetes Container Storage Interface (CSI) Kubernetes Local Persistent Volumes Longhorn - Distributed block storage for Kubernetes Postgres docs Postgres TOAST Everything I've seen on optimizing Postgres on ZFS Kubernetes Workload Resources Kubernetes Network Plugins Kubernetes Ingress Traefik Kubernetes the Hard Way (Setting up a cluster in a way that optimizes for learning) How does TLS work Let's Encrypt Cert manager for Kubernetes Choose Boring Technology A Linux user's guide to Logical Volume Management Docker networking overview Kubernetes Scheduler Tauri - Build desktop applications with web technology and Rust ripgrep - CLI tool to recursively search directory for a regex pattern (Meant to be a rust replacement for grep) angle-grinder / ag - CLI tool to parse and process log files written in rust Object.observe ECMAScript Proposal to be Withdrawn Ruby on Rails - Ruby web framework Django - Python web framework Laravel - PHP web framework Adonis - JavaScript NestJS - JavaScript What is a NullPointerException, and how do I fix it? Mastodon Clap - CLI argument parser for Rust AWS CDK - Provision AWS infrastructure using programming languages Terraform - Provision infrastructure with terraform language URL canonicalization of duplicate pages and the use of the canonical tag - Used by dev.to to send google traffic to the original blogpost instead of dev.to Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: This episode, I talk to Victor Adossi who describes himself as a yak shaver. Someone who likes trying a whole bunch of different technologies, seeing the different options. We talk about what he uses, the evolution of front end development, and his various projects. Talking to just different people it's always good to get where they're coming from because something that works for Google at their scale is going to be different than what you're doing with one of your smaller projects. [00:00:31] Victor: Yeah, the context. Of course in direct conflict with that statement, I definitely use Google technology despite not needing to at all right? Like, you know, 99% of people who are doing like people like to call it indiehacking or building small products could probably get by with just Dokku. If you know Dokku or like CapRover. Are two projects that'll be like, Oh, you can just push your code here, we'll build it up like a little mini Heroku PaaS thing and just go on one big server, right? Like 99% of the people could just use that. But of course I'm not doing that. So I'm a bit of a hypocrite in that sense. I know what I should be doing, but I'm not doing that. I am writing a Kubernetes cluster with like five nodes for no reason. Uh, yeah, I dunno, people don't normally count the controllers. [00:01:24] Jeremy: Dokku and CapRover, I think those are where it's supposed to create a heroku like experience I think it's based off of the heroku buildpacks right? At least Dokku is? [00:01:36] Victor: Yeah Buildpacks has actually been spun out into like a community thing so like pivotal and heroku, it's like buildpacks.io, they're trying to build a wider standard around it so that more people can get involved. And buildpacks are actually obviously fantastic as a technology and as a a process piece. There's not much else like them and you know, that's obvious from like Heroku's success and everything. I know Dokku uses that. I don't know that Caprover does, but I haven't, I haven't really run Caprover that much. They, they probably do. Like at this point if you're going to support building from code, it seems silly to try and build your own buildpacks. Cause that's what you will do, eventually. So you might as well use what's there. Anyway, this is like just getting to like my personal opinions at this point, but like, if you think containers are a bad idea in 2022, You're wrong, you should, you should stop. Like you should, you should stop. Think about it. I mean, obviously there's not, um, I got a really great question at an interview once, which is, where are containers a bad idea? That's probably one of the best like recent interview questions I've ever gotten cause I was like, Oh yeah, I mean, like, you can't, it can't be perfect everywhere, right? Nothing's perfect everywhere. So it's like, where is it? Uh, and of course the answer was networking, right? (unintelligible) So if you need absolute performance, but like for just about everything else. Containers are kind of it at this point. Like, time has born it out, I think. So yeah, I always just like bias at taking containers at this point. So I'm probably more of a CapRover person than a Dokku person, even though I have not used, I don't use CapRover. [00:03:09] Jeremy: Well, like something that I've heard with containers, and maybe it's changed recently, but, but something that was kind of holdout was when people would host a database sometimes they would oh we just don't wanna put this in a container and I wonder if like that matches with your thinking or if things have changed. [00:03:27] Victor: I am not a database administrator right like I read postgres docs and I read the, uh, the Postgres documentation, and I think I know a bit about postgres but I don't commit right like so and I also haven't, like, oh, managed X terabytes on one server that you are making sure never goes down kind of deal. But the stickiness for me, at least from when I've run, So I've done a lot of tests with like ZFS and Postgres and like, um, and also like just trying to figure out, and I run Postgres in Kubernetes of course, like on my cluster and a lot of the stuff I found around is, is like fiddly kernel things like sort of base kernel settings that you need to have set. Like, you know, stuff like should you be using transparent huge pages, like stuff like that. But once you have that settled. Containers are just processes with name spacing and resource control, right? Like, that's it. there are some other ins and outs, but for the most part, if you're fine running a process, so people ran processes, right? And they were just completely like unprotected. Then people made users for the processes and they limited the users and ran the processes, right? Then the next step is now you can run a process and then do the limiting the name spaces in cgroups dynamically. Like there, there's, there's sort of not a humongous difference, unless you're hitting something very specific. Uh, but yeah, databases have been a point of contention, but I think, Kelsey Hightower had that tweet yeah. That was like, um, don't run databases in Kubernetes. And I think he called it back. [00:04:56] Victor: I don't know, but I, I know that was uh, was one of those things that people were really unsure about at first, but then after people sort of like felt it out, they were like, Oh, it's actually fine. Yeah. [00:05:06] Jeremy: Yeah I vaguely remember one of the concerns having to do with persistent storage. Like there were challenges with Kubernetes and needing to keep that storage around and I don't know if that's changed yeah or if that's still a concern. [00:05:18] Victor: Uh, I'd say that definitely has changed. Uh, and it was, it was a concern, depending on where you were. Mostly people who are running AKS or EKS or you know, all those other managed Kubernetes, they're just using EBS or like whatever storage provider is like offering for storage. Most of those people don't actually have that much of a problem with, storage in general. Now, high performance storage is obviously different, right? So like, so you'll, you're gonna have to start doing manual, like local volume management and stuff like that. it was a problem, because obviously CSI (Kubernetes Container Storage Interface) didn't exist for some period of time, and like there was, it was hard to know what to do for if you were just running a Kubernetes cluster. I think a lot of people were just using local, first of all, local didn't even exist for a bit. Um, they were just using host path, right? And just like, Oh, it's on the disk somewhere. Where do we, we have to go get it right? Or we have to like, sort of manage that. So that was something most people weren't ready for, especially if you were just, if you weren't like sort of a, a, a traditional sysadmin and used to doing that stuff. And then of course local volumes came out, but I think they still had to be, um, pre-provisioned. So that's sysadmin stuff that most people, you know, maybe aren't, aren't necessarily ready for. Uh, and then most of the general solutions were slow. So like, I used Longhorn (https://longhorn.io) for a long time and Longhorn, Longhorn's great. And super easy to set up, but it can be slower and you can have some, like, delays in mount time. it wasn't ideal for, for most people. So yeah, I, overall it's true. Databases, Databases in Kubernetes were kind of fraught with peril for a while, but it wasn't for the reason that, it wasn't for the fundamental reason that Kubernetes was just wrong or like, it wasn't the reason most people think of, which is just like, Oh, you're gonna break your database. It's more like, running a database is hard and Kubernetes hasn't solved all the hard problems. Like, cuz that's what Kubernetes does. It basically solves a lot of problems in a very generic way. Right. So it just hadn't solved all those problems yet at this point. I think it's got decent answers on a lot of them. So I, I mean, I don't know. I I do it. Don't, don't take what I'm saying to your, you know, PM meeting or your standup meeting, uh, anyone who's listening. But it's more like if you could solve the problems with databases in the sense before. You could probably solve 'em on Kubernetes now with a good understanding of Kubernetes. Cause at the end of the day, it's all the same stuff. Just Kubernetes makes it a little easier to, uh, do it dynamically. [00:07:50] Jeremy: It sounds like you could do it before, but some of the, I guess the tools or the ways of doing persistent storage were not quite there yet, or they were difficult to use. And so that was why people at the start were like, Okay, maybe it's not a good idea, but, now maybe there's some established practices for how you should run a database in Kubernetes. And I, I suppose the other aspect too is that, like you were saying, Kubernetes is its own thing. You gotta learn Kubernetes and all its intricacies. And then running a database is also its own challenge. So if you stack the two of them together and, and the path was not really clear then maybe at the start it wasn't the best idea. Um, uh, if somebody was going to try it out now, was there like a specific resource you looked at or a specific path to where like okay this is is how I'm going to do it. [00:08:55] Victor: I'll just say what I normally recommend to everybody. Cause it depends on which path you wanna go right? If you wanna go down like running a database path first and figure that out, fill out that skill tree. Like go read the Postgres docs. Well, first of all, use Postgres. That's the first tip there. But like, read those documents. And obviously you don't have to understand everything. You won't understand everything. But knowing the big pieces and sort of letting your brain see the mention of like a whole bunch of things, like what is toast? Oh, you can do compression on columns. Like, you can do some, some things concurrently. Um, you know, what ALTER TABLE looks like. You get all that stuff kind of in your head. Um, and then I personally really believe in sort of learning by building and just like iterating. you won't get it right the first time. It's just like, it's not gonna happen. You're get, you can, you can get better the first time, right? By being really prepared and like, and leave yourself lots of outs, but you kind of have to like, get it out there. Do do your best to make sure that you can't fail, uh, catastrophically, right? So this is like, goes back to that decision to like use ZFS as the bottom of this I'm just like, All right, well, I, I'm not a file systems expert, but if I. I could delegate some of that, you know, some of that, I can get some of that knowledge from someone else. Um, and I can make it easier for me to not fail catastrophically. For the database side, actually read documentation on Postgres or the whatever database you're going to use, make sure you at least understand that. Then start running it like locally or whatever. Again, Docker use, use Docker locally. It's, it's, it's fine. and then, you know, sort of graduate to running sort of more progressively, more complicated versions. what I would say for the Kubernetes side is actually similar. the Kubernetes docs are really good. they're very large. but they're good. So you can actually go through and know all the, like, workload, workload resources, know, like what a config map is, what a secret is, right? Like what etcd is doing in this whole situation. you know, what a kublet is versus an API server, right? Like the, the general stuff, like if you go through all that, you should have like a whole bunch of ideas at least floating around in your head. And then once you try and start setting up a server, they will all start to pop up again, right? And they'll all start to like, you, like, Oh, okay, I need a CNI (Container Networking) plugin because something needs to make the services available, right? Or something needs to power the ingress, right? Like, if I wanna be able to get traffic, I need an ingress object. But what listens, what does that, what makes that ingress object do anything? Oh, it's an ingress controller. nginx, you know, almost everyone's heard of nginx, so they're like, okay. Um, nginx, has an ingress control. Actually there's, there used to be two, I assume there's still two, but there's like one that's maintained by Kubernetes, one that's maintained by nginx, the company or whatever. I use traefik, it's fantastic. but yeah, so I think those things kind of fall out and that is almost always my first way to explain it and to start building. And tinkering iteratively. So like, read the documentation, get a good first grasp of it, and then start building yourself because you'll, you'll get way more questions that way. Like, you'll ask way more questions, you won't be able to make progress. Uh, and then of course you can, you know, hop into slacks or like start looking around and, and searching on the internet. oh, one of the things that really helped me out early learning Kubernetes was, Kelsey Hightower's, um, learn Kubernetes the hard way. I'm also a big believer in doing things the hard way, at least knowing what you're choosing to not know, right? distributing file system, Deltas, right? Or like changes to a file system over the network is not a new problem. Other people have solved it. There's a lot of complexity there. but if you at least know the sort of surface level of what the thing does and what it's supposed to do and how it's supposed to do it, you can make a decision on, Oh, how deep am I going to go? Right? To prevent yourself from like, making a mistake or going too deep in the rabbit hole. If you have an idea of the sort of ecosystem and especially like, Oh, here, like the basics of how I can use this thing, that's generally very good. And doing things the hard way is a great way to get a, a feel for that, right? Cause if you take some chunk and like, you know, the first level of doing things the hard way, uh, or, you know, Kelsey Hightower's guide is like, get a machine, right? Like, so, like, if you somehow were like, Oh, I wanna run a Kubernetes cluster. but, you know, I don't want use necessarily EKS and you wanna learn it the hard way. You have to go get a machine, right? If you, if you're not familiar, if you run on Heroku the whole time, like you didn't manage your own machines, you gotta go like, figure out EC2, right? Or, I personally use, hetzner I love hetzner, so you have to go figure out hetzner, digital ocean, whatever. Right. And then the next thing's like, you know, the guide's changed a lot, and I haven't, I haven't looked at it in like, in years, actually a while since I, since I've sort of been, I guess living it, but it's, it's like generate certificates, right? So if you've never dealt with SSL and like, sort of like, or I should say TLS uh, and generating certificates and how that whole dance works, right? Which is fascinating because it's like, oh, right, nothing's secure on the internet, except that we distribute root certificates on computers that are deployed in every OS, right? Like, that's a sort of fundamental understanding you may not go deep enough to realize, but if you are fascinated by it, trying to do it manually would lead you down that path. You'd be like, Oh, what, like what is this thing? What is a CSR? Like, why, who is signing my request? Right? And it's like, why do we trust those people? Right? And it's like, you know, that kind of thing comes out and I feel like you can only get there from trying to do it, you know, answering the questions you can. Right. And again, it takes some judgment to know when you should not go down a rabbit hole. uh, and then iterating. of course there are people who are excellent at explaining. you can find some resources that are shortcuts. But, uh, I think particularly my bread and butter has been just to try and do it the hard way. Avoid pitfalls or like rabbit holes when you can. But know that the rabbit hole is there, and then keep going. And sometimes if something's just too hard, you're not gonna get it the first time. Like maybe you'll have to wait like another three months, you'll try again and you'll know more sort of ambiently about everything else. You get a little further that time. that's how I feel about that. Anyway. [00:15:06] Jeremy: That makes sense to me. I think sometimes when people take on a project, they try to learn too many things at the same time. I, I think the example of Kubernetes and Postgres is pretty good example, where if you're not familiar with how do I install Postgres on bare metal or a vm, trying to make sense of that while you're trying to into is probably gonna be pretty difficult. So, so splitting them up and learning them individually, that makes a lot of sense to me. And the whole deciding how deep you wanna go. That's interesting too, because I think that's very specific to the person right because sometimes you wanna go a little deeper because otherwise you don't understand how the two things connect together. But other times it's just like with the example with certificates, some people they may go like, I just put in let's encrypt it gives me my cert I don't care right then, and then, and some people they wanna know like okay how does the whole certificate infrastructure work which I think is interesting, depending on who you are, maybe you go ahh maybe it doesn't really matter right. [00:16:23] Victor: Yeah, and, you know, shout out to Let's Encrypt . It's, it's amazing, right? think Singlehandedly the most, most of the deployment of HTTPS that happens these days, right? so many so many of like internet providers and uh, sort of service providers will use it right? Under the covers. Like, Hey, we've got you free SSL through Let's Encrypt, right? Like, kind of like under the, under the covers. which is awesome. And they, and they do it. So if you're listening to this, donate to them. I've done it. So now that, now the pressure is on whoever's listening, but yeah, and, and I, I wanna say I am that person as well, right? Like, I use, Cert Manager on my cluster, right? So I'm just like, I don't wanna think about it, but I, you know, but I, I feel like I thought about it one time. I have a decent grasp. If something changes, then I guess I have to dive back in. I think it, you've heard the, um, innovation tokens idea, right? I can't remember the site. It's like, um, do, like do boring tech or something.com (https://boringtechnology.club/) . Like it shows up on sort of hacker news from time to time, essentially. But it's like, you know, you have a certain amount of tokens and sort of, uh, we'll call them tokens, but tolerance for complexity or tolerance for new, new ideas or new ways of doing things, new processes. Uh, and you spend those as you build any project, right? you can be devastatingly effective by just sticking to the stack, you know, and not introducing anything new, even if it's bad, right? and there's nothing wrong with LAMP stack, I don't wanna annoy anybody, but like if you, if you're running LAMP or if you run on a hostgator, right? Like, if you run on so, you know, some, some service that's really old but really works for you isn't, you know, too terribly insecure or like, has the features you need, don't learn Kubernetes then, right? Especially if you wanna go fast. cuz you, you're spending tokens, right? You're spending, essentially brain power, right? On learning whatever other thing. So, but yeah, like going back to that, databases versus databases on Kubernetes thing, you should probably know one of those before you, like, if you're gonna do that, do that thing. You either know Kubernetes and you like, at least feel comfortable, you know, knowing Kubernetes extremely difficult obviously, but you feel comfortable and you feel like you can debug. Little bit of a tangent, but maybe that's even a better, sort of watermark if you know how to debug a thing. If, if it's gone wrong, maybe one or five or 10 or 20 times and you've gotten out. Not without documentation, of course, cuz well, if you did, you're superhuman. But, um, but you've been able to sort of feel your way out, right? Like, Oh, this has gone wrong and you have enough of a model of the system in your head to be like, these are the three places that maybe have something wrong with them. Uh, and then like, oh, and then of course it's just like, you know, a mad dash to kind of like, find, find the thing that's wrong. You should have confidence about probably one of those things before you try and do both when it's like, you know, complex things like databases and distributed systems management, uh, and orchestration. [00:19:18] Jeremy: That's, that's so true in, in terms of you are comfortable enough being able to debug a problem because it's, I think when you are learning about something, a lot of times you start with some kind of guide or some kind of tutorial and you follow the steps. And if it all works, then great. Right? But I think it's such a large leap from that to something went wrong and I have to figure it out. Right. Whether it's something's not right in my Dockerfile or my postgres instance uh, the queries are timing out. so many things that could go wrong, that is the moment where you're forced to figure out, okay, what do I really know about this not thing? [00:20:10] Victor: Exactly. Yeah. Like the, the rubber's hitting the road it's uh you know the car's about to crash or has already crashed like if I open the bonnet, do I know what's happening right or am I just looking at (unintelligible). And that's, it's, I feel sort a little sorry or sad for, for devs that start today because there's so much. Complexity that's been built up. And a lot of it has a point, but you need to kind of have seen the before to understand the point, right? So I like, I like to use front end as an example, right? Like the front end ecosystem is crazy, and it has been crazy for a very long time, but the steps are actually usually logical, right? Like, so like you start with, you know, HTML, CSS and JavaScript, just plain, right? And like, and you can actually go in lots of directions. Like HTML has its own thing. CSS has its own sort of evolution sort of thing. But if we look at JavaScript, you're like, you're just writing JavaScript on every page, right? And like, just like putting in script tags and putting in whatever, and it's, you get spaghetti, you get spaghetti, you start like writing, copying the same function on multiple pages, right? You just, it, it's not good. So then people, people make jquery, right? And now, now you've got like a, a bundled set of like good, good defaults that you can, you can go for, right? And then like, you know, libraries like underscore come out for like, sort of like not dom related stuff that you do want, you do want everywhere. and then people go from there and they go to like backbone or whatever. it's because Jquery sort of also becomes spaghetti at some point and it becomes hard to manage and people are like, Okay, we need to sort of like encapsulate this stuff somehow, right? And like the new tools or whatever is around at the same timeframe. And you, you, you like backbone views for example. and you have people who are kind of like, ah, but that's not really good. It's getting kind of slow. Uh, and then you have, MVC stuff comes out, right? Like Angular comes out and it's like, okay, we're, we're gonna do this thing called dirty checking, and it's gonna be, it's gonna be faster and it's gonna be like, it's gonna be less sort of spaghetti and it's like a little bit more structured. And now you have sort of like the rails paradigm, but on the front end, and it takes people to get a while to get adjusted to that, but then that gets too heavy, right? And then dirty checking is realized to be a mistake. And then, you get stuff like MVVM, right? So you get knockout, like knockout js and you got like Durandal, and like some, some other like sort of front end technologies that come up to address that problem. Uh, and then after that, like, you know, it just keeps going, right? Like, and if you come in at the very end, you're just like, What is happening? Right? Like if it, if it, if someone doesn't sort of boil down the complexity and reduce it a little bit, you, you're just like, why, why do we do this like this? Right? and sometimes there's no good reason. Sometimes the complexity is just like, is unnecessary, but having the steps helps you explain it, uh, or helps you understand how you got there. and, and so I feel like that is something younger people or, or newer devs don't necessarily get a chance to see. Cause it just, it would take, it would take very long right? And if you're like a new dev, let's say you jumped into like a coding bootcamp. I mean, I've got opinions on coding boot camps, but you know, it's just like, let's say you jumped into one and you, you came out, you, you made it. It's just, there's too much to know. sure, you could probably do like HTML in one month. Well, okay, let's say like two weeks or whatever, right? If you were, if you're literally brand new, two weeks of like concerted effort almost, you know, class level, you know, work days right on, on html, you're probably decently comfortable with it. Very comfortable. CSS, a little harder because this is where things get hard. Cause if you, if you give two weeks for, for HTML, CSS is harder than HTML kind of, right? Because the interactions are way more varied. Right? Like, and, and maybe it's one of those things where you just, like, you, you get somewhat comfortable and then just like know that in the future you're gonna see something you don't understand and have to figure it out. Uh, but then JavaScript, like, how many months do you give JavaScript? Because if you go through that first like, sort of progression that I, I I, I, I mentioned everyone would have a perfect sort of, not perfect but good understanding of the pieces, right? Like, why did we start transpiling at all? Right? Like, uh, or why did you know, why did we adopt libraries? Like why did Bower exist? No one talks about Bower anymore, obviously, but like, Bower was like a way to distribute front end only packages, right? Um, what is it? Um, Uh, yes, there's grunt. There's like the whole build system thing, right? Once, once we decide we're gonna, we're gonna do stuff to files before we, before we push. So there's grunt, there's, uh, gulp, which is like grunt, but like, Oh, we're gonna do it all in memory. We're gonna pipe, we're gonna use this pipes thing to make sure everything goes fast. then there's like, of course that leads like the insanity that's webpack. And then there's like parcel, which did better. There's vite there's like, there's all this, there's this progression, but how many months would it take to know that progression? It, it's too long. So they end up just like, Hey, you're gonna learn react. Which is the right thing because it's like, that's what people hire for, right? But then you're gonna be in react and be like, What's webpack, right? And it's like, but you can't go down. You can't, you don't have the time. You, you can't sort of approach that problem from the other direction where you, which would give you better understanding cause you just don't have the time. I think it's hard for newer devs to overcome this. Um, but I think there are some, there's some hope on the horizon cuz some things are simpler, right? Like some projects do reduce complexity, like, by watching another project sort of innovate so like react. Wasn't the first component, first framework, right? Like technically, I, I think, I think you, you might have to give that to like, to maybe backbone because like they had views and like marionette also went with that. Like maybe, I don't know, someone, someone I'm sure will get in like, send me an angry email, uh, cuz I forgot you Moo tools or like, you know, Ember Ember. They've also, they've also been around, I used to be a huge Ember fan, still, still kind of am, but I don't use it. but if you have these, if you have these tools, right? Like people aren't gonna know how to use them and Vue was able to realize that React had some inefficiencies, right? So React innovates the sort of component. So Reintroduces the component based model component first, uh, front end development model. Vue sees that and it's like, wait a second, if we just export this like data object, and of course that's not the only innovation of Vue, but if we just export this data object, you don't have to do this fine grained tracking yourself anymore, right? You don't have to tell React or tell your the system which things change when other things change, right? Like you, you don't have to set up this watching and stuff, right? Um, and that's one of the reasons, like Vue is just, I, I, I remember picking up Vue and being like, Oh, I'm done. I'm done with React now. Because it just doesn't make sense to use React because they Vue essentially either, you know, you could just say they learned from them or they, they realize a better way to do things that is simpler and it's much easier to write. Uh, and you know, functionally similar, right? Um, similar enough that it's just like, oh they boil down some of that complexity and we're a step forward and, you know, in other ways, I think. Uh, so that's, that's awesome. Every once in a while you get like a compression in the complexity and then it starts to ramp up again and you get maybe another compression. So like joining the projects that do a compression. Or like starting to adopting those is really, can be really awesome. So there's, there's like, there's some hope, right? Cause sometimes there is a compression in that complexity and you you might be lucky enough to, to use that instead of, the thing that's really complex after years of building on it. [00:27:53] Jeremy: I think you're talking about newer developers having a tough time making sense of the current frameworks but the example you gave of somebody starting from HTML and JavaScript going to jquery backbone through the whole chain, that that's just by nature of you've put in a lot of time right you've done a lot of work working with each of these technologies you see the progression as if someone is starting new just by nature of you being new you won't have been able to spend that time [00:28:28] Victor: Do you think it could work? again, the, the, the time aspect is like really hard to get like how can you just avoid spending time um to to learn things that's like a general problem I think that problem is called education in the general sense. But like, does it make sense for a, let's say a bootcamp or, or any, you know, school right? To attempt to guide people through the previous solutions that didn't work, right? Like in math, you don't start with calculus, right? It just wouldn't, it doesn't make sense, right? But we try and start with calculus in software, right? We're just like, okay, here's the complexity. You've got all of it. Don't worry. Just look at this little bit. If, you know, if the compiler ever spits out a weird error uh oh, like, you're, you're, you're in for trouble cuz you, you just didn't get the. get the basics. And I think that's maybe some of what is missing. And the thing is, it is like the constraints are hard, right? No one has infinite time, right? Or like, you know, even like, just tons of time to devote to learning, learning just front end, right? That's not even all of computing, That's not even the algorithm stuff that some companies love to throw at you, right? Uh, or the computer sciencey stuff. I wonder if it makes more sense to spend some time taking people through the progression, right? Because discovering that we should do things via components, let's say, or, or at least encapsulate our functionality to components and compose that way, is something we, we not everyone knew, right? Or, you know, we didn't know wild widely. And so it feels like it might make sense to touch on that sort of realization and sort of guide the student through, you know, maybe it's like make five projects in a week and you just get progressively more complex. But then again, that's also hard cause effort, right? It's just like, it's a hard problem. But, but I think right now, uh, people who come in at the end and sort of like see a bunch of complexity and just don't know why it's there, right? Like, if you've like, sort of like, this is, this applies also very, this applies to general, but it applies very well to the Kubernetes problem as well. Like if you've never managed nginx on more than one machine, or if you've never tried to set up a, like a, to format your file system on the machine you just rented because it just, you know, comes with nothing, right? Or like, maybe, maybe some stuff was installed, but, you know, if you had to like install LVM (Logical Volume Manager) yourself, if you've never done any of that, Kubernetes would be harder to understand. It's just like, it's gonna be hard to understand. overlay networks are hard for everyone to understand, uh, except for network people who like really know networking stuff. I think it would be better. But unfortunately, it takes a lot of time for people to take a sort of more iterative approach to, to learning. I try and write blog posts in this way sometimes, but it's really hard. And so like, I'll often have like an idea, like, so I call these, or I think of these as like onion, onion style posts, right? Where you either build up an onion sort of from the inside and kind of like go out and like add more and more layers or whatever. Or you can, you can go from the outside and sort of take off like layers. Like, oh, uh, Kubernetes has a scheduler. Why do they need a scheduler? Like, and like, you know, kind of like, go, go down. but I think that might be one of the best ways to learn, but it just takes time. Or geniuses and geniuses who are good at two things, right? Good at the actual technology and good at teaching. Cuz teaching is a skill and it's very hard. and, you know, shout out to teachers cuz that's, it's, it's very difficult, extremely frustrating. it's hard to find determinism in, in like methods and solutions. And there's research of course, but it's like, yeah, that's, that's a lot harder than the computer being like, Nope, that doesn't work. Right? Like, if you can't, if you can't, like if you, if the function call doesn't work, it doesn't work. Right. If the person learned suboptimally, you won't know Right. Until like 10 years down the road when, when they can't answer some question or like, you know, when they, they don't understand. It's a missing fundamental piece anyway. [00:32:24] Jeremy: I think with the example of front end, maybe you don't have time to walk through the whole history of every single library and framework that came but I think at the very least, if you show someone, or you teach someone how to work with css, and you have them, like you were talking about components before you have them build a site where there's a lot of stuff that gets reused, right? Maybe you have five pages and they all have the same nav bar. [00:33:02] Victor: Yeah, you kind of like make them do it. [00:33:04] Jeremy: Yeah. You make 'em do it and they make all the HTML files, they copy and paste it, and probably your students are thinking like, ah, this, this kind of sucks [00:33:16] Victor: Yeah [00:33:18] Jeremy: And yeah, so then you, you come to that realization, and then after you've done that, then you can bring in, okay, this is why we have components. And similarly you brought up, manual dom manipulation with jQuery and things like that. I, I'm sure you could come up with an example of you don't even necessarily need to use jQuery. I think people can probably skip that step and just use the the, the API that comes with the browser. But you can have them go in like, Oh, you gotta find this element by the id and you gotta change this based on this, and let them experience the. I don't know if I would call it pain, but let them experience like how it was. Right. And, and give them a complex enough task where they feel like something is wrong right. Or, or like, there, should be something better. And then you can go to you could go straight to vue or react. I'm not sure if we need to go like, Here's backbone, here's knockout. [00:34:22] Victor: Yeah. That's like historical. Interesting. [00:34:27] Jeremy: I, I think that would be an interesting college course or something that. Like, I remember when, I went through school, one of the classes was programming languages. So we would learn things like, Fortran and stuff like that. And I, I think for a more frontend centered or modern equivalent you could go through, Hey, here's the history of frontend development here's what we used to do and here's how we got to where we are today. I think that could be actually a pretty interesting class yeah [00:35:10] Victor: I'm a bit interested to know you learned fortran in your PL class. I, think when I went, I was like, lisp and then some, some other, like, higher classes taught haskell but, um, but I wasn't ready for haskell, not many people but fortran is interesting, I kinda wanna hear about that. [00:35:25] Jeremy: I think it was more in terms of just getting you exposed to historically this is how things were. Right. And it wasn't so much of like, You can take strategies you used in Fortran into programming as a whole. I think it was just more of like a, a survey of like, Hey, here's, you know, here's Fortran and like you were saying, here's Lisp and all, all these different languages nd like at least you, you get to see them and go like, yeah, this is kind of a pain. [00:35:54] Victor: Yeah [00:35:55] Jeremy: And like, I understand why people don't choose to use this anymore but I couldn't take away like a broad like, Oh, I, I really wish we had this feature from, I think we were, I think we were using Fortran 77 or something like that. I think there's Fortran 77, a Fortran 90, and then there's, um, I think, [00:36:16] Victor: Like old fortran, deprecated [00:36:18] Jeremy: Yeah, yeah, yeah. So, so I think, I think, uh, I actually don't know if they're, they're continuing to, um, you know, add new things or maintain it or it's just static. But, it's, it's more, uh, interesting in terms of, like we were talking front end where it's, as somebody who's learning frontend development who is new and you get to see how, backbone worked or how Knockout worked how grunt and gulp worked. It, it's like the kind of thing where it's like, Oh, okay, like, this is interesting, but let us not use this again. Right? [00:36:53] Victor: Yeah. Yeah. Right. But I also don't need this, and I will never again [00:36:58] Jeremy: yeah, yeah. It's, um, but you do definitely see the, the parallels, right? Like you were saying where you had your, your Bower and now you have NPM and you had Grunt and Gulp and now you have many choices [00:37:14] Victor: Yeah. [00:37:15] Jeremy: yeah. I, I think having he history context, you know, it's interesting and it can be helpful, but if somebody was. Came to me and said hey I want to learn how to build websites. I get into front end development. I would not be like, Okay, first you gotta start moo tools or GWT. I don't think I would do that but it I think at a academic level or just in terms of seeing how things became the way they are sure, for sure it's interesting. [00:37:59] Victor: Yeah. And I, I, think another thing I don't remember who asked or why, why I had to think of this lately. um but it was, knowing the differentiators between other technologies is also extremely helpful right? So, What's the difference between ES build and SWC, right? Again, we're, we're, we're leaning heavy front end, but you know, just like these, uh, sorry for context, of course, it's not everyone a front end developer, but these are two different, uh, build tools, right? For, for JavaScript, right? Essentially you can think of 'em as transpilers, but they, I think, you know, I think they also bundle like, uh, generally I'm not exactly sure if, if ESbuild will bundle as well. Um, but it's like one is written in go, the other one's written in Rust, right? And sort of there's, um, there's, in addition, there's vite which is like vite does bundle and vite does a lot of things. Like, like there's a lot of innovation in vite that has to have to do with like, making local development as fast as possible and also getting like, you're sort of making sure as many things as possible are strippable, right? Or, or, or tree shakeable. Sorry, is is is the better, is the better term. Um, but yeah, knowing, knowing the, um, the differences between projects is often enough to sort of make it less confusing for me. Um, as far as like, Oh, which one of these things should I use? You know, outside of just going with what people are recommending. Cause generally there is some people with wisdom sometimes lead the crowd sometimes, right? So, so sometimes it's okay to be, you know, a crowd member as long as you're listening to the, to, to someone worth listening to. Um, and, and so yeah, I, I think that's another thing that is like the mark of a good project or, or it's not exclusive, right? It's not, the condition's not necessarily sufficient, but it's like a good projects have the why use this versus x right section in the Readme, right? They're like, Hey, we know you could use Y but here's why you should use us instead. Or we know you could use X, but here's what we do better than X. That might, you might care about, right? That's, um, a, a really strong indicator of a project. That's good cuz that means the person who's writing the project is like, they've done this, the survey. And like, this is kind of like, um, how good research happens, right? It's like most of research is reading what's happening, right? To knowing, knowing the boundary you're about to push, right? Or try and sort of like push one, make one step forward in, um, so that's something that I think the, the rigor isn't in necessarily software development everywhere, right? Which is good and bad. but someone who's sort of done that sort of rigor or, and like, and, and has, and or I should say, has been rigorous about knowing the boundary, and then they can explain that to you. They can be like, Oh, here's where the boundary was. These people were doing this, these people were doing this, these people were doing this, but I wanna do this. So you just learned now whether it's right for you and sort of the other points in the space, which is awesome. Yeah. Going to your point, I feel like that's, that's also important, it's probably not a good idea to try and get everyone to go through historical artifacts, but if just a, a quick explainer and sort of, uh, note on the differentiation, Could help for sure. Yeah. I feel like we've skewed too much frontend. No, no more frontend discussion this point. [00:41:20] Jeremy: It's just like, I, I think there's so many more choices where the, the mental thought that has to go into, Okay, what do I use next I feel is bigger on frontend. I guess it depends on the project you're working on but if you're going to work on anything front end if you haven't done it before or you don't have a lot of experience there's so many build tools so many frameworks, so many libraries that yeah, but we [00:41:51] Victor: Iterate yeah, in every direction, like the, it's good and bad, but frontend just goes in every direction at the same time Like, there's so many people who are so enthusiastic and so committed and and it's so approachable that like everyone just goes in every direction at the same time and like a lot of people make progress and then unfortunately you have try and pick which, which branch makes sense. [00:42:20] Jeremy: We've been kind of talking about, some of your experiences with a few things and I wonder if you could explain the the context you're thinking of in terms of the types of projects you typically work on like what are they what's the scale of them that sort of thing. [00:42:32] Victor: So I guess I've, I've gone through a lot of phases, right? In sort of what I use in in my tooling and what I thought was cool. I wrote enterprise java like everybody else. Like, like it really doesn't talk about it, but like, it's like almost at some point it was like, you're either a rail shop or a Java shop, for so many people. And I wrote enterprise Java for a, a long time, and I was lucky enough to have friends who were really into, other kinds of computing and other kinds of programming. a lot of my projects were wrapped around, were, were ideas that I was expressing via some new technology, let's say. Right? So, I wrote a lot of haskell for, for, for a while, right? But what did I end up building with that was actually a job board that honestly didn't go very far because I was spending much more time sort of doing, haskell things, right? And so I learned a lot about sort of what I think is like the pinnacle of sort of like type development in, in the non-research world, right? Like, like right on the edge of research and actual usability. But a lot of my ideas, sort of getting back to the, the ideas question are just things I want to build for myself. Um, or things I think could be commercially viable or like do, like, be, be well used, uh, and, and sort of, and profitable things, things that I think should be built. Or like if, if I see some, some projects as like, Oh, I wish they were doing this in this way, Right? Like, I, I often consider like, Oh, I want, I think I could build something that would be separate and maybe do like, inspired from other projects, I should say, Right? Um, and sort of making me understand a sort of a different, a different ecosystem. but a lot of times I have to say like, the stuff I build is mostly to scratch an itch I have. Um, and or something I think would be profitable or utilizing technology that I've seen that I don't think anyone's done in the same way. Right? So like learning Kubernetes for example, or like investing the time to learn Kubernetes opened up an entire world of sort of like infrastructure ideas, right? Because like the leverage you get is so high, right? So you're just like, Oh, I could run an aws, right? Like now that I, now that I know this cuz it's like, it's actually not bad, it's kind of usable. Like, couldn't I do that? Right? That kind of thing. Right? Or um, I feel like a lot of the times I'll learn a technology and it'll, it'll make me feel like certain things are possible that they, that weren't before. Uh, like Rust is another one of those, right? Like, cuz like Rust will go from like embedded all the way to WASM, which is like a crazy vertical stack. Right? It's, that's a lot, That's a wide range of computing that you can, you can touch, right? And, and there's, it's, it's hard to learn, right? The, the, the, the, uh, the, the ramp to learning it is quite steep, but, it opens up a lot of things you can write, right? It, it opens up a lot of areas you can go into, right? Like, if you ever had an idea for like a desktop app, right? You could actually write it in Rust. There's like, there's, there's ways, there's like is and there's like, um, Tauri is one of my personal favorites, which uses web technology, but it's either I'm inspired by some technology and I'm just like, Oh, what can I use this on? And like, what would this really be good at doing? or it's, you know, it's one of those other things, like either I think it's gonna be, Oh, this would be cool to build and it would be profitable. Uh, or like, I'm scratching my own itch. Yeah. I think, I think those are basically the three sources. [00:46:10] Jeremy: It's, it's interesting about Rust where it seems so trendy, I guess, in lots of people wanna do something with rust, but then in a lot of they also are not sure does it make sense to write in rust? Um, I, I think the, the embedded stuff, of course, that makes a lot of sense. And, uh, you, you've seen a sort of surge in command line apps, stuff ripgrep and ag, stuff like that, and places like that. It's, I think the benefits are pretty clear in terms of you've got the performance and you have the strong typing and whatnot and I think where there's sort of the inbetween section that's kind of unclear to me at least would I build a web application in rust I'm not sure that sort of thing [00:47:12] Victor: Yeah. I would, I characterize it as kind of like, it's a tool toolkit, so it really depends on the problem. And think we have many tools that there's no, almost never a real reason to pick one in particular right? Like there's, Cause it seems like just most of, a lot of the work, like, unless you're, you're really doing something interesting, right? Like, uh, something that like, oh, I need to, I need to, like, I'm gonna run, you know, billions and billions of processes. Like, yeah, maybe you want erlang at that point, right? Like, maybe, maybe you should, that should be, you know, your, your thing. Um, but computers are so fast these days, and most languages have, have sort of borrowed, not borrowed, but like adopted features from others that there's, it's really hard to find a, a specific use case, for one particular tool. Uh, so I often just categorize it by what I want out of the project, right? Or like, either my goals or project goals, right? Depending on, and, or like business goals, if you're, you know, doing this for a business, right? Um, so like, uh, I, I basically, if I want to go fast and I want to like, you know, reduce time to market, I use type script, right? Oh, and also I'm a, I'm a, like a type zealot. I, I'd say so. Like, I don't believe in not having types, right? Like, it's just like there's, I think it's crazy that you would like have a function but not know what the inputs could be. And they could actually be anything, right? , you're just like, and then you have to kind of just keep that in your head. I think that's silly. Now that we have good, we, we have, uh, ways to avoid the, uh, ceremony, right? You've got like hindley Milner type systems, like you have a way to avoid the, you can, you know, predict what types of things will be, and you can, you don't have to write everything everywhere. So like, it's not that. But anyway, so if I wanna go fast, the, the point is that going back to that early, like the JS ecosystem goes everywhere at the same time. Typescript is excellent because the ecosystem goes everywhere at the same time. And so you've got really good ecosystem support for just about everything you could do. Um, uh, you could write TypeScript that's very loose on the types and go even faster, but in general it's not very hard. There's not too much ceremony and just like, you know, putting some stuff that shows you what you're using and like, you know, the objects you're working with. and then generally if I wanna like, get it really right, I I'll like reach for haskell, right? Cause it's just like the sort of contortions, and again, this takes time, this not fast, but, right. the contortions you can do in the type system will make it really hard to write incorrect code or code that doesn't, that isn't logical with itself. Of course interfacing with the outside world. Like if you do a web request, it's gonna fail sometimes, right? Like the network might be down, right? So you have to, you basically pull that, you sort of wrap that uncertainty in your system to whatever degree you're okay with. And then, but I know it'll be correct, right? But and correctness is just not important. Most of like, Oh, I should , that's a bad quote. Uh, it's not that correct is not important. It's like if you need to get to market, you do not necessarily need every single piece of your code to be correct, Right? If someone calls some, some function with like, negative one and it's not an important, it's not tied to money or it's like, you know, whatever, then maybe it's fine. They just see an error and then like you get an error in your back and you're like, Oh, I better fix that. Right? Um, and then generally if I want to be correct and fast, I choose rust these days. Right? Um, these days. and going back to your point, a lot of times that means that I'm going to write in Typescript for a lot of projects. So that's what I'll do for a lot of projects is cuz I'll just be like, ah, do I need like absolute correctness or like some really, you know, fancy sort of type stuff. No. So I don't pick haskell. Right. And it's like, do I need to be like mega fast? No, probably not. Cuz like, cuz so I don't necessarily don't necessarily need rust. Um, maybe it's interesting to me in terms of like a long, long term thing, right? Like if I, if I'm think, oh, but I want x like for example, tight, tight, uh, integration with WASM, for example, if I'm just like, oh, I could see myself like, but that's more of like, you know, for a fun thing that I'm doing, right? Like, it's just like, it's, it's, you don't need it. You don't, that's premature, like, you know, that's a premature optimization thing. But if I'm just like, ah, I really want the ability to like maybe consider refactoring some of this out into like a WebAssembly thing later, then I'm like, Okay, maybe, maybe I'll, I'll pick Rust. Or like, if I, if I like, I do want, you know, really, really fast, then I'll like, then I'll go Rust. But most of the time it's just like, I want a good ecosystem so I don't have to build stuff myself most of the time. Uh, and you know, type script is good enough. So my stack ends up being a lot of the time just in type script, right? Yeah. [00:52:05] Jeremy: Yeah, I think you've encapsulated the reason why there's so many packages on NPM and why there's so much usage of JavaScript and TypeScript in general is that it, it, it fits the, it's good enough. Right? And in terms of, in terms of speed, like you said, most of the time you don't need of rust. Um, and so typescript I think is a lot more approachable a lot of people have to use it because they do front end work anyways. And so that kinda just becomes the I don't know if I should say the default but I would say it's probably the most common in terms of when somebody's building a backend today certainly there's other languages but JavaScript and TypeScript is everywhere. [00:52:57] Victor: Yeah. Uh, I, I, I, another thing is like, I mean, I'm, of ignored the, like, unreasonable effectiveness of like rails Cause there's just a, there's tons of just like rails warriors out there, and that's great. They're they're fantastic. I'm not a, I'm not personally a huge fan of rails but that's, uh, that's to my own detriment, right? In, in some, in some ways. But like, Rails and Django sort of just like, people who, like, I'm gonna learn this framework it's gonna be excellent. It most, they have a, they have carved out a great ecosystem for themselves. Um, or like, you know, even php right? PHP and like Laravel, or whatever. Uh, and so I'm ignoring those, like, those pockets of productivity, right? Those pockets of like intense productivity that people like, have all their needs met in that same way. Um, but as far as like general, general sort of ecosystem size and speed for me, um, like what you said, like applies to me. Like if I, if I'm just like, especially if I'm just like, Oh, I just wanna build a backend, Like, I wanna build something that's like super small and just does like, you know, maybe a few, a couple, you know, endpoints or whatever and just, I just wanna throw it out there. Right? Uh, I, I will pick, yeah. Typescript. It just like, it makes sense to me. I also think note is a better. VM or platform to build on than any of the others as well. So like, like I, by any of the others, I mean, Python, Perl, Ruby, right? Like sort of in the same class of, of tool. So I I am kind of convinced that, um, Node is better, than those as far as core abilities, right? Like threading Right. Versus the just multi-processing and like, you know, other, other, other solutions and like, stuff like that. So, if you want a boring stack, if I don't wanna use any tokens, right? Any innovation tokens I reach for TypeScript. [00:54:46] Jeremy: I think it's good that you brought up. Rails and, and Django because, uh, personally I've done, I've done work with Rails, and you're right in that Rails has so many built in, and the ways to do them are so well established that your ability to be productive and build something really fast hard to compete with, at least in my experience with available in the Node ecosystem. Um, on the other hand, like I, I also see what you mean by the runtimes. Like with Node, you're, you're built on top of V8 and there's so many resources being poured into it to making it fast and making it run pretty much everywhere. I think you probably don't do too much work with managed services, but if you go to a managed service to run your code, like a platform as a service, they're gonna support Node. Will they support your other preferred language? Maybe, maybe not, You know that they will, they'll be able to run node apps so but yeah I don't know if it will ever happen or maybe I'm just not familiar with it, but feel like there isn't a real rails of javascript. [00:56:14] Victor: Yeah, you're, totally right. There are, there are. It's, it's weird. It's actually weird that there, like Uh, but, but, I kind of agree with you. There's projects that are trying it recently. There's like Adonis, um, there is, there are backends that also do, like, will do basic templating, like Nest, NestJS is like really excellent. It's like one of the best sort of backend, projects out there. I I, I but like back in the day, there were projects like Sails, which was like very much trying to do exactly what Rails did, but it just didn't seem to take off and reach that critical mass possibly because of the size of the ecosystem, right? Like, how many alternatives to Rails are there? Not many, right? And, and now, anyway, maybe let's say the rest of 'em sort of like died out over the years, but there's also like, um, hapi HAPI, uh, which is like also, you know, similarly, it was like angling themselves to be that, but they just never, they never found the traction they needed. I think, um, or at least to be as wide, widely known as Rails is for, for, for the, for the Ruby ecosystem, um, but also for people to kind of know the magic, cause. Like I feel like you're productive in Rails only when you imbibe the magic, right? You, you, know all the magic context and you know the incantations and they're comforting to you, right? Like you've, you've, you have the, you have the sort of like, uh, convention. You're like, if you're living and breathing the convention, everything's amazing, right? Like, like you can't beat that. You're just like, you're in the zone but you need people to get in that zone. And I don't think node has, people are just too, they're too frazzled. They're going like, there's too much options. They can't, it's hard to commit, right? Like, imagine if you'd committed to backbone. Like you got, you can't, It's, it's over. Oh, it's not over. I mean, I don't, no, I don't wanna, you know, disparage the backbone project. I don't use it, but, you know, maybe they're still doing stuff and you know, I'm sure people are still working on it, but you can't, you, it's hard to commit and sort of really imbibe that sort of convention or, or, or sort of like, make yourself sort of breathe that product when there's like 10 products that are kind of similar and could be useful as well. Yeah, I think that's, that's that's kind of big. It's weird that there isn't a rails, for NodeJS, but, but people are working on it obviously. Like I mentioned Adonis, there's, there's more. I'm leaving a bunch of them out, but that's part of the problem. [00:58:52] Jeremy: On, on one hand, it's really cool that people are trying so many different things because hopefully maybe they can find something that like other people wouldn't have thought of if they all stick same framework. but on the other hand, it's ... how much time have we spent jumping between all these different frameworks when what we could have if we had a rails. [00:59:23] Victor: Yeah the, the sort of wasted time is, is crazy to think about it uh, I do think about that from time to time. And you know, and personally I waste a lot of my own time. Like, just, just rec

http://9chat-e.mynt.work/?c=radio/contents&id=662 プログラミング学習に役立つ情報をお伝えするラジオ番組

http://9chat-e.mynt.work/?c=radio/contents&id=662 プログラミング学習に役立つ情報をお伝えするラジオ番組

44bits 팟캐스트 126번째 로그에서는 도커 서울 밋업 종료, 파이어폭스 사용자 감소, 스택오버플로 2021 설문조사에 대해서 이야기를 나누었습니다. Dockerfile heardoc 지원 Engineering Update: BuildKit 0.…

44bits 팟캐스트 126번째 로그에서는 도커 서울 밋업 종료, 파이어폭스 사용자 감소, 스택오버플로 2021 설문조사에 대해서 이야기를 나누었습니다. 참가자: @nacyo_t, @raccoonyy, @outsideris, @ecleya 정기 후원 - 44bits podcast are creating 프로그래머들의 팟캐스트 녹음일 8월 6일, 공개일 10월 14일 쇼노트: https://stdout.fm/126/ 주제별 바로 듣기 00:00 시작 03:15 쿠버네티스 동양북스 신간 05:57 Docker Seoul Meetup 종료 10:07 Dockerfile heardoc 지원 24:21 스택오버플로 2021 설문조사 결과 57:59 Firefox 사용자 감소 01:04:11 RenderingNG 쇼노트 Dockerfile heardoc 지원 Engineering Update: BuildKit 0.9 and Docker Buildx 0.6 Releases - Docker Blog 스택오버플로 2021 설문조사 결과 Stack Overflow Developer Survey 2021 - Stack Overflow 스택오버플로우의 개발자 설문조사 2021 - GeekNews Firefox 사용자 감소 Firefox Public Data Report RenderingNG Chromium이 발표한 RenderingNG가 무엇인가? - NHN Cloud Meetup

An airhacks.fm conversation with Prof. dr. Matjaz Juric (@matjazbj) about: the larger the system, the more important the modularization, modularization and reuse, modularization and business requirements, cross-cutting logic is a solved problem, a module is a Java package, OSGi introduces additional complexity, packaging vs modularity, modularization and team work, most of the patterns became a part of the platform, isolation with deployment units, a module is a Dockerfile, internal modularization became less important, physical and logical modularization, logical over physical modularization, physical modularization introduces complexity, costs driven development, kubernetes and modularization, cloud complexity vs. Java runtime complexity, wrong cloud expectations, CI/CD in the clouds, internal microservice structure should be simpler, ECS blue green deployment with AWS CodeDeploy, vendor independence vs. cloud specific services in the clouds, Payara Cloud: Payara cluster became Kubernetes operator, functions and microservices, serverless computing with functions, function communication styles, Apache Kafka and functions, the Outbox pattern is too technical, KumuluzEE and Kumuluz Platform, Prof. dr. Matjaz Juric on twitter: @matjazbj, Prof. dr. Matjaz Juric at University of Ljubljana

Watch the live stream: Watch on YouTube About the show Sponsored by Sentry: Sign up at pythonbytes.fm/sentry And please, when signing up, click Got a promo code? Redeem and enter PYTHONBYTES Special guest: Julia Signell Brain #1: Practical SQL for Data Analysis Haki Benita Pandas is awesome, but … “In this article I demonstrate how to use SQL to perform fast and efficient data analysis.” First part of the article. SQL is faster than Pandas But they are great together Then tons of examples showing exactly how to best use SQL queries and Pandas in data analysis:: Basics including random data and sampling Descriptive statistics Subtotals including rollup and groupign sets Pivot tables, both conditional expressions and aggregate expressions Running and cumulative agregation Linear Regression Interpolation Super cheat sheet for useful SQL queries Michael #2: Git Blame in your Python Tracebacks via Ruslan Portnoy, by Ofer Koren Helpful Modules: traceback & linecache traceback uses linecache, and we can change linecache line's text They create a git blame bit of functionality to add to line's source Turns out this flows to things like PDB. Ripe for a proper package we can add to requirements-dev.txt Julia #3: fsspec: a unified file system library Martin Durant Other libraries conform to the interface so that each part of the analysis pipeline is like an interchangeable building block (for example s3fs, gcsfs) With the cloud providers competing to host data, fsspec makes it easy to swap out the read layer so that you can hop clouds. Brian #4: The need for slimmer containers or I'm even more confused now as to the usefulness of official base images on Docker Hub Ivan Velichko @iximiuz I read this article recently and it had me concerned. Then just yesterday read it again and there are some updates. I'm still concerned, but now also confused. So let's run it down. docker scan can be run on official Python images. It uses Snyk Container. We talked about one form of Snyk on Episode 227. Spoiler, all of the official Python containers have vulnerabilities except alpine. But. In an update, the author says that Alpine has a bunch of problems. The update includes some discussion on Hacker News vulnerability scanners tend to have lots of false positives official base images are rarely updated some people suggest adding an upgrade command in the beginning of every Dockerfile. but others object saying that the practice leads to unrepeatable builds So, I'm left with wondering if using official Python images are even worth it. Michael: Python's official image on docker hub Michael: PEP 656 -- Platform Tag for Linux Distributions Using Musl Michael: We dive a lot into this in our latest Talk Python recording (not out yet, but live stream is available) Some stats: Ubuntu: Found 32 vulnerabilities, 31 with upgrade. python:latest: Found 364 vulnerabilities, 353 with upgrade Ubuntu with source Python: 35 total, 28 low, 7 medium, several from intermediate tools such as wget, gcc, etc. Removing many dev tools SHOULD lower the count, but doesn't (e.g. wget, gcc) Switching from python:3-9 to python:3.9-slim-buster dropped the issues to 69. Michael #5: PandasGUI: A GUI for analyzing Pandas DataFrames Features View DataFrames and Series (with MultiIndex support) Interactive plotting Filtering Statistics summary Data editing and copy / paste Import CSV files with drag & drop Search toolbar Best way to see what it's about is to watch the video. Julia #6: xarray: pandas-like API for labeled N-dimensional data We've been talking a lot about the pandas API and how it's a common target for dataframe libraries. Xarray is not a dataframe library, it's for labeled N-dimensional data. People use it in geosciences, and in image processing where they don't have tabular data, but the axes mean something (lat, lon, time, band…) You can select, aggregate, resample, using the real dimension labels. It can be backed with dask arrays or numpy arrays (or other types of arrays). It supports plotting with .plot Extras Michael Python 3.10.0b2 is available (even windows store) Django security releases issued: 3.2.4, 3.1.12, and 2.2.24 Another method overloading library? Recently moved to pip-compile requirements.in style after last week I'm running PyCharm EAP Brian Someone responded to me the other day on twitter with an emoji that I was not clear on the meaning of. So I looked it up on emojipedia.org. Super useful for occasionally out of touch people like myself. pytestbook.com (redirects to pythontest.com/pytest-book/) has a facelift and a new home, to get ready for an announcement later this week. It's built on markdown, hugo, github, and Netlify, so changes can be done super quick with just a commit and push. I just needed a nice readable theme, and Pradyun's blog looked great, so I copied his choices. The blog will eventually also have writing, the legacy posts worth keeping from pythontesting.net, and probably transcripts from Test & Code. Julia GH CLI entrypoints - they are so cool! Example - with pandas you can plot with different backends not just matplotlib and the logic for those backends is contained in the plotting libraries not pandas. Joke From https://upjoke.com/programmer-jokes I asked a programmer what her New Year's resolution will be. She answered: 1920x1080. How does a programmer confuse a mathematician? x = x + 1 Why do Python programmers have low self esteem? They're constantly comparing their self to other.

Build automation tools automate the process of building code, including steps such as compiling, packaging binary code, and running automated tests. Because of this, build automation tools are considered a key part of a continuous delivery pipeline. Build automation tools read build scripts to define how they should perform a build. Common build scripts include Makefile, Dockerfile, and bash. Earthly is a build automation tool that allows you to execute all your builds in containers. Earthly uses Earthfiles, which draws from the best features of Makefile and Dockerfile and provides a common layer between language-specific tooling and the CI build spec. Earthly builds are repeatable, isolated, and self-contained, and will run the same way across different environments such as a CI system or a developer's laptop. Vlad Ionescu is the Founder and CEO of Earthly Technologies. He was formerly the founder and chief architect at ShiftLeft.io. Vlad joins the show today to talk about why reproducible builds are important, how Earthly simplifies build scripts, and what the long-term vision for Earthly looks like.

Тайминг: 00:53 - Ностальгия по ICQ (https://dev.by/news/zagruzki-icq-v-gonkonge-vyrosli-v-35-raz-iz-za-nostalgii-i-nedoveriya-k-whatsapp) 05:29 - Эксперты рассуждают про StopGame 16:53 - Разбор Sysdig 2021 Container Security and Usage Report (https://sysdig.com/blog/sysdig-2021-container-security-usage-report/) 01:06:10 - Учимся безопасно писать Dockerfile (https://habr.com/ru/company/swordfish_security/blog/537280/) 01:17:21 - Что нового в k8s 1.20? (https://m.habr.com/en/company/flant/blog/530924/)   Доп материал: Схема - https://containerd.io/img/architecture.png DOM Panel discussion - https://www.youtube.com/watch?v=Zy6VovBkbOk Сказать спасибо: https://www.patreon.com/devopskitchentalks Музыка: https://www.bensound.com

You probably know that Azure Container Registry enables you to store and manage container images securely, but did you know it can also be used as a part of your DevOps pipelines? Jeremy Likness shows Scott Hanselman how ACR can manage your images and even build them for you in the cloud. [0:00:00]– Overview[0:01:57]– Generating a Dockerfile in Visual Studio and building a container[0:06:24]– Running the container with Azure Container Instances[0:10:17]– Using container images in ACR as part of a build pipeline[0:13:05]– Wrap-upTutorial: Build and deploy container images in the cloud with Azure Container Registry TasksAutomate container image builds and maintenance with ACR TasksAzure Container RegistryCreate a free account (Azure)

You probably know that Azure Container Registry enables you to store and manage container images securely, but did you know it can also be used as a part of your DevOps pipelines? Jeremy Likness shows Scott Hanselman how ACR can manage your images and even build them for you in the cloud. [0:00:00]– Overview[0:01:57]– Generating a Dockerfile in Visual Studio and building a container[0:06:24]– Running the container with Azure Container Instances[0:10:17]– Using container images in ACR as part of a build pipeline[0:13:05]– Wrap-upTutorial: Build and deploy container images in the cloud with Azure Container Registry TasksAutomate container image builds and maintenance with ACR TasksAzure Container RegistryCreate a free account (Azure)

You probably know that Azure Container Registry enables you to store and manage container images securely, but did you know it can also be used as a part of your DevOps pipelines? Jeremy Likness shows Scott Hanselman how ACR can manage your images and even build them for you in the cloud. [0:00:00]– Overview[0:01:57]– Generating a Dockerfile in Visual Studio and building a container[0:06:24]– Running the container with Azure Container Instances[0:10:17]– Using container images in ACR as part of a build pipeline[0:13:05]– Wrap-upTutorial: Build and deploy container images in the cloud with Azure Container Registry TasksAutomate container image builds and maintenance with ACR TasksAzure Container RegistryCreate a free account (Azure)

You probably know that Azure Container Registry enables you to store and manage container images securely, but did you know it can also be used as a part of your DevOps pipelines? Jeremy Likness shows Scott Hanselman how ACR can manage your images and even build them for you in the cloud. [0:00:00]– Overview[0:01:57]– Generating a Dockerfile in Visual Studio and building a container[0:06:24]– Running the container with Azure Container Instances[0:10:17]– Using container images in ACR as part of a build pipeline[0:13:05]– Wrap-upTutorial: Build and deploy container images in the cloud with Azure Container Registry TasksAutomate container image builds and maintenance with ACR TasksAzure Container RegistryCreate a free account (Azure)

You probably know that Azure Container Registry enables you to store and manage container images securely, but did you know it can also be used as a part of your DevOps pipelines? Jeremy Likness shows Scott Hanselman how ACR can manage your images and even build them for you in the cloud. [0:00:00]– Overview[0:01:57]– Generating a Dockerfile in Visual Studio and building a container[0:06:24]– Running the container with Azure Container Instances[0:10:17]– Using container images in ACR as part of a build pipeline[0:13:05]– Wrap-upTutorial: Build and deploy container images in the cloud with Azure Container Registry TasksAutomate container image builds and maintenance with ACR TasksAzure Container RegistryCreate a free account (Azure)

In this bonus episode we will discuss the different Dockerfile instuctions and see how images are built. We also discuss ways to make our images smaller in size. You can say hi or send me a feed back by writing to me at "kubernetes at sent dot com" Support Link: www.buymeacoffee.com/chintu

An ML webapp usually requires:a) Tensorflow b) Opencv c) Flask

Chris and Josey use Docker for every day work, but is it all it can be or should be? What troubles have they run into and what suggestions do they have? Listen to find out! TOPICS - Their first experience with Docker was wonderful, right? - What is Docker and why containerization? - What is a Dockerfile? - What is docker-compose? - Are they the same? - Docker services, networks, volumes, containers, images - How do you pick docker-compose versions? - ....and so much more! MUSIC FROM THE CCMIXTER COMMUNITY Snazzy Intro: On Top of the World by texasradiofish (c) copyright 2015 Licensed under a Creative Commons Attribution Noncommercial (3.0) license. http://dig.ccmixter.org/files/texasradiofish/50478 Ft: John Fletcher, Patricia Edwards, ElRon XChile, Speck, alexplaysguitar Live Show Starting Soon: cdk - Sunday by Analog By Nature (c) copyright 2016 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/cdk/53755 Live Show Outro: ＭＩＬＬＥＮＮＩＡＬＳ by Analog By Nature (c) copyright 2018 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/cdk/57150

コンテナ本番環境 Dockerfile を書くためのベストプラクティス Amazon Elastic Container Service Heroku Deploying with Docker Ubuntuデスクトップ Ubuntu 20.04 LTS (Focal Fossa)

Foundations of Amateur Radio The hobby of Amateur Radio is essentially one of experimentation. Within our community we endlessly build things, from amplifiers to Yagis and every letter of the alphabet in between. With every experiment we grow the amateur radio sphere of influence just a little bit. As our hobby is evolving into Software Defined Radio, or SDR, the homebrew aspect of our community is also changing bit by bit and as a result, homebrew today is just as likely to be based on software as it is in hardware. Unlike the physical world where you need to source and buy components, design a circuit, build it, test it and then put it in a box, in the software realm you can get started with the computer that is more than likely within reach right now. Recently I took delivery of a new SDR, an ADALM Pluto. It's essentially a Linux computer, FPGA and transmit capable SDR in a small box. I bought it specifically for the purpose of experimentation. One of the first things I did with this device was install an existing piece of software called dump1090. The tool listens to 1090 MHz and decodes Mode S transponders, used by aviation to report aircraft information in real-time. Originally written by Salvatore Sanfilippo in 2012 for the RTL-SDR dongle, it was patched by several people and in 2017 it was updated by Jiang Wei to support the Pluto SDR. My contribution to the project is minor. I've updated the on-board web-server to use Open Street Map and a few other cosmetic changes. For me it was a "Hello World" project, something that's the software equivalent of warming up your soldering iron and pre-tinning the wire you're about to use. The tools to do this is what I want to discuss. When you look at the software that underlies much of the SDR world, the digital modes, logging, contesting, even the software inside tools like the Nano-VNA, much of it is open source. That means that as a curious amateur you can have access to the underlying equivalent of the circuit diagram. As you can with a soldering iron, a scribe and wire, you can patch or update a circuit. In the software realm you can do the same once you have access to the source code. The tools you're going to get in touch with are text editors, compilers, libraries and configuration files. If that's not your thing, I appreciate that, but if it sparks your interest, you'll open the door into a brand new world of software development where you can determine how a mode works or what it supports or how it interacts with your radio or testing gear. When you jump in, likely feet first, you're going to make mistakes and lose hair and sleep and you'll be shaking your virtual or physical fist at the person who came before you, but then that's the world of experimentation, so likely you'll already have that down pat. You'll likely play with different tools that require different versions, often installed side-by-side, much to your chagrin when you learn that it just won't work. Not to mention that removal of the offending tool often leaves interfering cruft behind, not unlike unsightly and short-circuiting blobs of solder. I'm here to introduce you, albeit briefly, to a tool that will take much of that pain away. The free tool is called Docker. It has got little in the way of visibility in the amateur radio world, but in the software development world it's pretty much old hat. Essentially the idea is that you can install stuff into a so called disposable container so you can have your copy of dump1090 installed in one container and your copy of codec2 in another, a copy of rtl-sdr in a third container, all working independently from each other, without needing to complicate things with multiple computers or virtual machines. If a developer uses Debian, another uses Ubuntu and a third uses Red Hat, you can run these side-by-side without any issue. If they need an ancient version of something, that too is handled without a problem. Make a mistake, destroy the container and start again, fresh. Docker is a tool that allows you to build an environment on Linux, MacOS and Windows, as well as the Raspberry Pi, that acts and behaves in many ways like a virtual machine. In all the ways that you're likely to use it, at least initially, it's indistinguishable. What that means is that the operating system, the compiler and the libraries that you need for one tool won't affect those needed for another tool. The best part of this is that you can build on a massive library of pre-existing Docker containers and use files that describe how to build and compile tools like dump1090. If you look for my callsign vk6flab on github.com, you'll find my version of dump1090 and you'll find a Dockerfile that describes how I built it. The project contains all the bits you'll need to get started with your own version of dump1090, or some other project that tickles your fancy. Every time you build something, the amateur radio sphere of influence grows just that little bit. I'm Onno VK6FLAB

Join me, your host, Scott Everhart as I discuss Dockerfiles and how they allow you to enhance your automationI'll be discussing where they come from, some use cases and a command reference of some useful commands that go into a dockerfile.I'll also be reviewing a simple dockerfile to show how the commands are formatted and used together.Show Notes are archived at https://scott-everhart.com/podcast/blog/

Containers are all the jazz, and they contribute to all sorts of positive outcomes. In this episode, I cover the basics of Containerization. Sources Containers will not fix your broken Culture docker.io Transcript Containers - If one single technology could represent the union of Dev and Ops it would be containers. In 1995, Sun Microsystems told us that using Java we could write once and run anywhere. Containers are the modern, and arguably in this respect more successful, way to go about this portability. Brought to the mainstream by Docker, containers promise us the blessed land of immutability, portability and ease of use. Containers can serve as a breaker of silos or the handoff mechanism between traditional Dev and Ops. This is the DevOps Dojo Episode #4, I'm Johan Abildskov, join me in the dojo to learn. As with anything, containers came to solve problems in software development. The problems containers solve are around the deployment and operability of applications or services in traditional siloed Dev and Ops organizations.    On the Development side of things deployment was and is most commonly postponed to the final stages of a project. Software is perhaps only on run the developers own computer. This can lead to all sorts of problems. The architecture might not be compatible with the environments that we deploy the software into. We might not have covered security and operability issues, because we are still working in a sandbox environment. We have not gotten feedback from those who operate applications on how we can enable monitoring and lifecycle management of our applications. And thus, we might have created a lot of value, but we are completely unable to deliver it.   On the Operations side of things, we struggle with things such as implicit dependencies. The applications run perfectly fine on staging servers, or on the developer PC, but when we receive it, it is broken. This could be because the version of the operating systems doesn't match, there are different versions of tooling, or even something as simple as an environment variable or file being present.   Different applications can also have different dependencies to operating systems and libraries. This makes it difficult to utilize hardware in a cost-efficient way.   Operations commonly serve many teams, and there might be many different frameworks, languages, and delivery mechanisms. Some teams might come with a jar file and no instructions, while others bring thousands of lines of bash.   In both camps, there can be problems with testing happening on something other than the thing we end up deploying.    Containers can remedy most of these pains. As with physical containers, it does not matter what we stick into them, we will still be able to stack them high and ship them across the oceans.   In the case of Docker we create a so called Dockerfile that describes what goes into our container. This typically starts at the operating system level or from some framework like nodejs. Then we can add additional configurations and dependencies, install our application and define how it is run and what it exposes. This means that we can update our infrastructure and applications independently. It also means that we can update our applications independently from each other. If we want to move to a new PHP version, it doesn't have to be everyone at the same time, but rather product by product fitting it into their respective timelines. This can of course lead to a diverse landscape of diverging versions, which is not a good thing. With great power comes great responsibility. The Dockerfile can be treated like source code and versioned together with our application source.    The Dockerfile is then compiled into a container image that can be run locally or distributed for deployment. This image can be shared through private or public registries.   Because many people and organizations create and publish these container images, it has become easy to run a test on tooling. We can run a single command, and then we have a configured Jenkins, Jira or whatever instance running, that we can throw away when we are done with it. This leads to faster and safer experimentation.   The beautiful thing is that this container image then becomes our build artifact, and we can test this image extensively, deploy it to different environments to poke and prod it. And it is the same artifact that we test and deploy. The container that we run, can be traced to an image which can be traced to a Dockerfile from a specific Git s ha. That is a lot of traceability.   Because we now have pushed some of the deployment responsibility to the developers, we have an easier time architecting for deployment. Our local environments look more like production environments. Which should remove some surprises from the process of releasing our software leading to better outcomes and happier employees.   Some of you might think, isn't this just virtual machines. And it kind of almost is. Intuitively at least. But containers are implemented to borrow more directly from the host operating system, which leads to lower startup times, and smaller images.   We can create and share so-called base images. Images that are can be seen as a template or runtime for specific types of applications. This can help reduce the lead time from project start to something that can be deployed in production to almost zero, as the packaging and deployment has been taken care of.   But as Bridget Kromhout said, “Containers will not fix your broken culture”. Containers are not the silver bullet that they are sometimes touted as.    When we move into a container universe, perhaps even moving towards container orchestration with Kubernetes, we tend to neglect or forget about the Ops capabilities and problems we still need to solve. Backups and failovers. Patching of OS and libraries. Performance monitoring and alerting. There are many things that might become implicit and that can lead to risky business decisions. While Docker may lead us as developers to be able to somewhat better maintain and run our application in production, I want to make it very clear. Docker is not a replacement for Ops   Using containers is an enabler for many things, and will also create tension against a bureaucratic organization, because of its ease of use. It will be mind-blowing for some, and will require mindset shifts in both Dev and Ops. It also paves the way for more lifecycle management later on, with for instance Kubernetes. To reap the full benefits of containers we have to architect our applications for it using principles such as the 12 factor application. This will again introduce tension and help us build better applications. So while containers will not fix your broken culture, if you are not already thinking about containerization, you probably should be. This has been the DevOpsDojo on Containers. You can follow me on twitter @randomsort. You can find show notes and more at dojo.fm. Support the show by leaving a review, sharing this episode with a friend or colleague or subscribing to the DevOpsDojo on your favourite podcast platform. Thank you for listening, keep learning.

Dans cet épisode, Audrey et Emmanuel se retrouvent en tête à tête pour discuter du nouveau drama à venir dans l’écosystème Java (Leyden), de l’actualité des librairies, des annonces de GitHub, de bonnes pratiques en matière d’outils et d’architecture et bien évidemment de la prochaine appli tendance : Stop Covid. Enregistré le 7 mai 2020 Téléchargement de l’épisode LesCastCodeurs-Episode–232.mp3 News Langages Projet Leyden: images statiques pour Java mais pas GraalVM native image Améliorer les performance de G1 “out of the box” Librairies Lucene a 20 ans Quarkus 1.4 est sorti Comment utiliser Mockito avec Quarkus Micrometer sort la 1.5 une LTS Spring rattrape son retard sur OpenJDK dans le schéma de version Micronaut 2.0 M3 Infrastructure Les bonnes pratiques pour écrire un fichier Dockerfile pour les développeurs ICANN rejette la vente de .org a une boite privée Cloud Les release notes de Google Cloud sur une seule page Web Cloudflare implement le draft d’HTTP/3 et compare Node.js v14 Data Les choses que j’aurai aimé que plus de développeurs connaissent sur les bases de données Redis 6 est sorti Outillage Test Containers 1.14 GitHub est gratuit pour les équipes si on downgrade sur le gratuit, on perd quoi https://help.github.com/en/github/getting-started-with-github/faq-about-changes-to-githubs-plans#if-i-downgrade-from-github-team-or-a-legacy-plan-to-github-free-what-features-will-i-lose Récap des annonces GitHub Satellite 2020 Spock 2.0 vs JUnit 5.0 Controler Kubernetes de Google Spreadsheet Gradle 6.4 Architecture Les microservices, trop fort pour toi - opinion Méthodologies COVID vs l’open space Sécurité Loi, société et organisation Apple et Google offrent un framework de notification d’exposition (au COVID–19) Stop-Covid La France se met dans une impasse face à Apple avec StopCovid StopCovid ou encore ? StopCovid : anonymat et autorités Conférences Devoxx UK du 24 au 26 Août 2020 AlpesCraft reportée à l’automne DevOps D-Day le 9 octobre 2020 - Le CfP est ouvert jusqu’au 15 juin DevFest Nantes les 15 et 16 octobre 2020 - Le CfP est ouvert jusqu’au 31 mai FrontSide le 15 octobre 2020 Volcamp.io les 15 et 16 octobre 2020 DevFest Toulouse les 5 et 6 novembre 2020 FlowCon les 9 et 10 novembre 2020 Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

Dans cet épisode, Audrey et Emmanuel se retrouvent en tête à tête pour discuter du nouveau drama à venir dans l'écosystème Java (Leyden), de l'actualité des librairies, des annonces de GitHub, de bonnes pratiques en matière d'outils et d'architecture et bien évidemment de la prochaine appli tendance : Stop Covid. Enregistré le 7 mai 2020 Téléchargement de l'épisode [LesCastCodeurs-Episode-232.mp3](https://traffic.libsyn.com/lescastcodeurs/LesCastCodeurs-Episode-232.mp3) ## News ### Langages [Projet Leyden: images statiques pour Java mais pas GraalVM native image](https://twitter.com/mreinhold/status/1254812999145017351) [Améliorer les performance de G1 "out of the box"](https://kstefanj.github.io/2020/04/16/g1-ootb-performance.html) ### Librairies [Lucene a 20 ans](https://www.elastic.co/fr/celebrating-lucene) [Quarkus 1.4 est sorti](https://quarkus.io/blog/quarkus-1-4-final-released/) [Comment utiliser Mockito avec Quarkus](https://quarkus.io/blog/mocking/) [Micrometer sort la 1.5 une LTS](https://github.com/micrometer-metrics/micrometer/releases/tag/v1.5.0) [Spring rattrape son retard sur OpenJDK dans le schéma de version](https://spring.io/blog/2020/04/30/updates-to-spring-versions) [Micronaut 2.0 M3](https://objectcomputing.com/news/2020/04/30/micronaut-20-m3-big-boost-serverless-and-micronaut-launch) ### Infrastructure [Les bonnes pratiques pour écrire un fichier Dockerfile pour les développeurs](https://www.docker.com/blog/speed-up-your-development-flow-with-these-dockerfile-best-practices/) [ICANN rejette la vente de .org a une boite privée](https://twitter.com/eff/status/1256053946289774594?s=21) ### Cloud [Les release notes de Google Cloud sur une seule page](https://cloud.google.com/release-notes) ### Web [Cloudflare implement le draft d'HTTP/3 et compare](https://blog.cloudflare.com/http-3-vs-http-2/) [Node.js v14](https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e) ### Data [Les choses que j'aurai aimé que plus de développeurs connaissent sur les bases de données](https://medium.com/@rakyll/things-i-wished-more-developers-knew-about-databases-2d0178464f78) [Redis 6 est sorti](https://redislabs.com/press/redis-6-0-released-and-now-available-in-redis-enterprise-cloud/) ### Outillage [Test Containers 1.14](https://github.com/testcontainers/testcontainers-java/releases/tag/1.14.0) [GitHub est gratuit pour les équipes](https://github.blog/2020-04-14-github-is-now-free-for-teams/) * si on downgrade sur le gratuit, on perd quoi https://help.github.com/en/github/getting-started-with-github/faq-about-changes-to-githubs-plans#if-i-downgrade-from-github-team-or-a-legacy-plan-to-github-free-what-features-will-i-lose [Récap des annonces GitHub Satellite 2020](https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/?utm_campaign=1588779509&utm_medium=social&utm_source=facebook,linkedin,twitter&utm_content=1588779509) [Spock 2.0 vs JUnit 5.0](https://blog.solidsoft.pl/2020/04/15/spock-vs-junit-5-the-ultimate-feature-comparison/) [Controler Kubernetes de Google Spreadsheet](https://github.com/learnk8s/xlskubectl) [Gradle 6.4](https://docs.gradle.org/6.4/release-notes.html) ### Architecture [Les microservices, trop fort pour toi - opinion](https://blog.octo.com/les-architectures-microservices-cest-un-peu-trop-fort-pour-toi-mon-ptit-gars/) ### Méthodologies [COVID vs l'open space](https://www.inc.com/geoffrey-james/the-open-plan-office-is-dead.html) ### Sécurité ### Loi, société et organisation [Apple et Google offrent un framework de notification d'exposition (au COVID-19)](https://blog.google/inside-google/company-announcements/apple-and-google-partner-covid-19-contact-tracing-technology) Stop-Covid * [La France se met dans une impasse face à Apple avec StopCovid](https://www.numerama.com/tech/619446-stopcovid-vs-apple-pourquoi-la-france-sest-mise-dans-une-impasse.html) * [StopCovid ou encore ?](https://medium.com/@cedric.o/stopcovid-ou-encore-b5794d99bb12) * [StopCovid : anonymat et autorités](https://quentin.dufour.io/blog/2020-04-20/stopcovid/) ## Conférences [Devoxx UK du 24 au 26 Août 2020](https://www.devoxx.co.uk/) [AlpesCraft reportée à l'automne](https://www.alpescraft.fr/) [DevOps D-Day le 9 octobre 2020](http://2019.devops-dday.com/) - [Le CfP est ouvert jusqu'au 15 juin](https://conference-hall.io/public/event/SoOGmgWEUqrFysQUbM8g) [DevFest Nantes les 15 et 16 octobre 2020](https://devfest.gdgnantes.com/) - [Le CfP est ouvert jusqu'au 31 mai](https://conference-hall.io/public/event/tcsfaCc4Gg0sSSxdJZKO) [FrontSide le 15 octobre 2020](https://frontsideconf.fr/) [Volcamp.io les 15 et 16 octobre 2020](https://www.volcamp.io/) [DevFest Toulouse les 5 et 6 novembre 2020](https://devfesttoulouse.fr/) [FlowCon les 9 et 10 novembre 2020](https://www.weezevent.com/flowcon-2020) ## Nous contacter Soutenez Les Cast Codeurs sur Patreon [Faire un crowdcast ou une crowdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter sur le groupe Google ou sur le site web

Quail Data #0007 - Stats Wars Rodolfo #1: MOSP MONARC Objects Sharing Platform (MOSP) es una plataforma para crear, editar y compartir objetos JSON validados de cualquier tipo. MONARC - Method for an Optimised aNAlysis of Risks by CASES (Método para un análisis optimizado de riesgos por CASOS.) Puede usar cualquier esquema JSON disponible para crear nuevos objetos JSON a través de un formulario web generado dinámicamente y basado en el esquema seleccionado. Sergio #2: Scikit Geometry "scikit-geometry también viene con funciones para calcular el diagrama de Voronoi, el casco convexo, cuadros delimitadores, la suma minkowski de dos polígonos, un árbol AABB para consultas vecinas más cercanas y muchas otras utilidades útiles para cálculos geométricos, con planes para agregar muchos más!" Rodolfo #3: pandapy Demos un momento para tomar en cuenta el siguiente meme: https://www.reddit.com/r/mathmemes/comments/ewct2v/euler_moment/ Ahora, ¿recuerdan, por una parte a Pandas? Y por otra parte, ¿a NumPy? Pues bueno, pueden pensar en este paquete como un hijo de ambos. PandaPy tiene la velocidad de NumPy y la usabilidad de Pandas (10x a 50x más rápido). Así como importas pandas como pd y numpy como np, el común es importar a pandapy como pp (ya sabes → pd & np = pp). Sergio #4: Como hacer tu propio blog sin ser un experto en computadoras con fast.ai y fast_template Una guía muy fácil de seguir para crear tu propio blog hosteado en GitHub pages sin tener que usar la linea de comando. Es muy practico y facil de seguir y ahora utiliza GitHub Actions para transformar tus notebooks de jupyter a blog posts Rodolfo #5: Construyendo un Python Data Science Container usando Docker Es un blog post que ilustra cómo crear un contenedor de Docker que incluya paquetería como NumPy, SciPy, Pandas, SciKit-Learn, Matplotlib y NLTK. Todo se realiza a través de la construcción de un Dockerfile basado en Alpine, una versión muuuy ligera de Linux. El post te da todos los comandos para levantar el contenedor. Sergio #6: Blog de Juvenal Campos - Como Visualizar Pirámides de Población en R Un paso a paso de como construir una piramide de poblacion con ggplot2 Juvenal usa blogdown de R para este blog - todxs deberiamos bloguear mas! Extras: Sergio: Lorem Ipsum pero mexicano ? jajaja https://ignaciochavez.com/projects/lorempaisum/ RStudioConf está aquí en San Francisco esta semana y tienen los materiales de sus talleres en GitHub pa quién no pudo asistir: https://github.com/rstudio-conf-2020 Rodo: Para la gente Pythonista que nos escucha, ¡ya hay fecha para el PyCon Latam 2020! 27-29 de agosto, Pto. Vallarta, Jalisco. ¡No se lo pueden perder! (https://twitter.com/PyLatam/status/1221886633210982402) Meme de la semana --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/quaildata/message Support this podcast: https://anchor.fm/quaildata/support

In this episode of Elixir Mix the panel has a conversation about a few things they have been thinking about. First, they shout out to anyone who would love to chat about config change callbacks. Then they dive into deployment discussing the updates that have happened this year. They share their experiences with the changes and compare the Elixir release to Distillery.  There are many options for deployment and they discuss some of the ones they have used. They consider services and do it yourself options. The panel shares lessons learned through their deployment experiences and give pro-tips for beginners and those new to Elixir.  The next topic they discuss is hot code reload. Michael shares his fascination with this practice and explains what it is. The panel discusses the possibilities and use-cases for hot code reload. Hot code upgrade is also discussed.  Panelists Mark Ericksen Michael Ries Eric Oestrich Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links grapevine  Deploying with Docker  https://hexdocs.pm/phoenix/heroku.html  https://www.heroku.com/  https://cloud.google.com/kubernetes-engine/  https://www.ansible.com/  https://gigalixir.com/  deploy.sh  Running migrations  release_tasks.ex  Configuration and releases  mix release  observer_cli  Erlang: The Movie  Using Erlang Distribution to test hardware  The Athens Affair  ElixirConf 2018 - Docker and OTP Friends or Foes - Daniel Azuma  Richard Carlsson - The art of the live upgrade - 10 yrs of evolving a live system | Code BEAM SF 19  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: Hot Rod   Install Elixir using asdf  Michael Ries: https://twitter.com/fhunleth/status/1195524113617637376  scenic sensor  Eric Oestrich: Elixir Wizards 

In this episode of Elixir Mix the panel has a conversation about a few things they have been thinking about. First, they shout out to anyone who would love to chat about config change callbacks. Then they dive into deployment discussing the updates that have happened this year. They share their experiences with the changes and compare the Elixir release to Distillery.  There are many options for deployment and they discuss some of the ones they have used. They consider services and do it yourself options. The panel shares lessons learned through their deployment experiences and give pro-tips for beginners and those new to Elixir.  The next topic they discuss is hot code reload. Michael shares his fascination with this practice and explains what it is. The panel discusses the possibilities and use-cases for hot code reload. Hot code upgrade is also discussed.  Panelists Mark Ericksen Michael Ries Eric Oestrich Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links grapevine  Deploying with Docker  https://hexdocs.pm/phoenix/heroku.html  https://www.heroku.com/  https://cloud.google.com/kubernetes-engine/  https://www.ansible.com/  https://gigalixir.com/  deploy.sh  Running migrations  release_tasks.ex  Configuration and releases  mix release  observer_cli  Erlang: The Movie  Using Erlang Distribution to test hardware  The Athens Affair  ElixirConf 2018 - Docker and OTP Friends or Foes - Daniel Azuma  Richard Carlsson - The art of the live upgrade - 10 yrs of evolving a live system | Code BEAM SF 19  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: Hot Rod   Install Elixir using asdf  Michael Ries: https://twitter.com/fhunleth/status/1195524113617637376  scenic sensor  Eric Oestrich: Elixir Wizards 

Mark Mirchandani hosts solo today but is later joined by fellow Googler and Developer Advocate Ray Tsang to talk Java! Ray tells us what’s new with Java 11, including more memory and fewer restrictions for developers. One of the greatest things for Ray is using Java 11 in App Engine because of the management support that it provides. Later, we talk about Spring Boot on GCP. Ray explains the many benefits of using this framework. Developers can get their projects started much more quickly, for example, and with Spring Cloud GCP, it’s easy to integrate GCP services like Spanner and run your project in the cloud. For users looking to containerize their Java projects, JIB can help you do this without having to write a Dockerfile. At the end of the show, Ray and Mark pull it all together by explaining how Spring Boot, Cloud Code, Skaffold, and proper dev-ops can work together for a seamless Java project. Ray Tsang Ray is a Developer Advocate for the Google Cloud Platform and a Java Champion. Ray works with engineering and product teams to improve Java developer productivity on GCP. He also helps Alphabet companies migrate and adopt cloud native architecture. Prior to Google, Ray worked at Red Hat, Accenture, and other consulting companies, where he focused on enterprise architecture, managed solutions delivery, and contributed to open source projects. Aside from technology, Ray enjoys traveling and adventures. Cool things of the week Cloud Run is now GA blog Budget API in Beta blog Interview App Engine site Micronaut site Quarkus site Java 11 on App Engine blog and docs Spring Boot and Spring Cloud site Spring Cloud GCP Projects site Cloud Spanner site Spring Cloud Sleuth site Stackdriver site Bootiful GCP: To Production! blog Effective Cloud Native Spring Boot on Kubernetes & Google Cloud Platform blog JDBC drivers site Hibernate ORM with Cloud Spanner docs Effective Cloud Native Spring Boot on Kubernetes & Google Cloud Platform blog Dev to Prod with Spring on GCP in 20 Minutes (Cloud Next ‘19) video Cloud Code site JIB site Skaffold site Debugger site Troubleshooting & Debugging Microservices in Kubernetes blog Cloud Code Quickstart docs Spring (or Java) to Kubernetes Faster and Easier blog GCP Podcast Episode 58: Java with Ray Tsang and Rajeev Dayal podcast Question of the week How do I dockerize my Java app? video github Where can you find us next? Ray is taking a break for the holidays, but in the future, you can find him at Java and JUG conferences. Mark is hanging out in the Bay Area, but Google Cloud Next in London and KubeCon and CloudNativeCon are happening now! Sound Effect Attribution “Small Group Laugh 4, 5 & 6” by Tim.Kahn of Freesound.org “Tre-Loco1” by Sonipro of Freesound.org “Mens Sincere Laughter” by Urupin of Freesound.org “Party Pack” by InspectorJ of Freesound.org “DrumRoll” by HolyGhostParty of Freesound.org “Tension” by ERH of Freesound.org

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby What’s new in Interactive Ruby Shell (IRB) with Ruby 2.7, Ruby 2.7 adds Integer#[] to support range values, Rails 6 adds add_foreign_key and remove_foreign_key for SQLite3, Puma 4.2.0 и Behind-the-scenes of ‘Geared Pagination’ in Rails Best practices when writing a Dockerfile for a Ruby application, Erubi - a ERB template engine for ruby и The Journey to One Million by Samuel Williams (video) Web V8 release v7.8, Node v12.11.0, Wikipedia’s JavaScript initialisation on a budget и Why JavaScript Tooling Sucks 15 Must-Have Vue Directives That Will Significantly Maximize Your Productivity, GPU.js 2.0, OGL - a small, effective WebGL framework, Repeater.js - a missing constructor for creating safe async iterators, Robot - fast 1kB functional library for creating Finite State Machines и React-Toastify 5.4.0

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019 Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough Azure DevOps Services VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins – YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019 Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough Azure DevOps Services VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins – YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019 Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough Azure DevOps Services VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins – YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild

In this episode I discuss the differences between the dockerfiles commands of ENTRYPOINT and CMD, and how to use them together for automate container startup tasks.

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019   Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough  Azure DevOps Services  VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins - YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild  

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019   Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough  Azure DevOps Services  VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins - YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild  

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Charles Max Wood Joined by Special Guest: Jessica Deen Episode Summary Coming to you live from the podcast booth at Microsoft BUILD is Charles Max Wood with The Deen of DevOps aka Jessica Deen. Jessica is a Senior Cloud Advocate at Microsoft. As an advocate she acts a liaison between developer communities and Microsoft to help understand developer pain points and road blocks especially in areas such as Linux, open-source technologies, infrastructure, Kubernetes, containers and DevOps. Jessica explains how to go about setting up a containerized application, Kubernetes and how to use Dockerfiles. Charles and Jessica then talk about how to get started with a Kubernetes cluster and the resources available for developers that don't have any infrastructure. Jessica advises that developers start with Azure DevOps Services and then go to Microsoft Learn Resource. Charles also encourages listeners to also check out the Views on Vue podcast Azure DevOps with Donovan Brown for further references. Jessica also recommends following people on Twitter and GitHub to find out about solutions and resources. Links Dockerfile and Windows Containers Kubernetes Jessica’s GitHub Jessica’s Twitter Jessica’s LinkedIn Jessica’s Website Microsoft Build 2019   Microsoft Learn Resource HTTP application routing Getting started with Kubernetes Ingress Controllers and TLS certificates Kubernetes Ingress Controllers and Certificates: The Walkthrough  Azure DevOps Services  VoV 053: Azure DevOps with Donovan Brown LIVE at Microsoft Ignite Jessica Deen Youtube Kubernetes in 5 mins - YouTube Follow Adventures in Angular on tv, Facebook and Twitter. Picks Jessica Deen: Lachlan Evenson Cloud Native Computing Foundation Kubernetes Handles on Twitter Shoe Dog Memoir Air Jordan 4 Fire Red Gum Singles Day Charles Max Wood: Real Talk /JavaScript Podcast The Legend of Zelda: Breath of the Wild  

Guillaume, Vincent et Emmanuel discutent des nouvelles autour de Java 12, Jakarta EE, Spring, Quarkus, la mairie de Paris et son data center. Mais aussi de web, de Huawei, du design des fichiers Dockerfile et bien d’autres choses encore. Enregistré le 4 juin 2019 Téléchargement de l’épisode LesCastCodeurs-Episode–212.mp3 News Langages JVM Ecosystem Survey 2019 Java 12 switch expressions Images officielles AdoptOpenJDK sur Docker Hub Don’t fear the Java Librairies Jakarta EE and the great naming debate Spring Boot 2.2 M3 available now Utiliser les co-routines Kotlin pour utiliser Spring Reactive structured concurrency trade off entre approche visuellement imperative et l’approache reactive GraalVM 19.0 Eclipse Vert.x 3.7.1 The JHipster Quarkus demo app Quarkus 0.16.0 emails blocking et non blocking Configuration profiles CORS Camel AWS SQS Reactive PostgreSQL client Introduction à JSON Web Tokens Autre article sur JWT Infrastructure Fusion OpenTracing / OpenCensus -> OpenTelemetry: quid de Jaeger On devrait éviter les Dockerfiles d’exemple qu’on voit un peu partout DigitalOcean ferme l’infra d’une boite via un script de verification les risques évoluent de gérer sa stack physique à gérer un prestataire et ses consequences de l’automatisation pas de backup hors du prestataire… Cloud gVisor, un an après Web Flutter 1.5 Build your Angular application with Bazel Build your own WebAssembly Compiler W3C / WHATWG fusionnent HTTP HEADERS du developpeur responsable HSTS Content-Security-Policy (upgrade insecure requests etc) cache control, accept encoding (compression) Accept and Accept CH ramener un webp quand in .jpg est demandé CH: tailles etc Gluon reutilise GraalVM pour faire des applis mobiles native mentionne jpackage Data Elastic rend des fonctionnalités de sécurité gratuites mais pas open source Changer le schéma de base de données automatiquement à SendGrid et à Square Outillage FreeCodeCamp quitte Medium Medium pousse pour un paywall les gens redecouvrent que les blogs sont distribués par nature RSS FTW Architecture Pourquoi les microservices devraient vous faire plus peur Méthodologies GitHub sort GitHub Sponsors sponsoriser un developer open source Product placement sur Wikipedia Les excuses de North Face Loi, société et organisation Google révoque la licence Android de Huawei : 5 questions pour comprendre ce que cela implique en suspension pour 3 mois Les développeurs chinois ont peur de perdre GitHub La mairie de Paris vs créer son propre data center Beaucoup de gens outrés qu’ils ne prennent pas OVH (securité, c’est un métier, etc) Pourquoi c’est pas si con durée de vie des données sur plus d’une vie humaine marché public de ~ 5 ans max: bouger données tous les 5 ans bonjour Conférences BestOfWeb les 6 et 7 juin 2019 DevFest Lille le 14 juin 2019 Hack Commit Push 15 juin pour contribuer à de l’open source presentation des projets au ParisJUG le 13 juin Voxxed Days Luxembourg les 20 et 21 juin 2019 Sunny Tech les 27 & 28 juin 2019 JugSummerCamp le 13 septembre 2019 - Le CfP est ouvert. DevFest Toulouse le 3 octobre 2019 - Le CfP est ouvert. DevFest Nantes les 21 et 22 octobre 2019 - Le CfP est ouvert. Voxxed Microservices 21 au 23 octobre 2019 et le CfP est ouvert. ScalaIO du 29 au 31 octibre a Lyon. CFP ouvert jusqu’à fin juin. Thème programmation fonctionelle. Devoxx Belgique du 4 au 8 novembre 2019 Bdx.io le 15 novembre 2019 - Le CfP est ouvert. DevOps D-Day les 13 et 14 novembre 2019 - Le CfP est ouvert. Codeurs en Seine le 21 novembre 2019 Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/wdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/  

PyDataMCR - Episode 1 - Geospatial data with Rebecca Davey and David Mulcahy Welcome to the official PyDataMCR podcast, In this episode we are joined by Rebecca and David from INRIX. We zip through topics including GPS tracking, Hidden Markov Models and open source tools. Show notes: Libraries: Geopandas - http://geopandas.org/ Dockerfile for geopandas - https://hub.docker.com/r/jaspajjr/geopandas Folium - https://python-visualization.github.io/folium/ HMM-learn - https://hmmlearn.readthedocs.io/en/latest/ Valhalla - https://wiki.openstreetmap.org/wiki/Valhalla Graphhopper - https://www.graphhopper.com/ Openstreetmap - https://www.openstreetmap.org Openstreetmap wiki - https://wiki.openstreetmap.org Mapping Mobility in Stockport - https://bit.ly/2TZFal5 HMM for mapmatching - https://bit.ly/2Nqb5ZL Tech heroes: Professor Anna Scaife: https://twitter.com/radastrat Cathy O'Neil - https://twitter.com/mathbabedotorg Safiya Noble - https://twitter.com/safiyanoble Tom MacWright - https://macwright.org/ Our Sponsor Cathcart Associates is a technology recruitment company with offices in Leeds and Manchester covering all things tech, but with an experienced team focusing on Data Science in the North West. We’re good at what we do. We understand what our candidates do, and what our clients need, and we really care about making sure you both get what you want. We’ve been sponsoring PyDataMCR since its inception because we’re nice guys and we like pizza. Check out our website to get in touch – cathcartassociates.com Contact Twitter - twitter.com/pydatamcr Slack - bit.ly/2v60ieu Meetup - meetup.com/PyData-Manchester/

일곱 번째 에피소드에서는 지난 에피소드에서 다 하지 못 한 AWS re:Invent 2018 이야기와 Japan Container Days v18.12에 대해서 이야기를 했습니다. 참가자: @seapy, @nacyo_t AWS re:Invent 2018 | Amazon Web Services AWS Whats new - AWS Lambda Supports Ruby AWS Whats new - AWS Lambda Now Supports Custom Runtimes, and Enables Sharing Common Code Between Functions (일본어) Perl을 AWS Lambda에 실행 phusion/traveling-ruby: Self-contained, Ruby binaries AWS Whats new - Application Load Balancer can now Invoke Lambda Functions to Serve HTTP(S) Requests (일본어) AWS Lambda Custom Runtimes芸人 Advent Calendar 2018 - Qiita akr/all-ruby: Run various versions of ruby command @seapy 딥 레이서 3위 (일본어) JapanContainerDays v18.12 RubyKaigi 2018 (일본어) JapanContainerDays v18.12 Meetup｜EventRegist 아키하바라 멘 무사시 부진 @asbubam 님 추천 kubernetes/kubernetes: Production-Grade Container Scheduling and Management Cloud Native Computing Foundation Members - Cloud Native Computing Foundation Projects - Cloud Native Computing Foundation Envoy - Visitor Management and iPad Sign in Software | Envoy moby/buildkit: concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit CRIU - Checkpoint/Restore In Userspace docker-ce/checkpoint-restore.md at master · docker/docker-ce opencontainers/runtime-spec: OCI Runtime Specification firecracker-microvm/firecracker firecracker-microvm/firecracker-containerd AWS Launchpad - Firecracker is now Open Source Kata Containers - The speed of containers, the security of VMs Nabla containers: a new approach to container isolation · Nabla Containers CRI: the Container Runtime Interface Red Hat Acquires CoreOS For $250 Million 하시코프 한국 사용자 모임 첫 번째 밋업 | Festa! 컨테이너 가상화의 모든 것 - 바이라인 네트워크 (일본어) 임프레스 북스 (일본어) Wantedly - 비지니스 SNS (일본어) 오차노미즈 솔라시티 컨퍼런스 센터 (일본어) ZOZOTOWN - ZOZOSUIT RubyKaigi 2019 Are you ready to attend RubyKaigi 2019? I’m READY! - 虚無庵

Guillaume s’assoie avec David Gageot pour discuter une partie de l’écosystème Kubernetes. C’est probablement le premier épisode d’une série sur Kubernetes. Enregistré le 11 septembre 2018 Téléchargement de l’épisode LesCastCodeurs-Episode–195.mp3 Interview Merci aux premiers auditeurs qui ont sauté le pas en nous soutiennent sur Patreon https://www.patreon.com/LesCastCodeurs. Ta vie, ton œuvre David Gageot Kubernetes Orchestrateur open source de containeurs, avec déploiement, scaling et management automatisé. Kubernetes Istio Un “service mesh” open source pour connecter, sécuriser, contrôler, monitorer vos applications sur Kubernetes. Istio Run El Capitan, macOS Sierra, High Sierra and Mojave on QEMU/KVM Knative Des blocs de construction de base, open source, pour créer des plateformes serverless sur Kubernetes, développé par Google, Pivotal, Red Hat, IBM, SAP et d’autres. Knative Skaffold Outil open source en ligne de commande pour faciliter le développement continu sur d’applications sur Kubernetes. Skaffold Jib Outil open source pour containeuriser des applications Java, avec plugins Maven et Gradle associés, pour builder rapidement, de manière reproductible, sans avoir recours au démon Docker. Jib Distroless Images Docker légères ne contenant que le système d’exploitation, les dépendances, et l’application elle-même, supportant Java, Go, .Net, Python ou Go. Distroless Kaniko Outil open source pour builder des images à partir d’un Dockerfile, dans un conteneur ou dans un cluster Kubernetes, sans avoir besoin du démon Docker. Kaniko Gvisor Un noyau en user-space écrit en Go, pour créer des conteneurs sandboxés. gvisor Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/  

Panel: Charles Max Wood Eric Berry Mark Erikson Special Guests: Julian Fahrer In this episode of Elixir Mix, the panel talks to Julian Fahrer about Docker. Docker is a container platform, which you can imagine as a set of tools, services, and practices that help you to develop, ship, and run your applications using software container technology. They talk about the applicability for developers for using Docker, the two different ways people use Docker, and how he usually uses Docker. They also touch on the main idea behind containers, the basics of Docker, and more! In particular, we dive pretty deep on: What is Docker? Containers are very lightweight Containers VS virtual machines How are people using Docker with Erlang and/or Elixir? What’s the applicability for using Docker? Ability to set up complex systems Docker works out of the box with Windows, Mac, and Linux 2 different ways people use Docker How do you usually use Docker? Working with Discourse Discourse uses Docker exclusively CodeFund Are you saying that the projects are headed more towards open source using Docker? Using Docker to have a front and backend separated experience Phoenix Main idea behind containers Running things in isolation John Papa Demonstration The value of deploying a release if you’re doing a Docker container The basics of Docker learndocker.online And much, much more! Links: Docker Erlang Elixir Discourse CodeFund Phoenix John Papa Demonstration learndocker.online Prometheus Twelve Factor App codetales.io @jufahr Julian GitHub Sponsors: Digital Ocean Picks: Charles Take time to code for fun Get away devchat.tv/elixir-docker Eric Cross Stitching Mark Dockerfile – his Gist Julian CNCF Landscape IndieHackers.com The UltraMind Solution by Mark Hyman

Panel: Charles Max Wood Eric Berry Mark Erikson Special Guests: Julian Fahrer In this episode of Elixir Mix, the panel talks to Julian Fahrer about Docker. Docker is a container platform, which you can imagine as a set of tools, services, and practices that help you to develop, ship, and run your applications using software container technology. They talk about the applicability for developers for using Docker, the two different ways people use Docker, and how he usually uses Docker. They also touch on the main idea behind containers, the basics of Docker, and more! In particular, we dive pretty deep on: What is Docker? Containers are very lightweight Containers VS virtual machines How are people using Docker with Erlang and/or Elixir? What’s the applicability for using Docker? Ability to set up complex systems Docker works out of the box with Windows, Mac, and Linux 2 different ways people use Docker How do you usually use Docker? Working with Discourse Discourse uses Docker exclusively CodeFund Are you saying that the projects are headed more towards open source using Docker? Using Docker to have a front and backend separated experience Phoenix Main idea behind containers Running things in isolation John Papa Demonstration The value of deploying a release if you’re doing a Docker container The basics of Docker learndocker.online And much, much more! Links: Docker Erlang Elixir Discourse CodeFund Phoenix John Papa Demonstration learndocker.online Prometheus Twelve Factor App codetales.io @jufahr Julian GitHub Sponsors: Digital Ocean Picks: Charles Take time to code for fun Get away devchat.tv/elixir-docker Eric Cross Stitching Mark Dockerfile – his Gist Julian CNCF Landscape IndieHackers.com The UltraMind Solution by Mark Hyman

This week we spoke with our San Francisco correspondent Alex Handy about containerizing Java applications. The Google Cloud Platform recently released Jib, a new open-source container image builder for Java developers. Google says that Jib “does not require you to write a Dockerfile or have docker installed, and it is directly integrated into [the] Maven and Gradle,” Java build tools. Jib comes with many of the cloud-native build-tool features you'd expect, including incremental builds, a configuration-as-code approach, and reproducible build images for faster deployments and rollbacks. We spoke with Handy about why you'd even want to run a Java application in a container and the recent updates in Java 10 that aim to reduce the challenges that come with CPU and memory usage when Java runs in a container. Then, later in the show, we previewed O'Reilly's open source conference, OSCON, which is back in Portland this year. TNS editor-in-chief Alex Williams and I will be at OSCON next week, attending sessions and talking to folks on the ground. We spoke about what we're looking forward to at that event. And you can catch our livestream on The New Stack Founder Alex Williams's Twitter feed (@alexwilliams), next Tuesday and Wednesday.

Apple comments on erroneous reports of iPhone brute force passcode hack, XSS, in Google Colaboratory + CSP bypass, how to deploy to Azure with Docker & VS Code, and debugging JavaScript in Google Chrome and Visual Studio Code. Full Show Notes: https://wiki.securityweekly.com/ASW_Episode21 Follow us on Twitter: https://www.twitter.com/securityweekly

Apple comments on erroneous reports of iPhone brute force passcode hack, XSS, in Google Colaboratory + CSP bypass, how to deploy to Azure with Docker & VS Code, and debugging JavaScript in Google Chrome and Visual Studio Code. Full Show Notes: https://wiki.securityweekly.com/ASW_Episode21 Follow us on Twitter: https://www.twitter.com/securityweekly

Aaron and Tyler Britten talk with Liz Rice (@lizrice, Technology Evangelist @AquaSecTeam) about what's easy—and what's not—about finding and patching security vulnerabilities in containers. This is a cross-over show with @PodCTL podcast. Show Links: Liz’s talk at Velocity Conf - “What’s so hard about container vulnerability scanning?” Use code "CLOUD" to get 20% off Velocity and OSCON Conference Passes Aqua Security Homepage Liz Rice’s Blog [Video] Kubernetes, Metadata and You (KubeCon 2017 Austin) [PODCAST] @PodCTL - Containers | Kubernetes | OpenShift - RSS Feed, iTunes, Google Play, Stitcher, TuneIn and all your favorite podcast players [A CLOUD GURU] Get The Cloudcast Alexa Skill [A CLOUD GURU] A Cloud Guru Membership - Start your free trial. Unlimited access to the best cloud training and new series to keep you up-to-date on all things AWS. [A CLOUD GURU] FREE access to AWS Certification Exam Prep Guide - At A Cloud Guru, the #1 question received from students is "I want to pass the AWS cert exam, so where do I start?" This course is your answer. [FREE] eBook from O'Reilly Show Notes Topic 1 - Welcome to the show Liz. Tell us a little bit about your background and the types of things that you’re working on these days. Topic 2 - Let’s start with the basics. A container is defined by a file (e.g. Dockerfile) that the user/developer/operator defines. How can a vulnerability get into that file? Topic 3 - Is it up to the CI/CD system or  host OS (where the container runs) or container orchestrator (e.g. Kubernetes) or container registry to figure out if a vulnerability exists? Topic 4 - How do most container registries today manage vulnerability lists, container scanning and potential mitigations? What are the difficult parts of those tasks? Topic 5 - Most containers today are Linux containers. Are you seeing anything happening (yet) around how to manage Windows containers vulnerabilities? Is the assumption that Microsoft will fix this through one of their existing tools, or are things happening in the open source community as well? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet and @ServerlessCast

Show: 32Show Overview:Tyler and Aaron Delp talk with Liz Rice (@lizrice, Technology Evangelist @AquaSecTeam) about what's easy—and what's not—about finding and patching security vulnerabilities in containers. This is a cross-over show with @TheCloudcastNet podcast. Show Notes:Liz’s talk at Velocity Conf - “What’s so hard about container vulnerability scanning?”Use code CLOUD to get 20% off Velocity or OSCON ticketsAqua Security HomepageLiz Rice’s Blog[Video] Kubernetes, Metadata and You (KubeCon 2017 Austin)Topic 1 - Welcome to the show Liz. Tell us a little bit about your background and the types of things that you’re working on these days.Topic 2 - Let’s start with the basics. A container is defined by a file (e.g. Dockerfile) that the user/developer/operator defines. How can a vulnerability get into that file?Topic 3 - Is it up to the CI/CD system or host OS (where the container runs) or container orchestrator (e.g. Kubernetes) or container registry to figure out if a vulnerability exists?Topic 4 - How do most container registries today manage vulnerability lists, container scanning and potential mitigations? What are the difficult parts of those tasks?Topic 5 - Most containers today are Linux containers. Are you seeing anything happening (yet) around how to manage Windows containers vulnerabilities? Is the assumption that Microsoft will fix this through one of their existing tools, or are things happening in the open source community as well? Feedback?Email: PodCTL at gmail dot comTwitter: @PodCTL Web: http://podctl.com

Show: 22Show Overview: Brian talks with Taylor Thomas (@_oftaylor, Software Engineer at Nike, @HelmPack Maintainer) about the architecture of Helm, how developers interact with it to deploy applications, how Helm manages ALM, Helm Summit, and the future plans for Helm v3. Show Notes:Helm (homepage)Helm - Kubernetes Package ManagerHelm Charts - https://github.com/kubernetes/chartsKubeApps - Online Repository of Helm ChartsGetting Started with Helm on OpenShiftHelm SummitHelm Emeritus Core Maintainers“Highway to Helm” (Introduction video)Topic 1 - Welcome to the show. Let’s talk about your background prior to getting involved in the Helm community, as well as where you’re focused on with Helm these days.Topic 2 - For someone that might only be familiar with docker containers (e.g. a DockerFile), give us the basics of what Helm does and the various pieces involved with using Helm (e.g. Helm, Helm Charts, Tiller, Kubernetes).Topic 3 - Helm is like a blueprint of how you want your containers / application to run. Can you walk us through what else is built into Helm to give it the ability to do Application Lifecycle Management? (versioning, updates, rollback, deletion, etc.)Topic 4 - Kubernetes can have a lot of different deployment models (stateful, stateless, jobs, batch, custom-resources, etc.). Does Helm have awareness of all of these models?Topic 5 - What are some of the common tools and patterns you’re seeing around using Helm (CI/CD pipelines, multicloud deployments, etc.)?Feedback?Email: PodCTL at gmail dot comTwitter: @PodCTL Web: http://podctl.com

Due to a variety of circumstances (including the move to Libsyn for hosting), this episode is being posted late. It was originally recorded in September, 2017. In this episode, Kito, Danno, and Ian discuss the Equifax hack (caused by an unpatched version of Struts), news from the Polymer Summit, Oracle’s donation of Java EE to Eclipse, Docker in-depth, and more. UI Tier Equifax hack: Using Struts and they did not patch. https://arstechnica.com/information-technology/2017/09/massive-equifax-breach-caused-by-failure-to-patch-two-month-old-bug/ https://www.rapid7.com/db/vulnerabilities/apache-struts-cve-2017-5638 Resolution 1:  https://struts.apache.org/docs/s2-045.html Resolution 2:  https://struts.apache.org/docs/s2-046.html Polymer 3 Announced - Move to NPM and ES6 Ionic releases Stencil - Web Components Compiler PrimeReact 1.0.0-Final Released Java EE Oracle donates Java EE to Eclipse Foundation Microprofile.io - Standard for Java EE-based microservices Vavr.io - functional library for Java 8/9  Other Docker First impressions Key concepts: containers, images, volumes, networks, stacks, swarm, nodes Docker CE vs EE Cost savings, efficiency, ease of use Tools, tools, tools (compose, docker-machine, docker CLI, Docker for Mac, Kitematic, Docker Cloud, Docker Hub, orchestration tools (Kubernetes, Docker Swarm), IDE integration (Eclipse Docker support, Webstorm Docker tooling) Deploying docker in the cloud (EC2, MS Azure, DigitalOcean) Docker for developers Dockerfile, base images, installing Java, database, web server, stacks, compose files, local swarm Docker in production Scaling a service, private Docker registry (on Nexus), swarm mode Docker gotchas Persistent data in the cloud Swarm mode overlay networking Development environment host VM cache Zombie processes (TINI) Docker releases Current stable: 17.07.0-ce Edge channel Picks Nozbe - task management Events Devoxx - November 6-12th, Antwerp, Belgium RVA JavaScript Conf 2017 - November 3rd, Richmond, VA, USA No Fluff Just Stuff Minneapolis October 20 - 21, 2017    

This week Dave talks with Jeremy Eder about blockchain, Hyperledger, OpenShift Blockchain, and more! I spent all my profits on new fans. Blockchain Hyperledger Ethereum Used for ‘First’ Paid Energy Trade Using Blockchain Tech OpenShift Blockchain Initiative Cutting Room Floor The Rise and Rise of Bitcoin (Unprofitably) mine Litecoin using a RHEL 7 container # # Dockerfile for cpuminer # usage: docker run creack/cpuminer --url xxxx --user xxxx --pass xxxx # ex: docker run creack/cpuminer --url stratum+tcp://ltc.pool.com:80 --user creack.worker1 --pass abcdef # # FROM         rhel7 MAINTAINER   David Egts RUN          yum -y update && yum -y install git automake gcc make curl-devel RUN          git clone https://github.com/pooler/cpuminer RUN          cd cpuminer && ./autogen.sh && ./configure CFLAGS="-O3" && make WORKDIR      /cpuminer ENTRYPOINT   ["./minerd"] We Give Thanks Jeremy Eder for getting us all blockchained up!

Новости Что новенького в Puppet 4 Конструктивная критика Dockerfile Приложение 12 факторов на русском Hypervisor-agnostic Docker Engine Dockramp DevOps team topologies distributed operating systems evolution or revolution Инфраструктура как код практически невозможна Лошадки, а не единороги Новое в hashi stack Nomand и Otto Еще один контейнер: LXD, неплохое объяснение, что же это такое Hangops про Hashconf, otto, nomad и Hashicorp Ближайший DevOps митап в Москве 14 октября У нас в гостях Роман Гущин и Евгений Килимчук Репозиторий Porto Репозиторий Smart (rt-scheduler) LinkedIn Романа LinkedIn Евгения

伊藤直也さん, 宮下剛輔さんをゲストに迎えて、Docker, chef, serverspec, Travis CI, Vagrant, サーバプロビジョニング、テスト などについて話しました。 Show Notes Docker LXC Linux Containers aufs Inside Sqale backend Heroku Cedar Stack Dokku Heroku Buildpacks Dockerfile miyagawa/docker-plenv-vanilla Vagrant serverspec Food fight show Test-Driven infrastrcture with Chef Test Kitchen ansible sunzi CloudFoundry lleval autodoc WEB+DB PRESS Vol.75