Quantas Bolhas em Um Copo de Cerveja?

Depois de derramar cerveja em um copo, nuvens de pequenas bolhas aparecem e começam a subir, formando uma camada espumosa no topo. À medida em que as bolhas estouram, o gás carbônico liberado transmite o aroma e o sabor tão desejados da bebida. Mas quantas bolhas existem em um copo de cerveja? Ao examinar vários fatores, os pesquisadores que fazem este relatório da Sociedade Americana de Química – ACS Omega – calculam que entre 200.000 e 2 milhões dessas minúsculas esferas podem se formar em um copo de cerveja gentilmente despejada.

As curvas de bolhas da cerveja e do champagne. Nota-se que as bolhas da cerveja crescem em uma razão mais explosiva que as do champagne

Como sabemos, em todo o mundo a cerveja é uma das bebidas alcoólicas mais populares. As Lagers levemente aromatizadas, que são especialmente apreciadas, são produzidas através de um processo de fermentação fria, convertendo os açúcares dos grãos maltados em álcool e dióxido de carbono. Durante a embalagem comercial, mais carbonatação pode ser adicionada para obter um nível desejado de espuma. Se você ainda não sabe, é por isso que garrafas e latas de cerveja quando abertas liberam bolhas de micrômetros de diâmetro. Essas bolhas são elementos sensoriais importantes na degustação da cerveja, que nesse sentido é semelhante aos vinhos espumantes.

Gérard Liger-Belair havia descoberto anteriormente que cerca de 1 milhão de bolhas se formam em uma taça de champanhe, mas os cientistas ainda não sabiam o número criado e liberado pela cerveja antes de se acomodar no copo. Então, Liger-Belair e Clara Cilindre resolveram examinar a questão. A seguir o resumo e o link para o estudo integral.

Resumo

O número de bolhas susceptíveis de se formar em um copo de cerveja é o resultado da sutil interação entre CO2 dissolvido, pequenas partículas e imperfeições no vidro, que atuam como locais de nucleação e ascenção dinâmica das bolhas. Desenvolvimentos experimentais e teóricos sobre o equilíbrio termodinâmico do dióxido de carbono dissolvido e fase gasosa (CO2) foram considerados relevantes para o engarrafamento e serviço [do verbo ‘servir’] de uma cerveja Lager comercial, com 5% de álcool em volume e uma concentração de aproximadamente 5,5 g L-1 de CO2 dissolvido. Foi derivado o raio crítico e a subsequente concentração crítica de CO2 dissolvido necessária para desencadear nucleação heterogênea de bolhas de CO2 nas microfissuras do copo, logo após a cerveja ser servida. O número total subseqüente de bolhas de CO2 que provavelmente se formarão em um único copo de cerveja foi teoricamente abordado como uma função de vários parâmetros-chave em condições de degustação padrão. Os resultados apresentados aqui com a cerveja Lager foram comparados com conjuntos de dados anteriores medidos com champanhe comercial padrão (com álcool de 12,5% em volume e uma concentração de CO2 dissolvido próximo a 11 g L-1).

Link para o estudo original, um sério candidato ao prêmio IgNobel deste ano.

Toyota lança o Conceito bZ, Uma Linha ‘Carbono Zero’

Eu gosto de carros. E tenho um blog. Isso seria motivo suficiente para dar espaço à industria automotiva neste cantinho da Internet. Mas os automóveis não precisam de meus motivos para estar aqui. Eles são legítimos participantes da vida tecnológica, e estar em dia com a evolução no campo que vai da eletrificação à eletrônica embarcada nos automóveis é uma obrigação de todo tecnologista. Assim, vamos falar do belo Toyota bZX4 – um dos primeiros sites a fazê-lo em língua portuguesa.

Apesar da sua forte insistência em ‘powertrains’ híbridos anteriormente, a Toyota agora mudou parte de seu foco para veículos totalmente elétricos, apresentando o SUV elétrico bZ4X para “abrir caminho para um futuro mais sustentável.”

Divulgação

Encaixando-se na linha beyond ZerobZ [“além de Zero”, em referência às emissões de carbono] da montadora japonesa, o novo conceito SUV representa um salto à frente no domínio dos elétricos, com a missão de alcançar a neutralidade em carbono até 2050.

O conceito Toyota BZ4X aponta para outra opção em nosso já robusto portfólio eletrificado

