<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Caleb Hearth</title>
    <description>The latest articles on DEV Community by Caleb Hearth (@calebhearth).</description>
    <link>https://dev.to/calebhearth</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F58978%2F6e8639be-fda1-41be-831d-93478e9c874d.jpeg</url>
      <title>DEV Community: Caleb Hearth</title>
      <link>https://dev.to/calebhearth</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/calebhearth"/>
    <language>en</language>
    <item>
      <title>Tell GitHub to Render Markdown Pages with .gitattributes</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Fri, 22 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/tell-github-to-render-markdown-pages-with-gitattributes-5432</link>
      <guid>https://dev.to/calebhearth/tell-github-to-render-markdown-pages-with-gitattributes-5432</guid>
      <description>&lt;p&gt;Articles on Hearthside are written in Markdown (GitHub-flavored), but the file extension is &lt;code&gt;.md.yaml&lt;/code&gt; as they also make use of Jekyll-style front matter. My &lt;a href="https://github.com/calebhearth/frontmatter" rel="noopener noreferrer"&gt;Frontmatter gem&lt;/a&gt; requires that files it handles end in &lt;code&gt;.yaml&lt;/code&gt; or &lt;code&gt;.yml&lt;/code&gt;, so this is necessary.&lt;/p&gt;

&lt;p&gt;Because of the file extension, GitHub until this week did not render the Markdown correctly. Instead articles have been highlighted if they were written in YAML completely, which really messes up the Syntax highlighting even beyond not giving a rendered preview.&lt;/p&gt;

&lt;p&gt;I’m not sure why I never thought to look into it in the last several years of writing this way, but it turns out that you can tell GitHub’s Linguist tool what type of language a file type should match, so to do that I added this to my project’s &lt;code&gt;.gitattributes&lt;/code&gt;:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;*.md.y*ml linguist-language=markdown 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;a href="https://calebhearth.com/dt/github-linguist" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>github</category>
      <category>markdown</category>
      <category>frontmatter</category>
    </item>
    <item>
      <title>Oxtail, and more Cooklang Exploration</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Thu, 21 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/oxtail-and-more-cooklang-exploration-54mb</link>
      <guid>https://dev.to/calebhearth/oxtail-and-more-cooklang-exploration-54mb</guid>
      <description>&lt;p&gt;After &lt;a href="https://calebhearth.com/dt/oat-notes" rel="noopener noreferrer"&gt;yesterday’s post&lt;/a&gt;, it was time to finally try to handle a blog post and Cooklang recipe in one file. The solution to how to format things was simple: inline the recipe in a Markdown code fence and pre-process it. The file looks like:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt; --- [yaml frontmatter] --- [markdown intro] ```

cooklang [cooklang recipe]

 ``` [markdown outro] 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;The code to do it is ugly and relies on a Regular Expression&lt;sup id="fnref:regex"&gt;&lt;a href="https://calebhearth.com/dt/oxtail#fn:regex" rel="footnote noopener noreferrer"&gt;1&lt;/a&gt;&lt;/sup&gt;, &lt;a href="https://cooklang.org/cli/" rel="noopener noreferrer"&gt;CookCLI&lt;/a&gt; to generate some JSON that I use to render a partial during the view render. I didn’t bother building a nice data object, so I’m using a mess of &lt;code&gt;{}.dig&lt;/code&gt; and &lt;code&gt;case / in / else&lt;/code&gt; pattern-matching statements to generate the markup. It does properly handle marking up the recipe with the h-recipe microformat, so that’s a win. See below for Rails partial&lt;sup id="fnref:partial"&gt;&lt;a href="https://calebhearth.com/dt/oxtail#fn:partial" rel="footnote noopener noreferrer"&gt;2&lt;/a&gt;&lt;/sup&gt;.&lt;/p&gt;

