This is part 4 in a cool series on The New Stack exploring the Kubeflow machine learning platform.

I recently built a four-node bare metal Kubernetes cluster comprising CPU and GPU hosts for all my AI experiments. Though it makes economic sense to leverage the public cloud for provisioning the infrastructure, I invested a fortune in the AI testbed that’s within my line of sight.

The author shares many insights into the choices he made while building this dream setup.

Local network monitoring stack (forked from this project) that’s tailored to run on your Raspberry Pi.

Here’s a quick start to stand-up a Docker Prometheus stack containing Prometheus, Grafana with blackbox-exporter and speedtest-exporter to collect and graph home network connections and speed.

This week we’re talking with Daniel Stenberg about 23 years of curl. Daniel shares how curl came to be, what drives and motivates him, maintaining a good cadence of an open source product, what to expect from http3, how many billions of users curl has, and Daniel also shares some funny stories like the “Spotify and Instagram hacking ring.”

In this post, Tomas Wróbel lays out 10 potential drawbacks to the typical PR flows:

1. More long living branches, more merge conflicts
2. The reviewability of a change decreases with size
3. Short feedback loop makes programming fun
4. Reviews tend to be superficial
5. Merging is blocked by remarks that shouldn’t be blocking
6. It’s easier to fix than to explain the fix
7. Developers are slower to adapt the responsibility mindset
8. PRs discourage continuous refactoring
9. Negative emotions and outright pathology
10. How do you switch to branches with migrations

This is a nice, long list of landing page templates you can use for your next website. Right now it’s just a list of links, though. What would really make it useful is screengrabs of each template embedded right there in the README so you don’t have to click each link to get an idea of what it looks like. PRs welcome? 😎

The EFF launched a new site you can use to see if your Chrome install is one that Google is testing FLoC on.

Google is running a Chrome “origin trial” to test out an experimental new tracking feature called Federated Learning of Cohorts (aka “FLoC”). According to Google, the trial currently affects 0.5% of users in selected regions, including Australia, Brazil, Canada, India, Indonesia, Japan, Mexico, New Zealand, the Philippines, and the United States.

They also do a nice job describing exactly what FLoC is and what it might mean regarding your privacy online.

Yes, this joke has been made before, but I’m serious. In the same way that serverless lets backend developers “forget” about servers, what if “codeless” did the same, but for your application code.

In other words, what if API requests to your service included the code that the caller wants to be executed on the server?

Here is an example to help you understand the importance of cherry-picking. Suppose you have made several commits in a branch, but you realize it’s the wrong branch! What do you do now? Either you repeat all your changes in the correct branch and make a fresh commit, or you merge the branch into the correct branch. Wait, the former is too tedious, and you may not want to do the latter. So, is there a way? Yes, Git’s got you covered.

I’m a pretty big fan of cherry-pick, too. I don’t use it often, but every time I do… 👨‍🍳💋

Jerod and Nick discuss the big Deno news, play a ridiculous new game in honor of April Fool’s Day, then give shout outs to some awesome software projects we love.

At Channable we use Nix to build and deploy our services and to manage our development environments. This was not always the case: in the past we used a combination of ecosystem-specific tools and custom scripts to glue them together. Consolidating everything with Nix has helped us standardize development and deployment workflows, eliminate “works on my machine”-problems, and avoid unnecessary rebuilds. In this post we want to share what problems we encountered before adopting Nix, how Nix solves those, and how we gradually introduced Nix into our workflows.

If Nix is intriguing to you, you’re going to love an upcoming episode of The Changelog. 😉

Jose Valim (the creator of Elixir) recently asked developers from all programming languages to contribute a solution to a short coding challenge based on a real world use case that I had come up while building an Elixir application. Here’s what happened.

Testing can be hard, how to test, where to test, what is a good test? All questions that can be deceptively difficult to answer. In this episode we talk about the trials and tribulations of testing and why it can be argued to be especially difficult in Go.

This doesn’t aim to entirely replace find and ls, but if you already know SQL (like many of us do), why not be able to leverage that knowledge for your more advanced file-finding needs? Here’s a couple of examples so you get the idea:

Find temporary or config files (full path and size):

fselect size, path from /home/user where name = '*.cfg' or name = '*.tmp'

Use aggregate functions:

fselect "MIN(size), MAX(size), AVG(size), SUM(size), COUNT(*) from /home/user/Downloads"

Find by date and time intervals:

fselect path from /home/user where modified gte 2017-05-01

Karoy Lorentey with the announcement:

The Swift Standard Library currently implements the three most essential general-purpose data structures: Array, Set and Dictionary. These are the right tool for a wide variety of use cases, and they are particularly well-suited for use as currency types. But sometimes, in order to efficiently solve a problem or to maintain an invariant, Swift programmers would benefit from a larger library of data structures.

We expect the Collections package to empower you to write faster and more reliable programs, with less effort.

This joins the Swift Algorithms and Swift Numerics packages in what is becoming a valuable, open source resource for Swift developers around the world to use.

Nikola Mrkšić, CEO & Co-Founder of PolyAI, takes Daniel and Chris on a deep dive into conversational AI, describing the underlying technologies, and teaching them about the next generation of voice assistants that will be capable of handling true human-level conversations. It’s an episode you’ll be talking about for a long time!

geared towards building search systems for any kind of data, including text, images, audio, video and many more. With the modular design & multi-layer abstraction, you can leverage the efficient patterns to build the system by parts, or chaining them into a Flow for an end-to-end experience.

Congrats to the entire Crystal team and community on the big One O!

Crystal, a new object-oriented, compiled systems programming language that aims to blend the conciseness and friendliness of Ruby with the efficiency of C, recently released its first major version. Crystal 1.0 has a syntax close to Ruby’s and features statically inferred types, C bindings, and macros. Crystal may attract developers with a Ruby/Rails, Elixir/Phoenix background.

This has been a long time in the making. Can you believe it’s been five years since we had Ary and Juan on The Changelog? On that episode we discussed what it would take to get Crystal to 1.0…

We have to stop insisting that software updates, etc. need to be distributed over HTTPS. Let me tell you why this is not an ideal way of going about it.

This week we’re joined by long-time web developer Matt Patterson. Earlier this year Matt wrote an evocative article for A List Apart called The Future of Web Software Is HTML-over-WebSockets. In this episode Matt sits down with Jerod to discuss, in-detail, why he believes the future of the web is server-rendered (again) and how Ruby on Rails is well positioned to bring that future to us today.

In a copyright decision that will undoubtedly have ripple effects on the software industry for years to come, the Supreme Court of the United States held that:

Google’s copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law.

This quote pulled from the linked opinion by a hacker news commenter drives right in to the heart of the matter:

“Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.”