pixelfed.social/p/Fotos.photos…

Diego Herculano

2025-04-17 12:55:16

China

@photography@lemmy.ml
#photography #photo #streetphotography #fotografia #China #360Degrees #35mm #art #travel #press #news #photooftheday #mastodon #PortfolioDay #pixelfed #photojournalism #photodocumentary #beach

How it started: a simple repair job on a Roland drum machine. How it ended: a scratch-built FM drum synth module that’s completely analog, and completely cool.

[Moritz Klein]’s journey down the analog drum machine rabbit hole started with a Roland TR-909, a hybrid drum machine from the mid-80s that combined sampled sounds with analog synthesis. The unit [Moritz] picked up was having trouble with the decay on the kick drum, so he spread out the gloriously detailed schematic and got to work. He breadboarded a few sections of the kick drum circuit to aid troubleshooting, but one thing led to another and he was soon in new territory.

The video below is on the longish side, with the first third or so dedicated to recreating the circuits used to create the 909’s iconic sound, slightly modifying some of them to simplify construction. Like the schematic that started the whole thing, this section of the video is jam-packed with goodness, too much to detail here. But a few of the gems that caught our eye were the voltage-controlled amplifier (VCA) circuit that seems to make appearances in multiple places in the circuit, and the dead-simple wave-shaper circuit, which takes some of the harmonics out of the triangle wave oscillator’s output with just a couple of diodes and some resistors.

Once the 909’s kick and toms section had been breadboarded, [Moritz] turned his attention to adding something Roland hadn’t included: frequency modulation. He did this by adding a second, lower-frequency voltage-controlled oscillator (VCO) and using that to modulate the drum section. That resulted in a weird, metallic sound that can be tuned to imitate anything from a steel drum to a bell. He also added a hi-hat and cymbal section by mixing the square wave outputs on the VCOs through a funky XOR gate made from discrete components and a high-pass filter.

There’s a lot of information packed into this video, and by breaking everything down into small, simple blocks, [Moritz] makes it easy to understand analog synths and the circuits behind them.

youtube.com/embed/Xbl1xwFR3eg?…

hackaday.com/2025/04/17/design…

Molte persone che si avvicinano al machine learning non hanno un forte background in ingegneria del software, e quando devono lavorare su un prodotto reale, il loro codice può risultare disordinato e difficile da gestire. Per questo motivo, raccomando sempre vivamente di imparare a usare le coding best practices, che ti permetteranno di lavorare senza problemi all’interno di un team e di migliorare il livello del progetto su cui stai lavorando. Oggi voglio parlare dell’inheritance di Python e mostrare alcuni semplici esempi di come utilizzarla nel campo del machine learning.

Nello sviluppo software e in altri ambiti dell’informatica, il technical debt (noto anche come design debt o code debt) rappresenta il costo implicito di future rielaborazioni dovuto a una soluzione che privilegia la rapidità rispetto a un design a lungo termine.

Se sei interessato a saperne di più sui design patterns, potresti trovare utili alcuni dei miei articoli precedenti.

Python Inheritance

L’Inheritance non è solo un concetto di Python, ma un concetto generale nell’Object Oriented Programming. Quindi, in questo tutorial, dovremo lavorare con classei e oggetti, che rappresentano un paradigma di sviluppo non molto utilizzato in Python rispetto ad altri linguaggi come Java.

Nell’OOP, possiamo definire una classe generale che rappresenta qualcosa nel mondo, ad esempio una Persona, che definiamo semplicemente con un nome, un cognome e un’età nel seguente modo.

class Person:
def __init__(self, name, surname, age):
self.name = name
self.surname = surname
self.age = age

def __str__(self):
return f"Name: {self.name}, surname: {self.surname}, age: {self.age}"

def grow(self):
self.age +=1

In questa classe, abbiamo definito un semplice costruttore (init). Poi abbiamo definito il method str, che si occuperà di stampare l’oggetto nel modo che desideriamo. Infine, abbiamo il method grow() per rendere la persona di un anno più vecchia.

Ora possiamo instanziare un oggetto e utilizzare questa classe.

person = Person("Marcello", "Politi", 28)
person.grow()
print(person)

# output wiil be
# Name: Marcello, surname: Politi, age: 29

E se volessimo definire un particolare tipo di persona, ad esempio un operaio? Possiamo fare la stessa cosa di prima, ma aggiungiamo un’altra variabile di input per aggiungere il suo stipendio.

