Oportunidades de Aplicação de Big Data em Saúde: Os Clientes e Os Pesquisadores

Posted by – 21/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Concluiremos agora essa série examinando as oportunidades que se apresentam para os Clientes e passando rapidamente por oportunidades para os Pesquisadores.

Os Clientes das organizações de saúde podem ter sua vida bastante facilitada pelos mecanismos de Big Data adotados pelos demais atores. É muito frequente que consultas sejam marcadas para uma data futura contando com a disponibilidade de resultados de exames na tal data. Essas consultas ou são inefetivas ou tornam-se simplesmente uma ausência a mais caso esse exame não esteja disponível. E isso acontece com imagem, com laboratório, com patologia e praticamente com qualquer área de apoio. Ao detectar que um determinado resultado não estará disponível, medidas podem ser tomadas para remarcar a consulta, por exemplo.

Isso é especialmente importante em hospitais terciários, que atendem muitas pessoas que não fazem parte da população local que muitas vezes enfrentaram longos deslocamentos apenas para ver sua intenção malograda pela indisponibilidade de algum dado.

Além disso, ao detectar que um perfil específico de Cliente tem uma necessidade (por exemplo, realização de coletas fora do horário comercial), o sistema pode reorganizar as demais coletas para acomodar aquele perfil, de uma maneira dinâmica, evitando que o Cliente procure outro serviço que tenha a disponibilidade de que necessita.

Propositalmente, não entraremos em detalhes dos benefícios para a população dos Pesquisadores, uma vez que acredito que sejam auto-evidentes: a disponibilidade de dados em múltiplos sistemas e a possibilidade de filtragem uma vez que esses dados estejam disponíveis permite que toda sorte de pesquisa científica seja realizada. Existem grupos coletando dados de pacientes de UTI e alertando para sepse; existem grupos de pesquisa de transplantes alertando para pacientes que desenvolverão rejeição meses antes que ela seja evidente; existem grupos que previnem a re-internação baseado na coleta remota de dados simples.

As possibilidades realmente são muito amplas e a tecnologia permite uma gama de combinações que cientistas de dados podem fazer que simplesmente não tem como ser antecipada.

Oportunidades de Aplicação de Big Data em Saúde: Os Pagadores

Posted by – 14/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Pagadores.

A penúltima população que analisamos, os Pagadores, põem-se, muitas vezes, como antagonistas dos Provedores e negam pagamentos a procedimentos já realizados de uma forma rotineira. Mas isso não precisa ser assim.

Quantas auditorias poderiam ser evitadas e quanto tempo perdido poderia ser recuperado caso as informações que fizeram um determinado procedimento ser necessário estivessem a disposição dos Pagadores no momento em que se decide por uma glosa? Ou mesmo, quantos procedimentos repetidos em diversos serviços poderiam ser evitados caso os dados compartilhados de um estivesse disponíveis para outro? Sim… estamos longe disso, mas os primeiros passos já podem ser dados agora e muita coisa pode ser feita em parceria. Nem os Provedores se beneficiam de um Pagador falido, nem os Pagadores se beneficiam de um Provedor ineficiente. Essa posição de antagonismo não precisa ser a regra.

Além disso, uma disciplina bem desenvolvida dentro do Big Data, com algoritmos bem reconhecidos e estudados e com bastante experiência acumulada é o controle de fraudes. Todo esse expertise pode ser importado por um cluster de Big Data a serviço dos Pagadores e, em paralelo com os controles hoje existentes, pode auxiliar na detecção de atividades fraudulentas, constituindo mais uma ferramenta.

Por fim, um diferencial importante para qualquer Pagador é a agilidade com que consultas e procedimentos são autorizados. Com os dados disponíveis e devidamente analisados em tempo real, esse diferencial se transforma em vantagem para seus clientes o que, em última instância, se transforma em receita.

No próximo, e último, post, analisaremos o que se espera de oportunidades do Big Data para os Clientes.

Oportunidades de Aplicação de Big Data em Saúde: A Força de Trabalho

Posted by – 07/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e comecei a analisar as oportunidades de aplicação de Big Data para cada um deles, começando com os Provedores. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outro grupo, a Força de Trabalho.