Enquanto detalhes específicos sobre o conceito permanecem escassos, a Toyota espera iniciar a produção de uma versão Pronta Para a Estrada o mais rápido possível, e lançá-la em meados de 2022. Uma vez pronto, o bZ4X será um dos 70 modelos de carros elétricos a serem oferecidos pela montadora até 2025, quinze dos quais serão totalmente elétricos (não híbridos).

Divulgação

“O conceito Toyota bZ4X aponta para outra opção em nosso já robusto portfólio eletrificado” disse Bob Carter, vice-presidente executivo de vendas das operações norte-americanas da Toyota. “Na Toyota, somos uma empresa centrada em seres humanos – o cliente é nosso CEO e, no final, é quem decidirá quais tecnologias nos levarão para um futuro neutro em carbono. Com investimentos e ofertas de produtos em todo o espectro de eletrificação, pretendemos estar presentes com produtos e tecnologias que atendam às diversas necessidades dos clientes em todo o mundo. “

Divulgação

Claro que, sendo um conceito, ainda não há detalhes concretos sobre o preço do SUV bZ4X, de modo que os interessados ​​devem ficar alertas para atualizações da notícia.

(*)Em outras notícias e outros becos da indústria automotiva, a Audi revelou oficialmente seu Q4 E-Tron.

Divulgação

Pelo que apuramos, o Toyota bZ4x tem as seguintes características:

  • Usando uma plataforma específica para Veículo Elétrico à Bateria [Battery Electric Vehicle, BEV], o bZ4X combina uma distância entre eixos longa com um comprimento total curto; isso resulta em um design distinto e em um espaço interior comparável a um sedan do segmento D.
  • Um volante de formato único [ver foto no final do post] elimina a necessidade de alterar a pegada ao fazer curvas e também contribui para um interior espaçoso; o veículo adota um sistema de direção “by wire”, que dá uma sensação de condução suave, alinhada com as intenções do motorista.
  • A posição rebaixada do painel de instrumentos e a localização dos mostradores acima do volante servem não apenas para melhorar o senso de espaço do veículo, mas também melhorar a visibilidade e contribuir para uma condução segura.
  • O bZ4X adota um novo sistema AWD desenvolvido em conjunto pela Toyota e Subaru. Ele promete combinar um desempenho seguro e agradável na condução – realçado pela responsividade única dos veículos eletricos – com um impressionante desempenho off-road.
  • Além do uso de sistemas de energia regenerativa (KERS), o veículo também adota um sistema de recarga solar; isso inteligentemente recarrega a bateria enquanto estacionário e aumenta ainda mais o desempenho ambiental. Ele também promete uma autonomia inigualável.

A Toyota tem atualmente 22% de sua linha global de produtos eletrificada de alguma forma. No ritmo das necessidades dos clientes, à medida em que eles se movem em direção aos produtos Hybrid / BEV / FCEV, a Toyota eliminará lentamente os veículos de combustão interna.

Divulgação

Moderadores do Facebook: ‘Somos as Amídalas da Internet’

Na manhã do último dia 14 de abril, um repórter Senior de notícias de tecnologia do Buzzfeed compartilhou o que parecia ser um relato angustiante do que é trabalhar como um moderador de conteúdo no Facebook.

A nota interna anônima sinalizando a renúncia do empregado foi lançada no Twitter por Ryan Mac em uma série de nove prints. O suposto funcionário em questão é baseado em Austin, TX e trabalha para a Accenture, uma empresa que fornece funcionários para moderação de conteúdo no Facebook.

Um moderador de conteúdo do Facebook contratado pela Accenture em Austin se demitiu esta manhã com uma ácida nota interna. Eu digitei na íntegra para que as pessoas possam ler por si mesmas.

A mensagem descreve a moderação de conteúdo como um trabalho desgastante tanto do ponto de vista mental como físico, que levou alguns de seus colegas de trabalho a entrar em medicação psiquiátrica pela primeira vez ou se auto-medicar com álcool e drogas.

As experiências traumatizantes dos moderadores de conteúdo são bem documentadas ao longo dos anos em publicações como Wired Magazine.

O funcionário em questão alegou que o Facebook fez melhorias em seu programa de bem-estar, mas sustenta que elas ainda são inadequadas, afirmando que “os gerentes vêem os cérebros dos funcionários como máquinas”, em vez de levar em conta as conseqüências do estresse no ambiente de trabalho.