class Worker:
def __init__(self, name, surname, age, salary):
self.name = name
self.surname = surname
self.age = age
self.salary = salary

def __str__(self):
return f"Name: {self.name}, surname: {self.surname}, age: {self.age}, salary: {self.salary}"

def grow(self):
self.age +=1

Tutto qui. Ma è questo il modo migliore per implementarlo? Vedete che la maggior parte del codice del lavoratore è uguale a quello della persona, perché un lavoratore è una persona particolare e condivide molte cose in comune con una persona.

Quello che possiamo fare è dire a Python che il lavoratore deve ereditare tutto da Persona, e poi aggiungere manualmente tutte le cose di cui abbiamo bisogno, che una persona generica non ha.

class Worker(Person):
def __init__(self, name, surname, age, salary):
super().__init__(name, surname, age)
self.salary = salary

def __str__(self):
text = super().__str__()
return text + f",salary: {self.salary}"

Nella classe worker, il costruttore richiama il costruttore della classe person sfruttando la parola chiave super() e poi aggiunge anche la variabile salary.

La stessa cosa avviene quando si definisce il metodo str. Utilizziamo lo stesso testo restituito da Person usando la parola chiave super e aggiungiamo il salario quando stampiamo l’oggetto.

Ereditarietà nel Machine Learning

Non ci sono regole su quando usare l’ereditarietà nell’machine learning . Non so a quale progetto stiate lavorando, né come sia il vostro codice. Voglio solo sottolineare il fatto che dovreste adottare un paradigma OOP nel vostro codice. Tuttavia, vediamo alcuni esempi di utilizzo dell’ereditarietà.

Definire un BaseModel

Sviluppiamo una classe di base per il modello di ML, definita da alcune variabili standard. Questa classe avrà un metodo per caricare i dati, uno per addestrare, un altro per valutare e uno per preelaborare i dati. Tuttavia, ogni modello specifico preelaborerà i dati in modo diverso, quindi le sottoclassi che erediteranno il modello di base dovranno riscrivere il metodo di preelaborazione.
Attenzione, il modello BaseMLModel stesso eredita la classe ABC. Questo è un modo per dire a Python che questa classe è una classe astratta e non deve essere usata, ma è solo un modello per costruire sottoclassi.

Lo stesso vale per il metodo preprocess_train_data, che è contrassegnato come @abstactmethod. Ciò significa che le sottoclassi devono reimplementare questo metodo.

Guardate questo video per saperne di più su classi e metodi astratti:

youtube.com/embed/UDmJGvM-OUw?…

from abc import ABC, abstractmethod
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score
from sklearn.ensemble import RandomForestClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.datasets import load_iris
import numpy as np

class BaseMLModel(ABC):
def __init__(self, test_size=0.2, random_state=42):
self.model = None # This will be set in subclasses
self.test_size = test_size
self.random_state = random_state
self.X_train = None
self.X_test = None
self.y_train = None
self.y_test = None

def load_data(self, X, y):
self.X_train, self.X_test, self.y_train, self.y_test = train_test_split(
X, y, test_size=self.test_size, random_state=self.random_state
)

@abstractmethod
def preprocess_train_data(self):
"""Each model can define custom preprocessing for training data."""
pass

def train(self):
self.X_train, self.y_train = self.preprocess_train_data()
self.model.fit(self.X_train, self.y_train)

def evaluate(self):
predictions = self.model.predict(self.X_test)
return accuracy_score(self.y_test, predictions)

Vediamo ora come ereditare da questa classe. Per prima cosa, possiamo implementare un LogisticRegressionModel. Che avrà il suo algoritmo di preelaborazione.

class LogisticRegressionModel(BaseMLModel):
def __init__(self, **kwargs):
super().__init__()
self.model = LogisticRegression(**kwargs)

def preprocess_train_data(self):
#Standardize features for Logistic Regression
mean = self.X_train.mean(axis=0)
std = self.X_train.std(axis=0)
X_train_scaled = (self.X_train - mean) / std
return X_train_scaled, self.y_train

Poi possiamo definire tutte le sottoclassi che vogliamo. Qui ne definisco una per una Random Forest.

class RandomForestModel(BaseMLModel):
def __init__(self, n_important_features=2, **kwargs):
super().__init__()
self.model = RandomForestClassifier(**kwargs)
self.n_important_features = n_important_features

