<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/feed.rss.xml" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Michele Franzin</title>
    <description>Founder @ SeeSaw, Padua, Italy. Technical talks, reflections on craft and career, stories from the trenches of running a software company.
I care about removing waste from how we build.</description>
    <link>https://speakerdeck.com/fuzziness</link>
    <atom:link rel="self" type="application/rss+xml" href="https://speakerdeck.com/fuzziness.rss"/>
    <lastBuildDate>2013-03-30 07:17:11 -0400</lastBuildDate>
    <item>
      <title>Semantic Image Search in Ruby: Postgres, Redis, or LLM? A CO₂-Conscious Comparison</title>
      <description>Postgres, Redis, or LLM? Ask any engineer, and you already know the answer: it depends.
On what, exactly? Usually, there are four things: speed, cost, complexity, and quality. This talk adds a fifth column to that table and shows how to fill it in.
Three real Ruby implementations of semantic image search are run on the same dataset and machine, and compared on grams of CO₂e per query alongside the usual four axes.
The deck includes the measurement method, the formula, the Ruby snippets, and the numbers — but no recommendation.
Just one column you probably didn't have before.

Rubycon.it 2026 — Michele Franzin, SeeSaw.</description>
      <media:content url="https://files.speakerdeck.com/presentations/ac74c916719249178ed6545f600dcd48/preview_slide_0.jpg?39368352" type="image/jpeg" medium="image"/>
      <content:encoded>Postgres, Redis, or LLM? Ask any engineer, and you already know the answer: it depends.
On what, exactly? Usually, there are four things: speed, cost, complexity, and quality. This talk adds a fifth column to that table and shows how to fill it in.
Three real Ruby implementations of semantic image search are run on the same dataset and machine, and compared on grams of CO₂e per query alongside the usual four axes.
The deck includes the measurement method, the formula, the Ruby snippets, and the numbers — but no recommendation.
Just one column you probably didn't have before.

