DEV Community: Yuta Miyama

One week SRE transition crash course

Yuta Miyama — Mon, 21 Mar 2022 07:05:52 +0000

This is my story. I’ve been developing various web applications for the past 5 years. Size and domain vary, but most of the time, my primary responsibility is to “ship features”.

Just at the beginning of this month, I transitioned into SRE (Site Reliability Engineer) role. The terminology and its practice were popularized by Google - https://sre.google/ I won’t try to explain what’s already best explained by them.

This blog is to share how my first week went.

I thought I could give u*nique insights into how a seasoned software developer can quickly ramp up himself when changing the course of his career*.

Can this happen in ONE WEEK?

How product developers can lose sight of a system’s runtime

First of all, a bit of justification on why this transition is not a trivial one.

Having been a web application engineer for some time, my focus has been mostly around the codebase; the static snapshot of the system without deep-dive into the runtime.

I’m not saying I didn’t pay attention to where the code is deployed, how to monitor them, etc. My point is that my “most important priority” has been to come up with a scalable “domain model” that’s separated from the underlying system.

Divide enables focus, takes away the holistic understanding.

This tendency is exacerbated by having worked for a bigger company.

What I code, will be deployed to some virtual machine owned by Tier 1 Cloud providers. They have their own abstractions on these machines. This is not inherent to the big companies, but due to the sheer scale of the system, new failure patterns emerge from the distributed architecture.

This is one of the reasons why I need to give myself a ramp-up time, to familiarize myself with the runtime.

Feature shipping mentality

There’s another, much more significant reason why this transition is hard.

In a company with more than thousands of employees, often times the department to own the “feature shipping speed” is different from the department which owns the Core SLOs (Service Level Objectives) of the underlying component. I won’t debate if that’s a good thing or not. This separation certainly enables the concentration and focus of each developer.

However, this has a hidden cost. If you develop too much of a “feature shipping mentality”, you might be cutting a scope that’ll actually save your day when the release happens.

Don’t just ship code. Duh.

Three steps to start your SRE journey

Enough about the background. Below are the three steps I discovered, to maximize the “throughput” of my learning.

1. Pick up the terminology

At this stage, focus on the two things:

What and how many layers of abstractions are there to deal with?
What are the rough dependencies (topology) of each runtime, at various layers of abstractions?

One thing I find amusing is that libraries meant for infrastructure (non-end-user facing in general) sometimes have wild names I have no idea what it’s doing.

It’s not straightforward to unpack these random terminologies. In order not to get lost in its randomness, pay attention to the explanation by its layers.

2. Put yourself in the shoes of the incident responder.

Once your SRE life begins, you'll be paged for a wide variety of things; its breadth and depth vary significantly.

It's almost certain that nobody can prepare for all the possible causes. Then, the question becomes:

What is the “incident lifecycle” you can generalize? (Detection, Early impact assessment, offending component identification, …) use your own words so that the learnings stick to your brain.
In each stage of the incident unfolding, what’s the focus you have to have? Depending on the size/domain of your role, you might be wearing different hats during the lifecycle of an incident.

3. Know ways to keep filling the gaps

Finally, as it was the same for application development, nothing is set in stone. Industry’s practice, tooling, and even preferred incident response communication strategy might change.

Lean on others. Ask them what they find most useful when they started this journey.
Look for the industry's go-to books. Buy some to get you started, and buy some more for the reference you can use long-term.

Summary

In this article, I made an attempt to explain how one can transition himself to the SRE role. It turned out to be much more generic than I imagined. Though, I believe this is a good piece of advice 😇 Hope you find it useful too.

This article is written with Suiko, a note app that grows with your thoughts.

This article was first drafted using a note app called “Suiko”. If you’re interested in how to craft your writings, please join the app beta testing form below.

https://kenzan100.substack.com/p/ive-created-an-app-optimized-for

I’ve created an app optimized for drafting articles. On your smartphone.

Yuta Miyama — Sat, 19 Feb 2022 11:51:03 +0000