Existem diversas oportunidades que se referem a características básicas do Big Data, especialmente ao seu potencial agregador e pervasivo que podem ser aplicadas pelos e para a Força de Trabalho. Vamos tomar um médico como representante dessa categoria e vejamos, por exemplo, seu fluxo usual em um hipotético round (“round” é como tratamos, em nosso meio, a visita em série aos pacientes internados sob responsabilidade de um médico ou de uma determinada equipe):

  • O médico visita o paciente em seu leito, coleta as informações subjetivas do mesmo, atualiza um ou outro conhecimento a cerca da evolução de sua doença e volta para a sala de prescrição;

  • Na sala de prescrição ele abre o sistema 1 para verificar os últimos exames de laboratório do paciente;

  • A seguir ele abre o sistema 2 para verificar as últimas imagens e/ou seus relatórios;

  • Ato contínuo ele abre o sistema 3 para verificar se o resultado de um procedimento (por exemplo, um exame de patologia) retornou e, caso positivo, qual seu resultado;

  • De posse desse conhecimento, ele abre o sistema de prontuário eletrônico para registrar sua visita e para prescrever os próximos passos ou a continuidade do cuidado;

  • Finalmente o médico retorna para a enfermaria para visitar o paciente ao lado.

Com algumas variações e com a utilização de notas à beira do leito, os médicos podem otimizar essa rotina, por exemplo, visitando a todos e depois se retirando para “lidar” com os diversos sistemas. Dificilmente, no entanto, vão escapar de interagir com sistemas diferentes e utilizar seu bom senso para integrar os conhecimentos neles contidos. Uma perda de termpo e eficiência injustificada. Sem falar que é fácil negligenciar um desses passos (por exemplo, ao invés de verificar o sistema de patologia por algum resultado adiantado, o médico escolhe esperar os X dias que usualmente são consumidos na análise de uma peça anatômica e perde a oportunidade de tomar uma atitude assim que a informação estiver disponível).

Ora! Tecnologia para agregar todas as informações de diferentes sistemas está disponível há muitos anos e o Big Data não só a tornou acessível como eficiente. E se o médico tiver todas essas informações na mão? Suponha em um tablet ou outro dispositivo de visualização, com uma interface de busca estilo Google, ou mesmo algo mais estruturado, que aglutine todas as informações relevantes ao alcance de um toque. Ao invés de páginas e páginas de exames laboratoriais, gráficos gerados “just-in-time” com a evolução de todos os exames relevantes e com codificação de cores para indicar os que estejam fora do padrão. Da mesma forma que as notificações para os Gerentes Assistenciais, exames que saiam do padrão podem gerar alertas personalizados, que os médicos podem receber em sua interface de trabalho ou em outro dispositivo.

Outra prática onde a agregação que o Big Data é capaz de proporcionar pode ajudar essa população é a interação entre as disciplinas. O mesmo sistema de notificação pode ser utilizado para avisar de interconsultas ou pedidos de consultoria para outras especialidades. Muitos grupos fazem isso utilizando ferramentas públicas, como WhatsApp, ou celulares dedicados a grupos (como o “celular da cirugia”), mas veja que é muito mais fácil e efetivo criar uma notificação no sistema do que entrar em contato com alguém em uma ferramenta terceira e passar um caso para consultoria (ao que o destinatário poderia ter acesso completo e não a apenas uma fração). Ademais, a agregação desses metadados pode ajudar a gerar outros insights: por exemplo, pacientes que têm mais de duas consultorias solicitadas têm prognóstico mais reservado? Ou equipes que têm muitas solicitações de interconsultas têm o número de profissionais adequado?

Áreas de apoio, como patologia e SADTs também se beneficiam. Veja que a rotina intensa de trabalho (fruto da necessidade de produzir resultados cada vez mais rápido) nessas áreas leva muitas vezes a que seus trabalhadores negligenciem as informações que estão disponíveis em outro sistema e se restrinjam aos pequenos bits de informação contidas em uma papeleta que podem ou não ser relevantes e podem ou não ser completos. A qualidade do resultado cai e aumenta muito a chance de erros ou intervenções desnecessárias.

Veja que examinamos majoritariamente o caso do médico, mas praticamente toda a Força de Trabalho assistencial está em maior ou menor grau submetida a isso. Fisioterapeutas, psicólogos, assistentes sociais, todos têm rotinas parecidas e se beneficiariam dos mesmos tipos de ferramentas.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para os Pagadores.