&lt;p&gt;As you’ll see, the CLI doesn’t handle combining ingredients of the same name to amounts, and it isn’t able to parse ingredient aliases or comments. I’ll probably open an issue on the project’s &lt;a href="https://github.com/cooklang/cooklang-cli" rel="noopener noreferrer"&gt;GitHub repo&lt;/a&gt;, but ultimately it looks like the &lt;a href="https://github.com/cooklang/cooklang-rs" rel="noopener noreferrer"&gt;rust&lt;/a&gt; tool is the way to go.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/oxtail" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>nablopomo</category>
      <category>recipe</category>
      <category>nablopomo2024</category>
      <category>cooklang</category>
    </item>
    <item>
      <title>How I Model SwiftUI Views</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Tue, 19 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/how-i-model-swiftui-views-2jkp</link>
      <guid>https://dev.to/calebhearth/how-i-model-swiftui-views-2jkp</guid>
      <description>&lt;p&gt;The approach I take to defining ViewModels for SwiftUI was heavily inspired by Paul Hudson’s post &lt;a href="https://www.hackingwithswift.com/books/ios-swiftui/introducing-mvvm-into-your-swiftui-project" rel="noopener noreferrer"&gt;Introducing MVVM into your SwiftUI project&lt;/a&gt;. In it, he advocates for defining &lt;code&gt;class ViewModel&lt;/code&gt; inside an extension to the relevant view. By naming each view’s MVVM class &lt;code&gt;ViewModel&lt;/code&gt;, it can always be referenced directly by that name instead of remembering to use &lt;code&gt;ContentViewViewModel&lt;/code&gt;, &lt;code&gt;UserListViewModel&lt;/code&gt;, etc. I take it a step further and simply name the class &lt;code&gt;Model&lt;/code&gt;:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight swift"&gt;&lt;code&gt;&lt;span class="kd"&gt;import&lt;/span&gt; &lt;span class="kt"&gt;SwiftUICore&lt;/span&gt;