(Originally written in https://kenzan100.substack.com/)

Hello! Let me share an app I’ve created, for drafting articles with ease.

I’m calling for alpha testers, who’d like to give this app a try. If you’re interested, please contact me via this Google Form.

First. On the difficulty of writing long, quality sentences.

Usually, I have many fragmented thoughts in my head; some are potentially good, some are probably bad that doesn’t lead anywhere :)

The problem, is I don’t know which one is which.

For me, the only way to tell between these two, is to “put it out there” for others to read. Only when I write them with the audience in mind, I can test the texts to its potential.

Now, the question becomes how to cross that chasm. I need some amount of momentum and continuity to keep crossing the chasm. Make it “good enough” for others to at least make sense of what I’m trying to say.

There’s a sharp “cliff” between the random thoughts that only exist in my head, and the carefully crafted sentences that convey the points of these ideas.

Why it is difficult to form an article

When I think about this, I think about a journey any thought takes. From a rough, raw idea that’s in your brain, into a sequence of sentences that forms a logic:

Let’s dissect this into the three stages of content transformation.

First, the thoughts are born in your mind, and they resemble a structure of a graph network. Thoughts, ideas, and concepts have some “links” in between, but their significance might not be apparent at this stage.
Then, with the right “saturation” of these graph nodes and links, some of them will start to form into a set of “outlines”.
Finally, some parts of the outlines will be extracted into a series of sentences tailored for the audience; the version you think is good enough to put it out there.

Unsurprisingly, there’re already apps that fit each stage of this journey:

Roam Research, Obsidian
Dynalist, Workflowly
Words-like software

There’re even some apps that cover the multiple (or all) stages of this journey: Notion, Markdown editors, or even a suite of Google Documents/Spreadsheets might do it.

Many failed attempts to complete the journey of words transformation

I have a track record of trying out as many note-taking apps I could do. When I look at my past creation in each one of these apps, I see many failed attempts of forming a consistent habit.

Most of the time, I leave these tools with some unfinished thoughts, unable to push them to cross the line of publishing them. Why did these texts not make it out there?

Many failed attempts that I don’t feel like adding more

I see two reasons (out of potentially many) here.

Most of the tools are promising too much, becoming too powerful, too complicated.
Consequently, they’ll force you the mindset of “organizing the past texts” before you can start writing new ones.

Even as simple as Apple native note app, I would feel compelled to look at what I’ve written in the past, when starting the app.

I want something, that doesn’t force me into thinking “I have to organize these texts”. I do want to find them “eventually” when the time is right. But that shouldn’t be the first action I need to take in the platform.

In Japanese, this reminds me of a concept called “発酵” (fermentation process). You could translate it as “sleep on the ideas”. You want to forget them, let them stay where they are, how they are. Unless you actively seek for them to come back to it.

I’m making a tool exactly for that. A simple, intuitive tool to make you do the following two things very well.

A blank inbox to start writing random texts. It’s your dumping ground of anything that comes across your brain.
Carefully crafted set of UX to edit, organize, and grow them sometime later.

If the tool can do these two things extremely well, I believe that’s all what I need to cross that chasm. I can finally start publishing my thoughts into the wild. And maybe more importantly, I can finally be ease with my writing, fully knowing that some will never see the light. and That’s OK.

I’ve turned this process into an app (iOS, Android, and the Web app)

First, every screen starts with a blank slate of a text box.

First Screen of the App

The basic idea here is that your past sentences should never be the distraction of the texts you’re about to produce. Taking advantage of this “blank slate everytime”, you’re safe to start dumping what’s fresh in your mind.

After that, you’re taken into an editing screen, that you can extend the text with “pluses” and “reorder handles”.

Editing Screen with “+” and “reorder handles”

The process of turning the random thoughts to the outlining, requires a carefully selected set of tools to assist you in the journey.

This is the part I’m actively developing right now. This is where you come in! Each month, I add many features, talk to the alpha testers, then discard some.

What I’m aiming, is to create a “sharp knife for texts editing”; it should have a few set of Editing UX that’s just enough to form the structure of your article. Fast and intuitive.

Eventually, some texts will find its aim; a meaningful structure that delivers the points it wants to make.

Publish it to anywhere you’d like

From there, it’s totally up to you. I only publish maybe one out of ten articles (posts) I create in this app.