Rubycon.it 2026 — Michele Franzin, SeeSaw.</content:encoded>
      <pubDate>Fri, 08 May 2026 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/semantic-image-search-in-ruby-postgres-redis-or-llm-a-co2-conscious-comparison</link>
      <guid>https://speakerdeck.com/fuzziness/semantic-image-search-in-ruby-postgres-redis-or-llm-a-co2-conscious-comparison</guid>
    </item>
    <item>
      <title>Unleashing git power</title>
      <description>Sono sempre di più gli sviluppatori che usano sistemi per il controllo di versione del software e tra questi strumenti Git è diventato uno standard de-facto. Cloni, Pull(i), Commit(ti), push(i) ...niente di più semplice, vero? ...ma ti è mai capitato di aggiungere un commit sul branch sbagliato (ed ovviamente push-ato sul repository remoto)? ...o di voler correggere il tuo codice con un singolo commit preso di un branch completamente diverso (ma niente altro)? ...mai trovato intrappolato in un conflitto di merge mentre git ti trascina nella tana del bianconiglio? Niente paura, abbiamo un paio di comandi esotici che renderanno più semplice la tua vita da programmatore (e quella dei tuoi colleghi).</description>
      <media:content url="https://files.speakerdeck.com/presentations/5a0ec15310f04aa09650767c1f52dacf/preview_slide_0.jpg?14203979" type="image/jpeg" medium="image"/>
      <content:encoded>Sono sempre di più gli sviluppatori che usano sistemi per il controllo di versione del software e tra questi strumenti Git è diventato uno standard de-facto. Cloni, Pull(i), Commit(ti), push(i) ...niente di più semplice, vero? ...ma ti è mai capitato di aggiungere un commit sul branch sbagliato (ed ovviamente push-ato sul repository remoto)? ...o di voler correggere il tuo codice con un singolo commit preso di un branch completamente diverso (ma niente altro)? ...mai trovato intrappolato in un conflitto di merge mentre git ti trascina nella tana del bianconiglio? Niente paura, abbiamo un paio di comandi esotici che renderanno più semplice la tua vita da programmatore (e quella dei tuoi colleghi).</content:encoded>
      <pubDate>Sat, 16 Nov 2019 00:00:00 -0500</pubDate>
      <link>https://speakerdeck.com/fuzziness/unleashing-git-power</link>
      <guid>https://speakerdeck.com/fuzziness/unleashing-git-power</guid>
    </item>
    <item>
      <title>How to disassemble a monolith into microservices (#daje version)</title>
      <description>There's a huge interest around microservices and microservice architecture... almost every IT conference has a session about it.
A clear idea of the benefits/pitfalls that this approach brings is crucial for a successful adoption in a project.

In this presentation I share some of the experiences made during the dismantling a monolithic application into microservices.
I analyze some of the reasons justifying the adoption of this type of architecture, talk about the most important issues to consider and reveal some approaches that have been successful in our experience.

Topics (among others): microservices, monolith, communication, async messaging, rabbitmq, circuit breaker, conway law, devops, sacrificial architecture.

Talk presented at Codemotion 2016 in Rome.

Note: This is a adapted version of the presentation, without effects and animations.</description>
      <media:content url="https://files.speakerdeck.com/presentations/889ae4e6b3964643bb43fcc98b5dd16b/preview_slide_0.jpg?6029504" type="image/jpeg" medium="image"/>
      <content:encoded>There's a huge interest around microservices and microservice architecture... almost every IT conference has a session about it.
A clear idea of the benefits/pitfalls that this approach brings is crucial for a successful adoption in a project.

In this presentation I share some of the experiences made during the dismantling a monolithic application into microservices.
I analyze some of the reasons justifying the adoption of this type of architecture, talk about the most important issues to consider and reveal some approaches that have been successful in our experience.

Topics (among others): microservices, monolith, communication, async messaging, rabbitmq, circuit breaker, conway law, devops, sacrificial architecture.

Talk presented at Codemotion 2016 in Rome.

Note: This is a adapted version of the presentation, without effects and animations.</content:encoded>
      <pubDate>Fri, 18 Mar 2016 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/how-to-disassemble-a-monolith-into-microservices-number-daje-version</link>
      <guid>https://speakerdeck.com/fuzziness/how-to-disassemble-a-monolith-into-microservices-number-daje-version</guid>
    </item>
    <item>
      <title>How to disassemble a monolithic app in microservices</title>
      <description>Talk presented at Rubyday 2015 in Turin.

There's a huge interest around microservices and microservice architecture... almost every IT conference has a session about it.
A clear idea of the benefits/pitfalls that this approach brings is crucial for a successful adoption in a project.

In this presentation I share some of the experiences made during the dismantling a monolithic application into microservices.
I analyze some of the reasons justifying the adoption of this type of architecture, talk about the most important issues to consider and reveal some approaches that have been successful in our experience.

Topics (among others): microservices, monolith, communication, async messaging, rabbitmq, circuit breaker, conway law, ruby, deploy, devops, sacrificial architecture.

Note: This is a adapted version of the presentation, without effects and animations.
</description>
      <media:content url="https://files.speakerdeck.com/presentations/067fd9c053324b6c977fbefccf638c41/preview_slide_0.jpg?5612504" type="image/jpeg" medium="image"/>
      <content:encoded>Talk presented at Rubyday 2015 in Turin.

There's a huge interest around microservices and microservice architecture... almost every IT conference has a session about it.
A clear idea of the benefits/pitfalls that this approach brings is crucial for a successful adoption in a project.

In this presentation I share some of the experiences made during the dismantling a monolithic application into microservices.
I analyze some of the reasons justifying the adoption of this type of architecture, talk about the most important issues to consider and reveal some approaches that have been successful in our experience.

Topics (among others): microservices, monolith, communication, async messaging, rabbitmq, circuit breaker, conway law, ruby, deploy, devops, sacrificial architecture.

Note: This is a adapted version of the presentation, without effects and animations.
</content:encoded>
      <pubDate>Fri, 13 Nov 2015 00:00:00 -0500</pubDate>
      <link>https://speakerdeck.com/fuzziness/how-to-disassemble-a-monolithic-app-in-microservices</link>
      <guid>https://speakerdeck.com/fuzziness/how-to-disassemble-a-monolithic-app-in-microservices</guid>
    </item>
    <item>
      <title>1 year product development with a distributed team</title>
      <description>Develop a product with a distributed team is a not trivial challenge in many ways: make the team work well, develop the product, stay on time and budget ...
In this talk we would like to share some of the experiences made in over a year long work that put us on test several times to achieve the goal.</description>
      <media:content url="https://files.speakerdeck.com/presentations/ea49dcb24dde40cab2b996e6d992e02e/preview_slide_0.jpg?5484098" type="image/jpeg" medium="image"/>
      <content:encoded>Develop a product with a distributed team is a not trivial challenge in many ways: make the team work well, develop the product, stay on time and budget ...
In this talk we would like to share some of the experiences made in over a year long work that put us on test several times to achieve the goal.</content:encoded>
      <pubDate>Mon, 26 Oct 2015 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/1-year-product-development-with-a-distributed-team</link>
      <guid>https://speakerdeck.com/fuzziness/1-year-product-development-with-a-distributed-team</guid>
    </item>
    <item>
      <title>Micro services: what are and when not to use</title>
      <description>Talk about basic concepts behind micro services to better evaluate when introduce it in a project.</description>
      <media:content url="https://files.speakerdeck.com/presentations/fb3786dd32dc473dbcfa99c3335116a4/preview_slide_0.jpg?5466046" type="image/jpeg" medium="image"/>
      <content:encoded>Talk about basic concepts behind micro services to better evaluate when introduce it in a project.</content:encoded>
      <pubDate>Sat, 24 Oct 2015 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/micro-services-what-are-and-when-not-to-use</link>
      <guid>https://speakerdeck.com/fuzziness/micro-services-what-are-and-when-not-to-use</guid>
    </item>
    <item>
      <title>Gentle introduction to CQRS</title>
      <description>what if I say "CQRS + ES"? ... if you're already looking on wikipedia this talk is for you. CQRS and Event Sourcing introduction for acronyms haters. 100% fluff free</description>
      <media:content url="https://files.speakerdeck.com/presentations/3579e6545e8145daa17684aca1311a9f/preview_slide_0.jpg?5466073" type="image/jpeg" medium="image"/>
      <content:encoded>what if I say "CQRS + ES"? ... if you're already looking on wikipedia this talk is for you. CQRS and Event Sourcing introduction for acronyms haters. 100% fluff free</content:encoded>
      <pubDate>Tue, 15 Sep 2015 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/gentle-introduction-to-cqrs</link>
      <guid>https://speakerdeck.com/fuzziness/gentle-introduction-to-cqrs</guid>
    </item>
    <item>
      <title>git per manager e pizzaioli</title>
      <description>Non sai cos'è git? non hai mai considerato di usare un repository per memorizzare i tuoi file? o non vuoi usarlo perchè sei troppo pigro? diamo una occhiata (non troppo tecnica, promesso) a questo potente tool per familiarizzare un po' e capire come può essere utile. Parte 1 di 3.</description>
      <media:content url="https://files.speakerdeck.com/presentations/f7e80c207b580130e5bc22000a8c4174/preview_slide_0.jpg?1252047" type="image/jpeg" medium="image"/>
      <content:encoded>Non sai cos'è git? non hai mai considerato di usare un repository per memorizzare i tuoi file? o non vuoi usarlo perchè sei troppo pigro? diamo una occhiata (non troppo tecnica, promesso) a questo potente tool per familiarizzare un po' e capire come può essere utile. Parte 1 di 3.</content:encoded>
      <pubDate>Fri, 29 Mar 2013 00:00:00 -0400</pubDate>
      <link>https://speakerdeck.com/fuzziness/git-per-manager-e-pizzaioli</link>
      <guid>https://speakerdeck.com/fuzziness/git-per-manager-e-pizzaioli</guid>
    </item>
  </channel>
</rss>