Oportunidades de Aplicação de Big Data em Saúde: Os Gerentes Assistenciais

Posted by – 31/10/2016

No primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. No post seguinte, analisei brevemente a primeira subpopulação dos Provedores, que é composta pelos Administradores Hospitalares. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outra subpopulação deles: os Gerentes Assistenciais.

Os Gerentes Assistenciais recebem dados que permitem uma tomada de decisão “local” e em pequena escala, sem a necessidade de um processo burocrático na instância superior e que provavelmente servirá para o “melhor cenário” e não contemplará uma miríade de cenários sub-ótimos que são bastante mais frequentes.

Uma das perguntas que pode ser respondida para essa população é: Se um determinado paciente tem a necessidade de coletar um exame específico, qual o melhor momento para fazê-lo? Em um ambiente hospitalar, um paciente que se desloca entre departamentos leva consigo um funcionário (em geral um técnico de enfermagem) que vai “desfalcar” a equipe local. Fazer esse deslocamento no momento errado pode ampliar o tempo necessário para o retorno do funcionário e gerar toda a sorte de ineficiência como consequência. Muito mais efetivo é ter uma alocação dinâmica e disparar o processo de transporte no momento ótimo.

Esses Gerentes ainda podem ter acesso a notificações de processos de que eventualmente estejam responsáveis. Ao invés de ligar para a farmácia diariamente para verificar a disponibilidade de um determinado medicamento ou material, sua interface de trabalho o notifica quando um material necessário chega à farmácia.

Dependendo do grau pretendido de integração das informações, um Gerente Assistencial pode ajudar a alimentar algoritmos de aprendizado de máquina que tornem possível a automatização de diversas tarefas, acabando com a perda de tempo com as rotinas repetitivas e com a possibilidade de que tarefas essenciais sejam esquecidas em prol do “problema da vez”.

Por fim, não podemos esquecer de um sério problema que faz parte do dia a dia dos Gerentes Assistenciais em qualquer organização de saúde de médio ou grande porte: as escalas e as capacidades de cada funcionário. Através da integração com os dados do departamento de pessoal quando da ocorrência de uma falta ou quando da programação de férias, é possível rapidamente saber qual funcionário e de onde ele vai ser deslocado para cobrir a vacância. Não é incomum que esses controles sejam feitos manualmente e executados “na emergência”, muitas vezes resultando em um deslocalmento de um funcionário sem a capacitação adequada para aquele serviço, ou na criação de um novo problema em solução ao anterior. Com a integração desses dados na interface de trabalho dos Gerentes Assistenciais, resolver esses problemas se torna trivial.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para a Força de Trabalho.

Oportunidades de Aplicação de Big Data em Saúde: Os Administradores Hospitalares

Posted by – 24/10/2016

No primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Provedores, especialmente para uma subpopulação deles: os Administradores Hospitalares.

Os Administradores Hospitalares devem primar pela prestação de serviços com a melhor qualidade possível dentro do orçamento proposto. Clínicas e hospitais em geral têm departamentos para cuidar da relação com fornecedores e da qualidade de suas compras e embora o Big Data possa ter algum papel aqui, esse já é um caso coberto por ferramentas tradicionais e com processos provavelmente mais bem definidos e aceitos dentro das instituições. Há um papel paralelo para o Big Data nesse caso, quando não houver interesse de fazê-lo protagonista, mas analiso esse caso mais tarde.

Onde o Big Data brilha, nesse caso, é na gama de ferramentas que disponibiliza para avaliação e tomada de decisão em tempo quase real. Um cluster de Big Data pode, por exemplo, através do consumo de dados on-line dos prontuários eletrônicos e de outros sistemas com base no paciente (por exemplo, farmácia), apontar qual o paciente é um potencial risco econômico (pacientes que, por causa do perfil da doença, do tipo do seguro-saúde ou das interações da equipe médica com a prescrição, têm potencial para dar prejuízo ao hospital) e sugerir medidas para mitigar esse risco.

Outra oportunidade para os administradores hospitalares é a monitoração em tempo quase real da ocupação dos serviços e a sugestão, através de algoritmos de aprendizado de máquina e das redes neurais, da alocação ótima de recursos. Por exemplo, se pacientes de um determinado seguro-saúde ou convênio, com uma determinada faixa etária ou com determinados perfis preferem realizar exames de SADT em determinados horários enquanto outros perfis de paciente não têm preferência, será que não é mais custo-efetivo alocar os pacientes com expectativas mais restritas nos horários adequados do que arriscar perdê-los?

