Forem: Rafael Milewski

EchoSense: Capture Every Word

Rafael Milewski — Sun, 07 Dec 2025 14:41:17 +0000

This is a submission for the DEV's Worldwide Show and Tell Challenge Presented by Mux

What I Built

I'm reusing a previous project of mine:

AssemblyAI Voice Agents Challenge: Real-Time

Rafael Milewski

Nov 23 '24

EchoSense: Your Pocket-Sized Companion for Smarter Meetings

#devchallenge #assemblyaichallenge #ai #api

Comments 18

3 min read

I built a portable device that captures its surroundings and enhances it with real-time insights and knowledge capabilities. Users can place the device in a meeting, for example, to get live transcription, ask questions to the AI it connects to, and receive automatic summaries. The system can package all of the content and send it by email for later review, analysis, or record keeping.

My Pitch Video

Demo

Since this project relies on dedicated hardware to function as intended, it's not possible to provide a full end-to-end demo without physically shipping a device to the judges.

However, I've created a simulation environment that allows you to preview the frontend experience and explore the core interactions:

echosense-simulation.vercel.app

Source Code:

milewski / echosense-challenge

Making sense of echoes and delivering insights

EchoSense

Portable device for real-time audio transcription and interactive summaries.

This is the main repository for my submission to AssemblyAI Challenge.

Esp32: The firmware source code for the ESP32-S3-Zero device.
Frontend: The UI that communicates with the device via websocket.

Each subfolder includes instructions for running the project locally.

For a more detailed overview, including screenshots, you can read the submission sent to the challenge here:

https://dev.to/milewski/echosense-your-pocket-sized-companion-for-smarter-meetings-3i71

View on GitHub

The Story Behind It

This project was originally created for a dev.to hackathon, but the idea was inspired by a real-world observation. I often attend meetings where most participants are non-native English speakers. I noticed some coworkers relying on some automatic captioning software instaled on their computer just to keep up, either because their English inst good enough or because the mix of accents made things difficult to understand.

This was the root inspiration for EchoSense. I wanted to build something that not only provided real-time captioning, but went beyond what tools like Zoom or Teams offered at the time by adding features like live transcription, AI-powered insights, summaries, and more. I believe a device like this can be useful for a wide variety of users, and since it's simple to assemble and build, it could even be a fun weekend project.

I also drew inspiration from a few open-source hardware projects, such as:

Both share all the files and tutorials needed to build a "smart" device yourself. I love this approach, it's a great way to learn, experiment, and deepen your understanding of how hardware and software work together.

Technical Highlights

The stack isn't complicated. The device is built on an ESP32, but instead of using traditional C-based code, it's written in Rust. I chose Rust because I believe it's better suited for embedded development: it provides a modern developer experience, strong safety guarantees, and excellent performance. In practice, this made development significantly easier and less error-prone than if I had written it in C.

Due to hardware limitations, the device itself isn't capable of running transcription or large language model tasks locally. Instead, it captures audio and streams data to a third-party service for real-time transcription and AI processing, keeping the hardware lightweight while still enabling powerful functionality.

One interesting challenge I faced during this project was that the ESP32 variant I chose has an extremely small stack memory. It would sometimes crash simply by receiving an extra item in a JSON array from the server... in other words, a JSON response of just a few kilobytes would instantly crash the device when attempting to parse it because there wasn't enough memory to hold the data. This is almost unthinkable for the new generation of developers who are used to working with effectively unlimited resources and architect as if client devices have infinite RAM. In most cases today that mindset doesn't cause issues, because memory is abundant, but on a constrained device like this, every byte matters and small decisions can have huge consequences.

Because of this limitation, the software had to be written with extreme efficiency to avoid stack overflows while still handling tasks in real time and serving multiple clients.

This experience gave me a glimpse of what it must have been like to build computer software or video games when machines were orders of magnitude slower than this microcontroller. It's fascinating how far computing has come, and how disconnected most modern developers are from the constraints that used to define everyday programming.

Conduit: A UI-less node-based system

Rafael Milewski — Sat, 03 May 2025 11:52:25 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: Exploring the Possibilities

What I Built