def preprocess_train_data(self):
#Select top `n_important_features` features based on variance
feature_variances = np.var(self.X_train, axis=0)
top_features_indices = np.argsort(feature_variances)[-self.n_important_features:]
X_train_selected = self.X_train[:, top_features_indices]
return X_train_selected, self.y_train

Ora usiamo tutto nella funzione main.

if __name__ == "__main__":
# Load dataset
data = load_iris()
X, y = data.data, data.target

# Logistic Regression
log_reg_model = LogisticRegressionModel(max_iter=200)
log_reg_model.load_data(X, y)
log_reg_model.train()
print(f"Logistic Regression Accuracy: {log_reg_model.evaluate()}")

# Random Forest
rf_model = RandomForestModel(n_estimators=100, n_important_features=3)
rf_model.load_data(X, y)
rf_model.train()
print(f"Random Forest Accuracy: {rf_model.evaluate()}")

Conclusioni

Uno dei principali vantaggi dell’ereditarietà di Python nei progetti ML è nella progettazione di codici modulari, mantenibili e scalabili. L’ereditarietà aiuta a evitare codice ridondante, scrivendo la logica comune in una classe base, come BaseMLModel, riducendo quindi la duplicazione del codice. L’inheritance rende anche facile incapsulare comportamenti comuni in una classe base, permettendo alle subclasses di definire dettagli specifici.

Il principale vantaggio, a mio avviso, è che una codebase ben organizzata e orientata agli oggetti consente a più sviluppatori all’interno di un team di lavorare indipendentemente su parti separate. Nel nostro esempio, un ingegnere capo potrebbe definire il modello base, e poi ogni sviluppatore potrebbe concentrarsi su un singolo algoritmo e scrivere la subclass.
Prima di immergerti in design patterns complessi, concentrati sull’utilizzo delle best practices nell’OOP. Farlo ti renderà un programmatore migliore rispetto a molti altri nel campo dell’AI!

L'articolo Inheritance in Python: la chiave per scrivere codice pulito e collaborativo nel Machine Learnin proviene da il blog della sicurezza informatica.

When journalists at The Oregonian started reporting on a sexual harassment lawsuit against Nike, they knew that sealed documents in the case could provide vital information. Little did they know that going to court to get them could mean undercutting their First Amendment rights.

A recent decision from a federal appellate court related to the Oregonian’s quest for access means that journalists who intervene in court cases to try to unseal court records could subject themselves to “prior restraints,” or judicial orders barring them from reporting news related to the case.

That’s why Freedom of the Press Foundation (FPF) joined a coalition of media companies and press freedom groups to file an amicus brief supporting the Oregonian’s request that the full appeals court reconsider this unprecedented decision.

Fight for access to Nike lawsuit records

In 2022, The Oregonian moved to unseal certain documents from a lawsuit brought by four former female employees at Nike who claimed the sportswear company fostered a “culture of unequal compensation and sexual harassment.” Of central interest to the news outlet were the individuals named in internal company documents about allegations of discrimination and harassment.

Around the same time, an Oregonian journalist met with the lawyer for the plaintiffs as part of their reporting on the case. During the meeting, the lawyer inadvertently sent the reporter confidential documents from the lawsuit.

It can’t be right that journalists who go to court to vindicate the public’s First Amendment right of access to court records have fewer First Amendment protections than journalists who don’t.

Typically, when journalists receive secret documents, they want to report on them—and the First Amendment protects their right to do so. But in this case, the court ordered The Oregonian to return or destroy the documents and prohibited it from publishing any information obtained from them.

The Oregonian objected, but a panel of judges from the U.S. Court of Appeals for the 9th Circuit ruled that the news outlet could be required to return or destroy the documents. The appeals court said that The Oregonian became a party to the case when it intervened in the lawsuit to seek the unsealing of the records and, as a result, it could be restricted from publishing them without violating the First Amendment rights it would enjoy as a nonparty news outlet.

Losing First Amendment rights by exercising them

The Court of Appeals’ decision is yet another example of courts ignoring key precedent on prior restraints. The Supreme Court has made clear time and again that prior restraints can be justified in only the most extreme circumstances.

If the court didn’t approve of a prior restraint on publication of the Pentagon Papers — which the government claims contained national security secrets — it seems obvious that it wouldn’t approve of a prior restraint on documents describing sexual harassment complaints at a shoe company.