Outro exemplo é a otimização das agêndas de consultas ou de realização de exames conforme a sazonalidade ou as condições do tempo (com previsão de chuva posso fazer “overbooking” já que conto com um maior absenteísmo na nossa população?).

Além disso, as ferramentas de Business Inteligence provavelmente já em uso pelos administradores podem tanto se alimentar de dados de um cluster Big Data quando alimentá-lo, oferecendo uma convergência e uma riqueza de dados muito maior para os tomadores de decisão da organização.

Por fim, mas sem a pretenção de esgotar as oportunidades, tudo que envolve a assistência médica pode ter seu pagamento negado a posteriori. Desde internações até procedimentos e medicamentos podem ser “glosados” pelos Pagadores, deixando o Provedor com uma conta “perdida”. Existem algoritmos que empresas estadounidenses utilizam para evitar fraudes que podem ser perfeitamente adaptados para identificar quais são as contas que estão sob risco de glosa. De posse dessa informação em um momento anterior, o Provedor pode tomar medidas que mitiguem o risco econômico ou que até previnam a ocorrência da glosa.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para outra subpopulação dos Provedores, os Gerentes Assistenciais.

A matemática do recrutamento ideal

Posted by – 20/10/2016

Em 2016 a Propus completará 13 anos. Como boa parte das empresas de TI, nasceu da união de amigos “micreiros”: especificamente, de amantes do software livre e do código aberto, que resolveram “colocar o dinheiro onde está nossa boca” e testar esse modelo de negócios. Muitos altos e baixos depois, algumas reformulações e passadas algumas crises econômicas, acho que finalmente chegamos a um sistema de recrutamento adequado. Ou, ao menos, o último processo seletivo que conduzi deixou-me mais satisfeito do que jamais estive antes.

Em primeiro lugar, vamos deixar claro: contratar bons funcionários é difícil. E contratar bons funcionários em uma empresa de TI é provavelmente ainda mais difícil. A Propus se orgulha de contratar hackers – afinal de contas, essa é uma empresa de hackers – logo, sabemos bem como é difícil. (Spoiler: se você é hacker, por favor, entre em contato!).

No começo nosso processo era bastante enxuto: uma troca de email e uma entrevista simples e era bastante fácil saber quem queríamos. Depois, certificações começaram a ser consideradas e, especialmente no caso de desenvolvedores, líamos os códigos escritos pelo candidato. Passamos pela fase da avaliação psicológica, da avaliação por consultoria terceirizada, até da avaliação “grafológica”! Chegamos mesmo a aplicar pequenas provas com conhecimentos básicos que precisávamos.

Em outro momento, mantivemos um programa de estágio com o objetivo expresso de contratar os que se saíssem melhor no programa. Embora essa seja uma abordagem que gostamos muito, às vezes não dá para esperar até algum estagiário “ficar pronto”, ou correr o risco de que, naquele ano em especial, nenhum estagiário tenha se saído particularmente bem para ser contratado como profissional.

Esse era um problema sem solução, usualmente abordado da maneira tradicional: anúncio em jornal e listas de discussão ou fóruns na Internet, análise de currículo e entrevista. No último processo que conduzimos dessa forma, recebemos mais de 100 currículos, dos quais cerca de 30 eram “perfeitos para a vaga”, o que gerou 30 entrevistas e… nenhuma contratação. Isso mesmo! Nenhuma das 30 entrevistas de fato se encaixava na análise prévia do currículo.

O grande problema é que o tempo investido nessa seleção e nessas 30 entrevistas foi muito grande e o resultado foi muito ruim. A experiência havia sido tão traumática que simplesmente passamos a evitar ter de contratar até o último instante (e mesmo depois de passado o último instante). Isso nos levou a firmar o propósito de desenvolver um sistema de recrutamento que se adequasse à nossa empresa e passamos a buscar algumas inspirações. Uma dessas inspirações foi o TrueAbility. Que sisteminha interessante! Você testa na prática os conhecimentos dos candidatos e extrai um resumo do rankeamento deles. Que vontade de simplesmente utilizar esse sistema. Seu único problema: não está traduzido para o português. A julgar pela amostra das últimas seleções, embora a maioria dos candidatos entenda razoavelmente o inglês (com alguns poucos fluentes no idioma), não queríamos que a habilidade de entender inglês prejudicasse algum candidato em potencial, o que relegou o TrueAbility a um segundo plano.