&lt;span class="kd"&gt;extension&lt;/span&gt; &lt;span class="kt"&gt;ContentView&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
 &lt;span class="kd"&gt;@MainActor&lt;/span&gt; &lt;span class="kd"&gt;@Observable&lt;/span&gt; &lt;span class="kd"&gt;class&lt;/span&gt; &lt;span class="kt"&gt;Model&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="c1"&gt;// properties and functions&lt;/span&gt;
  &lt;span class="p"&gt;}&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt; 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;And each view has an instance of its ViewModel, and hopefully nothing else.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;struct ContentView: View {
  @State private var model: Model = .init()
} 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;In practice, useful property wrappers like &lt;code&gt;@Binding&lt;/code&gt; or &lt;code&gt;@Environment&lt;/code&gt; will get hoisted into the view. I’ve also had absolutely zero luck incorporating this fully with SwiftData. In theory you can build your own &lt;code&gt;Query&lt;/code&gt; with &lt;code&gt;Predicate&amp;lt;PersistentModel&amp;gt;&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/how-i-model-views" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>nablopomo</category>
      <category>swift</category>
      <category>swiftui</category>
      <category>mvvm</category>
    </item>
    <item>
      <title>Truncate Date to Calendar.Component in Swift</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Mon, 18 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/truncate-date-to-calendarcomponent-in-swift-2465</link>
      <guid>https://dev.to/calebhearth/truncate-date-to-calendarcomponent-in-swift-2465</guid>
      <description>&lt;p&gt;I’m frequently wanting to work with truncated dates in Swift apps, especially when dealing with Swift Charts. Foundation provides &lt;code&gt;Calendar.startOfDay(for:)&lt;/code&gt; to get the first moment of a day, and that’s been really useful. The extension below will do something similar for an arbitrary&lt;sup id="fnref:sorta"&gt;1&lt;/sup&gt; &lt;code&gt;Calendar.Component&lt;/code&gt; to truncate that date to the first moment of that component.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;extension Date { /// Returns the first moment of a given Calendar.Component, as a Date. /// /// For example, pass in `.hour` called on `Date()`, if you want the start of /// the current hour of the current day. /// Supported Calendar.Components are .year, .month, .day, .hour, .minute, /// .second. Passing an unsupported component will cause `self` to be returned /// unchanged. /// Calling `.start(of: .day)` is equivalent to calling `.startOfDay`. /// - parameter to: The smallest component you want /// - returns: The first moment of the given date. func start(of component: Calendar.Component) -&amp;gt; Date { let allComponents =...
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;a href="https://calebhearth.com/dt/swift-truncate-date" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>swift</category>
      <category>nablopomo2024</category>
    </item>
    <item>
      <title>Using Starship for the Same Prompt, but Faster</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Fri, 15 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/using-starship-for-the-same-prompt-but-faster-5epo</link>
      <guid>https://dev.to/calebhearth/using-starship-for-the-same-prompt-but-faster-5epo</guid>
      <description>&lt;p&gt;Starship is a highly-configurable, cross-shell prompt. I recently switched to using it and it sped up my prompt rendering from being noticably slow and taking probably half a second to render to an imperceptible 0.03s rendering time. It actually does slightly more than my old prompt did as well even in that time.&lt;/p&gt;

&lt;p&gt;My previous prompt, one that I’d been rocking for about 10 years, was defined in the dual behemoths that are &lt;a href="https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh" rel="noopener noreferrer"&gt;Git’s contrib prompt script&lt;/a&gt; and my &lt;a href="https://github.com/calebhearth/dotfiles/blob/44837b56081441aed12415f9bfa9f32165a40d37/zsh/prompt.zsh" rel="noopener noreferrer"&gt;former prompt.zsh&lt;/a&gt; which called it and added a few other bits like per-host emoji for when I was SSH’d into another machine and some custom shortening of &lt;code&gt;$PWD&lt;/code&gt;. I dug it up so that I could show what it would look like:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;hearthside(main *$%=)/app ❯
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;And the new one looks pretty similar. Mostly you’ll notice that I’ve changed color schemes to one inspired by the GitHub colorblind scheme, which I’ve really come to like. I’ve also swapped one set of funny symbols for another, and unfortunately you probably can’t see them in this text.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/starship-prompt" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>rust</category>
      <category>shell</category>
      <category>dotfiles</category>
    </item>
    <item>
      <title>Send a From Header When You Crawl</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Thu, 14 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/send-a-from-header-when-you-crawl-40f7</link>
      <guid>https://dev.to/calebhearth/send-a-from-header-when-you-crawl-40f7</guid>
      <description>&lt;p&gt;Sending a From header is part of building a polite crawler, along with respecting Robots.txt and sending a unique User-Agent. The From header simply contains an email address that can be used by the site’s owner to reach out if your bot is creating any issues for them.&lt;/p&gt;

&lt;p&gt;RFC 9110 which describes HTTP Semantics says that &lt;a href="https://httpwg.org/specs/rfc9110.html#field.from" rel="noopener noreferrer"&gt;a From header SHOULD be sent for robotic user-agents&lt;/a&gt;. MDN says that the &lt;a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/From" rel="noopener noreferrer"&gt;From header “must” be sent&lt;/a&gt; in that circumstance, but doesn’t have a citation for a spec that defines that.&lt;/p&gt;

&lt;p&gt;I’ve been sending From headers for a while now, and I’m even including it as a requirement in a Swift type-driven API client I’ve been using across a few projects. I’m probably sending it in more places than I need to or that it would be expected in, but as I use scraping and API requests to &lt;a href="https://calebhearth.com/dt/now-hear-this" rel="noopener noreferrer"&gt;automate my /now page&lt;/a&gt;, it seems prudent in case that causes issues for &lt;a href="https://calebhearth.com/dt/services-and-data" rel="noopener noreferrer"&gt;the services I’m using&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Setting a From header is easy. Its syntax is &lt;code&gt;From: &amp;lt;email&amp;gt;&lt;/code&gt;. If you’re building any kind of scraper.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/send-a-from-header" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>crawling</category>
      <category>bestpractices</category>
      <category>http</category>
    </item>
    <item>
      <title>Search and Sync Your Shell History With Atuin</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Tue, 12 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/search-and-sync-your-shell-history-with-atuin-1abk</link>
      <guid>https://dev.to/calebhearth/search-and-sync-your-shell-history-with-atuin-1abk</guid>
      <description>&lt;p&gt;Atuin is a tool that runs in the background to capture commands you’ve entered. It stores these locally in a SQLite database and provides a great CLI tool to search through that history, provide stats of what commands you frequently run, and optionally syncs this history across devices.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://atuin.sh" rel="noopener noreferrer"&gt;Atuin&lt;/a&gt; is one of several cool Rust tools that I’ve found in the past year or so, and is my favorite addition to my terminal workflow in a long time. Other tools that I’ve found and would like to write up soon are: Hyperfine, ripgrep, and Starship.&lt;sup id="fnref:delta"&gt;&lt;a href="https://calebhearth.com/dt/search-sync-shell-atuin#fn:delta" rel="footnote noopener noreferrer"&gt;1&lt;/a&gt;&lt;/sup&gt; I’ve added Atuin to my /uses page with a link back to this post.&lt;/p&gt;

&lt;p&gt;Commands are grabbed via preexec and precmd hooks that allow it to get not only the command, but the current directory, hostname, session, duration of the command, and exit code. It stores these in its SQLite database along with a timestamp, so you’re free to introspect that data yourself as well. It also leaves the shell’s history file alone, so unless you disable it yourself you’ll still have that.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/search-sync-shell-atuin" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>atuin</category>
      <category>rust</category>
      <category>shell</category>
      <category>dotfiles</category>
    </item>
    <item>
      <title>Decryption/CypherError on Rails 7.1 Apps with Encrypted Columns After Upgrading from Previous Versions</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Mon, 11 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/decryptioncyphererror-on-rails-71-apps-with-encrypted-columns-after-upgrading-from-previous-f9d</link>
      <guid>https://dev.to/calebhearth/decryptioncyphererror-on-rails-71-apps-with-encrypted-columns-after-upgrading-from-previous-f9d</guid>
      <description>&lt;p&gt;When upgrading to Rails 7.1 with any models using the &lt;code&gt;encrypts&lt;/code&gt; macro from &lt;code&gt;ActiveRecord::Encryption&lt;/code&gt;, be wary of upgrading the &lt;code&gt;config.load_defaults&lt;/code&gt; in &lt;code&gt;config/application.rb&lt;/code&gt; from &lt;code&gt;7.0&lt;/code&gt; to &lt;code&gt;7.1&lt;/code&gt;. The &lt;a href="https://github.com/rails/rails/blob/v7.1.0/railties/lib/rails/application/configuration.rb#L290-L291" rel="noopener noreferrer"&gt;7.1 defaults for &lt;code&gt;ActiveRecord::Encryption&lt;/code&gt;&lt;/a&gt; include a combination of settings that can lead to your app being unable to decrypt data that it previously encrypted:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;active_record.encryption.hash_digest_class = OpenSSL::Digest::SHA256 active_record.encryption.support_sha1_for_non_deterministic_encryption = false 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;While the exception backtrace will probably include lines from your app, they won’t be helpful in identifying or resolving the issue except that you might notice that they include the getter method for a database column that you’ve defined with &lt;code&gt;encrypts&lt;/code&gt;. You’ll see an error with a backtrace ending something like:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;.../encryptor.rb:58:in `rescue in decrypt': ActiveRecord::Encryption::Errors::Decryption (ActiveRecord::Encryption::Errors::Decryption) .../cipher/aes256_gcm.rb:79:in `rescue in...
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;a href="https://calebhearth.com/dt/rails-7-1-encryption-errors" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>nablopomo</category>
      <category>rails</category>
      <category>bug</category>
      <category>opensource</category>
    </item>
    <item>
      <title>I Use /uses</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Fri, 08 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/i-use-uses-1ed8</link>
      <guid>https://dev.to/calebhearth/i-use-uses-1ed8</guid>
      <description>&lt;p&gt;Back in 2023 I quietly published my &lt;a href="https://calebhearth.com/dt/uses" rel="noopener noreferrer"&gt;/uses&lt;/a&gt; slashpage. Today I gave it a pass to update things that had fallen out of date.&lt;/p&gt;

&lt;p&gt;This is another of the slashpages that I think folks should have, though it’s probably less important than an /about, /links, or even /now. A &lt;a href="https://indieweb.org/using" rel="noopener noreferrer"&gt;/uses&lt;/a&gt; page lists out gear, apps, software, and other tools that its author uses. Having something on /uses is usually an implicit endorsement of that tool, though it’s totally possible that someone uses something but wishes that it were better, knows of a nicer alternative but the cost—monetary, of switching, or otherwise—is too high.&lt;/p&gt;

&lt;p&gt;Also that year as part of NaBloPoMo 2023 I published &lt;a href="https://calebhearth.com/dt/apps-i-use-2023" rel="noopener noreferrer"&gt;Apps I Use in 2023&lt;/a&gt; which is sort of an extension to my /uses page with the addition of a bit of historical context in case I update it (which might be upcoming this month).&lt;/p&gt;

&lt;p&gt;&lt;cite&gt;&lt;span&gt;According to &lt;span&gt;&lt;span&gt;Robb Knight&lt;/span&gt; on &lt;a href="https://slashpages.net/#uses" rel="noopener noreferrer"&gt;Slash Pages&lt;/a&gt;&lt;/span&gt;, &lt;span&gt;&lt;span&gt;Wes Bos&lt;/span&gt; created the first &lt;a href="https://wesbos.com/uses" rel="noopener noreferrer"&gt;/uses page&lt;/a&gt;&lt;/span&gt;.&lt;/span&gt;&lt;/cite&gt; I aspire to the quality of Wes’ page: mine is basically a list with sections.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/i-use-uses" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>slashpages</category>
      <category>indieweb</category>
    </item>
    <item>
      <title>How to Send a Webmention h-entry</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Thu, 07 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/how-to-send-a-webmention-h-entry-o2g</link>
      <guid>https://dev.to/calebhearth/how-to-send-a-webmention-h-entry-o2g</guid>
      <description>&lt;p&gt;Webmentions are a useful way to notify a website that you have linked to it. Microformats like &lt;code&gt;h-entry&lt;/code&gt; combined with &lt;code&gt;u-in-reply-to&lt;/code&gt;, &lt;code&gt;u-like-of&lt;/code&gt;, &lt;code&gt;u-bookmark-of&lt;/code&gt;, or &lt;code&gt;u-repost-of&lt;/code&gt; give context to the mentions.&lt;/p&gt;

&lt;p&gt;Sending a &lt;a href="https://indieweb.org/Webmention" rel="noopener noreferrer"&gt;Webmention&lt;/a&gt; means &lt;code&gt;POST&lt;/code&gt;-ing to a Webmention endpoint with the data &lt;code&gt;source&lt;/code&gt; and &lt;code&gt;target&lt;/code&gt;. The &lt;code&gt;source&lt;/code&gt; is the URL of the page that contains a link to the URL &lt;code&gt;target&lt;/code&gt;. Note that a standards-compliant recipient will discard Webmentions if the content of the &lt;code&gt;source&lt;/code&gt; page does not contain a “per-media-type” mention of the &lt;code&gt;target&lt;/code&gt; URL. For example, and HTML &lt;code&gt;source&lt;/code&gt; might contain an &lt;code&gt;&amp;lt;a href&amp;gt;&lt;/code&gt; or &lt;code&gt;&amp;lt;video src&amp;gt;&lt;/code&gt; matching &lt;code&gt;target&lt;/code&gt; URL and a JSON &lt;code&gt;source&lt;/code&gt; could contain any key whose value exactly matches &lt;code&gt;target&lt;/code&gt;. A plain text document would need to contain the &lt;code&gt;target&lt;/code&gt; URL verbatim.&lt;/p&gt;

&lt;p&gt;While simply notifying a site that you’ve mentioned or linked to it is nice, without additional context the Webmention might not be very useful. Adding context using &lt;a href="https://microformats.org/wiki/h-entry" rel="noopener noreferrer"&gt;&lt;code&gt;h-entry&lt;/code&gt;&lt;/a&gt;, ideally with embedded [&lt;code&gt;h-card&lt;/code&gt;]s.(&lt;a href="https://microformats.org/wiki/h-card" rel="noopener noreferrer"&gt;https://microformats.org/wiki/h-card&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/webmentions-h-entry" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>nablopomo</category>
      <category>webmention</category>
      <category>microformats</category>
      <category>indieweb</category>
    </item>
    <item>
      <title>Ask Git to Show a Method</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Tue, 05 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/ask-git-to-show-a-method-j0m</link>
      <guid>https://dev.to/calebhearth/ask-git-to-show-a-method-j0m</guid>
      <description>&lt;p&gt;If you enjoy this article on Git, also check these other &lt;a href="https://calebhearth.com/dt/tags/git" rel="noopener noreferrer"&gt;Git tips&lt;/a&gt;:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href="https://calebhearth.com/dt/stash-what-git-wouldnt-commit" rel="noopener noreferrer"&gt;Stash only what &lt;code&gt;git commit&lt;/code&gt; wouldn't commit&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://calebhearth.com/dt/rubocop-git-blame" rel="noopener noreferrer"&gt;Ignore refactoring commits in &lt;code&gt;git blame&lt;/code&gt;&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://calebhearth.com/dt/sign-git-with-ssh" rel="noopener noreferrer"&gt;Use your SSH key to sign commits&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt; 

&lt;p&gt;When coding, I often find myself wanting to quickly check the details of a &lt;a href="https://stackoverflow.com/a/155655/218211" rel="noopener noreferrer"&gt;function or method&lt;/a&gt; related to what I’m working on. For instance, I might need to understand how the function handles its arguments or recall its side effects.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;If you just want to know how to do this, you can &lt;a href="https://calebhearth.com/dt/git-show-func#all-wrapped-up-in-a-script" rel="noopener noreferrer"&gt;jump down&lt;/a&gt; and skip my story.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;I usually use &lt;code&gt;ctags&lt;/code&gt; with Vim for this. A quick &lt;code&gt;]&lt;/code&gt;, a brief read, and a &lt;code&gt;&amp;lt;Ctrl-o&amp;gt;&lt;/code&gt; and I’m back from whence I came and more informed for my effort. Still, sometimes would be more convenient to just have the code printed right to my terminal from the command line.&lt;/p&gt;

&lt;p&gt;If you’re here, you might remember that we previously looked at Git’s ability to walk the &lt;a href="https://calebhearth.com/dt/git-method-history" rel="noopener noreferrer"&gt;history of a specific method&lt;/a&gt; using &lt;code&gt;git log -L&lt;/code&gt;&lt;sup id="fnref:log"&gt;&lt;a href="https://calebhearth.com/dt/git-show-func#fn:log" rel="footnote noopener noreferrer"&gt;1&lt;/a&gt;&lt;/sup&gt;. What you might not know is that &lt;code&gt;git log&lt;/code&gt; and &lt;code&gt;git show&lt;/code&gt; are close siblings—actually defined in the same file.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/git-show-func" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>git</category>
      <category>shell</category>
    </item>
    <item>
      <title>Highlighting Text in Links with Text Fragments</title>
      <dc:creator>Caleb Hearth</dc:creator>
      <pubDate>Sun, 03 Nov 2024 00:00:00 +0000</pubDate>
      <link>https://dev.to/calebhearth/highlighting-text-in-links-with-text-fragments-3b0l</link>
      <guid>https://dev.to/calebhearth/highlighting-text-in-links-with-text-fragments-3b0l</guid>
      <description>&lt;p&gt;I’ve used URL text fragments in a few posts now and often use it outside of this blog to point someone to a particular piece of text on a page. They’re a really useful feature that allows you to create a URL that links not just to a page or an anchor on that page, but specifically to a bit of text that you’d like to call out to your audience.&lt;/p&gt;

&lt;p&gt;The URL Fragment Text Directive is a W3C Draft, but has been around in at least some major browsers since 2020 and now has good support across Chrome, Edge, Safari, and Firefox as of this September. Firefox was the last straggler, with Safari joining the party in 2022.&lt;/p&gt;

&lt;h2&gt;
  
  
  Building URLs
&lt;/h2&gt;

&lt;p&gt;Despite using Safari as my daily driver for various privacy, security, performance, and platform integration reasons, I still keep Chrome around for the occasional Google Meet call and for generating these links: highlight some text and right clip to copy a link to the highlight. Safari doesn’t have that feature yet unfortunately.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://calebhearth.com/dt/text-fragments" rel="noopener noreferrer"&gt;Read More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>html</category>
      <category>css</category>
      <category>nablopomo2024</category>
      <category>indieweb</category>
    </item>
  </channel>
</rss>
