Josue Meetings - FOSS aplicativo para transcrever e resumir calls

Jefferson Rodrigues — Thu, 30 Jul 2026 03:05:33 +0000

Josue Meetings é um aplicativo desktop que grava suas reuniões em segundo plano, capturando o áudio do sistema e do microfone. O aplicativo permanece na menu bar e transforma o áudio em texto utilizando o Whisper executado localmente. Depois, se desejar, gera resumos e responde perguntas usando OpenAI ou DeepSeek.

Sem servidor próprio: seus dados permanecem na sua máquina.

O problema

Toda reunião online gera informações importantes, mas quase sempre elas acabam se perdendo. Gravar o áudio, transcrever e resumir normalmente exige várias ferramentas e serviços na nuvem.

O Josue Meetings resolve tudo isso em um único fluxo, executado localmente.

Como funciona

Dê um nome para a reunião (ou utilize o padrão).
Inicie a gravação.
Acompanhe os níveis de áudio do sistema e do microfone.
Pause, retome ou finalize quando desejar.
Continue trabalhando normalmente pela menu bar.
Ao finalizar, a reunião é aberta automaticamente para transcrição.

Transcrição local

Toda a transcrição é realizada utilizando o Whisper executado na própria máquina.

Você pode exportar o resultado em:

Markdown (.md)
Texto (.txt)

Após uma transcrição bem-sucedida, o áudio pode ser removido automaticamente, preservando sua privacidade.

Inteligência Artificial (Opcional)

Com uma chave de API da OpenAI ou DeepSeek, você pode:

Gerar resumos automáticos.
Conversar com um agente sobre uma reunião.
Organizar reuniões em pastas.
Fazer perguntas considerando todas as reuniões de um projeto.

Configuração

O aplicativo possui um assistente de configuração que detecta o sistema operacional e orienta a instalação dos componentes necessários.

Atualmente:

✅ macOS: captura de sistema + microfone utilizando BlackHole e Multi-Output Device.
🚧 Windows: suporte em evolução.
🚧 Linux: suporte em evolução.

Recursos

Aplicativo desktop (Electron)
Gravação do sistema + microfone
Funcionamento na menu bar
Transcrição 100% local (Whisper)
Resumos e chat via OpenAI ou DeepSeek
Organização por projetos
Agente por pasta
Lixeira integrada
Assistente de configuração
Privacidade por padrão

Grave suas reuniões sem interromper seu trabalho, transcreva tudo localmente e utilize IA apenas quando fizer sentido, sempre com a sua própria chave de API.

O software é livre e aceitamos contribuição de pessoas bem intencionadas que queiram ajudar a melhorar cada dia mais!
Repositório do projeto

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

Jefferson Rodrigues — Thu, 26 Feb 2026 03:58:02 +0000

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

🎯 Introdução

Resolvi revisar os meus conhecimentos sobre temas essenciais da programação. Iniciei pelo SOLID porque é algo que deve ser revisitado de vez em quando para garantir que estamos entendendo não só o conceito, mas a prática também.

Com isso, podemos escrever códigos mais limpos, escaláveis e de fácil entendimento.

🛠️ Metodologia

Usei como base dois repositórios meus de quando eu estava estudando Clean Architecture. Um deles trata-se de um app simples: buscar conselhos em uma API e retornar para o usuário.

Neste projeto, aplico cada um dos cinco princípios do SOLID. Abaixo, detalho como cada um deles se comporta no código.

🟢 S — Single Responsibility Principle (SRP)

Princípio da Responsabilidade Única: Uma classe deve ter um, e apenas um, motivo para mudar.

No exemplo abaixo, a classe abstrata para o data source define apenas o contrato de busca remota. Ela não se preocupa com lógica de negócio ou como os dados serão exibidos.

abstract class AdviceRemoteDataSource {
  Future<Advice>? getAdvice();
}

Outro exemplo claro é o tratamento de erros. Criamos uma estrutura base e especializamos as falhas:

abstract class Failure extends Equatable {
  const Failure([List properties = const <dynamic>[]]) : super();
}

// Responsável apenas por erros de servidor
class ServerFailure extends Failure {
  @override
  List<Object?> get props => [];
}

// Responsável apenas por erros de cache local
class CacheFailure extends Failure {
  @override
  List<Object?> get props => [];
}

🔵 O — Open/Closed Principle (OCP)