No entanto, a ideia de testar um candidato na prática passou a dominar a nossa visão de como desenhar o novo processo. Nós acabamos bolando uma máquina virtual recheada de problemas que costumamos enfrentar no dia a dia com nossos clientes – na verdade, todos os problemas da máquina virtual vieram de clientes e apenas foram adaptados para o nível da vaga e conter uma solução definitiva. Agora, onde encaixar esse teste prático?

Para encurtar o assunto, nosso processo acabou sendo formatado nas seguintes etapas:

  1. Anúncio (listas, jornal, LinkedIn etc);
  2. Coleta de currículos;
  3. Triagem geográfica (o candidato está onde precisamos dele? Se não está, pode/quer se mudar para o local de trabalho?);
  4. Triagem econômica (o candidato tem pretensão salarial compatível com a vaga ofertada? Se não tem, aceita as condições daquela vaga?);
  5. Análise de currículo (o candidato declara possuir os requisitos exigidos para a vaga? Esse é o momento para esclarecer alguma dúvida por email);
  6. Teste prático;
  7. Entrevista;
  8. Contratação.

Note que encaixamos o teste prático na máquina virtual antes da entrevista e, até a entrevista propriamente dita, todas as comunicações foram ou por telefone ou por email. Mesmo o teste prático é realizado remotamente.

Na última seleção testamos esse processo com um anúncio no LinkedIn. No período de coleta dos currículos, 94 foram enviados. Apenas 13 sobreviveram para chegar ao teste prático (o que já seria uma grande melhoria em relação à seleção anterior: melhor entrevistar 13 de 94 do que 30 de 100!). O teste prático cortou esse número em outros 50%. Somente 6 chegaram nele, o que é a demonstração do que havíamos detectado empiricamente no passado: a análise do currículo deixa muita margem a dúvidas.

Como maneira de avaliar nosso novo processo, acabamos entrevistando os 13 candidatos, mesmo os que foram cortados pelo teste prático. Embora presumindo algum viés – afinal, o entrevistador já conhecia o resultado do teste prático no momento da entrevista – essa ação acabou demonstrando que realmente o teste prático ajuda muito e, em um próximo processo seletivo, devemos entrevistar apenas os que forem bem rankeados no teste prático.

No final das entrevistas, havíamos localizado nosso futuro funcionário! E não foi o que melhor se saiu no teste prático. Ou seja, a entrevista é importante, como pudemos demonstrar. É como diz o Joel Spolsky (outra grande inspiração): “when you find the smart, gets-things-done candidate, you’ll know it”.

(Originalmente publicado no LinkedIn).

Oportunidades de Aplicação de Big Data em Saúde

Posted by – 22/03/2016

O campo da saúde é uma área heterogênea que envolve muitos atores com interesses ora sintônicos ora antagônicos e oferece muitas oportunidades para aplicação das disciplinas do Big Data.

Em primeiro lugar, quais são os atores e como podemos agrupá-los para estudar que oportunidades existem e podem ser oferecidas? A seguir um esboço que não pretende ser completo. Nos demais artigos dessa série explorarei cada um deles.

  • Provedores: são os que entregam diretamente os serviços de saúde, como hospitais e clínicas. Esse grupo está mais interessado no gerenciamento da saúde e da entrega de seus serviços e são mais parecidos com entidades de administração, preocupados com a gestão dos custos e a manutenção da qualidade. Duas subpopulações são facilmente identificáveis:

    • Administração: são os que gerenciam as contas, compras, relacionamento com pagadores, etc

    • Gerenciamento Assistencial: são os que cuidam para que os clientes tenham suas necessidades atendidas e estão interessados no fluxo de atendimento e na otimização dos processos intra e interdepartamentais

  • Força de trabalho: são os que trabalham na “última milha”, responsáveis pela prestação do serviço, tais como médicos, laboratoristas, técnicos de enfermagem ou de radiologia, etc

  • Pesquisadores: são os que consomem dados coletados pela força de trabalho para gerar estudos científicos e econômicos.

  • Pagadores: são os que pagam pelos serviços de saúde, em última análise, no Brasil, convênios e seguros saúde ou as diversas esferas governamentais. Uma parcela menor de pagadores são os próprios pacientes e são um caso particular do próximo grupo.

  • Clientes: são os que recebem os serviços de saúde, os pacientes. Como escrito acima, alguns desse grupo também são pagadores, mas a regra geral é que são clientes não diretamente pagantes (possuidores de seguro-saúde ou pacientes do SUS).

