<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Pikkola Journal</title>
    <link>https://blog.pikkola.com/</link>
    <description>Technical essays from Pikkola on remote work, browser tools, metadata and search.</description>
    <language>en</language>
    <copyright>(c) 2026 Pikkola. All rights reserved.</copyright>
    <managingEditor>hello@pikkola.com (Pikkola Editorial Desk)</managingEditor>
    <webMaster>hello@pikkola.com (Pikkola)</webMaster>
    <lastBuildDate>Mon, 09 Nov 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.pikkola.com/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Generative Engine Optimization (GEO): Why Your Site Needs llms.txt</title>
      <link>https://blog.pikkola.com/posts/generative-engine-optimization-llms-txt</link>
      <guid isPermaLink="true">https://blog.pikkola.com/posts/generative-engine-optimization-llms-txt</guid>
      <pubDate>Mon, 09 Nov 2026 00:00:00 +0000</pubDate>
      <category>GEO</category>
      <description>Search returned ten links and you picked one. An assistant returns one answer and cites three sources. The unit of competition has changed from a ranking position to a quotation, and most sites are still optimising for a list that no longer exists. Generative engine optimisation — GEO, sometimes called answer engine optimisation — is what happens when you take that shift seriously: you write and structure a site so that a retrieval system can find a passage, understand it without surrounding context, and quote it accurately. Much of it is just clear writing. The rest is a handful of structural decisions, one of which is a small text file called llms.txt . What an answer engine actually does…</description>
    </item>
    <item>
      <title>Mastering Open Graph &amp; Twitter Cards: The Complete Developer Guide</title>
      <link>https://blog.pikkola.com/posts/open-graph-twitter-cards-guide</link>
      <guid isPermaLink="true">https://blog.pikkola.com/posts/open-graph-twitter-cards-guide</guid>
      <pubDate>Sun, 08 Nov 2026 00:00:00 +0000</pubDate>
      <category>Distribution</category>
      <description>Nobody clicks a link. They click a card: a picture, a headline and a domain, rendered by someone else&#x27;s software from tags you wrote months ago and have not looked at since. That card is the entire first impression for every share on X, LinkedIn, Facebook, Slack, Discord, WhatsApp and KakaoTalk — and it is built by a crawler that will not run your JavaScript, will not log in, and will give up after a few seconds. Most broken previews are not cosmetic. They are the difference between a link that gets read and one that scrolls past. This guide covers what the crawlers actually do, the tags that matter and the ones that do not, image rules per platform, dynamic cards at the edge, and the five…</description>
    </item>
    <item>
      <title>The Modern Guide to Web-Based Text Diffing and JSON Patch</title>
      <link>https://blog.pikkola.com/posts/web-text-diffing-and-json-patch</link>
      <guid isPermaLink="true">https://blog.pikkola.com/posts/web-text-diffing-and-json-patch</guid>
      <pubDate>Fri, 06 Nov 2026 00:00:00 +0000</pubDate>
      <category>Engineering</category>
      <description>Diffing looks like an algorithms exercise until you build one. Then it becomes a product problem: people do not want the mathematically minimal edit script, they want to see what changed, in the order they read it, without a ten-second freeze on a 3,000-line file. This guide covers the two places diff shows up in web software — human-readable text comparison and machine-applicable JSON changes — and the practical thresholds where the textbook answer stops being the right answer. Almost all of it can run in the browser, which is worth remembering the next time someone is about to paste a config file full of credentials into a server-side diff service. Why run diff in the browser at all Three…</description>
    </item>
    <item>
      <title>How to Manage Timezones Across Remote Teams Without Calendar Chaos</title>
      <link>https://blog.pikkola.com/posts/managing-timezones-across-remote-teams</link>
      <guid isPermaLink="true">https://blog.pikkola.com/posts/managing-timezones-across-remote-teams</guid>
      <pubDate>Wed, 04 Nov 2026 00:00:00 +0000</pubDate>
      <category>Remote work</category>
      <description>A team spread across Seoul, London and New York does not have a scheduling problem. It has nine hours of offset, and every meeting that ignores that number quietly taxes somebody&#x27;s evening. The fix is not a smarter calendar app. It is a short list of written conventions that anyone can apply without thinking. Most advice about distributed teams starts with tools: pick a scheduler, share your calendar, try asynchronous video. Tools help, but they only automate a decision you have already made. If the team never agreed on which hours are shared, a scheduler will happily book a 3 a.m. call and call it a match. This guide is the decision layer. It covers how to count a team&#x27;s real overlap, how…</description>
    </item>
  </channel>
</rss>