“A questão real, no entanto, não é o impacto persistente de imagens individuais; é o acúmulo de milhares delas ao longo do tempo”, escreve o moderador anônimo. “Os analistas de conteúdo são pagos para olhar o pior da humanidade por oito horas por dia. Somos as amígdalas da Internet, uma primeira linha de defesa – constantemente bombardeada – contra potenciais traumas para a base de usuários.”

O empregado logo descobre que o contrato de confidencialidade, assinado por todos os funcionários quando entram na empresa, torna difícil manter a saúde mental, bem como se candidatar a outros empregos, uma vez que eles não podem discutir os detalhes de sua atividade como moderadores de conteúdo. Soluções propostas incluem treinamento em saúde mental para gerentes, mais tempo em atividades de bem-estar e capacidade de acesso a terapia, entre várias outras sugestões.

O repórter do Buzzfeed propôs que, se executivos como Mark Zuckerberg passassem um tempo experimentando pessoalmente o trabalho de moderação de conteúdo, eles talvez pudessem ficar mais dispostos a fazer melhorias. No entanto, quando questionado em 2019 pela congressista americana Katie Porter, Zuckerberg disse que esse não seria o melhor uso de seu tempo.

Código: O Que Há em Um Nome

Este post registra em português o recém lançado pre-print de um estudo que avalia a maneira como os nomes de funções e variáveis são normalmente usados na composição de um programa de computador, e qual seu impacto na facilidade de compreensão e manutenção do código. O trabalho sugere que sejam usados nomes menos obfuscados e mais expressivos na nomenclatura desses elementos de código, como no exemplo:

// Este fragmento mostra os nomes, obfuscados e
// inexpressivos, para a função exibeNum() e suas variáveis
// internas n1 e n2

void exibeNum(int n1, float n2) {
    cout << "O número int é: " << n1;
    cout << "O número float é: " << n2;
}

// Este fragmento mostra uma nomenclatura mais clara e
// expressiva para as mesmas funções e variáves, 
// agora renomeadas

void funcao_que_exibe_numero(int numero_1, float numero_2) {
    cout << "O número int é: " << numero_1;
    cout << "O número float é: " << numero_2;
}

Este é um daqueles assuntos que nunca são citados nominalmente, mas que estão logo abaixo da superfície, e são fundamentais para produtividade de uma equipe de programação. Ao trabalho:

Resumo

Os nomes de variáveis ​​e funções servem como documentação implícita e são instrumentais para a compreensão de um programa. Mas escolher nomes bons e significativos é difícil. Realizamos uma sequência de experimentos em que um total de 334 sujeitos são obrigados a escolher nomes em determinados cenários de programação. O primeiro experimento mostrou que a probabilidade de que dois desenvolvedores selecionassem o mesmo nome era baixa: Nas 47 instâncias de nossos experimentos, a mediana de probabilidade foi de apenas 6,9%. Ao mesmo tempo, depois que um nome específico é escolhido, ele geralmente é entendido pela maioria dos desenvolvedores. A análise dos nomes fornecidos no experimento sugere um modelo em que a nomeação é um processo (não necessariamente consciente ou serial) de três etapas: (1) Selecionar os conceitos a serem incluidos no nome, (2) Escolher as palavras para representar cada conceito, e (3) construir um nome usando essas palavras. Um experimento de acompanhamento, usando a mesma configuração, então verificou se o uso explícito desse modelo pode melhorar a qualidade dos nomes. Os resultados foram que os nomes selecionados por assuntos utilizados pelo modelo foram julgados, por dois juízes independentes, superiores aos nomes escolhidos no experimento original, em uma proporção de dois para um. O uso do modelo parece incentivar o uso de mais conceitos e nomes mais longos (grifos nossos).

Link para o trabalho integral em ArXiv

Ano do Jubileu para o FTP

O dia 16 de abril de 1971 não é apenas a data em que os Rolling Stones lançaram Brown Sugar, mas também é lembrado, no mundo da Tecnologia da informação, pela publicação da RFC 114 marcando o dia do nascimento do FTP [File Transfer Protocol – Protocolo de Transferência de Arquivo].