That’s perfectly ok for me. Every word I’ve dumped in this playground must have had its purpose at the time of writing. Maybe it will in the future, too.

Some of them, will make it to some blogging platforms I use; Medium, Dev.to, or maybe your own hosted blog sites.

The app is totally unopinionated on how you’ll use the drafts in the end

Would you like to give this app a try?

I’m currently in the process of recruiting early testers, to give me feedback on the direction of the app. If you’d like to try this out, please fill out the following simple form to say hi!

Google Form for Early Testers

I’ve had some success inviting alpha testers from Japanese audience. Now, I’d like to receive more feedback worldwide.

No matter what, let’s keep writing! Your words are worth sharing.

Say Hi on Twitter

Happy Writing!

Line by line explanation of Ruby 3 Ractor - worker pool implementation

Yuta Miyama — Mon, 31 May 2021 18:02:17 +0000

Ruby 3 has an exciting update about its concurrency support: Ractors.

First, please read https://github.com/ruby/ruby/blob/master/doc/ractor.md for "What it is" and "What it can do".

If you're trying to achieve some sort of concurrent programming and ❤️ Ruby language, you should definitely give it a try.

Worker pool's implementation in Ractor

Below's the copy of the code explained in Ractor's official documentation. It's slightly modified to provide more granular explanation on its behaviour.

I've also annotated the code heavily, so that you can read the intent of each line with me.

Let's decipher this line by line, so that you can properly assess what you can do with Ractor.

For the basic API of Ractor, please refer to https://ruby-doc.org/core-3.0.0/Ractor.html

Code with line-by-line explanation

# This example computes if the given numbers is a prime number or not, using 10 parallel workers. 

# to make `num.prime?` possible.
require 'prime'

# this ractor will keep listening to the sent messages, and yield them to whomever want to take the value.
pipe = Ractor.new do
  loop do
    Ractor.yield Ractor.receive
  end
end

# Let's check the prime numbers from 1 upto 1000
N = 1000
# we'll use 10 workers to do this work.
RN = 10
# worker ractors initialization.
# each worker ractor takes pipe as its sharable object (Ractor has some synchronization mechanism according to [this doc](https://github.com/ruby/ruby/blob/master/doc/ractor.md#shareable-objects)) 
# then, each worker Ractor reads the input through the pipe (multiplexing) to utilize 10 workers
workers = (1..RN).map.with_index do |i|
  Ractor.new pipe, i do |pipe, i|
    # Ractor#take is a blocking call, and waits till pipe yields something
    while n = pipe.take
      # Worker, then in turn, computes something (expensive :) and yields to whomever willing to listen to this ractor
      Ractor.yield ["worker ##{i}}", n, n.prime?]
    end
  end
end

# sending 1000 numbers to the pipe, worker ractors are ready to consume by now.
(1..N).each{|i|
  pipe << i
}

# main process (main process itself is a running Ractor) calls
# Ractor#select, which can listen to a list of ractors
# because it's called (1..N) times, it'll hit all of the computed values by the time pp prints them.
pp (1..N).map{
  _r, (wid, n, b) = Ractor.select(*workers)
  [wid, n, b]
}.sort_by{|(wid, n, b)| n}

Conclusion

I hope this illustration together with https://github.com/ruby/ruby/blob/master/doc/ractor.md has given you a better understanding of what you can do with Ractor.

In my opinion, Ruby finally providing basic primitives for doing actor based concurrency is very exciting.

You won't have to focus too much on the performance gain, or even the current status of all the APIs (they explicitly state its an experimental feature, as of Ruby 3.0.1).

still, I'm confident that we can already start learning how to write distributed systems all within the favourite language of our choice :)

I hope you'll dig a bit deeper by yourself, as well! Happy coding 🙌

Make an original io game in 5 days

Yuta Miyama — Fri, 01 Jan 2021 18:02:33 +0000

I've used my holiday break to make an original .io game from scratch. It took me 5 days.

Here, I'll share how you can do the same.

Why?

Cuz it's my passion.

Before I ventured into a software development career, I used to make a physical card game that teaches kids about environmental issues.

I poured my soul into that game, and I've wanted to make more games ever since.

Cuz online game dev has so much learning potential.

Take a look at the above image (from MDN game dev web page).