I have built Conduit, a domain-specific language (DSL) for creating node-based workflows. Conduit enables developers to create reusable building blocks with an intuitive syntax that can be mixed and matched to build complex data processing pipelines. It's similar to node-based UI tools like ComfyUI but without the graphical interface, offering a code-first approach that's more flexible and embeddable.

One of Conduit's most powerful features is its true cross-language compatibility. Unlike many workflow tools that are tied to specific languages or platforms, Conduit workflows can be compiled to native libraries (.so/.dll) and seamlessly integrated with virtually any programming language through FFI (Foreign Function Interface). This means you can define your workflows once in Conduit's intuitive DSL and then use them from JavaScript, Python, PHP, Java, Go, or any other language that supports FFI - all while maintaining native performance. This language-agnostic approach eliminates the need for complex interoperability layers or performance-degrading bridges between different technology stacks.

What makes this project special is how Amazon Q Developer transformed my development process. With its assistance, I was able to build in TWO days what would have taken a month otherwise, including creating a custom DSL parser, implementing an ECS architecture, and developing procedural macros — all challenging aspects of Rust development that typically require significant time investment and expertise.

Demo

The project includes working examples that demonstrate Conduit's capabilities:

A Rust example that reads an image file, resizes it, and saves the result:

let pipeline = r#"
  resizer {
    source <- read_file {
      input <- "./examples/conduit-example/cover.png"
    }
    width <- 512
    height <- 215
    output -> write_file {
      destination <- "./examples/conduit-example/cover.smaller.png"
    }
  }
"#;

let mut engine = Engine::new();
engine.run_pipeline(pipeline);

If you're a visual learner, the above example can be visualized like this:

Demo code can be found here.

A Node.js integration example showing how Conduit can be used from JavaScript:

import { ConduitEngine } from './Engine'

const engine = new ConduitEngine()

const pipeline = `
  resizer {
    source <- read_file {
      input <- "../conduit-example/cover.png"
    }
    width <- 512
    height <- 215
    output -> write_file {
      destination <- "../conduit-example/cover.smaller.png"
    }
  }
`

engine.runPipeline(pipeline)
engine.destroy()

Demo code can be found here.

Code Repository

milewski / conduit-challenge

This is the main repository for my submission to "Amazon Q Developer "Quack The Code" challenge.

Conduit is a domain-specific language (DSL) for creating node-based workflows in Rust. It enables you to build complex data processing pipelines with a simple, declarative syntax

Installation

Add Conduit to your Cargo.toml:

[dependencies]
conduit = { git = "https://github.com/milewski/conduit-challange.git", version = "0.1.0" }
conduit-derive = { git = "https://github.com/milewski/conduit-challange.git", version = "0.1.0" }

Quick Start

use conduit::Engine;
use conduit_derive::Node;
#[derive(Node)]
pub struct Logger {
    pub left: Input<String>,
    pub right: Input<String>,
}