Tendo esses atores em vista, quais são as oportunidades de aplicação das disciplinas de Big Data para cada um deles ou conjunto deles? Vamos analisar isso em detalhes nos próximos posts.

(Originalmente publicado no site da Propus).

Duas dicas para acelerar o APT

Posted by – 30/11/2015

Às vezes você só quer um pouco mais de velocidade nos downloads do APT e não tem muito como modificar muito a instalação do cliente. Duas dicas simples podem ganhar minutos preciosos:

Coloque em algum dos /etc/apt.conf.d (sugiro criar o /etc/apt.conf.d/71parallel) a seguinte linha:


Acquire::Queue-Mode "host";

Isso faz com que o modo de queue do APT seja orientado ao host e não ao tipo de URL. Dependendo dos seus sources, isso acelera mais do que o modo access padrão.

A segunda dica é um hack que encontrei há algum tempo em um blog que faz o download prévio das URLs que serão utilizadas na operação do APT para o /var/cache/apt/archives usando xargs:

Ajuste os parâmetros NBATCH e NPARALLEL e boa sorte.

Last Subversion repository decommissioned – at last!

Posted by – 01/10/2015

Today I completed the git migration of the last Subversion repository we still had online at Propus.

Nothing different from what we had done for all the rest, but this was an old repository, mostly with unmaintained code, modeled after “project-as-subdirectory” style… Good old days…

Two scripts – I am sure people can find somewhere else on the Internet – are worth pasting here:

First, I detected 3 revisions committed by root user. The first two matched the creation of first two projects (AKA directories), so I mapped the three of them to the same person (who had this bad habit of logging as root). It ended up I was wrong for the third revision: it was the beginning of a new project, but by a different person. Since the authors file maps one-to-one, “root” could only be one and the person.

So, after the migration, I just use filter-branch to fix that particular commit. Trivial, but worth a gist:

Lastly, there are some projects (mapped as subdirectories in the new git repo), that we’d like to split from the “archived” do keep using or adding to them. They will become active projects again. So, we cloned the whole repo again, and used filter-branch to the rescue:

Since that was the last Subversion repository still alive, I’d like to end this post with a thanks for all the years of good service! Time to move on…

Such a big directory…

Posted by – 17/09/2014

There’s no easy way to list files in a 10-million-file directory. Our beloved find and ls will almost never do it without requiring your whole week. I know it’s a bad design to have such a beast in place, but hey… we don’t always control the design of things our customers like to deploy. And some customers seems to like to defy logic sometimes.

Anyway, having to work with such thing requires some special plumbing. I usually code something quick using getdents in C, but I always forget to put it around and end up coding everything again everytime. I was about to upload it to github this time, but I found something already there. So this is just a heads up if there’s anyone out there needing this.

Simple CGI MJPEG Streamer in Bash

Posted by – 30/06/2014

This is mainly just for personal reference; I’m posting here since it may help someone else. I am sending images captured in surveillance IP cameras via FTP to some hosting. This is for convenience, since any cheap surveillance IP camera has this facility. So, how to watch in near-real-time without having to refresh the browser or using some javascript trickery? Also, How to watch using common IPcam mobile clients?

Easy enough: just create a MJPEG stream and use a CGI-capable HTTP server for the job. Some quick hacking (and inotify abuse) gave me the following Bash script:

Now, I just have to figure-out how to kill the process afterwards 🙂

O Movimento Software Livre Morreu. Longa Vida ao Movimento Software Livre!

Posted by – 09/06/2014

Assistindo ao debate “Morreu o Movimento Software Livre no Brasil?”, do FISL15, resolvi compilar diversos pontos que foram marginalmente abordados no debate e que flutuam na minha cabeça há algum tempo, merecendo um aprofundamento nesse contexto.

Movimento Software Livre e Ideologias Alienígenas