As you can see, it has so many surface areas that you can dig into.

Being a good software developer is all about being a constant learner. This excites me.

What's in it for you?

Have you imagined yourself as a game developer someday ? You know how to program something, but you aren't really sure how to start as a game developer?

This tutorial serves as yet another article to give you that push to finally start making your own game.

Target Audience

I'm assuming that you have a little bit of programming experience already. When I describe the steps in specific terms, I expect you to be able to "Google it" for supplementary knowledge.

But don't worry.
I've also provided the commit by commit instruction in each step. When you're lost in the instruction, look at the code diff to make sure you're on track.

The game I made
Part1: Make a local development environment (Day1)
Part2: Design the game elements (Day2, Day3)
Part3: Adjust the elements to a "playable" state(Day4, Day5)
Takeaways

The game I made

It's like a 2D tank game, where you'll navigate your character to beat an opponent's character. But there's one twist.

You'll have to play "Rock Paper Scissors" when you collide with opponents. So you'll need to be creative on how to adjust each character's "shape" before they collide.

You can play the game via this link. It might take a few seconds before it boots.

Part1: Make a local development environment (Day1)

First of all, let's focus on making a foundation for a local development environment.

(Make sure you have a Node.js on your machine. I'm using MacBook + Homebrew)

Part1-1: Build HTML/JS via Webpack

Grab your favorite package manager. NPM should be fine, but I like Yarn more.
Install Webpack for your project directory. Again, you can pick alternatives if you know what you're doing :)
Create a JS/HTML template to conform to the Webpack build cycle.
Try running your build, e.g. yarn webpack --watch
Access the file to see your progress. e.g. open dist/index.html

This commit represents the progress so far.

You should be able to see some messages on console + HTML.

Part1-2: Draw something on canvas

Next, let's make sure you'll be able to draw/manipulate objects using the HTML canvas element. I've used this tutorial to get familiar with the basics.

Draw a circle on the canvas.
Add an event listener to the keydown event.
Write a JS "game loop" function so that the drawing happens continuously as you move the circle.
Assign dynamic coordinates(x, y) to the "draw circle" function so that that cursor keys can move the circle.

This commit represents this part of progress.

Yay! your circle should be moving as you press your cursor keys :)

Part1-3: Prepare web server

Finally, let's spin up a web server. This step prepares you for the next step, where you'll be moving your game state to the server-side.

Server-side dictating the game logic is crucial to provide a consistent online game experience.

To connect server-side logic with the user's input + rendering, we'll use a technology called WebSocket.

WebSocket enables efficient bi-directional messages between clients and servers.

Let's first set up "connections." Actual event implementations are explained in later steps.

Install and spin up Express web server.
Install and setup WebSocket connections between the server and the client, using a library called Socket.io.

This part of the commit looks like this.

Part2: Design the game elements (Day2, Day3)

So far, we've created the following components to as scaffolding to build games on.



1. HTML/JS + Webpack to build(package) them.
2. Canvas + EventListeners to render/interact with visual elements.
3. Express web server + WebSocket to establish bi-directional connections.

Recapping what we're building

It's useful to have a summary of what kind of game you're making at this stage. Below's my version:



Game Idea memo

<Game Objects>
- Player object: to move around in 2d canvas.
- "Rock Paper Scissors" Coins: to place in 2d canvas.


<Game Logic>
1. When the Player collides with Coins, the Player will change its shape to one of "Rock" / "Paper" / "Scissor."
2. The shape change is based on the maximum number of coins you've collected at a given moment.
3. When Players collide with each other, the actual "Rock Paper Scissor" game takes place. It uses the current shape of each player object.
4. Winner stays in the game. The loser is kicked out of the game. The last person to remain in the game wins all.

Let's build out the proof-of-concept, according to the game memo.

Part2-1: Translate the game logic to data models

One useful step is to translate the game logic described above to actual data models our server should use.

Don't try to be perfect. Pay attention to "what's the foundational properties each role has to have?". We can add more properties later as the game gets sophisticated.

I started my data model as the following:



{
  players: [
    { id: yuta, x: 0, y: 0 }, ...
  ],
  coins: [
    { kind: Rock, x: 10, y: 10 }, ...    
  ]
}