But perhaps even more worrying than the court’s ignorance of prior restraint precedent is its position that The Oregonian forfeits its First Amendment right to publish the documents because it intervened in the lawsuit to vindicate another First Amendment right — the right of access to judicial documents.

Journalists move to unseal court records all the time. While the First Amendment gives every member of the public the right to access court records and proceedings, the Supreme Court has specifically noted the special role journalists play in exercising that right and using it to inform the public.

But as the attorneys from Davis Wright Tremaine wrote in the amicus brief we joined, the appeals court’s decision “effectively penalizes news outlets that intervene to unseal court records while also gathering information on the same topic through other reporting methods.”

To understand why this punishes journalists, imagine if The Oregonian had never intervened in the Nike lawsuit to try to unseal documents. If everything else still played out the same — its reporter met with a lawyer and the lawyer inadvertently sent the reporter sealed court records—there would be no question that the reporter would have a First Amendment right to publish those documents.

But if the appeals court’s decision stands, journalists who go to court to unseal documents won’t have the same First Amendment right to publish documents they independently obtain through interviews, public records requests, or even anonymous leaks.

That’s a problem because, as our brief explains, many important news stories, from the Miami Herald’s reporting on the Jeffrey Epstein case to The Boston Globe’s Spotlight investigation of child sexual abuse by the Catholic Church, relied on both unsealing court records and shoe-leather reporting.

It can’t be right that journalists who go to court to vindicate the public’s First Amendment right of access to court records have fewer First Amendment protections than journalists who don’t. The full Court of Appeals must reconsider this case and right this backward decision.

freedom.press/issues/when-it-c…

This is the first in a series of profiles of independent journalists who use public records to hold local governments accountable.

Lisa Pickoff-White fell in love with — and experienced the hurdles of — records reporting as a journalism graduate student at the University of California, Berkeley, where she participated in a project to investigate and report on the 2007 murder of Oakland Post editor Chauncey Bailey.

The effort brought together newsrooms to finish Bailey’s reporting on violence and fraud in a San Francisco bakery, which the investigation revealed had long-standing ties with local politicians and police.

“That experience really opened up my eyes to both records reporting and data journalism,” Pickoff-White said. “I realized there was this whole other side of journalism that, even though I had been working in it, that I didn't even really know anything about, and it was something that I was excited to pursue. I immediately was like, ‘This is grueling, difficult work, but it’s work I really want to do.’”

Now, 15 years later, that training continues to pay off, as Pickoff-White’s California Reporting Project sends out more than 700 public records requests to law enforcement agencies each year. In fact, since its inception in 2018, the project has surpassed 3,500 records requests. Pickoff-White, the project’s director, doesn't plan on slowing down.

“One of the things that draws me to journalism is those known unknowns,” Pickoff-White said. “Like, making visible what is hard to see. Being able to connect the dots. I think systems reporting is one of the things that I love about reporting and records research. It allows you to take people’s lived experiences, back it up with data and say, this is occurring and it is occurring more than once, and to give people some context on why it might be occurring as well.”

Systems reporting "allows you to take people’s lived experiences, back it up with data and say, this is occurring and it is occurring more than once, and to give people some context."

Lisa Pickoff-White

The California Reporting Project was born after the state’s Right to Know Act was enacted in 2018, allowing the public to request police reports and reports related to law enforcement’s use of violence and other kinds of misconduct. Hosted by UC Berkeley’s Investigative Reporting Program, the project is a collaborative database with records shared from reporters at 40 news organizations across the state.

“One of the real successes of this project is we’ve already published more than 100 stories out of these records,” Pickoff-White said. “Ever since we started sending requests on January 1, 2019, people have had access to these records and have been able to report out of them. And that’s really important to me, because these are public records.”

With newsrooms increasingly cash-strapped, the cost and time it takes to make and appeal public records requests can be prohibitive. The reporting project’s database collects records obtained from records requests. It also monitors pending requests. That way, reporters can avoid duplicating efforts and instead rely on materials other requesters obtain to use for their own coverage.

“It’s really time-consuming and hard and can cost a lot to make a record request,” Pickoff-White said. “I really encourage other reporters to come together to collaborate on this, because together, we’re stronger. If you could find a way to work with people to invest in the time up front pays dividends in the end.”