O Movimento Software Livre é uma expressão, no âmbito técnico, do anseio natural de liberdade do ser humano. Foi o precursor de diversos movimentos de cultura livre que, de certa forma são mais antigos ainda que o próprio Software Livre, mas que até então não possuiam ferramentas coerentes para se desenvolver. No entanto, como todo movimento, é habitado por pessoas que têm aspirações diferentes e muitas vezes essas pessoas confundem suas próprias e particulares aspirações com as do movimento, levando a uma “identificação ideológica cruzada”, que acaba associando ao movimento Software Livre diversas outras ideologias de maneira até equivocada.

Embora o próprio Stallman não seja um comunista (expresso por suas ações ao longo da vida, mas literalmente também escrito por ele mesmo), o Movimento Software Livre acabou, em diversos lugares – inclusive o Brasil – sendo capturado pelo espectro da esquerda política. E isso só fez mal ao Software Livre. (Seria igualmente ruim se fosse capturado pela direita política, veja bem.) Isso fica amplamente evidente quando fazemos o contraponto entre Open Source e Free Software e identificamos isso como um embate entre capitalismo e comunismo, como foi feito no debate em questão. Nenhuma discussão poderia ser menos produtiva e mais equivocada do que essa! Especialmente porque não existe nenhuma incompatibilidade entre as 4 liberdades que definem um Software Livre e os 10 pontos da definição de Software de Código Aberto.

Exatamente. Para que fique bastante claro vou colocar em um parágrafo separado: não existe nenhuma incompatibilidade entre as 4 liberdades que definem um Software Livre e os 10 pontos da definição de Software de Código Aberto. Portanto, não há um conflito conceitual entre Software Livre e Software de Código Aberto, muito menos um conflito semelhante ao embate capitalismo versus comunismo.

More

Goodbye Jorte, hello ownCloud

Posted by – 30/05/2014

After I migrated from Palm Treo to Android phones, I was very displeased with the Calendar application. I don’t use Google Apps (my phone is AOSP), which only leaves me with (argh!) Exchange for online-synced calendar. Besides, the first incarnations of the Calendar application in AOSP were barely usable.

So I just went for a standalone free (as in beer) Calendar application named Jorte, which is really good. Recently, I’ve been investigating ownCloud and CalDAV, and decided to review the state of current AOSP Calendar application. To my surprise, it have evolved a lot (to the point of being usable), but still no CalDAV sync.

So I found DAVdroid in F-droid repository, which is an interesting application that can register a CalDAV account that is usable by AOSP Calendar. So, now, I am able to use ownCloud calendaring, ownCloud CalDAV server and my phone, and, since free-as-in-speech software is much better than free-as-in-beer, I decided to ditch Jorte.

But Jorte doesn’t have an option to export its data to an Icalendar file (why make things easy, right?). All it spits is a csv-file as a backup. (As a side-note, Jorte seems to intentionally not provide an Icalendar-file export option… as the ‘rrule’ field they use in the csv follow the same rules Icalendar standard dictates, they might be using it internally). Since this is pretty trivial stuff, I just coded a Ruby script to do the job. I released it to my github repo, just in case anyone else finds it useful.

ConQuest DICOM Server

Posted by – 03/04/2014

I’ve been busy with Real Life™ lately, but I managed to get some time to work on ConQuest DICOM Server packaging for Debian. I’m almost reaching upload state. The work can be checked at GitHub.

It’s compiled for i386 in an unsigned APT repo, if anybody wants to play with it before I upload. These are the sources:

# Wheezy
deb http://people.debian.org/~spectra/debian spectra-wheezy/
# Sid
deb http://people.debian.org/~spectra/debian spectra-sid/
# Ubuntu Saucy
deb http://people.debian.org/~spectra/ubuntu spectra-saucy/

Enjoy it.

Nostalgia time

Posted by – 03/12/2012

My parents will soon be moving to a smaller home, so they are digging up a lot of stuff of my sister and mine past. Among my stuff, they just sent me my first computer (which was, of course, the first computer of my father’s company I was using in the spare time). I couldn’t believe they kept that. It was an Unitron Apple ][ 64K!! I just had it cleaned and took this picture:

Due to the closed informatics market Brazilians were subject to at the time, it came with a full set of manuals in Portuguese which taught me how to code in Basic (I was too young to learn English at the time)… Interesting how a bad policy like that can result in a Good Thing™ sometimes. 🙂

Is it just me or does this picture made you nostalgic also?