impl ExecutableNode for Logger {
    fn run(&self) {
        println!("{} {}", self.left.read

…

View on GitHub

I intend to grow this into an open-source project because deep inside, this is ideally how I would like ComfyUI to be. There's still a long journey ahead for building all the custom nodes, which is especially challenging given that the majority of code for AI workflows is written in Python. However, with my hands-on experience with Candle and Burn libraries, I may be able to get pretty close!

The Problem and Inspiration

I'm a huge fan of ComfyUI, a powerful node-based system I’ve used extensively in hackathons and personal projects. But despite its strengths, I kept running into two consistent limitations:

When I needed functionality beyond what the existing nodes or community contributions provided, I had to build it myself — typically in Python, through a manual and often clunky process.
Systems like ComfyUI are not easy to embed. Sometimes, I just want a lightweight, embeddable engine that works directly within the language I'm using — without setting up servers, UIs, or dealing with platform-specific quirks.

This led me to a question:

What if there were a tool like ComfyUI, but entirely code-driven — no GUI, no friction, just flexible building blocks?

What if I could create node-based workflows not just for ML models, but for anything — like making API calls, evaluating expressions, chaining CLI commands, validating form data, or even just adding numbers?

That’s the idea behind Conduit: a node-based system that’s completely UI-less, embeddable, and designed for developers who want full control without leaving their editor.

Technical Implementation

Conduit features a simple, intuitive syntax heavily inspired by hardware description languages like Verilog. Creating custom nodes is straightforward—just define a Rust struct, derive it with the Node macro, and you're ready to build. No need to deal with Python or JavaScript; everything is native Rust with the ability to be called from other languages via FFI.

I wrote a basic tutorial explaining the syntax here, which covers everything you need to know about the DSL: https://github.com/milewski/conduit-challenge?tab=readme-ov-file#basic-syntax

One of the key advantages of Conduit is its cross-language compatibility. You can build your workflow, compile it to a .so/.dll dynamic library, and use it in ANY programming language via FFI. I've provided an example of how to use it in JavaScript, but there are no limitations—you could integrate it with Dart, PHP, Java, or any other language. Because the workflows run natively, you get native performance without the bottlenecks specific to each language's runtime environment.

Tech Stack

The project was built entirely in Rust, with a custom DSL written using PEST, a powerful parsing expression grammar library. The language grammar (PEG) can be found in schema.pest.

Performance is a core advantage of Conduit's architecture. By leveraging Rust's zero-cost abstractions and the ECS pattern, Conduit workflows execute with near-native performance regardless of complexity. Unlike traditional scripting-based workflow systems that interpret code at runtime or rely on language-specific VMs, Conduit compiles workflows to optimized machine code. This approach eliminates interpreter overhead and enables automatic parallelization of independent nodes. In practical terms, this means Conduit can process data-intensive workflows (like image manipulation or large dataset transformations) significantly faster than equivalent implementations in interpreted languages, while maintaining predictable memory usage and avoiding garbage collection pauses.

Conduit adopts an Entity Component System (ECS) design pattern using bevy-ecs, which makes it simple to parallelize operations where possible, resulting in extremely efficient workflow execution. It also utilizes an inventory system to automatically register nodes, further enhancing the ergonomics of the project.

The project is divided into two crates:

Conduit: The main crate responsible for parsing the DSL and executing the node workflows
Conduit-Derive: A procedural macro crate that eliminates boilerplate code when creating new nodes

How I Used Amazon Q Developer

Before this hackathon, I wasn't aware that Amazon Q CLI existed. Initially, I assumed it would be similar to other IDE tools like GitHub Copilot or Gemini Assistant—primarily code auto-completion tools. However, I was pleasantly surprised to discover it was a full-featured CLI assistant, my first experience using AI directly from the command line.

Development Journey with Amazon Q

My journey began by asking Amazon Q for hackathon project ideas. I provided context about my interest in node-based systems like ComfyUI, and it suggested building something similar to what Conduit has become. When I asked for a prototype, the quality of the output immediately gave me confidence that I was working with a powerful tool.

The code Amazon Q produced was remarkably similar to what I would have written myself, which gave me the confidence to continue. What would have taken me months to build, I was able to accomplish in just two days with Amazon Q's assistance!

Another point worth mentioning: I saw there was extensive documentation on the AWS Q website, but I skipped it all and jumped straight to the installation. The command line itself has a /help command that explains what features are available, making it effortless to figure out how to use the tool. This ease of use was a pleasant surprise.

Architectural Decisions

I started from scratch, first creating the foundation and then asking Amazon Q to help build feature by feature. For straightforward tasks, I wrote the code myself, but for more complex challenges that would typically require significant time to figure out the best approach, I asked Amazon Q to provide multiple options.

What impressed me most was Amazon Q's ability to generate substantial amounts of code while maintaining a step-by-step approach. I could discuss concerns like, "I think if you change the struct this way, it would require a lifetime parameter and could cause trouble when implementing X Y Z" and it would understand my concerns and propose alternative approaches that aligned with the existing codebase.

Advanced Rust Features

Once my first version was working, I wanted to simplify the codebase to reduce boilerplate and create a more ergonomic library. That's when I asked Amazon Q to create a procedural macro to generate all the necessary boilerplate. Amazon Q condensed it into a single #[derive(Node)] attribute and made the code super clean to use! Admittedly, procedural macros in Rust are hard to write and would have taken me a long time to implement myself, but with a single prompt, Amazon Q was able to build it and make it work on the first try!

I also discussed with Amazon Q what would be the best design patterns to apply to this project for better performance, parallel execution, and multi-threading. Initially, I implemented it using channels, but Amazon Q recommended using the ECS pattern instead, which made the implementation much simpler. This guidance on architectural decisions was invaluable.

Tips for Using Amazon Q Developer

Work incrementally: Ask Amazon Q to write or change code in small increments rather than tackling large features all at once. This isn't because it can't handle complex tasks, but because smaller changes are easier to understand and review. You won't be able to effectively follow along, make changes, or fix bugs if you don't understand the code being produced.
Commit frequently: Always commit your code before asking Amazon Q to make changes. Even though it shows and confirms changes before implementing them, having a git history makes it easier to understand what was modified and where.
Provide clear direction: Give Amazon Q hints about what you want to accomplish. Specify which files you want to modify, what changes you want to make, and how they should be implemented. It works best when you provide specific file and function names.
Create an AmazonQ.md file: Write a guide explaining what Amazon Q should and shouldn't do, along with project context. Including instructions to always run tests or compile the project helps ensure that Amazon Q will verify its changes and fix any errors before finalizing them.

Future Development

If you like the project and want to help it move forward, contributions are welcome! There are several features and improvements on the roadmap:

Async Runtime/Scheduler: Implement support for nodes that can run asynchronously
Enhanced Error Handling: Complete the integration with thiserror for more robust error management
Arithmetic Expressions: Update the DSL to support arithmetic operations:

  node { property <- (500 * 5) / (10 * another::module) }

Conditional Logic: Add support for conditional nodes:

  test { property <- if (true && false, "when-true", "when-false") }

Expanded Node Library: Implement more nodes for various use cases

Pull requests addressing any of these areas would be greatly appreciated!

Imaginarium - Build. Explore. Leave Your Mark.

Rafael Milewski — Sun, 27 Apr 2025 18:19:32 +0000

This is a submission for the Alibaba Cloud Challenge: Build a Web Game.*

What I Built

I created a multiplayer open-world game where you control a robot in an infinite, isometric grid-based world. Your mission is to use your imagination to build unique monuments that decorate the landscape. Each monument is dynamically generated with the help of AI (powered by ComfyUI), and is permanently placed at the location where it was created. As players explore the world, they can discover the creations of others and encounter fellow travelers cruising through the ever-evolving map, making it a vibrant and shared experience.

Demo

https://imaginarium.monster

Source Code

https://github.com/milewski/imaginarium-challange

The Repository Contains:

The game source code located in /game
The WebSocket server and API located in /server
The Terraform setup files for the infrastructure located in /infrastructure

Alibaba Cloud Services Implementation

To support the game's backend and dynamic content delivery, I utilized several Alibaba Cloud services:

Elastic Compute Service (ECS):

Used for hosting the backend servers, including the API and WebSocket services. ECS provided the flexibility and performance needed to run Rust-based backend components efficiently.

Object Storage Service (OSS):

Used to store and serve static assets generated by players, such as monument images. OSS offered scalable and reliable storage with easy access over the web.

Content Delivery Network (CDN):

Integrated to accelerate the delivery of frontend assets, improving load times and the overall user experience, especially for a browser-based WASM game.

Container Registry (CR):

Used to host and manage the container images for the server components. Leveraging Alibaba Cloud’s container registry streamlined the deployment process.

While there were additional Alibaba Cloud services that could have further enhanced the project, integrating them would have required more development time. I effectively had only four days to work on this project, and it was an incredibly fun experience. Overall, working with Alibaba Cloud was smooth and straightforward, largely thanks to the official Terraform provider, which made it easy to explore available services and quickly provision and configure the necessary infrastructure.

Game Development Highlights

The game was developed using the Bevy game engine, entirely built in Rust, and compiled to WebAssembly (WASM) to run seamlessly in the browser. User-generated monument images are dynamically created using a Stable Diffusion XL model, enhanced with several LoRAs via ComfyUI. All generation services are containerized with Docker and deployed to Alibaba Cloud in a Docker Swarm cluster of a single node.

Technical Highlights:

Bevy, Rust, Vuejs, Alibaba Cloud, Docker, ComfyUI, WebSocket, Axum, Terraform

The game runs entirely in the browser via WebAssembly.
Real-time communication with the server is handled through a WebSocket connection using a custom binary protocol.
Both the server and the client frontend are built in Rust, sharing code between them for efficiency and consistency.
A lightweight Vue.js wrapper manages loading logic, WASM communication, modal handling, and audio token interactions.
Monument generation is dynamic, leveraging ComfyUI pipelines for on-the-fly creation of assets.

EchoSense: Your Pocket-Sized Companion for Smarter Meetings

Rafael Milewski — Sat, 23 Nov 2024 17:02:33 +0000

This is a submission for the AssemblyAI Challenge : Sophisticated Speech-to-Text and No More Monkey Business.

What I Built

I developed EchoSense, a portable hardware device that captures spoken content in settings like meetings, classes, brainstorming sessions, and conferences. It features a web interface with real-time transcriptions of everything echoing through its microphone. Users can ask questions about the discussion or generate summaries in real-time, making it an invaluable tool for live events.

The device operates on a modest 40MHz SoC with 4MB of RAM. It’s lightweight, efficient, and can run on a tiny lithium battery, making it highly portable.

Tech Used

Vue, TypeScript, shadcn/ui
ESP32, Rust, Espressif IoT Development Framework (IDF)
WebSocket, SendGrid, AssemblyAI

Demo

Since this is a hardware device, providing a link to a demo isn’t feasible. However, I’ve recorded a video showcasing it in action, along with instructions on how to build one yourself.

and here is the GitHub repository with the source code:

milewski / echosense-challenge

Making sense of echoes and delivering insights

EchoSense

Portable device for real-time audio transcription and interactive summaries.

This is the main repository for my submission to AssemblyAI Challenge.

Esp32: The firmware source code for the ESP32-S3-Zero device.
Frontend: The UI that communicates with the device via websocket.

Each subfolder includes instructions for running the project locally.

For a more detailed overview, including screenshots, you can read the submission sent to the challenge here:

https://dev.to/milewski/echosense-your-pocket-sized-companion-for-smarter-meetings-3i71

View on GitHub

Screenshots

Journey

When powered on, the device automatically connects to the configured Wi-Fi network and requests a temporary token from AssemblyAI, valid for one hour. It establishes a real-time transcription WebSocket connection and generates a local network URL, displayed as a QR code on the OLED screen.

The QR code directs users to the device’s IP address, where a web server runs on port 80. The server hosts a Vue.js-based interface, with all assets (CSS, JS, images) inlined into a single minified and mangled HTML file.

This optimization ensures minimal memory usage—essential in a resource-constrained environment where every byte counts.

As the user speaks, audio is streamed in ~500ms chunks, sampled at 16000Hz in PCM16 format, via the WebSocket connection to AssemblyAI. Transcriptions are returned and displayed live to any user who scans the QR code. Simultaneously, the audio is saved locally on the device’s SD card for further use.

The following diagram illustrate this functionality:

Prompts Qualification

My submission qualifies for 2 prompts:

Really Rad Real-Time
No More Monkey Business

Incomplete functions

The SD card was initially intended to store recordings and later attach them to emails. However, I realized that file sizes would grow too large, exceeding email attachment limits. To address this, a backend would be required to receive and convert the files from raw PCM16 to MP3. Since this wasn't the main focus of the challenge, I left this feature unfinished, as it would require building and hosting a backend.
Currently, there’s no way to configure Wi-Fi, API keys, or recording options via the web UI. All keys are injected at build time during compilation. Ideally, users would set up the device via a local Wi-Fi connection between their phone and the device, but this setup would require additional work.
I had planned to design and 3D print a case, possibly as a cube, to align with names like MeetingBox or MetaCube. Unfortunately, I didn’t have time to complete this, so the prototype was built and presented on a breadboard.

If anyone has any question, feel free to ask below or open an issue on GitHub—I’ll be happy to help!

DearBook: Create Magical Illustrated Children's Stories with AI

Rafael Milewski — Sun, 10 Nov 2024 05:43:59 +0000

This is a submission for the Open Source AI Challenge with pgai and Ollama

What I Built

I built an AI-powered children's book generator that creates fully illustrated stories based on user input. The user provides a brief prompt outlining the desired storyline, such as:

Create a fun story about a bird who was afraid to fly.

In response, an entire illustrated book is generated!

Users can also explore and read stories created by others. All stories are public and anonymous.

Demo

https://dearbook.fun

milewski / dearbook-challenge

Create Magical Illustrated Children's Stories with AI

DearBook

Create Magical Illustrated Children's Stories with AI

This is the main repository for my submission to The Open Source AI Challenge.

The project is organized into three folders:

Backend: Contains the API, Queue, Database, ComfyUI, and Ollama.
Frontend: The UI that communicates with the API.
Infrastructure: The Terraform and stack files used to deploy the application on a Docker Swarm cluster.

Each subfolder includes instructions for running the project locally. Setup is straightforward, as everything has been containerized, running docker compose up is all that’s needed.

Warning

You need a good NVIDIA GPU to run this project!!.

For a more detailed overview, including screenshots, you can read the submission sent to the challenge here:

https://dev.to/milewski/dearbook-create-magical-illustrated-childrens-stories-with-ai-4mpe

Winner announcement:

https://dev.to/devteam/congrats-to-the-winners-of-the-open-source-ai-challenge-with-pgai-and-ollama-46b6

View on GitHub

Tools Used

TimescaleDB: The self-hosted Docker version was used.

pgvector: It was used to store the embedding of the storyline of the book, alongside other important context useful for the search. (source)

pgvectorscale: The StreamingDiskANN index type was used on the book's searchable embedding to speed up the process. (source)

pgai: The ai.ollama_embed() was used to generate embeddings of user input content during the search function. (source)

Ollama:

It was used for creating embeddings, generating the story of the book, analyzing whether the user input content is safe for children, and generating an idea prompt for an image generation model.

There were mainly two models used:

llama3.1:8b: for text generation.
mxbai-embed-large: for embedding.

ComfyUI:

It was used to generate the logo, book cover and every page based on the prompt generated by Ollama.

The main base model utilized was juggernaut-xl, alongside a few LoRAs. They can all be found in the project workflow file.

Stack

Overview of other technologies used:

PHP / Laravel / FrankenPHP / WebSocket
VueJs / Typescript / Tailwind
Docker / Docker Swarm / Traefik / Redis
Terraform / Vultr GPU Cloud

Technical Description

The process for the book generation is as following:

The user creates a prompt, which is optional. If left blank, Ollama generates a new story independently.
A preliminary check is performed to ensure the prompt does not contain any violent or inappropriate content for children. If such content is found, the generation process is aborted immediately. (prompt).
If the user provides input, the 10 records most similar to the user’s prompt are retrieved based on their embeddings. If no input is provided, the top 10 closest embeddings to each other are retrieved. This is done to prevent the LLM from generating duplicate content. In previous tests, it often produced stories about Max and the paintbrush. With this control, if a story about a paintbrush is generated, it ensures that it is at least not related to Max.
The LLM is then instructed to create a story with at least 10 paragraphs, ensuring that it doesn’t closely resemble any of the top 10 stories already in the database. (prompt)
Once the main story is created, each paragraph on its own doesn’t provide enough context for an image generation model to maintain consistency across pages. To address this, a new prompt is given to the LLM to generate context-rich descriptions for each paragraph, including details about the story, main characters, gender, and other relevant information. (prompt)
These prompts are then sent to ComfyUI, which generates the necessary assets.

Final Thoughts

I certainly learned a lot through this experience. Until now, I hadn’t had much exposure to or understanding of vector embeddings, but now it has finally clicked.

Also, knowing that with pgai I can interact with LLMs directly in SQL gives me more ideas than I have time to execute them. I had also never tried to configure a server with NVIDIA GPUs, and now I understand many of the challenges involved. My current setup is a Docker Swarm cluster with three nodes: one for ComfyUI, Ollama, and CPU-based apps. Getting NVIDIA to run on Swarm was troublesome, but it was a valuable learning experience.

I intend to keep this demo app running until the end of the challenge, and after that, anyone curious to see it can host it on their own computer. All the Docker files and instructions on how to run it are in the github repository.

Prizes qualifications

I believe my submission qualifies for the following additional prize categories:

Open-source Models from Ollama: I used llama3.1:8b and mxbai-embed-large
All the Extensions: I used pgvector, pgai and pgvectorscale.
~~Vectorizer Vibe: I could not use pgai Vectorizer because it was not implemented for Ollama. So I rolled my own queue solution.~~

Noisy Monsters 🎶👾

Rafael Milewski — Sun, 13 Oct 2024 18:01:24 +0000

This is a submission for the The Pinata Challenge

What I Built

I built a music app where you place monsters on the scene and record custom audio for each of them. The recordings can be anything—mouth beats, hand-made noises, or whatever sound you can think of. Each monster loops its sound, turning the scene into a lively messy audio experience!

All visual assets were created using ComfyUI.

Tech used:

PixiJs
ToneJs
Vue
ComfyUI (SDXL & Flux Dev)
Pinata
Node for the backend API

Demo

Try it out here: https://noisy-monsters.onrender.com

You can also share your creations and let others experience them:

https://noisy-monsters.onrender.com?share=QmUzrpzHcwDfKuTqpV19L3mdZ8J84XDE8WCi3Fthx1z8Ub

My Code

milewski / pinata-challenge

Pinata Challenge

This Repo is my submission to the dev.to challenge: https://dev.to/challenges/pinata.

Demo: https://noisy-monsters.onrender.com

View on GitHub

More Details

The app uses Pinata to store and share the state of the scene along with the user-recorded audio. When you click "Share" all recorded audio is uploaded to Pinata's IPFS, along with the app's state (the monster positions, and which sound is associated with each monster) in JSON format. The CID is embedded in the URL as ?share=cid.

When someone opens the app with a ?share=cid link, the app fetches the JSON data from IPFS and reconstructs the scene with all the monsters and sounds intact, allowing users to share their creations easily!

Notes

I only discovered this challenge two days before the submission deadline, so I had to finish the app as quickly as possible. As a result, there are several features I'd like to improve or add, such as:

Intro screens and clearer instructions on how to play.
Hover states for better UI feedback.
Some feedback when user starts recording.
Error handling.
Various code optimizations.
Add different audio effects / modifiers for each monster.
Rewrite the code, Vue was totally not necessary.

Despite the time crunch, I'm excited to share this project and plan to keep improving it!

Forem: Rafael Milewski

EchoSense: Capture Every Word

What I Built

EchoSense: Your Pocket-Sized Companion for Smarter Meetings

My Pitch Video

Demo

milewski / echosense-challenge

Making sense of echoes and delivering insights

EchoSense

The Story Behind It

Technical Highlights

Conduit: A UI-less node-based system

What I Built

Demo

Code Repository

milewski / conduit-challenge

This is the main repository for my submission to "Amazon Q Developer "Quack The Code" challenge.

Table of Contents

Installation

Quick Start

The Problem and Inspiration

Technical Implementation

Tech Stack

How I Used Amazon Q Developer

Development Journey with Amazon Q

Architectural Decisions

Advanced Rust Features

Tips for Using Amazon Q Developer

Future Development

Imaginarium - Build. Explore. Leave Your Mark.

What I Built

Demo

Source Code

Alibaba Cloud Services Implementation

Game Development Highlights

Technical Highlights:

EchoSense: Your Pocket-Sized Companion for Smarter Meetings

What I Built

Tech Used

Demo

milewski / echosense-challenge

Making sense of echoes and delivering insights

EchoSense

Screenshots

Journey

Prompts Qualification

Incomplete functions

DearBook: Create Magical Illustrated Children's Stories with AI

What I Built

Demo

https://dearbook.fun

milewski / dearbook-challenge

Create Magical Illustrated Children's Stories with AI

DearBook

Winner announcement:

Tools Used

Stack

Technical Description

Final Thoughts

Prizes qualifications

Noisy Monsters 🎶👾

What I Built

Demo

My Code

milewski / pinata-challenge

Pinata Challenge

More Details

Notes