Pretty straightforward. The game has two arrays, with each object holds its x y coordinate. The coin has kind property to represent Rock/Paper/Scissor to have a different effect.

Separate game logic from rendering logic

To provide consistent/fair UX among players, we should express game logic on the server-side. The client-side (JS run in browsers) will only be responsible for two things: rendering the game state and sending user inputs to the server.

We can imagine this separation as a continuous cycle of inputs -> state change -> rendering -> next inputs.

Part2-2: Connect server-side logic to client-side rendering

First, let's tackle the part where the server sends data models to the client-side. For the above, it'll simulate the state transition -> rendering part.

Convert the data model to JS Objects. Put that in server-side JS.
Prepare server-side game-loop.
Have WebSocket send the data model as gameUpdates to clients.
Have clients output received data models.

This commit describes this part.

You should be able to see the circles at the coordinates/size defined on the server-side. 🎉

Part2-3: Connect client-side inputs to server-side logic

Next, let's express the other half of interaction: client inputs -> server state transition.

Bridge the user input eventListener to the WebSocket event.
Have the server-side update its data model by the inputs received from the client-side.
Change the static data model to the dynamic one.

The commit and the successful output is as follows:

Keep it up!

Congrats on making it this far! You already have 80% of the foundational code to make a 2D online game.

Part3: Adjust the elements to a "playable" state(Day4, Day5)

Now that we have most of the elements ready, how do we turn this into a "playable" game?

Let's come back to the game idea memo:



Game Idea memo

<Game Objects>
- Player object: to move around in 2d canvas.
- "Rock Paper Scissors" Coins: to place in 2d canvas.


<Game Logic>
1. When the Player collides with Coins, the Player will change its shape to one of "Rock" / "Paper" / "Scissor."
2. The shape change is based on the maximum number of coins you've collected at a given moment.
3. When Players collide with each other, the actual "Rock Paper Scissor" game takes place. It uses the current shape of each player object.
4. Winner stays in the game. The loser is kicked out of the game. The last person to remain in the game wins all.

Part3-1: Translate game logic to a player's story

It's important to tell a "game dynamics" from a user's point of view. From the moment a player joins a game, how does it progress? How does it end? Do they want to come back after one game ends?



<Player Story>
1. At the beginning, players start with the "Rock" state. At this point, colliding with each other means "tie": nothing happens.
2. As you move the object, you'll start placing some Rock Paper Scissors coins.
3. You'll watch out what state opponents are in. Depending on that, you'll either try to change your state to a winning one or change the opponent's state to a losing one.
4. When it's ready, tackle and collide with an opponent.
5. If won, you'll readjust your state so that you can keep winning with others.

Let's use this sample player story as a guide to build the rest.

Part3-2: Enable player-to-coin interaction

Let's address the part where each player's state changes by the coins collected so far.