freedom.press/issues/pooling-p…

If you’ve spent any time on two wheels, you’ve certainly experienced the woes of poor bicycle shifting. You hit the button or twist the knob expecting a smooth transition into the next gear, only to be met with angry metallic clanking that you try to push though but ultimately can’t. Bicycle manufacturers collectively spent millions attempting to remedy this issue with the likes of gearboxes, electronic shifting, and even belt-driven bikes. But Praxis believes to have a better solution in their prototype HiT system.

Rather then moving a chain between gears, their novel solution works by folding gears into or away from a chain. These gears are made up of four separate segments that individually pivot around an axle near the cog’s center. These segments are carefully timed to ensure there is no interference with the chain making shifting look like a complex mechanical ballet.

While the shift initialization is handled electronically, the gear folding synchronization is mechanical. The combination of electronic and mechanical systems brings near-instant shifting under load at rotational rates of 100 RPM. Make sure to scroll through the product page and watch the videos showcasing the mechanism!

The HiT gearbox is a strange hybrid between a derailleur and a gearbox. It doesn’t contain a clutch based gear change system or even a CVT as seen in the famous Honda bike of old. It’s fully sealed with more robust chains and no moving chainline as in a derailleur system. The prototype is configurable between four or sixteen speeds, with the four speed consisting of two folding gear pairs connected with a chain and the sixteen speed featuring a separate pair of folding gears. The output is either concentric to the input, or above the input for certain types of mountain bikes.

Despite the high level of polish, this remains a prototype and we eagerly await what Praxis does next with the system. In the meantime, make sure to check out this chainless e-drive bicycle.

hackaday.com/2025/04/17/bicycl…

Il Municipio Roma III ospita l’incontro “Liberi di vivere, liberi di scegliere”
29 Aprile 2025 – 18.00 – 20.00

Alessia Cicatelli, membro di Giunta e parte del team legale dell’ Associazione Luca Coscioni, interviene all’incontro organizzato dal Municipio Roma III “Liberi di vivere, liberi di scegliere – Una battaglia di civiltà che riguarda tutti e tutte”, un appuntamento pubblico dedicato al tema dei diritti civili e della libertà di scelta. Interverranno anche:

• Marietta Tidei
• Claudio Marotta
• Marta Marziali, Consigliera Municipio III
• Michela Frappetta
• Simone Filomena, Consigliere Municipio III

Porterà i saluti istituzionali Paolo Marchionne, Presidente del Municipio Roma III.

Modera l’incontro Paolo Cento.

L’appuntamento è per martedì 29 aprile alle ore 18.00, presso la Sala Consiliare del Municipio Roma III, in Piazza Sempione, Roma.

L'articolo Il Municipio Roma III ospita l’incontro “Liberi di vivere, liberi di scegliere” – con Alessia Cicatelli proviene da Associazione Luca Coscioni.

If you had to guess, what do you think it would take to build an ocean-going buoy that could not only survive on its own without human intervention for more than two years, but return useful data the whole time? You’d probably assume such a feat would require beefy hardware, riding inside an expensive and relatively large watertight vessel of some type — and for good reason, the ocean is an unforgiving environment, and has sent far more robust hardware to the briny depths.

But as Wayne Pavalko found back in 2016, a little planning can go a long way. That’s when he launched the first of what he now calls Maker Buoys: a series of solar-powered drifting buoys that combine a collection of off-the-shelf sensor boards with an Arduino microcontroller and an Iridium Short-Burst Data (SBD) modem in a relatively simple watertight box.

He guessed that first buoy might last a few weeks to a month, but when he finally lost contact with it after 771 days, he realized there was real potential for reducing the cost and complexity of ocean research.

Wayne recalled the origin of his project and updated the audience on where it’s gone from there during his 2024 Supercon talk, Adventures in Ocean Tech: The Maker Buoy Journey. Even if you’re not interested in charting ocean currents with homebrew hardware, his story is an inspirational reminder that sometimes a fresh approach can help solve problems that might at first glance seem insurmountable.

DIY All the Way

As Dan Maloney commented when he wrote-up that first buoy’s journey in 2017, the Bill of Materials for a Maker Buoy is tailored for the hobbyist. Despite being capable of journeys lasting for several thousand kilometers in the open ocean, there’s no marine-grade unobtainium parts onboard. Indeed, nearly all of the electronic components can be sourced from Adafruit, with the most expensive line item being the RockBLOCK 9603 Iridium satellite modem at $299.

