Historia-Da-Computacao | AkitaOnRails.com

História da Computação e Retro Dev no YouTube

Mon, 19 May 2025 15:19:00 -0300

Eu assisto MUITO YouTube, e fico sempre compartilhando coisas legais que assisto no meu X e Instagram (me sigam lá). Tem vários videos que vira e mexe eu volto atrás.

Finalmente resolvi compilar uma lista com os canais que eu mais assisto e uma lista das principais playlists e exemplos de videos de cada canal que recomendo assistir.

Provavelmente vou ficar voltando nesta página pra atualizar de tempos em tempos. Se alguém se lembrar de algum que eu esqueci, mandem nos comentários. Tem canais como GameSack ou Sega Lord X ou Retro Game Corp ou Wullfden ou Macho Nacho Productions e vários outros assim que não listei, porque são mais de “reviews” e não cruzam tanto com “dev”. Tentei focar em coisas que eu acho que um “dev” deveria saber.

Lista (2025-05-19)

[Akitando] #97 - Só Precisamos de 640 kB de Memória? | 16-bits até 64-bits!

Thu, 13 May 2021 10:41:00 -0300

DESCRIÇÃO

Um dia nos disseram que 640 kilobytes de RAM é o suficiente pra tudo que a gente precisasse. Isso foi no começo dos anos 80. Hoje quero mostrar como a gente lidava com essa limitação no MS-DOS, como era na geração anterior e como ficou na transição pra 32-bits, depois pra 64-bits, e porque isso é relevante pra você, como programador.

Hoje vamos ter História!

Conteúdo:

00:00 - Intro
01:25 - Recapitulando Mappers de 6502
08:48 - MS-DOS
12:13 - Segmento:Offset = 20 bits
18:50 - HMA, UMB, EMS, XMS
23:31 - Config.sys
27:51 - modo protegido e virtualização
31:26 - AWE/PAE
32:17 - swap/page faults
38:42 - 64-bits
41:26 - NX Bit/DEP
47:25 - Conclusão

Links:

Tutorial of ARM Stack Overflow Exploit – Defeating ASLR with ret2plt (https://www.fortinet.com/blog/threat-research/tutorial-of-arm-stack-overflow-exploit-defeating-aslr-with-ret2plt)
How do ASLR and DEP work? (https://security.stackexchange.com/questions/18556/how-do-aslr-and-dep-work)
Memory Prices 1957+ (https://jcmit.net/memoryprice.htm)
Mastering x86 Memory Segmentation (https://www.eejournal.com/article/mastering-x86-memory-segmentation/)
Configuring your MS-DOS properly (https://www.cubic.org/docs/configuring.htm)
Autoexec.bat and config.sys information (https://www.computerhope.com/ac.htm)
4DOS Introduction and Installation Guide (https://wiki.preterhuman.net/4DOS_Introduction_and_Installation_Guide)
The GRUB MBR (https://thestarman.pcministry.com/asm/mbr/GRUB.htm)
NES EMULATION (https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2009/bhp7_teg25/bhp7_teg25/index.html)
6502 Instruction Set (https://www.masswerk.at/6502/6502_instruction_set.html)
ROMs and Mappers: Why NES Games Can Be So Different On The Same Hardware (https://abad1dea.tumblr.com/post/187429390285/roms-and-mappers-why-nes-games-can-be-so)

SCRIPT

Olá pessoal, Fabio Akita

Hoje vai ser um video bem puxado. O pior é que metade dos detalhes técnicos que vou explicar, na prática você nunca precisaria saber, mas quero explicar mesmo assim. Minha idéia é continuar um pouco aqueles vídeos de introdução à computação e videogames onde comecei a explicar sobre a arquitetura de 8-bits de processadores como o 6502 da nintendinho e acelerar em direção a como era nos PCs na era dos 16-bits e o que significa migrar pra 32-bits e depois pra 64-bits do ponto de vista de escovação de bits.

Se alguém tentou programar um pouco no fim dos anos 80, deve se lembrar da barreira dos 640 kilobytes de RAM. Boa parte de hoje vai ser explicar sobre o que era isso e como a gente fazia. Quem já começou hoje, na era de 64-bits, não sabe a sorte que tem de ter endereços sobrando de memória. Pra vocês vai ser bom pra entender porque programador velho fica ranzinza falando que programar hoje é bem mais fácil que antigamente. Vamos entender de onde vem isso.

Como eu falei antes, metade das técnicas que vou falar hoje e metade dos termos que vou falar são legados. Pense mais como curiosidade de museu do que alguma coisa que você deveria saber de cabeça. Mas acho que a noção de como as coisas funcionavam pode dar insights de como você enxerga programação hoje e como as coisas podem evoluir a partir daqui. Então vamos lá.

(…)

Vamos voltar um pouco atrás nos episódios. Vocês vão se lembrar que falamos rapidamente sobre os videogames de 8-bits, que usavam processadores 6502 ou derivados e como eles carregam dados de cartuchos, que são basicamente chips de memória ROM, com um certo range, ou intervalo de endereços. Toda vez que um jogo precisa de mais de 40 kilobytes de memória, o cartucho pode trazer um chip controlador, um mapper.

Eu expliquei isso no episódio sobre o NES, nosso Nintendinho, pra mais detalhes reveja o video no link acima. Mas basta lembrar que o 1o Super Mario é provavelmente um dos jogos mais complicados que se podia fazer dentro dos limites de 40 kilobytes de um cartucho sem mapper, onde temos uns 32 kilobytes pro código do jogo e míseros 8 kilobytes pros gráficos. Por isso as fases do primeiro Super Mario reusam os mesmos gráficos, os tiles e sprites, da primeira fase, mas só mudando a paleta de cores. Os inimigos são sempre os mesmos. E por aí vai.

Se a gente abrir o binário do jogo num emulador como o Mesen e olharmos a região chamada CHR do cartucho, aqui estão todos os gráficos do jogo inteiro. É só isso que tem no primeiro Super Mario. Pra conseguir caber tudo nesse espaço, os programadores tiveram que ser muito criativos. Exemplo famoso é ver esta tela da primeira fase. As nuvens e os arbustos usam os mesmos tiles, só muda a paleta de cores, tão vendo?

Lembram como nos episódios anteriores eu falei que o sistema operacional costuma dividir endereços de memória, segmentar regiões como Heap, Stack e outros? Mesma coisa pro 6502, em particular no NES. Por exemplo, a stack de um NES vai do endereço hexa 01A0 até 01FF, que dá 95 bytes. Aliás, toda vez que tiver dúvidas, abre uma calculadora como essa que vem no Windows em modo programador e faz a conta em hexadecimal, 1FF menos 1A0 e vai dar 5F que convertendo em decimal é 95. Apesar de parecer pouco, todo jogo de nintendinho, até os mais complexos, funcionam nesse espaço.

O código do programa em si fica entre os endereços 8000 a FFFF, divididos em bancos. Os bancos de programa costumam ser chamados de PRG. Se a gente olhar no emulador Mesen, dá pra puxar o que tem na ROM PRG. No visualizador ele começa do endereço 0 e vai até 7FFF. Quer dizer que é o endereço 0 desse banco, dentro desse segmento da ROM PRG. Mas nos endereços globais em vez de 0 é 8000.

De curiosidade, no cartucho do Super Mario o linguição de bytes começa com 78 depois D8 A9 10 8D 00 20 A2 FF e assim por diante. Podemos pegar qualquer tabela de conjunto de instruções de 6502, como esse aqui pra converter em mnemônicos de Assembler. Daí podemos ver que 78 é a instrução SEI ou Set Interrupt Disable. Ele não tem parâmetros, então o próximo D8 é outra instrução, CLD que é Clear Decimal, também sem parâmetro.

Agora A9 é LDA, que a gente já tinha visto nos outros vídeos. É o Load Accumulator. Ele vai pegar o endereço seguinte, que é FF e carregar o que tiver lá no acumulador. Depois 8D que é a instrução STA ou Store Accumulator que vai pegar o que tiver no acumulador e mandar pro endereço 20 00. Como o 6502 é little endian, ele grava o low byte primeiro, então inverte e a gente lê como 00 20. Esse endereço é da PPU, que é o chip que controla os gráficos.

Em vez de ficar traduzindo assim byte a byte na unha, melhor usar um recurso do emulador Mesen que é o debugger. Ele traduz tudo pra gente. E olha só, veio exatamente o que acabei de falar a partir do endereço 8000. Assim como um binário ELF que é executável de Linux, um cartucho de NES começa com um cabeçalho de 16 bytes que vai dizer pro processador o que ele vai encontrar no cartucho. Por exemplo, os mappers que fazem trocas dos bancos de ROM pra ter mais espaço do que é possível endereçar.

Dependendo do tipo de cartucho, como do Super Mario que não tem mapper, que a gente chama de mapper zero, ele manda dar jump pro endereço 8000 que é onde tem a primeira instrução do jogo. Não dá pra endereçar mais de 40 kilobytes de ROM, mas com um mapper ele vai trocando os bancos de 16 ou 32 kilobytes dinamicamente. Dá pra ter quantos bancos você quiser. Eles respondem nos mesmos endereços, daí quando a gente pede pra trocar, os mesmos endereços passam a retornar dados diferentes. Quando a gente pede o endereço 8000 do banco 1 vai vir uma instrução. Se pedirmos o mesmo endereço 8000 mas do banco 2, vai vir uma instrução diferente.

Bancos são como se fossem páginas, e endereços são linhas nessas páginas. Um jogo que usa no máximo 32 kilobytes de ROM PRG e 8 kilobytes de ROM CHR é como se fosse uma página de papel, e cada endereço é uma linha. Temos linhas que vão de 0000 até 2000 que costuma ser os 8 kilobytes de CHR e do endereço 8000 até FFFF que costuma ser os 32 kilobytes de PRG.

Com mappers, o jogo tem mais páginas, como um livro. A gente pede a página pro mapper, mas o número de linhas continua o mesmo. Então, a primeira linha da página 1 vai ser diferente da primeira linha da página 2 e assim por diante. Fica mais complicado porque a gente tem que saber de que página pedir dados, mas a vantagem é que mesmo com um número de linhas limitado por página, dá pra ter várias páginas extras e assim podemos ter um Super Mario 3 com mais de 200 kilobytes e jogos ainda maiores como o Kirby Adventure que saiu quase no fim da vida do NES com quase meio megabyte e por isso os gráficos eram quase o que um Super Nintendo faria.

Isso tudo dito, vamos ver os endereços de 0 a 2000, com ou sem banco de mappers. É onde ficam os tiles, os gráficos. Um sprite é feito usando uma combinação de tiles diferentes. E podemos atribuir diferentes paletas de cores. Com isso podemos reusar esses tiles pra coisas diferentes. O exemplo mais citado são os tiles de nuvem, que usam a paleta que faz ficar branco. Se escolher a paleta verde, vira um arbusto. E se o design for feito de maneira criativa, dá pra economizar muito espaço de tiles reusando com cores diferentes.

O objetivo desse exercício todo de endereços, intervalos de endereços, estruturas fixas como tiles e sprites, é pra relembrar que no começo da programação a gente começa lidando com as formas mais simples de representar e mapear dados. Do ponto de vista de uma CPU de nintendinho, a única coisa que ele sabe é manipular memória de 0 até FFFF. No caso do processador 6502, vai reservar alguns desses endereços em conjuntos de segmentos. Vai ser hardcoded que no endereço hexa 4016 é que você vai ler quais botões do controle foram apertados, por exemplo.

Apesar de 0 até FFFF ter um total de 65 kilobytes de endereço, parte desses endereços é reservado pros 2 kilobytes de RAM, pros controles, pro video, pro audio e vai sobrar perto de 32 kilobytes pra programas e 8 kilobytes pra gráficos, por isso eu falei que os primeiros jogos eram limitados em 40 kilobytes. Pra ter mais espaço, precisa usar truques como os mappers. Mas na prática é como se a CPU tivesse acesso a um arrayzão de 0 até 65 mil 535 posições. E se assistiu meu episódio sobre os Hello World, você já sabe como funciona um array.

Antigamente, a quantidade de memória que a gente tinha era super limitada. Hoje temos gigabytes de memória, mas mesmo assim ainda parece pouco. O maior jogo de nintendinho não tinha meio megabyte. Literalmente qualquer foto que você tira num smartphone tem megabytes de tamanho. Por causa disso a gente consegue organizar esses recursos de uma forma mais ergonômica pra programadores. Um desses confortos é não precisar acessar as coisas diretamente em endereços e fazer cálculos de offset de endereços pra achar as coisas.

Num nintendinho, o total de endereços é fixo em 16-bits, sempre vai ser no máximo 64 kilobytes de endereços. Pra ter mais que isso precisa de um mapper, um controlador que vai mapear páginas. É mais ou menos isso que a gente fazia em MS-DOS nos PCs dos anos 80. Todo mundo deve ter ouvido a famosa frase atribuída ao Bill Gates que dizia que PCs não precisam de mais do que 640 kilobytes de memória. Era o máximo que o DOS conseguia endereçar na época.

Se você tava acostumado com micros de 8-bits com endereços de 16-bits, então o máximo que dava pra enxergar era 64 kilobytes. Em poucos anos ter 10 vezes mais memória parecia impressionante. Mas nós programadores sempre vamos dar um jeito de encher toda memória que tem. Toda vez que alguém disser “ah, o mundo só precisa de X gigabytes de RAM”, sempre vai aparecer um Chrome dizendo “hold my beer”.

No fim o MS-DOS também acabou adotando coisas similares a mappers de cartucho, mas em software. Vocês hoje em dia felizmente nunca vão ter que lidar com DOS, mas se um dia tiver curiosidade de usar um DOSBox ou FreeDOS seja pra rodar programas velhos ou pra games antigos mesmo, vai acabar esbarrando em alguns termos estranhos. O que eu vou explicar a seguir não vale mais pra PCs modernos, mas ter essa noção na cabeça pode ajudar a enxergar arquitetura de computadores de forma diferente, por isso acho que vale a pena. Não se preocupem em decorar números ou nomes que vou dizer, só tenta pegar a idéia geral.

O MS-DOS era um sistema operacional pra máquinas de 16-bits. Dessa geração pensar um Super Nintendo ou Mega Drive. Mas ele era compatível só com processadores tipo Intel 8086 e 8088 e inicialmente rodava no que passou a se chamar de modo real. Nesse modo os programas têm acesso a todos os endereços que era possível endereçar. Lembra que quando falamos em 8-bits ou 16-bits ou 32-bits em CPUs estamos falando do tamanho dos registradores.

Normalmente o barramento de endereços tem tamanho de bits diferentes. Como no caso do 6502 do NES: era uma CPU com registradores de 8-bits mas que acessava endereços de 16-bits pra ler ou escrever valores de 8-bits na RAM. Eu expliquei como isso funciona em detalhes no video do Guia mais Hardcore de Introdução à Computação. Só lembre que o tamanho do registrador não é diretamente ligado ao tamanho dos endereços.

Com as CPUs saltando de 8-bits pra 16-bits, a gente poderia imaginar que a próxima geração de endereços ia melhorar e saltar dos 16-bits direto pra 32-bits. Isso porque parece que estamos só dobrando os números, mas se lembrem que isso são potências de base 2. O salto não é o dobro, linear, e exponencial. 16-bits endereçava no máximo 64 kilobytes, que mesmo pra época era bem apertado. Mas 32-bits é 2 elevado a 32 que seria 4 gigabytes possíveis. No meio dos anos 80, meros 2 megabytes custavam 600 dólares. 4 gigabytes - se fosse possível comprar - custaria nada mais, nada menos que mais de um milhão e duzentos mil dólares. 2 megas!

Aumentar o barramento de endereços pra 32-bits significa ter 32 pinos, mais transistores e tudo mais, o custo do chip aumenta bastante. Aí provavelmente eles pensaram, “cara, a gente tem um processador com registradores de 16-bits. Pra que dobrar a quantidade de bits nessa geração, se vai levar décadas pra existir 4 gigabytes barato?”

64 kilobytes é realmente muito pouco. Se carregar uma planilha num Lotus 1-2-3 da vida, ia faltar memória bem rápido. Em vez disso vamos fazer uma gambiarra. Vamos criar novas instruções que peguem pares de registradores de 16-bits e vamos chamar um de segmento e outro de offset e com isso calcular um endereço de 20-bits. Em vez de desperdiçar fazendo um barramento de 32-bits, 20-bits é mais que suficiente.

Com 16-bits você só consegue enxergar até o endereço FFFF, quatro Fs que chega ao máximo de 64 kilobytes. Colocando só mais 4-bits de endereços, temos a capacidade de endereçar até 2 elevado a 20 que dá 1024 bytes ou 1 megabyte de endereços. É 16 vezes mais memória que a geração do Nintendinho. Esse é o poder da exponencial, não se esqueçam disso.

Vamos entender essa gambiarra, não seria um endereço linear de 0 até FFFFF, ou 5 Fs. Porque os registradores eram de 16-bits. Então precisava dar um jeito de usar dois valores de 16-bits pra calcular um endereço de 20-bits. Era horrível programar em baixo nível naquela época. Eu felizmente não precisei, mas tenho dó de quem usava Assembler de 8088.

Os endereços podiam ir de 0000:0000 até FFFF:FFFF, notem os dois pontos. Olhando assim parece um endereço de 32-bits. Mas são só 2 valores de 16-bits um atrás do outro. Na verdade você pega o primeiro segmento e multiplica por 16, hexa 10, que é o mesmo que fazer shift pra esquerda e colocar um zero. Daí você soma com o segundo segmento, que é um offset. É que nem um array, onde você tem o endereço do começo do primeiro elemento e vai somando com um offset pra cada posição. Offset é uma coisa que você vai sempre ver em computação, então vale estudar se ainda não entende.

Essa fórmula é arbitrária. Literalmente tiraram da bunda. Daí um endereço segmentado de FFFF:0010 é igual a FFFF * 16 bits ou 0x10 em hexa, que vai dar FFFF0 mais o offset 0010 que vai resultar no hexa 100000 que é o último endereço do limite de 1 megabyte quando você tem só 20 linhas de endereçamento.

Mas o maior endereço que dá pra representar concatenando dois valores de 16 bits é FFFF com FFFF. De novo, faz o primeiro FFFF shift pra esquerda que dá FFFF0 mais o offset FFFF que vai dar o endereço de 20-bits 10FFEF que é quase 64 kilobytes acima de 1 megabyte. Esses 64 kilobytes no topo dos endereços é conhecido como HMA ou High Memory Area, porque fica na parte mais alta dos endereços.

Nos processadores 8086 e 8088, quando o processador recebia uma requisição pra um endereço acima do 1 megabyte que é FFFF:0010, ele fazia um wrap, ou seja, truncava os primeiros bits mais da esquerda, então 100000 virava 00000, 100001 virava 00001 e assim por diante. É mais ou menos que nem fazer o módulo por 100000. Lembra que nos episódios anteriores falei que era importante ter noção de módulo.

Se a memória fosse uma fita de papel, com posições numeradas de 0 até 100000, é como se eu pegasse a ponta final dessa fita e grudasse com a ponta inicial 0 e aí viraria um anel. Quando chega no último endereço FFFFF, ele volta pro 0. Por isso nunca chega no endereço teórico máximo que falei agora, o 10FFEF porque truncando os primeiros 4 bits vira 0FFEF. Ele faz isso pra nunca tentar pegar um endereço alto inválido.

Mas os problemas não acabam aí. Se você parar dois segundos pra pensar nesse esquema de cálculo, vai ver que muitas combinações de segmentos e offsets acabam no mesmo endereço de 20bits. Sem pensar muito, peque o endereço 0001:0010 e 0002:0000. Faça a conta. No primeiro é 1 com shift pra esquerda que dá 10, mais 10 do offset vai dar 20. No segundo já é 2 shift pra esquerda que é 20 somado com 0 que é 20. Os dois vão chegar no endereço 00020. Tem mais de 4 mil combinações de segmento e offset que vão conflitar.

Isso é um problema porque você pode pensar que tá escrevendo num endereço e acaba sobrescrevendo em cima de outro errado sem saber. Parecem diferentes porque a notação de segmento e offset são diferentes mas ambos resultam no mesmo endereço real de 20 bits. Pra controlar um pouco a zona, virou uma convenção normalizar a notação. Então dentre essas duas opções que chegam no mesmo endereço, o correto seria escrever olhando a partir do endereço de 20-bits, enfiar os dois pontos entre os dois últimos hexa e chegamos em 0002:0000, que é considerado o endereço normalizado.

Pensa que zona, na hora de programar ter que ficar calculando essas conversões de cabeça. Óbvio que mais cedo ou mais tarde vai dar pau. Fico imaginando que é um pouco o que engenheiros nos Estados Unidos sofrem se precisam trabalhar em projetos que é em sistema métrico e imperial ao mesmo tempo. Uma hora escreve em polegadas, depois em centímetros, depois em jardas, daí faz temperaturas em Fahrenheit e converte pra Celsius e assim vai até uma hora explodir um foguete.

Independente disso, de fato a gente não precisava de 4 gigabytes de RAM no meio dos anos 80, mas claramente mesmo 1 megabyte sendo 16 vezes mais que os pífios 64 kilobytes de micros como Apple II ou Commodore 64 ou o nintendinho, aplicativos de produtividade como Lotus, Wordstar, dBase, nos fizeram passar a usar mais e mais memória e 640 kilobytes rapidamente começaram a se mostrar insuficientes.

Diferente de micros antigos e consoles de videogame, a gente não tinha a opção de cartuchos em PCs. Primeiro que seriam mais caros. E mesmo ainda sendo caro, era melhor usar RAM. Com disquetes ou HDs, você precisa carregar os bits do programa na RAM pra poder usar. Com cartucho não precisava carregar porque ele já é o próprio chip de memória. Quando pluga o cartucho o programa já tá carregado e pronto pra usar. Por isso que com poucos kilobytes de RAM era suficiente porque não ia ser gasto carregando os programas. Mas em PCs, parte da RAM vai ser sempre usado pra carregar o sistema operacional e os programas e o que sobrar é onde você vai trabalhar seus dados.

Entenda o problema. Independente se a gente colocar mais memória, todo programa, incluindo o sistema operacional tipo DOS e seus clones como DR-DOS, drivers de video, drivers de áudio, tudo carregava na memória convencional de 640 kilobytes. Sobrava bem pouca memória. E os programas ficavam cada vez maiores. Rapidamente 640 kilobytes não ia ser suficiente. Mas a gente não pode usar endereços acima de 640k, ou seja a partir de A0000 até FFFFF, porque são reservados. Do A0000 até CFFFF é memória de vídeo. De F0000 até FFFFF é memória pra BIOS. E como existia a regra de truncar acima do endereço 9FFFF pra voltar pra zero, mesmo plugando mais chips de memória, não ia ter como endereçar eles.

Por isso começaram a pensar em formas de quebrar essa limitação de 640 kilobytes. As primeiras soluções foi fazer algo parecido com os mappers de cartuchos de nintendinho: uma placa pra ligar nos slots ISA da placa-mãe com mais chips de RAM, talvez mais 1 megabyte, e um chip controlador como um mapper que seria carregado em algum lugar nos 640 kilobytes de RAM convencional. Daí você chamaria alguma interrupção ou função do sistema pra fazer bank switching, que é a mesma ideia que já vimos de como ter um cartucho de mais de 40 kilobytes.

O trecho reservado de 384 kilobytes no alto dos endereços acima dos 640 kilobytes convencionais foi chamado de upper memory area ou UMA. E uma das primeiras gambiarras foi usar endereços nesse espaço pra endereçar a memória extra, enfiado entre os endereços de periféricos e da BIOS. Soluções desse tipo, com um hardware especializado, criavam o que a gente chamava de EMS ou Expanded Memory ou memória expandida. Daí a gente podia ter muito mais de 1 megabyte, talvez 8 megabytes, algumas soluções iam até 32 megabytes. Isso no fim dos anos 80, com processadores 8088.

Se eu entendi direito, EMS usa um intervalo de endereços nessa região de memória alta reservada de 384 kilobytes, criando páginas pequenas, de 16 kilobytes, que é o EMS page frame. Daí seus dados poderiam ser carregados na memória acima de 1 megabyte e o driver de EMS vai fazendo page swaps de 16 kilobytes de cada vez. Bill Gates parece que odiava essa gambiarra. E era mesmo uma gambiarra, que se você entendeu como funciona bank switching de mappers de cartucho de nintendinho, é mais ou menos a mesma coisa. Quando saíram os 80386 aí não precisava mais de hardware especializado e o controle de EMS passou a ser emulado só via software.

Independente do EMS, a partir do 80286, você podia colocar mais pentes de memória e extender memória com endereços acima de 1 megabyte. Não dá pra carregar programas nesses endereços, mas você podia armazenar dados que um programa carregado na memória convencional podia usar. Tipo carregar o Lotus 1-2-3, que era o Excel da época, nos primeiros 640 kilobytes e as planilhas nos endereços acima de 1 megabyte, indo a um máximo de 15 megabytes.

Memória eXtendida é diferente da memória Expandida que falamos agora. Expandida é o EMS, que controla páginas de 16 kilobytes na memória alta e só funcionava com hardware especializado ou com os 80386. Mas nos 80286 passamos a poder acessar a memória acima de 1 megabyte. Pra isso precisava desligar o sistema de truncar endereços acima de 1 megabyte.

Resumindo até agora, a gente tinha memória convencional que são os primeiros 640 kilobytes de RAM onde carregava o DOS e seus programas. Daí tinha os últimos 384 kilobytes que era o UMA ou memória alta. Depois disso, antes do 80286, truncava os endereços. Acima da marca de 1 megabyte ainda tinha uma sobra de 64 kilobytes de endereços que se chama HMA ou high memory area. E com o 80286 agora temos a possibilidade de endereçar acima do 1 megabyte, a XMS ou memória extendida. No 286 ele chamou o esquema de ver memória até 1 mega e truncar como modo real, e pra acessar mais memória criou um conjunto de mecanismos e chamou de modo protegido. Você só podia estar em um desses modos de cada vez.

Se você achou complicado a idéia de endereços de memória de 20-bits divididos em segmentos de 16-bits, num 80286 em vez de endereços de 20-bits, eles aumentaram pra 24-bits, o que dava pra endereçar um máximo de 16 megabytes. Mas com esse esquema de segmentação, em modo protegido, cada processo recebia um segmento virtual separado de até 8 megabytes. Mesmo se você tivesse 16 megabytes, poderia rodar dois programas, cada um mapeando até 8 megabytes de cada vez.

Pra acessar a memória extendida, XMS, a gente escrevia um arquivo chamado Config.sys que o DOS carregava logo que bootava. Precisava pelo menos carregar o driver HIMEM.sys que significa High Memory. Hai-mém e não Hímem! Com o HIMEM.sys e colocando a diretiva de DOS = HIGH, UMB, significa que ele ganhava acesso aos endereços da memória alta, o segmento entre 640K e 1 megabyte. UMB significa Upper Memory Block. Isso carregava o sistema operacional nos blocos sobrando nessa memória alta. Daí dava pra carregar alguma coisa lá, economizando a memória convencional, já era um pequeno ganho.

Como era pouco espaço de blocos de memória alta, a gente carregar um gerenciador de memória lá, como o EMM386 da própria Microsoft. Originalmente ele ia servir como software de emulação pra memória expandida, o EMS, fazendo page frame na memória alta pra paginar a XMS. Mas depois passamos a não precisar fazer mais isso, então era só passar o parâmetro NOEMS pra EMM386. Combinando a HIMEM com a EMM386 ganhamos acesso à memória alta e à XMS. Daí tinha diretivas como LH que acho que era Load High e DRIVERHIGH que é literalmente carregar drivers na High Memory Area, que são aqueles últimos 63 kilobytes de endereços depois do 1 megabyte, que processador antigo truncava o endereço.

Aliás, desde aquela época você vê que programador é bem pragmático pra criar nomes. Mas só no que expliquei até agora a gente tinha HIMEM e motorista bêbado com DRIVER HIGH. Vai vendo.

Raspando o tacho, pegando kilobyte livre onde dava, a gente economizava memória convencional, os primeiros 640 kilobytes onde roda programa, porque o sistema operacional DOS, e a maioria dos drivers como de placa de som, mouse, CD e tudo mais carregava ou na UMB ou na HMA e os programas conseguiam carregar dados na XMS. Economizar os 640 kilobytes era crucial pra carregar programas e jogos que cada vez ficavam maior. E na prática vira e mexe um programa não rodava mesmo porque faltava memória. Então essas otimizações todas não eram opcionais não.

E isso porque eu nem falei do CEMM da Compaq, do QEMM da Quarterdeck, do 386Max da Qualitas e outras soluções concorrentes pra gerenciar essa zona de memória. Entre o MS-DOS 3 até o MS-DOS 5 tinha várias combinações de gerenciadores de memória e alternativas ao MS-DOS como o concorrente DR-DOS da Digital Research. As coisas só ficaram menos ruins pra gente que era usuário quando saiu o DOS 6.2 que já vinha com todas essas ferramentas embutidas, como o EMM386, Memmaker, Scandisk e muito mais. E nesse meio tempo a Microsoft veio introduzindo o Windows 1.0, Windows 2.0.

Você pensa que daí não tinha como piorar, mas depois da introdução do modo protegido nos 80286, que era meio bugado, depois a introdução do modo Enhanced nos 80386, junto com Windows 2.0 pra 286 e Windows 3.0 pra 386, a coisa ficou mais confusa ainda antes de melhorar. Mas à medida que o Windows 3.1 com Enhanced Mode do Intel 386 começou a se popularizar, a necessidade de gerenciar memória na unha começou a diminuir. Com o 386 saltamos da geração de 16-bits pra 32-bits.

A importância de um Windows 95 foi dar um ponto final em uma década de bateção de cabeça da gente tentando extrair kilobytes da maldita limitação de 640 kilobytes de memória convencional, tentando entuchar o máximo possível nos kilobytes acima de 640 e ainda tendo que lidar com o esquema esdrúxulo que a Intel inventou de segmentação de endereços, fazendo aquele cálculo horroroso pra transformar dois registradores de 16-bits num endereço de 20 ou de 24 bits. Só que esse esquema se perpetuou nas APIs de 32-bits também.

Do ponto de vista do hardware, a gente começou no fim dos anos 70 com os processadores 8086 e 8088 com barramento de endereço de 20 pinos, ou 20-bits. Mas só tinha registradores de 16-bits. Em vez da Intel juntar dois registradores de 16-bits e concatenar pra fazer um endereço de 32-bits, fizeram o esquema de segmento e offset. Com offsets de 16-bits a gente tinha que lidar com blocos de 64 kilobytes de cada vez. E os endereços acima de 1 megabyte eram truncados pra dar a volta.

Daí no começo dos anos 80 sai o 80286 que introduz o modo real que é como rodava o 8086 com endereços de 20-bits. E o modo protegido dava opção de memória virtual e protegida, que é a idéia do sistema operacional alocar tabelas pra controlar o endereçamento dos programas. A grosso modo, em vez de todo programa enxergar os mesmos endereços reais, vão enxergar endereços virtuais de uma tabela local, exclusiva pra cada programa, que é controlado pelo sistema operacional, que vai ser o único que enxerga uma tabela global. Um programa que assumia ter acesso a endereços reais de hardware quebrava nesse modo.

Com esse controle de tabelas, a idéia é evitar que um programa escreva em cima do endereço do colega do lado, que é uma coisa que acontecia o tempo todo quando a gente tentava rodar mais de um programa ao mesmo tempo num MS-DOS da vida usando TSR que é como os programas ficam ativos em background. A CPU 80386 foi o divisor de águas e que marca a transição mesmo pro mundo 32-bits. Nela Intel colocou uma funcionalidade de Virtual 8086, que faz programas MS-DOS rodarem em ambiente isolados, onde um não enxerga a memória do outro.

Num Windows, quando você pede pra abrir programas de DOS ele abre o equivalente a uma máquina virtual. Virtualização, que é uma tecnologia da época dos mainframes, entrou no mundo de microcomputadores nessa época. E mesmo fora do Windows existiam alternativas de controladores de concorrência em modo texto como o ConcurrentDOS ou GEOS e mais, mas no final já sabemos que quem ganhou a concorrência foi o Windows mesmo.

Hoje em dia não temos mais esse subssistema mas do Windows 3 até o Windows NT, isso era importante porque mesmo indo pra interface gráfica, a maioria dos programas mais importantes rodava em modo texto no DOS. Só a possibilidade de rodar mais de um programa de DOS concorrentemente, sem um crashear o outro, já era um bom motivo pra migrar pra Windows. O outro motivo era a uniformização das APIs pra programadores. Antigamente, tinha uma dúzia de empresas só fazendo gerenciadores de memória. Sem falar em outras coisas como drivers de áudio, drivers de video. Pra áudio precisava programar pra Sound Blaster, Adlib ou Roland. Pra video precisava manualmente tomar conta de modo CGA ou EGA ou VGA. Com Windows era uma API só pra tudo e o Windows lidava com hardware por trás.

Na era 32-bits as coisas ficaram um pouco mais fáceis. Finalmente a gente deixou pra trás essa ideia de ficar manualmente controlando memória segmentada e passamos a lidar com endereços lineares, mais parecido com lidar com arrays em qualquer linguagem. Quer uma posição específica na memória? Vai direto na posição em vez de ficar fazendo conta de segmento e offset. O único problema é que no fim dos anos 80 onde o normal era lidar com no máximo 1 megabyte, pular pra 4 gigabytes parecia tão difícil quanto mandar um foguete pra lua.

Eu disse que no meio dos anos 80, se desse pra comprar 4 gigabytes iria custar mais de um milhão de dólares. Uns 15 anos depois, em 1999, já era possível comprar 4 gigabytes. Apesar de ainda ser caro não era mais um valor impossível. Com menos de 10 mil dólares dava pra comprar. Um usuário doméstico não ia comprar e nem precisava de tudo isso. Mas em corporações que precisavam, agora tinha a opção. Ou seja, em menos de 2 décadas a memória ficou 100 vezes menos cara. E o limite de 32-bits já tava sendo batido em empresas que precisavam rodar bancos de dados, por exemplo.

Pra remediar isso inventaram Address Windowing, que é a técnica de reservar uma janela de memória dentro dos 32-bits pra endereçar mais páginas fora. Parecido de novo com a idéia de mappers de nintendinho ou EMS no DOS. Particularmente o PAE ou Physical Address Extension, implementado nos processadores Pentium. Isso permitia um Windows 2000 Advanced Server acessar até 8 giga de memória real ou um Windows 2000 Datacenter acessar até 32 giga. No boot você passa o parâmetro de /PAE pra habilitar isso na CPU. Na prática, cada programa de 32-bits continua só conseguindo enxergar o máximo de 4 giga de memória virtual. Mas se dois programas quiserem realmente encher esse tanto de memória, num Windows 2000 normal ou ia cair pra swap ou ia dar erro.

Aliás, nem falei disso. Em modo real, o programa enxerga a memória real do sistema. Se for 1 megabyte, vai ser só 1 megabyte e o programa que se vire pra usar alguma técnica como memory mapped files, ou seja, tirar pedaços de dados da memória e gravar num arquivo, e quando precisar daquele pedaço, recarregar do arquivo pra memória. Pra fazer isso, num sistema operacional moderno, o gerenciador de memória do sistema operacional divide a memória em páginas. É como se fosse um array de arrays. Mais corretamente, acho que é uma árvore B-Tree, como expliquei dois episódios atrás. Cada node era uma página de memória.

Quando a memória vai acabando, o gerenciador pode pegar algumas páginas pouco usadas e gravar em disco pra liberar espaço. Disco é ordens de grandeza mais lento. Mas entre acabar a memória e crashear ou ficar mais lento, a escolha costuma ser deixar mais lento. Mas aí quando o programa tentar ler uma página que não tá mais lá, vai dar falha de leitura de página, o famoso page fault, uma exceção.

O gerenciador pausa o programa pra tratar essa exceção, se não tiver espaço sobrando na memória, primeiro grava mais páginas em disco pra liberar espaço, e depois carrega a página que você queria do disco de volta pra memória. Feito isso devolve o controle pro programa, e ele continua como se nada tivesse acontecido. É o mesmo conceito que a gente usa pra fazer cache. Se você já teve que otimizar tempo de resposta de aplicação Web com um memcache ou Redis, é o mesmo conceito no gerenciador de memória.

Você troca performance pra poder ter mais espaço do que caberia na memória real. Por isso falamos em memória virtual: o programa acredita que pode usar até 4 gigabytes, usando endereços de 32-bits. Ele pede essa posição de memória pro gerenciador de memória do sistema operacional. E esse gerenciador é que mapeia do endereço virtual pro endereço real. Por isso no 286 começaram a chamar esse esquema de modo protegido, porque quando dois programas enxergavam a mesma memória real, um podia escrever em cima dos endereços do outro. Mas agora eles enxergam uma tabela abstrata que o gerenciador de memória dá pra eles. Eles não tem acesso à memória real mais. Então esse gerenciador garante que um programa nunca vai acessar endereços do outro.

Com PAE é mais ou menos isso, ele tem mais tabelas virtuais e pede pra CPU mais memória, e ele vai dar memória acima do limite de 4 gigabytes. Do 386 em diante a própria CPU passou a ter um MMU que é Memory Management Unit, em hardware, que em CPUs com recurso de PAE vai ter endereço de 40 bits, e isso dá pra mapear memória real até o máximo de 1 terabyte. Só que ficar gerenciando essas tabelas virtuais também gasta espaço na memória. Você usa memória pra gerenciar mais memória, por isso a gente não tenta mapear o máximo teórico que na prática ninguém vai usar, pra não desperdiçar. Por isso o Windows de 32-bits limita de 8 giga até 64 gigas dependendo da versão.

Como expliquei antes, CPUs de 8-bits antigas tinham endereçamento de 16-bits. CPUs de 16-bits começaram tendo endereços de 20-bits, depois 24-bits. Aí saltamos pra processadores de 32-bits com endereços de 32-bits mesmo. Mas com PAE passamos a ter endereços de até 40-bits. Isso quem dá suporte é a CPU. Então um 386 de 32-bits não tinha como acessar mais que 4 gigas. Só com os Pentium de 32-bits e endereços de 40-bits que dava pra ir pra 32 gigas, 64 gigas ou até mais.

Outro problema é que você pensa que um programa tem acesso do endereço 0 até o endereço 4 bilhões e tanto que são os 4 gigabytes, de novo, como se fosse um lista linear. Pra visualizar na cabeça é melhor pensar assim mesmo. Mas internamente a memória virtual é segmentada como eu expliquei nos episódios de estrutura de dados. O sistema operacional precisa manter estruturas de dados como Heap, Stack e muito mais e pra isso ele reserva 2 gigabytes de endereço. Isso no caso do Windows. No Linux você podia compilar configurado pra reservar menos. E nos Windows Server você pode passar o parâmetro “/3” se não me engano, pro sistema operacional reservar só 1 giga pra ele e deixar 3 gigas pro programa.

Lembra que eu falei que tabelas virtuais de PAE usam espaço de memória? Então, esse é um exemplo de porque precisa reservar endereços. Você nunca tem o espaço total de endereços disponíveis. Um banco de dados com o SQL Server, rodando num Windows Datacenter, com PAE, com o flag /3 pra pedir mais memória, ainda assim vai ter no máximo 3 gigabytes. Então o que ele faz é subir mais de um processo, cada um com até 3 gigabytes. Se o servidor da época instalar o máximo de 64 gigabytes que o Windows Datacenter permitia, ele ia precisar subir e coordenar até 20 processos rodando em paralelo pra conseguir usar toda a memória real.

Uma coisa que eu ficava cabreiro naquela época é justamente só ter 2 gigas no máximo e eu ficava pensando: se existe essa opção de bootar com “/3” porque o Windows já não faz isso sempre por padrão pra me dar esse 1 giga a mais? E a resposta é porque nesse espaço reservado do sistema operacional fica mapeado os endereços pra bibliotecas compartilhadas, DLLs de sistema. E mesmo não ocupando os 2 giga ele pode ocupar endereços no fim desses 2 gigas.

Mesmo tendo espaço vazio no meio, se ele usar os endereços mais pertos do fim, eu não consigo diminuir o espaço que ele reserva. Daí tem o conceito de fazer rebasing das DLLs, que é forçar elas a carregar nos endereços mais do começo pra eu poder diminuir esse espaço com o boot em “/3”. Pra isso precisava carregar o mínimo de DLLs possível. Drivers podiam se carregar em endereços no algo, por isso que só opções de servidor, com drivers controlados, é que costumavam dar essa opção.

Então, gerenciar memória nunca foi algo legal, sempre foi chato. Felizmente, diferente do que a gente precisava fazer com DOS, era menos chato se você programasse no mundo 32-bits porque nesse estágio Windows ou Linux já faziam o grosso do gerenciamento de memória e você só tinha que lidar com a memória virtual disponível por processo que eles dão pra você, mas quando viramos pro século XXI, era da Internet e servidores de bancos de dados, claramente a gente ia precisar de mais memória. 4 gigas pareciam infinitos em 1995, mas em 2005 era altamente insuficiente.

Por isso começou a corrida pros 64-bits no começo do século, com AMD Athlon, Intel Itanium e outros. Mas em resumo, hoje a maioria das pessoas estão em 64-bits, inclusive em celulares. 64-bits dá um total teórico de 2 elevado a 64 endereços que são inimagináveis 16 mil PETA bytes. Assim como em 1985 ninguém conseguia imaginar uma máquina com 4 gigabytes de RAM, em 2021 ninguém consegue imaginar uma máquina com 16 mil Peta bytes. E felizmente hoje, 4 giga DDR4 custa menos de 100 dólares. Nada mal partindo de 10 mil dólares no fim dos anos 90.

Porém, se você for milionário e quiser ir até o limite teórico de 64-bits que são os 16 mil petabytes, precisaria gastar na faixa de 400 bilhões de dólares. Pra dar uma noção, em 2019 se estimava que o Google inteiro tinha pouco mais de mil petabytes de dados, então estamos falando do custo pra guardar todos os dados do Google na RAM de uma única máquina, dez vezes.

Mesmo se você fosse um Jeff Bezos ou Jack Ma da vida pra jogar uns bilhões fora, ainda assim não ia conseguir usar esse tanto de memória. Isso porque ninguém imagina que a gente vai chegar perto desse número tão cedo, talvez nas próximas décadas. Então é desperdício otimizar o chip pra ter esse tanto de pinos de endereço e barramentos e controladores. Então o chip de fato tem registradores de 64-bits pra poder calcular números grandes numa única instrução. Mas o barramento de endereços é de 40 ou no máximo 48-bits, e não 64.

40 bits é um intervalo de endereços que vai de zero até 2 elevado a 40 que é exato 1 petabyte. Isso permite endereçar 16 mil vezes menos memória do que 64-bits. Nenhuma CPU moderna de 64-bits, seja um Intel Xeon, um AMD Epic, um Apple M1, um Qualcomm Snapdragon. Todos são capados na faixa dos 40-bits. Dificilmente alguém vai ter 1 petabyte de RAM numa única máquina. O mais comum em workstations hoje é a faixa de 256 giga. Um Mac Pro pode ir até 1.5 terabytes de RAM, que são 12 pentes de 128 giga DDR4. O custo hoje em 2021 pra isso é 15 mil dólares.

Com o antigo PAE no mundo 32-bits começamos a pensar um pouco mais na segurança dos dados na memória. Com tudo que expliquei deve ter ficado claro que naquela época a gente precisava ficar caçando kilobytes em tudo que é canto pra carregar drivers. Então adicionar coisas extras como aparatos de segurança não só não era prioridade, como simplesmente não ia caber em muitos casos. Um vírus é minúsculo. Mas um antivírus é bem pesado.

Com a adoção em massa de computadores, especialmente por causa da adoção da Internet, surgiram muitos vírus e malwares e eles sempre tiram vantagem do entendimento de como endereçamento de memória funciona e como conseguir injetar código malicioso em algum endereço que vai ser executado. Pra mitigar isso, junto com o PAE veio a primeira idéia do bit NX, que significa no-execute.

A ideia é marcar certas áreas de endereços de memória virtual que não podem ser executados. Eu não sabia disso, mas parece que nos 80286, com a memória segmentada daquele jeito chato que expliquei, também dava pra controlar isso no nível dos segmentos. Mas em memória com endereçamento linear de 32-bits a partir dos 386, já não tinha mais segmentos nos endereços virtuais. Então eles inventaram esse outro jeito de conseguir saber quais endereços tem dados que não podem ser executados. Até então não existia essa distinção.

Isso é importante porque um programa pode ter instruções pra dar jump pra qualquer lugar. Se ele tiver um bug e tentar pular pra um pedaço de memória que só tem dados, vai dar crash e só. Mas se alguém notar esse comportamento e escrever instruções executáveis neste endereço, quando o bug acontecer e der jump, vai executar o código malicioso sem saber. Mas se o sistema operacional marcar como no-execute, esse código não pode ser executado e se tentar, a CPU vai impedir.

Esse bit NX permite o recurso de DEP de segurança que é Data Execution Prevention, que vai evitar que certas partes da memória sejam executáveis, como a stack dos programas. Em máquinas mais antigas que não tinham o bit NX ainda é possível ter recurso parecido de no-execute. Se os endereços fossem de 32-bits flat, lineares, seria mais difícil, mas isso são os endereços virtuais, como pra calcular o endereço real os chips da Intel precisam fazer aquele cálculo de segmento e offset, dá pra marcar regiões da memória por segmento. Se você entendeu tudo que expliquei hoje já consegue imaginar e vou deixar um link pra uma resposta que achei no site StackExchange que explica em mais detalhes se tiver curiosidade.

Mas pra fechar o assunto de memória, como cheguei até 64-bits, não daria pra finalizar sem pelo menos mencionar ASLR ou Address Space Layout Randomization. A gente escovou bastante bits hoje de propósito pra você entender que tudo funciona baseado em endereçamento. Você entendeu que a memória é segmentada. Segmentos são simplesmente conjuntos de endereços. Do endereço 0 até X fica a stack, do X+1 até Y fica a heap, de Y+1 até Z ficam endereços de periféricos, e assim por diante. Era assim no nintendinho de 8-bits, no 80286 de 16-bits, e assim por diante.

Lembra toda a conversa sobre o limite de 1 megabyte, memória expandida e tudo mais? Pois bem, pelos motivos de se ter poucos endereços e também pra ser mais fácil de programar em baixo nível, os segmentos tinham endereços fixos. Se você for programar num nintendinho, tem certeza que vai achar a ROM a partir do endereço hexa 4020, por exemplo. Se for programar pra DOS num PC antigo, tem certeza que acima do endereço de 640 kilobytes vai achar os endereços de periféricos. E a mesma coisa se perpetuou em modo protegido, memória virtual e sistemas operacionais de 32-bits.

Eu expliquei que o Windows reserva um pedaço da memória virtual de 4GB pra segmentos internos. O tal espaço reservado de 2 gigabytes. Lá vai ter coisas como a stack e o heap do programa, mas também DLLs que são bibliotecas compartilhadas do sistema. Quando seu programa precisar de alguma função do sistema, ela vai estar num endereço que você consegue enxergar dentro do seu espaço protegido. O problema é que tudo isso sempre vai estar em endereços fixos e conhecidos.

Se um vírus ou malware se injetar no seu programa, ele vai ter acesso a esse espaço de memória. Pior, se ele souber de um bug como um stack overflow, vai saber exatamente em que endereço fica a stack e vai saber exatamente em qual endereço injetar seja lá que código malicioso pra executar. Em 32-bits isso é muito fácil. Se você é gamer, muitos mods funcionam assim: se injetando nos programas. O jeito mais educado é interceptando chamadas de funções. O jeito bruto é escrevendo direto em endereços fixos na memória do jogo.

Uma forma de dificultar isso é carregar esses segmentos e DLLs em endereços aleatórios. Só na hora que o programa executar que ele vai saber quais são os novos endereços, daí um vírus não poderia assumir um endereço fixo, porque toda vez vai mudar. O problema é que em 32-bits temos pouco espaço e se ficar movendo segmentos de lugar a gente vai fragmentar a memória. Faz de conta que resolvemos colocar uma DLL no meio dos 2 GB que temos. Daí já impede aquele parâmetro “/3” pra gente conseguir ter 3 gigas livres pro programa. Aí pra servidor esse programa já não presta.

Mas acabamos de falar que em 64-bits tem tanto endereço, mas tanto endereço, que na prática os chips de CPUs como da Intel e AMD só vem mesmo com 40-bits de endereços reais. Significa que temos 24-bits de endereços sobrando que não dá pra usar de qualquer jeito. Então ASLR é um recurso que calcula uma posição aleatória dentro de X posições na memória virtual, estrategicamente escolhidas pra não fragmentar a memória de formas absurdas. Toda vez que seu programa iniciar o endereço da stack, da heap, das DLLs compartilhadas vão ser diferentes dentro de 256 possibilidades.

Tem como o vírus descobrir o endereço em tempo real se tiver vazamento de ponteiros no seu programa, mas esse recurso sozinho dificulta uma quantidade grande se não todos os malwares de overflow que existiam até 2004 pelo menos. Isso sozinho não torna seu computador totalmente seguro, só cria uma camada extra de dificuldade. Se estiver interessado em saber formas de burlar essa proteção também vou deixar linkado um artigo de 2020 que mostra como nas descrições abaixo.

Como eu disse no começo, você nunca vai ter que calcular endereços de 20-bits em computadores de 16-bits dos anos 80, felizmente. Em meio a HIMEM.sys e motoristas bêbados, até chegarmos na era dos 64-bits, gerenciar memória era uma tarefa árdua, tediosa, cheia de bugs e exploits. Tinha mais técnicas de gerenciar memória e escovar bit do que existem pokemóns. Mas acho importante entender como a memória funciona, porque mesmo programadores experientes tratam esse assunto mais como astrologia do que como ciência. Daí quando chegamos no limite da máquina e precisamos pensar em formas de otimizar, a discussão parece mais argumentação de horoscopo do que realmente formas práticas.

Parece besteira, mas entender um mapper de nintendinho de 8-bits, faz a gente entender memória expandida em DOS de 16-bits, que faz a gente entender PAE em computadores de 32-bits, até ter uma visão mais realista do que são 64-bits. A forma como gerenciadores de memória lidam com segurança, fragmentação, páginas e swaps, vai ajudar quando você precisar otimizar um sistema.

Se tiver os conceitos que eu expliquei hoje vai conseguir ler um paper do Google sobre a diferença entre um tcmalloc, jemalloc ou um Scudo hardener. Memória não é tudo igual. Não é uma lista linear. Quanto mais cedo você entender como seus programas realmente usam a memória, mais cedo vai parar de sugerir bobagens pra otimizar seus programas. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, clique no sininho e compartilhem o video com seus amigos. A gente se vê, até mais.

[Akitando] #96 - Estrada do Futuro em 1996 | Meus 19 Anos

Tue, 20 Apr 2021 11:57:00 -0300

DESCRIÇÃO

Achei textos que eu escrevi em 1996, em particular sobre o livro “Estrada do Futuro” de Bill Gates, publicado em 1995. Como a gente imaginava as tecnologias do século 21 e o que de fato virou realidade?

Links:

Meu Livro de 1996 (https:/akita1996.herokuapp.com)

SCRIPT

Olá pessoal, Fabio Akita

Passei as últimas semanas dando um jeito nos meus backups. Estou com dois NAS de 10 terabytes cada e andei movendo um monte de coisa velha pra lá e pra cá. No meio da limpeza esbarrei num material que fiz uns 25 anos atrás. Quem me acompanha no Twitter já viu. É um mini-livro que escrevi pra compilar o que eu sabia sobre computação quando tinha 19 anos, no meio do meu 2o ano de faculdade.

O capítulo de conclusão desse livro é um resumo do livro The Road Ahead, do Bill Gates, que tinha sido publicado em 1995, e faz 25 anos de idade ano passado. Eu li logo que foi lançado. Se você viu meu episódio do fim de 2018 sobre minha máquina do tempo, sabe que eu guardo backup de muita coisa desde a época de faculdade até hoje, incluindo quase todos os meus e-mails, projetos e trabalhos que fiz nesses 25 anos. Se puder, faça backups das suas coisas, daqui 25 anos pode ser engraçado de rever.

Achei interessante trazer alguns trechos do que escrevi com 19 anos pra dar perspectiva pra quem tá nessa faixa dos 20 anos ou em fase de iniciante, independente da idade. Como sempre digo, carreira é uma coisa individual, o que eu relato sobre a minha não deve ser regra pra de ninguém, só mais uma referência. E quero falar um pouco sobre isso hoje também, então vamos lá.

(…)

Em 1996 eu tava no 2o ano de ciências da computação, ralando pra tirar o atraso. Nunca fui o aluno mais aplicado nem com as melhores notas na faculdade. Pelo contrário, tinha tanta coisa acontecendo no meio dos anos 90 que me distraía muito fácil. Eu tinha zero idéia do que ia fazer depois de me formar, e tava mais interessado em acompanhar as novidades.

Pra dar contexto. Nessa época os filmes mais influentes até então pra mim eram coisas como Exterminador do Futuro 2 de 92, Jurassic Park de 93, Toy Story de 95. Steve Jobs já tinha saído da Apple e só iria voltar pra Apple daqui 2 anos ainda. Ele tava ocupado com a Next e depois com a Pixar, e o lançamento do filme Toy Story foi um marco, tendo sido o primeiro longa metragem de sucesso feito em CG, coisa super normal hoje. A era da computação gráfica tava só começando. E estudantes como eu sonhavam de poder usar uma workstation como as da Silicon Graphics ou da Sun.

Interfaces gráficas ainda eram novidade. Windows 95 tinha acabado de ser lançado. Java 1.0 tinha acabado de ser lançado. Netscape 1.0 tinha acabado de ser lançado. Delphi 1.0 tinha acabado de ser lançado. Meu computador na época já era um 386 com uns 33Mhz eu acho, não lembro se já tinha 4 mega de RAM. Monitor era VGA de 65 mil cores, resolução de 800 por 600. Pra colocar isso em perspectiva, os ícones dos seus programas são feitos em resolução retina, de 512 por 512 pixels. Ou seja, num único ícone de hoje quase cabia todos os pixels do meu monitor de 1995.

Celulares ainda eram só pra voz. A coisa mais próxima de um computador portátil era o Palmpilot com 512 kilobytes de RAM. A mídia que a gente mais usava ainda era disquetes e CDs. Pendrive não existia. Tocador de mp3 ainda não existia. Eu tenho a impressão que GPS em carros tinha acabado de ser lançado, mas a gente ainda usava mapa em papel mesmo.

Internet ainda era uma grande novidade. Novidade no sentido das pessoas se perguntarem pra que servia, se era só mais uma modinha passageira que já ia acabar. As velocidades eram absurdamente horrendas. Hoje a maioria deve estar na faixa de 50 megabits por segundo. Naquela época o normal era 14 kilobits ou menos.

Aqui no Brasil, pra variar, a gente tava atrasado, mas nas faculdades dava pra ter uma idéia do que tava acontecendo nos Estados Unidos. Em 94 o Real tinha acabado de sair, e com isso pela primeira vez entramos num período fora da hiperinflação. Uns 4 anos antes o Collor abriu o mercado e possibilitou importarmos coisas como computadores, provavelmente a única coisa útil que ele fez. Daí as coisas começaram a acelerar um pouco.

Mas aos 19 anos, o máximo que eu tinha conhecimento sobre empresas de tecnologia eram os poucos provedores de acesso discado como Mandic ou STI. Ainda não eram gigantes, então dependendo de que parte do país você era, nem isso tinha ainda. Como Web ainda não era tão difundida, pra saber das novidades no mundo só por jornais e revistas ou participando de feiras como Fenasoft ou Comdex, que só aconteciam em São Paulo e no Rio de Janeiro. A internet do Brasil era limitada a poucas cidades e poucas regiões, por exemplo nas universidades federais.

Os poucos de nós que tinham acesso à internet na faculdade gastava tempo em salas de IRC e fuçando servidores FTP abertas que tinha por aí. E nesse cenário estava eu, ainda tentando entender o que queria fazer “quando crescer”. Pense assim, computação no Brasil era super limitado. O que se considerava “profissão” era a área de processamento de dados, pra trabalhar talvez com Cobol em alguma indústria como automobilística, pra processar dados de mainframe. Talvez bancos. Nada muito empolgante, pra dizer o mínimo.

Pouco a pouco vinha crescendo um mercado intermediário, da microinformática comercial. Desenvolvimento de sisteminhas pra comércio e serviços. Plataformas como Clipper, Paradox, Visual Basic. O normal era programar pra DOS, os mais modernos pra Windows 3.1 de 16-bits.

E em 1995 tava começando a transição pra coisas como Windows 95 e 32-bits. Linux ainda era desconhecido. Lembrem-se que naquele momento male male tinha 4 anos de idade. Na indústria mais de ponta você ouvia falar de UNIX e minicomputadores e workstations.

Se você assistiu meu episódio sobre o Diário de Henry Jones, vai lembrar que eu sempre gostei de tentar entender a história da computação e a idéia de compilar meu conhecimento de alguma forma, como este canal do YouTube. 25 anos atrás eu já tinha essa vontade de escrever sobre o pouco que sabia. Gastei pelo menos de maio a novembro de 96 tentando compilar o que eu tinha lido em livros e artigos num único lugar. Foi a primeira tentativa que tenho documentado de tentar escrever alguma coisa.

Eu não era nada organizado então esquece bibliografia. Não tenho idéia de onde tirei todos os textos, mas o capítulo final veio quase inteiro como resumo do livro do Bill Gates. Com o lançamento do Windows 95, a Microsoft tava quase no pico da sua história. Naquela época eu tinha feito a transição de programar só pra DOS com coisas como Clipper e tava aprendendo a fazer sisteminhas em Delphi 1.0 pra Windows 16-bits.

Falando dos meus textos, eles eram bem ruins. Não que os de agora sejam alguma maravilha da literatura. Mas naquela época minha mania de fazer tangentes era bem pior. Eu ainda não tinha aprendido a editar e cortar fora a gordura ou separar em artigos diferentes e queria entuchar quinhentas coisas diferentes no mesmo lugar. Eu ainda faço isso, mas bem menos.

A primeira metade da minha “conclusão” tem mais cara de introdução. Longa, tediosa, e desnecessariamente detalhista. Mas a segunda metade é mais interessante. Não sei se eu vi isso no livro ou se foi idéia minha mas o texto é contado sobre como seria o dia a dia de uma pessoa do futuro. Eu vou adaptar um pouco o texto em si pra não ficar tão maçante. Se quiserem ler o original o link tá nas descrições abaixo. Daí vou intercalando com comentários de hoje. Vamos lá.

(…)

Hoje em dia os microcomputadores avançam cada vez mais rápido, com processadores mais velozes que o mais veloz e caro computador de uma década atrás. Todo mundo cada vez mais ligado a computadores. A maioria das pessoas da classe média e alta já usam micro em casa quase tão naturalmente quanto usam o microondas ou o controle remoto de TV.

(comentário) E isso não era verdade. Quando era novo eu achava que era e não achei uma estatística da época, mas dependendo de onde procurar vai ver que em 1998 menos da metade das casas dos Estados Unidos tinham computador.

No Brasil esse número era certamente ordens de grandeza menor. Eu chutaria que talvez 20%, se muito. Lembrem-se que quase perdemos a onda dos micros nos anos 80 por conta do mercado fechado e pela hiperinflação. Entre conseguir financiar uma moradia ou carro a juros altíssimos, computador era um luxo pra poucos. Só a partir de 94, com a entrada do Real, que ter coisas consideradas “supérfluas” como um computador, viria a se tornar uma opção.

E qual o perfil do cidadão da nova Era da Informação? Hoje em dia uma pessoa comum, pode acordar, ligar seu micro, acessar sua conta de Internet e verificar seu INBOX pra ver se tem novos emails. Enquanto toma seu café, pode acessar a Web e procurar por alguma versão eletrônica dos principais jornais e ver as manchetes do dia enquanto degusta um bom croissant e toma um capuccino.

Em seguida, poderia acessar os bancos de dados da empresa onde trabalha e ver se tem alguma novidade. Ele se conectaria à rede da empresa, talvez uma Intranet e realizaria todo o trabalho que é possível ser feito remotamente, como atualizar os dados da empresa, enviar relatórios e outras coisas.

Mais tarde ele vê na sua agenda eletrônica que vai ter uma reunião para discutir dados referentes ao seu departamento. Ele liga sua mini câmera situada no topo do seu monitor e se liga à Internet.

A reunião será composta por várias pessoas, cada qual em uma filial da empresa em outros países. A Internet é uma rede global. Logo, pessoas de vários países podem se comunicar, virtualmente como se não existissem fronteiras. Essa reunião seria via telepresença, uma teleconferência. A câmera serve pra transmitir sua imagem pela rede.

Utilizando-se de programas comuns como uma planilha de dados, elas podem compartilhar dados e discutir estratégias interagindo diretamente com esses dados e retransmitindo para os outros em tempo real, como se fossem dados numa folha de papel única onde todos rabiscam ao mesmo tempo, sem necessidade de presença física. Depois dessa reunião, o banco de dados de cada filial já está atualizado.

A agenda eletrônica de todos é atualizada dinamicamente pela rede ligada às outras agendas - um conceito interessante onde um compromisso de grupo é inserido nas respectivas agendas automaticamente, com um programa que verifica a disponibilidade de cada um do grupo a arruma a agenda da melhor forma possível.

(comentário) Esse trecho é bizarramente atual, em tempos de quarentena e trabalho remoto. Em 1996 já era possível imaginar agendas compartilhadas via Google Calendar, calls via Zoom e trabalho colaborativo usando coisas como um Google Docs de hoje. Mas apesar de parecer uma premonição, na época a gente já conhecia coisas como o Lotus Notes e depois o próprio Microsoft Exchange pra trabalho em equipe. Guardem isso que vou explicar mais pra frente.

Notável é o uso de termos como Era da Informação. Em gerenciamento se falava muito disso da era dos Knowledge Workers ou trabalhadores do conhecimento, pra contrastar os novos tipos de profissão que não tem rotina, como programação, onde o principal é a capacidade de resolver problemas diferentes em vez de repetir as mesmas coisas todos os dias. Esse termo foi cunhado por uma das referências na área de administração, Peter Drucker.

E também note como eu falei de “mini câmera” porque o termo webcam ainda não era usado. Dois anos antes, em 1994 a Apple foi uma das primeiras a ter uma webcam, mas chamava QuickCam, feita pela Connectix. Essa foi a primeira versão comercial, e o primeiro protótipo foi de 1991, de estudantes da universidade de Cambridge que apontaram uma camera conectada na rede pra vigiar uma garrafa de café, daí eles não precisavam perder tempo indo até a cozinha se não tivesse café. A preguiça bem aplicada é sempre uma boa fonte de inspiração pra inovações. Vamos continuar.

Durante o dia ainda tem uma série de operações bancárias que precisam ser feitas. Depois de confirmadas são todas enviadas pra um servidor do banco via computador. Uma senha de segurança é digitada e todas as movimentações financeiras do dia são efetuadas.

No fim do dia ainda precisa fazer reservas de vôo pras férias que tá chegando. Via computador dá pra acessar a rede da companhia aérea, conhecer os diversos pacotes de férias e daí decidir o mais adequado. Daí é só preencher um formulário eletrônico, um e-form, e pronto.

Fim do dia, nosso amigo já tá exausto depois de trabalhar o dia todo e resolve pedir uma pizza. Na Internet as melhores pizzarias já tem sites pra pedidos eletrônicos. Depois de fazer o pedido é só dar o número do cartão de crédito. A pizza chega em pouco tempo, entregue a domicílio.

Da mesma forma também dá pra ir numa renomada loja de música ou livros e fazer encomendas depois de uma longa olhada na seleção dos best-sellers do mês na Web, igual ao pedido de pizza. O cartão de crédito vem servindo bem por enquanto como o dinheiro eletrônico da Internet.

Então, depois de mandar alguns e-mails pra amigos e ver a última atualização do jornal da noite na Web, o dia acaba bem. Esse foi um resumo do dia de uma pessoa de negócios da nova geração. Mas ainda tem os herdeiros dessa nova geração, os jovens. O novo mundo tem espaço pra todos e crianças e adolescentes são os alguns dos principais usuários das novas tecnologias de informação.

(comentário) Dependendo de como você lê esse trecho, pode pensar que a gente já tinha previsto a massificação do Internet Banking, do ecommerce em geral, como Amazon, até delivery como iFood. Na real não é bem assim. Em 96 já existia internet banking, bem limitado e desconhecido mas tinha.

O primeiro banco brasileiro a oferecer algum serviço via web foi o Bradesco em 95. E outros bancos como Unibanco seguiram rápido. Era super precário. Se você acha os de hoje ruins, nem imagina como era em 96, mas pra ser justo, eles até que tavam tentando.

Nem Amazon, nem MercadoLivre, nem nada disso ainda ia existir por mais meia década, mas já existiam exemplos rudimentares de ecommerce. O que é considerado o primeiro grande ecommerce do Brasil foi a Booknet do escritor Jack London, fundada no final de 95. Se você nunca ouviu falar, alguns anos depois ela foi vendida pra GP investimentos, um dos primeiros venture capitalists a atuar na américa latina.

Sua fundação se tornou o Submarino.com. Muito antes da B2W ou da Americanas. Claro que em 96 a gente não sabia disso. Acho que eu nem sabia que a Booknet existia ainda. Mesmo em 99 ele tinha só uns 50 mil clientes, e isso já era considerado grande na época.

Ecommerce ainda era bem difícil porque ninguém tinha motivos pra confiar em digitar número de cartão de crédito em sites estranhos. Levou anos pra tecnologia convencer as pessoas que finalmente ficou seguro. Mas em 96 realmente era bem inseguro fazer compras online.

Não impactava tanto quanto hoje porque a gente não tinha uma fração da quantidade de gente transacionando. E já se tinha a noção de que poderia existir algum tipo de e-dinheiro ou dinheiro digital. E-cash é um conceito que só viria a acontecer mesmo mais perto do ano 2000. O Paypal mesmo só seria fundado em 1998.

E no último trecho é notável também que a gente acreditava que os jovens iriam ter um papel fundamental na adoção de novas tecnologias. A primeira rede social online no formato mais parecido com o que conhecemos hoje, fora dos aplicativos só de comunicação como IRC, AIM ou ICQ seria o SixDegrees.com de 1997, que foi o avô de redes como Friendster, MySpace ou Orkut.

Tomando isso como base já temos quase todos os elementos pra novas tecnologias, como computadores de bolso. Esse tipo de dispositivo seria mais ou menos do tamanho dos pagers que temos hoje, com microprocessadores poderosos e menores do que os atuais, e com ligação wireless a milhares de servidores disponíveis em várias redes, como a Internet. Pagamentos em lojas e quiosques seria feita utilizando esse aparelho pra realizar movimentações financeiras uma vez que há a possibilidade de se ligar à um banco.

Além disso há a unificação de plataformas com a Internet. A Internet é quase um sistema operacional completo. Com linguagens como um Java de hoje já é possível criar aplicativos disponíveis em tempo real na rede sem a necessidade de uma cópia em cada micro, ou seja, pra usar um editor de textos precisaria instalar no HD do seu micro numa plataforma como Windows.

Com a plataforma da Internet os HDs seriam praticamente desnecessários em sistemas de computação móvel, com o sistema operacional pra rede gravada em ROM e seus arquivos poderão ser gravados no espaço em disco na conta Internet disponível. As vantagens são óbvias: menor espaço físico pro micro local, acessibilidade do aplicativo e dos arquivos salvos de qualquer lugar e usando qualquer computador ligado à Internet.

(comentário) Isso se parece muito com o que você tem hoje em dia com SaaS e Cloud em geral: não precisa instalar nada pra usar Google Docs, Gmail, Slack, e ter todos os seus arquivos no cloud, num Microsoft OneDrive ou Dropbox. Nos anos 90, empresas como a Sun e Oracle estavam tentando entender a melhor forma de organizar aplicativos online. Porque instalar na máquina de todo mundo e ter o trabalho de atualizar tudo? Em vez disso porque não ter servidores potentes e máquinas clientes mais fracas que servissem só como terminais. Era a idéia dos NetPCs.

Na nossa cabeça de 96, o nosso Google Docs de hoje seria um aplicativo feito em Java que carregaria pelo navegador como um applet. E passamos anos tentando fazer algo assim, tanto com applet como com coisas como ActiveX da Microsoft. Ainda ia levar mais de 10 anos, até a época do primeiro Gmail, pro HTML e Javascript finalmente se tornarem minimamente usáveis pra aplicativos.

E ainda ia levar até 2006 pra AWS aparecer e começar a moldar a idéia de cloud computing, onde a gente teria nossos dados e processamento totalmente na nuvem. Além de cloud, o primeiro trecho descreveu exatamente como é um smartphone dos dias de hoje, perceberam?

Em casa, a indústria de entretenimento ganha um novo aliado. Até agora um dos maiores avanços foi a introdução da TV a cabo, com imagens de altíssima qualidade e possibilidades de centenas de canais diferentes. Isso vem se tornando quase tão comum quanto um videocassete. Tomando carona nessa infra-estrutura um aparelho parecido com um videogame ou videocassete está sendo testado e já tá em fase avançada de desenvolvimento: o set-top-box.

Esse aparelho, munido de rápidos e poderosos microprocessadores irá se tornar o aparelho padrão da casa moderna. Com um set-top-box ligado à TV e conectado à Internet uma infinidade de possibilidades seriam abertas. A interatividade com os programas de TV como os Talk-Shows ou Game-Shows seriam muito maiores com os telespectadores interagindo com os apresentadores com a velocidade de transmissão dos cabos usados na TV a cabo. Os sistemas de tele-compra se difundiriam muito mais transformando Shopping Centers inteiros em ambientes virtuais a serem navegados na Internet.

Além disso, quando os set-top-box ficarem mais comuns, coisa de no máximo uma década, as video-locadoras atuais seriam virtualmente extintas devido à outra tecnologia: o video-on-demand. Com a velocidade aumentada devido à utilização de cabos de fibra-ótica, muito mais dados poderiam trafegar de uma vez o que tornaria possível transmitir filmes inteiros via Internet.

As pessoas também já não precisariam mais ficar presos a horários fixos. Com as telecomunicações ligadas na rede, bancos de dados de grande capacidade poderiam armazenar todos os programas do dia e transmití-los à vontade do assinante. Assim, basta escolher num menu que apareceria na tela da TV pelo programa que tem vontade de assistir na hora que quiser e não perder mais tempo com comerciais ou ter que ir à uma locadora para alugar um vídeo.

(comentário) Desde o começo do Java, antes dos NetPCs, muitas empresas já vinham perseguindo a idéia de um microcomputador que eles chamavam de set-top-boxes. Literalmente caixas que você ia deixar em cima da TV, talvez recebendo internet pela mesma infraestrutura de TV a cabo. E seria tipo um hub, um cérebro que ia permitir a gente ter mais controle sobre a programação da TV.

Muita gente até hoje ainda assiste TV de forma passiva, mas se você assiste meu canal você faz parte da geração que assiste o que quer e quando quer via YouTube ou Netflix da vida. O que a gente chamava de set-top-box hoje você chama de Chromecast ou Apple TV, ou melhor ainda, SmartTV, que já vem embutido com um microcomputador dentro rodando algum Android da vida.

Na previsão a gente fala que em até 10 anos isso ia acontecer e seria o fim das locadoras. Levou mais de 10 anos, precisou de coisas como o Tivo, Roku, Apple TV, Chromecast, o sucesso da tecnologia de smartphones pra termos processadores ARM e sistemas operacionais como Android ou Tyzen pra ficar barato o suficiente pra adicionar em toda TV. Todo mundo tentou solucionar esse problema na 1a década do século XXI, mas foi um processo bem mais lento de várias empresas em paralelo. Mas mesmo assim, redes de locadoras como Blockbuster de fato desapareceram antes disso.

Bill Gates acreditava que a Internet da época ainda era a versão 1.0, super rudimentar, super lenta. Boa parte do que a gente usava dependia da infraestrutura da antiga Arpanet, montada mais pra fins acadêmicos. Não era robusta o suficiente. Pra internet comercial acontecer de verdade precisaria haver algum motivo pras pessoas quererem banda larga.

É um investimento enorme das telecoms e elas precisam saber que haveria retorno desse investimento. Gates acreditava que video on demand seria o catalizador pra essa demanda, porque só via linha discada da época seria impossível assistir video em tempo real como fazemos hoje.

A febre da bolha da Internet ajudou a acelerar essa infraestrutura. Muitas empresas investiram nisso durante o fim dos anos 90 e começo dos 2000. Mas levou mais de uma década pra gente ter banda larga difundido o suficiente pra possibilitar um YouTube a partir de 2005.

Hoje em dia, de fato, o maior uso de banda no mundo é de serviços de streaming, tanto que quando as quarentenas começaram e todo mundo foi obrigado a ficar em casa, aumentou dramaticamente o uso de banda ao ponto que os governos da Europa pediram pra Netflix da vida forçar baixar a qualidade do streaming pra usar menos banda, porque a infraestrutura não tava preparada pra tanta demanda do dia pra noite.

Mas o ponto é que o Gates tava certo em imaginar que se a internet fosse se tornar o tal “information superhighway”, como ele chama no livro, termo cunhado pelo Al Gore lá por 94, a infraestrutura física tinha que ser muito mais que usar a rede discada e modens lentos.

Iria passar pelo reuso da rede de TV a cabo até conseguirmos ter fibra ótica, cabos submarinos, satélites e tudo mais pra ligar tudo mundo em banda larga como é hoje. E o catalizador pra isso poderia ser video on demand, como de fato foi. Mas a previsão tava muito arrojada, demorou um pouco mais do que a gente pensava.

O comércio ganharia um contexto totalmente novo. Hoje em dia vamos às lojas, pesquisamos no boca-a-boca, gastamos horas e horas visitando dezenas de lojas por horas a fio até encontrar o que precisamos. Os mais avançados usam o sistema de tele-compras que usam canais de TV só deles pra apresentar produtos e permitir compras só usando telefone, cartão de créditos, com entrega a domicílio. Utilizando um micro na Internet também já temos a possibilidade de encontrar muitas opções parecidas como lojas de música, livros, equipamentos eletrônicos, companhias aéreas e mais.

Mas num futuro bem próximo vamos ter virtualmente tudo que temos na vida real via Internet. Teríamos desde o mais simplório super-mercado até o maior Shopping Center em ambientes virtuais pra navegarmos com simplicidade e todas as compras seriam feitas via cartão de crédito, como hoje, ou por dinheiro-eletrônico. Nesse sentido já existem muitas empresas se ligando a grandes bancos para criar um padrão seguro e viável de virtualizar o dinheiro, assim as operações financeiras seriam muito mais fáceis e seguras que hoje.

(comentário) Esse era um dos usos mais fáceis de visualizar naquela época, que é o comércio online. Mas a gente ainda não tinha muita idéia de como isso ia acontecer. Muito tempo antes da gente se preocupar com segurança, alguns se arriscavam a comprar online com cartão de crédito. Mas antigamente não tinha Paypal nem nada disso. SSL tinha acabado de ser inventado. Quase nenhum banco tava preparado pra esse tipo de integração. Ainda ia levar alguns anos pro ecommerce se tornar massivo.

Naquela época a gente ainda não conseguia imaginar um Google, muito menos ad sense, SEO e tudo mais. Nossa idéia de procurar na internet era ter algo parecido com as páginas amarelas na Web. Era a idéia ingênua de catalogar tudo que existe mas ninguém pensava que teria tantos sites que logo precisaria ter alguma forma de pesquisar via relevância. A gente tinha idéia de search engines mas não tinha idéia do PageRank do Google, que ainda estava bons 3 anos no futuro.

Fora que hoje temos o conceito de marketplaces, onde uma Amazon ou MercadoLivre da vida concentra acesso ao inventários de centenas de lojas menores por baixo. A idéia antiga eram só lojas independentes ou algum conceito de shopping center virtual. E quando a gente falava “virtual” era uma noção bem scifi de realidade virtual mesmo.

VR era uma tecnologia que a gente tava começando a brincar. Mas nem hoje ninguém sabe como é o melhor jeito ainda. O máximo que a gente tinha na cabeça era a idéia de portais web, que todo discador dava acesso, como UOL, Terra ou iG da vida, que funcionavam como porta de entrada pra tal “web”.

Em outra situação veríamos uma pessoa entrando no seu carro popular mas com um detalhe se sobressaindo no painel: uma espécie de tela plana wireless ligada à Internet poderia automaticamente ler as informações sobre as vias públicas mais próximas e identificar um engarrafamento e encontrar um caminho desobstruído. Além, é claro, de servir como um computador de bordo completo.

(comentário) De novo, esse tipo de coisa não era tão difícil de imaginar porque a gente já tava começando a ver a primeira geração de GPS e mapas digitais. Lógico que dali pra um Waze ia precisar de quase 20 anos de novas tecnologias. Mas o conceito que a gente entendeu nos anos 80 a 90 foi a visão de Gordon Moore, onde o poder de processamento dobra a cada 2 anos mais ou menos.

Em particular passamos os anos 70 e 80 vendo empresas como a Sony miniaturizando tudo, como sair dos enormes tocadores de LP pra walkmans por exemplo, então a gente extrapolava que no futuro ia continuar nesse mesmo ritmo e muito em breve ter um computador no carro seria inevitável.

As escolas e os centros de treinamento também seriam beneficiados pelas novas tecnologias como monitores planos tão finos quanto um quadro-negro ligados à um micro computador e este ligado à Internet. Qualquer dado poderia ser adicionado à uma apresentação pré-preparada em real-time ou então um grupo de pesquisadores poderia se comunicar com um expert do outro lado do planeta via teleconferência. E em vez de cada participante fazer anotações em cadernos usando as primitivas canetas ou lápis, cada computador de bolso pessoal seria ligado à rede local e toda informação relevante seria automaticamente armazenada na sua conta de Internet.

O Wallet-PC substituiria vários documentos como a carteira de identidade, documento de motorista, passaporte, exames médicos e muito mais, bastando ao usuário digitar sua senha pessoal e acessar os dados pela rede. Assim, num aeroporto, a passagem seria validade pela transferência de dados do micro computador ao computador do aeroporto, o passaporte seria verificado e a passagem validada sem a necessidade de qualquer outra interação do usuário senão tocar na tela ( touch-screen ).

(comentário) Uma das coisas que o Gates acertou foi a noção de smartphones que temos hoje. Ele chamava de Wallet-PC e tecnicamente ele descrevia como um computador do tamanho de uma carteira.

Vale lembrar que a Microsoft de fato tentou implementar muitas dessas idéias. Lá no começo dos anos 2000 eles já tentaram ter uma tela de notebook com touch com suporte no Windows. Mas o conceito ainda tava muito à frente do tempo. Foi só depois dos Blackberry, lançamento do iPhone, telas multi-touch e a chegada das redes 3G que chegamos a concretizar essa visão.

Depois surgiram coisas como QR codes, RFID e outras formas de codificação que facilitaram muito termos coisas como passagens digitais, identificação de produtos e muito mais, mas isso só apareceria mesmo na última década.

A parte da educação que não mudou muito. Eu fico pasmo de ver que estudantes de computação hoje estão aprendendo mais ou menos do mesmo jeito que eu aprendia em 96. Claro que ter material online, comunicação distribuída como whatsapp, emails, google drive e tudo mais ajuda muito comparado ao que eu tinha, mas não foi uma disrupção significativa. O sistema em si ainda é o mesmo. Uma hora eu falo mais sobre educação, mas se os cursos de agora são alguma indicação, essa é uma área que evoluiu muito pouco.

A evolução mais que premeditada e com a ajuda de dezenas de gigantes da informática como Oracle ou Microsoft é a da Super Information-Highway, a evolução direta da Internet e provavelmente uma das maiores revoluções da conectividade. Isso irá acontecer quando a rede for usada pra mais serviços, difundida nas casas de mais pessoas com possibilidades de armazenamento de dados, processamento de informações e muito mais além de conseguir concentrar o mundo todo numa grande rede onde dá pra fazer quase tudo. A rede que vai ligar os micros em casa aos servidores das empresas aos Wallet-PC aos computadores de bordo de veículos de qualquer natureza e a muito mais coisas.

E tudo isso é só uma simples amostra das tendências para a próxima geração, coisa muito próxima e já com muitos elementos prontos e outros já em desenvolvimento. Em pouco tempo todas as tarefas dispendiosas e tediosas poderão ser feitas em segundos e informações de milhões de fontes diferentes em centenas de locais distribuídos no mundo todo estarão disponíveis ao “toque de um dedo”.

(comentário) E essa foi minha conclusão. A gente sempre tinha na cabeça esse conceito abstrato chamado Information Superhighway. A internet comercial tinha acabado de começar mas a gente ficava imaginando o que seria a próxima versão da internet. Isso era derivado da idéia do Gates de ter um computador em cada casa, e o passo natural com a internet era cada computador em cada casa com acesso à internet. Mais do que isso, o processamentos e os dados nesse lugar abstrato que antes chavam de super highway e hoje chamamos de Nuvem.

Eu com 19 anos nunca fui o tipo empreendedor nem nada disso. Depois de ler tudo isso eu tava empolgado com o futuro. Mas eu não tinha vontade de ser aquele que ia inventar o Waze, Zoom, Google ou qualquer coisa assim. É aqui que eu falo que você tem que tomar cuidado pra não querer tentar fazer as coisas do jeito que eu faço.

Eu simplesmente gosto de novas tecnologias. 25 anos depois eu continuo inconformado e quero mais. Mas não tenho esse drive de precisar fazer as coisas eu mesmo. É meio como quem gosta de carros esportivos, você quer poder dirigir um Lamborghini, mas não necessariamente quer construir o próximo Lamborghini. Ou quem gosta de um bom vinho gran crux. Eu quero poder tomar um vinho campeão mas não quero gastar a próxima década produzindo a melhor uva. Tecnologia pra mim é que nem um Armani, eu quero ter, mas não faço questão de virar estilista pra isso.

Eu sempre gostei de adotar tudo que saía de novo, o novo me deixa empolgado. Tecnologia em particular é interessante porque é como poder ter uma Ferrari sem precisar pagar o preço de uma Ferrari, porque é tudo digital, só baixar e entender. Novos sistemas operacionais, novas linguagens, novas bibliotecas. Eu sempre tive a obsessão de um colecionador.

Por acaso, à medida que eu ia colecionando, e ia aprendendo os detalhes de como cada coisa funcionava, por coincidência esse conhecimento acabaria sendo útil pra muita gente. E no próximo episódio vou mostrar como essa obsessão por colecionar tecnologia iria ser a fundação da minha carreira de maneiras inesperadas.

Só refletindo hoje é que parece que o livro The Road Ahead foi mais influente do que eu imaginei na época. Eu nunca fui fã do Bill Gates, mesmo depois de ter lido o livro. A gente usava coisas da Microsoft porque era a maior e praticamente não tinha concorrentes. Apesar de ter usado MS-DOS e Windows 3.1 por anos já, logo que saiu coisas como o Netscape ou Linux, eu quis usar no mesmo dia que descobri que existiam. Desde a faculdade eu nunca tinha aprendido o conceito que a gente precisava ser fã de alguma coisa. Eu só queria o que era mais novo e melhor e ponto.

O episódio de hoje foi mais pra desenterrar mais uma memória que eu nem lembrava que tinha e por coincidência é um material que fez 25 anos este ano. Eu gosto de ter guardado esse material que escrevi. Era uma época em que a gente era ingênuo e tudo parecia possível. Muita coisa que tinha no livro do Gates não aconteceu ou aconteceu diferente. Então também não é um livro profético nem nada. É muito fácil escolher só as previsões que deram certo. Especialmente porque as que deram certo poucas vieram da própria Microsoft. Empresas como Google, Apple, Amazon foram mais decisivas em concretizar essa visão no meio dos anos 2000.

Eu não sou nenhum tipo de profeta ou tenho bola de cristal por ter escrito essas coisas. Eu só observei o que outros como Gates falavam. O próprio Gates estava perto do ápice. Pra dar noção, no fim de 1996 a Microsoft ia ser avaliada em 100 milhões de dólares. Ao fim dos anos 90 estava próxima de meio trilhão, mas aí a bolha da internet estourou e ela diminuiu pra menos de 1 quarto de trilhão. Depois da crise financeira de 2008 ia diminuir ainda metade desse valor, pra ficar próxima dos 100 milhões de valuation igual 1996. Mas depois iniciou o atual super ciclo de crescimento, onde todo mundo só cresce faz quase 12 anos e em 2019 ela finalmente ultrapassaria o 1 trilhão, pra se unir aos big 4 de hoje que são a Apple, Alphabet e Amazon.

Por causa disso ele tem acesso a todas as principais pesquisas em todas as principais áreas da indústria. O co-autor do livro The Road Ahead foi Nathan Myhrvold, que foi CTO da Microsoft na época e co-fundador da controversa Intellectual Ventures que é um portfolio de patentes. Ele já desenvolveu e comprou dezenas de milhares de patentes e é considerado um “patent troll”, que são aqueles que saem processando os outros por patentes triviais até, quase extorsão.

Mas apesar das controvérsias ele de fato é um cientista que ao longo dos anos trabalhou em diversas áreas como astronomia, paleobiologia e muito mais. O ponto é que o co-autor do livro tinha de fato o dedo em todo tipo de inovação que tava no forno e ninguém sabia que existia na época. O melhor jeito de prever o futuro, como já diria Steve Jobs, é inventar o futuro.

Seria muito clichê dizer que o livro me inspirou a entrar na área de wallet-pcs que viriam se tornar smartphones ou a estudar redes pra entender como fazer video on demand ou qualquer coisa assim, mas também não. Nenhuma decisão de carreira que eu tive jamais teve nada a ver com o livro. Mas de qualquer forma é uma publicação que fez sentido pra minha cabeça de 19 anos de idade e me ajudou a visualizar como as coisas poderiam ser no futuro. Então quando cada uma dessas coisas começaram a aparecer anos depois, facilitou eu adotar porque fazia parte dessa grande visão de futuro.

Por hoje eu só queria compartilhar essa história não pra dizer que ela me inspirou a seguir determinado caminho, mas sim pra dizer que uma vez que a gente chega no futuro é muito fácil contar uma história voltando pra trás. Hoje em dia os jovens de 19 anos provavelmente estão igualmente empolgados com o que os visionários de hoje prevêem sobre o futuro como os Elon Musk da vida.

O aviso é só pra não acreditar em tudo ao pé da letra, mas não há mau nenhum em ter a visão de inteligências artificiais e fontes de energia alternativas pro futuro. Daqui 25 anos talvez essas coisas já tenham se tornado triviais também. E quem quiser compartilhar histórias do que pensavam sobre o futuro nos anos 90, não deixem de mandar nos comentários abaixo. Se curtiram o video deixem um joinha, assinem o canal, cliquem no sininho e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

[Akitando] #86 - O Computador de Turing e Von Neumann | Por que calculadoras não são computadores?

Fri, 23 Oct 2020 10:00:00 -0300

DESCRIÇÃO

Quem foi John Von Neumann? Como ele e Alan Turing inventaram o computador moderno? E como uma máquina de escrever levou Alan Turing ao computador? E o que é esse tal de “Turing Complete” que toda discussão de linguagens de programação menciona?

00:00 - Intro
01:24 - Alan Turing e sua máquina de escrever
06:31 - O que são Máquinas de Turing?
15:41 - de Babbage, a Zuse, ao Colossus
20:17 - O que é Turing Complete?
30:03 - O maior gênio que já viveu: Von Neumann
39:35 - Turing + Von Neumann = Computador Moderno

Links:

Boy Who Wanted to ‘Make a Typewriter’ Instead Became Father of Computer Science (https://oztypewriter.blogspot.com/2013/09/boy-who-wanted-to-make-typewriter.html)
What exactly is Turing Completeness? (https://medium.com/@evinsellin/what-exactly-is-turing-completeness-a08cc36b26e2)
Are There Problems That Computers Can’t Solve? (https://www.youtube.com/watch?v=eqvBaj8UYz4)
Turing Machine Visualization (https://turingmachine.io/)
Turing Complete (https://wiki.c2.com/?TuringComplete)
Who Invented the Computer? (https://www.turing.org.uk/scrapbook/computer.html)
Konrad Zuses Z3 in Detail (http://www.inf.fu-berlin.de/lehre/SS01/hc/zuse/node4.html)
The Unparalleled Genius of John von Neumann (https://medium.com/cantors-paradise/the-unparalleled-genius-of-john-von-neumann-791bb9f42a2d)
Plankalkül (https://en.wikipedia.org/wiki/Plankalk%C3%BCl)
PC Jr (https://www.pcjs.org/)

SCRIPT

Olá pessoal, Fabio Akita

No final da segunda parte do video sobre teclados, quem assistiu viu que mostrei o avô dos teclados mecânicos, a máquina de escrever de verdade. E quando eu adicionei ele no video eu tinha dois objetivos. O primeiro, claro, era adicionar uma camada de história naquele video, mas o segundo era usar de gancho pra historinha que quero contar hoje. Aliás, historinha nada, se prepara que essa vai ser uma história bem longa e se você nunca leu sobre Turing e Von Neumann, você vai finalmente entender o que é um computador e porque uma máquina de calcular não é um computador.

Além disso este episódio vai servir como ponte entre os vídeos do guia hardcore de introdução a computação com o Nintendinho que mostrei alguns vídeos atrás, e o próximo que vai ser mais leve e quero falar um pouco mais sobre meus video games e emuladores preferidos. Quero explicar como que de uma máquina de escrever foi possível chegar no computador moderno. E quero contar um pouco da história das duas pessoas que eu considero mais importantes e que representam o tipo de gigantes que construíram as bases da computação moderna. Vamos focar em duas dessas pessoas, uma é famosa e você provavelmente conhece. O outro é um dos maiores gênios que já existiu, um monstro de proporções bíblicas, pau a pau ao intelecto de um Albert Einstein, mas que você provavelmente nunca ouviu falar.

(…)

Como disse na introdução, a história que vou contar agora eu tô segurando desde quando fiz a série sobre teclados. Quem assistiu vai se lembrar da máquina de escrever mecânica original de Christopher Sholes. O que vocês não sabem é que a máquina de escrever teve um papel crucial na invenção do computador moderno. Não lembro como mas anos atrás eu esbarrei num artigo muito bom do blog de um cara chamado Robert Messenger, de 2013, e eu vou pegar bastante coisa dele.

O artigo começa assim: em vinte e três de junho de 1912, no quadragésimo quarto aniversário da primeira patente de máquina de escrever de Christopher Latham Sholes, uma data celebrada até hoje como o Dia da Máquina de Escrever - Ethel Stoney Turing, filha do engenheiro chefe da Madras Railways, deu a luz em Paddington. Um filho. Onze anos depois, no verão de 1923, esse menino, Alan Mathison Turing escreveu a seus pais a partir da sua escola em Hazelhurst, Sussex. Os pais estavam na India porque o pai, Julius Mathison Turing trabalhava no serviço civil da India. Ele contava que naquela semana ele imaginou como fazer uma máquina de escrever..

Alan Turing nunca inventou uma máquina de escrever, mas usou de inspiração pra se tornar o pai da Ciência da Computação. Talvez vocês se lembrem do filme The Imitation Game, onde o eterno Sherlock Holmes, Benedict Cumberbatch, interpreta Alan Turing no famoso episódio da Segunda Guerra Mundial, onde ele derrota a máquina de criptografia Enigma dos alemães com uma máquina de computar enorme, um passo importante pra ajudar terminar a guerra a favor dos Aliados. Se ainda não assistiu o filme, recomendo, embora ele não explique de fato como funciona a máquina de Turing, pra isso recomendo ver meus videos sobre criptografia.

(mostrar maquina) O filme foi baseado no livro Alan Turing: The Enigma, de Andrew Hodges, que foi publicado em 1983. Num dos trechos dessa biografia temos a passagem que diz que a mãe de Turing tinha uma máquina de escrever e que isso fascinava o jovem Alan. Ele desenhou sua máquina automática ou a-machine como um tipo idealizado de máquina de escrever com carriage, ou carro, infinito, sobre a qual uma cabeça de leitura passava com habilidade não só de escrever, mas de ler e apagar um quadrado de cada vez antes de mover pro quadrado imediatamente adjacente.

A biografia segue explicando que, claro, existiam máquinas que manipulavam símbolos naquela época, a máquina de escrever era um exemplo. Alan sonhou em inventar máquinas de escrever quando criança. Sua mãe tinha uma e ele pode ter começado se perguntando o que significava dizer que uma máquina é “mecânica”. Podia significar que sua resposta, pra alguma ação de um operador, era perfeitamente previsível. Esquece por um momento que você já conhece computadores, e pense numa época que só se conhecesse máquinas como a de escrever.

Alguém poderia descrever de antemão exatamente como a máquina se comportaria sob qualquer contingência. Mas havia mais a ser dito sobre a humilde máquina de escrever do que isso. A resposta depende das condições da máquina, ou o que o Alan chamava da “configuração” atual da máquina. Em particular, uma máquina de escrever poderia estar na configuração de maiúscula ou minúscula.

Essa era uma idéia que o Alan elaborou de forma mais genérica e abstrata. Ele considerou máquinas que em qualquer determinado momento estariam em uma de um número finito de possíveis configurações. Então, se existe somente um número finito de coisas que a máquina pode fazer, é possível saber todo o comportamento da máquina de uma forma finita.

Entretanto, a máquina de escrever tinha uma funcionalidade a mais que era essencial à sua função. Seu ponto de digitação se mexia, relativo à página. Sua ação de digitação seria independente da posição desse ponto na página. Ela teria “configurações” internas e uma posição variável na linha de impressão. A ação da máquina não dependeria da sua posição.

Sem levar em consideração detalhes como margem, linha de controle e assim por diante, o que eu acabei de listar seria suficiente pra dar uma descrição completa da natureza de uma máquina de escrever. Um relato exato das configurações e posições permitidas e de como teclas determinam os símbolos impressos, tecla de shift pra mudar configuração de minúscula pra maiúscula, a barra de espaço e backspace, tudo isso resumiria as funcionalidades mais relevantes.

Se um engenheiro olhasse essa descrição e criasse uma máquina física que atendesse a essas especificações, o resultado seria uma máquina de escrever, independente da cor, peso ou outros atributos. Mas uma máquina de escrever era muito limitada pra servir de modelo. Ela lidava com símbolos, só conseguia escrever, e precisava de um operador humano pra escolher os símbolos e mudar as configurações de posição, uma de cada vez. Então Turing se perguntou, o que seria um tipo “mais” genérico de máquina que lidasse com símbolos?

Pra ser uma “máquina” ela precisaria reter a qualidade de uma máquina de escrever, de ter um número finito de configurações, e um comportamento determinado exato em cada. Mas deveria ser capaz de muito mais. Então ele começou a imaginar máquinas que seriam super-máquinas de escrever.

Pra simplificar, ele imaginou máquinas trabalhando só em uma linha. Isso é uma tecnicalidade, mas que permitia esquecer de coisas como margens e linhas de controle. Mas era importante que o suprimento de papel pudesse ser, tipo, infinito. Nessa imagem, o ponto de digitação de sua super máquina de escrever poderia progredir pra esquerda ou pra direita indefinidamente. Por uma questão de definição, ele imaginou esse papel sendo uma forma de fita, marcado com unidades quadradas, de tal forma que somente um símbolo pudesse ser escrito em cada uma. Então suas máquinas teriam uma definição finita, mas poderiam trabalhar em uma quantidade infinita de espaço.

E assim foi nascendo as sementes da idéia de uma máquina discreta universal, ou seja, que pudesse ser configurada pra várias tarefas diferentes. A máquina de escrever de Sholes, reduzida aos seus princípios fundamentais, nos suporta até hoje. Turing simplesmente se livrou das pessoas e digitadores. E isso é possível porque a máquina de Turing é ainda mais excepcionalmente crua do que uma máquina de escrever. Tudo que ele usa é uma fita de papel que é ao mesmo tempo material de programa e dados, seu input e output ao mesmo tempo.

Turing enxugou a máquina de escrever a essa fita. Mas tem ainda mais economias, sua máquina não precisa de letras redundantes, cifras e sinais de um teclado de máquina, ele consegue se virar somente com um sinal e a ausência desse sinal, ou seja, 1 e zero. Essa informação binária pode ser lida ou escaneada pela máquina. Daí ela pode mover a fita de papel um espaço pra direita, um pra esquerda, ou não se mexer.

E é só isso. Sério, isso que acabei de descrever é um computador. E nenhum computador que já foi construído ou vai ser construído vai conseguir fazer mais que esse modelo. Isso foi provado matematicamente por Alan Turing em 1936. E resumindo, uma máquina de Turing conforme definido no seu paper On Computable Numbers, with an application to the Entscheidungsproblem, são construções matemáticas abstratas que nos ajudam a descrever rigorosamente o que significa computação.

Se você não entendeu ainda o que é isso de fita infinita e cabeça de leitura, eu achei um site chamado Turing Machine Visualization que permite escrever uma máquina de Turing usando uma simplificação da notação que ele usou no seu paper. No paper, Turing define sua máquina como tendo um ou mais estados, cuja notação é esse Quezão, daí um estado inicial q0 pertencente a Quezão, algum parâmetro de entrada Sigma, a tal fita Gamma, onde Sigma que é o parâmetro está contido na fita Gamma, um símbolo branco bezinho pertencente à fita Gamma, e uma ou mais funções de transição Delta que tem o tipo indo de Quezão e Gamma para Gamma, left ou right ou seja, comando pra esquerda ou pra direita e Quezão.

Ver notação matemática é um troço que faz o cérebro da maioria desligar em pânico, mas relaxa que vai ficar mais simples já já. Vamos considerar uma máquina de Turing muito simples de exemplo, que faz um incremento em um número binário, basicamente soma 1 a um número. A gente viu isso no video do guia hardcore de introdução à computação, então você deve se lembrar. Vamos implementar usando essa notação.

Começamos definindo os estados possíveis nessa lista Quezão, temos direita, sobe um, e término. O processo começa no estado inicial q0 sendo ir pra direita. O número de entrada em binário é o Sigma igual a 1 0 nesse exemplo, mas poderia ser qualquer número em binário. A fita Gamma contém o Sigma então ele tem 1 0 e espaço em branco. E o bezinho define o espaço em branco.

Agora definimos as funções de transição. Se o estado for pra direita e a cabeça estiver lendo 1 na fita ele devolve 1, ou seja, não muda nada, vai pra direita e mantém o estado em ir pra direita. Mesma coisa pro zero. Porém, se ele ler um espaço em branco, não escreve nada mas agora muda o comando pra ir pra esquerda e muda o estado pra carry, ou sobe um.

Se o estado for sobre um e ele ler 1, agora apaga e escreve zero no lugar, em seguida dá comando pra continuar pra esquerda e mantém o estado em sobe um. Agora, se for zero, escreve 1, dá comando pra esquerda e muda o estado pra done ou término. Mesma coisa se ler espaço em branco.

Eu sei, até agora muitos de vocês provavelmente não estão entendendo nada, mas aguenta aí. Indo pro site que eu recomendei, o Turing Machine Visualization, podemos reescrever dessa notação mais formal pra uma mais prática e mais parecida com uma linguagem de programação. Eles fizeram um interpretador pra facilitar a gente escrever o equivalente a programinhas. Se você é programador, isso deve ser super trivial.

Então vamos trocar a notação matemática por … isto! Agora deve estar assustando menos né? Recapitulando, começamos definindo o equivalente a uma variável com o número binário que queremos incrementar, esse é tipo o argumento ou parâmetro de entrada. Daí tem esse blank que define o que é um espaço em branco. Temos start state sendo right que é o estado inicial de indo pra direita.

Em seguida temos a tabela de configuração de transições. Se você alguma vez já trabalhou num sistema de e-commerce por exemplo, já deve ter visto uma máquina de estados que define o estado de uma ordem de venda, por exemplo. Se eu vou na Amazon e compro um Kindle, meu pedido pode iniciar com um estado de aguardando pagamento e dá o comando de executar o pagamento. Quando o pagamento é confirmado o estado do pedido muda pra, por exemplo, aguardando envio, e ele solta um comando pra mandar pra fila do centro de distribuição. E assim por diante até o pedido ter confirmação da entrega.

Como é um conjunto finito de estados, chamamos essa estrutura de estados e transições de máquinas de estado finito ou autômatos finitos. Isso se estuda em Teoria dos autômatos, que é um sub-tópico de ciências da computação. Na prática você define diferentes estados que seu sistema pode estar, e define o que acontece na transição de um estado pra outro. Qualquer linguagem moderna tem bibliotecas pra lidar com isso. Mas de qualquer forma, a máquina de Turing original é configurada com uma tabela de estados e transições. No exemplo do site ela pode estar no estado de “right” ou o que eu chamaria de “indo pra direita” ou “carry” que seria “subindo um”. Subindo um no sentido do sobe um que fazemos em somas.

O primeiro estado é muito simples, ele simplesmente vai indo pra direita sem fazer nada enquanto for lendo 1 ou 0 na fita. Mas ele pára quando encontra um espaço em branco. Nesse caso ele muda o estado pra subindo um e recebe o comando de voltar pra esquerda.

No estado de subindo um, se encontrar 1 ele escreve 0, porque vai subir um pra esquerda. E vai trocando 1 por 0, 1 por 0, até encontrar 0. Daí ele pode colocar o 1 que tinha subido e terminar, já que esse programa é simplesmente um incremento de 1. E daí ele muda o estado pra “done” ou terminado. Nesse site você vai encontrar exemplos bem mais complexos que isso, por exemplo, pra determinar se um número é divisível por três. Ou melhor ainda, nós já vimos no outro video como fazer uma máquina de adição de números binários com o processador MOS 6502 num protoboard. Eis a versão de autômatos finitos numa máquina de Turing. Você pode ir avançando passo a passo pra ver o sistema funcionando visualmente, então é bem fácil de entender. Divirtam-se.

Na prática você poderia pensar no tal ponto de digitação que falei antes ou “cabeça” como a cabeça de leitura de um disquete, ou CD, ou Blu Ray, e a fita como sendo a cadeia de bits que tem nas trilhas. Nós sempre lidamos com dados e programas da mesma forma, como uma cadeia super longa de bits. Alguns dos bits são instruções que executamos como programa, outros bits são dados como um texto, uma imagem ou um video. E se for um HD, podemos escrever também. Além disso essa cabeça pode se movimentar pra trás ou pra frente, ou seja, ela pode ter acesso aleatório a qualquer posição na fita. E por exemplo, você vai se lembrar que RAM quer dizer exatamente isso, memória de acesso aleatório.

A beleza do trabalho de Turing foi ter definido com rigor matemático o que é um programa, na forma da máquina de Turing, configurado como transições entre estados finitos. E o conceito de uma máquina universal que consegue executar quaisquer máquinas de Turing, que é o que ele chama de máquina de Turing Universal e na prática chamamos isso de computador. Uma máquina Universal de Turing é uma máquina de Turing cuja tarefa é simular outra máquina de Turing arbitrária, com uma entrada de dados arbitrária.

O que chamamos de computador moderno tem uma característica muito importante: ela consegue carregar e armazenar configurações, ou o que chamamos de programas. Essa é uma distinção que eu considero importante. Recentemente me perguntaram isso: o que diferencia um ábaco ou uma calculadora mecânica de um “computador” de verdade? A definição é se ela é ou não é uma máquina universal de Turing, particularmente com a característica de não distinção entre programa e dados no armazenamento, na tal fita infinita, o que permite a universalidade dele poder simular outra máquina de Turing.

Antes de Turing existem diversos experimentos que alguns chamam de “computador” mas que na realidade seria mais correto chamar de máquinas de calcular grandes. E aqui eu vou usar trechos do artigo “Quem Inventou o Computador” do site do próprio autor da biografia do Turing, o Andrew Hodges. Ele diz, e eu concordo, por exemplo, que não podemos chamar o Engenho Analítico de Charles Babbage de computador. Ele não incorpora a idéia vital de armazenar programas da mesma forma que os dados.

A máquina de Babbage foi desenhada pra armazenar programas em cartões perfurados, enquanto o trabalho de calcular era feito mecanicamente por engrenagens e rodas. Havia outras diferenças, claro, como ainda usar base numérica decimal em vez de binário, ou obviamente não ser eletrônico já que sequer Thomas Edison tinha nascido naquela época.

Cem anos depois, em 1940, dava pra usar relays eletromagnéticos no lugar de engrenagens. Mas ninguém avançou além dos princípios da Babbage. Existiam grandes calculadoras que você podia reconfigurar mas nenhum deles era um computador. A idéia era a mesma: você construía uma máquina que fazia aritmética, e então rearranjava as instruções encodadas num cartão perfurado ou mudando cabos e switches de lugar ou algo assim, e fazia a máquina calcular. Depois que terminasse e precisasse fazer outro cálculo, precisava reconfigurar a máquina inteira de novo. Eram calculadoras grandes reconfiguráveis, mas não eram computadores. De novo, elas não tinham como armazenar programas e não eram capazes de simular qualquer outra máquina.

Pelo mesmo motivo, o ENIAC que muitos consideram um dos primeiros computadores também não era um computador. Era outra calculadora gigante. Sim, só porque era grande e complexa usava válvulas no lugar de engrenagens, não é isso que faz a máquina ser um computador. Durante a guerra teve várias tentativas de quebrar a criptografia alemã e um deles foi a máquina batizada de Colussus, na Inglaterra. Novamente, não era um computador, era uma máquina especificamente desenhada pra quebrar ciphers da máquina de Lorenz. E por mais complexa e útil que ela fosse, ainda não era um computador.

O papel mais importante do Colossus foi de fato mostrar pra Alan Turing, que também tava trabalhando pra quebrar a criptografia alemã, sobre a velocidade e confiabilidade da eletrônica. E esse aparato britânico tava na frente dos esforços norte-americanos já que o ENIAC tinha tamanho e complexidade comparáveis ao Colossus, mas só começou realmente a funcionar depois que a guerra tinha acabado, em 1946. E aí ela já tava obsoleta.

O engenheiro alemão Konrad Zuse desenhou calculadoras mecânicas e eletromecânicas de forma independente também, antes e durante a guerra. Ele não usou eletrônicos. E o que ele construiu ainda era mais próximo dos princípios de Babbage, mas teve o mérito de reconhecer a importância da programação e pode ser creditado por um tipo de linguagem, o Plankalkül.

Zuse foi um caso de azar. Ele era um gêniozinho também, autodidata, fazia tudo sozinho. Pra descrever circuitos lógicos ele inventou um sistema próprio de notação de diagramas. Depois de acabar o Z1 em 1938 ele descobriu que o cálculo que inventou sozinho já existia e era conhecido como cálculo proposicional. Enquanto trabalhava na sua dissertação de doutorado, ele desenvolveu o primeiro sistema formal conhecido pra notação de algoritmos, capaz de lidar com branches e loops. Ele descreveu sua linguagem Plankalkül num livro que não foi publicado, porque foi bem no período conturbado quando caiu a Alemanha Nazista. Os computadores que construiu foram destruídos por bombas durante a guerra, ele só conseguiu resgatar o Z4.

O Z3 também é considerado por muitos como o primeiro computador programável. Um ENIAC precisava ser reprogramado pra cada tarefa via o trabalhoso, tedioso e fácil de errar mecanismo via conexão de dezenas de cabos. E diferente do monstruoso ENIAC ou mesmo do Colossus da Inglaterra, foi o Z3 feito na unha por Zuse, sem financiamento do governo ou institutos nem nada, quem chegou mais perto do que Turing viria a definir como máquina de Turing. O problema é que o Z3 não tinha condicionais, mesmo assim, pelo menos na teoria, ele quase poderia ser considerado Turing Complete.

Nas palavras de Raúl Rojas que em 1998 demonstrou isso, ele diz “Nós podemos portanto dizer que, de uma perspectiva abstrata teórica, o modelo de computação do Z3 é equivalente ao modelo de computação dos computadores de hoje, mas de uma perspectiva prática, e do jeito que o Z3 é realmente programado, ele não equivale ao modelo moderno de computador”.

Aliás, assim como Raúl demonstrou, existem diversas formas artificiais e bem tortuosas de tentar montar experimentos teóricos abstratos que no caso extremo dá pra dizer que um Engenho Analítico de Babbage, o Z3 de Zuse ou o Colossus tem “potencial” de ser Turing Complete, mas na prática eles não tinham chegado lá de verdade. Eu disse que o caso de Zuse foi de azar porque sendo conterrâneo de Turing a diferença entre os dois é que Turing foi escolhido pelo governo Britânico pra ajudar nos esforços da guerra e teve a sorte de trabalhar num projeto de grande notoriedade, mas quando Zuse se voluntariou pra ajudar na guerra, ele foi rejeitado.

Antes de continuar a história eu falei algumas vezes o termo Turing Complete. E se você é programador faz algum tempo, já deve ter visto ou participado de discussões inúteis sobre se uma linguagem é Turing Complete ou não. Deixa eu aproveitar pra esclarecer isso.

Máquinas de Turing podem ser funções parciais, ou seja funções pras quais não tem saídas bem definidas. Elas podem receber qualquer número inteiro e dar de saída qualquer número inteiro. No paper dele tem uma definição bem mais formal do que isso, mas só imagine uma máquina de Turing como uma função numa linguagem moderna, que recebe números e devolve números. E o conjunto de funções que você pode expressar com máquinas de Turing é o que chamamos de funções computáveis.

Existem números computáveis e também números não-computáveis. Se for possível calcular um número com precisão arbitrária, esse número é computável. No universo de todos os números possíveis, de inteiros a complexos a pi e tudo mais, nem todos são computáveis, mas na prática é difícil de cabeça chegar num número não computável. A maioria que mexemos no dia a dia são computáveis. Mas isso é só pra relembrar que computadores não necessariamente conseguem lidar com 100% dos números possíveis na matemática. No máximo aproximamos.

Pra um programador que não é cientista da computação e não vai lidar no dia a dia com construção de CPUs ou linguagens de computador, talvez as definições formais não sejam tão interessantes, por isso não estou detalhando demais. Mas é mais pra entender que existe uma definição matemática que delimita o que são números computáveis e funções computáveis, ou seja, existe uma definição não só do que dá pra fazer, mas também do que não é computável. Se quiser se aprofundar, o conceito mais importante sobre isso é o que Turing chamou de sequências computáveis. Fica de lição de casa pra vocês pesquisar o que é isso.

Mas voltando pra definição, uma linguagem Turing complete é uma que pode simular uma máquina de Turing, como no site de visualização. Só isso. Ou seja, se você pode simular uma máquina de Turing, então pode computar qualquer função que uma máquina de Turing consegue computar, mas o que a torna “completa” é que ela pode computar todo o conjunto de funções computáveis de Turing, e não só algumas. Na prática, todas as linguagens de programação que você consegue imaginar provavelmente podem ser “consideradas” Turing Complete na prática.

Se fôssemos rigorosos ao pé da letra, acho que nem existem linguagens que são Turing Complete.Por definição uma máquina de Turing tem uma memória, a tal fita de papel, que não tem limites pra esquerda ou pra direita, é infinita. Um computador de verdade obviamente tem limites. Você nunca vai ter RAM infinita. Ela pode ser muito grande, ter peta-petabytes, mas isso não tá longe, mas muito longe de infinito. Máquinas ou linguagens que conseguem fazer tudo que uma máquina de Turing consegue mas até um certo limite de memória, chamamos de Linear Bounded Automations ou Automação Linear Limitada, que são máquinas de Turing que impõe um limite pra esquerda e pra direita da fita.

E a pergunta mais óbvia é, se um computador não pode ser 100% uma máquina de Turing, como uma linguagem de programação, que roda num computador com limites, poderia ser Turing Complete? Tem um jeito, que é definir uma linguagem só no papel dizendo que suporta Listas ou Arrays infinitos, mas na prática a implementação que limita o tamanho máximo. Ou seja, tipo dizer que na “intenção” ele tá dentro das regras, mas quando tenta rodar, o hardware que é limitado e não deixa acessar memória infinita e crasheia. É um truquinho sujo usando uma tecnicalidade da definição.

Na formalidade matemática isso faz diferença. Mas pra um engenheiro faz pouca diferença. Então, se você encontrar alguma discussão acirrada se a linguagem X ou Y é ou não é Turing Complete e ninguém tá provando que as tais linguagens conseguem de verdade lidar com memória sem limites, então a discussão é uma grande perda de tempo.

Na prática, toda linguagem de programação que chamamos por aí de Turing Complete tem capacidade de fazer qualquer coisa que outra linguagem Turing Complete consegue fazer. Dado tempo suficiente de execução e memória suficiente, elas são equivalentes. Agora, ser capaz não é a mesma coisa que ser eficiente. Muita gente confunde isso. Por isso é possível e não deveria ser surpresa, fazer um simulador de PC antigo em Javascript, como nesse site chamado PC Junior que vou deixar linkado nas descrições.

Se você ainda não entendeu, um PC é uma máquina universal de Turing, que consegue rodar um simulador de PC, que é uma máquina de Turing, feita numa linguagem Turing Complete como Javascript, pra simular outras máquina de Turing, no caso um PC virtual pra jogar Doom. Como os PCs de hoje são exponencialmente mais poderosos que PCs dos anos 90, até usando uma linguagem como Javascript conseguimos simular o PC velho inteiro a ponto de rodar Windows 95, Windows 3.1, jogos como Commander Keen ou Doom, e esses programas não sabem que estão rodando num ambiente simulado.

De qualquer forma, pra uma linguagem ser Turing Complete na prática, não precisa de muita coisa. Não são sintaxes exóticas, bibliotecas complicadas nem nada disso. Numa linguagem imperativa basta ter alguma forma de repetição condicional como um “while” ou um “if com go to” e uma forma de ler e escrever pra algum lugar, tipo registradores ou variáveis. E numa linguagem funcional, baseada em lambda calculus, basta conseguir abstrair funções de argumentos e aplicar funções em argumentos. Tecnicamente, se você consegue fazer recursão, tá com meio caminho andado.

Existe um conceito chamado Turing tarpit ou poço de piche, no sentido de você se sujar e afundar, de linguagens que foram desenhadas especificamente pra terem só o mínimo do mínimo pra ser Turing Complete. Ser legível e fácil de usar não é parte do requerimento. E nessa categoria se encontram linguagens como Brainfuck, que é uma linguagem Turing Complete, e teoricamente consegue fazer tudo. Só vai ser terrivelmente traumático tentar. Se você nunca viu, eis um exemplo de um programa que calcula números de fibonacci em Brainfuck. Sim, acreditem ou não, isso é uma linguagem de verdade, e é Turing Complete. Divirtam-se.

Por isso eu repito, sim, qualquer linguagem Turing Complete consegue fazer tudo que outra Turing Complete faz, mas não quer dizer que vai ser eficiente. Uma que confunde muita gente são Expressões Regulares que toda linguagem decente suporta hoje em dia. E não, Expressões Regulares não são Turing Complete. Primeiro que ele só se move numa direção. Quando adicionaram backreferences não lembro se passava a ser Turing Complete, mas pra todos os propósitos pode considerar que não é. Como o próprio nome diz, ela faz parte da categoria de Linguagens Regulares, que são linguagens que podem ser definidas puramente com Expressões Regulares. Você vai entender isso se estudar autômato finito determinístico. Se estudar compiladores vai ver isso e chegar em coisas como a hierarquia de Chomsky. Fica de lição de casa também.

Outros exemplos que você já deve ter ouvido falar e é verdade, SQL não é Turing Complete e HTML ou XML não são Turing Complete. Na prática sim, podem ser consideradas linguagens de programação, mas não são completas, ou seja, não conseguem fazer o que outras linguagens conseguem. Pra um engenheiro isso não importa muito, o que importa é a eficiência pra certos casos de uso. Por exemplo, o horroroso Brainfuck é Turing Complete, mas é inútil pra ser usado de verdade a menos que você seja sadomasoquista. Já HTML, mesmo não sendo Turing Complete, é beeem mais útil na prática. Então é uma discussão mais acadêmica que não tem tanta utilidade a menos que, de novo, você seja alguém trabalhando na pesquisa e desenvolvimento de novas linguagens por exemplo.

Finalmente, se for pra ser rigorosamente formal, nenhum computador nem linguagem é Turing Complete de verdade porque não temos memória infinita. Turing Complete é o ideal inatingível, o topo da cadeia alimentar da ciência da computação. Nada que foi construído até hoje supera o que é possível fazer com uma máquina de Turing teórico, a gente só se aproxima. Mesmo se pensarmos em um computador quântico, ele também não consegue fazer nada a mais que uma máquina de Turing já não faça. Vai ser absurdamente eficiente, mas só isso: eficiente. É importante esse conceito pra entender que o paradigma geral de computação que conhecemos hoje foi delimitado por Alan Turing e ninguém conseguiu pensar em outro modelo que supera o dele. Não é impossível, só ninguém conseguiu ainda.

Agora, voltando sobre a diferença entre grandes máquinas de calcular e um computador moderno, ou seja, uma máquina universal de Turing, agora você já sabe que muita gente chama as máquinas de Babbage, o de Zuze, o Eniac, o Colossus como “computadores”. Mas na real são máquinas de calcular glorificadas. Não são máquinas de Turing e portanto não tem parentesco com nossos computadores modernos. Se eu usar a analogia de parentesco, o computador de Babbage tem tanto parentesco com nossos PCs ou Smartphones quanto um macaco tem parentesco com seres humanos. O DNA bate uma porcentagem alta, mas nós e os macacos somos espécies completamente diferentes. Nós não descendemos dos macacos.

Apesar do Turing ter desenvolvido toda a matemática que dá origem à ciência da computação; a máquina de Turing é teórica, um modelo. Quem de verdade trabalhou no desenvolvimento do primeiro hardware que pode ser considerado de fato o primeiro computador moderno completo de verdade foi John Von Neumann no projeto do EDVAC, cujo paper pode ser considerado as bases do computador moderno. Por isso chamamos a arquitetura de hardware de todo computador como arquitetura Von Neumann. E segundo ele, o que o Turing desenvolveu é impressionante, mas ele não chegou a descrever como de fato construir uma máquina de Turing de verdade. Aí o Von Neumann preencheu as lacunas que faltavam do ponto de vista da engenharia do hardware.

Eu falei bastante de Turing e todo mundo hoje em dia já ouviu falar dele, especialmente depois do filme e por outros motivos que não tem nada a ver com ciências da computação. Mas eu acho que a maioria dos programadores não ouve falar em Von Neumann como deveria e eu vou corrigir isso hoje. E essa descrição vai ser lotada de superlativos, pode se preparar. Eu gostei de um artigo que saiu no blog Cantors Paradise em 2019 escrito por Jørgen Veisdal e vou pegar emprestado alguns trechos, mas recomendo ler o artigo completo que vou deixar nas descrições abaixo.

O artigo abre com uma frase sem autoria que diz “A maioria dos matemáticos prova o que eles podem, Von Neumann prova o que ele quiser”. Pois é, eu falei que ia ter superlativos. E o artigo continua descrevendo como “o último representante dos grandes matemáticos”. Qualquer um poderia descrevê-lo como a pessoa mais inteligente que já viveu e não seria um exagero. Digamos que todo prêmio Nobel de ciências do século XX iria reconhecer Von Neumann não como um par, mas muitas vezes como um superior. E não seria exagero dizer que se a física teórica teve Albert Einstein, a matemática e computação não ficaram nem um pouco longe, porque tiveram Von Neumann.

Ele nasceu no começo do século XX em Budapeste, na Hungria e desde criança já era prodígio. Histórias circulam que quando ele tinha seis anos já conseguia fazer cálculos tipo dividir números de 8 dígitos de cabeça e conversar em grego antigo. Isso não pareceu grande coisa? Ele já era proficiente em cálculo aos 8 anos e leu a teoria das funções de Emile Borel aos 12. E segundo relatos de muitos que o conheceram ao longo dos anos, todos dizem que ele tinha memória eidética. Lembram do Sheldon de The Big Bang Theory? Pois é, só que aqui era real. Ele era capaz de repetir tudo que havia lido, mesmo anos depois.

Num dos relatos no livro The Computer from Pascal to Von Neumann de Herman Goldstein, ele diz o seguinte: “uma de suas habilidades impressionantes era seu poder de lembrança absoluta. Dentro do que eu posso dizer, Von Neumann era capaz de ler um livro ou um artigo e citar de volta palavra por palavra; e ele podia fazer isso anos depois sem hesitar. Ele também conseguia traduzir sem diminuir a velocidade da sua língua original pra inglês. Numa ocasião eu testei sua habilidade e pedi que ele me dissesse como o conto clássico A Tale of Two Cities começava. E assim ele começou a recitar o primeiro capítulo inteiro, sem pausas, e continuou citando até que eu pedi que ele parasse depois de uns dez ou quinze minutos”.

Puta que o pariu. Esse é o tipo de coisa que é quase super poder de herói da Marvel. O cara era tipo um Reed Richards com Tony Stark. Mas isso é só a ponta do iceberg. Quando von Neumann entrou pra faculdade em 1921 ele já tinha escrito um paper com seu tutor sobre uma generalização do teorema de Fejér. Aos 18 anos ele já era reconhecido como um matemático propriamente dito. Colaborou em papers sobre teoria dos conjuntos em Berlin e teve aulas de física, incluindo estatística mecânica com Albert Einstein. Ah sim, ele tava na dúvida de que faculdade fazer, então eventualmente se formou tanto em engenharia química quanto Ph.D em matemática. Aos 24 anos. Sim, ele fez duas faculdades ao mesmo tempo e se formou nas duas summa cum laude, ou seja, com a maior das honras.

Um dos professores de matemática relatou o seguinte: “Durante um seminário pra estudantes avançados em Zürich que eu tava ensinando, eu cheguei num certo teorema, e eu disse que ele ainda não estava provado e que poderia ser difícil. Von Neumann não disse nada por cinco minutos, daí levantou a mão. Quando eu chamei ele pra ir pra lousa, ele foi e escreveu a prova. Depois disso eu tive medo de Von Neumann.” Ah sim, e esse professor era George Pólya, por si só um dos maiores matemáticos da Hungria.

Depois disso ele continuou trabalhando em pesquisa com o maior matemático do mundo na época, David Hilbert. E durante esse período ele escreveu um monte de papers sobre teoria dos conjuntos e lógica enquanto ainda estava na faixa dos 20 anos. E em resumo, sua maior contribuição à teoria dos conjuntos é o que seria chamado de teoria de Von Neumann-Bernays-Gödel. E não, eu não sei o que isso significa. Fica de lição de casa pra vocês.

Mais ou menos na mesma época que estava contribuindo pra teoria dos conjuntos, ele também provou um teorema conhecido como minimax pra jogos de soma zero. E isso criaria a fundação pro novo campo de estudos que viria a ser chamado de teoria dos jogos. Lembra aquele filme do Russell Crowe, Mente Brilhante? Por causa do filme todo mundo acha que foi John Nash que deu origem à teoria dos jogos, e apesar de ter sido importante depois, quem criou a fundação toda foi Von Neumann. Em colaboração com o economista Oskar Morgenstern, Von Neumann depois publicaria o livro definitivo em jogos cooperativos de soma zero, intitulado Teoria dos Jogos e Comportamento Econômico em 1944.

Mas voltando pra 1929, ou seja, quando tava com 26 anos ele já tinha publicado 32 papers de pesquisa, quase um paper por mês. E até aqui ele já influenciou os campos de teoria dos conjuntos e ajudou a fundar teoria dos jogos. O que mais? Nessa época um tema que tava só começando gerava discussões ferrenhas entre físicos, a tal da física quântica. Numa dessas disputas estava nomes que você já ouviu falar, Heisenberg e Schrödinger. E não, não é esse Heisenberg e sim este outro. Schrodinger era meio hater do Heisenberg, dizendo que as formulações dele tava tudo errado.

Iniciando com um incidente entre esses dois, nos anos seguintes o von Neumann publicou vários papers que estabeleceram um framework matemático rigoroso pra mecânica quântica, hoje conhecido como axiomas de Dirac-Von Neumann, isso sem contar que ele explicou como entender mecânica quântica do ponto de vista estatístico. Ele teve um insight que nem Heisenberg, nem Niels Bohr, ou Schrodinger tiveram, baseado no campo de estudos de seu mentor David Hilbert, os espaços vetoriais de Hilbert que eu menciono no meu video sobre Supremacia Quântica. Mas só resumindo que enquanto gênios como Schrodinger tavam batendo cabeça entre eles, Von Neumann foi e encerrou a discussão.

Só que daí Hitler subiu ao poder na Alemanha, a guerra tava pra começar e Von Neumann foi pros Estados Unidos, recrutado pra Universidade Princeton como professor visitante. Logo no começo ele se virou pra teoria ergódica. E sim, eu também não tenho a mínima idéia do que diabos é isso. Mas segundo o artigo, teoria ergódica é uma área da matemática que estuda as propriedades estatísticas de sistemas dinâmicos determinísticos. Enfim, basta dizer que pra surpresa de ninguém a essa altura, Von Neumann fez contribuições essenciais incluindo o teorema ergódico médio de Von Neumann, considerado a primeira base matemática rigorosa pra estatística da mecânica de líquidos e gases. O matemático Paul Halmos disse sobre isso: “se von Neumann nunca tivesse feito mais nada, só isso já teria sido suficiente pra garantir imortalidade na matemática”.

Com a Segunda Guerra iminente, os nazistas perseguindo judeus, era questão de tempo pra chegarem na Universidade de Göttingen na Alemanha, que era então a referência do mundo em matemática e física. Mas por causa da perseguição, diversos nomes famosos ou foram expulsos ou fugiram e muitos foram pro recém formado Instituto pra Estudos Avançados nos Estados Unidos. Além de Von Neumann e Wigner veio Einstein que era judeu, claro. Daí outros como Max Born, Leó Szilárd, Edward Teller, Edmund Landau, James Franck, Richard Courant e vários outros foram também.

Enquanto estava no Instituto de Estudos Avançados, Von Neumann, só pra variar, fundou o campo de geometria contínua. Assim como no caso da teoria ergódica, ele publicou dois papers, um provando sua existência e discutindo suas propriedades, e outra dando exemplos. Fundar campos novos virou rotina pro Von Neumann. Fico imaginando ele acordando e pensando “hmm, que novos campos de estudo que não existem eu quero revolucionar hoje?” E pra provar isso, lá pro meio dos anos 30 ele desenvolveu expertise também na ciência de explosões, fenômeno que é bem difícil de modelar matematicamente. Veja uma explosão em CG em filmes dos últimos 20 anos e você vai ver que só hoje conseguimos simular explosões de forma mais realista.

De qualquer forma Von Neumann acabou se tornando uma autoridade também na matemática de cargas moldadas, cargas explosivas pra focar o efeito da energia na explosão. E sua maior contribuição pra bomba atômica foi no conceito e design das lentes explosivas que era necessárias pra comprimir o núcleo de plutônio da arma Fat Man, que foi a usada em Nagasaki. Ah sim, ele participou do projeto Manhattan e era conhecido de Richard Feynman e Robert Oppenheimer.

No currículo de Von Neumann até agora temos contribuições na matemática, incluindo teoria dos conjuntos, teoria dos números e espaços de Hilbert; na física, em especial em mecânica quântica; na economia com a teoria dos jogos; na biologia com autômatos celulares e depois em computadores e inteligência artificial. E aqui voltamos no nosso tópico central.

Seu trabalho com computadores começou em Princeton no meio dos anos 30 depois de se encontrar com um jovem Alan Turing de 24 anos, quando ele passou um ano no Instituto de Estudos Avançados entre 1936 e 37. Turing começou sua carreira trabalhando no mesmo campo que Von Neumann, em teoria dos conjuntos, lógica e o problema de decisão de Hilbert, o tal de “Entscheidungsproblem” e por isso seu paper seminal de 1936 se chama “On Computable Numbers, with an Application to the Entscheidungsproblem”.

Quando terminou seu ph.D em 1938, Turing já tinha estendido o trabalho de Von Neumann e Gödel e introduziu lógica original e a noção de computação relativa, aumentando suas máquinas de Turing anteriores por máquinas Oráculo, permitindo o estudo de problemas que vão além das capacidades da máquina de Turing original. Von Neumann chegou a convidar Turing pra uma posição de pós-doutorado como assistente de pesquisa depois do ph.D mas Turing rejeitou e em vez disso viajou de volta pra Inglaterra, pra participar do filme do Cumberbatch quebrando o código dos nazistas e ajudando a vencer a guerra.

Apesar do Turing ter ido embora, Von Neumann continuou pensando sobre computadores durante o fim dos anos 30 e durante a guerra. Depois da sua experiência no projeto Manhattan ele foi atraído pelo projeto do ENIAC da universidade da Pensilvânia durante o verão de 1944. E ele tinha boa noção da quantidade massiva de cálculos necessários pra prever o raio de uma explosão nuclear, ou o planejamento do caminho da bomba e também sobre como quebrar esquemas de criptografia. São centenas de cálculos complexos diferente e lembrem que o ENIAC era uma calculadora eletrônica gloficada e horrorosa, que só conseguia fazer uma tarefa de cada vez e toda vez pra reprogramar precisava reconfigurar dezenas e dezenas de cabos.

Pro Von Neumann tava claro que isso não ia rolar e em 1945, pro projeto da construção do computador EDVAC, ele propôs a descrição pra uma arquitetura de computadores hoje conhecido como arquitetura Von Neumann, que inclui o básico de um moderno computador eletrônico digital, que inclui: uma unidade de processamento que contém uma unidade de lógica aritmética e registradores de processo. Uma unidade de controle que contenha um registrador de instrução e um contador de programa. Uma unidade de memória que possa armazenar dados e instruções. Armazenamento externo e mecanismos de entrada e saída. Ou seja, ele especificou o que hoje chamamos de CPU, RAM e tudo mais. É a descrição de um computador moderno.

Como eu disse antes, o grande insight que separa o computador moderno das grandes calculadores, que tanto Turing quanto Von Neumann pensaram mas que não era nem um pouco óbvio na época, era o conceito de instruções de programa e dados conviverem no mesmo espaço de memória e armazenamento, em vez de serem duas coisas separadas como na máquina de Babbage. E não contente em ter feito só isso, claro que Von Neumann foi além.

Se você estudou algoritmos e estruturas de dados na faculdade e viu algoritmos de ordenação, com certeza esbarrou no Merge Sort, que divide arrays pela metade antes de ordená-los recursivamente, pra no final fazer o merge do resultado. Foi inventado por Von Neumann, claro. E ele mesmo escreveu o algoritmo pro computador EDVAC. De bônus, já que parece que ele tinha tempo sobrando, ele introduziu computação estocástica, embora a idéia era tão inovadora pra época que não seria implementada por mais uma década. E por fim, ele criou o campo de autômatos celulares, que precedeu a descoberta da estrutura do DNA por muitos anos.

E esse provavelmente vai ser o maior, melhor e mais influente currículo de um acadêmico e engenheiro que você jamais vai ver. E só pra jogar mais lenha na fogueira. Você poderia imaginar que um matemático do calibre de Von Neumann, que tá ali pau a pau no grupo de nomes como Einstein ou Schroedinger ou Hilbert, deve ser um daqueles matemáticos introspectivos, quietos, tímidos, isolados e anti-sociais bem no estilo Turing do Cumberbatch, né?

Não, pelo contrário, segundo relatos de conhecidos: “Festas e vida noturna tinham um apelo especial pra Von Neumann. Enquanto ensinava na Alemanha, ele foi assíduo da era de cabarés do circuito noturno de Berlin. E as festas na casa de Von Neumann eram frequentes, e famosas, e longas.” Ele era aquele tipo mais bonachão, que fazia piadinhas infames. E durante o período no Instituto de Estudos Avançados ele recebia reclamações porque ligava seu gramofone super alto tocando marchas alemãs no escritório, distraindo os escritórios vizinhos, incluindo Albert Einstein, que ficava putaço.

Von Neumann morreu de câncer em 1957, aos 53 anos. Ou seja, tudo isso que eu contei, foi antes dos 50 anos. Se você é do tipo que gosta de ter alguém em quem se espelhar, um ideal inatingível, esquece porcaria de CEO de startup ou influencier mamão com açúcar. Isso é a definição de padrões muito baixos. Se é pra sonhar, então sonha alto e coloca um Von Neumann como objetivo de vida pra ser fã. Quando estiver em dúvida, pense, o que Von Neumann faria? Hmm, ok, vamos pegar um problema que todo mundo acha impossível resolver, e resolver.

E por hoje é isso aí! Eu disse que essa história ia ser comprida, mas eu acho que a grande maioria dos programadores simplesmente desconhece John Von Neumann. Todo mundo já ouviu falar de Alan Turing mas só o que tem no filme. E muito programador iniciante adora falar sobre Turing Complete e se eu perguntar o que é uma máquina de Turing só sobra silêncio.

Turing e Von Neumann definiram o que é o computador moderno que usamos até hoje, tanto do ponto de vista do rigor matemático até a arquitetura do hardware propriamente dito. E por isso eu considero essa dobradinha como os verdadeiros pais da computação. E eu sei, muita gente vai perguntar, mas cadê o doutor Alonzo Church e Lambda Calculus? Relaxa que tá nos planos falar disso uma hora. Pra não perder quando sair, assine o canal e clique no sininho pra ser notificado. Se curtiu o video deixa um joinha e compartilhe o video com seus amigos. A gente se vê, até mais!

[Akitando] #74 - Emacs vs Java | Oracle vs Google

Wed, 18 Mar 2020 10:30:00 -0300

DESCRIPTION

Esta é uma história de coincidências e erros que moldaram o mundo de programação como você conhece hoje e que possivelmente mudem completamente esse mesmo mundo.

Richard Stallman e James Gosling são dois gigantes da computação e as ações que eles tomaram colocaram em movimento uma série de eventos que culmina com o processo da Oracle contra o Google. Quem está certo?

Links:

Richard Stallman - ILC 2002 (https://www.youtube.com/watch?v=4Jjhmc3Txv0)
My Lisp Experiences and the Development of GNU Emacs (https://www.gnu.org/gnu/rms-lisp.en.html)
Free Software: Freedom and Cooperation (https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt)
James Gosling on Richard Stallman (https://news.ycombinator.com/item?id=21251109)
James Gosling on how Richard Stallman stole his Emacs source code and edited the copyright notices (https://www.reddit.com/r/programming/comments/dhrcxw/james_gosling_on_how_richard_stallman_stole_his/)
Open Source History: Why Didn’t BSD Beat Out GNU and Linux? (https://www.channelfutures.com/open-source/open-source-history-why-didnt-bsd-beat-out-gnu-and-linux)
Sun is using the GPL as a weapon…but against whom and for what purpose? (https://dzone.com/articles/sun-using-gpl-a-weaponbut-agai)
Emacs violates GPL since 2009 (https://news.ycombinator.com/item?id=2820986)
CAN JAVA STILL BE FREE AFTER JANUARY 2019? (https://www.snowsoftware.com/int/blog/2019/03/07/can-java-still-be-free-after-january-2019)
Free but Shackled - The Java Trap (https://www.gnu.org/philosophy/java-trap.en.html)
The Oracle-Google Case Will Decide the Future of Software (https://www.wired.com/2016/05/oracle-google-case-will-decide-future-software/)

SCRIPT

Olá pessoal, Fabio Akita

No último video eu tentei quebrar algumas ingenuidades que as pessoas costumam ter sobre software livre. Tem uma história em particular que eu queria contar mas que não cabia no vídeo então resolvi fazer um separado. E tem a ver com dois assuntos que nem todo mundo associa. Sobre a origem do GPL e sobre um dos motivos de porque Java demorou tanto pra ser aberto como GPL e algumas ramificações disso.

A idéia deste episódio é também ensinar sobre outro ponto importante: não existem empresas perfeitas e não existem pessoas perfeitas. Por alguma razão as pessoas gostam de escolher celebridades que são excelentes em uma coisa e daí os fãs esperam que tudo que essa pessoa faça seja perfeito também. E ficam chateadas quando descobrem que na realidade essa pessoas não eram perfeita, era só pessoas. Você sabe que ainda é um adolescente se quando isso acontece sua reação é falar “Nossa, eu esperava mais dessa pessoa”.

Eu não me frustro com essas coisas porque eu não coloco nada nem ninguém num pedestal. Eu admiro o resultado de seus trabalhos e só. Meu mundo seria chato demais se eu ficasse perdendo tempo julgando coisas irrelevantes. Exemplo disso, a despeito do que muita gente pode imaginar, eu gosto de Java, ou melhor, eu respeito as milhões de horas homem colocada no Java. E por consequência eu respeito o trabalho de seus criadores como James Gosling ou Bill Joy. Eu gosto de Linux, sempre vou respeitar o trabalho hercúleo que o Linus Torvalds precisou executar pra conseguir isso. E eu também gosto de usar todo o ferramental GNU e tiro o chapéu pro Richard Stallman. Eu não pretendo cagar regra na cabeça de nenhum deles, porque eu não consigo me ver realizando nem metade do que esses nomes e vários outros conseguiram entregar. Por outro lado, é só até esse o limite que eles me interessam: o software.

Se o Stallman ou o Torvalds são socialistas ou capitalistas, se são democratas ou republicanos, o que eles dizem ou deixaram de dizer, nada disso muda a qualidade do software. Se realmente me interessasse cagar regra nisso, cadê eu desenvolvendo um projeto melhor que o deles? Seria muito hipócrita da minha parte achar que sou melhor que eles e ao mesmo tempo continuar usando o que eles criaram. Eu sou pragmático, não sou evangelista de software livre e nem de Microsoft e por isso vou seguir rodando Windows com Linux em cima dele. E pra demonstrar porque é perda de tempo achar que o mundo é maniqueísta e separado entre o Bem e o Mal, deixa eu contar uma história …

(…)

Se você não conhece Richard Stallman nem sua reputação controversa, basta dizer que ele é o criador do conceito de software livre, da licença GPL e diversos softwares importantes que estão em toda distro Linux como o compilador GCC ou o editor de textos Emacs. E eu diria que é só isso que você precisa saber. Mas se você tem interesse em assuntos de software livre deveria pelo menos ler todos os textos no site gnu.org. Foi o que eu fiz quando era estudante na faculdade.

Em 2002 o Stallman fez uma palestra na International Lisp Conference. Você que é fã de programação funcional, deveria saber que dezenas de programadores já programavam em linguagens funcionais como Lisp décadas antes de você descobrir o termo que, obviamente, não nasceu agora. Nessa palestra ele começa contando seu primeiro contato com Lisp nos anos 70, quando ele tinha acabado de entrar em Harvard e escreveu seu primeiro interpretador Lisp pra um PDP-11, uma máquina pequena que tinha uns 8 kilobytes de memória. E ele escreveu esse interpretador só com umas mil instruções. Lisp é um software fascinante que se você ainda não conhece, deveria.

Anos depois ele se aventurou a escrever um Lisp de verdade quando começou a trabalhar no MIT, no laboratório de Inteligência Artificial. Parece termos que você associa como modernos né? Lisp, programação funcional, inteligência artificial. Estamos falando do meio dos anos 70. De novo, você não está descobrindo nada de novo, é tudo derivado de mais de 4 décadas atrás.

De qualquer forma ele resolveu escrever um editor de textos chamado Emacs. Mas esse não é o Emacs que conhecemos hoje, era um editor escrito em linguagem de máquina, assembler de PDP-10. Pra quem não sabe, o Emacs é um editor de textos famoso porque ele contém uma linguagem de programação embutida, o Emacs Lisp ou elisp que é um dialeto de Lisp usado pra escrever código que manipula o editor. Toda vez que você instala uma extensão num Sublime Text, Atom ou VS Code, a idéia original vem do Emacs e muitos vão argumentar que Emacs ainda é superior nisso.

Porém, essa primeira versão ainda não tinha um interpretador Lisp. A idéia na verdade veio de outro editor que eles usavam, o TECO que significa Text Editor and Corrector, que tinha uma linguagem super feia porque ele não foi originalmente pensado pra ser programável. Era um editor que acabou ganhando funcionalidades de ser extensível via script.

De qualquer maneira, várias versões diferentes começaram a ser feitas. O próprio Stallman começou a desenvolver uma versão de Emacs em cima desse Teco. Outros desenvolvedores como Dan Weinreb e Bernie Greenberg tiveram a idéia de escrever Emacs usando o MacLisp do Multics. A idéia era tentar desenvolver um editor que fosse super flexível, com suas estruturas de dados internas como o buffer de edição, acessível a um Lisp e dessa forma fazer um meta-editor, ou seja, você podia editar o próprio editor.

Na sequência, o primeiro Emacs escrito em C que rodava em Unix veio de ninguém menos que James Gosling, que muitos hoje ainda devem reconhecer como um dos criadores do Java. Foi quando o Gosling também estava na faculdade. E essa versão foi conhecida como GosMacs. A palestra do Stallman é focada mais na história de como a pequena comunidade Lisp dos anos 70 foi desmantelada por uma briga comercial entre duas empresas que se derivaram do laboratório de inteligência artificial do MIT, a Lisp Machines Inc e a Symbolics.

O final dessa briga feia motivou Stallman a criar um sistema operacional livre que ele acreditava que seria necessário pra recriar uma comunidade livre de Lisp. Porém, diferente das máquinas especializadas de Lisp, que tinham instruções em nível de máquina que tornavam Lisp robusto e rápido, máquinas mais gerais não iam conseguir rodar Lisp de forma eficiente. Então, embora a intenção original fosse fazer um sistema operacional em Lisp, ele optou em fazer o sistema GNU em C e sobre esse sistema ele poderia rodar Lisp como um programa.

E assim, nos anos 80, começa o desenvolvimento do sistema GNU que você usa até hoje. Se você não sabia, - e isso todo mundo de software livre vai repetir na sua orelha até você cansar -, o que você roda é um sistema GNU com a kernel do Linux e por isso eles insistem que o sistema todo deveria no mínimo ser chamado de GNU/Linux. Eu sou a favor de nomenclaturas corretas mas esse acabou virando um daqueles casos que o nome popular significa mais do que o original. Quando falamos que estamos rodando “Linux” normalmente a gente quer dizer uma distribuição inteira, que inclui a kernel do Linux, o sistema GNU e vários outros software que compõe um pacote completo “Linux”. Usar Linux basicamente quer dizer um sistema que não é Windows nem Mac.

De qualquer forma, pra escrever o sistema nasce o GNU Emacs. E como o sistema GNU seria em C, ele precisava também de um editor Emacs escrito em C. Ele poderia escrever um do zero mas naquela época já existia o Gosling Emacs. Segundo os relatos do próprio Stallman, um amigo dele disse que tinha contribuído pro GosMacs e ele tinha uma permissão por e-mail do Gosling dizendo que ele podia distribuir a versão dele. Entendam, naquela época não havia ainda os conceitos modernos de software livre e licenças. Os hackers dos anos 70 simplesmente distribuiam o código por fita ou outros meios pra quem pedisse.

O Gosling, sendo um hacker daquela época, estava no mesmo espírito de colaboração e distribuia o código do GosMacs pra quem tivesse interesse em contribuir. Então quando o amigo do Stallman disse que era ok usar o GosMacs o Stallman embarcou. Só como tangente técnica, o GosMacs não era um Emacs como o feito em MacLisp por Greenberg pro Multics. Ele implementou uma linguagem de script muito mais simples chamada de mocklisp que parecia Lisp mas não tinha o conceito mais poderoso de tudo ser dados no interpretador e ser fácil manipular qualquer estrutura de dados do editor.

Pra quem não entende isso, se você for de Javascript por exemplo, seria o equivalente a você abrir o console do navegador e injetar novos códigos Javascript e conseguir inspecionar os dados em memória da página e tudo sem precisar recompilar ou recarregar a página. É o que o Emacs fazia nos anos 70 graças ao MacLisp. E hoje em dia é o que um editor como Atom ou VS Code faz também, é o mesmo conceito. De qualquer forma o mocklisp era muito mais simplório e o Stallman decidiu que não dava pra usar aquilo e ele resolveu substituir o mocklisp por um Lisp de verdade. Segundo Stallman o mocklisp não tinha um tipo de dados de estrutura, não tinha listas, não tinha arrays, não tinha symbols que são objetos com nomes.

Ao mesmo tempo que ele substituiu o mocklisp por um Lisp de verdade, ele precisou ir substituindo várias partes das estruturas internas do editor para que se tornassem objetos de Lisp e assim pudessem ser manipulados por script. Ele queria que a interface entre o Lisp e o editor fossem limpas, o que significava que objetos como buffer de edição, sub-processos, janelas, posição no buffer, tudo precisava ser objetos de Lisp, de forma que as primitivas do editor fossem chamáveis através de funções em Lisp. Esse trampo todo significou que seis meses depois ele praticamente reescreveu o GosMacs no que viria a ser o GNU Emacs.

Agora, a reviravolta aconteceu que depois disso. Aparentemente o Gosling vendeu o GosMacs pra uma empresa chamada UniPress. Pra piorar o tal amigo do Stallman que disse que tinha autorização de distribuição do Gosling perdeu o backup da mensagem. Então o Gosling Emacs se tornou Unipress Emacs que eles passaram a vender. No começo, vendo o GNU Emacs eles se interessaram em distribuir e até contratar o Stallman. Mas depois mudaram de idéia e em vez disso passaram a dizer na rede que ele não estava autorizado a distribuir o Emacs. Eles não disseram que iam processar ninguém nem nada, só que podiam pensar nisso um dia. E segundo o Stallman, isso foi suficiente pra fazer as pessoas pararem de usar o GNU Emacs com medo de serem processadas.

Como o Stallman já tinha reescrito uma boa parte do Gosling Emacs pra colocar Lisp e transformar em GNU Emacs, ele resolveu continuar o trabalho e substituir o que faltava, e assim não ter mais nenhum bit do código fonte do antigo GosMacs e não ser mais um problema contra a Unipress. Segundo ele, foi o trabalho de pouco mais de uma semana pra terminar. Mas por causa desse episódio, diz a lenda que assim nasceu a primeira licença copyleft na forma do Emacs General Public License. A primeira vez que o nome GNU General Public License apareceu foi em junho de 1988. E dali ele veio evoluindo pra ser um pouco menos restrita pra bibliotecas com o advento do LGPL junto com o GPL v2 lá por 1999. Durante esse período nasceu a kernel do Linux que se uniu ao sistema GNU e possibilitou as distros Linux que você usa até hoje.

E o GPL v3 foi o assunto do meu video de Apple e GPL que eu recomendo que vocês assistam. E assim termina a página da história do GPL do site free soft.org que eu falei. mas não seria um video no meu canal se fosse só isso. A história tem uma outra reviravolta.

(video gosling)

Em 15 de março de 2019 o canal Computer History Museum gravou uma entrevista com James Gosling. Eu vou voltar nessa entrevista em outro episódio, mas o trecho que nos interessa hoje foi quando ele foi questionado sobre o episódio do Emacs e num 180 graus de evento ele resolveu acusar o Stallman de ter roubado o GosMacs.

Segundo sua versão da história, o GosMacs como eu disse estava sendo desenvolvido no espírito de software aberto e distribuído quando ele estava na faculdade, em Carnegie Mellon, mas num belo dia ele parou pra pensar “bom, eu posso continuar sendo o Mr. GosMacs ou eu posso me focar e me formar de uma vez da faculdade”. Ele procurou pessoas que quisessem continuar mantendo o GosMacs mas ninguém tinha muito tempo pra assumir o projeto. Diz ele que chegou a oferecer até pro próprio Stallman e nem ele tava muito a fim porque na época ele era total anti coisas Unix. No final ele achou dois caras que estavam a fim de manter o projeto, mas eles iam precisar ganhar algum dinheiro com isso.

Como background, o Gosling explica uma coisa que parece que era comum em muitas universidades americanas, de que se o aluno cria alguma coisa dentro da universidade, essa criação parcialmente pertence à universidade. Então você não pode comercializar e nem mesmo dar de graça o que foi produzido enquanto era aluno. Carnegie Mellon no começo era mais frouxo com isso e o aluno era dono do que criava. Na época Carnegia era uma universidade pequena mas que tinha dois departamentos que se destacavam mundialmente, uma era a de artes e a outra a de computação. Daí aconteceu que um dos alunos de artes pro seu projeto de mestrado criou uma opera rock que acabou se tornando um puta sucesso financeiro e aí parece que a universidade tentou mudar retroativamente as regras de propriedade intelectual, supostamente pra tentar pegar um pedaço desse bolo.

Pra piorar no departamento de computação aconteceu algo similar onde um desenvolvedor chamado Brian Reed criou um software que se tornou muito popular chamado Scribe, um formatador de textos. E de novo, a universidade supostamente tentou algo similar com ele. E por conta desses episódios os alunos e professores tomavam muito cuidado com assuntos de propriedade intelectual. O Gosling conta isso na entrevista pra dizer que sob os conselhos do professor Mike Shamus ele adicionou cabeçalhos de textos de copyright em todos os arquivos do código fonte do GosMacs e ele tomava o cuidado de pedir uma carta de toda pessoa que quisesse uma cópia do GosMacs, basicamente dizendo que aceitavam a licença. Apesar que algumas pessoas daquela época reportam que pediram a tal cópia mas nunca tiveram que mandar nenhuma carta. Seria o equivalente hoje de você apertar o checkbox aceitando Termos e Condições quando instala um software.

Então, quando ele resolveu não ser mais o Mr. GosMacs e os tais dois caras apareceram, o acordo era que o GosMacs precisava ser grátis pra universidade e ao mesmo tempo não ser ridiculamente caro pra todo o resto. Os dois, segundo Gosling, eram tipo empreendedores de garagem e o novo Unipress Emacs parece que ganhou alguma tração e eles conseguiram algum dinheiro pra pagar ir pagando as contas.

Agora, segundo a versão do Gosling, quando o Unipress Emacs estava de boa no seu canto, pagando as contas, o Stallman ficou doidão. Assim mesmo que ele fala na entrevista “freak out” e saiu editando todos os cabeçalhos de copyright do código fonte do antigo GosMacs e liberou como GNU Emacs. Na cabeça do Gosling foi só isso que o Stallman fez com o código. E aí a IBM e a Digital Equipment, a DEC, pegaram essa versão e começaram a distribuir de graça, o que basicamente matou o mercado da Unipress. Daí eles resolveram processar a IBM e a DEC e isso virou um puta caso cabeludo. No final parece que eles ganharam e a IBM e DEC pagaram danos pra Unipress. Só que o GNU Emacs não desapareceu e depois disso a Unipress teve que mudar de modelo de negócio e fazer outra coisa.

(.. final da entrevista)

Como eu não estava lá presente no começo dos anos 80, minha opinião de hoje é que Stallman, Gosling, a Unipress, a IBM e DEC todos foram vítimas do não entendimento das leis de copyright. Sem precisar acusar ninguém de má índole, a resposta mais simples parece ser que foi ingenuidade mesmo. Eram todos basicamente recém formados de faculdade. O próprio Gosling não estava muito aí, ele ouviu falar dessa idéia interessante de Emacs, que já existia na forma de um monte de macros do editor TECO que começou com Guy Steele, o Emacs de Greenberg feito em MacLisp e a própria primeira versão mais simples do Stallman em Assembly de PDP-10 feito uns 7 anos antes do GosMacs. O que o Gosling fez foi a primeira versão em C.

Quando o Stallman começou a desenvolver o sistema GNU no começo dos anos 80 ele de fato pegou o GosMacs e fez todas as modificações que eu falei, como trocar o mocklisp por elisp e assim por diante. Mas durante o período que a Unipress distribuiu a versão do Gosling, o GNU Emacs de fato continua ainda contendo algum código do GosMacs. Contrário do que o Gosling acredita, não foi só uma versão sem os textos de copyright. Portanto sim, faz sentido a IBM e DEC perderem porque a versão do GNU Emacs que eles distribuíram ainda continua código original do GosMacs conforme testemunhas técnicas puderam atestar comparando arquivos dos dois. E faz sentido que o GNU Emacs em si ainda existiu depois porque faltava pouco pra substituir o resto, que foi o que o Stallman fez, e a partir desse ponto já não infringia mais a licença da Unipress. E esse é o GNU Emacs que você muita gente usa até hoje.

Mas o Gosling não estava muito interessado nisso porque no fim dos anos 80 quando esse episódio se desenrolou ele foi recrutado pela Sun Microsystems. Um dos fundadores é ninguém menos que Bill Joy que veio de Berkeley e trabalhou no que hoje você conhece como o Berkeley Software Distribution ou BSD UNIX, na forma de distros como FreeBSD, OpenBSD ou NetBSD que muita gente usa até hoje, sendo o atual MacOS da Apple meio que um derivado do FreeBSD. O SunOS 4 era baseado em BSD e depois o Solaris viria a ser derivado de outro Unix, o System V. E ironicamente Bill Joy também tendo sido o inventor de outro editor de textos, o lendário VI que depois foi reescrito como Vi Improved ou VIM do Brian Moolenar.

De qualquer forma, na Sun eles perseguiram outro projeto o Star7, um tipo de set top box, pense os Roku ou Apple TV ou Chromecast que você tem hoje, mas no fim dos anos 80. Já é uma lenda que desse projeto foi que nasceu a linguagem derivada de Simula, Pascal, Mesa e outros, codenome Oak que se tornaria o Java que todo mundo usa hoje. Mas a parte importante é que no fim dos anos 80 e começo dos anos 90, ninguém sabia muito bem o que fazer com código fonte aberto. O Linux ainda não era o sucesso que é hoje, e era muito experimental e razoavelmente apavorante adotar uma licença nova como a GPL.

E você pode imaginar que não ajudou nem um pouco o Gosling ter raiva do Stallman por causa do incidente da Unipress. E você pode ver que ele ainda guarda rancor porque ele mesmo disse isso agora em 2019. Pro Stallman ele é a vítima por ter trabalhado em cima do código do Gosmacs e pra ele o Gosling traiu todo mundo que colaborou no código do GosMacs quando ele resolveu unilateralmente vender pra Unipress. Ele se sentiu atacado e temendo novos episódios semelhantes no futuro daí que lendariamente ele teve a idéia de criar o conceito de copyleft e inventar a General Public License ou licença GPL.

Por outro lado o Gosling se sente a vítima porque na visão dele o Stallman roubou o código dele e prejudicou o negócio dos seus amigos da Unipress. Tanto ele se sente assim que ele foi contra adotar o GPL pro Java logo no começo. Precisou de mais de 10 anos e muita pressão da comunidade e do mercado pra ele apoiar a iniciativa do OpenJDK. Em vez disso a Sun tinha uma licença semi-proprietária. O código fonte era aberto mas você não podia usar esse código. Porém, a propaganda da Sun sempre foi que eles eram bonzinhos e apesar de segurarem a propriedade de tudo que é derivado do Java, eles nunca iam fazer nenhuma maldade.

Esse problema é grave e foi uma discussão longa do fim dos anos 90 até o começo dos anos 2010. Entenda, no mundo jurídico a palavra verbal não significa muita coisa. Sempre se lembre disso: tenha tudo por escrito em papel, assinado e com testemunha, senão você é o trouxa da história. O Stallman não gostou do posicionamento da Sun. E por conta de episódios como o Bug do Milênio que levou à adoção de linguagens e tecnologias que fossem imunes a esse bug e à Bolha da Internet que também ajudou muito a adoção do Java, agora um monte de empresas estava à mercê da boa vontade da Sun. Eu lembro que acho que foi por volta de 2004 que ele escreveu o famoso artigo Libre mas Algemado, a Armadilha Java, ou Java Trap como ficou conhecido. Eu era programador Java e acompanhava essa novela na época e lembro que fiquei pensando: uma hora isso vai dar merda.

A comunidade de software livre não ficou parada, e desde os anos 90 já existiam engenharia reversa do Java com projetos como o GCJ que é o compilador Java em cima do GCC, o GCC Classpath que é a reimplementação das bibliotecas Java padrão de forma aberta. Mas era uma corrida de gato e rato difícil. O Java ficava cada vez maior, e mesmo você reimplementando uma versão cleam room, a versão da Sun era mais testado e tinha mais investimento então sempre era mais performático. Nenhuma versão aberta era 100% compatível porque a Sun não liberava os testes pra validar. Finalmente nasceu o projeto IcedTea só em 2006, mais de 10 anos depois do Java ter sido inventado, que se tornou o projeto OpenJDK.

Mesmo a introdução do OpenJDK na JavaOne de 2006 não foi exatamente um mar de rosas. Como eu já expliquei não basta abrir usando uma licença de software livre. Por exemplo, de cara eles mudaram pro OpenJDK ser GPK com uma cláusula de exclusão de classpath. Se fosse GPL puro todo projeto Java que linkasse com bibliotecas Java seria contaminado com GPL e precisaria abrir seu código. Por isso existe a cláusula de exclusão que é uma versão mais leve do LGPL que é feito justamente pra bibliotecas. Porém eles não fizeram isso pra tudo, levou um tempo ainda pra coisas como o JavaFX ganhar a cláusula de exclusão, então no dia um você ainda estava arriscando se contaminar com GPL. Não foi uma transição suave. Eventualmente as coisas estabilizaram mas levou um tempo. Eu fico imaginando se já em 2006 existia a informação interna de serem vendidos pra alguém e antes disso eles deixaram esse cavalo de tróia ativo.

“Ah, mas a Sun é boazinha e nunca vai dar ruim.” Essa era a postura até o mundo ficar chocado quando a Oracle comprou a Sun e passou a ser a nova dona do Java. E se alguém acreditou que a Oracle comprou a Sun pra ajudar o Java, pense de novo. Recapitulando a histórica o projeto Android começou lá por 2003. Segundo a Wikipedia, o Google tentou negociar com a Sun comprar licenças pra usar o Java mas a Sun recusou porque segundo o testemunho da Oracle, o objetivo do Google era fazer um fork proprietário e incompatível do Java, coisa que a Sun já sofreu antes como no caso do J++ da Microsoft nos anos 90.

Como naquela época o OpenJDK ainda não era o que é hoje o Google se voltou pra outro projeto open source, o Apache Harmony, que era outra engenharia reversa aberta, ou implementação clean room - que é o que se chama uma reimplementação do zero sem olhar o código fonte original pra garantir que você não vai cair em plágio. Esse desenvolvimento se tornou a virtual machine Dalvik que saiu nos Android. Ao que parece, o Apache Harmony incluía 37 chamadas de API e 11 mil e quinhentas linhas de código que supostamente eram centrais ao Java e esse é estopim do caso contra o Google. A Apache Foundation na época tinha tentado conseguir licença da Sun mas de novo a Sun não concordou por divergências nas licenças.

Quando o Google lançou o Android em novembro de 2007 o CEO da Sun resolveu publicamente congratular o Google pra comunidade achar que o Android continua fazendo parte do ecossistema do Java. Mas aí veio o soco no estômago, quando a Oracle anunciou em abril de 2009 que estava completando a aquisição da Sun por 7.4 bilhões de dólares no que o CEO da Oracle, Larry Ellison chamou a aquisição da linguagem Java “do mais importante ativo de software que ela já adquiriu”.

Menos de um ano depois, em agosto de 2010 a Oracle entra com processo contra o Google por infringir copyright e patentes. Esse caso é complicado e eu não tenho paciência de seguir cada reviravolta, e entenda que este caso continua ativo até hoje. Em 2020 ainda não temos um veredito. E esse é o Java Trap que o Stallman avisou em seu artigo em 2004. Porém a discussão foi mais longe porque estão questionando se você implementar uma API que já existe é infringir copyright. Um exemplo tosco, System.out.println todo mundo sabe que é uma API do Java, essa e outras milhões que fazem parte da JVM e das classes standard que vem no JDK, se você reimplementar a API isso é considerado “fair use” ou isso é infringir propriedade intelectual?

Uma ramificação, Linux é software livre, mas ele também é a implementação de um outro padrão o POSIX que é a API do UNIX original, que não é livre. Já foi passada pra SCO, depois pra Novell e agora está na mão da Micro Focus. Se a Oracle ganhar e criar este precedente, então todo mundo que usa Linux se encontra numa posição ruim? A Micro Focus poderia processar todo mundo que usa Linux sobre o argumento que o Linux infringe copyright do UNIX ao reimplementar as mesmas APIs?

Pro Google a grande vantagem de ter implementado as APIs do Java e não ser o Java e sim uma implementação independente, foi porque ele achou que podia burlar as patentes e copyright da Sun e ao mesmo tempo se aproveitar de todo o ecossistema de código aberto, ferramentas e, principalmente, desenvolvedores de Java que poderiam potencialmente adotar o Dalvik do Android com mínimo esforço, se comparado à Microsoft ou Apple que precisaram convencer os desenvolvedores a adotar C# ou Objective-C. Mas se ele perder esse caso, além de ter que pagar até 80 bilhões de dólares de danos pra Oracle, pode gerar ramificações pra todo o mundo de código aberto.

Lembram que eu falei que definir fair use é complicado no episódio anterior? Este é um caso real e gigante, que alguns consideram o maior do século. E se você é um hater de Trump, deve odiar mais ainda a Oracle já que seu CEO Larry Ellison é um apoiador declarado. Apesar de tudo isso o julgamento não é trivial, por um lado, muitos argumentam e eu concordo que APIs não deviam ser objeto de copyright. Por outro lado, o caso da Oracle é que o Google não só implementou as APIs em cleanroom como eu falei, eles de fato usaram código do Java original. Como eu falei antes, o código fonte era aberto embora você não devesse usar porque a licença da Sun não era aberta. E se eu não entendi errado o projeto Apache Harmony que o Google usou, continha esses códigos também. Então não é um caso binário de certo ou errado. A forma como o suprema corte verbalizar a conclusão do caso pode ter efeitos em toda a indústria.

Na prática nenhum dos dois é totalmente certo nem totalmente errado. O Google escolheu se colocar nessa situação, ele poderia ter feito como a Microsoft, que depois que apanhou no caso do J++ da Sun, levou ao desenvolvimento do .NET e C#. Mas isso daria muito mais trabalho. Copiar a API do Java e até mesmo partes do código e criar um concorrente incompatível é muito mais simples e eles apostaram que iam sair ilesos disso. Foi uma aposta arriscada e eles sabiam disso, além do que eles não previram que a Sun seria obrigada a vender justo pra Oracle. Como eu já disse, você não pode se declarar ignorante da lei e dar de joão sem braço depois, foi uma aposta, eles blefaram e a Oracle pagou pra ver.

É impossível prever o futuro e vendo de trás pra frente sempre as coisas parecem mais simples. Mas veja que interessante, tudo isso está acontecendo porque o Java nunca foi realmente software livre. Durante sua história ele teve reimplementações como GCC Classpath ou Apache Harmony, mas eles nunca foram completos nem competitivos. Demorou até 2006 pra começar a iniciativa OpenJDK, e só por volta de 2008 que o OpenJDK começou de fato a ficar usável. Durante esse período todo mundo só confiou que mesmo o Java não sendo aberto, a Sun seria boazinha e ninguém viu a Oracle chegando um dia, nem o Google.

Se lá no meio dos anos 80, o Gosling não tivesse ficado com raiva do Stallman e tivesse comprado a idéia de software livre, talvez o Java tivesse tido a chance de ser aberto muito mais cedo, talvez desde o começo já que Bill Joy também veio do mundo dos hackers trocando código aberto. O que aconteceu em universidades como MIT, Carnegie Mellon, Berkeley e outras foi a origem dos conceitos de software livre. Mas, por outro lado, se o Stallman não tivesse se sentido prejudicado pelo Gosling e a Unipress, talvez não teríamos o GPL a tempo e software cruciais como Linux não teriam adotado essa licença no começo dos anos 90, estando a mercê de ser fechado num episódio similar ao da Unipress.

Aliás, o almoço grátis já acabou ano passado, em janeiro de 2019. Pra ter atualizações, negócios que vivem de Java precisam adquirir licença da Oracle diretamente ou via parceiros como a Oracle WebLogic ou SAP Netweaver. Ou usar OpenJDK e ficar por conta da comunidade. Ou pagar uma empresa que dá suporte ao OpenJDK como a Azul Systems, dentre outras alternativas. Mas não existe mais aquela idéia de “confie na Sun e use Java”. Essa é uma das razões de porque muitas empresas preferem não usar Java se não for realmente necessário, o que é uma infelicidade porque de fato a plataforma Java até hoje é uma das melhores que já foi criada. Resumo pra hoje em dia, se precisa usar Java, use OpenJDK.

Se você é novo em programação acho que vale a pena entender o quê é o quê nesse mundo que ainda está em constantes mudanças. Uma tecnologia não existe num vácuo. É importante entender a história das coisas que você usa. O mundo não é nem estático e nem preto no branco. Aliás, como última ironia, em 2011 descobriram que o Emacs, sim o software livre original, estava liberando binários sem liberar o código fonte completo por quase 2 anos, entre 2009 e 2011. Claro, parece que foi um erro da automação de releases e o Stallman se desculpou e já consertou isso, mas é pra ilustrar como é fácil cometer erros também. Todo mundo comete erros. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, não deixem de assinar o canal, clicar no sininho pra não perder os próximos episódios e compartilhem o video com seus amigos pra ajudar o canal. A gente se vê, até mais.

[Akitando] #61 - Meus Primeiros 5 Anos | 1990-1995

Thu, 12 Sep 2019 11:03:00 -0300

DESCRIPTION

Hoje quero voltar a contar algumas histórias. Se vocês assistiram os vídeos do começo do canal já devem ter visto alguns trechos de como eu era no começo de carreira.

Mas desta vez quero ir bem pra trás, até o momento zero! Muita gente tem essa dúvida: como começar? Como devo escolher o que aprender? Como eu sei que não estou perdendo tempo? E pra ajudar a responder essas perguntas vou dar como perspectiva como foi pra mim mesmo, dos 13 aos 18 anos, até o 1o ano de faculdade.

Esse período compreende os anos de 1990 a 1995. E eu acho que você pode se surpreender com a minha resposta a essas perguntas.

Vídeos complementares:

Procure o que você Ama … só que não! (https://www.youtube.com/watch?v=A2-yU3YjB1U)
Dúvida! Devo fazer faculdade? (https://www.youtube.com/watch?v=XWVcF7BoCSc)
O Diário de Henry Jones (https://www.youtube.com/watch?v=ii5Q2fCl8C0)
Devo fazer faculdade? (https://www.youtube.com/watch?v=iRjEa7N8wEo)
Sua Linguagem é Especial? - Parte 1 (https://www.youtube.com/watch?v=NwAvovzHRDU)
Sua Linguagem é Especial? - Parte 2 (https://www.youtube.com/watch?v=O4CWVQLbi48)
O que eu devo estudar? (https://www.youtube.com/watch?v=Ll1uAZ-WRa0)
Minha Máquina do Tempo (https://www.youtube.com/watch?v=0KNGiOp7eoE)
A Dimensão do Tempo para Iniciantes em Programação (https://www.youtube.com/watch?v=Qb5b8ZE9tIY)

Links:

Globo Reporter 1991 - A Febre dos Videogames (https://www.youtube.com/watch?v=8GirQPUdlTM)
Encoded, Decoded How Usenet—a protocol intended for conversations—was forever changed once the public figured out you could transfer binary files through it. (https://tedium.co/2017/10/03/usenet-binaries-history/)

SCRIPT

Olá pessoal, Fabio Akita

Muita gente se pergunta como aprender as coisas. Como aprender Linux? Devo escolher Java primeiro ou Python primeiro? Melhor esquecer Web e ficar no Mobile? O que devo aprender primeiro? Eu sempre venho respondendo essas perguntas no canal de diversas formas, mas cada caso é um caso.

Muita gente olha pra mim, hoje, com quase 30 anos na área e por alguma razão tem dificuldade de imaginar como chegar no mesmo nível. Pra quem esta chegando agora no canal eu fui programador minha vida inteira na última década só que passei a fazer outras coisas como palestras, geração de conteúdo e abri minha própria empresa.

Na realidade, a maioria das pessoas superestimam o que eu realmente sei e aí parece ainda mais longe. Mas todo mundo também esquece que qualquer um com X décadas de carreira teve seu dia 1 igualzinho todo mundo, sem saber nada de nada, zero conhecimento, zero experiência, e zero noção de pra onde ir. Isso é o normal, ninguém nasce sabendo o que vai fazer pro resto da vida.

Eu já vim contando algumas histórias, como no Diário de Henry Jones, na Dimensão do Tempo, Sua Linguagem é Especial, e neste episódio quero contar alguns trechos de história dos meus primeiros cinco anos, que encaixa entre esses outros episódios. Vocês vão ver que no geral as histórias não são nada especiais, nenhum episódio sobrehumano tipo entrar no MIT com 15 anos ou algo assim. Esses casos existem mas não sou eu.

Essa história é para os iniciantes ansiosos. Muitos que estão assistindo o canal, ou são jovens que estão pensando em entrar na faculdade ou estão nos primeiros anos, ou então pessoas mais experientes nos seus 30 ou 40 querendo pular pra área. Pra vocês que querem saber como muitos de nós que já passamos pela área começamos. O objetivo não é dar uma receita pra ser copiada, só dar um contexto e perspectiva. Eu realmente acho que não é tão importante ficar encanado demais nos primeiros anos. Iniciantes tem muito pouca informação pra ficar tentando escrever em pedra “é isso que eu vou fazer pelos próximos 5 anos”. Permita-se explicar.

Meus primeiros anos tendo exposição à computação foi do meio pro fim dos anos 80. Eu não tinha computador na época, eu tinha primos e amigos da escola que tinham e eu podia mexer quando ia na casa deles. Na minha cabeça um computador era uma coisa cara e inacessível pra mim, então eu só sonhava com o dia que eu teria meu próprio computador. Pensa que crianças como eu naquela época liam gibi da Turma da Mônica ensinando o que era o Dragão da Hiper Inflação e o Leão dos Impostos destruindo tudo. A gente cresceu entendendo que era normal nosso dinheiro não só não valer muita coisa. Felizmente minha família, que veio do interior tentar a vida na cidade grande, não era pobre, mas eu tinha noção que tinha coisas que eu não devia esperar ter.

Em 88 eu tinha uns 11 anos de idade, meu primeiro contato com alguma coisa que lembra código era no MSX hotbit do meu primo onde a gente minimamente precisava digitar um comando como LOAD pra carregar os games das fitas cassete. Foi assim que eu comecei a ter noção da idéia de que a gente dava comandos pra máquina executar. Eu via os códigos em revistas como a Micro Sistemas mas eu não tinha computador pra digitar. Eu via as propagandas de computadores da época como o MSX, os clones de Macintosh como o Unitron, os CP-400 ou CP-500 da Prológica, eram meus sonhos de consumo. Eu não tive nenhum deles, só pude mexer no dos outros de vez em quando.

Meu primeiro contato com programação de verdade foi em 1990, eu tinha 13 anos. Se eu não me engano alguém de telemarketing ligou em casa oferecendo desconto num curso de computação, e meus pais resolveram do nada me colocar nesse curso. Fomos eu e meu pai na verdade, aprender MBasic e Wordstar na Data Center, que já nem existe mais. Eu ouço as pessoas atrelando o aprendizado com algum objetivo fixo. Eu não entendo isso. Meu único desejo naquela época era programar qualquer coisa num computador, só isso, o único desejo de dar um comando e o computador me responder. Não tinha nenhum objetivo concreto, eu não estava pensando em aprender a programar pra ter uma carreira, ou porque eu queria abrir um negócio, nada disso. Era 1990, pensa que foi o ano que saiu Esqueceram de Mim e De Volta pro Futuro 3 nos cinemas, eu tinha 13 anos e zero noção do mundo.

Não lembro se foi nesse mesmo ano ou no ano seguinte, mas provavelmente entre 1990 e 1991, acho que meus pais se convenceram que eu realmente gostava de programar já que eu não desisti do curso, e modéstia a parte, eu entendia o Basic bem mais rápido que meu pai na época. Eu tinha um tio que era analista de sistemas, se não me engano ele fazia sisteminha pra uma loja de shopping e outros projetinhos pra outras pequenas empresas. Ainda estávamos na reserva de mercado, pra conseguir um bom computador, só indo no Paraguai, e esse tio conhecia alguém que trazia. Que nem hoje em dia que todo mundo conhece alguém que trás hardware de Miami. A gente não tinha Mercado Livre ou Gearbest, o mais próximo disso era a página de classificados nos jornais.

Enfim, meu pai resolveu investir num PC XT, com poderosos 1 MB de RAM, muito acima dos normais 640 kilobytes, um drive de floppy disk de 5 1/4" e outro mais moderno de 3 1/2" que suportava disquetes dupla face!!E poderosos 10MB de HD, que sei lá porque a gente chamava de Winchester naquela época. E junto um monitor CGA de 4 tons de fósforo verde e uma impressora matricial Epson FX 1050. O computador vinha com MS-DOS 3 e eu tinha GW-Basic e meu tio deixou instalado dBase III. Isso deve ter sido bem caro, hoje eu estimo que deve ter custado quase 2000 dólares em dinheiro dos anos 80! Eu tinha noção que era bem caro. E era basicamente isso que eu tinha. E era tudo que eu precisava, a partir daí eu me virei.

Pra ter uma noção de como eu tava feliz eu queria fazer meu próximo trabalho da escola no computador e imprimir na novíssima impressora, claro! Mas eu sequer tinha um editor de textos, e não tinha internet pra baixar. Como que eu fiz? Bom, a única coisa que eu sabia era Basic. Pois bem, abri o interpretador e fui digitando linha a linha do trabalho usando o comando PRINT. Detalhe, que eu não sabia e nem lembro se dava, pra navegar de volta pras linhas de cima. Uma vez que digitou era difícil de corrigir depois. Então da primeira vez eu tive meio que digitar do começo ao fim sem errar, felizmente era um texto curto. E foi assim que imprimi meu primeiro trabalho!

Em pouco tempo eu comecei a juntar mais programas. O DOS 5 eu acho que foi onde apareceu o editor Edit e o Quick Basic. Eu consegui uma cópia do Wordstar, do Lotus 1-2-3. A primeira apostila de dBase III eu acho que peguei emprestado com um primo mais velho que tava estudando. E o que eu fiz na época? Lembram que no episódio de Henry Jones eu contei que antes de ter um computador um hobby que eu tinha era copiar textos da enciclopédia na máquina de escrever? Então, eu copiei digitando, página a página dessa apostila no Wordstar pra imprimir minha própria versão. Detalhe que eu usei pouco porque depois de copiar todas as sei lá, 100 páginas da apostila, eu acabei aprendendo o dBase III.

Os anos meio que não são exatos mas acho que foi alguns meses depois, talvez final de 91? Meu tio perguntou se eu aprendi o tal dBase e me convidou pra ajudar ele nas férias da escola. E foi assim que consegui meu primeiro estágio. Ele passava os dias na tal loja, visitava clientes, e chegava no fim do dia com especificações e explicava o que ele queria, dai eu passava o dia seguinte na casa dele programando. Ele tinha um computador muito melhor que o meu, acho que já era um 386 com monitor VGA e eu obviamente já tava muito feliz só de poder usar um computador mais potente, e colorido! E assim eu comecei a migrar do dBase pro Clipper Summer 87 que tinham linguagem compatível, e logo na sequência pro Clipper 5. Fiz programas de controle de estoque, programa pra gerenciar um escritório de advocacia, programa que gerenciava não lembro o que de avião particular, e coisas assim.

Sendo bem honesto eu não tenho idéia de quanto do meu código era realmente aproveitável, mas eu seguia o exemplo dos outros programas do meu tio e ouvia os feedbacks dele no dia seguinte. Lembrando que eu programava do computador dele direto porque era mais eficiente, não tinha internet pra eu poder trabalhar remoto, não tinha Git, não tinha nada disso ainda. Controle de versão era basicamente um conceito desconhecido. Backup era em disquete. Assim foi uns dois meses das minhas férias de verão quando eu tinha uns 14 anos.

Clipper pra mim era o que provavelmente Javascript, ou Java, ou Visual Basic é pra muitos de vocês: a minha primeira linguagem favorita. Eu achava que dava pra fazer tudo em Clipper. Meu editor favorito na época era o Norton Editor, meu tio me apresentou pro Sidekick que era um programa residente em memória no DOS que tinha um help pros comandos do Clipper, utilitários como calculadora. Era tudo que eu precisava no meu ambiente de desenvolvimento. A partir desse ponto meio que já tava decidido que eu provavelmente ia escolher computação como faculdade. Outro contexto: fazer faculdade nunca foi uma opção, eu sempre encarei como o próximo passo natural depois do colégio, então eu nunca parei pra pensar em não fazer. De qualquer forma, depois desse estágio com meu tio, eu peguei mais alguns projetinhos por conta. Lembro de ter feito um programa de controle de estoque pra uma loja de bebidas do bairro por exemplo, e vocês não imaginam como eu fiquei contente quando consegui fazer um joguinho e meu próprio editor de textos simples, tudo em Clipper.

Pra ser mais honesto, ainda havia uma outra direção que eu ficava flertando. Desde criança tinha outra coisa que eu gostava de fazer e era desenhar. Olhando em retrospecto, claro que eu não era tão bom quanto eu achava que eu era. Mas vamos lá, eu era um pré-adolescente. A gente nunca tem noção de quanto é bom ou ruim em alguma coisa. Mas de qualquer forma eu gostava de desenhar. Eu tinha poucos amigos na época, eu nunca joguei bola na rua ou coisas assim, eu passei minha infância basicamente dentro de casa. Lá pelos 14 anos um menino da rua que estudava na mesma escola que eu acabou fazendo amizade comigo e foi interessante porque ele era o oposto de mim: eu sempre fui o japonês CDF introspecto e quieto e ele era o extrovertido. Vocês tem que entender que famílias japonesas eram bem mais rígidas, particularmente nos anos 80. De qualquer forma, nessa época a gente tava aprendendo computador ao mesmo tempo e ele sendo mais atirado conseguiu um bico pra gente na Fenasoft. Antigamente existiam 2 grandes feiras de tecnologia, a Fenasoft e a Comdex, coisa tamanho da Feira do Automóvel de hoje, que acontecia no Centro de Convenções do Anhembi.

Esse meu amigo era um ano mais novo que eu mas o filho da mãe era ligeiro, e inteligente. Ele puxou conversa num quiosque da Brasoftgames no shopping e eles ficaram impressionados e convidaram ele pra trabalhar na Fenasoft apresentando jogos. Porém teve um problema, a idade limite pra trabalhar era 15 anos e ele sendo um ano mais novo acabou não podendo ir e ele me mandou no lugar dele. Enfim, como eu disse o evento era gigantesco, ocupava o pavilhão do Anhembi inteiro, então imagina o tamanho. A estande da Brasoftgames era um dos maiores, com um super telão com palco e vários quiosques menores. Acho que o ano era 1992 e as novidades eram os novos kits multimidia que adicionavam CD-ROM, com super velocidades de 2x e 4x eu acho, e placas de som, os Adlib e Soundblaster. E jogos como Star Wars Rebel Assault, X-Wing e Tie Fighter.

Eu contei tudo isso pra chegar no seguinte episódio. E aqui eu devo dizer que não lembro de todos os detalhes mas se não me falha a memória aconteceu a seguinte situação. Imagina que a gente ficava nesses quiosquinhos espalhados pelo estande gigante, com um microfoninho que saia nas caixas de som daquela época, apresentando os jogos, e juntava um pessoal ao redor pra ver. De vez em quando nosso chefe subia no palco do telão e falava algumas merdas e fazia piadas sem graça. E aqui vem a parte que eu não lembro se foi assim mesmo que aconteceu mas eu lembro que eu tava ficando irritado com as piadas sem graça e as informações erradas que ele falava. E meio sem perceber, quando isso acontecia, meu quiosque que ficava perto do palco era interrompido porque o som do palco era mais alto. O que eu fiz? Eu comecei a gritar mais alto no meu quiosque. E eu acho que tava funcionando, o povo ficava olhando minha apresentação. Daí o chefe do meu chefe apareceu no meu quiosque uma hora.

Eu não entendi nada, mas acho que ele disse alguma coisa tipo “você, pra lá” e me mandou pro palco. De novo, vocês lembram que eu falei que eu sempre fui o japones CDF introvertido que nunca fala. Ênfase no “nunca”. Eu aquele tipo que na escola fazia trabalho em grupo sozinho sem ajuda dos outros só pra não precisar falar na frente de classe, e deixava alguém só falar no meu lugar. Já era um esforço sobrehumano eu estar naquele quiosquinho me acostumando a apresentar pra meia dúzia de pessoas aleatórias. Eu não sabia falar em público, nunca foi natural, especialmente aos 15 anos. E de repente lá estava eu, num palco, numa feira, na frente de um telão e com uma multidão olhando pra mim, esperando eu apresentar.

Esse foi um daqueles momentos “ou vai ou racha”. A imagem que me veio à cabeça foi que quando eu tinha uns 10 anos ou menos, eu tive que fazer uma pequena apresentação em público, num eventinho da comunidade japonesa do bairro, eu gaguejei, muito, eu desesperei e eu fugi do palco. Foi um trauma e agora, 5 anos depois, eu tive quase certeza que ia acontecer a mesma coisa. E pra minha surpresa eu tomei uma decisão consciente de não fugir. Essa foi a primeira vez que eu consegui falar em público direito e foi a primeira vez que eu me dei conta que talvez fosse possível eu falar em público. Muita gente me conhece hoje como palestrante, vocês não tem idéia de como foi difícil eu aprender isso. Eu nem sei dizer se a apresentação foi boa ou não, mas como não me expulsaram do palco, vou acreditar que foi bom o suficiente.

Porém, meu chefe, o alemão que me irritava quando subia no palco, acho que não gostou do chefe dele ter me colocado no palco porque no ano seguinte ele me barrou de trabalhar de novo. Mas aí aquele meu amigo conseguiu um bico no concorrente no mesmo evento e fomos pra Magnasoft. Com 16 anos eu já tava um pouco mais confiante e acho que foi nesse evento que outro episódio interessante aconteceu. Um dos programas que eu tinha que apresentar não era grandes coisas, era algum tipo de pacote educativo que tinha um programa nível de Paintbrush do Windows, pra desenhar. E eu disse que eu gostava de desenhar. Um dos jogos que eu gostava naquela época pela arte era o Tazmania e eu fiquei lá desenhando. Pensa que desenhar com um mouse de bolinha era muito ruim, mas eu já estava acostumado. E por acaso apareceu um jornalista que gostou daquilo e me convidou pra aparecer em algum jornal local da época. Como eu disse antes, eu não tinha muita idéia se o que eu desenhava era considerado bom ou não, mas isso foi um empurrãozinho.

Eu sempre fui fã de quadrinhos, games, mangás, animes, tokusatsu, era o que eu desenhava. Das revistas de videogames, como a Ação Games e Videogame eu era fã de alguns gamers da época e por acaso conheci um deles nessa Fenasoft, o Toni Ricardo Cavalheiro. Se vocês tem perto da minha idade talvez se lembrem desse Globo Reporter de 1991 ou 1992.

E ele aparecia lá também. Por causa desses eventos nessa época eu finalmente fiquei mais comunicativo e fiz amizade com ele. Cheguei a ir na casa dele com disquetes copiar jogos, e foi como tive acesso a coisas como Doom, The Lost Vikings, Lemmings e mais. E ele me apresentou pra revista Videogame, onde ele trabalhava fazendo reviews dos jogos. Naquela época, pra conseguir programas e jogos você tinha que pegar sua caixa de sapatos com disquetes, pegar um ônibus e ir na casa de alguém que tinha. Vocês não tem idéia de como a vida de vocês é fácil com internet hoje.

Eu pensei em fazer ilustrações pra revista já que apesar de gostar de games eu nunca fui nível de gamer profissional. Levei meu portfolio pra editora, e eu não sei se o editor não curtiu meus desenhos ou se foi sincero, mas ele começou perguntando se eu sabia fazer ilustração em computador, e claro, eu não sabia. Esses desenhos que estão aparecendo aqui do lado são meus lápis de 91 a 92 se não me engano. E ele disse “pois é, hoje em dia as ilustrações são todas digitais e vetoriais, precisa saber usar um CorelDraw”. Naquele mesmo dia eu fui pra uma livraria e comprei um livro de CorelDraw 3.

Passei o próximo mês aprendendo a ilustrar com CorelDraw. Em 1993 eu tinha ganhado meu segundo computador, um 386 de poderosos 66Mhz e acho que já tinha 2 ou 4 MB de RAM com uns 30 MB de HD. E agora eu tinha um monitor VGA. Coloque em perspectiva, era um monitor de 640 x 480 de resolução. O que chamamos de HD hoje em dia é 1920 por 1080, era 4 vezes menos densidade de pixels e tinha só 256 cores. Ah sim, e o mouse mais barato que você acha hoje já é ótico, o meu mouse naquela época era de bolinha, e ele era muito impreciso, enrolava fio de cabelo e sujeira dentro, era uma desgraça. Pensa ilustrar naquela época como era. Mesmo assim, eu treinei o quanto pude. Passava meus fins de semana fazendo ilustrações e depois de algumas semanas eu aprendi a maioria das técnicas e montei um novo portfolio, e fui bater na porta da editora de novo. E pra minha surpresa, acho que eles gostaram porque por alguns meses eu fiz ilustrações pra revista Videogame. Era uma ilustração de matéria por mês, por alguns meses só, não era grande coisa, mas eu já tava bem feliz de ter meus primeiros trabalhos publicados.

Em 94 eu parei tudo. Foquei exclusivamente em terminar o 3o colegial e conseguir passar em alguma faculdade. E eu me coloquei na obrigação de passar em alguma faculdade pública porque eu não queria que meus pais passassem os próximos 4 ou 5 anos tendo que pagar faculdade particular ou eu ter que trabalhar e estudar ao mesmo tempo pra dar conta. Eu saía de casa sei lá, 6 horas da manhã e voltava sei lá, 8 horas da noite, todos os dias e só parei depois do último vestibular do ano. Eu realmente levei isso a sério. Tinha 3 cursos que eu podia fazer naquela época: tecnólogo em processamento de dados na Fatec, um curso que na época era novo de engenharia de software ou engenharia de computação na Unicamp e bacharelado em ciência da computação na USP. No final passei nos 3 e escolhi fazer ciências da computação. Eu não tinha a mínima idéia da diferença dos 3 cursos naquela época.

Vamos pra 1995. Pra dar contexto, eu vi alguns dias atrás que vão lançar o terceiro filme da franquia Bad Boys do Michael Bay com o Will Smith e Martin Lawrence e eu dei risada de como o Martin tá gordo nesse filme. Mas o primeiro saiu em 95, pensa que foi 24 anos atrás. Nesse ano também saiu o 1o Toy Story, que foi uma revolução absurda em ser o primeiro longa metragem inteiro renderizado por computador numa época onde pouquíssimas pessoas tinham computador em casa e normalmente era alguma coisa como um 486 de 100Mhz e onde 4MB de RAM era considerado bastante.

Finalmente, na faculdade, eu podia deixar meus dias de CDF introspecto na escola pra trás e resolvi treinar pra ser mais extrovertido. Na minha época a gente chamava os novatos de bichos, acho que hoje ainda é bicho? Pra dar uma idéia de como eu tava testando meus limites, eu acabei ficando amigo de um grupo que resolveu que no 1o semestre a gente ia concorrer ao centro acadêmico contra a chapa de veteranos e nos auto entitulamos Chapa Bicho. Lembra meus desenhos de Taz na Fenasoft e meus skills de CorelDraw? Pois é, foi assim que eu fiz cartazes como esse aqui do lado. A gente era bem ativo, e não ganhamos por muito pouco. Meu primeiro semestre na USP já começou conturbado, e em paralelo a isso me engracei com a empresa junior e fiz cartazes pra eventos na faculdade como esse outro pra Oracle.

Pense que em 95 o Linux ainda não tinha muito mais que uns 4 anos de vida. Internet era absolutamente opcional ainda. Muita gente ainda nem tinha idéia direito de pra que servia Internet. Não se pode negar que eu tive o privilégio de poder cursar ciências da computação no Instituto de Matemática e Estatística da USP. Universidades como USP ou Unicamp estavam sentadas em cima do backbone da Fapesp, um dos poucos backbones que conectavam as universidades ao resto do mundo. Não era incomum algum problema nesse backbone deixar a gente ilhado e restrito a navegar só no Brasil, por exemplo.

Se formos falar de sistemas operacionais como MS-DOS com a interface gráfica do Windows 3.1 por cima, por exemplo, o stack TCP ainda era opcional. Você precisava instalar o Windows 3.1 for Workgroups ou instalar a stack TCP separadamente. Pra ter uma idéia de quão antigo estou falando, hoje em dia a gente usa redes cabeadas usando cabos 1000base-t ou 10Gbase-t, cabos twisted pair com conector RJ-45 em topologia de estrela. Antigamente eu trabalhava cabeando as salas da USP usando ethernet sobre cabo coaxial com conectores em T em rede que exigia um terminador, que é um resistor no final da rede em daisy chain. Qualquer ponto em T no meio da rede que alguém mexesse podia derrubar toda a rede local. Eu lembro que eu não sabia disso e justo na minha máquina ficava o terminador da rede. Eu não sabia o que era aquilo e desconectei. Dali a pouco desce a diretora do Centro de Computação e Eletrônica da Politécnica, o CCE, xingando “quem foi que derrubou a rede”. Pois é, isso acontecia em 1995, a gente usando tecnologia de 1985.

Enfim, eu mudei de assunto aqui, foi só pra lembrar que eu já fui estagiário um dia também. Falando em ser estagiário, eu preciso deixar registrado um outro conhecimento aleatório que queimou no meu cérebro e eu nunca mais esqueci. Quem aqui sabe o que é uma gaiola de faraday? Eu fazia manutenção dos micros das salas de computação. O CCE onde eu trabalhava era lotado de periféricos e peças. Numa das manutenções eu fui trocar o HD quebrado de um computador por um novo. O que eu fiz? Tirei o HD novo do saco plástico, coloquei em cima do saco e liguei o cabo de força pra testar. Dali a pouco sobe um cheiro de queimado e eu descobri que eu fritei a placa embaixo do HD. Por que? Pelo menos naquela época o saco tinha uma redinha desenhada do lado de fora e eu não sabia pra que servia. Nesse dia eu entendi, era uma gaiola de faraday pra proteger o HD dentro. Assim como seu carro. Do lado de dentro ele é eletricamente isolado, mas do lado de fora é altamente condutor, e eu encostei a placa do HD em cima da redinha do lado de fora e liguei o HD, altamente condutor, fritou tudo na hora … Coisas de estagiário. Pelo menos eu nunca mais esqueci.

Sobre esse estágio no CCE. Antes de entrar na USP, de vez em quando eu ajudava a BBS de um amigo meu, que era o meu vizinho da mesma rua. Lembra do meu amigo extrovertido que conseguiu os bicos na Fenasoft? Caso alguém das antigas se lembre, a BBS dele era a Medusa, o apelido online dele era Jungle. Uma das coisas que ele fazia era distribuir warez, pirataria mesmo, eu ajudava de vez em quando. Não me julguem, eu também já tive minhas épocas de não ter grana e a única forma de experimentar algum programa ou jogo era pirateando. Mesmo porque muita coisa de fora simplesmente nem chegava aqui. Não era incomum a gente usar blue boxes, que se vocês já viram algum documentário sobre Steve Wozniak deve lembrar quando ele conta a história do apito que vinha de brinde na caixa de cereais norte americanos Captain Crunch que conseguia emitir o sinal de 2600 hz que resetava a linha de trunk e com isso a gente conseguia habilitar ligação de longa distância de graça nas linhas telefônicas.

Eventualmente o povo criou software que rodava em placas de som como Soundblaster e com isso a gente conseguia fazer ligação internacional cobrando pulso de ligação local. Era só pegar o telefone, abrir a linha pra operadora, pegar o fone de ouvido ligado na Soundblaster, rodar o programa que rodava o tom e com alguma sorte ele abria a linha e agora a gente podia discar internacional. Era uma técnica de phreaking e embora nós só fôssemos os equivalentes a script kiddies hoje em dia, o povo gostava de se auto entitular phreaks. Acho que chegamos a testar black boxes também.

Enfim, a intenção era conseguir conectar em BBS de outros países como Alemanha. E além disso eles conectavam em servidores UNIX que estavam abertos na rede. Antigamente a senha hasheada ficava armazenada no arquivo passwd que era legível a um usuário guest. E o algoritmo de hash era fraco, e com brute force e rainbow tables a gente eventualmente conseguia quebrar algumas senhas e com isso tínhamos acesso a armazenamento em algum servidor. Daí a gente conseguia transferir programas pra essas contas que dávamos hijack pra fazer download com calma depois.

Lembrando que era hiper lento baixar coisas via modens de 19200 baud ou menos na época, nem estamos falando ainda de modens de 56k da última geração. Aliás, por causa desse tipo de coisa eu acho que separaram os hashes de senha nos arquivos shadow que tem permissões mais restritas. Vocês nunca se perguntaram porque existem os arquivos passwd e shadow num UNIX e Linux? O arquivo shadow já existia desde 86 mas muitos servidores UNIX rodando na época não estavam atualizados, lembrando de novo que atualizar um servidor naquela época não era só rodar um simples ‘apt upgrade’.

Essa época de BBS era quando eu tinha uns 15 a 16 anos. Depois que eu entrei na faculdade ficamos sabendo que era possível eu conseguir ganhar uma conta num servidor UNIX da faculdade com acesso à internet se eu fosse trabalhar como monitor na sala do CCE na Politécnica. Internet banda larga em 95 quando a gente usava modems hiper lentos. Lógico que eu decidi tentar e essa foi a motivação pra eu ir estagiar no CCE e pra eu aprender UNIX: baixar warez de forma mais rápida. Pois é!

De qualquer forma, uma coisa leva à outra. O acesso à internet que eu tinha era logando via telnet do pczinho da sala de computação onde eu era monitor. Era acho que um mísero 386 com monitor VGA de 256 cores, mas isso não importava porque o acesso era via Telnet, ou seja, terminal texto. Uma vez logado você caía num shell, acho que era Korn Shell. Uma das chatices dos computadores da sala era que eles tinham um timeout, não lembro se era de 1 hora. O computador fazia boot remoto. Ele tinha uma placa de rede e um EPROM que no boot ele baixava o DOS e Windows do servidor então não adiantava modificar os arquivos locais porque a cada boot ele zerava tudo e baixava de novo. No DOS era carregado um programa que depois de 1 hora ou algo assim ele forçava acho que um Halt and Catch Fire ou HCF e derrubava o computador inteiro.

A primeira coisa que os estudantes mais dedicados queriam era ficar mais tempo e daí a primeira coisa que os mais espertos aprenderam a fazer foi derrubar esse programa. Como era DOS alguns estudantes mais ligeiros entenderam que se tratava de um Terminate and Stay Resident ou TSR com uma system call chamada talvez pela INT 21h, eu posso estar errado mas era algo assim. Então era só carregar qualquer outra coisa nessa interrupção e assim apagar a rotina de derrubar a máquina que era carregado no boot do DOS. A gente era insistente.

Agora eu caía no shell do UNIX. Você acha Linux hoje complicado? Você não tem idéia de como era chato um UNIX de verdade, no caso um HP-UX pra ser mais exato. Era engraçado que por alguma razão os servidores da Politécnica tinham nomes de animais como Lion, Spider. Depois resolveram colocar nomes de origem indígena, a máquina que eu tinha conta era no Amandy. Bom, pra conseguir fazer qualquer coisa útil eu precisava primeiro aprender a navegar pelo shell. E repetindo que naquela época não existia stackoverflow nem muito menos Google. Aliás, também não tinha Amazon pra comprar livros nem nada disso. A gente tinha que aprender as coisas na marra mesmo.

Como eu venho da época do MS-DOS onde basicamente a gente precisava saber comandos pra fazer qualquer coisa, o UNIX era só outra linha de comando diferente. Eu não tive o choque de ter começado numa interface gráfica e de repente cair na linha de comando. Pra mim foi o oposto, a interface gráfica que sempre foi opcional. Assim começou minha jornada pra aprender o básico, no DOS eu sabia listar as coisas com o comando ‘dir’ agora no UNIX era usando ’ls’, no DOS eu copiava as coisas com comando ‘copy’ no UNIX era ‘cp’ e assim foi indo, um comando de cada vez. Ajudava bastante que fiquei amigo de veteranos do curso de Engenharia Elétrica da Poli, que por alguma razão eram muito mais tech savvy que o povo do IME na época. Por causa disso eu tive mais amigos na engenharia da Poli do que no meu curso no IME. Era um pessoal que desenhava circuitos integrados no café da manhã. Eu falo que cursar uma faculdade não é só pelo curso em si, mas sim por esse tipo de networking. Eu era o mais novo e o mais noobie de todos, e eu era uma esponja aprendendo tudo que conseguia deles.

Como em linha de comando não havia um navegador gráfico e como a Web no começo era muito simples, eu usava o Lynx como navegador. Hoje em dia com HTML 5, CSS 3, WebGL é impossível usar o Lynx. Eu costumo dizer que quebraram a Web hoje, mas se quiser navegar via linha de comando recomendo tentar o Browsh, que é bem mais moderno. Pra acessar meus e-mails tinha o comando ‘mail’ que era bem primitivo e eu nunca aprendi a usar direito mas felizmente tinha o cliente de e-mail ‘pine’. Se você já usou o editor Nano no Linux de hoje em dia, ele é o clone do editor Pico, que era o que vinha no cliente Pine e que eu usava todo dia em 95. Na época eu não usava Vim mas sim o Vi original e eu lembro do desespero de entrar e não conseguir sair da primeira vez, como todo mundo. Aprender o dois pontos “q” foi uma revolução! Aliás, uma versão alternativa mais moderna do que o Pine hoje parece ser o Aerc, ou você pode usar o fetchmail pra popular o maildir, ou eu “acho” que tanto o Pine quanto o Mutt suportam IMAP pra se conectar em servidores de e-mail mais modernos. Antigamente o protocolo era o POP3 e procmail.

Na sequência, aprendi a usar a Usenet, um pouco de Gopher, IRC e assim meu arsenal começou a aumentar. Mas preciso confessar que eu gastava a maior parte das minhas horas perdendo tempo em chat de IRC mesmo. E eu não estou falando de mIRC no Windows, mas do cliente de IRC original do UNIX na linha de comando. A gente fuçava mensagens na Usenet, descobria servidores onde o povo deixava arquivos, baixava bastante coisa via FTP. Tinha bastante coisa gratuita não-warez no FTP da Unicamp na época, foi onde eu baixei o beta do Java que ficava numa pasta chamada Oak, que depois fui entender que era o codenome do Java antes do 1.0.

Os protocolos de internet na época eram muito simples, a maioria baseado em texto e estamos falando de uma época anterior a encriptação como TLS, então hoje usamos SSH mas antigamente era só Telnet. Hoje usamos SCP mas antigamente era FTP e assim por diante. Além de FTP, muitos programinhas e mesmo imagens e outros arquivos binários eram trafegados no corpo das próprias imagens na Usenet ou até IRC. Pense google groups ou stackoverflow de hoje. Porém na usenet só trafegava texto, então como trafegar binários? Assim eu aprendi sobre unix to unix copy protocol ou UUCP e as ferramentas uuencode e uudecode, que transformava binários de 8-bits em textos de 7-bits. O equivalente hoje seria o encode e decode de Base64. Finalmente o tráfego de warez estava começando a acontecer agora que eu sabia como me comunicar, onde procurar, e como trafegar os binários.

Mesmo em banda larga às vezes a fonte vinha de servidores lentos. E às vezes os arquivos eram quebrados em múltiplas mensagens na usenet. Daí a gente aprendeu a deixar os downloads via FTP rodando em background e com isso eu aprendi que UNIX suporta o conceito de jobs. Rodar o comando com o “E” comercial no final ou fazendo Ctrl + Z e aprendi a usar comandos como ‘bg’ e ‘jobs’ e ’nohup’. Eu não me recordo de ter usado comandos como ‘disown’, eu não entendia muito bem o conceito de signals ainda, como o HUP de hang up quando o terminal desconecta, fui aprendendo aos poucos. De qualquer forma, assim eu podia deixar as coisas baixando em background, deslogar da minha sessão, ir pra casa e no dia seguinte, se nada deu errado, pegar meus arquivos. Vocês podem ver que eu fui aprendendo a usar UNIX com a motivação de baixar pirataria, um motivo super nobre!

Não era comum na época consumir as coisas online como fazemos com YouTube ou Spotify. A banda era limitada, a velocidade era baixa, então a gente baixava tudo pra poder consumir depois. Vou dizer que a essa altura eu já estava menos interessado nos warez e mais engajado nas salas de chat de IRC e tentando entender melhor como a Web funcionava. Interessante que eu usava Windows 3.1 e Windows NT já naquela época, a gente tinha navegadores como Netscape Navigator Gold onde eu aprendi a editar HTML, FrontPage da Microsoft, editores como o HotDog eu acho, mas pra coisas como IRC, FTP, Usenet a gente usava terminal mesmo. A internet era mais devagar nas máquinas locais e mais rápido do servidor, então era um incentivo pra continuar no terminal. Eu finalmente comecei a me sentir confortável com essa tal de Internet e suas tecnologias de base.

E esse foi um pequeno resumo de alguns episódios que eu lembro entre 1990 e 1995. O episódio não tem nenhum objetivo muito educativo a não ser contar minha história mesmo. Pode ser que eu esteja sendo leviano mas até hoje eu nunca atrelo aprender alguma coisa com nenhum objetivo muito grandioso. Eu nunca penso “vou aprender X porque isso pode ser mais lucrativo no futuro” ou “quero aprender Y porque parece que vai me levar pra uma carreira mais promissora” ou qualquer coisa planejada assim. Todas as memórias que eu tenho de aprender alguma coisa sempre tiveram objetivos super banais, como vocês puderam ver. Se resumir a última metade do vídeo você pode dizer que eu aprendi UNIX pra baixar pirataria mais rápido. Só que tudo que eu aprendi: copiando apostila de programação, sendo estagiário do meu tio, apresentando games na Fenasoft, fazendo ilustrações pra revista videogame, aprendendo as tecnologias de internet pra baixar warez, tudo me levou a aprender coisas como dBase, Clipper, CorelDraw, UNIX e aprender a falar em público.

Eu falei no episódio de Procure o que Ama só que não, que eu gosto do meu esforço, e é isso que eu quero dizer. Naquela época dos 13 aos 18 anos eu sequer tinha essa noção de que a gente devia procurar alguma coisa que ama. Eu só fui fazendo, sendo curioso. Aliás, a definição de hacker pra mim é uma pessoa curiosa com tecnologia. Uma coisa foi levando a outra, e sem querer se passaram 5 anos que eu fui aprendendo um monte de coisas que se tornariam importantes nos anos seguintes.

Se eu ficasse toda hora pensando “ah, não vou perder tempo com isso porque não sei se vai ser útil daqui 5 anos” eu ia ficar estagnado o tempo todo só planejando, planejando e nunca de fato fazendo. Esquece, nessa fase da vida é inútil ficar planejando, a gente é jovem demais pra ter noção real de qualquer coisa. E eu estou parando a história exatamente antes de começar a primeira bolha da internet, nesse ano eu ainda ia ver o lançamento de coisas como Java 1.0, Delphi 1.0, Flash 1.0 no ano seguinte, .NET nem existia ainda, todo mundo ainda usava Perl e não Python, UNIX e não Linux, PHP ainda não tinha começado.

Esse foi um breve resumo dos meus primeiros 5 anos, eu sei que não é um conhecimento geral mas eu queria deixar registrado essa fase pra posteridade, espero que tenha ajudado a dar alguma perspectiva pra alguns de vocês. E vocês, como foram os seus primeiros 5 anos? Não deixem de compartilhar nos comentários abaixo, se curtiram mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê, até mais!

[Akitando] #59 - A História de Ruby on Rails | Por que deu certo?

Wed, 21 Aug 2019 17:00:00 -0300

15 anos atrás Ruby on Rails é lançado, e todo mundo tinha certeza que logo desapareceria.

Ruby on Rails 6.0 acabou de ser lançado.

Why, The Lucky Stiff sumiu faz 10 anos.

Estou iniciando o 2o ano do meu canal e acho que agora é uma boa hora para contar essa história.

Esta é a história que eu queria ter contado logo que comecei o canal, 1 ano atrás. Mas eu precisava explicar muitas outras histórias antes para dar contexto. Minha própria carreira inicial. A história da computação e da Web nos anos 90 a 2000. Conceitos como Agilidade e Startups.

Agora que contei boa parte do que queria, se vocês assistiram os vídeos do último ano, devem estar equipados pra entender esta parte da história. Neste episódio vou compilar 8 anos de história, de onde veio Ruby on Rails, e porque ele estava destinado a dar certo mesmo que todos os “experts” achassem que não daria.

Se quiser aprender mais, entre no grupo de Rails do Facebook: https://www.facebook.com/groups/rubyonrailsbrasil/

É o maior e melhor grupo que eu conheço e eles estão sempre compartilhando dicas, materiais e cursos, fora ofertas de emprego.

Disclaimer:

Esta história é contada sob meu ponto de vista pessoal tendo participado ativamente de muitos eventos. Posso ter esquecido alguns momentos e nomes importantes, então mande nos comentários se eu perdi alguma coisa.

Logo de cara, só depois que terminei de subir o video notei que esqueci de mencionar o pessoal do Rio Grande do Sul, do antigo Mailee e que fez o Catarse, o Kickstarter brasileiro!! Perdoem-me por ter esquecido.

Links:

15 Minute Blog Demo 2005 (https://www.youtube.com/watch?v=Gzj723LkRJY)
Ten Years Of Test Driven Development (http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment)
The history of testing framework in Ruby (http://rubykaigi.org/2015/presentations/kou/)
Why’s Poignant Guide to Ruby (https://poignant.guide)
Why The Lucky Stiff Documentary (https://www.youtube.com/watch?v=64anPPVUw5U)
Ruby Koans (http://rubykoans.com)
Ruby Quiz (http://rubyquiz.com)
RailsCasts (http://railscasts.com)
RubyTapas (www.rubytapas.com/)
CodeSchool: Rails for Zombies (https://www.pluralsight.com/courses/code-school-rails-for-zombies)
Blog Igvita (https://www.igvita.com)
Rails and Merb Merge (https://yehudakatz.com/2008/12/23/rails-and-merb-merge/)
RailsEnvy videos (https://www.youtube.com/watch?v=YZeZsZEEpno&list=PLfBoZfyUGYQZ--h9B4e_tmyob8tbqOTKd)
The Decision to Leave Code School (https://www.greggpollack.com/the-decision-to-leave-code-school/)
Travis CI joins the Idera family (https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc)
Reia (https://github.com/tarcieri/reia)
11 types of apps you can build with Ruby on Rails (https://naturaily.com/blog/ruby-on-rails-apps)
Who gives a F*** about Rails in 2019? (https://naturaily.com/blog/who-gives-f-about-rails?utm_source=linkedin&utm_medium=post)
Why should you choose Ruby on Rails for your MVP? (https://prograils.com/posts/why-should-you-choose-ruby-on-rails-for-your-mvp?utm_source=rubydaily&utm_medium=referral&utm_campaign=rails-mvp-1)
AkitaOnRails: Retrospectiva on Rails - 10 Anos e Muito Mais! (http://www.akitaonrails.com/2014/08/26/retrospectiva-on-rails-10-anos-e-muito-mais)
AkitaOnRails: Entrevistas (https://www.akitaonrails.com/interview)
AkitaOnRails: _Why, Ruby Dramas, and Dynamiting Courtlandt (http://www.akitaonrails.com/2016/09/26/os-proximos-10-anos)
AkitaOnRails: The Next 10 Years (http://www.akitaonrails.com/2016/09/26/os-proximos-10-anos)

R.I.P.:

Remembering Jason Seifer (https://www.greggpollack.com/remembering-jason-seifer/)
EZRA ZYGMUNTOWICZ: IN MEMORIAM (https://www.engineyard.com/blog/ezra-zygmuntowicz-in-memorium)
REMEMBERING JIM WEIRICH (https://lithespeed.com/remembering-jim-weirich/)
Remembering James Golick (https://medium.com/@benkaufman/remembering-james-golick-23c1dc3ab920)
GIVING OPEN-SOURCE PROJECTS LIFE AFTER A DEVELOPER’S DEATH (https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death/)

=== Script

Olá pessoal, Fabio Akita

Finalmente! Finalmente, decidi fazer um episódio sobre Ruby on Rails. Muita gente que me conhece nas interwebs como AkitaOnRails começou a me acompanhar quando eu comecei a evangelizar Rails mais de 12 anos atrás. Quando comecei o canal talvez muitos pensariam que a coisa mais óbvia é que eu ia continuar falando de Rails, mas até hoje ainda não fiz nenhum video a respeito. Esse é o episódio que eu queria ter feito 1 ano atrás mas que precisei publicar 58 vídeos antes pra dar o contexto. Exagerando um pouco eu diria que todos os videos que eu fiz até agora foram um prólogo pra esse. Também é apropriado que estou oficialmente iniciando o 2o ano do canal exatamente com esse tema. Quem acompanha o canal já me viu mencionando alguns eventos históricos de Ruby on Rails como nesse episódio da série Começando aos 40 (episodio 1 de backend)

Se alguém me perguntar hoje: é essencial usar Rails? Honestamente não, embora eu diria que você se daria melhor usando Rails, sem dúvida. Em 2019 temos muitas outras opções se, e somente se, você souber o que está fazendo. Eu ainda considero Rails o melhor framework de ponta a ponta e o melhor ecossistema pra maioria dos casos, o pacote completo. Os princípios e fundamentos que tornaram Rails especial em 2004 continuam valendo hoje. Mesmo que você não use Ruby, você provavelmente está “On Rails” e não sabe disso. A história do Rails é um caso único e eu não vejo ele se repetindo de novo tão cedo.

A idéia do video de hoje não é ser a história totalmente completa, mas sim a história pelo meu ponto de vista enquanto personagem nessa história, então vai ter alguns eventos talvez importantes que eu talvez pule. Enquanto escrevia eu via as páginas aumentando, 10 páginas, 20 páginas, 30 … e resolvi que não vou cortar em múltiplos video, pra variar. Vai tudo numa tacada só (… respira …), então vão pegar a pipoca, a água, vão no banheiro antes, e senta aí que lá vem história.

(…)

Como é o jeito “certo” de desenvolver um software médio web hoje em dia? Simples, começa criando um novo projeto no GitHub ou GitLab. Daí roda o generator do seu framework pra criar o esqueleto. Faz o primeiro commit e dá push pro repositório e agora abre acesso pros seus colegas de trabalho. Vamos organizar o trabalho da equipe num backlog e cada um vai fazendo uma pequena feature. Cada feature você abre um novo Pull Request ou Merge Request, dependendo se for GitHub ou GitLab.

Agora vamos criar os specs e fazer o código pra passar. Ou se você não é adepto de test-first development ou TDD como Eu também não sou sempre, pode ser o bom e velho test-after, importante é subir seu código com um mínimo de testes. Alguém insistiu em tentar subir código sem testes? git reset –hard nele! Junta os commits dos testes, do seu código, manda pro branch do pull request. Finalizou? Pede pros colegas darem aquela revisada marota. Agora que tem algum código já seria bom automatizar a execução dos testes, então vamos configurar um Travis-CI ou Circle-CI ou o CI integrado do próprio GitLab.

Agora a gente vai subindo novos códigos, vendo os testes de todo mundo da equipe rodando e passando. E depois de alguns pull requests mergeados, temos uma primeira versão que já dá pra pro usuário brincar. Hora de subir num ambiente de staging pra mandar pros usuários testarem. Então bora criar um projeto no Heroku, definir os recursos extras como banco de dados que vamos precisar e git push heroku.

Sucesso! Aplicativo funcionando! E pra facilitar a vida, vamos criar um continuous deployment ligado ao CI pra toda vez que subir código novo e os testes passarem, ele já subir a versão nova pro ar. Ou então pra cada pull request ainda não aprovado subir um ambiente de testes no Heroku em paralelo também. Assim a vida dos testers e QA vai ficar mais fácil.

Além disso podemos conectar serviços como CodeClimate pra constantemente avaliar a saúde do nosso código, ver se não estamos acumulando muito débito técnico. Avaliar se não estamos deixando de atualizar bibliotecas com bugs de segurança. Se quisermos adicionar recursos mais avançados como WebSockets, pra criar um chat ou fazer push notifications, devemos usar serviços como o bom e velho Pusher. Pra maioria de nós não é necessário usar Node.js ou Go ou algo assim. E podemos habilitar o New Relic RPM no Heroku pra monitorar o uso da nossa aplicação e avaliar possíveis gargalos que precisamos ir otimizando. Ah, é bom viver nessa era de Software as a Service.

Tudo isso que eu acabei de explicar em 2 minutos é o dia a dia de qualquer projeto web comum, ou pelo menos deveria ser caso você ainda esteja numa empresa que não segue esse tipo de fluxo de trabalho. Eu diria que mesmo quem não segue, sente uma certa inveja e gostaria de estar trabalhando assim. Porém lembre-se do que eu venho falando em todos os meus vídeos: essa é uma realidade hoje pra muitos, em 2019. Isso não era verdade em 2004. E esta é a história de como a comunidade Ruby on Rails criou essa realidade.

Eu já contei parte disso no episódio do Diário de Henry Jones, mas em 2004 eu ainda era um consultor Java e SAP, lidando com o peso e burocracia de projetos enterprise desenhados em centenas de páginas de casos de uso e diagramas UML, usando coisas como IBM WebSphere ou BEA WebLogic. Mundo open source não era algo que programadores enterprise discutiam muito, porque não parecia muito “profissional”, era coisa de “agência de php pra sitezinho de sobrinho”. Profissionais usavam JSP, com algum framework proprietário da IBM ou da Oracle.

Pensem em um ambiente onde gerenciar banco de dados era um troço difícil, nenhum programador gostava de fazer ou mesmo podia fazer se quisesse. Pra isso existiam DBAs. Subir aplicativo web em produção era um saco, ninguém queria fazer, por isso existia gente de infra só pra subir versão nova em produção. Gerenciar versionamento de software era um saco! Ninguém queria fazer! Eu juro que existia emprego pra uma posição chamada “Gerente de Configuração” pra ferramentas da Rational tipo Clearcase, que é literalmente alguém cujo job description era fazer commit do código! (mindblown!)

O que havia de mais avançado no mundo open source naquela época era poder desenvolver apps em Apache Struts ou o novíssimo Spring na era do Java 1.4 pra 1.5, subir num tomcat ou glassfish local pra testar e num JBoss pra subir em produção. Usar Subversion era um troço meio subversivo ainda. Povo preferia usar Clearcase ou Microsoft SourceSafe. E mesmo usar Subversion era sofrido, tenta fazer merge de branches pra subir no trunk. E desenvolver fora da rede offline não dava porque Subversion precisava estar online já que commit é o equivalente a commit mais push num Git de hoje. Windows XP ainda era mais do que normal, com um tanto de antivirus tipo McAfee (video) pesando e mesmo assim com aquela sensação que ligar o XP na internet era que nem fazer sexo sem proteção. Acho que eu formatava e reinstalava meu sistema com certa frequência só pra garantir. Eram tempos difíceis …

Então em 2005 a gente esbarra num video com o chamativo título de “Blog em 15 minutos” de um moleque desconhecido com cara de cagador de regra … não, não, não era eu, era esse dinamarquês chamado David Heinemeir Hansson que a gente se acostumou a chamar só de DHH. Pff … em 15 minutos meu Eclipse com os plugins de Websphere nem carregou tudo ainda. Esse video aliás, tem quase 15 anos, e eu acho que vale a pena incorporar ele aqui. Lembrem-se, eu sei que 15 anos atrás muitos de vocês assistindo tinham uns 10, talvez 15 anos de idade, mas tente assistir assumindo que Nada que vocês usam hoje existia naquela época.

(… blog 15 minutos)

A gente chamava esse video também de “video do oops”. O David foi convidado pra vir pro FISL de 2005, o Forum Internacional de Software Livre que acontece em Porto Alegre, todo ano. Um dos organizadores naquele ano foi meu camarada Rodrigo Kochenburger que hoje mora em São Francisco e é um dos melhores programadores que eu já conheci. Antes de mim, pessoas como ele já estavam engajados nessa comunidade de nicho que era Ruby. Agora, entenda que literalmente ninguém usava Ruby fora do Japão e mesmo lá era só um pequeno grupo. Quando o DHH veio apresentar o Rails no FISL a platéia eram basicamente pythonistas e outros que tavam nos corredores. Se tinha meia dúzia de rubistas, no FISL inteiro, era muito.

Pra dar uma noção, tirando pessoas como o Rodrigo não tinha quase nenhum rubista na ativa em 2005. Tinha o Caffo que é outro Rodrigo, o Rodrigo Franco que tinha começado a primeira mailing list brasileira de Rails, a Rails-BR. Tinha o Adriano Dadario e o Ronie Uliana que mantinham o antigo site/forum RubyBR. Tinha o mestre Eustáquio Rangel que publicou o primeiro livro de Ruby no Brasil, e o Ronaldo Ferraz que publicou o primeiro tutorial de Rails em português. Ainda ia levar algum tempo pra aparecer outros blogs que viraram referência aqui no Brasil como o Simples Ideias do Nando Vieira. Aliás, eu provavelmente vou esquecer muitos nomes do começo da história, me perdoem e quem se lembrar da galera das antigas pode mandar nos comentários abaixo.

Naquela época o Vinicius Teles do Rio de Janeiro já tinha publicado seu livro sobre Extreme Programming e estava começando a aplicar em projetos Rails. E outros nomes começaram a surgir como o Manoel Lemos, que hoje virou venture capitalist na Redpoint mas na época desenvolveu o BlogBlogs em 2006, antes de entrar pra Editora Abril. A ótima equipe que de alguma forma o Marco Gomes conseguiu juntar foi quem construiu o famoso Boo-Box em 2007. Na época existia os e-mail do UOL e tinha um produto paralelo que era o BOL ou Brasil Online, que foi feito em Rails lá por 2006 ou 2007 também.

Como falei em outros episódios eu acredito em ciclos de mercado. É muito difícil identificar o começo de um ciclo, normalmente você se dá conta que tá dentro de um quando já passou da fase de early adopters. Mas em 2005 eu sabia que Ruby on Rails, principalmente no Brasil, estava ainda começando o dia 1 desse ciclo. É muito raro conseguir enxergar o dia 1 de alguma coisa que vai conseguir completar o ciclo de 10 anos e embarcar nele no começo. Em 2005 eu tinha já uns 10 anos de carreira, e eu lembro que senti esse frio na espinha quando relembrei de 1995, ano que tivemos alguns dos lançamentos mais históricos até então, o Java 1.0, o Delphi 1.0, o Netscape 1.0 com Javascript 1.0, o Windows 95 inaugurando a era 32-bits. E ali estava eu, 10 anos depois, sentindo que um novo ciclo de 10 anos estava iniciando no mundo de programação. Eu não podia imaginar o que viria pela frente, só agora em retrospectiva dá pra ligar os pontos.

Eu achei o David Hansson, o DHH, um cara muito inteligente, diferente da maioria puramente técnica. Ele criou um produto que ninguém tinha feito igual até então. E não estou dizendo só em criatividade técnica. Estou falando em produto como um todo mesmo. Aliás, ninguém se referia a sites como “produtos” nessa época. Algumas coisas eram geniais só de bater o olho e algumas coisas a gente sabia que seria genial mas faltava ainda tempo pra se provar.

Vamos começar do básico. Naquela época dentre algumas das linguagens mais usadas estava Basic, tanto do Visual Basic, quanto VBScript de ASP e plugins de Office, e no novo .NET, daí C#, Java, PHP, ColdFusion, lembram de ColdFusion?? Lembrando que estamos falando de C# acho que 2, Java 1.5, PHP 3 ou 4. Javascript ainda era não mais que um brinquedo pra soltar box de alert nas páginas. ActionScript que era baseado em Javascript só existia no mundo Flash. Nenhuma das novas linguagens que você conhece hoje tinham sido inventados ainda como Scala, Elixir, Go, Rust, Clojure, Swift, Kotlin. Objective-C ou Erlang já existiam mas ninguém nunca tinha ouvido falar neles no mercado em geral.

Falando em Objective-C a gente tava entrando no final do ciclo de hype de orientação a objetos. Nos anos 70 principalmente a discussão sobre o que era a melhor forma de descrever e programar objetos foi tema de inúmeras discussões, livros, eventos e eu argumentaria que a melhor linguagem orientada a objetos de todos os tempos foi Smalltalk. Porém as empresas que mantinham as versões comerciais de Smalltalk como ParcPlace-Digitalk, ObjectShare, acho que tiveram ingerências ou azar mesmo, e começaram a desaparecer nos anos 80. E o aparecimento de coisas como Visual Basic e depois Java meio que foi o tiro de misericórdia. Smalltalk desapareceu quase totalmente nos anos 90, ninguém mais ouvia falar. Hoje se você procurar ainda acha a Cincom ou a Gemstone e versões open source como o Squeak e Pharo. Só alguns nichos ainda carregavam a herança de Smalltalk em linguagens como Objective-C que a NEXT de Steve Jobs estava usando e essa linguagem obscura do Japão chamada Ruby, que é uma das únicas que se assemelha ao estilo do Smalltalk e Objective-C, mesmo hoje.

Escolher Ruby foi um acerto improvável. Muitos poderiam criticar o fato do DHH não ter escolhido algo como Python que também é uma linguagem interpretada, orientada a objetos e com tipagem dinâmica, mas teria sido a escolha errada. Eu nem sei se o DHH chegou a pensar tão longe assim, eu acho que foi mais sorte mesmo, mas ainda bem que ele escolheu Ruby no lugar. Apesar da linguagem em si ter características excepcionais de ser super flexível, expressiva e agradável de trabalhar comparado com Java, ele tinha Uma coisa que ninguém mais tinha: … ninguém usava, não tinha um ecossistema estabelecido. É como você encontrar ouro e acumular, anos antes do mundo determinar que ele tinha valor.

O DHH começou como um freelancer, trabalhando da Dinamarca que é o país dele, pra agência chamada 37signals, de Chicago, que foi fundado por Jason Fried. Ele já tinha trabalhado um pouco com Java, um pouco com PHP, e assim como todos nós naquela época, já estava de saco cheio da burocracia do Java ou dos bugs e cultura de “quick and dirty” do PHP e Perl do fim dos anos 90. Então por 2003 ou 2004 a agência começou a migrar pra virar uma empresa de produtos, e o DHH resolveu dar uma chance pra esse tal de Ruby. Assim ele desenvolveu o lendário Basecamp que é uma ferramenta colaborativa pra organizar pequenos projetos, e em 2004 ele extraiu o framework Ruby on Rails. Aliás, primeira dica, nunca acredite num framework que não foi extraído de um aplicativo de verdade.

(musica de suspense) Agora aqui entra a minha análise pessoal. O fato do DHH ter se aliado a Jason Fried e o DNA da 37signals ser de design, especialmente numa época onde o design da Apple estava começando a despontar, foi extremamente importante. Muito da linguagem minimalista do design da escola alemã de Bauhaus se misturou ao estilo de código, produto e filosofia do DHH. Naquela época o normal pra um arquiteto enterprise era criar frameworks o mais flexível possível, tudo explícito, tudo configurável, com o maior número de abstrações e indireções pra suportar projetos corporativos de qualquer tamanho e qualquer escala, e de preferência via comitê, com consenso de gente que nem de fato vai usar. Era a filosofia de “e se amanhã eu precisar?”. O DHH preferiu fazer o caminho inverso, que na época era muito inédito: criar um produto de verdade primeiro, que realmente funciona com usuários de verdade, e depois extrair as peças da fundação pra montar um framework. Ironicamente era assim que antes empresas como IBM e Oracle extraíam seus produtos: depois de implementar primeiro num grande cliente, como o governo ou os militares.

(comercial java)

Pouca gente fazia isso nos anos 2000. Arquitetos corporativos eram esnobes demais pra ir pra ralé e, deus me livre, fazer alguma coisa que funciona de verdade. (excerpt) No mundo PHP o pessoal fazia produtos inteiros, vide Joomla, vide Drupal, vide Wordpress. Mas eles raramente extraíam as partes comuns pra reusar em outro projeto, e a comunidade ficava fragmentada em ilhas. O estilo de código quick and dirty macarrônico, muita otimização prematura, porque o PHP não era exatamente a coisa mais performática do mundo também, e diferente de Ruby o PHP de fato tomou muita porrada de verdade. Em vez de “perder tempo” fazendo frameworks, eles ficavam cada um na sua ilha de produto e não se preocupavam muito em reuso. O máximo eram as tentativas de imitar o mundo Java, e imitar justamente a parte ruim: fazendo frameworks gigantes demais como o Zend e criando monstrinhos como o primeiro Magento.

“Vamos ficar masturbando diagramas abstratos como se fosse arte barroca o dia inteiro”.

(comercial php)

Comparativamente o framework Ruby on Rails era muito pequeno. Quando eu escrevi o primeiro livro de Rails eu também não sabia tudo de Rails ainda, então eu escrevi meu livro, capítulo a capítulo lendo o código fonte de cada parte. O código naquela época era pequeno o suficiente pra dar pra ler de ponta a ponta. Mais importante: o código que eu como desenvolvedor de uma app usando Rails precisava escrever era surpreendentemente pouco. Vindo de J2EE a gente tinha que fazer um trilhão de boilerplates; exatamente porque o framework exigia tudo explícito.

Por exemplo, quero fazer um Entity Bean em 2000. Precisava fazer um arquivo que é a interface, outro que é a implementação em si, outro que é um stub pra acesso remoto e por aí vai. Cada coisa que você fazia num J2EE precisava de uns 3 ou 4 arquivos de boilerplate pra ligar as coisas no framework. Não seria exagero dizer que se o projeto tinha 100 arquivos, só uns 20 era código de verdade com regra de negócio e tudo. Por isso a gente precisava usar Eclipse com plugins: pra ele gerar e atualizar essas classes extras pra gente. Era que nem os JavaBean antigos, se eu precisasse programar 10 propriedades, precisava implementar 20 métodos: 10 getters e 10 setters e, de novo, o Eclipse gerava isso automaticamente pra gente. Sério, era um saco programar com as primeiras versões de J2EE. (abaixa a cabeça)

Mas aí eu vi que no Rails não precisava fazer nada disso. Tinha quase zero boilerplates, era uma heresia! Ele apresentou esse conceito de Convention over Configuration e DRY ou Don’t Repeat Yourself, que é um pensamento meio óbvio hoje - ou pelo menos deveria ser - mas não era em 2004. Toda entidade vai ter os mesmos 3 ou 4 arquivos de boilerplate que não serve pra nada, então pra que gerar? Faça o framework inferir o que precisa gerar em tempo de execução e não gere nenhum arquivo que não seja absolutamente necessário. E, mais do que isso, o pouco que eu preciso gerar, não precisa de um plugin numa IDE: roda um script na linha de comando e boom, gera tudo pra mim! Isso era revolucionário! Daí é facil ver como um projeto que deveria ter 100 arquivos, em Rails tinha só uns 20 ou menos.

Justiça seja feita, o J2EE foi quem introduziu o modelo de MVC ou Model View Controller ou mais corretamente o Model 2 da Sun para o mundo em geral. Só que era tão complicado de entender que fazia sentido você precisar de certificação de arquiteto Java só pra conseguir entender esse tal de MVC. O Rails foi quem tornou MVC e conceitos como thin-controllers algo finalmente acessível pro público em geral.

O gerador do Rails sempre gera o esqueleto do projeto. Você sempre sabe que controllers vai nessa pasta, models vão nessa pasta, e views vão nessa outra pasta. Sem XMLs complicados pra configurar e duas dúzias de boilerplates que você nunca sabe onde colocar. Daí todo projeto Rails tem mais ou menos a mesma estrutura e era fácil pular de projeto e saber onde ficam as coisas. E a idéia se pagou porque 15 anos depois, a estrutura do Rails 5 de hoje é muito parecida com a do Rails 1. Mais do que Convention over Configuration, desde o começo Rails era o que gente chamava de opinionated, ou seja, seguia as opiniões do DHH. Isso é controverso até hoje, mas ele bateu o pé e insistiu em integridade conceitual.

Isso Não é uma democracia e Rails era um framework sem consenso e sem comitê. Já não era sem tempo, consenso em mundo técnico é só o mínimo denominador comum dos membros. Em vez de tentar abraçar o mundo e criar um framework que poderia ser pra qualquer coisa ele focou pra ser bom pra fazer apps similares ao Basecamp. Tem gente que odeia isso, mas haters gonna hate. Você pode trocar alguns componentes com alguma facilidade, mas quanto mais diferente você tentar ficar do Rails original, mais complicado vai ficar pra manter o projeto no futuro.

E aqui vemos a influência da Apple. Macbooks bem que poderiam ter mais portas de expansão, ser mais fácil de trocar peças e assim por diante. Mas aí ele seria igual um Dell ou Lenovo. O que torna o Macbook um Macbook é a forma. Sempre vai existir a discussão de forma contra função mas qualquer coisa diferente só pra conseguir consenso com algum nicho destrói sua integridade conceitual. Minimalismo parte do princípio que quem faz o design tem uma opinião muito forte sobre o que é esse mínimo. DHH não é nenhum Jobs, mas ambos certamente tinham muita opinião e não seriam dobrados com facilidade, e ambos foram provados corretos ao longo da década. Não é difícil de argumentar que se hoje Macs são dominantes no mundo de tech startups, foi por causa de Ruby on Rails. Sim, a culpa é nossa. Vejam este vídeo de 2007 que foi feito em parceria com a Apple Education:

(apple video)

Um dos aspectos que vinham ligados por padrão era segurança. Numa época onde era super comum sites sendo lançados em produção com erros primários como cross site request forgery, cross site scripting, sql injection, session hijacking, tudo isso já era travado por padrão no Rails. De novo um efeito de Convention over Configuration, ou seja, porque ter que ligar coisas manualmente que já deveriam estar ligadas por padrão? Você precisava manualmente desligar as proteções se quisesse, e aí fica por sua conta. Por isso apps Rails por muitos anos sempre estiveram entre alguns dos mais seguros por padrão. Todo framework que te vende “flexibilidade” porque você mesmo pode escolher quais componentes por adicionar, sempre vai ser pior porque a grande maioria vai sempre escolher errado.

E se isso não fosse suficiente, nesse esqueleto que ele gera igual pra todo projeto ainda havia outra coisa Completamente diferente: um diretório chamado test. E todo gerador de models, ou controllers ou views também gerava arquivos correspondentes de testes vazios nesse diretório. Lembrem-se era 2004, o manifesto ágil de software tinha saído só 3 anos antes. Vamos lembrar uma coisa, Gerry Weinberg fez testes pela primeira vez em cartões perfurados em 1989. Kent Beck, um dos criadores de Extreme Programming começa a experimentar essa ideia e cria SUnit em 1994 inaugurando a idéia da gramática de testes como test cases, asserts, e vai fazendo pesquisa e escrevendo a respeito até finalmente consolidar a idéia de test driven development e lançar o JUnit no ano 2000. Ou seja, a idéia de TDD não tinha ainda 4 anos desde que o mercado começou a ouvir falar.

Os mundos de desenvolvimento tradicionais, sejam .NET, Java, PHP, não estavam assim muuuuito empolgados em adotar, só alguns pequenos nichos. Então nesse ponto era muito frustrante querer que os programadores fizessem testes, se você tentasse provavelmente todo mundo ia tirar sarro de você na melhor das hipóteses ou você podia ser demitido mesmo, por ser improdutivo fazendo código irrelevante pro projeto! Éee eu sei! De novo, aqui temos outro insight: é muito difícil implementar mudanças radicais como um TDD num ecossistema gigante que já existe e é resistente a mudanças. Não vai acontecer tão fácil, mas existem estratégias. Lembram que eu falei antes que um dos acertos improváveis do DHH foi ter escolhido Ruby, uma linguagem que ninguém usava? Eis o motivo de porque deu certo: porque ele precisava introduzir um novo paradigma mas sem ter que gastar tempo convencendo antigos usuários de Ruby e migrando projetos inteiros pro novo paradigma, por isso dava pra se mover muito rápido.

No ano 2001 o mundo Ruby começou a se interessar com a idéia de testes no estilo de xUnit, surgiram bibliotecas como testsup, depois Lapidary, finalmente RubyUnit e Test::Unit que seguia o estilo xUnit do Kent Beck. E isso foi adotado no Rails do DHH, como padrão! Não algo que você tinha que adicionar depois, mas algo que o framework obrigava você a manualmente tirar se não quisesse. Junte a isso que alguns agilistas como Ward Cunningham e acho que Martin Fowler já estavam com um olho no Ruby porque ele lembra o Smalltalk que eles já gostavam como a verdadeira orientação a objetos, um estilo que ficou perdido nos anos 80.

Aliás, o primeiro livro de Ruby em inglês saiu em 2001, apelidado de Pickaxe por causa da capa, foi escrito por dois signatários do Manifesto Ágil, Dave Thomas e Andy Hunt. Portanto você imagina que além de tudo essa comunidade ocidental de Ruby, começando do zero já iniciaria com Extreme Programming e The Pragmatic Programmer como filosofias de fundação. Finalmente uma comunidade de software que estava começando do zero do jeito certo, ou seja, o jeito verdadeiramente Ágil de desenvolvimento.

Mais do que isso, o tipo de desenvolvedor que virava rubista era muito estranho. O exemplo mais notável foi o lendário Why, the Lucky Stiff, que escreveu naquela mesma época o lendário livro que muitos usaram pra aprender Ruby: The Poignant Guide to Ruby. Sério, olha algumas páginas desse livro (video).

Why era um pseudônimo, e ele nunca quis revelar seu nome ou qualquer detalhe da sua vida, e quando algumas pessoas começaram a fuçar e começar expor sua vida pessoal, inclusive revelando seu nome verdadeiro como sendo Jonathan Gilette, ele fez uma coisa que admiro até hoje. Ele resolveu sumir do mapa em 2009, sem deixar vestígios. Aliás, em 18 de agosto de 2019 faz 10 anos desde que Why apagou todos os seus repositórios e sites e desapareceu.

Ele era um artista que usava código pra se expressar, e ao contrário de um Python ou Java com seu estilo de engenharia de ter só um jeito certo pra se fazer as coisas, e tudo deve ter consenso em comitê, o Ruby era o oposto: manipule a linguagem como você quiser. Ele tinha a liberdade do Lisp com a expressividade do Smalltalk. Nenhuma outra linguagem da época permitiria algo como o que Why fazia. Why the Lucky Stiff que inclusive é um nome que aparece citado uma única vez no romance The Fountainhead, de Ayn Rand. Outra coincidência que eu achei muito providencial dado que Why fez a mesma coisa que o fim do livro A Nascente.

(video acabando com chunky bacon)

Se você nunca ouviu a expressão “Chunky Bacon”, você ainda não aprendeu Ruby do jeito certo (risos). Ruby começou sendo ferramenta de artistas. A primeira geração de rubistas é um grupo que não se via igual talvez desde os anos 60 ou 70. E o que eu falei que Ruby atraía desenvolvedores estranhos é porque eram pessoas que gostavam de expressar suas décadas de experiência com código. Entrar num grupo gigante é fácil, é só ser um seguidor. Mas pra entrar num grupo com zero pessoas, você precisa ser um criador. Por isso a primeira geração de rubistas trouxe gente como Chad Fowler, Rich Kilmer, David Black, o falecido e adorado Jim Weirich, depois agilistas como Dave Thomas ou Martin Fowler ou Uncle Bob. Não deixem de assistir o documentário sobre o Why que eu co-apresentei na Rubyconf Brasil de 2014 com Kevin Triplett e meus artigos sobre ele que vou deixar nas descrições abaixo.

Então vamos recapitular nossa sopa primordial: uma linguagem obscura, que resgata o espírito de Smalltalk e Lisp, a orientação a objetos original, que implementa corretamente os princípios ágeis, e até mesmo outras noções como yagni ou you ain’t gonna need it, que é o jeito minimalista que o DHH aprendeu na renascença da nova Apple de Steve Jobs, numa comunidade de misfits e artistas wannabe, de desenvolvedores experientes dos anos 70 a 90 que queriam voltar a se expressar com código. Claro que isso atraiu a atenção de muitos agilistas da época, incluindo metade dos signatários do manifesto. E mais do que isso: chegamos ao fim da depressão do crash das ponto coms em 2001, estava na hora de recomeçar a criar produtos e o Basecamp e o estilo Getting Real da 37signals se tornou o exemplo de como fazer isso. Aliás, o Getting Real que aqui no Brasil chegamos a fazer uma tradução oficial em português também e que se tornou o manifesto da nova geração de empreendedores de produtos de tech startups, muito antes do surgimento de Lean Startup.

E claro, todo mundo deu risada de Ruby on Rails, um framework não-enterprise, que não era infinitamente configurável, que vinha com defaults estranhos como MySQL em vez de suportar Oracle, que não tinha suporte pra Windows, que te obrigava a apagar os arquivos de testes, porque ninguém queria fazer testes no mundo Java, e ainda usando Macs??? Profissionais usam Windows XP, lógico! E ainda usando essa linguagem bizarra chamada Ruby que diz que é orientada a objetos mas não tem tipos estáticos como toda linguagem profissional como Java ou C#. Lógico que ia ser um fracasso. (gandhi)

Ah, e você não gosta do Jira hoje? Imagina como o Jira era mil vezes pior em 2004, e como todo mundo ria que algo no estilo Basecamp nunca seria usado no mundo enterprise. Se ainda não entendeu a gravidade da situação da época foi em 2003, 1 a 2 anos antes que o Java Server Faces, o JSF tinha acabado de ser lançado e todo mundo estava adotando aquele lixo, que era um ASP.NET WebForms piorado pra Java! Ah sim, pra quem gosta de falar em frameworks baseados em componentes e orientados a eventos, ASP.NET e JSF. (joinha)

A partir de agora, apertem os cintos, vamos fazer uma longa timeline, de uns 7 anos! Eu não vou por temas e sim em ordem cronológica. Vocês assistiram os demais videos do meu canal né? Porque agora muita coisa que eu disse neles vai se encaixar.

2004 foi um ano especial. Em 1o de Abril o Gmail foi lançado, demonstrando um dos primeiros single page applications e o poder de tecnologias como Ajax. Em 24 de julho saiu o primeiro beta público do Ruby on Rails versão 0.5. Em 2 de Outubro o DHH apresenta o Rails pela primeira vez numa RubyConf, que na época estima-se que tinha umas 60 pessoas na platéia. Três dias depois a O’Reilly promove a conferência Web 2.0 onde o termo foi cunhado pela primeira vez. Em 10 de dezembro o Google lança aquela funcionalidade que você usa todo dia e nem pensa muito, o Google Suggest, que vai te dando sugestões à medida que você vai digitando os termos de pesquisa, usando XMLHTTP e de novo demonstrando o poder do AJAX e comunicação assíncrona em tempo real. Todo mundo queria fazer a mesma coisa.

2005 não ia ficar pra trás. Logo no 1o dia do ano, a Robot Co-op lança o 43 Things; o site é um early adopter de Ruby on Rails. Em 8 de fevereiro o Google Maps lança pra Internet Explorer e Firefox, redefinindo o nível de interação possível em um web browser. Essa era a época que o Google tava literalmente on-fire lançando um app atrás do outro. E alguns dias depois, em 15 de Fevereiro, Jesse James Garrett cunha o termo Ajax para descrever as novas aplicações web ricas como Flickr, Google Suggest, ou Google Maps. No dia seguinte o Rodrigo Caffo cria a primeira mailing list brasileira de Rails, a Rails-BR.

Em março o britânico Peter Cooper começaria o blog Ruby Inside, o melhor blog pra se manter atualizado no mundo Ruby e Rails e que daria origem anos depois ao conjunto de mailing lists como JavaScript Weekly, Ruby Weekly, RubyFlow, Frontend Focus, Node Weekly, Golang Weekly e vários outros que centenas de milhares de desenvolvedores usam até hoje e se mantém com um dos melhores canais pra se manter atualizado. Em 7 de Abril tivemos outra revolução, o Lançamento inicial do sistema de controle de versão distribuída git. E na sequência, em 2 de Julho, o DHH grava o demo do blog de 15 minutos, demonstrando a velocidade do desenvolvimento rápido com Rails. Esse video se torna viral e todos os sites de todas as linguagens começam a notar a presença desse alien.

E não demorou muito, também por volta de julho tivemos o lançamento inicial do Groovy on Grails, um framework inspirado no Rails pra recém lançada linguagem Groovy que roda na JVM. Foi o primeiro de muitos clones de Rails que apareceriam nos próximos anos. Daí ainda em julho, no dia 7, é lançada a biblioteca javascript script.aculo.us 1.0.0 que possibilita um novo nível de interação em páginas web, tornando fácil adicionar os efeitos de estilo Web 2.0 nas suas aplicações. No dia 21 de Julho, o framework Django é lançado depois de ficar em desenvolvimento por mais de 2 anos. Em 4 de Agosto o livro Agile Web Development with Rails, primeira edição foi publicado pela PragProg, novamente escrito pelos agilitas Dave Thomas e Andy Hunt. E foi em outubro de 2005 que o indiano Satish Talim inaugurou o curso online pra iniciantes RubyLearning que está ativo até hoje e foi importante naquela época.

De curiosidade, em 3 de Dezembro teve a Conferência Snakes and Rubies que levou os criadores do Django e do Rails (video) pra discutir sobre frameworks web e os caminhos diferentes que eles tomaram. Naquela época ainda não estava claro quem ia ganhar, mas os motivos que eu já citei antes devem deixar claro porque um foi muito diferente do outro apesar de terem começado parecido. 10 dias depois o Rails 1.0 é lançado. (…) Nós tínhamos alguns dos melhores escritores de blog daquela geração, um dos melhores sempre foi o Ilya Grigorik do blog Igvita e que hoje é engenheiro de web performance do Google. Seus artigos sobre performance no Ruby e Web em geral influenciaram toda a nossa geração e vale a pena reler ainda hoje. Seu primeiro blog post foi ao ar em 28 de dezembro. E assim acaba 2005!

As coisas começam a esquentar em 2006. Primeiro, em março, Jamis Buck que entrou pra equipe Core do Rails renomeia seu projeto SwitchTower pra se tornar o que conhecemos como Capistrano e a forma inédita de automatizar deployment de projetos em máquinas de produção orquestrando via SSH, e essa ferramenta inspiraria diversas outras como o Fabric e Ansible de Python que vieram depois dele. Ainda em março, no dia 21 o Jack Dorsey posta o primeiro tweet: “just setting up my twttr”. 2 dias depois o Eustáquio Rangel lança o primeiro livro de Ruby no Brasil e um mês depois em 5 de Abril eu escrevo meu primeiro post no que viria depois a se tornar o blog AkitaOnRails.com.

Em 22 de Junho acontece a primeira RailsConf em Chicago. E já em 30 de Junho o rubista Hamptom Caitlin sobe o primeiro commit do SASS e inicia uma nova era de meta-linguagens pra tornar possível ser capaz de codar decentemente em linguagens chatas como CSS. Também já em 5 de Julho surge o JRuby 0.9, uma versão de Ruby que roda em cima da JVM e já consegue rodar Rails. Charles Nutter e Tom Enebo continuam firmes e fortes mantendo a linguagem até hoje.

Muito antes de termos a onda de cursos online que temos hoje, a comunidade Ruby on Rails foi pioneira em mostrar como cursos de qualidade poderiam ser feitos e foi Geoffrey Grosenbach que iniciou isso com seu Peepcode, que anos depois seria adquirida pela Pluralsight. Muita gente, incluindo eu, aprendemos muito nos cursos do Geoffrey.

Pra continuar os lançamentos revolucionários, em 25 de Agosto a Amazon Web Services, ou AWS, lança o Elastic Compute Cloud (EC2) e inicia de fato a Era do “Cloud Computing” como conhecemos hoje. No dia seguinte, em 26 de Agosto o John Resig lança o então adorado e hoje denegrido jQuery. Pouco mais de um mês depois em 6 de Outubro meu primeiro livro “Repensando a Web com Rails” saiu da gráfica, o primeiro de Rails publicado no Brasil. Três dias depois em 9 de Outubro, o Ronaldo Ferraz lança o primeiro tutorial de Rails no Brasil. E ainda em Outubro surge o primeiro framework concorrente de Rails escrito em Ruby, o Merb 0.03 que significa (“Mongrel+Erb”).

(video jobs iphone)

E falando em 2007, logo no começo do ano em 9 de Janeiro o mundo da tecnologia recebe um novo marco: o lançamento do primeiro iPhone. Poucos dias depois em 18 de Janeiro é lançado o Rails 1.2 lançado com o lendário RESTful resources e o mundo finalmente aprendeu que HTTP não é só GET e POST e finalmente os outros verbos ganharam uso. Foi neste ponto que mundo Web começou a proliferar a idéia de APIs REST como Roy Fielding publicou no ano 2000 definindo REST. Ruby on Rails se tornou o gold standard em APIs. Em 20 de Fevereiro o Christian Neukirchen define a interface Rack, inspirado pelo Web Service Gateway Interface ou WSGI de Python que foi definido na famosa PEP 333 de 7 de dezembro de 2003.

Em 4 de março o saudoso Ryan Bates lançou o primeiro episódio do videocast chamado Railscasts. Assim como Geoffrey da Peepcode ele criou dezenas de videos curtos sensacionais e muito bem produzidos e editados. Novamente mostrando como videos de programação poderiam ser bem feitos e ensinando toda uma geração de Railers, incluindo eu mesmo. Infelizmente ele parou por volta de 2013. Eu diria que o sucessor espiritual do Ryan hoje é o Avdi Grimm com seu também excelente RubyTapas, cujo primeiro episódio foi ao ar em 24 de setembro de 2012, então ele realmente é quase uma continuação do Railscasts só que voltado ao Ruby em si. Eu recomendo que vocês assinem.

Na renascença das tech startups, começaram a surgir as famigeradas redes sociais, a versão moderna do muro das lamentações. Na melhor fase tivemos Orkut, Friendster e MySpace que já estavam saturados mas o público pedia por mais. Facebook estava só começando a aparecer, não lembro se nesse ano já tinha aberto no Brasil. De repente um grupo que tinha crescido no mundo de blogs com a Odeo resolveu criar um modelo experimental de micro-blogging, que você podia enviar posts via SMS, e por isso tinha o limite de 140 caracteres. E eles resolveram batizar esses micro-posts de tweets, inaugurando também a era de nomes bizarros pra startups. E, mais importante, escolheram Ruby on Rails pra implementar. Claro, ser inspirado pelo framework do blog de 15 minutos pra fazer uma plataforma de micro-blogging fazia todo sentido. Eu abri minha conta em 2007 se não me engano.

Agora, em Abril de 2007 inicia-se a maior infâmia da história até então, a famigerada controvérsia do “Rails não Escala” iniciada por uma comunicação mal feita do Alex Payne, do próprio Twitter. Lembram que eu expliquei que Twitter foi criado como uma plataforma de micro-blogging? Pensa se o Twitter tivesse sido programado em cima do Wordpress. Só que 2 anos depois ele deu certo e milhões de pessoas começaram a usar, só que o uso mudou. Em vez de ser micro blog posts, a plataforma começou a ser usada como um sistema de comunicação, ou seja, de broadcast de mensagens. Claro que nem Ruby, nem PHP, nem Python, aguentariam isso. O problema nunca foi a linguagem, foi a arquitetura.

Só existia uma arquitetura conhecida na época que suportaria o broadcast massivo de mensagens, e se chamava Erlang. Mas ninguém queria ter que usar a sintaxe do Erlang, e por sorte o Odersky tinha acabado de lançar o Scala, com o framework Akka, que copia a arquitetura de atores do Erlang e possibilita usar esse sistema em cima da JVM. Ou seja, o Scala era a coisa mais próxima do Erlang que se tinha e, claro, fazia sentido mudar essa parte do back-end. Não é que o Rails não escala, nenhum outro framework em nenhuma outra linguagem ia escalar. Hoje em dia, pra esse cenário seria Elixir. Essa controvérsia seguiria o Rails por anos (e finalmente nos livramos disso, afinal se você acha que o Rails não escala, olhe pro GitHub, até hoje feito em Rails e usando a última versão)

Em 18 de Maio de 2007 o mundo de testes nunca mais seria o mesmo. Já expliquei sobre a importância de desenvolvimento com testes e como isso foi um gancho importante pra ganhar o apoio dos agilistas ao Rails, mas foi neste dia que o lendário RSpec foi lançado, baseado nas experiências de Steven Baker desde 2005 e com a ajuda de Dave Astels, Aslak Hellesøy que depois criaria o Cucumber, iniciando a era de Behavior Driven Development, e claro o simpático David Chelimsky que a comunidade brasileira adorou conhecer quando eu trouxe nas duas primeiras Rails Summit Latin America em 2008 e 2009. Todos os frameworks de teste na maioria das linguagens modernas que você conhece hoje como o Chai do Javascript é descendente direto do RSpec.

Seguindo na linha dos clones de Rails, ainda em maio de 2007 surge o Framework Play para Java. Em 16 de Maio eu iniciei meu primeiro emprego oficial como Railer full-time na Surgeworks, uma pequena consultoria de Utah. Mais pro fim vou falar da pessoa que se arriscou em contratar um brasileiro numa época em que isso era muito raro. Eu trabalhei remoto por um ano mais ou menos, onde eu finalmente comecei a programar em Rails profissionalmente, aos 30 anos. Só pra relembrar: eu deixei de ser sênior de Java e SAP e voltei a ser júnior e ganhar como júnior.

Por volta de Julho outro nome importante apareceu, o grupo do RailsEnvy com Gregg Pollack e Jason Seifer que contribuíram muito no estilo diferentão dos hipsters de Rails dessa época. Eles aproveitaram a campanha Get a Mac que a Apple agressivamente publicou como comerciais de TV entre 2006 e 2009, no auge da dominância da Apple do Zeitgeist, os famosos comerciais “Hello I’m a Mac ….

(comercial mac vs pc)

Então em 2007 Gregg e Jason fizeram diversos clones desses videos com o mesmo princípio com Rails pra tornar mais divertido a forma como a gente via as demais tecnologias diferentes de Rails que até aquele momento ainda estavam vivendo no passado. E eles fizeram vários videos começando com o famoso Hi, I’m Ruby on Rails … (comercial)

Vocês podem ver os videos no canal de YouTube do Gregg Pollack que vou deixar linkado abaixo. Com o tempo o Gregg e Jason acabaram se separando, o Gregg montou a consultoria EnvyLabs e em paralelo, seguindo nos passos de Geoffrey Grosenbach e Ryan Bates montou o famoso Code School, com uma grade mais estruturada pra ensinar Ruby on Rails e outras novas tecnologias. E foram eles que criaram o conceito de Rails for Zombies que depois outras comunidades, como Python, copiaram também. Não existia comunidade que gerava mais conteúdo técnico do que a de Rails naquela época. O Rails for Zombies foi o primeiro curso do Code School que foi lançado em 2010. E o negócio foi vendido em 2015 também pra PluralSight onde vocês ainda podem achar os cursos.

Em 4 de Outubro tivemos o lançamento inicial do microframework Sinatra, também escrito em Ruby mas que não tinha o objetivo de competir com o Rails, ele era mais focado em micro-aplicações ou mesmo pra ser micro-serviço de APIs; ele é largamente copiado em outras linguagens até hoje. Ainda em outubro, no dia 19 finalmente os rubistas Chris Wanstrath e Tom Preston-Werner começam a trabalhar no GitHub, literalmente de um Starbucks. O Chris tinha o blog Err the Blog e começou criando bibliotecas de Ruby que conseguiam interfacear com Git.

Também em outubro, no dia 22 foi a primeira vez que eu organizei um evento, em São Paulo, o RejectConf SP que teve muitos dos nomes do Ruby brasileiro que você reconhece até hoje como Carlos Brando (CTO do Enjoei), Danilo Sato (ThoughtWorks), Fabio Kung (que foi do Heroku por muitos anos e agora está no Netflix), Vinicius Teles (da HE:Labs), Carlos Villela (que foi da ThoughtWorks por muitos anos e foi pra DigitalOcean), George Guimarães (Plataformatec) e mais. A Caelum do Paulo Silveira estava lá também ajudando com o coffee-break da galera. Vocês estão vendo como as coisas estão acontecendo muito rápido, todo mês, às vezes toda semana estava saindo alguma coisa que influenciaria o mercado pelos próximos anos. Como eu disse no começo, 2004 marcou o início de uma nova era pra Web.

(2008) E pra não quebrar a tradição do ano iniciar com alguma coisa, já no primeiro dia de 2008 tivemos nosso primeiro grande RubyDrama. Era engraçado que antigamente não existia dramas em nenhum lugar, com frequência. Era tão raro na real que quando acontecia a gente chamava de RubyDrama. Notem que dramas só começaram a acontecer com frequência com o surgimento de plataformas como o Twitter. No caso do Ruby em 2008, Zed Shaw, o criador do Mongrel que foi o primeiro servidor de aplicações pra Rails, fez uma declaração bombástica de sua saída, chamando a comunidade Ruby de ghetto. Isso reverberou por um algum tempo. E ele não estava totalmente errado, só que ele não sabia jogar o jogo, o Zed é o tipo de cara tecnicamente excepcional mas de cabeça quente. Mas, todo drama que parece tão importante pra você hoje, alguns anos depois, ninguém mais nem se lembra, e o Mongrel foi rapidamente substituído por outros servidores de aplicação como o Thin, Passenger, Unicorn e depois o Puma que usamos hoje.

Mais importante do que isso, nesse mesmo dia 1o de Janeiro de 2008 foi quando o Heroku recebeu seu primeiro investimento seed de USD 20 mil da Y/Combinator. Esse foi o mesmo ano que eu participei da minha primeira Railsconf nos Estados Unidos. Lá eu conheci o James Lindenbaum um dos fundadores do Heroku. Eles estavam com um estande no evento e ninguém mais se lembra disso mas a primeira versão do Heroku era pra ser uma IDE Web pra desenvolvimento de software. Só que eles viram que isso não ia rolar naquela época. Pense que 10 anos atrás ainda era muito difícil imaginar coisas como o Electron que usamos hoje, o Google ainda não tinha começado a otimizar o Javascript, acho que nem tinha o V8 ainda. Então eles tiraram essa idéia mas ficaram com a segunda parte que era onde os apps iam rodar, a infraestrutura de containers que surgiria muito antes do Docker e que inaugura o primeiro PaaS ou Platform as a Service. Aliás, é disso que nasce as boas práticas do Doze Fatores ou 12 factors pra escalabilidade em 2007, escrito por Adam Wiggins que foi co-fundador do Heroku também. E, claro, Ruby on Rails foi o primeiro framework que estava compatível com os Doze Fatores.

Se você é de Elixir, pra efeitos históricos vale relembrar o projeto Reia de Tony Arcieri, que eu recomendo que vocês sigam porque ele manja muito sobre segurança e hoje em dia Rust. Pra dar perspectiva, o primeiro commit do Elixir do José Valim foi em 9 de Janeiro de 2011. O primeiro commit do Reia é de 21 de março de 2008 e ele é basicamente o Elixir uns três anos antes: uma nova linguagem muito mais próxima de Ruby que compila em bytecodes que executam na VM Beam do Erlang. No fim o Tony perdeu o interesse no projeto e foi fazer outras coisas como a biblioteca Celluloid pra Ruby que hoje é usado pra abstração de concorrência, seja de threads ou I/O assíncrono, inclusive hoje é dependência no Rails.

Já em 2 de Abril o desenvolvimento do Rails sai de Subversion e move seus repositórios pro GitHub, dando credibilidade pra essa ferramenta chamada Git que quase ninguém tinha ouvido falar fora dos grupos de Linux e desenvolvimento do kernel. Por muito tempo 90% dos repositórios que tinha no GitHub eram projetos Ruby e Rails, e todo mundo de fora começou a ficar interessado em testar. Alguns dias depois, em 10 de Abril o GitHub sai do beta e lança publicamente. Hoje em dia vocês nem pensam e basicamente adotam Git, mas nessa época além de Subversion, no mundo open source ainda tinha gente que usava CVS mesmo, e a nova geração ainda estava entre coisas como Mercurial ou Bazaar. Em 14 de Abril foi quando José Valim mandou seu primeiro commit pro Rails, foi o começo de 2 anos de trabalho que o tornou membro do grupo Rails Core em 2010.

Nesse ano eu estava tendo que me virar. Em Junho eu tinha saído da Surgeworks e entrei na Locaweb. Embarquei pra Portland, no Oregon, pra Railsconf com a missão de conseguir integrar com a comunidade de lá e organizar o primeiro grande evento de Rails no Brasil, na América Latina na real. Com cerca de 3 meses só pra organizar tudo do zero, em 15 de Outubro tivemos o Rails Summit Latin America 2008, no Auditório Elis Regina do Anhembi em São Paulo. Deu bastante trabalho mas os nomes que eu consegui trazer muitos vão reconhecer até hoje como Chad Fowler, um dos rubistas originais no Ocidente, fundador da Rubyconf, meus amigos Ninh Bui e Hongli Lai da Phusion que desenvolveram o Passenger, um dos servidores de aplicação tipo o Puma de hoje, o David Chelimsky que contribuía no projeto RSpec e Cucumber, o Chris Wanstrath, fundador do GitHub, o Dr. Nic, o Obie Fernandez e mais. Ninguém achava a) que um evento desses fosse possível, nem b) que ele seria consistente e duraria quase 10 anos! Nessa primeira edição acho que já conseguimos juntar mais de 400 pessoas.

Outro acontecimento que vale lembrar nesse ano foi em 2 de setembro quando o Google finalmente lança o venerado e hoje temido navegador Chrome junto com a engine de Javascript mais importante de todos os tempos, o controverso V8, que vai dar início ao atual ecossistema Javascript. Pare um instante pra considerar isso se você for iniciante. A Apple se inspirou no Konqueror do KDE, fez fork e transformou o componente KHTML no WebKit. Daí o Google tinha contratado engenheiros do Firefox alguns anos antes mas eles nunca se acharam na posição de empurrar um novo navegador, mas chegaram num ponto que fez sentido começar com o WebKit como fundação e, no melhor estilo Google, fazer um deles parecido a partir de um fork em 2013.

Pra fechar bem o ano, em 23 de Dezembro tivemos o merge dos projetos Rails e Merb e a equipe do Merb se junta ao Rails core team. Lembram o RubyDrama do começo do ano do Zed Shaw? Ele tinha meia razão, sempre existiu um grupo fechado pra discutir o desenvolvimento do Ruby on Rails, e isso não é nenhum problema, o DHH sempre quis ser como um Steve Jobs, ele controla o Rails com mãos de ferro, e não só o código mas tudo relacionado ao “produto” Ruby on Rails, como a marca, o nome, os eventos e tudo mais. Certo ou errado, ele owna as decisões em vez de se esconder atrás de um comitê. Isso é integridade conceitual que todo projeto precisa: um ditador benevolente. Gostem ou odeiem, foi o que manteve o Rails intacto até hoje.

Mas deixa eu explicar esse episódio, só pra ter registrado. Durante essa bolha de interesse explosivo em cima de Ruby on Rails, alguma empresas foram fundadas pra suportar a infraestrutura de startups que cresciam do nada como Twitter ou GitHub, especialmente depois da famigerada controvérsia do Rails não escala do Alex Payne. Uma dessas foi a Engine Yard, que estava competindo com a AWS e Rackspace. Pense que em 2008 a AWS só existia fazia 2 anos e nem todo mundo ainda tinha entendido essa idéia de máquinas virtuais voláteis cobradas por uso. Ainda dava pra pensar em competir com a AWS. A Engine Yard foi fundada por pessoas excepcionais, em particular o EZRA ZYGMUNTOWICZ, super gente boa que eu conheci em 2008 também. Ele era genial, tanto como programador, como quanto infra.

Por exemplo, na época ele criou um sistema de deployment em máquinas físicas usando o protocolo Jabber que se usa em instant messager. Pensa você abrir faz de conta, um whatsapp de hoje em dia, e falar com sua infraestrutura e mandar ordens como atualizar as máquinas ou deployar apps, em 2008! Além disso ele foi o único que enxergou como fazer um concorrente de verdade pro Ruby on Rails, dado sua experiência com hardware e otimização de Linux, ele começou fazendo patches no Rails e no Mongrel e eventualmente criou o Mongrel ERB, um software que tira o Rails da equação. Em vez de fazer só mais um micro-framework, ele resolveu competir pau a pau e fez um Rails que muitos argumentariam que era melhor, esse foi o Merb.

A equipe que a Engine Yard montou contou com programadores como o Yehuda Katz e Carl Lerche pra acelerar o desenvolvimento do Merb. Tudo isso enquanto ele estava montando um data center, carregando servidores nas costas, montando rede, e ajudando outras tech startups a escalarem seus projetos em Rails. Então eles rapidamente criaram uma excelente reputação. Eles eram um dos maiores patrocinadores da Railsconf. Só que o erro foi que eles começaram a evangelizar o Merb agressivamente demais. Tipo, eles iam nas Railsconf falar mal do Rails e ofereciam o Merb como opção. Eu disse que o DHH queria ser o Steve Jobs? Saibam que a Railsconf só pode acontecer com o aval dele, porque a marca Ruby on Rails é trademark do DHH e o evento também. Imagina se na Macworld aparecesse um palestrante falando que Mac é um lixo, na frente do Steve Jobs. …. Pois é, o DHH ficou furioso com isso e eu soube de uma conversa dele com o Tom Mornini, um dos co-fundadores e na época CTO da Engine Yard. Eu estava online pouco depois que isso aconteceu falando com o Matt Aimonetti, outro core developer do Merb na época e o autor do post de reconciliação anunciando que o Merb seria mergeado no Rails.

Eu não estava fisicamente na sala ouvindo, então não me citem, mas do que eu ouvi foi um ultimato do DHH pro Tom Mornini. Ou vocês páram com essa palhaçada de falar mal do Rails, na Railsconf, que inclusive é o seu sustento já que vocês atendem clientes de Rails, ou vamos “ter problemas”. Isso seria péssimo problema de relações públicas num estágio onde eles provavelmente ainda estavam no vermelho, procurando mais investidores e mais clientes. Então no final a Engine Yard cedeu à pressão e anunciou parar o Merb. Foi assim que o Yehuda Katz, Carl Lerche e Matt Aimonetti entraram pro grupo Rails Core Team e foi assim que o Merb morreu e nasceu o Rails 3.0. ufffff

(2009) Com toda essa controvérsia “resolvida” por enquanto, podemos começar o próximo ano, 2009 em 16 de Março com o lançamento do Rails 2.3; agora sendo uma aplicação Rack. Finalmente, só agora, 7 anos depois do lançamento do framework baseado em I/O assíncrono Twisted do Python, em 27 de Maio temos o lançamento inicial do Node.js graças ao V8 lançado um ano antes. Ela permite que programadores escrevam Javascript client side e server side, pela primeira vez desde o falecido Netscape Livescript nos anos 90. E só pra colocar um pé do Rails até nisso, Ryan Dahl mesmo disse que foi inspirado pelo parser do Mongrel de Zed Shaw pra fazer o Node.js.

Em 13 de Dezembro, Jeremy Ashkenas sobe o primeiro commit do Coffeescript, um dos primeiros transpilers pra tentar tornar programar em Javascript algo mais agradável. Lembrando que nesta época ainda não tínhamos nem sinais do ES6 e Javascript pré-ES6 era um pesadelo de se usar. Na época o Coffeescript era excelente pra se trabalhar, ele inventou o conceito de fat arrows pra funções anônimas, interpolação de strings e muito mais que hoje você tem no ES6, então é muito fácil odiar o Coffee hoje sem saber como era em 2009. O Coffeescript serviu seu propósito em ajudar a evoluir o Javascript.

Virando mais um ano, por volta de abril de 2010 Steve Jobs publica o prego no caixão do Adobe Flash com o artigo Thoughts on Flash e sedimenta o caminho para HTML 5 + CSS 3 + Javascript não só em dispositivos móveis mas também em desktops. O Flash se tornou um morto-vivo desde então. A intenção original de Jobs era empurrar o então melhor navegador com o então melhor engine Javascript que era o Safari no Mac e agora no iPhone como uma plataforma para criar aplicações web. Eu diria que foi Jobs que sem querer tornou mainstream o conceito de Single Page Apps e o primeiro framework javascript a oferecer isso foi o hoje defunto SproutCore que deixou descendente na forma do atual Ember, que foi criado pelo mesmo Yehuda Katz que trabalhou no Merb da Engine Yard e também no Rails 3.0 e resolveu o problema de dependências do Ruby com a introdução do Bundler, que se tornaria referência pra todas as ferramentas de gerenciamento que vieram depois dele como Hex do Elixir, Cargo do Rust, Npm e Yarn no Javascript e assim por diante.

Esse negócio de dois frameworks se unificarem e só sobrar um, como o próprio Yehuda lembrou na época, já tinha acontecido outras vezes. No mundo Java o Struts 2 foi um merge com outro framework, o WebWork que se vendia como “Struts feito direito”. Em 1o de agosto de 2010 é lançado o Rails 3.0 com contribuições do Merb core team; um ano desde o lançamento do Rails 2.3. O que sobrou da comunidade Merb viu as promessas de um caminho de migração e a idéia de que o Rails se tornaria mais próximo das idéias do Merb se esvair. E esse foi o fim dessa história.

2011 foi outro ano interessante, em 12 de Julho o Criador do Ruby, Yukihiro Matsumoto (Matz) e outros membros do Ruby Core, são contratados pelo Heroku. Em 31 de Agosto o Rails 3.1 é lançado e o jQuery substitui o antigo Prototype como padrão. E em 19 de Setembro eu anunciei a criação da minha primeira empresa de desenvolvimento de software própria, a Codeminer 42. Aqui se iniciaria uns 4 anos de pesadelo na minha vida, vocês não tem idéia de como doeu criar uma empresa do zero, bootstrapped, sem investimento externo, pra crescer de forma sustentável e ser lucrativa. Felizmente já faz uns 3 ou 4 anos que as coisas tão super bem, graças a de … graças aos esforços incessantes de quem trabalhou nesses últimos anos na empresa.

Finalmente, em Novembro de 2011 outro produto importante foi lançado, o Travis-CI, fundado por rubistas como Josh Kalderimis, Konstantin Haase, Sven Fuchs e outros, em Berlin, na Alemanha. Eles conseguiram finalmente produtificar o conceito de integração contínua. Não só isso como ofereceram um serviço gratuito pra projetos open source que se integra diretamente no GitHub e pela primeira vez projetos de software livre tinham a opção de demonstrar seu nível de testes diretamente na primeira página dos repositórios. Vocês podem ver que nós rubistas originais levávamos testes realmente a sério.

Só de bônus, foi também em 2011 mas não achei a data que Bryan Helmkamp criou o CodeClimate pra automatizar ferramentas de análise de código como Rubocop, Flay, Brakeman e outros, se integrando ao GitHub pra demonstrar como anda a saúde de nosso código. A partir desse ponto fomos refinando mais e mais nosso cinto de utilidades de qualidade de código Ruby e demos o exemplo pra todas as outras comunidades. Nenhum até hoje conseguiu chegar no mesmo nível obsessivo de qualidade que nós das primeiras gerações de Railers quisemos alcançar.

Vou parar a cronologia por aqui, veja que estou parando 8 anos atrás, mas acho que vocês podem ver como os acontecimentos do mercado em geral e do Ruby on Rails a esta altura já tinham mudado o mundo de desenvolvimento de software. Novas linguagens começaram a surgir, muitos influenciados por Ruby. Novos frameworks começaram a surgir, muitos influenciados por Ruby on Rails. O fluxo de trabalho havia sido já fundamentalmente mudado graças à adoção das práticas ágeis de extreme programming, Os conceitos de produtos Web 2.0, adoção de SaaS, PaaS, mundo cloud e tudo mais derivou dessa geração de Ruby on Rails entre 2004 e 2011. E em 2011 ainda estamos 2 anos antes do Docker ser lançado pela primeira vez, essa história é longa.

Lá no começo, em 2008 eu comecei a entrevistar diversos rubistas e outros desenvolvedores e publiquei no meu blog. Se você é de Microsoft vai saber quem é Scott Hanselman, leia a entrevista no blog. Adrian Holovaty o criador do Django de Python? Tá no blog também. Criadores de conteúdo como Geoffrey Grosenbach que na época tocava o Peepcode e o Peter Cooper que na época tocava o Ruby Inside? Tão no blog também. Depois da controvérsia que o Alex Payne do Twitter causou com o Rails não Escala eu entrevistei um dos primeiros engenheiros do Twitter, o Blaine Cook, confira no blog. Membros fundadores do Ruby Central e os primeiros rubistas, Chad Fowler, David Black depois Evan Phoenix do projeto Rubinius e Ruby Specs, tão no blog. Rails Core Team Alumni como Jamis Buck e Josh Peek, também tão lá no blog. Enfim, vou deixar a página com as entrevistas linkadas nas descrições abaixo.

Durante esse período entre 2008 e 2016 eu tive a oportunidade de trazer muitos dos principais nomes pra cá incluindo os fundadores do Ruby Central como Chad Fowler, David Black e Rich Kilmer, depois Evan Phoenix. Trouxe gente do Rails Core da época como Matt Aimonetti, Aaron Petterson que é o Tenderlove. Fundador do GitHub Chris Wanstrath, depois Scott Chacon. O Konstantin Haase do Sinatra e Travis-CI. E na última tivemos gente do Ruby Core Team do Japão com a presença de Akira Matsuda. E falando em última, foi no dia 25 de setembro de 2016, que depois de 10 anos organizando eventos de Ruby, eu decidi pendurar as chuteiras.

Como tudo que eu faço fora do meu trabalho principal, eu nunca lucrei nada com os eventos. Vamos dizer que como gerador de conteúdo eu dou um péssimo empresário, porque meu primeiro livro de Rails eu escrevi sem ganhar um centavo porque abri mão dos royalties pra baratear o custo, o objetivo era fomentar o mercado. O blog eu até experimentei colocar ads por um tempo mas era muito feio então desisti e nunca monetizei. Os podcasts que eu fazia com Carlos Brando ou o Rosa nunca monetizei. A Rubyconf eu nunca tive nenhuma compensação financeira. E agora fazendo videos, eu também não monetizo.

Faz mais de 10 anos que eu gero conteúdo de graça e espero poder continuar fazendo isso. E eu não faço isso porque eu sou um cara legal, pelo bem disso ou pelo bem daquilo. Eu só faço assim porque eu quero. O dia que eu não puder, eu páro. Na minha cabeça eu sempre tive uma noção que se meu conteúdo fosse atrelado a um incentivo financeiro, isso ia me comprometer demais. Isso já aconteceu antes, quando tinha patrocinador ou grupos externos envolvidos. E não tem nada que me irrita mais do que eu não poder falar alguma coisa porque certos grupos não iam gostar. Por isso eu prefiro pagar as coisas do meu bolso pra nunca ser usado como plataforma pros outros.

Quando anunciei minha aposentadoria da Rubyconf Brasil, eu achava que finalmente ia conseguir passar um ano sem ter que pensar em eventos… ledo engano. Em dezembro de 2016 uma idéia apareceu do nada na minha cabeça, eu juro que tentei tirar essa idéia da cabeça, mas aí eu e meu sócio começamos a montar a conferência experimental The Conf, mas isso é história pra outro dia. Agora em 2019 estamos na 3a edição da The Conf, crescendo um passo de cada vez, como aconteceu com a Rubyconf Brasil. Um dia eu juro que páro de fazer eventos. E, de novo, eu quero que o evento seja o mais independente possível, basicamente eu e meus sócios pagamos praticamente tudo.

Essa história pra mim começou numa quarta-feita a noite em abril de 2006 quando eu me dei conta que quase ninguém no Brasil inteiro tava dando a mínima pra Ruby on Rails ou sequer sabia o que era isso. Eu nunca tinha visto algo assim antes: a tecnologia certa, com os conceitos certos, tudo pronto, e todo mundo ignorando. Eu tinha duas escolhas, me mudar pra São Francisco e tentar a vida em tech startup de Rails, ou tentar começar do absoluto zero no Brasil. Obviamente escolhi a segunda opção e foi assim que eu comecei, com zero seguidores, zero views, zero empresas e zero emprego.

Preciso agradecer muito meu primeiro chefe de Rails, o Carl Youngblood que achou meu blog lá no começo e me mandou uma oferta de trabalho remoto pra Surgeworks. A coincidência é que o Carl foi missionário no Brasil. Ele é mórmom de Utah. E ele fala português brasileiro quase perfeito, com sotaque brasileiro e tudo, foi muito bizarro ver um gringo falar melhor português do que eu falo inglês. E foi assim que me tornei o primeiro brasileiro da equipe e pra onde eu levei diversos nomes que você deve conhecer hoje como Carlos Brando, o Rodrigo Kochenburger que mencionei no começo, o Marcos Tapajós do Rio de Janeiro, o Renato Carvalho de Brasília que depois fundou a Startaê e vários outros.

Com a missão de evangelizar Ruby e Rails no Brasil eu embarquei numa jornada de palestras por todo o Brasil, fui pra Natal, Teresina, Brasilia, Fortaleza, Campos no Rio, Xanxerê, Londrina, Porto Alegre, Curitiba, Salvador, Rio de Janeiro, São Carlos, Campo Grande, além de ter tido a oportunidade de fazer amigos como o Nihn e Hongli da Phusion na Railsconf de Portland em 2008, ter ido pra Las Vegas pela primeira vez na RailsConf 2009, ter conseguido palestrar pela primeira vez num evento internacional na RailsConf 2010, onde eu conversei pela primeira vez com o DHH, com o Bob Martin e muitos outros, e de lá fui palestrar em Buenos Aires na Locos x Rails, em Moscow, em Amsterdam, em Tel Aviv em Israel que certamente foi um dos países mais fascinantes que eu já conheci, e finalmente em Tokyo em 2011 onde eu pude conhecer o grupo por trás do desenvolvimento do Ruby, incluindo seu criador, o Matz, que assistiu minha palestra sobre como a comunidade de Ruby cresceu no Brasil. Ao longo de 10 anos eu devo ter dado umas 200 palestras no Brasil e no mundo, foi uma jornada absurda que eu não imaginava que pudesse acontecer naquela quarta feira a noite em 2006.

Não podia deixar de relembrar os rubistas que nós perdemos. O Jason Seifer, que foi parceiro de Gregg Pollack no RailsEnvy nos deixou em abril de 2017. O excelente blogueiro de Ruby e criador de bibliotecas como o resource controller original, anterior ao inherited resources nos deixou 3 dias antes de acabar 2014. Ezra Zygmuntowicz nos deixou em Dezembro de 2014. O simpático e saudoso Jim Weirich que inspirou toda uma geração a se importar com testes nos deixou também em 2014, em fevereiro. 2014 foi um ano ruim onde, por diversas razões, perdemos excelente pessoas na nossa comunidade.

Falando em Jim Weinrich se você gosta da linguagem Ruby devia se exercitar num de seus legados, o site Ruby Koans com diversos exercícios diferentes do que vocês está acostumado e que vai te fazer pensar bastante. E na mesma linha temos o Ruby Quiz do James Edward Grey II com mais dezenas de exercícios. São excelentes opções pra você que quer juntar seus amigos pra aprender Ruby, como desenvolver com TDD, no formato de Dojo.

Ruby on Rails já completou 15 anos. Foi uma década e meia de mercado e até hoje ainda temos um mercado enorme, onde rubistas ainda estão entre os desenvolvedores mais bem pagos do mercado e onde o framework ainda é o pacote mais completo, tanto do ponto de vista do framework em si e do ecossistema que se formou ao redor. É o pacote mais pragmático pra montar uma tech startup, salvo raras exceções em componentes especiais que podem ser feitos em Elixir ou Go. Mas se você não quer ter dores de cabeça, você ainda escolhe Ruby on Rails. E se precisa de exemplos, não precisa ir muito longe, o GitHub que você talvez já use todo dia é Ruby on Rails, o gigante Shopify foi um dos primeiros a usar Rails e usa até hoje, o AirBnb é Rails, Kickstater é Rails, a Bloomberg ainda usa Rails, o Twitch usa Rails, Zendesk é Rails, Hulu que foi adquirida primeiro pela Fox e agora pela Disney é Rails.

Uma das coisas que muita gente critica é que Ruby on Rails é um framework que se tornou quase um monopólio dentro da comunidade Ruby, temos alguns micro-frameworks como Sinatra e outros menores que tem seu lugar, mas depois do incidente do Merb, nunca mais outro framework chegou perto de competir. Muita gente usa isso pra dizer como em Java, PHP, Javascript tem muito mais opção. Só que isso é um problema na verdade, porque todo mundo pega uma escolha diferente e isso fragmenta a comunidade. Agora você como desenvolvedor muda de empresa, vai encontrar um projeto com bibliotecas e estruturas e estilos completamente diferentes. Toda vez você tem uma curva de aprendizado maior e você nunca realmente domina, é o caso de virar um Jack of all trades, master of none. Como em Ruby, todo projeto em Rails é parecido, quando você muda de empresa, encontra o mesmo ambiente e já é produtivo imediatamente. Por isso andamos tão rápido em tão pouco tempo, porque além disso todo o ecossistema de bibliotecas, produtos e soluções só precisava focar num único framework e com isso nasceu Heroku, Travis, CodeClimate, New Relic.

Levou anos pras outras comunidades começarem a entender um pouco disso e agora no Python meio que Django é a escolha padrão, em PHP o Laravel é a escolha padrão, em Elixir o Phoenix é o padrão, em Crystal o Lucky ou Kemal são padrão, no Java não tenho certeza se Play ou Spring é mais usado, no Go não tenho idéia de qual é padrão mas acho que não tem, são várias opções, em Javascript nem me pergunta, não quero nem pensar nessa zona.

A única outra comunidade na época que pôde usufruir desse fator, pelo bem ou pelo mal, foi o ASP.NET da Microsoft. A diferença é que o ASP.NET original era baseado nos paradigmas que tínhamos no J2EE do fim dos anos 90 e que foi justamente o que o Rails veio combater em 2004. E em 2004 nenhuma outra linguagem tinha opção parecida. Levou anos e anos até finalmente chegarmos no estágio de hoje, onde todo mundo finalmente está trabalhando mais ou menos “on Rails” que quer dizer com foco em qualidade, em entregar valor, em usar as práticas ágeis, usando essa geração de SaaS e IaaS com bons repositórios de código como GitHub ou GitLab, bons gerenciadores de projeto especialmente os derivados do Pivotal Tracker, embora os derivados de Trello também quebrem o galho, boas soluções de deployment de Heroku a soluções da AWS. E até a Microsoft cedeu e com o ASP.NET MVC ele se aproximou dos paradigmas do Ruby on Rails também.

O modelo de desenvolvimento de software se divide em antes e depois de 2004. E tudo que construímos nos 10 anos seguintes até 2014 é o que usamos até hoje em 2019 como o estado da arte. Eu queria falar dos últimos 8 anos desde 2011 mas vou parar por aqui e quem sabe retomar num próximo episódio, mas o objetivo de hoje era registrar o que eu lembro que foi importante pra mim no começo da história e qual foi a importância do surgimento do Ruby on Rails e porque vai ser muito difícil algo parecido acontecer de novo: o DHH teve a sorte de lançar o produto certo na hora certa, com diversos acontecimentos por todo o mercado convergindo no tipo de solução que ele apresentou. O produto certo, feito com os princípios corretos, escolhendo as tecnologias e paradigmas que mais tinham chance, e conseguindo convencer o grupo certo de pessoas, inspiradas pela vontade de se expressar com código em vez de só seguir patterns chatos corporativos e fazer produtos enterprise que ninguém ligava.

Mas sendo muito honesto eu acredito que a influência do Ruby on Rails foi até mais ou menos 2012. Depois disso finalmente as demais comunidades adotaram práticas similares e apareceu uma nova classe de problemas pra resolver. O tipo de coisa que você precisa pra ter um Whatsapp, Discord, Hangouts, Facebook Messenger. Eu diria que é onde o problema original do Twitter finalmente atingiu o mainstream e realmente passamos a resgatar o modelo do Erlang em outras linguagens como Clojure, Go, Elixir, e o meio tapa buraco que foi Node.js pra esses casos. Depois de 2012 que as linguagens mobile se modernizaram com Swift e Kotlin. E também foi depois de 2012 que o Docker apareceu e a conversa sobre devops ganhou um level up culminando com o surgimento de ferramentas e plataformas como Terraform e Kubernetes.

Com tudo isso dito, missão cumprida! Por hoje eu fico por aqui. Se ficaram com dúvidas mande nos comentários abaixo, se curtiram mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê semana que vem, até mais!

[Akitando] #37 - A Dimensão do TEMPO para Iniciantes em Programação | Série "Começando aos 40"

Wed, 30 Jan 2019 17:00:00 -0200

Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal Akitando. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.

Descrição no YouTube

Este é o 2o episódio da série “Começando aos 40” e hoje quero ajudar a aliviar um pouco a ansiedade dos programadores iniciantes.

Começando agora você não sabe por onde começar. Devo aprender mobile? Devo aprender Web? Se for Web, devo aprender PHP? Ou então Java? Mas e Machine Learnine? E Big Data?

Antes de tentar explicar um pouco desses assuntos vocês precisam entender como chegamos até aqui.

Mais importante, entender porque fazer planos de longo prazo nesta carreira e fixar “ideais” pode não ser uma boa idéia.

É um tema meio “abstrato” mas eu acredito que antes de começar de verdade, seja você um jovem de 20 ou um novo-jovem de 40, vocês precisam entender a dimensão do “TEMPO” na nossa carreira.

Script

Olá pessoal, Fabio Akita

Fiquei muito contente com a recepção do primeiro episódio desta mini-série. Se você ainda não viu clique no link acima e não deixe de ler as histórias das pessoas que comentaram. Recapitulando, a idéia dessa série veio porque me perguntaram, como uma pessoa de 40 anos poderia ingressar neste mercado. Seria muito fácil mandar meia dúzia de links de cursos online e cagar regra do tipo “eu acho que você tem que estudar Python ou Javascript”. Mas ser um programador profissional é muito mais do que isso.

No episódio de HOJE eu quero falar sobre um assunto que alguém de 40 anos provavelmente já tem mais noção e contrastar com alguém de 20 anos que está começando agora. O fator TEMPO. Eu detesto dizer dessa forma porque me faz me sentir MUITO velho, mas preciso pontuar o fato que a maioria dos jovens ainda não tem noção do que TEMPO significa. Vou explicar.

(…)

O tempo é realmente relativo. Mas em outro sentido. Vamos pegar o caso de uma pessoa com 20 anos. Significa que na sua cabeça o conceito de “minha vida inteira” tem 20 anos.

Pra ser mais prático, eu diria que a maioria das pessoas pode desconsiderar os primeiros 10 anos porque era só um bebê ainda, sem muita consciência de si mesmo e do mundo ao redor. Então, na realidade, o que você chama de “sua vida inteira” é a segunda metade: um período extremamente curto de 10 anos.

Se você tem 20 anos agora, nasceu entre 1998 e 1999. Aliás, como alguém twitou no ano novo, este ano marca o fim de todas as crianças ou menores de idade que nasceram no século XX. Todo mundo que tem menos de 18 anos já nasceu no século 21!

Na sua cabeça, 10 anos pode parecer um tempo longo, muito longo, e é lógico, afinal “sua vida inteira” foram só esses 10 anos. Agora, se você é como eu e já está nos 40 anos, então nós já vivemos o equivalente a 2 vidas a mais. Conseguem entender essa dimensão? Tudo aquilo que você de 20 viveu, aprendeu, sofreu, riu e chorou, coube em 10 anos. Nós de 40 vivemos isso 3 vezes já! E o que dizer de quem já tem 50 ou 60 anos? Não vou especular porque eu ainda não cheguei lá, mas a vida é bem mais longa do que parece.

Você de 20, tente se imaginar voltando aos 10 anos de idade, com todas as memórias dos 20, e tendo que repetir tudo de novo mais 2 vezes. Agora vem a primeira armadilha que você vai enfrentar na sua vida: nós somos matematicamente ruins, eu vou falar sobre matemática em outro episódio, mas por hoje só aceite o seguinte: você está pegando “sua vida inteira” de meros 10 anos e projetando no futuro até os 40 ou 50 anos achando que é possível imaginar como você vai ser. Mas isso é impossível.

Aos 20 você está só idealizando seu futuro. Fantasiando. E é tudo uma ilusão. Praticamente nada do que você está projetando pro seu futuro vai se concretizar do jeito que você imagina agora. E se quando chegar aos 40 você olhar pra trás e disser “sim, tudo aconteceu exatamente como eu tinha imaginado aos 20 anos” eu sinto dizer que você provavelmente limitou muito suas opções e viveu muito abaixo do seu potencial.

Veja a razão inicial desta série: dar dicas a pessoas de 40 anos mudando de carreira. Ninguém com 20 imagina que, 20 anos depois, vai estar fazendo uma virada de 180 graus na vida.

Novamente, eu estou generalizando. Cada um teve histórias e circunstâncias muito diferentes, e lógico que é impossível cobrir todos os casos. Mas o fato é que você está congelando sua situação e a situação do mundo ao seu redor e imaginando que o mundo no futuro vai ser mais ou menos parecido com o que é hoje. Você as notícias de possível recessão no mundo, conflitos na faixa de Gaza,a destruição da Venezuela, fome, pobreza, manifestações. E você acha que o mundo sempre foi assim e que sempre vai continuar sendo. Foi o motivo de porque eu falei sobre Hans Rosling no meu vídeo “O mundo hoje é pior?” que você pode assistir clicando no link acima. Mas spoilers: não o mundo está constantemente melhorando. Você vai ter MUITO mais oportunidades amanhã do que tem hoje. Não só um pouco, você vai ter oportunidades inimagináveis e isso vale pra você de 20 e pra você de 40.

Vamos fazer um exercício pra demonstrar isso. Digamos que você tivesse 20 anos em 1985. Nesse ano estávamos saindo da ditadura militar. Estávamos com uma hiperinflação absurda no Brasil que destruía todo nosso poder de compra. A Guerra Fria ainda era uma coisa real. A revolução dos microcomputadores male male tinha 10 anos nesse ponto, os micros mais potentes dessa época eram coisas como o Commodore 64, com poderosos 64 kilobytes de RAM! Modems ainda não eram difundidos e a Internet basicamente não existia. Linux não tinha sido inventado ainda. Windows ainda não existia. MS-DOS ainda era uma novidade. Nessa época assistíamos filmes em fitas Betamax, usávamos fitas cassette e vinil ainda pra ouvir música.

Digamos que o você de 20 anos em 1985 decidisse seguir carreira de programador. Você aprenderia Basic, aprenderia C, talvez Cobol em alguma grande indústria, em breve você estaria aprendendo coisas novas como dBase III ou Clipper ou Dataflex.

Agora vamos pular pra 1995, ano que eu entrei na faculdade e tinha 18 anos. O Plano Real estava sendo um razoável sucesso nesse ponto, tínhamos quase paridade de 1 pra 1 com o dólar, e com a abertura dos mercados na época do Collor em 1991, podíamos importar muita coisa nessa época. O mundo estava diferente já, com a queda do muro de Berlin e o fim da União Soviética também em 1991, as coisas estavam caminhando bem apesar de outras guerras acontecendo como no Iraque de Sadam Hussein. O Windows 95 tinha acabado de ser lançado. A internet comercial estava só começando com cerca de Um Porcento da população experimentando a “ultra” velocidade de modems discados de Cinquenta e Seis kbps. Muitas novidades estavam sendo lançadas nesse ano, como os primeiros navegadores como Netscape, linguagens como Delphi e Java e LiveScript que viraria Javascript. O famoso Macromedia Flash iria sair só no ano seguinte.

Digamos que o você de 20 anos em 1995 decidisse seguir carreira de programador. Você provavelmente iria pro lado de Visual Basic, Visual C, Borland C++, Borland Delphi, talvez quisesse tentar uma carreira em ambiente Unix como Solaris e Java da então amada Sun, ou com minicomputadores IBM programando REXX em OS/2. Web sequer era uma carreira de verdade ainda. Sabe o dBase ou Clipper ou Dataflex de 10 anos atrás? Já estavam no caminho de queda.

De 1995 vamos pra mais 10 anos no futuro, agora você tem 20 anos mas no novo século, em 2005. O mundo era um lugar muito diferente depois do atentado terrorista de 11 de setembro. Nesse momento o mundo web já tinha chegado chegando e explodido na bolha das ponto e muitos até duvidaram sobre o futuro da internet. As redes sociais tinham acabado de começar, Orkut, Friendster, MySpace. Ruby on Rails tinha acabado de ser lançado e ninguém estava dando muita bola. Flash se tornou ubíquito. Estávamos ainda a pelo menos 1 ano da Amazon lançar o AWS, YouTube, Instagram, Pinterest, nada disso existia ainda, e nessa época a Apple já tinha se levantado das cinzas, dominado o mundo com seus iPods, e estava pra iniciar a migração dos processadores PowerPC pra Intel, abrindo o caminho pros desenvolvedores adotarem Macs pra programar.

Digamos que o você de 20 anos em 2005 decidisse seguir carreira de programador. Você provavelmente iria pro lado de C# ou Java ou PHP ou fazer sites em Flash e Wordpress. Navegadores eram todos incompatíveis e coisas como JQuery viraram necessidade na briga entre Firefox e Internet Explorer. O Google Chrome ainda seria lançado só daqui 3 anos, nem o Gmail tinha sido lançado ainda. Sabe o Visual Basic e Delphi e a Borland de 10 anos atrás? Já estavam no caminho de queda.

Nosso último salto é de 2005 pra 2015, mais 10 anos. O mundo mudou completamente pra nós. Passamos por uma das maiores crises econômicas entre 2008 e 2009 que quase levou o mundo financeiro ao colapso. Ao mesmo tempo as redes sociais se consolidaram, Facebook saiu na frente dominando e vários outros como Orkut e MySpace ficaram pra trás. A Apple surpreendeu o mundo lançando o iPhone em 2007, o Google lançando o Android pouco tempo depois e de repente todo mundo já tinha smartphones nos bolsos, uma das adoções de tecnologia mais rápida da história.

A Amazon trouxe o conceito de infraestrutura como serviço e somando ao mundo de smartphones criamos o conceito de “Cloud”. Também por causa do surgimento do mundo mobile e das redes sociais começamos a falar sobre Software as a Service ou SaaS e o mundo de escalabilidade, concorrência e de repente tínhamos mais dados do que poderíamos jamais precisar e inventamos mais ferramentas como a categoria NoSQL de bancos de dados como MongoDB, Redis, Cassandra. E tivemos uma explosão em novas linguagens como Scala. Javascript começou a ganhar relevância quando Steve Jobs matou o Flash e agora todos queriam Apps.

Também de repente todo mundo precisou rebuscar Objective-C pra programar pra iPhones, Javeiros ganharam nova casa em Android, o mundo C# ganhou um boost também em gaming com iniciativas como Unity. Depois de zonear o mundo, Steve Jobs acabaou morrendo em 2011 e com ele as inovações da Apple. A Microsoft finalmente voltou aos eixos com o Windows 10 e a linha Surface. Certamente esses 10 anos foram um dos mais movimentados na nossa história.

Digamos que o você de 20 anos em 2015 decidisse seguir carreira de programador. Você provavelmente estaria ferrado em escolher entre tantas opções. E eu provavelmente estou ferrado também pra explicar mais sobre isso em outros episódios. E isso porque eu nem vou mencionar tudo mais que surgiu entre 2015 e hoje, meros 4 anos.

E vocês acham que a história terminou? Vamos voltar pra década entre 1985 a 1995. Nessa época jovens programadores gostariam de estar escrevendo em revistas especializadas da época como Micro Sistemas ou escrever livros de papel mesmo. Entre 1995 e 2005 acho que muitos estavam fazendo seus websites pessoais, gerenciando grupos de Orkut, e começando a explorar esse troço novo chamado Blogs. De 2005 a 2015 que surgiram vários outros canais como redes sociais, YouTube e cursos online. Agora todo mundo se tornou um semi-profissional nessa nova categoria chamada geração de conteúdo.

Portanto um jovem de 20 anos em 1985 ou 1995 que era o meu caso, jamais poderia imaginar até onde iria a revolução dos microcomputadores e que uma parcela considerável da população mundial teria computadores, muito menos conectados à internet 24 horas por dia. Não poderíamos imaginar que teríamos smartphones e que uma parcela considerável da população mundial teria smartphones. Não poderíamos imaginar que filmes, músicas, livros e todos os conteúdos estariam disponíveis em serviços como Netflix e que um terço do volume de dados trafegados na internet seria deles. Não poderíamos imaginar que as pessoas teriam a opção de se tornar blogueiras ou virar celebridades num canal que viria a ser maior e melhor do que a TV no caso do YouTube. E, no caso de nós programadores, não era simples de imaginar que cada nova linguagem que aprenderíamos numa década se tornaria obsoleta já na década seguinte e teríamos que aprender mais e mais linguagens e tecnologias novas. Entenderam agora porque eu constantemente falo tanto sobre “Aprendendo a Aprender”?

Pra você que tem 20 anos e está entrando agora numa carreira que envolve tecnologia. Veja meus vídeos sobre “Sua Linguagem NÃO É especial”. Apaixone-se pelo processo de aprender e usar as tecnologias, nunca pelas tecnologias em si e as empresas por trás. Nos anos 90 a marca Sun era reconhecida pelos seus produtos inovadores como os workstations, o Solaris, pessoas como James Gosling e Bill Joy. De repente tudo mudou, em 2009 ela foi vendida pra Oracle e desde então ninguém mais se lembra dela. De repente a Apple era um gigante nos anos 80, quase morreu nos 90, fez um retorno triunfante nos 2000 e então estamos na ressaca da morte de Jobs desde 2011. A Microsoft teve altos e baixos iguais, sendo hegemônica nos anos 90, quase se desintegrando no processo anti-truste de 2000, sendo ostracizado nos anos 2000 e perdendo o bonde dos dispositivos de música e smartphones e só agora retornando de forma triunfal. Hoje você é fã do do Facebook, de unicórnios como Uber, Netflix, Spotify.

Toda startup inovadora de ontem se torna o enterprise de amanhã. Entenda essa verdade. A parte cruel de ter sucesso é se tornar quem se queria superar. São ciclos, é assim que as coisas funcionam. Eu conheci o GitHub em 2008, era um escritório pequeno, poucas pessoas. Hoje vale bilhões, basicamente dominou todo o código open source do planeta e foi comprada pela Microsoft. Nada permanece igual por mais de uma década neste nosso mundo de tecnologia.

E essa percepção não é nova, todo mundo falava da famosa Lei de Moore, do grande Gordon Moore, a “lei” que na verdade era só uma observação que o poder de computação dobrava pelo mesmo preço a cada 18 a 24 meses. Essa lei já morreu neste século quando batemos num teto de clock e passamos a adotar multi-cores. Mas existe outro Gordon, Gordon Bell e a Lei de Bell de 1972 que descreve como classes de computadores se formam, evoluem e podem eventualmente morrer.

Bell considera essa lei parcialmente um corolário da Lei de Moore. A definição é: Mais ou menos a cada década uma nova classe de computadores de menor custo se forma baseada em uma nova plataforma de programação, rede e interface resultando em uma nova usabilidade e o estabelecimento de uma nova indústria.

A Lei Bell fala sobre uma nova classe de computadores, e pode ser do mainframe pros minicomputadores para workstations para desktop para dispositivos móveis pra cloud computing e assim por diante. Faz 50 ou 60 anos que isso vem acontecendo, e só na minha curta história de 4 décadas eu diria que vi isso acontecer com meus próprios olhos. Não acredita em mim? Se você tem 20 anos talvez não tenha essa memória tão viva, mas se você tem 40 certamente vai se lembrar de quando em 2005 o Papa Benedito 26 foi escolhido, essa era a multidão assistindo no Vaticano. Então, menos de 10 anos depois, ele resignou e em seu lugar um novo papa foi escolhido, Papa Francisco, e esta é a multidão no Vaticano em 2013. Sim, o mundo mudou, e ele vem mudando constantemente.

A vocês de 20 anos fica a dica: planeje sua carreira mas estabeleça planos ou objetivos fixos. Você tem a fantasia de viver sendo feliz e fazendo as coisas que gosta, seja lá o que isso for, e eu já expliquei no meu vídeo “Procure o que você Ama, só que não” porque esse pensamento vai limitar suas opções.

A vocês de 40 anos, vou só confirmar o que vocês já sabem: a vida muda. Vocês provavelmente já entenderam que o importante não é fazer o que ama, mas amar o processo e aproveitar as chances que a vida vai te dando, sem ficar olhando muito pra trás. Por alguma razão os jovens tem vivido mais no passado do que os mais velhos, olhando muito pros nomes e ideologias falidas do passado. Livrem-se de ideologias e dogmas, elas não servem pra nada, pois quem vive de museu é passado.

Vou repetir, sua linguagem de programação não te define. As empresas de tecnologia não te definem. Seu salário atual não te define. Suas ideologias nunca deveriam te definir, porque você vai mudar todas elas em breve. Seus objetivos não te definem, porque à medida que o mundo vai mudando, seus objetivos vão mudar também. A única coisa que é constante é gostar do jogo e gostar do seu próprio esforço, seja lá no que esteja fazendo.

O objetivo do episódio de hoje era dar perspectiva. Antes de eu sair dizendo “vá aprender tecnologia X ou vá fazer curso Y” eu acho importante que todos você entendam onde vocês estão, no espaço e no tempo. Essa perspectiva vai ajudar vocês a terem mais dimensão. Quando você se pergunta, será que estou atrasado? Será que ainda tem tempo? Será que estou indo muito devagar? Pare pra pensar na perspectiva desse episódio. Talvez, talvez você esteja atrasado, pra década passada, mas uma nova década já se abriu.

No próximo episódio prometo que vou começar a tocar em alguns assuntos mais práticos tanto pro curto quanto pro longo prazo. Não deixem de assinar o canal e clicar no sininho pra não perder, se curtiram mandem um joinha e compartilhem suas histórias de perspectiva nos comentários abaixo. A gente se vê semana que vem, até mais!

[Akitando] #9 - 7 Recomendações de Shows para pessoas de Tech

Tue, 11 Sep 2018 17:00:00 -0300

Descrição no YouTube

Esta semana vou testar um formato um pouco diferente, hoje quero compartilhar com vocês 7 shows que vão ao mesmo tempo entretê-los e educá-los um pouco sobre a história da computação moderna.

Alguns links pra complementar:

Ada Lovelace: Original and Visionary, but No Programmer (https://www.bbvaopenmind.com/en/ada-lovelace-original-and-visionary-but-no-programmer/)
BBC DOCUMENTARY : Calculating Ada - The Countess of Computing 2015 (https://www.youtube.com/watch?v=QgUVrzkQgds)
Halt And Catch Fire (https://www.amc.com/shows/halt-and-catch-fire)
Halt And Catch Fire: A Modern History Lesson (https://www.youtube.com/watch?v=DOC-85uAAgc)
Download: The True Story of the Internet (https://www.youtube.com/playlist?list=PL_IlIlrxhtPMqW4b0-v8OgLvFZQes6SoZ)
AkitaOnRails: The iPod Revolution (http://www.akitaonrails.com/2011/01/30/documentario-the-ipod-revolution)

Outras recomendações:

Revolution OS (http://www.revolution-os.com/)
Indie Game: The Movie (http://buy.indiegamethemovie.com/)
Objectified (https://www.imdb.com/title/tt1241325/)
Helvetica (https://www.imdb.com/title/tt0847817/)
AlphaGo (https://www.imdb.com/title/tt6700846/)

Recomendações dos comentários:

BBS: The Documentary (https://archive.org/details/BBS.The.Documentary)
Triumph of the Nerds PBS Documentary (https://www.youtube.com/watch?v=FFX4WqtviKE&list=PL5RgZmLSfXyCHm9p7xF6sGIInG3cAjMYE%29)
Steve Jobs Brainstorms with the NEXT Team (1985) (https://www.youtube.com/watch?v=BNeXlJW70KQ)

Script

Olá Pessoal, Fabio Akita

Eu gosto muito de cultura pop, filmes, séries de TV. Durante as últimas décadas, computadores tem sido tema de centenas. De clássicos como 2001: uma odisséia no espaço, War Games, ou Terminator até mais recentes como Person of Interest ou Mr. Robot. A grande maioria coloca a tecnologia como um acessório “mágico”, mas alguns tentam mostrar um pouco mais da ambientação e da história. HOJE quero dar 9 recomendações de entretenimento em filmes, documentários e séries de TV que eu assisti.

…

Eu costumo dizer que tive muita sorte. Eu conheço a história da computação moderna a partir do meio dos anos 80 porque eu vi em primeira mão como tudo aconteceu. A história antes dos anos 80 eu aprendi via enciclopédias. Entender como os eventos se conectam durante todo esse período é muito legal.

Se você nunca se interessou muito, talvez consiga se motivar assistindo alguns filmes pra começar a apreciar o que você tem hoje. De onde veio o computador que você usa hoje? De onde vem o smartphone que você usa hoje? Porque as coisas são como são?

O maior problema de filmes é que escritores normalmente gostam de tomar várias “liberdades artísticas”. Mas tudo bem, filme não é documentário. Assistam pelo entretenimento e para se motivar a ir atrás da história real.

Antes de iniciar, cruzei com um filme que é tão ruim que não dá pra recomendar, mas achei importante comentar aqui pelo assunto. É um tanto obscuro, mas é estrelado por ninguém menos que Tilda Swinton, foi lançado em 1999 e se chama Conceiving Ada.

É meio uma ficção científica hiper fantástica sobre tentar trazer Ada pro mundo moderno. De qualquer forma achei interessante ter a imagem da Tilda Swinton como a personificação de Ada Byron King, única filha legítima do poeta Lord Byron, vindo a se tornar condessa de Lovelace. Muitos clamam que ela foi a primeira programadora mas não existem muitas evidências disso. O fenômeno Lovelace é mais um exemplo de como a cultura popular sobrepõe fatos históricos. Não há dúvidas de que ela e seu mentor Babbage foram visionários na história da computação, mas discutir se ela foi ou não a primeira programadora não é útil pra história. Babbage inventou o Difference Engine em 1822 e o Analytical Engine em 1837. Ele escreveu os primeiros programas rudimentares em 1836 e Ada, que foi mentorada por Babbage, evoluiu esses programas em coisas mais complexas em 1842. A colaboração dos dois foi importante na história.

Agora sim, vamos às recomendações.

A primeira recomendação é um filme, The Immitation Game, de 2014. Este acho que todo mundo conhece por causa das atuações impecáveis de Benedict Cumberbatch como Alan Turing, considerado por muitos como o pai da programação moderna, e surpreendentemente da Keira Knightly como Joan Clarke. Apesar da linha geral da história ser interessante, se apresentando com o estilo “outsider que precisa se provar ajudando a ganhar a guerra e revolucionando a computação ao mesmo tempo, mas é injustamente condenado e acaba seus dias em desgraça”. A história real é bem menos dramático que isso. Alan Turing de fato teve um fim injusto, que tentaram corrigir só em 2013. Mas tirando isso o computador de Turing não foi construído sozinho, eles tiraram Gordon Welchman do filme, que é uma omissão importante. Apesar do toque dramático, o computador não foi chamado de Christopher e sim Bombe. E o Bombe não foi tão revolucionário mesmo na época, ainda era só mais um dispositivo eletromecânico com switches de relay e rotores em vez de tubos a vácuo e circuitos eletrônicos. A revolução só viria com John Von Neumann - que eu nunca vi em nenhum filme aliás. Novamente, como entretenimento é um ótimo filme para trazer o nome de Alan Turing ao interesse das pessoas, mas não usem como base pro seu trabalho de história.

A segunda recomendação é uma série de TV. Se você só conhece a AMC por causa de The Walking Dead, procure saber sobre Halt and Catch Fire de 2014 (cujo nome aliás, é o mnemonico HCF de assembly pra crashear um computador). Ela tem quatro temporadas e é uma das melhores séries sobre computadores que eu já vi. Não é um documentário. Não é um biótipo de pessoas de verdade. Ela é como MadMen, onde podemos ver como era a vida no começo dos anos 80 até quase o meio dos anos 90 através de personagens que estavam no meio da revolução dos microcomputadores e a cultura de BBS até o início da internet comercial. É meio como ver a história real pelos bastidores. O casting dessa série é fenomenal, todos os protagonistas são estelares. Começa com Lee Pace como Joe MacMillan, um personagem à la Steve Jobs, escrito como um ex-IBMista tentando ser visionário. Lee Pace talvez vocês reconheçam de personagens como Thranduil na trilogia The Hobbit ou como Ronnan the Accuser no Guardiões da Galáxia. Tem também Scott McNairy como Gordon Clarke um tipo mais Wozniak, talvez vocês tenham visto ele em filmes como Killing Them Softly, Argo, 12 Years a Slave. E em Argo a esposa de seu personagem também foi Kerry Bishé que em Halt and Catch Fire é Donna Clark, uma das personagens femininas na indústria de tech que eu mais gostei até hoje. Sério, ela é perfeita, quase perfeita demais na minha opinião, mas não vou reclamar, e junto com a personagem Cameron Howe de Mackenzie Davis - que você deve ter visto no novo Blade Runner: 2049 - formam uma dinâmica incrível na 3a e 4a temporada. Dois exemplos de mulheres na tecnologia numa época bem diferente da nossa. Não tenho elogios suficientes pra descrever essa série, altamente recomendo.

A terceira recomendação da lista é provavelmente o que eu mais gosto pelo efeito nostalgia, nem tanto pela qualidade de produção, já que é um filme feito para TV pela TNT em 1999, Pirates of Sillicon Valley, adaptado do livro Fire in the Valley. É a melhor adaptação da história da revolução dos microcomputadores dos anos 80 e 90. Ela vai do fim dos anos 70 até o começo dos 90, dá um salto e termina no lendário retorno de Jobs à Apple no fim dos anos 90. As interpretações de Noah Wyle e Anthony Michael Hall como Jobs e Gates são fenomenais e até hoje quando eu penso em Jobs e Gates eu imagino esses dois. O casting no geral é muito bom, Joey Slotnick e John Dimaggio como Wozniak e Balmer também são perfeitos. Apesar de ser um filme pra entretenimento, e apesar das liberdades artísticas, esse é um dos poucos filmes que realmente fez uma boa pesquisa e na maior parte os eventos são corretos. Tem poucos pequenos erros que não quebram o filme como um todo, e é unânimo que Noah Wyle fez um Jobs tão bom que foi reconhecido pelo próprio Jobs, Wozniak e outros próximos como Daniel Kottke. Até Gates reconhece que o filme é próximo da realidade. E a forma como dramatizaram a relação de Jobs com Gates é muito boa. De todos os filmes sobre computadores já feitos, esse é de longe a melhor recomendação de todos. É tão bom que eu já vi esse filme uma dezena de vezes e não me canso de assistir.

A quarta recomendação não é um filme mas o primeiro documentário da lista. Na sequência de Pirates, assista o documentário da Discovery Channel chamado Download: The True Story of the Internet escrita pelo jornalista John Heilemann, lançado em 2008. Ele é dividido em 4 episódios: Browser Wars, Search, Bubble, People Power, respectivamente conta a história da famigerada Guerra dos Browsers, a história que dá origem ao Google, o Crash das Ponto Com e o início da história das redes sociais. Ela cobre um pedaço importante da história que vai do meio dos anos 90 até o começo do século XXI. Nela vocês vão entender como a Microsoft quase foi dividida em 3 num dos julgamentos mais pesados da história da computação, que quase quebrou Bill Gates e foi o motivo dele ter saído da presidência da Microsoft. Vai conhecer mais sobre a história de personagens importantes como Jim Clark, Marc Andreesen, Shawn Fanning. Mais interessante é como esse documentário é construído meio como se fosse um episódio do Investigação Discovery, tem aquele tom de suspense como se estivessem contando a história de um crime. E é justamente esse um pouco da idéia: de mostrar como a história não é tão bonita quanto muitos podem imaginar.

E falando em Shawn Fanning, a quinta recomendação é outro documentário também da Discovery, chamado The iPod Revolution, de 2007. Esse filme conta a história do produto que transformou a Apple de uma empresa de computadores no maior titã da indústria de música. É a história da origem do iPOD e como o iTunes colocou a indústria de música de joelhos, transformando a Apple num ícone cultural. Pra mim este filme é a continuação de Pirates of Silicon Valley e um importante episódio da nossa história recente. Diferente do documentário anterior, esse tem um tom mais épico, e trás vários escritores e jornalistas famosos que eu lia muito na época como Leander Kahney, David Pogue, Steven Levy, Jeffrey Young. Eu gostei tanto desse documentário quando foi lançaro que eu cheguei a fazer as legendas em portugues, e vocês assistir do meu blog no link na descrição deste vídeo abaixo.

A sexta recomendação deve ser a única que praticamente todo mundo aqui já deve ter assistido e por isso não preciso explicar muito, The Social Network, de 2010. Ela basicamente queimou nas nossas mentes que Mark Zuckerberg na verdade é Jesse Eisenberg nas horas vagas. É provavelmente um dos melhores trabalhos de screnplay de Aaron Sorkin desde The West Wing e pra mim o filme que trás de volta o David Fincher da época de Fight Club e Seven. Naturalmente, baseado em um livro chamado Accidental Billionaires, e naturalmente também com Muitas liberdades artísticas na história. Na verdade, o filme é praticamente só liberdades artísticas, mas como drama é de longe o melhor desta lista. Só não citem o filme como referência histórica.

Em termos de boa produção, a sétima e última recomendação acaba voltando pra Jobs. Não confundir com o filme que estrelou Ashton Kutcher, que eu não recomendo. Primeiro porque Pirates faz um trabalho muito melhor com a mesma história. Segundo porque Kutcher não chega aos pés de Noah Wyle em Pirates e terceiro porque existe este outro filme que eu gosto por causa da combinação de Michael Fassbender como Jobs e de novo Aaron Sorkin como escritor, baseado - mais ou menos - na primeira metade da biografia de Walter Isaacson. Minha recomendação é o filme Steve Jobs de 2015. Vocês devem ter notado que todos os filmes são obras de ficção, nenhum é uma biografia. E de todos os filmes com Jobs este é provavelmente o mais bem feito mas o mais longe da realidade. É o único que pelo menos mostra um pouco da era NEXT. Em parte gostei da estrutura em 3 atos de Sorkin usando conversas nos bastidores antes de uma das icônicas apresentações de Jobs. É um filme bem inteligente na verdade, mas nesse ponto da história acho que foi muito pouco muito tarde. Mesmo assim, vale muito a pena assistir. O maior defeito de Steve Jobs é também a parte que eu pessoalmente mais gosto: Aaron Sorkin nunca esteve tão afiado nos diálogos, é basicamente um filme que devia se chamar “Como fazer diálogos afiados, by Aaron Sorkin” subtítulo “um filme sobre Steve Jobs”.

E estas são algumas das minhas recomendações. O que acharam? E quais são as suas recomendações e porque? Não deixe de compartilhar com a gente nos comentários abaixo. Se gostaram dêem um joinha, assinem o canal e clique no sininho pra não perder os próximos episódios! A gente se vê, até mais.

Retrospectiva on Rails - 10 Anos e Muito Mais!

Tue, 26 Aug 2014 16:17:00 -0300

Finalmente consegui fazer uma retrospectiva com os principais acontecimentos não só da última década de Ruby on Rails mas eventos em anos anteriores e durante que influenciaram nosso ecossistema de alguma forma significativa.

Como base eu pedi permissão ao Luke Francl que publicou o artigo original Looking Backward: Ten Years on Rails. Sobre ele, adicionei diversas novas datas que não estavam lá mas que foram significativas.

Certamente tem diversos outros que eu não coloquei ou me esqueci mesmo (vou adicionando aos poucos). Se quiserem contribuir eu coloquei um Gist para que todos possam fazer fork e me mandar mudanças.

Quando vocês começaram a programar com Rails/Ruby e por que? Coloque nos comentários abaixo! Eu devo fazer um outro post separado também contando um pouco do meu começo com Rails mais pra frente.

1972

cerca de Janeiro - Lançado Smalltalk-72, a primeira versão usada em pesquisa.

1978

cerca de Janeiro - Pattern MVC criado pela primeira vez por Trygve Reenskaug na Xerox Parc.

1995

21 de Dezembro - Ruby 0.95 é lançado. (Primeira versão pública)

1997

27 de Maio - Eric S. Raymond lança os artigos que se tornariam o livro The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary que delineiam a revolução open source que ganhou fôlego na década de 90, principalmente depois que a combinação GNU/Linux começou a fazer sucesso.

1998

cerca de Janeiro - XML-RPC é lançado, baseado no draft da especificação do protocolo SOAP.

1999

cerca de Janeiro - SOAP (“Simple Object Access Protocol”) 1.1 é lançado. Ele se torna o jeito padrão de se fazer chamadas de web services em Java e .NET.
22 de Outubro - Dan Kegel escreve o canônico artigo The C10K Problem que se torna o marco para a implementação de I/O assíncrono nos diferentes sistemas operacionais para finalmente a web conseguir escalar. Isso se tornará as raízes de projetos como NGINX e Node.js no futuro.
30 de Outubro - The Pragmatic Programmer: From Journeyman to Master por Dave Thomas e Andy Hunt é publicado. Recomenda que programadores aprendam uma linguagem de scripting.
cerca de Novembro - SourceForge é lançado, fornecendo CVS hosting de graça para projetos de código aberto.

2000

cerca de Janeiro - Roy Fielding define “REST” em sua dissertação de Ph.D.
10 de Março - A bolha das ponto-com explode.

2001

cerca de Janeiro - Microsoft lança o Outlook Web Access, a primeira grande aplicação a usar a biblioteca XMLHTTP que vem no Internet Explorer.
cerca de Janeiro - Programming Ruby (primeira edição) por Dave Thomas e Andrew Hunt é publicado.
cerca de Fevereiro - Agile software manifesto é criado.
cerca de Abril - State Software (empresa do Douglas Crockford) começa a trabalhar num “JavaScript Message Language” para intercâmbio de dados. É rapidamente renomeado para JSON.
22 de Outubro - Glyph Lefkowitz lança o Twisted, um dos primeiros frameworks de programação event-driven em Python. Node.js (lançado em 2009) seria um dos muitos sucessores que se seguiram ao Twisted.

2002

cerca de Janeiro - website JSON.org é lançado.
11 de Fevereiro - Struts 1.0.2 é lançado.

2003

cerca de Janeiro - Patterns of Enterprise Application Architecture por Martin Fowler é publicado; inclui a descrição do pattern Active Record.
cerca de Janeiro - RubyForge é lançado para fornecer hosting para a comunidade Ruby; é baseado num fork da plataforma SourceForge.
7 de Dezembro - PEP 333 que define o Web Server Gateway Interface é publicado; ele fornece uma interface HTTP comum para frameworks web Python.
5 de Fevereiro - Basecamp é lançado.
10 de Fevereiro - Flickr é lançado; sua animação de edição “yellow fade” é amplamente copiado.
cerca de Março - Java Server Faces 1.0 é lançado; é o jeito “do futuro” para desenvolvimento de aplicações web em Java.

2004

1 de Abril - Google lança GMail, demonstrando recarregamento ao vivo de aplicações web.
14 de Março - Lançamento público inicial do Rubygems.
24 de Julho - Primeiro lançamento do Ruby on Rails (0.5)

Eu venho falando (e propagandeando) Rails por tanto tempo que é estranho finalmente vê-lo no mundo. Imaginem vocês, ainda não estamos falando de um lançamento 1.0, mas o pacote atualmente em oferta é algo que eu me sinto bem confortável compartilhando com o mundo. Sem dúvida, poderia ter mais documentação e mais exemplos, mas Artistas de Verdade Entregam, e esta peça vai crescer em público. Aproveitem Rails!

2 de Outubro - DHH apresenta na Rails at RubyConf 2004. Francis Hwang estima 60 pessoas na audiência.
5 de Outubro - a conferência apenas por convite Web 2.0 da O’Reilly populariza o termo “Web 2.0”.
25 de Outubro - Primeiro lançamento do Ruby on Rails como Rubygem (0.8)
10 de Dezembro - Google lança o Google Suggest, que usa XMLHTTP para atualizar as sugestões de busca de forma assíncrona enquanto você digita. Desenvolvedores rapidamente fazem engenharia reversa da técnica.

2005

1 de Janeiro - A Robot Co-op lança o 43 Things; o site é é um early adopter de Ruby on Rails.
20 de Janeiro - Rolling with Ruby on Rails é publicado.
27 de Janeiro - Carlos Riberio discute o problema dos frameworks web Python.

No mundo Python, existem diversos frameworks web competindo. É interessante ver como muitos deles são muito mal documentados, ou nem mesmo documentados. Mas mesmo projetos que tem um bom volume de documentação ainda falham em endereça o problema do modelo mental. Um manual que toca somente em problemas práticos - principalmente, especificações de APIs - é perto de inútil nesse sentido.

Gostaria de ver mais esforços gastos na documentação dos problemas de arquitetura de um framework. Não somente 'como eu chamo este método', mas 'como eu estruturo minha aplicação'. Essa é a pergunta difícil, e a falta de uma resposta satisfatória para isso é normalmente uma boa razão para escrever mais outro framework.

2 de Fevereiro - Primeira menção de Ruby on Rails no meu blog (do Luke Francl)

A comunidade Java tem falado sobre esse Ruby on Rails por alguns meses já.
Hoje eu finalmente dei uma olhada nisso.

Parece bem legal. Um framework REST-ful para criar aplicações web dinâmicas com quantidade mínima de código. Escrever aplicações REST-ful com URLs limpas em outros frameworks pode ser uma enorme dor (experimente fazer isso só com servlets - você vai implorar por misericórdia).
Fora isso, o que eu gostei é que ele é uma stack inteira, integrada junto de maneira bonita. Isso é algo que eu realmente sinto falta em Python. Python tem um milhão de frameworks web, mas nenhum deles tem um pacote completo como Rails.

Considerei usar Python para alguns projetinhos meus, e eu ainda não encontrei o "melhor" framework web Python. Devo usar mod_python ou FastCGI? Qual mapeamento objeto-relacional é o melhor? Que linguagem de template devo usar? Qual framework de view vai me dar URLs bonitas, com bom SEO, que parecem profissionais? Finalmente, desses montes de frameworks, qual deles eu posso contar por uma comunidade ativa para boa documentação e suporte?

É uma puta dor de cabeça.

O mesmo problema se aplica ao mundo Java, mas lá você sempre pode se virar através do Servlet/JSP padrão, que tem suporte institucional da Sun, ou ir para frameworks como Struts, Spring, e Hibernate que tem milhares de desenvolvedores, boa documentação, livros publicados, etc.
Mas no fim … será que Rails vale o preço de ter que aprender Ruby? Hmmm …

5 de Fevereiro - Sam Stephenson lança o Prototype.js
8 de Fevereiro - Google Maps lança para Internet Explorer e Firefox, redefinindo o nível de interação possível em um web browser.
15 de Fevereiro - Jesse James Garrett cunha o termo Ajax para descrever as novas aplicações web ricas como Flickr, Google Suggest, ou Google Maps.
16 de Fevereiro - Rodrigo Caffo cria a primeira mailing list brasileira de Rails, a Rails-BR
7 de Abril - Lançamento inicial do sistema de controle de versão distribuída git.
2 de Julho - David Heinemeier Hansson grava o demo do blog de 15 minutos, demonstrando a velocidade do desenvolvimento rápido com Rails.
cerca de Julho - Lançamento inicial do Groovy on Grails, um framework inspirado no Rails para a linguagem Groovy que roda na JVM.
7 de Julho - script.aculo.us 1.0.0 é lançado, tornando fácil adicionar os efeitos de estilo Web 2.0 às suas aplicações.
21 de Julho - Django é lançado depois de ficar em desenvolvimento por mais de 2 anos.
cerca de Agosto - Locomotive é lançado; torna fácil a configuração de um ambiente de desenvolvimento Rails no Mac.
4 de Agosto - Agile Web Development with Rails, primeira edição publicada.
20 de Agosto - Foundations of Ajax publicado; um livro inteiro sobre como usar Ajax.
26 de Outubro - Primeiro encontro do Ruby Users de Minnesota (Luke).
3 de Dezembro - Conferência Snakes and Rubies trás juntos os criadores do Django e do Rails (video).
13 de Dezembro - Rails 1.0 é lançado.

2006

21 de Março - Jack Dorsey posta primeiro tweet: “just setting up my twttr”
23 de Março - Eustáquio Rangel lança primeiro livro de Ruby no Brasil.
5 de Abril - Escrevo meu primeiro post no que viria a se tornar o blog AkitaOnRails.com.
22 de Junho - A primeira RailsConf acontece em Chicago.
30 de Junho - Hamptom Caitlin sobe o primeiro commit do SASS e inicia uma nova era de meta-linguagens para tornar possível codificar decentemente em linguagens ruins como CSS.
5 de Julho - JRuby 0.9 consegue rodar Rails.

Vamos ver até onde essa comunidade pode chegar.
Ruby on Rails poderá ser muito ou nada, tudo vai depender de como o mercado vai encarar a novidade. Mas muita coisa pode ser feita agora. Para começar, aprendendo sobre o assunto.

Vou postar os principais assuntos sobre a plataforma aqui e espero que todos colaborem com idéias e sugestões ou mesmo críticas e opiniões.

Infelizmente ainda existem muitos desafios a serem vencidos. Para começar, materiais de Rails em português virtualmente inexistem. Sites brasileiros idem. Portanto quando digo “começar do zero”, estou falando sério.

O maior desafio será convencer o mercado. E isso não se faz da noite para o dia. Significa que ainda não será possível deixar o legado do Java totalmente de lado. Vamos começar um período de transição onde tentaremos as duas coisas em paralelo.

Os pioneiros sempre caminham por território árduo, mas a recompensa dos primeiros sempre será maior também. Esse é o sentido do investimento.

29 de Julho - Django 0.95 é lançado, incluindo mudanças de “remoção de mágica”.
25 de Agosto - Amazon Web Services lança o Elastic Compute Cloud (EC2) e inicia de fato a Era do “Cloud Computing” como conhecemos hoje.
26 de Agosto - John Resig lança o jQuery
6 de Outubro - Meu livro “Repensando a Web com Rails” saiu da gráfica, o primeiro de Rails no Brasil.
9 de Outubro - Ronaldo Ferraz lança o primeiro grande tutorial de Rails no Brasil.
cerca de Outubro - Merb 0.03 é lançado (“Mongrel+Erb”)
11 de Dezembro - Eu (Luke) começo novo emprego com Rails.

2007

9 de Janeiro - O mundo da tecnologia recebe um novo marco: o lançamento do primeiro iPhone.
18 de Janeiro - Rails 1.2 lançado com RESTful resources.
20 de Fevereiro - Christian Neukirchen define a interface Rack, inspirado pelo WSGI.
16 de Maio - Eu inicio meu primeiro emprego oficial como Railer full-time na Surgeworks.
cerca de Abril - Inicia a famigerada controvérsia do “Rails não Escala” iniciada pelo Alex Payne, do Twitter. Essa controvérsia seguiria o Rails por anos (finalmente nos livramos disso!)
cerca de Maio - Framework Play para Java é lançado.
4 de Outubro - Lançamento inicial do microframework Sinatra; ele é largamente copiado em outras linguagens.
19 de Outubro - Chris Wainstraith e Tom Preston-Werner começam a trabalhar no GitHub.
22 de Outubro - A primeira vez que organizo um evento, em São Paulo, o RejectConf SP que teve praticamente todos os nomes do Ruby brasileiro que você reconhece até hoje como Carlos Brando (Enjoei), Danilo Sato (ThoughtWorks), Fabio Kung (Heroku), Vinicius Teles (HE:Labs), Carlos Villela (ThoughtWorks), George Guimarães (Plataformatec) e mais.
cerca de Dezembro - Rails 2.0 é lançado.

2008

1 de Janeiro - o primeiro grande RubyDrama acontece com a declaração bombástica de Zed Shaw de sua saída da comunidade Ruby.
1 de Janeiro - Heroku recebe seu primeiro seed de USD 20k da Y/Combinator.
2 de Abril - Desenvolvimento do Rails move para o GitHub.
10 de Abril - GitHub lança fora do beta.
1 de Junho - Lançados o Ruby Enterprise Edition e Phusion Passenger. Pela primeira vez ganhamos uma forma robusta de fazer deployment de aplicações Rails e rodar múltiplos processos Ruby (na versão 1.8.6 ainda!) usando menos recursos do servidor.
15 de Outubro - Organizei o primeiro grande evento de Rails do continente, o Rails Summit Latin America 2008, no Auditório Elis Regina, no Anhembi em São Paulo. Tivemos ninguém menos que Chad Fowler, Ninh Bui, Hongli Lai, David Chelimsky, Chris Wanstrath, Dr. Nic Williams, Obie Fernandez e mais. Ninguém achava a) que um evento desses fosse possível, nem b) que ele seria consistente e perduraria até hoje (2014)!
23 de Dezembro - Merge do Rails/Merb anunciado; equipe do Merb se junta ao Rails core team.

2009

16 de Março - Rails 2.3 é lançado; Rails agora é uma aplicação Rack.
27 de Maio - Lançamento inicial do Node.js, um ambiente de programação web para a máquina virtual V8. Ela permite que programadores escrevam Javascript client side e server side.
13 de Dezembro - Jeremy Ashkenas sobe o primeiro commit do Coffeescript, um dos primeiros transpilers para tentar tornar programar em Javascript algo mais agradável.

2010

1 de Agosto - Rails 3.0 lançado com contribuições do Merb core team; havia passado um ano desde o lançamento do Rails 2.3.
cerca de Abril - Steve Jobs publica o prego no caixão do Adobe Flash com o artigo Thoughts on Flash e sedimenta o caminho para HTML 5 + CSS 3 + Javascript não só em dispositivos móveis mas também em desktops. O Flash se tornou um morto-vivo desde então.

2011

12 de Julho - Criador do Ruby, Yukihiro Matsumoto (Matz), é contratado pelo Heroku.
31 de Agosto - Rails 3.1 é lançado; jQuery agora é a biblioteca Javascript padrão.
19 de Setembro - Anuncio a criação da minha primeira empresa de desenvolvimento de software própria, a Codeminer 42

2013

cerca de Junho - Rails 4.0 é lançado com funcionalidades como Turbolinks e caching para tentar fazer aplicações web “clássicas” tão rápidas quanto aplicações com front-end baseado em Javascript.

[Off-Topic] Meu Primeiro "Livro"

Tue, 22 Jul 2014 20:14:00 -0300

Em 2007 escrevi meu primeiro livro “publicado”, sobre Ruby on Rails. Em 2006, comecei este blog. Antes disso eu já escrevia, só que sem publicar.

Se acompanha o blog, viu que ontem saiu um artigo sobre Segurança, onde falo da importância do backup. Minha rotina de backup vem de longa data. Eu já guardava tudo quando só tinha caixas de disquetes, e a cada geração de mídia migrava de uma para outra.

Foi assim de disquetes para discos de zip drive, depois para CDs, daí para DVDs e finalmente para o meu Drobo, como publiquei em 2009, com uma parte no Dropbox. De vez em quando dou uma fuçada nesse arquivo, e acabei de esbarrar num “livro” que escrevi quando era estudante do 3º semestre de Ciências da Computação na USP, em Maio de 1996. O backup é datado de Maio de 1996, então provavelmente escrevi isso antes.

Fonte: The Road Ahead - Bill Gates

Nunca escrevi esse livro para ser publicado. Escrevi porque sempre gostei de pesquisar e de organizar as coisas por escrito, para mim mesmo. E esse gosto tem um momento de origem bem específico: o filme Indiana Jones e a Última Cruzada, de 1989.

Eu provavelmente tinha acabado de fazer um curso de datilografia (acho que foi em 1988, já não tenho certeza). Tinha uma enciclopédia em casa, e o filme trazia o diário do pai do Indiana. A ideia de um livro que reúne a pesquisa de uma vida inteira virou uma imagem que me acompanha até hoje.

O medo por trás disso era esquecer o que eu tinha aprendido. Eu queria registrar o que sabia num único lugar, para garantir que estaria acessível se um dia eu quisesse lembrar. Como agora.

Desde então eu quis escrever para destilar tudo que sabia sobre um assunto num único lugar. Lembrem-se que isso foi muito antes da Wikipédia, muito antes de ter qualquer informação acessível a qualquer momento como temos hoje. E continua sendo um dos motivos de eu escrever: mesmo que ninguém lesse, eu escreveria para mim mesmo, como faço há mais de duas décadas.

Boa parte desse material é puro exercício de digitação. Para os mais novos, vale explicar que antes de consultarmos tudo pela Web existia uma mídia analógica quase extinta chamada “papel”. E antes do “copy and paste”, a gente tinha que datilografar ou digitar cada texto, transcrevendo do analógico para o digital.

OCR ainda não era difundido, e nem todo mundo tinha um scanner (os que existiam hoje seriam considerados de resolução e qualidade péssimas). Então tinha que gostar muito de transcrever, e esse por sinal era um dos meus hobbies favoritos desde que ganhei a minha primeira máquina de datilografia.

Para a posteridade, segue a versão em PDF, capítulo a capítulo, caso tenham curiosidade de saber o que um estudante de 1996 sabia.

Palavras do Autor: Introdução à Informática
CAPÍTULO I - /HISTÓRIA DA HUMANIDADE/
CAPÍTULO II - /Anatomia - dos átomos à matéria orgânica/
CAPÍTULO III - /Personal Computers - um pouco mais de história/
CAPÍTULO IV - /Uma rápida apresentação das partes de um Corpo Humano/
CAPÍTULO V - /Disco Básico/
CAPÍTULO VI - /Dando Ordens à Máquina/
CAPÍTULO VII - /WINDOWS e EMS/
CAPÍTULO VIII - /16 ou 32 Bits: Isso importa para você?/
CAPÍTULO IX - /RISC vs. CISC: a Verdadeira História/
CAPÍTULO X - /Teste de Crash em Sistemas Operacionais/
Últimas palavras: uma visão global
Vendas pela Internet

Se tiver que escolher, dá para pular os capítulos II, IV, V e X. O VII é engraçado para ver o que era um Windows em 1996. O VIII serve para lembrar que naquela época a migração de 16-bits para 32-bits era uma dor de cabeça, nada parecido com a facilidade de ir depois de 32 para 64-bits.

O capítulo IX é para quem usava Mac nos anos 90, ainda na era anterior ao RISC de hoje. Os mais curiosos provavelmente são a introdução e os dois últimos capítulos, que trazem mais opiniões pessoais sobre o pouco que eu entendia de internet naquele momento. A primeira vez que naveguei na Web foi em 1994.

O que acharam? Não deixem de comentar. :-)

[Off-Topic] Visão do Passado sobre a Internet

Sun, 26 May 2013 20:56:00 -0300

Vendas pela Internet

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipadas com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações, começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à **ARPA **( Advanced Research Projects Agency ) e ao DoD ( Department of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para **DARPA **( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do **INWG **( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o **IP **( Internet Protocol ) e o **TCP **( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

Para entender a importância da Internet em todos os sentidos : sociais, políticos e financeiros, é preciso ver quem navega pela Internet. Vamos nos basear nas pesquisas de John Quarterman, um provedor de acesso, consultor e publisher de Austin, Texas, que pesquisa a composição da população da Internet na sua Internet Demographic Survey.

Uma das coisas que Quarterman tem feito é definir várias Internets de acordo com os tipos de aplicações que rodam nos servidores e as atividades dos usuários. O “núcleo da Internet” é constituído por computadores que oferecem serviços interativos como FTP, Telnet ou aplicações WWW. A “Internet de consumo” inclui pessoas que usam os serviços interativos oferecidos pelo núcleo - por exemplo, usuários que navegam no World Wide Web. O total do ciberespaço, que rotula como a “matriz”, são todos os usuários que trocam e-mail com outros usuários. Essas categorias se encaixam uma na outra: a matriz inclui a Internet de consumo, que inclui a Internet Núcleo.

Um dos problemas que Quarterman tem que enfrentar envolve hosts virtuais. Um provedor de acesso à Internet tem que registrar os nomes de domínio para os usuários, mas os endereços, na verdade, residem nas máquinas do provedor. Isso pode levar a equívocos, fazendo parecer que as pessoas têm máquinas conectadas à Internet. Esse grupo pertence à categoria de Internet de consumo, e todo o correio que Quarterman envia para os postmasters em vários endereços é no final englobado por um host.

“O problema dos hosts virtuais cresceu enormemente no ano passado ( 1995 )”, disse Quarterman. “Você pode acessar um site Web, realmente existe informação lá, e realmente corresponde à organização. Está de fato em um computador na Internet, mas pode ser o mesmo computador de outros domínios.”

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, **2,9% ( 1.293 ) **responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia **16,9 milhões de usuários da Internet nuclear **( mais do que o dobro do ano passado ) e **26,4 milhões de usuários da Internet de consumo **( novamente o dobro ); **39 milhões de usuários **( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Na pesquisa de 1995, Quarterman contou 45 mil máquinas conectadas à Internet. O número real de domínios registrados excedeu este número porque nem todos os domínios registrados são usados e alguns são domínios em outras redes, como a UUCP, onde você pode enviar correio, mas não pode usar serviços Internet interativos.

O Web é quente, mas o FTP ainda supera a navegação. Quarterman também percebe que o uso do sistema operacional Windows está caindo e que os Macintoshes ( apesar do uso do Internet Protocol e não do MacOS ) e as máquinas Unix estão aumentando sua fatia no controle de domínios.

Os resultados são anunciados e veiculados no site Web da **MIDS **( que publica as revistas mensais **Matrix News **e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ) em http://www.mids.org. “O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda”.

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao _cyberspace _- estamos crescendo 50% ao mês. Com isso chegamos à uma população de **260 mil cibernautas **no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam **um milhão de usuários **na virada do ano.

Publicidade

Depois da revolução dos microcomputadores na década de 80 e da disseminação da informática com “um micro em cada mesa e em cada casa”, tivemos uma das maiores evoluções já vistas na história onde a humanidade evoluiu em 10 anos o que não conseguiu evoluir desde a Idade Média, entrando na Era da Informação.

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde “países” e “oceanos” não têm mais significado e onde as distâncias físicas não fazem mais sentido. A **virtualização **evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer e fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o **CoolTalk **da Netscape Inc. ( **http://www.netscape.com **) que substitui o telefone ou o TimedVideo Grabber ( **http://www.avernus.com/~allan **) que possibilita a transmissão de imagens em _real-time _com o uso de câmera, tornam possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em “carne-e-osso”.

E falando em evolução, depois de 500 anos de reinado absoluto das mídias impressas como difusor de informação, esta está sendo rapidamente substituída por publicações digitais na World Wide Web, a parte da Internet que mais chama a atenção atualmente.

Com trabalhos pioneiros como a **Enciclopédia Britannica **( **http://www.eb.com **), que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a **Encarta **da **Microsoft **( **http://www.microsoft.com **), e também de serviços de procura do tipo “páginas amarelas” como as oferecidas por sites como o **Yahoo! **( **http://www.yahoo.com **) ou **Lycos **( **http://www.lycos.com **), tornaram a Internet também o maior repositório de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundialmente famosas como a **PC Magazine **( **http://www.pcmag.com **) da **Ziff Davis Publishing **( **http://www.ziff.com **) ou a **Playboy **( **http://www.playboy.com **) já têm suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma “cara” à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a **HTML **( Hyper Text Mark-Up Language ) e um protocolo específico, a **HTTP **( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu **Netscape Navigator **e a **SpyGlass **com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da **IBM **( **http://www.ibm.com **) que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das **Olimpíadas **( **http://www.atlanta.olympic.org **), onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o **The Gate **( **http://sfgate.com **) um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o **San Francisco Chronicle **e o **San Francisco Examiner **com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet ( **http://www.agestado.com.br **) com as principais chamadas do dia e informações diversas, incluindo seus classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos **serviços on-line **como as gigantes **Compuserve **e **America On-line **que atendem a pessoas do mundo todo e têm aliados como Netscape e Microsoft. Esse tipo de organização é baseada em “serviços” que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a **Folha de São Paulo **e o **Grupo Abril **que lançaram, respectivamente, o **Universo Online **e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o **The New York Times **cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços têm faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar “out-doors virtuais” ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a **Sun **ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como **Hypertext **( palavras dentro de um texto que levam a outras páginas ), **Marquees **( frases que se movimentam na linha ), músicas ( através de arquivos **WAVE **ou da nova tecnologia **Real Audio **), animações ( via imagens **GIF **animadas ou então utilizando recursos da linguagem **Java **) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia **VRML - Virtual Reality Markup Language **) e muito mais. Nesse filão mercadológico estão empresas como a **Vivid Studio **( **http://www.vivid.com **) que tem como clientes as gigantes **Silicon Graphics **e Microsoft ou a **Razorfish **( **http://www.razorfish.com **) que desenha para a **Time-Warner **e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos **IPX/SPX **ou **NetBIOS **por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o **cybercash **( **http://www.cybercash.com **) com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo **SIPS **( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clicar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação **768-bit RSA **e a 56-bit DES. Todas as transações são autenticadas com as assinaturas **MDS **e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a **Digicash **( **http://www.digicash.com **), com os serviços centrados no site da **First Digital Bank **( **http://bank.digicash.com **), utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A **Visa **( **http://www.visa.com **) ( que também já é parceira da **Sony **- **http://www.sony.com **- no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o **STT **( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A **Mastercard **( **http://www.mastercard.com **) está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão **SEPP **( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança **SSL **( Secure Sockets Layer ) e contribui no desenvolvimento da interface **SSL **do **W3C **( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu - **http://www.w3.org **). Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI ( http://www.mci.com ), Bank of America ( http://www.bankamerica.com ), Mastercard, First Data Corporation, Novell ( http://www.novell.com ), Digital ( http://www.dec.com ) e Silicon Graphics.

Praticamente todas as empresas do setor financeiro vêm investindo muito no desenvolvimento de uma plataforma segura e confiável suficiente para transações financeiras de todos os níveis de importância. Hackers à parte, os negócios via Internet não diferem muito dos efetuados fora dela. Ou seja, a melhor forma de estar livre de problemas é confiar na credibilidade das empresas sérias. Dificilmente alguém vai querer comprometer seu bom nome deixando de entregar a mercadoria no prazo ou “negociando” o número do cartão de crédito.

No Brasil, o **Mappin **( **http://www.mappin.com.br **) foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na **Confeitaria Brunella **( **http://www.ams.com/brunella **) de São Paulo ou fazer reservas ao **Marcellu’s Bar **( **http://www.marcellus-bar.com.br **) do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu’s Bar, a reserva é feita por e-mail.

Se há alguém de mudança para os Estados Unidos ou precisando simplesmente comprar preços, poderá consultar o For Sail By Owner Connection. Trata-se de um site especializado em vendas de casas, com fotos e especificações. Se na verdade você precisa vender a sua casa, também poderá anunciar nesta page : http://www.cracker.com/byowner.

Pensando em viagens, a **Cruisin **( **http://www.cracker.com/cruisin **) é a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Criado para fins militares, depois expandido para os meios acadêmicos e, finalmente, atingindo o público em geral, a Internet caminha em evolução acelerada cobrindo praticamente todos os setores da sociedade onde se constrói as bases do que pode ser considerado um mundo virtual.

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada **Information Super Highway **onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

Nessa próxima geração, “passear” será vestir uma roupa de realidade virtual e visitar locais virtuais com amigos de outros continentes num encontro digital. E isso não se trata de delírios de ficção científica: tanto estamos perto disso que tais tecnologias são reais e já existem, tudo que resta é o tempo para torná-las acessíveis e operacionais a nível de distribuição em massa.

[Off-Topic] Visão do Passado sobre a Internet

Sun, 26 May 2013 19:56:00 -0300

Estou abrindo alguns backups bem antigos, trabalhos que guardei de 1995 a 2001, meia década de história. Na minha página no Facebook tem alguns exemplos que acabei de publicar. Quando eu estava na faculdade, comecei a escrever um livro (que nunca terminei nem publiquei) sobre computação em geral e sobre os primórdios da Internet.

O texto a seguir está exatamente como deixei num arquivo Word, em 3 de agosto de 1996, às 9:52 da manhã, com o nome “CAP12.DOC”. Vejam como eu via a Internet 17 anos atrás.

Vendas pela Internet

Forewords

Foi delegada à ARPA ( Advanced Research Projects Agency ) e ao DoD ( Department of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para DARPA ( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do INWG ( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP ( Internet Protocol ) e o TCP ( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, 2,9% ( 1.293 ) responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia 16,9 milhões de usuários da Internet nuclear ( mais do que o dobro do ano passado ) e 26,4 milhões de usuários da Internet de consumo ( novamente o dobro ); 39 milhões de usuários ( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Os resultados são anunciados e veiculados no site Web da MIDS ( que publica as revistas mensais Matrix News e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ). “O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda”.

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao cyberspace - estamos crescendo 50% ao mês. Com isso chegamos à uma população de 260 mil cibernautas no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam um milhão de usuários na virada do ano.

Publicidade

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde “países” e “oceanos” não têm mais significado e onde as distâncias físicas não fazem mais sentido. A virtualização evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer e fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o CoolTalk da Netscape Inc. que substitui o telefone ou o TimedVideo Grabber que possibilita a transmissão de imagens em real-time com o uso de câmera, tornam possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em “carne-e-osso”.

Com trabalhos pioneiros como a Enciclopédia Britannica, que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a Encarta da Microsoft, e também de serviços de procura do tipo “páginas amarelas” como as oferecidas por sites como o Yahoo! ou Lycos, tornaram a Internet também o maior repositório de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundialmente famosas como a PC Magazine da Ziff Davis Publishing ou a Playboy já têm suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma “cara” à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a HTML ( Hyper Text Mark-Up Language ) e um protocolo específico, a HTTP ( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu Netscape Navigator e a SpyGlass com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da IBM que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das Olimpíadas, onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o The Gate um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o San Francisco Chronicle e o San Francisco Examiner com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet com as principais chamadas do dia e informações diversas, incluindo seus classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos serviços on-line como as gigantes Compuserve e America On-line que atendem a pessoas do mundo todo e têm aliados como Netscape e Microsoft. Esse tipo de organização é baseada em “serviços” que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a Folha de São Paulo e o Grupo Abril que lançaram, respectivamente, o Universo Online e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o The New York Times cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços têm faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar “out-doors virtuais” ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a Sun ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como Hypertext ( palavras dentro de um texto que levam a outras páginas ), Marquees ( frases que se movimentam na linha ), músicas ( através de arquivos WAVE ou da nova tecnologia Real Audio ), animações ( via imagens GIF animadas ou então utilizando recursos da linguagem Java ) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia VRML - Virtual Reality Markup Language ) e muito mais. Nesse filão mercadológico estão empresas como a Vivid Studio que tem como clientes as gigantes Silicon Graphics e Microsoft ou a Razorfish que desenha para a Time-Warner e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos IPX/SPX ou NetBIOS por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o cybercash com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo SIPS ( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clicar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação 768-bit RSA e a 56-bit DES. Todas as transações são autenticadas com as assinaturas MDS e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a Digicash, com os serviços centrados no site da First Digital Bank, utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A Visa ( que também já é parceira da Sony - no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o STT ( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A Mastercard está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão SEPP ( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança SSL ( Secure Sockets Layer ) e contribui no desenvolvimento da interface SSL do W3C ( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu. Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI, Bank of America, Mastercard, First Data Corporation, Novell, Digital e Silicon Graphics.

No Brasil, o Mappin foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na Confeitaria Brunella de São Paulo ou fazer reservas ao Marcellu’s Bar do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu’s Bar, a reserva é feita por e-mail.

Pensando em viagens, a Cruisin é a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada Information Super Highway onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

[Off-Topic] Tributo a Steve Jobs

Thu, 06 Oct 2011 01:41:00 -0300

Como todos já sabem, 5 de outubro de 2011 marca o fim de uma era com a morte do visionário e empreendedor Steve Jobs. Nos próximos dias, todos os meios de comunicação vão publicar artigos e mais artigos sobre sua vida e seu legado, e sua biografia oficial deve sair em breve. Por isso não vou me alongar repetindo a mesma história que hoje já é conhecida por todos.

Acredito que é a primeira vez que fiquei chocado e momentaneamente sem reação com a morte de alguém. Não se fala de outra coisa no Twitter e outras redes sociais neste momento. Muita gente está desolada. Muitos estão pessimistas que a Apple não vai sobreviver sem seu líder.

Pessoalmente, me sinto contente e com muita sorte por ter vivido a geração seguinte a nomes como Steve Jobs. A Apple foi fundada em 1976 e incorporada em 1977. Quando o iPhone original foi lançado, em 2007, tanto a Apple quanto eu comemorávamos 30 anos.

Da mesma forma, minha história com computadores e tecnologia começou em 1984, no mesmo momento em que o Macintosh original estava nascendo.

Assim como Steve Jobs subiu nos ombros de gigantes como Robert Noyce, Hewlett-Packard e outros das primeiras gerações da informática, nós desta geração tivemos a chance de observar um gigante trabalhando. É muito tentador tentar reduzir os feitos de Steve a “receitas mágicas”, como todos gostam de fazer com grandes biografias. Porém nenhuma das conclusões que todos querem tirar vai fazer muito sentido.

Talvez a mensagem que melhor resume a filosofia que Steve Jobs popularizou com a Apple é o que foi ilustrado no icônico comercial de 1997 (bloguei sobre isso em 2007):

Obviamente, a que mais chega próximo à filosofia de vida de Steve é seu agora lendário discurso em Stanford de 2005 (bloguei sobre isso em 2007 também):

No começo do ano legendei o documentário da Discovery Channel que conta a história do retorno de Steve à Apple até o sucesso do iTunes + iPod (foi em Janeiro deste ano):

Your browser does not support the video tag. [Direct Link](https://s3.us-east-2.amazonaws.com/blip.tv/Akitaonrails-iPodRevolutionPtBR748.m4v.mp4)

Se você não conhece esta história, vale a pena assistir. Se já viu, vale a pena rever. Coincidentemente, a história de Steve segue o Monomito, ou a jornada do herói, a receita das grandes histórias detalhada por Joseph Campbell na sua famosa obra O Herói de Mil Caras. Ele resume:

“Um herói se aventura a partir do mundo rotineiro comum a uma região de maravilha sobrenatural: forças fabulosas são encontradas lá e uma vitória decisiva é ganha: o herói retorna dessa aventura misteriosa com o poder de conceder bênção a seus semelhantes”

A Jornada do Herói descrita por Campbell se divide em 3 partes: a Partida (Jobs e Wozniak na garagem iniciando a Apple); a Iniciação (a queda de Steve da Apple nos anos 90, seus desafios e aprendizados com a NeXT e a Pixar) e o Retorno (o retorno à Apple em 1997 e os sucessivos lançamentos que tiraram a Apple da quase-falência até a posição de empresa mais valiosa dos Estados Unidos).

Para mim, o sinal de que “O Império Contra Ataca” havia se transformado em “Retorno de Jedi” estava na simbólica aliança com sua arqui-inimiga Microsoft em 1997, que expliquei no post Para eu ganhar, o outro precisa perder ….

E no fim, é exatamente isso que todos deveriam almejar, como Steve Jobs e outros gigantes: caminhar pelos passos da jornada do herói. Sair do comum, da mediocridade, do conformismo e arriscar, explorar, cair muitas vezes e se levantar quantas forem necessárias.

Nenhum esforço, nenhum suor ou sangue derramado é garantia de sucesso. Retornando ao comercial de 1997, lembre-se:

“Porque aqueles que são loucos o suficiente para achar que podem mudar o mundo, são os que conseguem.”

Que, para mim, é o avesso de outra frase famosa (de autoria desconhecida, mas atribuída a Einstein, Ben Franklin, Rita Mae Brown, a um provérbio chinês e outros):

“A definição de insanidade é repetir as mesmas coisas dia após dia e esperar resultados diferentes.”

Steve Jobs foi o exemplo moderno dos grandes exploradores: os navegantes que atravessaram oceanos para encontrar o novo mundo, os cientistas que quebraram crenças antigas, e assim por diante. Ninguém mandou que fizessem aquilo. Fizeram por conta própria, para sustentar crenças que, na época, só eles defendiam, mesmo que os chamassem de loucos e transgressores. E o tempo provou que os loucos eram justamente os que os chamavam de loucos.

Steve Jobs foi um exemplo moderno de como a visão de um único indivíduo é capaz de moldar grandes porções de uma sociedade inteira, como expliquei em fevereiro. Ele foi um dos candidatos mais próximos de um Howard Roark moderno.

Também coincidentemente, Steve trabalhou até perto de um mês antes de morrer, mais do que eu e mais do que você, tenha certeza. Trabalhou durante os sete anos em que enfrentou o câncer. Finalizou seu trabalho repassando o bastão a pessoas de confiança que entendem sua filosofia, como Tim Cook e Phil Schiller. Conseguiu até terminar sua biografia, e só tirou “férias”, forçadas, no último mês de vida.

Não lembro onde vi isto certa vez, mas uma frase combina perfeitamente com tudo isso:

“Se não for para se tornar o melhor naquilo que faz, para que fazer?”

Para terminar, deixo os tweets que lancei logo que soube que Steve havia falecido, ensaiando para este tributo pessoal:

“Don’t despair or moan too much. Be thankful to have lived in the same generation as Steve. Now, what will do you do with this privilege?” – 4 horas atrás

“Did you slow down because of Steve’s death? That’s not how you honor him: speed up your own accomplishments, that’s what he would’ve done.” – 4 horas atrás

“U ppl that are sad. U had the chance to witness ‘miracles’. Stand up. Steve is daring u to live up to what he has started. What will u do?” – 3 horas atrás

“Steve Jobs was great because he lived for himself. It didn’t matter what others complained. And in the process everybody benefitted.” – 3 horas atrás

[Off-Topic] Disney, História do Computador e o Encarte Perdido

Sun, 25 Sep 2011 02:41:00 -0300

Nos últimos eventos em que palestrei, apresento uma seção meio “nostálgica” onde um dos itens que mostro é sobre a seguinte revista em quadrinhos:

Esta revista foi lançada em novembro de 1984. Não lembro exatamente quando meu pai a comprou para mim, mas provavelmente foi entre novembro e dezembro daquele ano, quando ainda estava em circulação. Não fazia nem um ano que a Apple tinha lançado o primeiro Macintosh, que inaugurou a primeira geração de desktops com interface gráfica e mouse.

Eu ainda era criança nessa época, mas já tinha apreciação por computadores, especialmente a “atividade” de controlar a máquina pelo teclado. Minha brincadeira era trocar a sensação de digitar num teclado pela de datilografar numa máquina de escrever mecânica, exercício que até hoje me mantém touch-typist.

Esta revista foi especial por um motivo. A maioria dos “hackers” se foca em controlar o computador, em programá-lo, em “hackeá-lo”. A revista me abriu para um horizonte maior: a história dos computadores.

Naquela época não tínhamos Google e muito menos Wikipedia. Felizmente meus pais, sempre preocupados com educação, já tinham a enciclopédia Mirador, de onde eu pude aprofundar o assunto. Foi assim que, nos anos 80, alguns dos meus “heróis de infância” viraram Charles Babbage, Konrad Zuse, John von Neumann e Robert Noyce. Somados a outros nomes que ajudaram a formar meu raciocínio, como Carl Sagan, essa revista foi um pilar importante na minha formação nos anos seguintes.

Recomendo como leitura para qualquer criança. É leve e instrutiva, com um toque Disney. Eu ainda guardo meu exemplar, já razoavelmente surrado depois de mais de 26 anos. Nos últimos dias resolvi escanear suas páginas e montar um PDF, que você pode baixar neste link. Fiz também uma versão em EPUB, boa pra ler duas páginas lado a lado num monitor widescreen. Não sei quanto a direitos autorais depois de tanto tempo, ainda mais sem a chance de encontrar uma cópia para comprar hoje em dia. Se alguém me enviar uma notificação de cease and desist, eu retiro. Até lá, divirtam-se.

Um dos motivos para publicar isso é encontrar outras pessoas da mesma época que tenham comprado e ainda guardem seu exemplar. A revista tinha um encarte central em papel glossy, com 32 páginas, detalhando o lançamento do Macintosh original, com artigos sobre o MacPaint e outras coisas. Se alguém tiver, eu adoraria pelo menos os scans dessas páginas. Na época eu gostava tanto do encarte que acabei destacando ele da revista, e, soltas, essas páginas se perderam. Não deixem de comentar aqui embaixo se tiverem um exemplar!

Aproveitem!

[Documentário] The iPod Revolution

Sun, 30 Jan 2011 12:23:00 -0200

Pelo que consegui pesquisar, em 27 de dezembro de 2006 o Discovery Channel apresentou o documentário “The iPod Revolution: Inside Story of the Apple iPod and Steve Jobs”.

Esse documentário é muito bem produzido. Em 40 minutos ele resume a história da Apple de 1997 a 2006, cobrindo quase uma década que vai do retorno de Steve Jobs ao lançamento do iPod e ao sucesso gigantesco da iTunes Music Store. E isso é só metade da história: o iPhone só seria revelado em janeiro de 2007, então o enredo é ainda maior.

Sempre recomendo pesquisar essa história porque ela é muito interessante e engajante. Para mais detalhes leiam os livros:

The Perfect Thing: How the iPod Shuffles Commerce, Culture, and Coolness – do Steven Levy.
The Cult of the iPod – do Leander Kahney que também aparece no documentário.
iCon Steve Jobs: The Greatest Second Act in the History of Business – do Jeffrey Young e William Simon.

Como sempre mostro esse vídeo aos amigos que se interessam, resolvi que já passava da hora de legendar. Nem todo mundo a quem mostro é da área de tecnologia e, pra variar, inglês é um problema, mas isso é outro assunto. Se quiserem o arquivo de legenda, criei um Gist com ele. Para legendar usei o Miyu, para renderizar a legenda no vídeo usei o Submerge, e por fim subi tudo na minha conta no Blip.tv. Assistam a seguir:

Claro, o vídeo é propriedade da Discovery Channel, com todos os direitos reservados. Este material não deve ser usado para fins lucrativos. Ele já está disponível em vários outros sites, mas retiro o vídeo se for preciso. Caso eu retire, ainda há outras fontes, por exemplo no YouTube:

Mas a história é bem mais interessante que isso. Já li e assisti todo o material disponível sobre o assunto desde 1983. Pesquisando, encontrei alguns pedaços dessa história no YouTube também. Seguem mais links de vídeos:

1983 – Neste keynote, um jovem Steve Jobs, que acabara de transformar a Apple numa superpotência, fala sobre seus planos para um novo computador que seria lançado em 1984. É um discurso épico. No final, ele apresenta o comercial mais famoso do mundo, o 1984, dirigido por Ridley Scott e exibido uma única vez, no Super Bowl do ano seguinte.
Boston Macworld 1997 – Steve Jobs foi afastado da Apple em 1985 e retorna mais de 11 anos depois a uma Apple devastada, perdendo US$ 1 bilhão por ano, com gente como Michael Dell dizendo Se eu fosse a Apple, fecharia tudo e devolveria o dinheiro aos acionistas. Ele expõe os problemas, aponta os pontos ainda fortes da Apple e traça uma estratégia de recuperação totalmente contrária à de todos os “analistas”. Recomendo a qualquer um que se preocupe com gestão: como se reerguer de uma queda.
Macworld 1998 – Um ano depois do retorno, Steve já reformou toda a Apple e lança o primeiro produto que marca esse recomeço: o iMac colorido. Era um computador voltado principalmente ao nascente mercado de internet para consumidores. Lembrando que ainda é o começo da primeira bolha da internet.
iPod Introduction 2001 – Trecho da apresentação em que Steve mostra o iPod pela primeira vez. Foi um evento fechado, dentro do campus da Apple, apenas para jornalistas convidados. O primeiro dia de uma revolução como nenhum dos presentes poderia imaginar.
iTunes Store Introduction 2003 – Com softwares como Napster e Limewire permitindo baixar músicas de graça, como vender um sistema em que você precisa pagar pela música? Esse vídeo mostra como Steve conseguiu. O mais importante foi dobrar os Big 5 da indústria musical a aceitar um preço único e fixo para faixas avulsas e álbuns, e convencer os artistas a fragmentar os álbuns para vender músicas individuais.
“iPhone Introduction 2007” – Este é genial. Depois de dois anos e meio trabalhando em segredo, em meio a rumores crescentes sobre um iPod-phone, veja como Steve redefiniu o mercado de smartphones. Um ponto fundamental: o controle dos aparelhos sempre foi dos carriers, mas Steve negociou um contrato inédito com a Cingular (hoje AT&T) em que o aparelho continuava sob controle da Apple. Ou seja, nada de aplicativos de marketing pré-instalados e coisas do tipo. Neste ano acabou a exclusividade com a AT&T, e a Apple acaba de anunciar o iPhone em versão CDMA para os potenciais 93 milhões de clientes da Verizon.
Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Part 7
Part 8
Part 9
“iPad Introduction 2010” – Aqui ele revela o iPad, que todos diziam que seria ruim, que não pegaria, que não teria graça. Hoje virou recorde de vendas e foi eleito produto do ano.
Part 1
Part 2
Part 3
Part 4
“The Fall and Rise of Apple” – Este é um resumo da história de queda e como a Apple se reergueu, no contexto geral do mercado e de seus produtos:
Artigo 1
Artigo 2
Artigo 3
Artigo 4
Artigo 5
Artigo 6

Para fechar: no documentário, a Apple começa 1996 em péssimo estado, perdendo US$ 1 bilhão por ano, com as ações caindo para US$ 17 cada. Agora, no fechamento do último trimestre de 2010, ela vendeu 16,24 milhões de iPhones só nesse trimestre, além de 7,33 milhões de iPads, 19,45 milhões de iPods e 4,13 milhões de Macs. Repetindo: só no trimestre.

Até agora a Apple já vendeu mais de 14 milhões de iPads desde o lançamento, em abril do ano passado. E a ação está em US$ 340. Quem comprou em 1996 e segurou viu o capital crescer quase 80 vezes em 15 anos, contando os splits que a Apple fez em 2000 e 2005 (via comentário do @cassiozen, abaixo). Um excelente investimento.

AkitaOnRails, Retrospectiva 1985-2007

Sun, 12 Aug 2007 02:02:00 -0300

Alguns leitores comentaram que eu deveria fazer uma “auto-entrevista”. Falar de mim mesmo é estranho, mas falsa humildade nunca foi meu forte. Em vez de entrevista, resolvi fazer uma retrospectiva. Não chega a ser uma biografia completa, claro, são só alguns pontos-chave dos meus últimos 22 anos (antes disso eu ainda não sabia ler direito :-)

Talvez seja nostálgico para alguns, o que é sempre bom. Para os mais novos, talvez sirva para mostrar que currículo não se faz só com certificados. Experiência depende de tempo, muito tempo, mas quantidade de tempo não é sinônimo de qualidade. Tudo depende de juntar o que você realmente quer com o que você realmente gosta. Não é para todo mundo, mas quem tem esse instinto sabe do que estou falando.

O caminho é longo e sem fim, então nunca diga “já sei tudo que preciso”. Você nunca saberá tudo que precisa. Aprender é um processo diário, hora após hora: um pouco durante o trabalho, muito mais fora dele.

Quem sabe o que está fazendo não está nem aí para o que os outros dizem ou fazem. Você apenas faz o que sabe (não o que “acha”) ser o melhor caminho. Certo e errado é cara ou coroa: na média, você acerta 50% das vezes, como todos os outros. O “caminho certo” se define analisando os fatos que você conhece. Aprendeu algo novo? Refaça a análise e revise o caminho.

Dogmas são inúteis. Mantenha-se racional e disciplinado e suas chances aumentam. Nunca feche as próprias portas: seja seletivo no que aprender, mas não descarte opções por preconceito.

Faça o que gosta. É chavão, eu sei, mas é a única coisa que funciona. Meu currículo não começou no meu primeiro emprego: dediquei a vida inteira a isso, desde que me entendo por gente, e nunca tive plano B. Você não precisa ser assim, e isso não significa que eu saiba muito. Conheço muita gente mais nova, que começou há menos tempo e já sabe bem mais que eu.

Outro dia disse a um amigo: “somos todos alvos móveis”. Se você tem um ídolo, é porque ele é algo que você gostaria de ser. Você corre nessa direção e, quando chega ao nível que queria, seu ídolo já correu algumas léguas a mais. E lá vai você correr atrás de novo.

De novo: não existe receita, não existe guia passo a passo. Nem todos podem ser pintores, estilistas ou jornalistas. Eu definitivamente não sou bom cozinheiro, dificilmente serei bom marceneiro e com certeza nunca serei músico. Ninguém deveria escolher uma ocupação só pelo que paga melhor hoje. E amanhã?

Em 1985 fui inspirado pela primeira vez por uma revista em quadrinhos: uma edição especial da Disney chamada, se não me engano, A História dos Computadores. Se alguém ainda tiver, com o encarte central e em bom estado, estou interessado em comprar! Guiado pelo Prof. Pardal e pelo Prof. Ludovico, conheci Charles Babbage, Blaise Pascal, Konrad Zuse e outros nomes que nunca esqueci. Me considero um “arqueólogo da computação” desde essa época e volto ao assunto até hoje, por enciclopédias, livros e artigos. Meu sonho de consumo era um Unitron, o clone nacional do Macintosh original, recém-lançado.

Em 1987 meu primo tinha um MSX Hotbit e eu queria brincar com os jogos dele. Aprendi um pouco de Basic para dar load nos jogos em cassete. Minha leitura preferida era a revista Micro Sistemas, e Assembler ainda era inatingível para mim. Meu sonho de consumo era um CP-500 que um conhecido tinha. Tentei ler um livro de eletrônica, mas era demais para mim: nunca fui bom nisso. Estava só começando a entender o que significava “expandir RAM”.

Havia muitos micros legais nessa época. Hoje todo mundo admira os celulares novos nas vitrines; na minha época eu ficava nas vitrines dos clones de Apple II, do MSX da Gradiente, do Sinclair, do TK-90X, do CP-400. Eram caros demais para eu ter um, então só me restava imaginar as máquinas lendo as especificações técnicas.

Em 1988 fiz um curso de GW-Basic. Não tinha computador, mas aprendi a programar no papel. Também tive meu primeiro contato com pérolas da época como Wordstar e Lotus 1-2-3. Acho que foi por aí que comecei a ficar viciado em videogames: já tinha um Intellivision e finalmente ganhei um Master System!

Em 1989 ganhei meu primeiro PC-XT e aprendi dBase III e Clipper Summer 87. Tinha dois tios que programavam desde o Autumn 86. Foi quando escrevi minha primeira apostila, que de original não tinha nada: eu copiava textos de livros e enciclopédias só porque gostava de treinar datilografia. Graças a isso hoje chego a 400 tpm (toques por minuto), além de algumas dores estranhas nas mãos :-) Antes do XT, meu hobby era copiar textos na boa e velha Olivetti; com o teclado de computador, bem mais leve, meus dedos agradeceram. Desde o ano anterior minha leitura favorita era a saudosa revista Micro Sistemas, uma das poucas opções de qualidade na época.

Em 1990 fiz bicos com meu tio, que era analista de sistemas. Fiz vários sisteminhas em Clipper 5.0 e FoxPro, bons tempos de Ashton-Tate e Nantucket. Criei meu próprio editor de textos em Clipper, mas não fui páreo para o bom e velho Norton Editor aliado ao Sidekick. Havia poucas opções de linguagens e dava para passar meses numa só. Infelizmente nunca me interessei muito por linguagens de baixo nível como Assembler e C: li alguns livros, mas nunca pratiquei. Grave erro.

Em 1991 comecei a brincar de BBS com meu vizinho. Fui apresentado aos poderes do Pascal, ainda só olhando de longe. Bons tempos de FidoNet, PCBoard, Remote Access, Warez, blue box e afins. Muito antes da era do Orkut e do MSN, eu já gastava horas a fio em message boards. Meu sonho de consumo era conseguir rodar o Windows 3.1 no meu XT com monitor CGA verde.

Em 1993 trabalhei como apresentador de jogos na Brasoft Games durante as férias. Foi interessante porque tive acesso aos “MPC”, os PCs multimídia com CD-ROM e placa de som, itens opcionais e caros na época. Nunca vou esquecer as pérolas da LucasArts, como Day of the Tentacle. Nada a ver com programação, mas foi importante para o meu senso de estética e de possibilidades. Obras-primas da época? Wolfenstein e Doom, os originais, claro.

Em 1993 (ou teria sido 1992?) eu gostava de desenhar. Brinquei de ilustrador até mais ou menos 1998, quando desisti de vez. Nesse ano queria fazer ilustrações para uma revista de games (já disse que eu era viciado?). Levei meu portfólio ao editor e ele recomendou que eu aprendesse a ilustrar por computador, porque eu só tinha desenhos à mão livre. Voltei para casa e no mesmo dia comprei um livro de CorelDraw! 3.0, um calhamaço da editora Berkeley que lembro até hoje. Algumas semanas depois voltei com um portfólio novo, todo em CorelDraw!. Fiz ilustrações para umas seis edições, escrevi um artigo, colaborei aqui e ali, e desisti: não era minha vocação. Mas as noções de curvas de Bezier e vetorização ainda seriam úteis quando resolvi aprender Flash.

Em 1994 fiz minha única pausa dos hobbies e dos computadores: ano de vestibular. Estudava pelo menos 8 horas por dia, 7 dias por semana. Estabeleci objetivos, planejei e passei. Nunca tive segunda opção, então só me restava passar de primeira: USP e Unicamp, no mínimo, eram obrigação. Foi a grande lição desse ano: estabeleça objetivos, trace o plano, siga cada passo corrigindo a rota no caminho, mas não pare.

Em 1995 entrei na USP. No primeiro semestre tive que entregar trabalhos em Turbo Pascal e fiz meu primeiro framework, um toolkit gráfico para Pascal, além de alguns truques de fractais. Finalmente entendi a importância das décadas anteriores da computação e virei fã de Donald Knuth e Niklaus Wirth.

Ganhei minha primeira conta de acesso à internet, com um porém: só via terminal Unix. Tive que aprender Unix para usar a internet. Gopher, Lynx, Pine, bons tempos. Foi também a primeira vez que lidei com uma grande deficiência: meu péssimo inglês. Quando vi que alguns colegas da faculdade eram bons, decidi que não podia ficar para trás (e daí nasceu o artigo Seja Arrogante!). Era uma época pré-Google: eu usava as primeiras versões do Yahoo!, do WebCrawler, até a Amazon (que era feinha).

Este também foi o ano em que mais esperei por um software: o Windows 95. Li tudo que encontrei a respeito e nunca destrinchei tanto um sistema operacional; na verdade, desde o DOS 3.1 eu explorava cada canto e cada beco. Também estava empolgado com o novíssimo OS/2 Warp, uns 20 disquetes de 3,5", se não me engano! Rodar o Windows 3.1 virtualizado no OS/2 era incrível, a mesma sensação que tive anos depois ao rodar o Windows XP virtualizado no meu OS X pela primeira vez. Foi por causa desses assuntos que finalmente me interessei por arquitetura de sistemas e pela evolução dos sistemas operacionais.

Em 1996 fiz um bico num sisteminha para Windows 3.1 (eu sei, eu sei). Aprendi Delphi 1.0, lançado um ano antes. Eu já era fã de Turbo Pascal, então o Object Pascal foi natural: meu primeiro passo rumo à “moda” da época, a tal Orientação a Objetos. O UML apareceu nessa época, mas antes dele eu já bisbilhotava as metodologias originais: Booch, Objectory, Fusion. Sempre achei o assunto meio chato.

Também comecei a aprender Java 1.0, depois de baixar os betas no FTP da Unicamp. Mas o AWT não me pareceu bom o suficiente e continuei com o Delphi. Estranho pensar nisso hoje: naquela época a Borland parecia tão grande.

Fiz alguns sites pessoais sobre meus hobbies. Pois é, já fui fanático por animes e mangás, e fiz meu primeiro site de “sucesso”, entre aspas mesmo, porque eu causava polêmica até nos meus hobbies. Não havia nada em português sobre o assunto, então traduzi mangás e fiz legendas de anime. Sei japonês desde criança, o que ajudou, e não é de hoje que faço traduções :-) Fazendo sites pessoais, destrinchei todos os truques possíveis da época só com HTML, JavaScript e muito Photoshop. Brinquei um bocado com redes Windows for Workgroups e OS/2 1.3.

Em 1997 comecei a trabalhar numa produtora multimídia. Evoluí no web design, pude trabalhar com Macs (no saudoso System 8) e tive que aprender Director 5/Lingo e Flash 2/ActionScript. Desenvolver aplicações interativas em Director num Pentium 200 MHz com 32 MB de RAM não era exatamente confortável, mas era divertido. Perdi a conta de quantas vezes dormi no chão da empresa esperando arquivos gravarem em Zip drives, ou CDs queimando a 2x.

Nessa época o Linux já era bastante famoso. Fiz minhas primeiras tentativas de evoluir meu Unix com um RedHat 4.2, cuja caixinha azul com o logo vermelho nunca vou esquecer. Alguns anos antes eu tinha tentado o Slackware 1.0, mas desisti depois de instalações frustradas, hardware incompatível e problemas de drivers.

Em 1998 tive meu primeiro contato com server-side: Microsoft Index Server, SQL Server 6.5 e ASP. Não foi muito divertido, mas pelo menos aprendi bastante SQL. Newsgroups sempre foram meu ponto de apoio, e o site DejaNews foi um achado: uma coletânea indexada da Usenet, que hoje se chama Google Groups. Meu uso desse tipo de serviço caiu bastante. Será que a qualidade caiu junto?

Em 1999 tive que desenvolver sites em PHP e alguns scripts em Perl para Apache. Aprendi expressões regulares na marra: eu já deveria saber Regex, então aprendi de uma vez, e hoje faz muita diferença. Tive que evoluir no Linux e em todo o ferramental em volta, e felizmente o RedHat 7 da época já era muito bom. Fiz várias brincadeiras com protocolos e entendi a importância de conhecê-los. Não lembro como nem por quê, mas foi quando virei leitor assíduo do Slashdot, minha leitura diária, religiosamente, desde então.

Em 2000 tive que desenvolver um site em Zope/Python. Sempre imaginei que aquele sistema, com os conceitos de ZODB, Products e DTML, tinha potencial para crescer muito. Cresceu, mas não como eu imaginava. Hoje acho o Plone legal, mas com a sensação de que perdeu a janela de mercado. Foi meu primeiro contato com Python e a primeira vez que ouvi falar de uma linguagem chamada Ruby, à qual não dei importância na época.

Em 2001 tive que desenvolver vários sites e sistemas com ASP e outras tecnologias Microsoft, como VB e DCOM (é preciso respeitar o Don Box). Lidar com limitações é sempre um excelente caminho para evoluir: quando se tem muito, se esbanja; quando se tem pouco, se aprende a otimizar. Gerar componentes DCOM usando VBScript era divertido. Eu fazia muito “Ajax”, só que na época não se chamava assim (MSXML e DHTML já existiam), e muitos “Web Services”, que também ainda não tinham esse nome (HTTP e XML já existiam, claro). Impressionante como meia década depois essas coisas voltam com outros nomes e todo mundo acha que é novidade.

O .NET parecia muito legal na Beta 1, e lembro de ter feito um framework para ASP com conceitos do ASP.NET. Pode parecer estranho pular do mundo Linux do ano anterior de volta para o Windows Server. Nunca entendi por que, para gostar de uma coisa, você “precisa” criticar a outra. Minha função sempre foi uma só: resolver problemas dentro das restrições que me apresentavam, independente de tecnologia e plataforma. Ponto final.

Em 2002 precisei integrar um sistema em ASP com outro em SAP R/3, então tive que aprender ABAP. O livro “Aprenda ABAP/4 em 24 horas” durou, na verdade, 48 horas. Conhecer os conceitos de DCOM e CORBA fez bem: eu já sabia o que era RFC e como lidar com ambiente distribuído. Daqui começa minha “carreira” de garoto de programa (também conhecido como “consultor”): muito trabalho, pouco valor agregado. Meu aprendizado teve altos e baixos nos anos seguintes, e meu ritmo caiu até 2006.

Em 2003 precisei desenvolver sistemas em SAP Portal e Java, e aprendi coisas como Hibernate e Struts. Sem acesso ao código-fonte do servidor Java da SAP, só me restava descompilar as classes e explorar. Também tive que fazer um celular se comunicar com sistemas SAP, codificando os protocolos na unha. Depois dessa escovação de bits, nunca mais esqueci a diferença entre Big Endian e Little Endian, nem como é chato lidar com o protocolo iDEN. Lidei com criptografia e reforcei minhas noções de segurança, encriptação e autenticação. Nunca é demais ser paranoico.

Em 2004 precisei de um sistema de versionamento e aprendi Subversion. Nunca tive boa impressão do CVS. O Subversion ainda era beta, cheio de bugs, e cheguei a fazer um patch para o TortoiseSVN funcionar com o Visual Studio .NET, mas eu sentia que o SVN seria grande. Felizmente, estava certo. Acho que foi o ano em que mais programei Java: cacei todo tipo de bug no SAP Portal recém-lançado, criei um framework produtivo sobre o ruim que vinha com o produto e fiz muita integração com sistemas R/3.

Em 2005 precisei integrar sistemas de telecomunicação e aprendi um pouco de Tuxedo/C++. ESB, SOA e outros acrônimos do tipo se provaram bullshit de vendedor, como eu sempre disse. Comunicação e integração nunca foram novidade: trocar o nome para parecer novo não ajuda. EAI é uma das coisas mais velhas do mundo; desde que o segundo computador foi criado, integração já existia. Nessa época eu cutucava o mundo de gerência de projetos e me convenceram a me certificar como PMP. Perda de tempo: me certifiquei, mas nunca gostei do método. Passei um tempo estudando CMMi e outras metodologias e perdi o interesse rápido. Já sei que não tenho vocação para muita conversa.

Em 2006 tive que lidar com mais sistemas de telecomunicação, agora com webMethods. Mais “SOA”, mais “XML”, sem problemas. Por que todo mundo sofre para integrar sistemas híbridos? Quem sabe SAP não sabe webMethods, quem sabe webMethods sabe pouco Java, quem sabe Java não conhece os outros dois. Tudo falta de vontade.

Em paralelo, Rails entrou na jogada e lá fui eu escrever um livro. Impressionante como a coisa estourou lá fora e ninguém aqui deu a devida atenção. É o velho problema do ovo e da galinha: o programador não aprende porque não tem mercado, o mercado não se interessa porque não tem programador. Um dos lados tem que dar o primeiro passo. Os americanos são peritos em dar primeiros passos; nós somos doutores em esperar o tempo passar. Mas eu nunca dei atenção aos outros. Um mês e meio escrevendo quase me deixou louco, dormir 4 horas por noite não é normal. O livro saiu, o blog está aqui e, mais importante, eu aprendi muito. Felizmente mais gente está se interessando pelo assunto. Quem sabe em breve a gente ultrapasse o ponto de inflexão entre número de profissionais e interesse do mercado.

Finalmente, em 2007 eu estava cansado da consultoria e dos clientes. Fazer vista grossa a coisas idiotas nunca foi do meu feitio. Abandonei quem nunca me apoiou de verdade e resolvi voar solo. Se algum dia ouvirem a palavra “Balance”, corram! Falo sério! Mas boas coincidências acontecem: depois de quase um ano e meio falando sobre Rails, finalmente pude trabalhar com isso em tempo integral.

E aí vem a questão: o que me contrataram foi o resultado dos últimos 22 anos. O ano de Rails pesou pouco.

Espero que isso tenha atiçado a curiosidade de todos. As biografias do pessoal que entrevistei ultrapassam muito a minha, e conheci várias pessoas com histórias bem melhores. A minha, por ora, está razoável.

Como disse antes, também sou um alvo móvel. Amanhã estarei escrevendo a retrospectiva de 2007, 2008, 2009. Ano que vem saberei muitas coisas que não sei hoje, e não por acidente: todo mundo aprende algo novo, a menos que seja um vegetal. Estou falando de esforço consciente para aprender.

Não vou estagnar no Ruby, por mais que goste dele. Não importa se a novidade vem do mundo open source, da Apple, da IBM ou da Microsoft: temos que observar tudo. Um cozinheiro com 10 anos de casa que só sabe fazer a mesma meia dúzia de pratos é um autômato, não um mestre. Dez ou vinte anos não fazem diferença. E autômatos são facilmente substituíveis.

Off-topic: MacWorld 2007 - Steve Jobs anuncia o esperado iPhone!

Tue, 09 Jan 2007 11:34:34 -0200

Este keynote entrou para a história, definitivamente!

Todo Railer que se preze gosta da Apple, então imagino que todos já saibam: acabou de terminar (17:07) o keynote do Steve Jobs em São Francisco, na MacWorld 2007. Os rumores foram enormes nos últimos dias, nunca houve keynote tão esperado, e Jobs não decepcionou. Detalhes, transcrição e fotos na cobertura ao vivo da Engadget.

Deixando de lado o Apple TV (cujo protótipo, ainda chamado iTV, foi mostrado num evento especial em setembro de 2006), a pérola do show foi o iPhone: um iPod, um celular e um comunicador de internet, como Jobs definiu, 3 em 1. Os padrões de celulares e smartphones foram para o buraco; a Apple acabou de subir a barra a níveis estratosféricos. A lista:

4GB ou 8GB de memória flash
tela de alta resolução de 3.5" com 160ppi

Apenas 1 botão; todo o resto é a tela widescreen multitoque com 3 sensores (proximidade, luz ambiente e acelerômetro). Quer dar zoom numa foto? Encoste dois dedos na tela e afaste um do outro!

sincroniza com o iTunes (músicas, vídeos, fotos, contatos, calendários)

WiFi, Bluetooth 2.0, quad-band GSM+EDGE (nos EUA, pela Cingular/AT&T)
câmera digital de 2 Megapixels

Roda o OS X (!), e o Safari foi mostrado funcionando como browser. Integração com Google Maps, Yahoo Mail, POP3, IMAP. Vai além do BlackBerry

5 horas de bateria, 16 horas só de áudio
acessórios: fone de ouvido com microfone embutido no cabo (um apertinho no botão atende a ligação) e o menor e mais elegante fone bluetooth que já vi

Os preços são salgados, mas condizem com um aparelho excepcional: US$ 499 pelo modelo de 4GB e US$ 599 pelo de 8GB, com contrato de dois anos. E a partir de hoje a Apple Computer, Inc. passa a se chamar Apple, Inc.. Faz todo sentido: os produtos da Apple já estão no nosso quarto (iMac), no escritório (MacBook, Mac Pro), nos carros (BMW, Audi e outros), na sala (Apple TV) e nos bolsos (iPod, iPhone). Impressionante, para dizer o mínimo.

As ações da Apple fecharam o dia em alta de mais de 8%, e o Leopard nem foi mencionado! A meta é 1% de um mercado de quase 1 bilhão de celulares vendidos por ano: algo como 10 milhões de iPhones até o fim de 2008. O produto será lançado em junho nos EUA. Espero que chegue aqui logo!

Se alguém achar um link para baixar o vídeo do keynote (espero que saia logo no BitTorrent), avisa!

Off-topic: MacWorld 2007 - Keynote do Steve Jobs

Tue, 09 Jan 2007 08:18:13 -0200

Em menos de uma hora, às 15h em Brasília, 9h no horário do Pacífico, Steve Jobs sobe ao palco da MacWorld Conference & Expo 2007, em São Francisco. O keynote poderá ser acompanhado ao vivo por vários sites (veja a lista atualizada).

Esse keynote vem gerando dezenas de rumores e artigos pela indústria inteira. A revista Forbes publicou ontem All Eyes On Apple and Jobs, e com razão: ninguém na indústria cria tanta expectativa quanto a Apple de Steve Jobs.

A imagem enigmática acima apareceu no site da Apple alguns dias atrás e alimentou boa parte dessa expectativa. O que eles querem dizer com isso? Uma simples mensagem corporativa de “feliz ano novo”? Vinda da Apple? Provavelmente não.

Na WWDC 2006, Steve anunciou algumas das principais funcionalidades do próximo sistema operacional, Mac OS X 10.5 Leopard, que deve sair ainda este trimestre. Na ocasião ele mostrou o famoso slide “Top Secret”: existiam novidades que eles não iam revelar, para a Microsoft não copiar antes da hora. Será que chegou a hora de conhecermos esses segredos?

Enquanto isso os rumores continuam. Steve vai anunciar a aposentadoria? Um novo Mac para comemorar os 30 anos da Apple? Um MacBook subnotebook com armazenamento em estado sólido? O tão badalado iPhone, a combinação de iPod com celular? O lançamento imediato do Leopard?

Ou serão só novidades menores: o já conhecido iTV, novas versões do iTunes e do iLife, detalhes secundários do Leopard? Ou o padrão de sempre, um Mac Mini com processador Core 2 Duo e um Mac Pro com os novos Dual Quad Xeon?

Fiquem de olho. Os keynotes de MacWorld do Steve Jobs sempre são bombásticos. Basta lembrar 1997.