Add state property to each player's data model. Rock:0, Paper:0, Scissor:0.
In the server-side game loop, make collision-detection happen between players and coins.
Change the state of the player object, depending on the sum of collected coins.
Have client-side JS express the state change (for now, I'll just change the colors).

The commit

It will look like this:

You might wonder why coins won't appear on the screen. This is because the coin you've just placed collides with the player "right away".

There are several ways to fix this, but I'll do it in the next steps.

Collision Detection? What?

It might sound intimidating at first, but good articles/libraries are already out there to support you on this topic.

See this article for a good introduction to the subject.

Part3-3: Enable player-to-player interaction

By reusing the player-to-coin interaction above, we can build a player-to-player interaction.

One key difference here is that the player-to-player interaction will produce a "Rock Paper Scissor" event to determine the winner of that collision.

Here, I'll introduce another data model called match to express this state.



match = { loser: webSocketID, winner: webSocketID }

This will enable rendering the win/lose result to the client-side.

Prepare a match data model to express a win/lose state.
Implement player-to-player collision detection (reusing the method implemented in the previous part).
Implement the rule of Rock Paper Scissors.
Fill in the match data model with the result and send it to the client-side.
Output the match result on the client-side (for now, it'll output to the console).

The commit is here

Part3-4: Replace rendering objects with actual game images

You're almost there! Let's replace the placeholder circles with Rock Paper Scissor images to communicate the game concept.

Prepare images for player objects, as well as coin objects.
Replace the circles with the images.
Ajudst the x y coordinate of images so that center of the image will point to the coordinate.

3rd step requires the knowledge of setTransform from Canvas API. There're many good articles out there to do this. MDN API doc is always a good start.

Sidenote: Delay the player-to-coin collision detection

Above, I've described player-to-coin collision happens right away, hiding the coin object from appearing on the screen.

I can think of several ways to solve this (A. Change the coin concept to "bullet," shooting them from your player's object. B. Place the coins a little bit in front of you, ...).

In this post, I've chosen the option to "delay" the collision detection so that you can use coins both for you and for other players.

I've added the placedAt property to do this. placedAt will express the elapsed time since coin placement. This enables the small gap before the coin starts interacting with player objects.

The commit

Part3-5: Complete one game cycle

As the last step, let's supplement the player story with basic instructions.

Think from the user's perspective. Users would know nothing about how your game works when they first see it.

Prepare a win/lose result text as HTML.
Show the result text when the match is decided between two players.
Implement "clean up" logic for the lost player. (Disconnect WebSocket connection, Stop rendering, Delete the server-side objects).
Prepare Game Rule section as another HTML content.

The commit

Below's the screenshot of result display (top: winner side. bottom: loser side).

Choose where to deploy your game

If your objective is to prototype a casual game, I'd recommend Heroku Node.js deployment. It is easy to use, and the free tier should be enough to showcase your work.

The result

Congratulations!

You've now completed the first full cycle of the game-making process.

Let's recap how far we've come by looking at the repository and its commit history.

Takeaways

Making a game itself is only half the outcome. Here're a few tips I've learned along the way:

1. Revisit the process as composable steps for the next game

Organize your commit and game elements so that you can reuse the patterns in the next game.

In this post, we've learned:

Canvas 2D rendering + key-based controls
Games that involve Collision Detection
Casual multiplayer online games (.io games)

Eventually, you'll build your own pattern of techniques + elements, making the process tailored for your creativity.

2. Look for relevant articles + people who are doing the same thing

MDN is always a high-quality resource for web-based technologies.

It's critical to find likely-minded people who are already doing the output of their work.

Victor Zhou's blog on How to build a .io game from scratch helped me tremendously on this.

Be careful not to be swamped by the sheer amount of articles you'll find on the Internet. Not everything is high-quality.

A good measurement on when to stop searching is, "have I collected enough keywords/terminologies to unblock myself?".

3. Do a lot of deliberate practice

This is true to any kind of learning. The Game-making process is no exception, as it is a lifelong journey to create a game that's fun and satisfying.

Focus on the learning topic one at a time. There're many relevant technologies (Audio, WebRTC, Network programming, ...) and game genres(RPG, action, puzzle, ...) you could try. Trying to learn many things at once will degrade the learning.

Don't focus too much on "How to make people play my game?". Focus on "How can I share the learning within the game-making process?"

The latter will get you to a network of like-minded people, which is sometimes more important than the game itself.

Feedback is welcome!

I'll now focus on making the next game. Please give me comments/feedback on what you've thought of the article.

My Twiter account is kenzan100. Please follow me if you've liked my content.

See you next time!

Did you know Ruby has resolv-replace?

Yuta Miyama — Sun, 13 Dec 2020 22:22:21 +0000

In Ruby, there's a library called resolv-replace.

This is a drop-in replacement (moneky patch) of libc DNS resolver Ruby's using under the hood. It'll use a pure Ruby implementation called Resolv.

The doc states the merit of Resolv as "Resolv can handle multiple DNS requests concurrently without blocking the entire Ruby interpreter". So ppl probably reach out to this when they want to improve the performance.

You can read how resolv-replace is patching a set of Ruby's stdlibc network calls at https://ruby-doc.org/stdlib-2.7.0/libdoc/resolv-replace/rdoc/index.html.

If you'd like more control on the DNS layer due to how your app's constructed, I'd recommend checking out this library.

Cover Photo by JJ Ying on Unsplash

Create a private RSS feed without paying a penny.

Yuta Miyama — Sun, 13 Sep 2020 15:19:39 +0000

Photo by Annie Spratt on Unsplash

Prerequisite

Steps

Upload your mp3/mp4 contents to Dropbox. Get a raw link by following this step.
Locally, follow this article to create an RSS file.
Commit your RSS file to your Github repo. Publish it as a Github page.
Make sure your RSS file path is valid with https://castfeedvalidator.com/. Some of the test results say warnings. As long as this is a private feed, you can ignore them.
Share the RSS file path to your community! Popular podcast apps (including Apple Podcast) have a way to import RSS URLs directly. Enjoy.

To be minimum, below worked. (The URL is no longer valid, as I was too embarrassed to keep it public).

<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:rawvoice="http://www.rawvoice.com/rawvoiceRssModule/" version="2.0">
    <channel>
        <title>Podcast Title Here</title>
        <link>https://www.example.com</link>
        <image>
            <url>http://www.example.com/image3000x3000.png</url>
            <title>Podcast Title Here</title>
            <link>https://www.example.com</link>
        </image>
        <description>
            The full length description for your podcast
        </description>
        <language>en-us</language>
        <copyright>Yuta copyright 2016</copyright>
        <item>
          <title>Episode Name 2</title>
          <link>https://dl.dropbox.com/s/dff56030336b/YourVideoAudioFile.mp4</link>
          <pubDate>Sat, 02 Jan 2020 16:00:00 PDT</pubDate>
          <description>The full length episode 2 description</description>
          <enclosure url="https://dl.dropbox.com/s/dff56030336b/YourVideoAudioFile.mp4" length="36715125" type="audio/mpeg"/>
          <guid>https://dl.dropbox.com/s/dff56030336b/YourVideoAudioFile.mp4</guid>
        </item>
    </channel>
</rss>

Misc TIL

I didn't know that .mov and .mp4 are compatible with great extent
I'm not sure how protective this feed URL will become, only by specifying robots.txt. Let me know your thoughts.
If you're more serious about your audience, consider paid / services
Finally, another link I stumbled upon along the way. Thank you Internet!

DEV Community: Yuta Miyama

One week SRE transition crash course

How product developers can lose sight of a system’s runtime

Feature shipping mentality

Three steps to start your SRE journey

1. Pick up the terminology

2. Put yourself in the shoes of the incident responder.

3. Know ways to keep filling the gaps

Summary

I’ve created an app optimized for drafting articles. On your smartphone.

First. On the difficulty of writing long, quality sentences.

Why it is difficult to form an article

Many failed attempts to complete the journey of words transformation

I’ve turned this process into an app (iOS, Android, and the Web app)

Publish it to anywhere you’d like

Would you like to give this app a try?

Line by line explanation of Ruby 3 Ractor - worker pool implementation

Worker pool's implementation in Ractor

Code with line-by-line explanation

Conclusion

Make an original io game in 5 days

Why?

Cuz it's my passion.

Cuz online game dev has so much learning potential.

What's in it for you?

Target Audience

Table of contents

The game I made

Part1: Make a local development environment (Day1)

Part1-1: Build HTML/JS via Webpack

Part1-2: Draw something on canvas

Part1-3: Prepare web server

Part2: Design the game elements (Day2, Day3)

Recapping what we're building

Part2-1: Translate the game logic to data models

Separate game logic from rendering logic

Part2-2: Connect server-side logic to client-side rendering

Part2-3: Connect client-side inputs to server-side logic

Keep it up!

Part3: Adjust the elements to a "playable" state(Day4, Day5)

Part3-1: Translate game logic to a player's story

Part3-2: Enable player-to-coin interaction

Collision Detection? What?

Part3-3: Enable player-to-player interaction

Part3-4: Replace rendering objects with actual game images

Sidenote: Delay the player-to-coin collision detection

Part3-5: Complete one game cycle

Choose where to deploy your game

The result

Takeaways

1. Revisit the process as composable steps for the next game

2. Look for relevant articles + people who are doing the same thing

3. Do a lot of deliberate practice

Feedback is welcome!

Did you know Ruby has resolv-replace?

Create a private RSS feed without paying a penny.

Prerequisite

Steps

Misc TIL