Naqueles dias, este bloguista, infante, ainda achava que o mundo era mágico. A guerra do Vietnã estava na vanguarda das notícias; o TCP/IP ainda não existia; Jimi Hendrix tinha morrido há 6 meses; o Telnet era o novo “cool kid” e alguns dos artistas de rock’n’roll mais influentes estavam perto de lançar inesquecíveis obras-primas [Imagine, John Lennon, e.g.] – enquanto o FTP ainda usava um protocolo de rede chamado NCP [Network Control Protocol].

FTP – O mais popular protocolo de transferência de arquivo

Ao longo dos anos, o protocolo FTP foi refinado com 16 revisões diferentes[1], adicionando suporte com TCP/IP, uma extensão segura também conhecida como FTPS – que aproveita a mesma tecnologia que o HTTPS – e adições mais recentes, como suporte IPv6.

Cinquenta anos após o seu início, o protocolo ainda está muito forte, com milhões de servidores FTP ainda expostos na internet, o que é bastante surpreendente, considerando a má publicidade que recebe de algumas pessoas, empresas e instituições, que escrevem sobre o quão ruim o FTP está sendo ao vender o protocolo como um produto completo [mesmo que em muitos casos, o mais próximo que certos críticos chegaram do FTP é alguma API proprietária muito menos inteligente, que só pode ser usada se os distintos forem gentis o bastante para te dar uma chave].

Debian Linux, por exemplo, é um dos críticos e alega que desativou seus serviços de Protocolo de Transferência de Arquivos Públicos (FTP) em 2017, porque quase ninguém os usava mais e eles são difíceis de operar e manter. “Nosso próprio instalador não ofereceu FTP como uma maneira de acessar espelhos por mais de dez anos”, disseram.

As razões são bem simples: O colaborador do Debian Cétric Boultier diz que “servidores FTP não têm suporte para cache ou aceleração”, o que provavelmente significa que o Debian tem que jogar mais hardware no FTP do que seria sensato. Ele também observa que a maioria das implementações de software clientes “estagnaram e são desajeitadas de usar e configurar… O protocolo é ineficiente e requer adições de improvisações desajeitadas a firewalls e daemons de balanceamento de carga”.

De qualquer maneira, em 2021, o que parece ser reconhecido como progresso toma a forma de protocolos proprietários, feitos a portas fechadas e sem qualquer RFC [Request For Comment]. Em vez disso, o que sobra aos desenvolvedores que desejam criar servidores concorrentes é fazer a engenharia reversa dos kits de desenvolvimento de software.

Na verdade, em um mundo ideal não deveria importar qual ferramenta se usa, mas sim se essa ferramenta é fácil de usar, se vovó pode transferir as fotos que ela deseja compartilhar, abrir vídeos e fazer todas as outras coisas que não deveriam exigir dela conhecimentos sobre protocolos – pois nosso trabalho como engenheiros de dados é abstrair todas essas coisas complicadas para que, pela magia da abstração, alguém acessando sua conta bancária no conforto de seu lar não tenha que entender de criptografia ao usar SSL.

[1] FTP ao longo dos anos:

  • RFC 114 (abril de 1971)
  • RFC 697 (julho de 1975): Comando CWD
  • RFC 765 (junho de 1980): TCP / IP
  • RFC 959 (outubro de 1985): Protocolo de transferência de arquivos
  • RFC 1579 (fevereiro de 1994): FTP compatível com firewall
  • RFC 1635 (maio de 1994): Como usar o FTP anônimo
  • RFC 1639 (junho de 1994): FTP Operation Over Big Address Records
  • RFC 1738 (dezembro de 1994): Uniform Resource Locators
  • RFC 2228 (outubro de 1997): Extensões de Segurança FTP
  • RFC 2389 (agosto de 1998): Mecanismo de negociação de recursos para o protocolo de transferência de arquivos
  • RFC 2428 (setembro de 1998): Extensões para IPv6, NAT e modo passivo estendido
  • RFC 2577 (maio de 1999): Considerações de segurança de FTP
  • RFC 2640 (julho de 1999): Internacionalização do Protocolo de Transferência de Arquivos
  • RFC 3659 (março de 2007): Extensões para FTP
  • RFC 5797 (março de 2010): Registro de Comando e Extensão FTP
  • RFC 7151 (março de 2014): Comando HOST do protocolo de transferência de arquivos para hosts virtuais.

Fonte: Adaptado de filestash.app