Aberto para Extensão, Fechado para Modificação: Você deve ser capaz de estender o comportamento de uma classe sem modificar o seu código-fonte original.

A classe AdviceRepository está "fechada" (o contrato está definido). Se precisarmos de uma nova forma de obter dados, apenas implementamos o contrato em uma nova classe, sem tocar na interface original.

abstract class AdviceRepository {
  Future<Either<Failure, Advice?>>? getAdvice();
}

class AdviceRepositoryImpl implements AdviceRepository {
  final AdviceRemoteDataSource remoteDataSource;

  AdviceRepositoryImpl({required this.remoteDataSource});

  @override
  Future<Either<Failure, Advice?>>? getAdvice() async {
    try {
      final remoteAdvice = await remoteDataSource.getAdvice();
      return Right(remoteAdvice);
    } on ServerException {
      return Left(ServerFailure());
    }
  }
}

🟡 L — Liskov Substitution Principle (LSP)

Princípio da Substituição de Liskov: Objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem quebrar a aplicação.

No Flutter, isso é muito comum com os DataSources. A implementação AdviceRemoteDataSourceImpl pode substituir perfeitamente a abstração AdviceRemoteDataSource em qualquer lugar que ela seja exigida.

class AdviceRemoteDataSourceImpl implements AdviceRemoteDataSource {
  final http.Client client;
  AdviceRemoteDataSourceImpl({required this.client});

  @override
  Future<Advice>? getAdvice() async {
    // Implementação real da chamada HTTP
    // ...
  }
}

💡 Obs.: Uma melhoria seria criar um AdviceDataSource genérico, permitindo trocar o Remote pelo Local de forma transparente.

🟠 I — Interface Segregation Principle (ISP)

Segregação de Interface: Uma classe não deve ser forçada a implementar interfaces e métodos que não utiliza.

Em vez de criar uma interface gigante "TudoNoApp", dividimos em interfaces específicas. No exemplo, o repositório depende apenas do que é essencial para ele: o DataSource de conselhos.

// Interface específica e focada no domínio de conselhos
abstract class AdviceRemoteDataSource {
  Future<Advice>? getAdvice();
}

🔴 D — Dependency Inversion Principle (DIP)

Inversão de Dependência: Dependa de abstrações, não de implementações concretas.

Aqui é onde o GetIt ou Provider brilham. O AdviceRepositoryImpl não conhece a implementação do DataSource, ele conhece apenas o contrato. A "mágica" acontece no nosso Service Locator:

void setupLocator() {
  // Registramos a abstração apontando para a implementação
  getIt.registerLazySingleton<AdviceRepository>(
    () => AdviceRepositoryImpl(remoteDataSource: getIt()),
  );

  getIt.registerLazySingleton<AdviceRemoteDataSource>(
      () => AdviceRemoteDataSourceImpl(client: getIt()));

  getIt.registerLazySingleton(() => http.Client());
}

📊 Resumo Visual

Sigla	Princípio	Resumo em uma frase
S	Responsabilidade Única	Cada classe faz apenas uma coisa.
O	Aberto/Fechado	Estenda o comportamento sem alterar o original.
L	Subst. de Liskov	Subclasses devem honrar o contrato da base.
I	Segregação de Interface	Crie interfaces pequenas e específicas.
D	Inversão de Dependência	Dependa de contratos, não de classes concretas.

🏁 Conclusão

Utilizar esses conceitos na prática vai além de construir "códigos bonitos". Trata-se de garantir a manutenibilidade. Um código bem estruturado permite que ele viva mais e que as manutenções futuras não sejam um sofrimento.

Lembre-se: o seu código fala muito sobre você! 🚀

Ficou com alguma dúvida sobre como aplicar isso no seu projeto Flutter? Comenta aqui embaixo e vamos trocar uma ideia!

DEV Community: Jefferson Rodrigues

Josue Meetings - FOSS aplicativo para transcrever e resumir calls

O problema

Como funciona

Transcrição local

Inteligência Artificial (Opcional)

Configuração

Recursos

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

🚀 Revisando o S.O.L.I.D na Prática com Flutter e Dart

🎯 Introdução

🛠️ Metodologia

🟢 S — Single Responsibility Principle (SRP)

🔵 O — Open/Closed Principle (OCP)

🟡 L — Liskov Substitution Principle (LSP)

🟠 I — Interface Segregation Principle (ISP)

🔴 D — Dependency Inversion Principle (DIP)

📊 Resumo Visual

🏁 Conclusão