Even the watertight container that holds all the electronics is relatively pedestrian. It’s the sort of plastic latching box you might put your phone or camera in on a boat trip to make sure it stays dry and floats if it falls overboard. Wayne points out that the box being clear is a huge advantage, as you can mount the solar panel internally. Later versions of the Maker Buoy even included a camera that could peer downward through the bottom of the box.

Wayne says that first buoy was arguably over-built, with each internal component housed in its own waterproof compartment. Current versions instead hold all of the hardware in place with a 3D printed internal frame. The bi-level framework puts the solar panel, GPS, and satellite modem up at the top so they’ve got a clear view of the sky, and mounts the primary PCB, battery, and desiccant container down on the bottom.

The only external addition necessary is to attach a 16 inch (40 centimeter) long piece of PVC pipe to the bottom of the box, which acts as a passive stabilizer. Holes drilled in the pipe allow it to fill with water once submerged, lowering the buoy’s center of gravity and making it harder to flip over. At the same time, should the buoy find itself inverted due to wave action, the pipe will make it top-heavy and flip it back over.

It’s simple, cheap, and incredibly effective. Wayne mentions that data returned from onboard Inertial Measurement Units (IMUs) have shown that Maker Buoys do occasionally find themselves going end-over-end during storms, but they always right themselves.

youtube.com/embed/5WSOKEplw9g?…

Like Space…But Wetter

The V1 Maker Buoy was designed to be as reliable as possible.
Early on in his presentation, Wayne makes an interesting comparison when talking about the difficulties in developing the Maker Buoy. He likens it to operating a spacecraft in that your hardware is never coming back, nobody will be able to service it, and the only connection you’ll have to the craft during its lifetime is a relatively low-bandwidth link.

But one could argue that the nature of Iridium communications makes the mission of the Maker Buoy even more challenging than your average spacecraft. As the network is really only designed for short messages — at one point Wayne mentions that even sending low-resolution images of only a few KB in size was something of an engineering challenge — remotely updating the software on the buoy isn’t an option. So even though the nearly fifty year old Voyager 1 can still receive the occasional software patch from billions of miles away, once you drop a Maker Buoy into the ocean, there’s no way to fix any bugs in the code.

Because of this, Wayne decided to take the extra step of adding a hardware watchdog timer that can monitor the buoy’s systems and reboot the hardware if necessary. It’s a bit like unplugging your router when the Internet goes out…if your Internet was coming from a satellite low-Earth orbit and your living room happened to be in the middle of the ocean.

From One to Many

After publishing information about his first successful Maker Buoy online, Wayne says it wasn’t long before folks started contacting him about potential applications for the hardware. In 2018, a Dutch non-profit expressed interest in buying 50 buoys from him to study the movement of floating plastic waste in the Pacific. The hardware was more than up to the task, but there was just one problem: up to this point, Wayne had only built a grand total of four buoys.

Opportunities like this, plus the desire to offer the Maker Buoy in kit and ready to deploy variants for commercial and educational purposes, meant Wayne had to streamline his production. When it’s just a personal project, it doesn’t really matter how long it takes to assemble or if everything goes together correctly the first time. But that approach just won’t work if you need to deliver functional units in quantities that you can’t count on your fingers.

As Wayne puts it, making something and making something that’s easily producible are really two very different things. The production becomes a project in its own right. He explains that investing the time and effort to make repetitive tasks more efficient and reliable, such as developing jigs to hold pieces together while you’re working on them, more than pays off for itself in the end. Even though he’s still building them himself in his basement, he uses an assembly line approach that allows for the consistent results expected by paying customers.

A Tale Well Told

While the technical details of how Wayne designed and built the different versions of the Maker Buoy are certainly interesting, it’s hearing the story of the project from inception to the present day that really makes watching this talk worthwhile. What started as a simple “What If” experiment has spiraled into a side-business that has helped deploy buoys all over the planet.

Admittedly, not every project has that same potential for growth. But hearing Wayne tell the Maker Buoy story is the sort of thing that makes you want to go dust off that project that’s been kicking around in the back of your head and finally give it a shot. You might be surprised by the kind of adventure taking a chance on a wild idea can lead to.

youtube.com/embed/cCYdSGGZcv0?…

hackaday.com/2025/04/17/superc…