Apple | AkitaOnRails.comhttps://akitaonrails.github.io/tags/apple/Blog do Fabio Akita do Canal do YouTube 'Akitando' falando sobre tecnologia, carreira e coisas geek.Hugo -- gohugo.iopt-BRMon, 19 Oct 2026 23:20:48 +0000[Akitando] #56 - Falando um pouco de MAC, LINUX e WINDOWS | Qual eu devo escolher?https://akitaonrails.github.io/2019/07/24/akitando-56-falando-um-pouco-de-mac-linux-e-windows-qual-eu-devo-escolher/https://akitaonrails.github.io/2019/07/24/akitando-56-falando-um-pouco-de-mac-linux-e-windows-qual-eu-devo-escolher/Wed, 24 Jul 2019 17:00:00 -0300<div class="embed-container"> <iframe src="https://www.youtube.com/embed/brIQSA8FtDo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <p>No episódio de hoje, pegando carona que eu fiz um vídeo sobre instalar ambiente de desenvolvimento em Ubuntu (<a href="https://www.youtube.com/watch?v=epiyExCyb2s"target="_blank" rel="noopener">https://www.youtube.com/watch?v=epiyExCyb2s</a>) eu queria aproveitar pra contar vários pequenos momentos e conceitos sobre sistemas operacionais que eu gosto de ficar discutindo.</p> <p>No geral eu poderia dizer que é um vídeo “comparando” Linux, Mac e Windows mas a idéia não é escolher um no final mas sim delinear o que aconteceu nos últimos 20 e tantos anos que me fez ficar mudando de sistemas e hardware ao longo do tempo e porque existem algumas opiniões formadas hoje que quem está só começando não consegue entender porque as recomendações são extremas em muitos casos.</p>

No episódio de hoje, pegando carona que eu fiz um vídeo sobre instalar ambiente de desenvolvimento em Ubuntu (https://www.youtube.com/watch?v=epiyExCyb2s) eu queria aproveitar pra contar vários pequenos momentos e conceitos sobre sistemas operacionais que eu gosto de ficar discutindo.

No geral eu poderia dizer que é um vídeo “comparando” Linux, Mac e Windows mas a idéia não é escolher um no final mas sim delinear o que aconteceu nos últimos 20 e tantos anos que me fez ficar mudando de sistemas e hardware ao longo do tempo e porque existem algumas opiniões formadas hoje que quem está só começando não consegue entender porque as recomendações são extremas em muitos casos.

Antigamente a gente pedia “pelamor” pros desenvolvedores darem uma chance pros Macs. Hoje em dia o povo não entende porque tem tanta gente ainda recomendando Macs tão veementemente. E no fim, qual é a melhor escolha pra desenvolvedores de software? Vamos descobrir isso hoje.

== Errata

Eu falei que Fedora usa Yum, mas não é verdade, eu esqueci que agora ele usam DNF.

== Seções:

03:03 - Linux 14:00 - Mac 32:45 - Windows

== Links:

=== Script

Olá pessoal, Fabio Akita

Seguindo na discussão sobre instalação de ambiente de desenvolvimento de software, eu acho que preciso responder, por que diabos eu uso Windows 10? E na realidade a resposta é bem menos interessante do que parece.

A resposta mais simples é porque na prática não faz quase nenhuma diferença se você estiver usando hardwares como o meu. O episódio de hoje vai ser longo, porque eu comecei a escrever e fui jogando vários assuntos aleatórios na mistura. Quando começamos a falar de sistemas operacionais eu tenho vários conceitos e histórias que acho importante dar contexto. A idéia foi trazer vários pontos que eu considero interessantes e falar tudo de uma vez do que tentar diluir em múltiplos episódios. Mas no final eu acredito que vocês vão sair com um entendimento maior do que simplesmente diferenciar um sistema de outro pelo visual, então tenham um pouco de paciência hoje.

(…)

Desde pelo menos 2013 eu não uso computadores com menos de 16GB de RAM. E recentemente meus dois computadores principais, um Lenovo Thinkpad Extreme e um PC torre que comprei da Rocketz ano passado, tem 32GB de RAM. Ambos tem placas NVIDIA, o primeiro com um GTX 1050 que é mais que suficiente pra um notebook, e o segundo com um bom GTX 1070Ti do ano passado que não é topo de linha, mas até pra gaming 1080p a mais de 100fps é bem suficiente.

Meu primeiro Mac foi um Mac Mini G4 de 2003 com processador Power PC G4 de 1.25Ghz, não lembro se tinha 2GB de RAM, HD mecânico de 40GB, mas praquela época já tinha USB-2 e Firewire 400. Eu lembro que brinquei muito de editar vídeos com iMovie e gravar em DVD. Eu tive depois o primeiro Macbook branco de 13" com processador Intel Core Duo. E meu último Mac foi um Macbook Pro 15" de 2014 com tela retina display, Core i7, 16GB de DDR3, 512GB de SSD e vinha com a GeForce GT 750M com 2GB de GDDR5. Na minha opinião a última série de Macbook Pro ainda à frente do seu tempo, quando o teclado ainda era bom, quando não tinha touchbar, quando havia Magsafe pro cabo de força.

Mas, eu acho que a grande maioria das pessoas assistindo não está muito disposto a gastar mais que 1000 dólares numa máquina, de preferência menos. E eu concordo com vocês, especialmente se eu tivesse 25 anos eu não poderia comprar nada muito mais caro que 500 dólares, e parcelado, claro. Como eu já disse no episódio de Ubuntu, vocês não precisam de uma máquina tão topo de linha assim. Em desenvolvimento de software, a menos que você esteja programando apps Android e precisa subir aquele emulador lento, uma máquina Core i3 Skylake, com 4GB de RAM, e até com HD mecânico deve ser suficiente pra maioria dos casos. Daí com o tempo você troca o HD mecânico por um SSD de 256GB, um HD externo via USB-3, e mais 4 GB de RAM pra ficar com 8.

A idéia não é ser uma divisão perfeita, mas vamos começar essa conversa de hoje falando um pouco sobre Linux primeiro, depois vou falar de Mac e depois de Windows. Se você viu meus episódios da série de Back-end onde eu explico sobre threads e schedulers, já sabe que existem diferentes formas de estratégia pra threads. E os 3 sistemas operacionais principais: Windows 10, macOS e as várias distros Linux usam estratégias de schedulers diferentes. O melhor sendo o CFS do Linux. O MacOS e o Windows implementam multilevel feedback queue, pense em múltiplas filas com prioridades, mas por alguma razão a implementação do Windows continua sendo a piorzinha. É aquele momento que tudo dá uma engasgada, fica um pouco lento, daí volta. Ou você tá assistindo youtube ou netflix, deixa outra coisa rodando por trás e em algum momento seu vídeo perde frames, dá uma engasgada. É o tipo de coisa que acontece com frequência em máquinas fracas. Eu raramente vejo porque tenho máquina sobrando. Mas é uma coisa que em Linux e Mac não acontece nem de longe com tanta frequência mesmo em máquinas mais antigas.

Lembram a metáfora de threads tendo que esperar a vez e o scheduler mudando a thread de mesa às vezes e o custo relacionado a mover os dados de uma core pra outra? Até algumas versões atrás o Windows fazia algo muito burro, não lembro se já corrigiram. Se você tinha cores sem fazer muita coisa, ele pegava a thread em execução e mudava pra outro core. Do nada, em vez de simplesmente manter na core que ele tava. Ele tentava ser preemptivamente mais esperto e isso causava overhead desnecessário. É exatamente o tipo de coisa que raramente acontece no macOS ou Linux. Sendo honesto, eu não tenho visto acontecer no Windows também, mas ainda não sei o quanto é porque meu hardware tá compensando isso.

Falando em schedulers, além de schedulers de threads como o Completely Fair Scheduler ou CFS, também temos schedulers pra I/O como o Completely Fair Queue ou CFQ. Se você usa HD mecânico e muitos processos querem fazer coisas no disco ao mesmo tempo, dá pra imaginar que não dá, então você vai também precisar de algum tipo de queue ou fila pra gerenciar isso. E no Linux você pode trocar os schedulers de threads e os schedulers de I/O.

Numa máquina parruda, com muitos cores sobrando e SSD veloz, você sempre mantém o default que é CFS com CFQ ou noop pra não precisa gastar computação gerenciando filas pro I/O, já que SSDs são ordens de grandeza mais rápidos que HD mecânicos e conseguem lidar com muita concorrência. Se por outro lado você está numa máquina mais devagar, pode mudar do CFS pro MuQSS e do CFQ pro BFQ ou o Budget Fair Queue, além de configurar o swapiness da kernel pra evitar ao máximo usar swap de disco e criar mais gargalo no seu HD lento. São as coisas que explico no meu artigo sobre configurar Linux pra máquinas lentas que vou deixar de novo nas descrições abaixo.

Além disso você pode somar configurações assim com distros preparadas pra instalar componentes mais leves do que os Ubuntu da vida, e evitar que você precise manualmente ficar instalando vários pacotes. Exemplo disso seria um Lubuntu, ou Light Ubuntu, ou também um Puppy Linux que é baseado em Debian. Como parêntese alguns me falaram do Pop OS mas eu não gostei muito dele, é basicamente um Ubuntu pré-configurado e com repositórios extras pra facilitar instalar algumas coisas como tensorflow. Mas não vi grandes vantagens não. Primeiro quero ver se ele dura, já que foi criado e é mantido por uma pequena empresa tentando vender hardware customizado. Já vi isso acontecer antes com distros como Lindows, mas que sumiram. Um Mint ou Elementary pelo menos já existem faz alguns anos e continuam sendo suportados. Pra eu instalar como daily driver, precisa ter mais tempo de existência. Prefira escolher distros que já tem alguns anos de estrada.

Dentre as dezenas de distros que existem, eu acabo preferindo os mais maduros e com ecossistemas maiores, aqueles que todo tutorial que você abre tendem a ser os primeiros. Nessa categoria você tem principalmente os derivados de Debian. Ubuntu é um fork de Debian. Mint e Elementary são customizações em cima do Ubuntu, todos usam pacotes DEB com gerenciador APT. Você tem os derivados de RedHat como Fedora pra desktop ou CentOS pra servidor, e tem o Suse que é meio primo deles também, todos usam pacotes RPM com gerenciador YUM. Você tem os derivados de Arch como o Manjaro que usam Pacman. E tem os mais de nicho antigos como Slackware e Gentoo.

Uma característica que pode ou não ser um problema pra você no caso de Debian é que a intenção dele é ser sempre uma distro estável e confiável, e isso significa que ele demora bem mais pra oferecer versões mais novas de softwares mais novos. E faz sentido, tudo que é novo e ainda não foi testado o suficiente sempre deve ser considerado potencialmente bugado ou instável. Mas como desenvolvedores a gente muitas vezes precisa das coisas instáveis também, e por isso tem forks como um Ubuntu da vida, que oferece versão um pouco mais estável que são os LTS ou Long Term Support como o atual 18.04, que a Canonical deve fornecer suporte por uns 5 anos pelo menos, e versões mais bleeding edge, ou instáveis com coisas mais novas pra testar, que é a versão ímpar 19.04, que vai ter suporte bem menor. Mais ou menos o mesmo princípio você tem com CentOS sendo mais estável do que Fedora que tem pacotes mais recentes. Arch é sempre mais instável porque ele vai atualizando pra frente como se não houvesse amanhã. Não quer dizer que ele tem problemas, só que tem mais chances de ter, ele é uma bicicleta sem rodinhas, você tem que saber andar sozinho sem apoio.

Eu disse que Arch você vai sofrer se for iniciante, mas minha recomendação teve um pingo de compaixão. Arch pode parecer um pouco complicado no começo, mas ele é um sistema moderno, com gerenciador de pacotes e dependências bem competente, e com um dos melhores Wikis disponíveis em qualquer distro. Tem ampla documentação e suporte. Agora se você quiser ir pra um nível mais hardcore, precisa tentar Slackware. É a distro mais antiga ainda sendo mantida, desde 1993. Ele é um dos mais simples e mais parecido com o UNIX original e sua filosofia de KISS (keep it simple, stupid). Ele nem tem um gerenciador de dependências propriamente dito. Seus pacotes são meros tarballs, tipo zip se você não sabe o que é um tarball.

Em algum momento acho interessante tentar Slackware, mesmo hoje em dia. O Slack foi minha primeira distro em 1995. Não vou dizer que tenho boas memórias dele. Mas se quiser ir ainda mais um nível hardcore, você precisa experimentar o Gentoo cuja filosofia é baixar só código fonte e compilar tudo, literalmente tudo, na sua própria máquina. O sistema Portage dele é meio inspirado no Ports do BSD. Essa é uma distro pra você que tem muita curiosidade, muito tempo e principalmente muita paciência.

A maioria das distros mais novas por alguma razão acabam derivando de Ubuntu, caso do Pop OS. Um dos mais promissores na linha de Mint ou Elementary hoje seria o Deepin, que eu acho que é um dos mais bonitos e mais próximos da usabilidade de um MacOS sem tentar ser um clone exato. E de bônus, pra quem gosta de Arch e Manjaro, também tem a versão Manjaro Deepin que você pode usar em vez do Manjaro GNOME. Aliás, tem isso também, muitas distros já trazem versões pré-configuradas com diferentes desktop managers, como GNOME, KDE, Cinnamon, XFCE, o do Deepin que usa kwin, que é derivado do KDE Plasma, e outros mais exóticos com o i3 que muitos adeptos de teclado estão adotando.

Isso tudo dito, em PCs mais fracos não tem o que pensar, eu definitivamente recomendo instalar um Linux pra tirar o máximo da máquina. Em PC mid-range ou topos de linha eu acabo ficando no Windows puramente pelo suporte. Veja bem, minha situação é diferente da maioria das pessoas: meu dia a dia hoje não é mais ser programador tempo integral. Independente dos meus motivos pessoais, a recomendação ainda é tentar se manter no Linux como máquina primária. No meu caso, na maior parte do tempo eu vou acabar ficando em web apps, gmail, twitter, reddit, calendar, dashboards de AWS ou Google Cloud, e é tudo web. Coisas que tem clientes nativos como Dropbox, Zoom, Skype, tudo funciona bem em todos os sistemas operacionais. Apesar de eu não me incomodar com Google Docs ou Google Spreadsheet, eu ainda não gosto do Slides e mesmo a versão online do PowerPoint eu não me vejo usando. Ainda prefiro as versões nativas de apps do Office. De novo, é um gosto pessoal.

E mesmo o PowerPoint, tem várias coisas que ele faz até melhor que todo mundo mas em termos de usabilidade e produtividade ainda não supera o lendário Keynote da Apple. Mas tudo bem, em termos de pacotes de produção de conteúdo, eu gosto de ter acesso ao Adobe Creative Cloud, que só tem pra Windows e Mac. Mesmo em Mac eu ainda não trocaria Photoshop por qualquer outro produto. De novo, tudo gosto pessoal aqui. Entenda que metade da minha preferência pessoal é o fato de eu ter anos de experiência em ferramentas Adobe ou Apple. Se você nunca usou essas ferramentas, não vai sentir falta, então se começar com LibreOffice Impress, Google Slides, Da Vinci Resolve, Gimp, Inkspace, vai se acostumar. Em trabalhos criativos a ferramenta tem menos importância do que o treino artístico do profissional.

Se você não precisa de pacotes Microsoft, ou Adobe, ou não tem necessidade de desenvolver pra iOS, qualquer PC com qualquer boa distro Linux deve mesmo ser a primeira escolha. Você não está perdendo nada. Como muitos me lembraram depois, o Steam tem a opção do Proton e com isso a maioria dos games roda bem hoje em dia em Linux também. Dota 2, CS Go, Rocket League, Skyrim, Fallout, vai rodar. Se você joga Pubg vai ter problemas. Por baixo dos panos ele usar Wine e DXVK mas você não precisa ficar configurando manualmente jogo por jogo, por isso tá bem mais viável com o suporte da Valve hoje em dia.

Ou seja, numa máquina boa, o Windows funciona bem o suficiente pra eu esquecer que estou usando ele. E se você precisa de produtividade, realmente não quer ficar deixando sua máquina principal com risco de ficar instável, e nesse sentido não há nenhum grande problema em ficar no Windows. Mas na realidade, enquanto estou escrevendo este script eu estou muito tentado a voltar pro Linux como sistema primário. Entrei no Arch Wiki e vi que meu Lenovo Thinkpad X1 Extreme funciona perfeitamente com exceção do leitor de impressão digital, que não faço tanta questão de usar. Então eu acho que depois de editar este video vou instalar o bom e velho Manjaro, talvez o Deepin. Acompanhem minhas redes sociais pra ver como vai ficar.

Agora vamos pra parte 2, sobre Mac, o que eu realmente gosto é a consistência. Em Linux você tem diferentes desktop managers como GNOME, KDE, e por aí vai. Com diferentes toolkits gráficos como GTK, Qt, Tcl/tk, e isso faz com que cada aplicativo fique com sensação de “fora do lugar” se rodar misturado. Pegue um Kdenlive, que é feito com o toolkit Qt pra KDE, ele fica fora do lugar rodando num GNOME. Ou um Gimp rodando num KDE. A interface gráfica de Linux é uma zona. Aliás, parece que estou falando mal, mas calma, a nova interface do Gimp, por exemplo, ficou sensacional se comparado como era antes, e inclusive recomendo que dêem uma olhada. Isoladamente, cada aplicativo é muito bom, especialmente com os refinamentos de hoje em dia, mas como um conjunto eles são muito inconsistentes em usabilidade.

No mundo Windows é um pouco parecido porque a Microsoft não se compromete numa única linguagem de design. Desde o Windows Vista eles vem tentando modernizar a interface, mas aí mesmo entre os aplicativos da própria Microsoft você tem aberrações como o aplicativo principal de Settings pra maioria das configurações da máquina, mas ainda tem o antigo Control Panel pras coisas que ele ainda não modernizou. Coisas simples como botões, tem o estilo pseudo-3D em apps velhas, tem botão cinza, tem botão translúcido. Cada hora é de um jeito. Coisas bestas como o console ou o Notepad, só começaram a ser modernizados agora. Olha como o Notepad contrasta ao lado da Calculadora. Eu abro muitas coisas e parece que voltei pro Windows XP. Especialmente se pegar programas mais antigos de terceiros que não se atualizaram.

A Apple iniciou a idéia de um Human Interface Guideline ou HIG décadas atrás, literalmente um guia de usabilidade e design visual de todos os elementos do sistema operacional. A forma com que eles conseguiram manter esse HIG consistente e sempre se atualizando é que os aplicativos que a própria Apple desenvolve usam o HIG e os aplicativos feitos pela própria Apple tendem a ser muito bem feitos, e todos os usuários querem os mesmos elementos em todos os outros aplicativos. Eles são tão bem feitos, que até usuários de fora do Mac gostariam que seus apps em Linux e Windows ficassem parecidos. Olha esse dialog box pra escolhe arquivos do MacOS e veja o do Deepin que falei antes, ou o Finder no Mac e o file manager do Deepin. Está bem claro que o Deepin gosta da estética do MacOS também. Então sempre existiu tentativas assim de se criar temas e skins pra Linux e Windows ficarem mais parecidos com Macs. Quando você viu um usuário de Mac tentando tematizar o Mac pra ficar com cara de Linux ou Windows?

No Mac é tudo mais consistente. Manter consistente foi um risco que se pagou. Eles determinaram e cumpriram linhas de corte drásticos que na época deixou muita gente descontente, mas hoje o resultado se paga. Quando Steve Jobs voltou pra Apple ele trouxe o lendário NEXTStep que é o desktop manager e os frameworks de desenvolvimento de aplicações feitos em Objective-C. Quando eles evoluíram o NEXTStep pra virar o OS X eles fizeram uma camada de compatibilidade binária com o Mac classic. Então se você executasse um binário de Mac antigo ele conseguia rodar. Facilitou que o OS X rodava no mesmo processador dos Macs antigos, o IBM Power PC e foi assim de 2000 até 2006.

O NextStep foi a parte da Next que sobreviveu. Muitos talvez reconheçam a Next por causa da workstation Cube onde Tim Berners Lee desenvolveu o primeiro protótipo de um navegador web e o protocolo HTTP. Ou onde John Carmack desenvolveu o lendário Doom. As capacidades de desenvolvimento num Next eram reconhecidas como de fato as melhores da época. Se você abrir um Interface Builder do Xcode de hoje, é algo muito parecido com que eles usavam no fim dos anos 80 num Next.

Enquanto a linha de hardware morreu, o NextStep foi padronizado como OpenStep junto com a Sun. No mundo Linux surgiu o desktop manager chamado WindowMaker que tinha o look and feel do NextStep mas na verdade foi feito em C. E teve o GNU Step que era uma tentativa de implementação dos frameworks em Objective-C. A idéia é que um dia um app de NextStep podia ser compilado em GNU Step e rodar em Linux. Recentemente descobri um projeto que está incompleto e eu não testei ainda mas que se chama NextSpace e é uma tentativa mais moderna de ter um ambiente NextStep em Linux. Ele tem a cara do antigo WindowMaker mas implementando da forma certa os frameworks todos em Objective-C. Se ele for bem sucedido, seria até possível pegar códigos fonte de aplicativos simples feitos pra Mac e recompilar em Linux usando esse framework. Ele está fazendo o caminho certo: em vez de tentar reimplementar os frameworks e o visual de um Mac moderno, ele está fazendo o mesmo caminho que a Next fez pra dentro da Apple em 1998.

Voltando pra história, quando anunciaram o beta do novo sistema operacional, codenome Rhapsody, a idéia era um NextStep onde você podia rodar só aplicativos novos feitos em Objective-C e os apps antigos do Mac classic rodariam num Yellow Box que era basicamente uma camada de emulação. Claro, os desenvolvedores ficaram muito bravos. Eles queriam que os aplicativos deles funcionassem nativamente no novo sistema operacional, mas ninguém estava muito a fim de reescrever tudo que se tinha antes em Object Pascal ou C pra Objective-C. Por isso a Apple resolveu desenvolver um framework intermediário, mais compatível com a API do Mac classic. Esse conjunto de APIs intermediários foi chamado de Carbon. Você precisava modificar algumas partes do seu código antigo e recompilar usando o framework novo que dava acesso aos recursos modernos do OS X, como permitir multi tarefa preemptiva e modo de memória protegido. Era o processo de carbonização.

Daí em 2006 eles fizeram um dos movimentos mais interessantes que eu vi no mundo de tecnologia até então: mudar os Macs dos processadores Power PC pra Intel. Eu lembro quando assisti o Keynote e fiquei muito impressionado com a estratégia. Mais ainda porque desde 2001 nós ouvíamos mesmo rumores de que o OS X, por ter a estrutura UNIX e tudo mais, não deveria ser tão difícil de recompilar em Intel. E Jobs anunciou exatamente assim, foi sensacional. Na prática, a IBM provavelmente estava mais interessada nos processadores que estava vendendo simultaneamente pra Sony nos PS2, pra Microsoft nos Xbox originais e pra Nintendo nos GameCubes. A promessa que eles fizeram de um processador G5 de 3Ghz passou 2 anos e eles não entregaram pra Apple, e isso obviamente fez Steve Jobs ficar com cara de bobo por ter prometido isso 2 anos atrás. E um Jobs bravo não é exatamente fácil de negociar.

Frigir dos ovos, fora IBM, olá Intel. Alguém na IBM deve ter pensado pfff foda-se, duvido que eles nos abandonem, vão fazer o que, ter a dor de cabeça de migrar tudo pra Intel? É exatamente o que um Jobs bravo faria, e fez. Pra isso funcionar eles fizeram uma estratégia em etapas. Binários antigos de Power PC rodariam sobre uma camada de emulação chamada Rosetta, de uma pequena empresa que a Apple comprou. Essa camada traduzia as instruções RISC de PowerPC em instruções x86 em tempo real. Óbvio que era mais lento, mas era muito impressionante.

Toda aplicação mais nova, já desenvolvida no framework derivado do NextStep, que a essa altura tinha sido renomeado de Cocoa, só precisava assinalar um checkbox na IDE XCode. Fizeram uma apresentação de como pediram o código fonte do lendário Mathematica que rodava em Power PC e com algumas horas de tweaks no código e assinalando o tal checkbox, já se tinha um binário pronto pra rodar nativo em Intel. Aliás, esse keynote inteiro é de longe uma das melhores apresentações de transição de roadmap de produto que eu já vi, é uma aula que eu recomendo que vocês assistam. Vou deixar linkado o keynote nas descrições abaixo.

Até esse ponto muita gente preferia desenvolver no antigo CodeWarrior da MetroWerks, que era o que se usava pra escrever código pra Mac classic. Pra migrar pra Intel era preciso compilar via o novo XCode 2 e foi assim que o CodeWarrior morreu e todo mundo passou a adotar XCode. Ironicamente o CodeWarrior ganhou notoriedade quando a Apple migrou dos processadores Motorola 68000 pra PowerPC, e agora perdeu o bonde na segunda transição.

Todo aplicativo antigo que já tinha sido carbonizado também era praticamente só recompilar. Ao recompilar eles trouxeram outra tecnologia do NextStep: os Fat Binaries que foram renomeados como Universal Binaries. Um dos recursos mais interessantes pra mim no OS X e NextStep era o conceito de bundles. Tecnicamente em vez de você dar duplo clique em cima de um binário executável, você manda executar um bundle, que é simplesmente uma pasta especial com um arquivo de manifesto e algumas convenções de subpastas e nomes. Daí o OS X procura dentro dessa pasta o binário pra Power PC ou pra Intel dependendo de onde está rodando e executa o certo. Daí quando precisou migrar de 32-bits pra 64-bits foi a mesma coisa: recompilar e gerar os binários e fica tudo no mesmo bundle. Esse conceito de universal binary foi outra coisa inteligente na época que me deixou impressionado, porque eu estava vendo no Windows começar a aparecer coisas como o diretório Program Files (x86) ao lado do diretório Program Files, que é um troço que ainda existe no Windows até hoje. Isso sem contar o buraco negro radioativo que são os diretórios System32 e WOW64.

A Apple só conseguiu fazer isso porque a quantidade de pessoas usando Macs era muito pequena, só alguns poucos milhões. Então não tinha tanto problema se uma porcentagem pequena dos usuários ficasse alienada sem conseguir atualizar por conta de aplicativos legados que não iriam mais rodar. O ideal era todo novo aplicativo ser feito já usando os frameworks do Cocoa, em Objective-C, com XCode. E pra facilitar mais ainda, 2 anos depois desse anúncio eles lançam o iPhone, e nem 2 anos depois o Xcode passa a suportar compilar pra processadores ARM, usando frameworks derivados de Cocoa, em Objective-C, então mesmo se a maioria das pessoas não fosse adotar XCode e Objective-C, a urgência de querer desenvolver pra iPhone automaticamente criou essa necessidade e foi assim que Objective-C passou de uma linguagem obscura que quase ninguém usava além de desenvolvedor de Mac pra uma das linguagens mais reconhecidas nos anos 2010. E aqui eles demonstraram novamente, que não importa se você acha que uma linguagem é bonita ou feia, o que trás adoção pra linguagem é um killer app, no caso o iPhone e sua App Store. Sem um killer app, uma boa linguagem está morta.

Nesse sentido, acabou dando tudo certo pra Apple. Eles tiveram a possibilidade de começar praticamente do zero com o OS X, migrar os principais aplicativos aos poucos via carbonização ou reescrever direto em Cocoa. Ajudou que a fundação era baseada em UNIX então havia muito código aberto que podia ser reusado no processo, vindo tanto dos ecossistemas de BSD e de Linux. Vocês podem ver que esse processo de nascimento e evolução do OS X foi extremamente fascinante de se ver, e com os novos hardwares, qualquer programador antenado queria muito entrar nesse ecossistema o quanto antes, e por isso eu migrei pra Mac em 2004 e me senti ainda mais justificado com tudo isso que aconteceu.

Quando a adoção de iPhone aumentou a adoção de Macs, ao mesmo tempo comunidades web como Ruby on Rails já haviam entrado nesse vagão. O fato de Ruby vir pré-instalado em Macs ajudou muito. O fato de muitos aplicativos de Linux serem compatíveis no nível do código fonte também ajudou. Daí nasceram muitas ferramentas que são usadas até hoje e são parte fundamental do desenvolvimento tanto Web como Mobile. No começo era muito chato usar ferramentas open source no OS X porque a gente precisava baixar os fontes e compilar tudo na mão e torcer pra compilar. Aos poucos surgiram ferramentas automatizadas como o antigo Fink que tentava imitar o apt-get do Debian pra ser um repositório pra baixar pacotes em formato DEB, mas teve muito pouca adoção e suporte e morreu. Outra tentativa foi o MacPorts que tentava simular o Ports do BSD pra baixar pacotes de código fonte e compilar toda vez que baixava. Esse até durou alguns anos mas morreu também.

O que sobreviveu e existe até hoje é o Homebrew que é o gerenciador de pacotes que todo desenvolvedor de Mac usa e é feito em Ruby. No mundo mobile mesma coisa, a gente precisava organizar dependências ou manualmente usando coisas como submódulos de git, ou baixando as bibliotecas manualmente e jogando em pastas no projeto. Mas então surgiu o CocoaPods pra gerenciar dependência de projetos pra iOS, e ele também foi feito em Ruby. Outro dia vou falar mais de Ruby, mas os rubistas foram os que começaram a ajeitar o Mac pra ficar boa pra ser usada por qualquer desenvolvedor. O pacote Oh-my-ZSH pra trocar Bash por ZSH, de novo, foi feita por outro rubista.

Eu falei no começo que no mundo Linux e Windows a linguagem visual dos aplicativos é toda misturada. No mundo Mac, essas transições meio que forçaram o desenvolvimento de novos aplicativos usando os frameworks mais modernos e os guias HIG da Apple. E com a adoção de parte do mundo open source, e o desenvolvimento acelerado de apps iOS, a gente tinha um app bom atrás do outro surgindo. Editores de texto como o TextMate 2 que nós da comunidade Ruby começamos a usar dita a linguagem de todo novo editor de texto até hoje. A idéia de um editor rápido e simples que pode ser extendido via plugins, com recursos pra fazer pesquisa fuzzy em nome de arquivos, diversos shortcuts e macros pra expandir templates de código.

Se você usa Sublime Text, ou Atom ou Visual Studio Code e abrir o TextMate 2 com os diversos plugins instalados, vai ver como a gente tinha exatamente a mesma coisa que se tem hoje só que em 2004. Nenhum outro sistema operacional tinha um TextMate. E foi assim que surgiu a nova geração de plugins de Vim e Emacs que elevaram esses editores ao que eles são hoje também. O renascimento de vim como editor mais moderno veio muito dos plugins feitos pra Rails por outro rubista, o Tim Pope. Pela primeira vez as tendências principais de desenvolvimento de software estavam iniciando primeiro nos Macs e sendo levados pra Linux e Windows depois. Só considere que quase toda ferramenta que você usa hoje, de GitHub a Heroku, foi feito por desenvolvedores usando Macs.

A estética da Apple influenciou a web moderna, começando com o visual do Aqua original com seus elementos parecendo plástico translúcido, como os iMacs antigos, e depois se tornando mais metalizado como os PowerMac Titanium, e finalmente se tornando mais minimalista seguindo a identidade de aplicativos de iPhone. Hoje eu diria que o design e estrutura de apps e sites meio que convergiu e está mais estável, mas não havia lugar melhor pra estar entre 2006 a 2010 se você fosse desenvolvedor de software. E se você assistiu meu video da Apple e GPL que vou deixar linkado aqui em cima, também sabe que nesse período foi quando eles contrataram o Chris Lattner que evoluiu o LLVM até o clang substituir o GCC e desenhou a nova linguagem Swift. Desenvolvimento de software no mundo Apple era realmente empolgante com tudo isso.

Você tinha um pacote muito atraente: na época os Macs tinham preços até que competitivos mesmo se comparado aos PCs. Com a vantagem que os PCs eram objetivamente piores. O design industrial era desastroso pra dizer o mínimo. As configurações padrão eram fracas. Iniciativas como netbooks foram um fracasso. O Windows Vista da época não estava exatamente atraindo novos usuários. Pensa que o Windows 7 só veio a sair em 2009, ano que todo mundo queria Mac pra desenvolver apps pra iPhone. E pensa que só um ano antes tinha acabado de sair o Macbook Air que obliterou a imagem que a gente tinha de notebooks e iniciou a categoria de ultrabooks.

Sério, os PCs de antes de 2011 eram ruinzinhos, e muito feios. Os da Apple por outro lado, era um modelo melhor que o outro saindo frequentemente. Dava vergonha abrir um notebook PC do lado de um Macbook. Mas foi a partir de 2012 que as coisas começaram a virar. Steve Jobs estava mais ou menos certo: as tecnologias da Apple estavam uma média de 5 anos à frente do mercado. Incluindo I/O mais veloz com coisas como Lightning e Thunderbolt, o conceito de unibody enclosure, tecnologia de baterias, as telas Retina num mundo que ainda vendia monitores 720p todas descalibradas, o melhor trackpad até hoje ainda, e os melhores teclados em notebooks.

Mas, Steve Jobs morreu em 2011, e com ele foi enterrado também a visão e estratégia da Apple. O Mac Pro trashcan em 2013 iniciou um período de idade média dos hardwares Pro da Apple. A bolha de apps pra iPhone já estava estabilizando por 2014, então isso não ia mais acelerar venda de novos Macs. E pra piorar a partir de 2015 eles começaram a errar a mão nos Macbooks. Os teclados com switches butterfly são a pior construção que eu já vi, além de na prática serem rasos e desagradáveis pra longos períodos de digitação. O touchbar removendo teclas que são úteis pra desenvolvedores não ajudou em nada. Manter o mesmo unibody enclosure e ir entuxando CPUs que esquentam mais e mais como os Core i7 e os Core i9 causando thermal throttling não ajudou também. Eles esqueceram como em 2005 eles decidiram até mudar de CPU porque os G5 esquentavam demais pros produtos que a Apple queria fazer.

A Apple foi aumentando os preços e entregando menos. E nesse vácuo todos os outros fabricantes foram ficando melhores, em todos os segmentos, tanto em smartphones, como notebooks, como desktops. A Dell veio lançando um XPS melhor que outro faz uns 4 ou 5 anos já. A Lenovo veio lançando Thinkpads cada vez melhores e retornando à antiga glória. Mesma coisa com HP, Acer e outras marcas tradicionais. As marcas chinesas começaram a aparecer mais e mais com Xioami, Huawei e novas marcas começaram a pegar nichos mais premium com os notebooks da Razer. Chegou a hora de explorar a 3a parte deste episódio e pisar no mundo PC um pouco.

O mundo gamer explodiu por conta das iniciativas do governo da Coréia do Sul desde o ano 2000. Os torneios de eSports foram crescendo de meros 10 torneios no início do século pra 260 em 2010 a quase 700 em 2012. O Twitch foi lançado em 2011 e em 2015 já tinha mais de 4.5 milhões de visualizações únicas. Foi quando começou a sair as principais franquias de hoje como LOL, Dota 2, CS:Go, cada um atraindo milhões de novas pessoas a eSports. A Nvidia estava com placas ficando cada vez melhores como a GeForce 600 na arquitetura Kepler. A AMD que a Apple adotou como padrão entrou num vácuo até recentemente. A Apple perdeu o bonde do mundo gamer.

Se você não for gamer pode não parecer, mas a profissionalização de eSports ajudou em muito a evoluir mais rápido todos os componentes de PC. Antigamente era de fato fácil montar um PC equivalente mais barato que um Mac, mas eu sempre tive a sensação de que o resultado final não chegava perto. Por exemplo, não era comum montar PCs com porta Firewire 800. Mas hoje é comum PCs com Thunderbolt 3. Hoje eu diria que existem configurações de hardware superiores e não parece mais que eu estou perdendo alguma coisa. Pelo contrário, agora parece que ficando no Mac eu estou perdendo muita coisa boa no mundo PC.

Pra facilitar, o Windows 10 apareceu pra limpar a zona que foi do Vista até o 8. Conseguiram consertar o start menu, tiraram a porcaria da barra de Charms, otimizaram o suficiente pra não ficar pesado em máquinas mais fracas. E pra completar a partir de 2012 a própria Microsoft começou a entrar no nicho de tablets e ultrabooks com a linha Surface. E aqui eles acertaram bastante. E de fato, fazer o próprio hardware definitivamente ajuda a Microsoft tanto a ter uma linha de referência pros parceiros quanto a otimizar melhor o sistema pra um hardware de verdade em vez de depender só do feedback dos OEMs.

Uma nova geração de desenvolvedores começou a entrar na Microsoft. Foi recente que eles pularam de um headcount de aproximadamente 2 mil desenvolvedores pra 20 mil. Isso trouxe um exército de jovens programadores que cresceram sem o viés de achar que tudo que não é Windows é inimigo. Ajudou muito que eles resolveram se aventurar no mercado de infraestrutura como serviço pra competir com a AWS e fizeram o Azure. O Azure expôs todas as fraquezas do Windows como servidor. E eles se viram na necessidade de aprender com o que o Linux já tinha conquistado até então. Tecnologias como Hyper-V evoluíram muito desde então, o suficiente pra se tornar úteis no mundo desktop também.

A migração de 32-bits pra 64-bits ajudou a Microsoft porque muitos novos dispositivos de segurança se tornaram possíveis com essa mudança, como ASLR ou Address Space Layout Randomization. Explicando de forma simples, eu ensinei no meu episódio sobre gerenciamento de memória sobre endereçamento. Se um hacker sabe em que endereço determinada função com bug de segurança é sempre carregado, fica fácil de atacar. Em 32-bits eu posso mudar de lugar, mas você lembra como tem poucos endereços no final pra aplicação. Então mesmo mudando de lugar, via força bruta, dá pra achar ainda. Em 64-bits a dificuldade aumentou exponencialmente. Esse é um dos recursos habilitados em Windows de 64-bits dentre outras e isso ajudou a diminuir muito a superfície de ataque dos hackers. Apesar de ainda existir centenas de vetores de ataque você pode ver como não é mais tão frequente ouvir falar de Windows 10 em 64-bits sendo atacado de forma tão vergonhosa como foi Windows XP.

E com Hyper-V se tornando componente padrão pra segurança criando coisas como secure enclosures em hypervisor, por exemplo, no novo Windows Defender. Não é difícil ver que as coisas realmente mudaram dentro da Microsoft. Hoje em dia eu tenho um Malwarebytes instalado mas me dá a impressão que só o Windows Defender é suficiente pra maioria dos casos. E pros casos mais exóticos eu ainda tenho a opção de abrir o Windows Sandbox, que é um Windows virtualizado em Hyper-V pra rodar coisas inseguras. Ele sobe um Windows vazio, eu posso instalar até um virus ali, e ele não tem acesso à máquina hospedeira. E quando eu fecho o sandbox, tudo dentro dele morre.

Esse tipo de uso de tecnologia me empolga bastante e, claro, eu posso fazer tudo isso num Mac ou Linux também. Mas de novo, eu gosto de coisas que vêm por padrão, oferecendo consistência. E falando nisso, uma coisa que o Windows nunca pôde fazer, foi começar do zero. Ele ainda é obrigado a trazer diversos binários antigos pra manter compatibilidade com programas velhos. Em seu mérito, é possível pegar um programa binário que rodava até em Windows 98, e provavelmente vai executar no Windows 10. Nenhum outro sistema operacional tem esse nível de retrocompatibilidade binária.

Porém isso também significa que existem muitos vetores inseguros pré-instalados. Muitos aplicativos que obviamente tem cara de que foram feitos nos anos 90. Claro que eu preferia que eles parassem de suportar e forçassem todo mundo a escrever em frameworks mais novos. Mas do tamanho que Windows já era no ano 2000 e o tamanho que é hoje, não seria realista. Ironicamente antigamente todo mundo só fazia apps pra Windows, mas hoje a Microsoft tem mais dificuldade em convencer desenvolvedores a fazer novos apps pra Windows. O Windows Store parece um deserto se comparado à Apple App Store. Mas dentro dessas restrições, eu diria que o Windows 10 está andando numa velocidade até razoável.

No caso do Mac, logo quando o OS X surgiu, eles fizeram três coisas muito importantes. Primeiro foi manter as parcerias originais. Trazer a Microsoft pra dentro pra eles fazerem uma versão do Office e do então Internet Explorer 5 foi muito importante. Com a demora da entrada da Adobe, a própria Apple se viu obrigada a cobrir o buraco. Primeiro com produtos da linha profissional como Final Cut e Logic Pro. Mas depois com o conceito de hub multimídia e os produtos da suíte iLife como iPhoto, iMovie e iDVD. Esses produtos ainda são bons hoje nas novas versões, mas naquela época eles eram imbatíveis. Sem exageros, muita gente comprava iMacs pra ter o iLife.

Muitos dos primeiros YouTubers aprenderam a lidar com multimídia via iMovie. No Windows tínhamos uma zona chamada Windows Movie Maker, um Windows Player que não decidia o que queria ser, se um jukebox ou um tocador. As tecnologias multimídia dos Mac sempre foram superiores. Nessa época os desktop managers do Linux também estavam babando pra interface Aqua dos novos OS X.

E isso foi outro fator que me interessava. Trazer o NextStep pra dentro da Apple como OS X trouxe outras tecnologias que ninguém mais tinha. Na década de 80 ex-funcionários da Apple fundaram a Adobe e inventaram o Postscript. Pense em Postscript como um HTML, com a intenção de possibilitar o famoso WYSIWYG ou What you see is what you get, ou seja, o que está aparecendo na tela ser igual o que vai aparecer quando mandar pra impressora. Isso foi revolucionário porque criou o mercado de desktop publishing.

Essa tecnologia evoluiria pra Display Postscript e depois Display PDF que virou o Quartz no OS X. O desktop manager do novo OS X, em vez de seguir a zona que é o X no mundo UNIX, foi criado do zero pra ser um monolítico que desenha todas as janelas de todos os programas como elementos de composição num PDF. Tudo que poderia ser acelerado via OpenGL em placa gráfica, que era novidade na época. Isso possibilita adicionar elementos de pós-produção, como transparências, sombras e animações fluidas. Em 2000 isso funcionava bem no iMacs, apesar de um pouco lento. Mas os processadores G3 da época conseguiam suportar.

Isso se pagaria poucos anos depois, quando processar esse tipo de coisa passou a ser barato pras novas placas gráficas. Eles tomaram a decisão de ser um pouco mais lentos no começo mas sabendo que em 1 ou 2 gerações estaria na velocidade correta, tanto por otimizações de software quanto pela própria evolução do hardware. Em 2000 qualquer um diria “isso é desnecessário”. Eu acho que o fato deles estarem no fundo do poço e desesperadamente precisando se recuperar fez a Apple de 1998 tomar muitos riscos que nenhuma empresa tomaria hoje em dia.

Se você não sabe o que é compositing. Pense num sistema primitivo. Você tem janelas de vários programas. Eles vão sendo desenhados por cada programa numa certa área de um buffer, tipo uma matrix, que chamamos de frame buffer. Em 1/60 avos de tempo o sistema operacional pega o que está nesse buffer e manda pro monitor mostrar. Se eu mexo uma janela na frente da outra, as duas precisam redesenhar tudo. E pra ficar fazendo sombra de uma janela na frente da outra, 60 vezes por segundo, custa muito tempo. Em vez disso pense agora organizar uma nova abstração, tipo um canvas virtual, onde cada janela fica em layers e a janela de cima não sobrescreve a imagem da janela de baixo. E como num photoshop podemos ir aplicando efeitos como sombra num layer de cima e dinamicamente ele vai aplicar a sombra nos layers de baixo. Mas tudo isso feito via OpenGL na época, falando com a GPU, que foi feito pra aplicar efeitos em quadros muito rápido, o suficiente pra renderizar 60 quadros por segundo, e sem precisar que a CPU se meta. Com isso ganhamos animação fluida usando a GPU em vez da CPU.

Fazer um desktop manager com compositing não é trivial, especialmente se você já tem um jeito legado de fazer e agora ter que mudar. A Apple teve a visão de implementar isso em 2000. Foi mais uma daquelas coisas que você não sabia que precisava até ter visto. Só que depois de ver as animações fluidas, sem engasgos, sem fritar sua CPU, você olhava pro seu Linux e Windows que ainda desenhavam do frame buffer direto pra tela via CPU, e não tinha como ter aqueles efeitos e animações sem fritar sua CPU que ia precisar processar 30 quadros por segundo pelo menos.

Eles precisavam delegar isso pra GPU como a Apple estava fazendo. Mas levou até 2005 pra surgir o Compiz e Kwin no Linux, depois de muita experimentação, e mesmo assim ainda não 100%. E levou até 2007 pra lançar o Windows Vista com o mesmo sistema de compositing, que só ficaria completo e passou a ser obrigatório no Windows 8. Ou seja, na prática, nessa primeira década, só num Mac você tinha visuais agradáveis e lisos. Hoje em dia felizmente tanto os novos Linux quanto Windows 10 já usam sistemas de compositing e até High DPI que é pra monitores com alta densidade de pixels escalar os elementos da tela da forma correta, coisa que a Apple até hoje ainda é a única que faz 100% direito.

O que a Apple fez entre 2000 e 2009 nenhuma outra conseguiu fazer. Eles conseguiram rebootar o ecossistema inteiro, começar do zero com uma plataforma realmente à frente do seu tempo, criando um novo ecossistema consistente de ponta a ponta, incluindo ao lançar novos produtos como o iPhone que manteve a programação muito consistente mesmo que os binários fossem executar em arquiteturas tão diferentes quanto ARM e x86.

Eles evoluíram o LLVM ao ponto de conseguir se desvincular do GCC como compilador, coisa que em Linux ainda não está 100%. E com isso mudar de linguagens de Objective-C pra Swift, sem perder compatibilidade binária. Como eles conseguiram manter uma API unificada com os frameworks Cocoa, fica muito mais fácil de manter as coisas. Do lado da Microsoft eles foram fazendo tentativa em cima de tentativa e cada tentativa errada foi gerando mais dependências que hoje estão todas acumuladas no Windows 10 ainda. A Apple foi cortando fora as coisas velhas. Por exemplo, o suporte a 32-bits no MacOS já acabou em 2017. No Windows isso ainda vai durar alguns bons anos porque tem milhões de pessoas ainda presas em máquinas velhas só de 32-bits.

Então dos anos 2000 até 2005 a Apple estava se recuperando, reconstruindo as fundações quase do zero. OS X novo, novos iMac e a sorte grande de terem conseguido fazer o iPod dar certo. De 2005 a 2007 eles tiveram o trabalho de migrar tudo de PowerPC pra Intel. E de 2009 a 2012 foi a consolidação graças ao boom do iPhone. De 2013 em diante foi sentar nos louros e seguir a receita.

Dos anos 2000 até 2010 o mundo PC ficou correndo atrás sem saber muito pra onde ir. Todo mundo foi afetado com o crash da bolha da internet em 2001. Mas com a presença da Apple tão claramente demonstrando porque tudo que eles faziam estava errado, demorou uma geração inteira até finalmente eles começarem a copiar e finalmente ultrapassar a Apple de novo. Em 2019 as diferenças são mais do tipo: a caixinha de som do Macbook ainda é melhor. O SSD da Apple realmente ainda é um pouco mais rápido. E a integração do sistema operacional com o hardware ainda é muito bom. Tirando isso, qualquer combinação de hardware PC com Windows ou Linux está praticamente igual pra todos os efeitos práticos.

A grande virada pra desenvolvedores eu acho que vai ser o lançamento do Windows Subsystem for Linux versão 2 daqui alguns meses. Eu estou usando hoje em versão alfa. Em resumo é uma máquina virtual Hyper-V mais leve do que o normal porque ele não vai precisar pré-reservar CPU ou RAM e parece que consegue gerenciar recursos sob demanda. Então o custo inicial é razoavelmente barato e com start rápido, especialmente pra rodar tudo em linha de comando. Então se você sobe Docker pra Windows hoje, que também usa Hyper-V por baixo, vai ficar melhor.

Na prática o Windows 10 com WSL2 vai se tornar um sistema operacional com duas cabeças. Mas a cabeça Linux ainda vai rodar isolado. No MacOS a fundação inteira foi trocada pra UNIX e ele vem colhendo os benefícios disso até hoje. Isso não vai acontecer no Windows, eu diria talvez nunca. Então rodar oficialmente virtualizado é a segunda melhor coisa. Por outro lado, como o MacOS é um UNIX não compatível com Linux, não tem como baixar um binário de Linux e rodar direto no Mac. Isso vai ser possível no WSL que é literalmente um kernel de Linux rodando virtualizado, então em termos práticos, o mundo Windows vai ter acesso a muito mais do mundo Linux do que o Mac tem hoje.

Graças à Apple hoje temos PCs e notebook muito melhores. São mais leves, construídos com materiais muito mais elegantes e sofisticados do que só plástico e ferro. A Apple introduziu alumínio ao mundo e todo mundo vem experimentando com novos materiais como magnésio ou fibra de carbono. Os fabricantes aprenderam que a gente paga mais pra não ter que ter plástico. Os componentes hoje funcionam muito melhor integrados. Os firmwares das placas mães ficaram mais inteligentes, PCI-express facilitou a vida de todo mundo. SSDs e RAM ficaram muito mais baratos e acessíveis. E até a porcaria da placa gráfica integrada da Intel já serve pra maioria das coisas que precisamos hoje como assistir Netflix em 4K.

Se você está começando agora deve ficar mesmo confuso porque desenvolvedores mais experientes como eu passaram por esses períodos que eu falei. Muito do que se fala mal de Windows hoje é porque a gente sofreu com Windows XP. Muito do que se fala bem dos Macs é a fase de ouro até o lançamento dos iPads. A mesma coisa dos Linux, muito desenvolvedor que hoje usa Mac não consegue se ver tendo que sofrer pra instalar e customizar um Linux até ficar agradável pra usar, mas naquela época a gente não tinha Elementary ou Deepin. E pra mim, eu tenho gostos superficiais e pra mim visual faz diferença, e não ter a opção de desktop managers com compositing fazia muita diferença. No Windows a gente teve que esperar até sei lá, depois de 2009 pro Aero funcionar de verdade quando o Windows 7 ficou mais estável. E levou do Windows 8 até o 10 pra nova linguagem de interface Metro finalmente começar a ser mais adotada. Ou seja, eu realmente não recomendava e ainda não recomendaria usar Vista, 7 ou 8. O Windows 10 é o primeiro Windows que demonstrou interesse em cortar coisas fora e gastar tempo limpando a casa em vez de só ficar adicionando inutilidades como aquela horrível barra de Charms.

Eu disse que se você precisa desenvolver pra iOS, não tem o que escolher, você é obrigado a ter um Mac. Porém, não se preocupe em comprar os mais novos. Mesmo se você comprar um Macbook Pro usado de 2016 ainda vai funcionar razoavelmente bem. É muito difícil de justificar o custo de um Mac, especialmente com o dólar caro em relação ao Real. Mas a boa notícia é que hoje em dia comprar um bom PC não dá mais aquela sensação de estar escolhendo uma opção de segunda linha. Se você precisa desenvolver em .NET fique esperto, na prática, vai ser obrigado a usar Windows mesmo, mas dependendo do tipo de desenvolvimento, com o novo .NET Core você pode ter praticamente tudo que precisa num Linux e desenvolver com o Visual Studio Code. Caso você não saiba disso hoje é possível instalar SQL Server no Linux também e compilar e rodar programas .NET feitos em C# ou F# nativamente num Linux, é uma opção suportada depois que eles compraram a Xamarin. E com os frameworks da Xamarin ainda é possível fazer aplicações tanto pra iOS quanto pra Android, então existem várias opções ainda a serem exploradas no mundo Linux.

E por tudo isso, eu diria: se você tem dinheiro sobrando, na real tanto faz. Macbook Pro, Thinkpad X1 Extreme ou Carbon, Razer Blade, Asus Zephirus S, tem uma variedade muito boa. Se você for jogar ou criar conteúdo, escolha alguma com uma GTX topo da série 10 como as 1080 ou 1070 ou os mid-tier com 1660. Ou se quiser mesmo rasgar dinheiro, compra com as novas RTX série 20.

Se você não tem dinheiro sobrando, não se sinta mal em não estar comprando um Macbook. Procure os Dell Inspiron, Acer Switch, os HP Presario com Core i3 pelo menos. Antes pesquise no Google sobre a compatibilidade desses modelos com Linux. Escolha uma boa distro como um Ubuntu, Manjaro. E mesmo nessas máquinas dá pra ser criador de conteúdo, com um pouco mais de paciência, você consegue rodar Blender, Gimp, Kdenlive, Inkscape, Da Vince Resolve, Audacity e pra maioria dos casos você deve conseguir trabalhar normalmente.

Em 2016 meu objetivo de migrar pra Linux depois de mais de 10 anos usando Macs foi porque primeiro eu não tenho lealdade nenhum com a Apple. Não havia mais nada que me empolgava na Apple o suficiente pra ficar lá. E eu não ia ser aquele cara com Mac falando pras pessoas “usa lá Linux, dizem que funciona”. Eu só recomendo o que eu pessoalmente já usei como ferramenta primária por algum tempo, senão prefiro não recomendar. Eu não tenho lealdade com a Apple, também não tenho lealdade com a Microsoft e apesar de ter elogiado, ainda tá longe, mas bem longe do que eu gostaria que o Windows fosse. E também não sou ativista então nesse episódio longo veja que eu não disse nenhuma vez que você devia usar Linux por causa do aspecto de software livre. Estou sendo bem pragmático: do ponto de vista de produtividade, programação, gaming e criação de conteúdo, hoje em dia você tem PC antes de Mac e Windows e Linux antes de MacOS. Mas, mas, se você tem acesso a todas as opções, tanto faz na real.

E por hoje é isso aí, já fiz muito bikeshedding pra um episódio só. No final isso tudo foi um pouco uma desculpa pra eu contar alguns dos episódios da história da Apple que eu gosto, a migração do Mac Classic pro OS X, depois a migração de Power PC pra Intel. Acho uma pena que a Apple de hoje não se parece muito com a Apple daquela época, mas pelo lado bom, ainda bem que a Microsoft de hoje está muito melhor que a Microsoft daquela época. E como eu sempre digo: o mercado anda em ciclos. Espero que tenham gostado da história. Se ficaram com dúvida mande nos comentários abaixo, se curtiram mandem um joinha, assinem o canal, cliquem no sininho pra não perder os próximos episódios e continuem compartilhando com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!

No episódio de hoje, pegando carona que eu fiz um vídeo sobre instalar ambiente de desenvolvimento em Ubuntu () eu queria aproveitar pra contar vários pequenos momentos e conceitos sobre sistemas operacionais que eu gosto de ficar discutindo.

No geral eu poderia dizer que é um vídeo “comparando” Linux, Mac e Windows mas a idéia não é escolher um no final mas sim delinear o que aconteceu nos últimos 20 e tantos anos que me fez ficar mudando de sistemas e hardware ao longo do tempo e porque existem algumas opiniões formadas hoje que quem está só começando não consegue entender porque as recomendações são extremas em muitos casos.

Antigamente a gente pedia “pelamor” pros desenvolvedores darem uma chance pros Macs. Hoje em dia o povo não entende porque tem tanta gente ainda recomendando Macs tão veementemente. E no fim, qual é a melhor escolha pra desenvolvedores de software? Vamos descobrir isso hoje.

]]>applemicrosoftlinuxakitando[Akitando] #42 - Entendendo Apple, GPL e Compiladoreshttps://akitaonrails.github.io/2019/03/06/akitando-42-entendendo-apple-gpl-e-compiladores/https://akitaonrails.github.io/2019/03/06/akitando-42-entendendo-apple-gpl-e-compiladores/Wed, 06 Mar 2019 17:00:00 -0300<p>Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal <a href="https://www.youtube.com/channel/UCib793mnUOhWymCh2VJKplQ"target="_blank" rel="noopener">Akitando</a>. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.</p> <div class="embed-container"> <iframe src="https://www.youtube.com/embed/suSvMnNwV-8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe> </div> <h3>Descrição no YouTube<span class="hx:absolute hx:-mt-20" id="descrição-no-youtube"></span> <a href="#descri%c3%a7%c3%a3o-no-youtube" class="subheading-anchor" aria-label="Permalink for this section"></a></h3><p>Finalmente! Chegamos no episódio 42!</p> <p>Se você é geek que nem eu sabe que 42 é um número especial. Segundo o sábio profeta Douglas Adams o número 42 é a resposta da vida, do universo e de tudo. Se não acreditam leiam a bíblia do Guia do Mochileiro das Galáxias. De curiosidade é por isso que minha empresa se chama Codeminer 42. E em especial este ano eu vou completar meus 42 anos. Mas chega de numerologia, vamos começar a história de hoje.</p>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

Finalmente! Chegamos no episódio 42!

Se você é geek que nem eu sabe que 42 é um número especial. Segundo o sábio profeta Douglas Adams o número 42 é a resposta da vida, do universo e de tudo. Se não acreditam leiam a bíblia do Guia do Mochileiro das Galáxias. De curiosidade é por isso que minha empresa se chama Codeminer 42. E em especial este ano eu vou completar meus 42 anos. Mas chega de numerologia, vamos começar a história de hoje.

Hoje vamos fugir um pouquinho do tema de Back-end, que pretendo retomar semana que vem. Desta vez quero contar uma história que eu pessoalmente acho interessante. Vou falar sobre Apple, sobre licenças de software livre, sobre compiladores, um pouco do mundo mobile e um pouco do mundo web de novo. É uma história meio complicada mas que vai ajudar vocês a entenderem um pouco da dinâmica de como o mundo real afeta a evolução e adoção de linguagens e tecnologias.

Errata: várias vezes no vídeo eu falo “SpiderMonkey” mas eu queria dizer “JavascriptCore”. A SpiderMonkey é a engine de Javascript do Firefox, a JavascriptCore que é a engine que vem no WebKit e Safari. E o V8 é o do Chrome.

Errata 2: Eu falo que GPL é General Protection License, mas na verdade é General Public License.

Errata 3: me avisaram nos comentários e eu realmente comi bola quando falei dos emuladores de Android. Antigamente as imagens do OS eram realmente só de ARM mas hoje em dia de fato já existem imagens compilados pra x86, então em um Virtualbox habilitado pra usar os recursos de virtualização dos processadores AMD e Intel como o VT-X é possível acelerá-los. Ainda não é a mesma coisa que no MacOS/iOS que é um simulador sem necessidade de camada de virtualização, mas não deixa de ser um avanço.

Links:

Script

Olá pessoal, Fabio Akita

Desta vez vamos dar uma pequena pausa na série Começando aos 40. Vocês já viram dois episódios falando sobre back-end e o assunto ainda não acabou, mas pra quebrar um pouco decidi fazer uma longa tangente hoje e falar sobre um tema cabeludo que envolve o mundo de software livre, a Apple e compiladores. É até difícil definir que tema é esse exatamente. Tem a ver com compiladores e linguagens mas não é só isso. Mas é uma história que eu acho fascinante e queria compartilhar com vocês.

Além disso hoje finalmente estou completando o episódio 42. Se você é geek que nem eu sabe que 42 é um número especial. Segundo o sábio profeta Douglas Adams o número 42 é a resposta da vida, do universo e de tudo. Se não acreditam leiam a bíblia do Guia do Mochileiro das Galáxias. De curiosidade é por isso que minha empresa se chama Codeminer 42. E em especial este ano eu vou completar meus 42 anos. Mas chega de numerologia, vamos começar a história de hoje.

(…)

Como vocês viram nos vídeos passados, acho que deu pra entender que a Microsoft foi um rolo compressor nos anos 90 empurrando tecnologia atrás de tecnologia, boas ou ruins. Depois ela foi bruscamente parada no começo do século por causa do julgamento anti-truste. E de 2001 até pelo menos 2014, quem calçou seus sapatos de certa forma foi a Apple. Sem repetir muito o que todo mundo já sabe vamos resumir: em 1999 os iMacs translúcidos de plástico colorido foram um enorme sucesso pra marcar o retorno de Steve Jobs, numa época onde a Apple estava a dias de fechar as portas e declarar falência. Em 2001 surgia o Mac OS X baseado no NextStep e BSD UNIX, também em 2001 o iPod conquistou o mundo, em 2003 o iTunes conquistou o mundo.

Em 2005 com a ascendência do Ruby on Rails e a preferência por Macs de seu criador fez com que a comunidade Rails e o gosto pela estética da Apple andassem lado a lado. De 2005 a 2006 a Apple migrou dos processadores PowerPC pra Intel e de repente todo mundo queria usar Macs pra desenvolvimento já que ele era um sabor de BSD UNIX. Diversas ferramentas que só existiam em Linux passaram a ser portados. Gerenciadores de pacotes como Fink, MacPorts e hoje HomeBrew começaram a surgir. E mais importante, Ruby vinha pré-instalado nos Macs, facilitando ainda mais a adoção inicial.

Por duas vezes a Apple não só passou ilesa como explodiu em crescimento no meio de duas grandes crises. Em 2001 ela lançou seu iPod bem na queda da Crash das Ponto Coms, um dos piores episódios da história da Internet. E em 2007 os iPhones aparecem, 1 ano antes da famosa crise econômica de 2008 que muitos diziam que poderia ser o fim do mundo, e você pode assistir em filmes recentes como o incrível The Big Short. Mesmo em meio a essa crise, em 2009 a App Store vai ao ar inaugurando a era do desenvolvimento mobile e todo mundo quer aprender Objective-C agora, validando o estilo de orientação a objetos que já era mais familiar a quem usava Ruby do que quem usava Java. A Apple forçou a evolução da Web em direção à morte do Flash, e ao HTML 5 e CSS 3 que rodavam melhor nos seus navegadores Safari. E com o nascimento do MobileMe que foi o serviço online de cloud da Apple; nasceu o framework javascript SproutCore, que depois viria a se tornar Ember, inaugurando o estilo de produtos Web que conhecemos hoje.

Pós crise de 2008 e 2009, todo mundo queria desenvolver produtos mais sofisticados, com linguagem visual limpa, com a usabilidade que a Apple era lendária por oferecer em seus produtos. Mesmo antes disso, enquanto o mundo enterprise estava adotando soluções J2EE como o IBM Websphere ou BEA Weblogic a própria Apple tinha uma arquitetura mais simples e mais sofisticada na forma do WebObjects que era o motor por trás do lendário e-commerce da Apple na época. Uma pena que o WebObjects nunca teve real tração. Toda essa experiência trouxe a Apple como uma das maiores influenciadoras das tecnologias da época. E isso coincidiu com o pior período da história da Microsoft pós-processo dos Estados Unidos contra suas práticas monopolistas depois da Guerra dos Navegadores, então a Apple praticamente não teve competição.

Voltando ao nosso tema de programação e linguagens, entenda que 2006 e 2007 foram anos interessantes pro mundo dos compiladores por três motivos: a migração da plataforma de Macs para Intel, o lançamento do iPhone e a migração no mundo de software livre da famosa licença GPL v2 para o controverso GPL v3. Esses três acontecimentos, na minha opinião, influenciaram muito o landscape de desenvolvimento de software entre os mundos comercial e de software livre, e eu acho que ainda não vimos tudo que pode sair disso até hoje.

No ano 2000 um novo projeto começou a aparecer como uma pesquisa, o Low Level Virtual Machine de Chris Lattner e Vikram Adve. Em resumo essa tecnologia se tornou um compilador modular que chamamos de LLVM apesar de não ser de fato uma máquina virtual como uma JVM. O monopólio dos compiladores, principalmente no mundo open source, era basicamente do GCC, responsável por compilar os códigos em C, C++ e várias outras linguagens, incluindo coisas como Fortran, e que gera o binário da kernel Linux e todas as ferramentas de licença aberta que rodam ao seu redor nas distribuições Linux. Mas o GCC é um grande monolito, com mais de 25 anos de contribuições e evoluções, complicado de evoluir, expandir e integrar. Porém com décadas de refinamento e ajustes, é definitivamente um dos melhores compiladores do mercado.

O LLVM foi criado pra ser diferente, ele separou o processo de compilação em 3 grandes estágios, front-end, otimização e back-end. Não confundir com as carreiras de front-end e back-end. Pense na entrada do compilador que é o front, o miolo, e a saída do compilador que é o back, Vale a pena eu explicar o que isso significa. Em resumo, o front-end pega o seu código fonte, digamos em C, e faz a checagem e o parsing. O resultado desse estágio é seu código limpo e traduzido em outra linguagem intermediária, chamada literalmente de Intermediate Representation ou IR. Não seria muito diferente do Java gerando bytecodes ou do .NET que gera em IL pro CLR que é literalmente Intermediate Language. Também meio parecido com o que um transpiler de Coffeescript ou Dart ou Typescript faz transformando em Javascript por baixo. Na sequência esse código em IR passa pelo tal miolo, a fase de otimização, que vai fazer todas aquelas otimizações que eu expliquei no episódio anterior pra deixar seu código o mais eficiente possível. Inclusive como o GCC e outros compiladores, essa fase pode precisar “passar” pelo código múltiplas vezes, você às vezes vai ver esse termo “passes” porque algumas otimizações exigem conhecimento do código anterior. Finalmente o LLVM pega esse sub-produto otimizado e passa pro back-end, que vai finalmente traduzir em binário de máquina, gerando o executável do seu programa. Mas o importante é entender que existem 3 grandes pedaços de software independentes que, juntos, formam o compilador.

Então, em vez de usar GCC pra compilar C, você pode substituir por Clang que é um front-end de C feito pra LLVM. Teoricamente hoje você poderia tirar o GCC e recompilar uma distribuição Linux inteira usando Clang, até existem projetos testando isso. Por muitos anos, fazer o LLVM cuspir um binário tão otimizado quanto o de GCC foi bem difícil. E também havia a questão: pra que eu quero substituir o GCC se ele já funciona tão bem?

Em 2005 a Apple fez um de seus movimentos mais interessantes e pouco comentados e contratou Chris Lattner, que na época estava em início de carreira na Microsoft Research. Em 2006 Steve Jobs sobe ao palco na conferência WWDC e anuncia a transição da plataforma Mac dos processadores IBM PowerPC para Intel, mais especificamente a nova linha de processadores Intel Core. O sistema operacional OS X 10.4 Tiger foi o primeiro compilado ainda com GCC pra rodar tanto em PowerPC quanto Intel.

Mas em 2007 teríamos a sequência com o OS X 10.5 Leopard e o XCode 3.1, a IDE de desenvolvimento pra Mac e junto com ela viria o compilador GCC 4.2 e junto o LLVM integrado ao code generator do GCC, que foi conhecido como LLVM-GCC. O XCode 4.1 da época do Mac OS X Lion de 2011 foi o último a vir com o GCC como compilador, e de lá em diante o desenvolvimento em MacOS e iOS depende só do Clang. Ou seja, de 2006 até 2008 os produtos com processadores PowerPC foram todos migrados para Intel. Mas mais importante que isso, o compilador GCC foi sendo gradativamente substituído por Clang, a partir de 2007 até pelo menos 2011. Guarde essa informação.

No começo do século um novo tipo de produto começou a fazer um sucesso estrondoso. Lembra quando eu contei qual era o objetivo original do Java quando ele foi criado no começo dos anos 90? Ser um sistema pra um hardware de set-top-boxes. Ele estava quase uma década adiantado porque foi só nos anos 2000 que esse tipo de produto realmente explodiu, em particular o Tivo. Aqui no Brasil não tivemos Tivo mas tivemos similares. Era aquele produto que você podia gravar programas de TV a cabo pra assistir depois. É o que se chamava de DVR ou Digital Video Recorder, basicamente um receptor de sinal analógico, que digitalizava o vídeo e gravava organizado num HD. Acho que até hoje algumas empresas de TV a cabo ainda oferecem esse tipo de produto. Mas nos Estados Unidos o Tivo teve um sucesso explosivo. Tecnicamente falando ele era um mini-pczinho com uma placa de captura de vídeo que rodava uma versão de distribuição Linux.

Não é hoje que vou entrar em detalhes sobre licenças de software livra, mas a kernel Linux e a maioria das ferramentas que compõe uma distribuição que forma um sistema operacional completo, as ferramentas GNU, o compilador GCC e tudo mais usavam a licença GPL v2. GPL que significa General Protection License. Na prática, qualquer um, especialmente qualquer empresa que modifique código licenciado via GPL é obrigado a republicar as modificações ao público. O GPL não é uma unaminidade, por isso existem outras licenças, mas a maioria das coisas num Linux costumava ser GPL. E foi o que a Tivo fez: ela seguiu a licença e liberou as modificações que fez. Isso inclusive permitia que hobistas pudessem baixar esse código, fazer suas próprias modificações e carregar no Tivo. Então era como se fosse um PCzinho que dava pra brincar e instalar seus próprios programas.

Pelo menos naquela época, a maioria das empresas não gostava que seus dispositivos fossem modificados pra fazer coisas que não deveriam. Existem motivos pra isso, e nem vou entrar no mérito de certo ou errado, vamos só entender que eles não gostavam. Então na série 2 eles adicionaram um hardware que validava a assinatura do binário. Eu não sei como exatamente eles faziam isso, mas se você é iniciante vale entender pelo menos o conceito básico. Existe uma coisa em computação que chamamos de hashing. Existem algoritmos como os antigos MD5 ou SHA-1 ou os atuais SHA-256 ou bcrypt. Sem entender de criptografia entenda que eles são funções. O argumento de entrada pode ser qualquer bloco de dados, seja texto ou seja um binário. E a saída é sempre um texto de tamanho fixo.

Isso não é encriptação. Quando se encripta alguma coisa, você consegue reverter o processo e desencriptar. Em hashing não existe forma de pegar o resultado e reverter o processo e conseguir o argumento original. Dois blocos de dados diferentes podem dar o mesmo resultado, isso seria o que chamamos de colisão, mas é raro que isso aconteça num cenário real. O importante é que esse resultado serve como uma impressão digital, um fingerprint, de seja lá qual dado você tenha passado pra função. Ou seja, digamos que você passe o binário do kernel Linux. E o Tivo tem um firmware separado que quando carrega a kernel passa o binário por essa função e compara com a impressão digital que ele tem guardado num hardware que você não pode modificar.

Ou seja, se você modificou o kernel e instalou lá, a impressão digital vai ser diferente, então o Tivo pode rejeitar esse novo binário e impedir o boot. Essa seria uma forma simplória de fazer isso. Existem formas mais sofisticadas mas esse exemplo deve ajudar a entender parte do processo. Isso seria um tipo de DRM ou Digital Rights Management que a indústria de música adorava. Mas a Tivo achou um loophole no GPL v2, uma brecha na licença. A licença obrigava a liberar o código modificado, e isso eles fizeram, mas ela não fala nada sobre impedir o hardware de rodar código modificado no seu hardware.

Isso foi uma controvérsia gigante porque esse sistema de DRM, do ponto de vista dos desenvolvedores, restringia a liberdade do que o consumidor poderia fazer com o hardware que ele comprou. Isso gerou uma enorme polarização na opinião se uma empresa podia ou não fazer isso. Richard Stallman e Eben Mogler, os criadores da licença GPL ficaram enfurecidos, porque a GPL v2 não conseguia proibir essa atitude. Então eles iniciaram a modificação da GPL v2 para o novo GPL v3 que adicionava cláusulas que impediria isso que eles chamaram de “Tivoização”. E se você acha que o mundo open source apoiou essa medida, você está enganado. Isso gerou uma nova controvérsia e uma nova polarização. Por exemplo, Linus Torvalds odiou a medida e a kernel do Linux permanece na GPL v2.

Como eu já havia explicado no episódio da Lerna vs a ICE, licenças de software livre podem ser divididas em duas grandes categorias: as licenças restritivas e as licenças permissivas. Ao contrário do que o senso comum pode imaginar, o GPL é uma licença restritiva. Licenças como BSD, MIT, Apache e outras são mais permissivas. Em última instância a GPL impõe uma restrição importante: você é obrigado a liberar qualquer modificação que fizer num código GPL e essa modificação também será GPL. E sem cláusulas especiais e sub-licenças como LGPL você teria que se preocupar inclusive, se o binário gerado por um compilador com licença GPL se ela herda o GPL e se pode ser usada livremente ou não. É por isso que inclusive muitos chamam a GPL de uma licença viral. Já código licenciado via BSD por exemplo, não tem essa restrição. Você pode modificar o código e não tem a obrigação de liberar a modificação. Você pode gerar um binário e comercializar o binário e não se preocupar em ter que liberar o código.

A discussão sobre licenças de software livre é em última instância uma discussão sobre propriedade intelectual. A maioria das empresas prefere ficar bem longe de licenças restritivas pra não comprometer suas propriedades intelectuais, que é o que garante o seu valor. Nos anos recentes no começo dos anos 2000 tivemos grandes casos controversos em torno de propriedade intelectual no mundo open source como o famoso caso da SCO ou Santa Cruz Operation que processou a IBM pedindo nada menos que 1 bilhão de dólares, alegando que eles infringiram na sua propriedade do UNIX e usaram esse conhecimento nas contribuições ao Linux que a IBM fazia.

Se a SCO tivesse ganhado isso teria sido uma bomba nuclear tornando o Linux material radioativo pra quem usasse. Mas numa virada de eventos um juiz determinou que quem possuía os direitos que a SCO clamava na verdade era a Novell. E nessa mesma época por 2005 ou 2006 a Microsoft fechou um acordo de 400 milhões de dólares com a Novell que era dona do Suse Linux, cujo combinado era que uma não iria processar a outra em torno de propriedade intelectual, meio que sugerindo que haveria alguma coisa no Linux que deixaria quem não usasse Suse Linux vulnerável a algum processo no futuro de alguma forma. A comunidade open source odiou esse movimento, claro.

Certo ou errado, vocês podem entender pelo menos porque levar propriedade intelectual e licenças a sério é importante, principalmente nos Estados Unidos. À medida que as empresas iam adotando tecnologias open source, essa dúvida sempre deixa todos com os nervos à flor da pele. Se o Linux, que é a kernel por baixo de todas as distribuições e que estava sendo adotado rápido por todos, fosse condenado num processo desses, ele se tornaria material radioativo e toda empresa usando poderia descobrir uma bomba relógio explodindo. Isso é realmente sério. Se nos anos 2000 alguém perguntasse porque a Apple preferiu usar a base do FreeBSD nos OS X em vez do Linux, esse certamente poderia ser considerado um dos principais motivos: o FreeBSD usa licença BSD que é bem permissivo, ao contrário da GPL que tinha todas essas dúvidas pairando no ar.

Agora, o GPL v3 é um problema sério. Que outra empresa além da Tivo prefere manter certos códigos escondidos e dificultar você de instalar o que quiser em seus hardwares? Eu sempre fui fã da Apple e certamente a integração de hardware e software que eles fazem é excepcional, mas se você pensar puramente em questão de software livre, você vai ficar no mínimo em cima do muro com as práticas da Apple. E não confunda, sim, a Apple tem o código da base do seu sistema operacional aberto ao público na forma do Darwin, mas o MacOS é bem mais que só o Darwin, tem centenas de componentes que eles não querem abrir, incluindo a forma como o sistema se integra perfeitamente nos Macs e Macbook e, claro, nos iPhones de hoje. Se você notou que um iPhone faz a mesma coisa que um Tivo, impedindo você de instalar outro sistema nele, você pensou certo.

No outro lado do espectro, além de distribuições baseadas na kernel Linux, existem as distribuições baseadas em BSD, como FreeBSD, OpenBSD, NetBSD. O Linux é como se fosse um clone de UNIX, mas os BSDs em princípio são herdeiros do UNIX original. BSD seria o concorrente da outra linhagem de UNIX, o System V que deriva da época do UNIX System III da AT&T. Como o próprio nome diz, a filosofia dessas distribuições é Software Livre no sentido mais permissivo e liberal, com a licença BSD. Vamos dizer que eles “toleram” a GPL mas nunca gostaram dela e o GPL v3 foi uma afronta direta e ofensiva pra eles, e podemos dizer que eles não gostaram nada das cláusulas restritivas anti-Tivoização. Existe uma longa história de brigas políticas em torno do que é considerado Software Livre ou não e vou parar por aqui pra não me alongar demais por hoje.

O maior problema? Tudo no mundo open source era compilado com o GCC. Como eu já expliquei no episódio sobre a Lerna vs a ICE, licenças não podem ser mudadas retroativamente, só em novas versões. Como quem controla o GCC é o Richard Stallman, ele migraria pra nova GPL v3. Ou seja, quem não quisesse adotar a nova licença ficaria preso na versão 4 do GCC que ainda seria GPL v2. Então começou uma corrida contra o relógio. Você pode ficar usando o GCC que ainda era GPL v2 mas quanto mais tempo passa, mais ele fica defasado e até inseguro, já que correções e novas funcionalidade só iriam subir no GCC com GPL v3.

Resumo da história? Tanto FreeBSD quanto a Apple começaram um projeto que iria levar alguns anos pra sair do GCC e migrar a compilação de tudo pra usar LLVM e Clang, que era o único concorrente viável ao GCC. Se você alguma vez já se perguntou porque no MacOS vem um Bash tão antigo? Porque além do GCC outras ferramentas GNU mudaram pro GPL v3, o Bash foi um deles. Por isso hoje se instala o Bash mais novo e outras ferramentas com versões mais novas, como o próprio Git, você mesmo via Homebrew ou de outra forma manual como baixar os códigos fonte e gerando binários você mesmo. E por isso às vezes você tem confusão de compilar usando GCC ou Clang.

Pra Apple, além da questão das licenças, a linguagem Objective-C que é o coração dos frameworks de aplicativos nativos de MacOS e iOS nunca teve prioridade no grupo de desenvolvimento do GCC. Por causa disso o projeto Clang começou a avançar a passos mais largos e por isso eles começaram a estratégia de primeiro começar a usar GCC como o front-end pra LLVM, já que a primeira coisa mais difícil era parsear corretamente os códigos em C, C++ e Objective-C e por isso você começa com LLVM-GCC como eu disse antes. À medida que a compatibilidade do front-end entre GCC e Clang ficou mais próxima, daí eles começaram a colocar Clang como escolha padrão até finalmente remover completamente o GCC antigo.

Nesse período de 2006 então a Apple estava migrando seus sistemas operacionais de PowerPC pra Intel e ao mesmo tempo já estava planejando outro dispositivo pra ser lançado em 2007: o primeiro iPhone. E os iPhones não usam processador Intel e sim ARM. E os iPhones seriam sempre produzidos com o bloqueio de DRM pra impedir outro sistema de rodar no hardware, ou seja, eles seriam Tivoizados. E com todos os aplicativos desenvolvidos usando Objective-C e com a necessidade de compilar binários nativos pra Intel e para ARM.

Agora vamos entender outra coisa do LLVM que eu não disse antes. O LLVM é um conjunto modular de bibliotecas. O compilador Clang é um conjunto dessas bibliotecas. Como ele foi desenhado pra ser modular, significa que você teria relativa facilidade de trocar partes do front-end ou do back-end. Por exemplo, você pode fazer back-ends que cospem binários em Intel ou PowerPC ou ARM ou qualquer outro tipo de hardware. E como o front-end também é modular e ele cospe em IR antes de passar pro módulo de otimização, você também tem facilidade de integrar no XCode pra fazer análise estática do código e debug. Com a integração de ferramentas sofisticadas como o famoso DTrace do antigo Solaris e a substituição do debugger GDB que era usado com GCC pelo LLDB, a IDE do XCode foi ficando mais e mais avançada para conseguir instrumentar o código e otimizar muito melhor do que antes.

Ao mesmo tempo que Chris Lattner e sua equipe iam evoluindo o LLVM dentro da Apple, muitas das pesquisas geraram novas funcionalidades primeiro no próprio Objective-C como a introdução de lambdas e o ARC que é o Automatic Reference Counting. Pra você que é iniciante, na maioria das linguagens mais modernas você não pensa muito em gerenciar memória porque linguagens como Java tem garbage collectors, ou seja, o runtime gerencia a memória por você. Mas se você começou a aprender com linguagens como C, sabe que precisa você mesmo codificar o gerenciamento de memória manualmente. Ou seja, no seu código você chama funções como malloc e free e outros pra pedir memória pro sistema operacional e depois devolver essa memória. Lembra que eu falei que além de multi-thread o outro aspecto em programação mais difícil é gerenciamento de memória?

Pois é, à medida que sua aplicação fica complexa, você vai errar isso. Ao longo da sua carreira você vai ficar ouvindo falar de vazamento de memória por exemplo. Gerenciar memória é complicado, porque memória se fragmenta, você precisa lidar com coisas como regiões, arenas e muitos outros detalhes. Mas se você tem uma máquina potente, digamos, com 8GB de RAM ou mais, você fica preguiçoso e não percebe vazamentos porque tem memória sobrando. Pra facilitar se falta memória RAM o sistema operacional ainda tem a opção de usar o HD como memória. É isso que se chama de SWAP. Se você chega nesse ponto com uma aplicação mal feita que vaza memória, tudo bem, o sistema vai passar a usar HD. Tudo vai ficar lento pra caramba, mas não vai crashear. Mas pense em 2007 um iPhone com meros 128MB de RAM pra comportar o sistema operacional e os aplicativos e sem a opção de um HD pra fazer swap. Ou seja, se faltar memória o sistema vai crashear o aplicativo. Então gerenciar memória se torna especialmente importante em dispositivos com poucos recursos.

E como Objective-C é basicamente compatível com C e usa a mesma semântica de você manualmente codificar onde quer alocar memória e onde quer devolver essa memória, os primeiros aplicativos pra iOS que eram feitos por amadores ou mesmo por descuido acabavam tendo muitos vazamentos e crasheavam dando uma má experiência aos usuários. Por isso recursos como o ARC que foram introduzidos ao Objective-C eram importantes, pra evitar que você precise manualmente escrever código pra gerenciar memória, além da introdução de ferramentas como o DTrace e LLDB pra instrumentar seu código e conseguir analisar exatamente onde estão ocorrendo vazamentos, pra que você consiga consertar antes de mandar o binário final pra App Store.

E como desenvolvedor você ainda tem outro problema grave. Se você já tentou desenvolver pra Android deve ter notado que se quiser testar seu código antes de instalar no celular, a única forma de rodar no seu computador é usando uma máquina virtual. Não estou falando da JVM mas de máquinas virtuais de verdade como QEMU, VirtualBox ou VMWare. Primeiro porque o Android é um sistema operacional baseado em Linux e os binários estão pré-compilados pra processadores ARM. E binários de ARM não são compatíveis com processadores Intel que roda na sua máquina de desenvolvimento, seja PC ou Mac.

A única forma então é usar um emulador, que é uma máquina virtual, que vai traduzir as instruções de ARM em instruções de Intel. Quando você ouve que seu novo Samsung S10 ou mesmo Xiaomi Mi Mix rodam Qualcomm, você sabe que é um processador ARM. Então você programa seu aplicativo pra Android e sobe um emulador de Android como o da Bluestacks ou Nox ou qualquer outro no seu PC e ele vai emular o Android fazendo ele pensar que está rodando numa máquina ARM. Por isso é tudo tão absurdamente lento pra testar seu código, porque emular exige essa tradução de instruções e isso é lento. Não tem jeito.

Mas se você já desenvolveu pra iOS em Macs sabe que a mesma coisa não acontece quando você pede pra testar seu novo app de iPhone no seu Mac. Seu app roda com velocidade total, sem nenhuma lentidão. E você vai notar no XCode que quando vai rodar seu app no seu Mac de desenvolvimento, não existe uma opção pra subir um Emulador, como no Android, e sim um Simulador. A Apple fez uma coisa difícil mas que se pagou: eles compilam o sistema operacional iOS que roda em iPhone e iPad pra binários de Intel de verdade. Então quando você sobe o simulador, ele não precisa de uma máquina virtual pra traduzir as instruções, ele já é binário de Intel! E quando você compila seu projeto pra rodar no simulador o XCode está usando o LLVM pra cuspir binários de Intel também. Só quando você manda empacotar pra publicar na App Store que ele vai compilar em binário de ARM. Parece uma coisa meio óbvia de fazer, mas fazer isso da forma quase transparente como o XCode faz é impressionante até hoje dado que as ferramentas de desenvolvimento de Android do Google até hoje não fazem isso.

Por outro lado, alguns podem argumentar que apesar das funcionalidades impressionantes que a Apple conseguiu colocar no Objective-C, ele ainda tem a sensação de ser uma linguagem com sintaxe muito velha, especialmente se comparado ao Android onde o Google resolveu copiar a linguagem Java, embora similar ao J++ da Microsoft nos anos 90, ele também não é compatível com a JVM de verdade. O runtime do Android, o Dalvik é diferente. De qualquer forma, já discutimos como a linguagem Java também tem sintaxe considerada meio velha se comparada a coisas como Python ou Ruby ou mesmo Groovy. Mas se comparar com Objective-C - que eu pessoalmente gosto - a maioria vai dizer que prefere Java por estar mais acostumado e ter visto na faculdade.

Enquanto evoluía o LLVM, o Clang, os frameworks de iOS, as tecnologias do XCode, Chris Lattner começou a pensar numa nova sintaxe de linguagem. Assim em 2010 surgia o Swift, uma linguagem que é extremamente agradável ordens de grandeza se comparado ao Objective-C. E aqui surge outra enorme vantagem do LLVM. Assim como você pode ter back-ends que cospem binários de Intel ou ARM, você também pode ter múltiplos front-end. Você já tinha o front-end que entendia Objective-C, então eles fizeram um novo front-end pra essa nova linguagem Swift. E qual a vantagem? Os binários de ambos Objective-C e Swift são compatíveis entre si. Então seria super fácil você migrar pra Swift e continuar consumindo as mesmas bibliotecas e frameworks que já existiam e eram feitos em Objective-C. Você não precisa reescrever tudo em Swift, pode migrar aos poucos.

Então no mundo de Mac e iOS você tem agora a escolha de usar Swift com sua sintaxe bem mais moderna inspirada em Ruby, Python, Groovy e outras linguagens, com construções modernas, com o ARC pra gerenciar memória e ter a facilidade de rodar sua aplicação iOS em velocidade máxima no simulador de iOS com tudo compilado em binário de Intel e depois facilmente empacotar em binário de ARM pra rodar no seu iPhone de verdade. Por isso muitos desenvolvedores preferem criar apps pra iOS antes de Android até hoje.

No mundo Android as coisas não eram muito agradáveis. O Google também teve sua parcela de dor de cabeça com processo por propriedade intelectual. Lembram que eu já falei várias vezes que a Sun tinha sido adquirida pela Oracle? Então, eles foram processados por usar Java e a Oracle veio atrás com força. Oito anos depois o processo ainda não acabou e em 2018 a Oracle estava ganhando a batalha. Mas todo esse stress não faz o Google ter muito amor pelo Java. Ao mesmo tempo eles decidiram começar a mudar o foco do Java pra outra linguagem, no caso o Kotlin.

No Android o processo é o seguinte: você escreve seu código em Java e pode usar um compilador normal pra gerar bytecodes Java. Por isso você pode também usar muitas bibliotecas Java que já existem. Daí o bytecode Java é traduzido num segundo conjunto diferente de bytecodes chamado DEX que é o que roda no Dalvik. Antes esse DEX era interpretado no Dalvik, e tinha mais ou menos as mesmas funcionalidades que uma JVM como um Just-in-time compiler ou JIT pra gerar o binário nativo de ARM à medida que era executado. Como eu também já disse, isso é bacana pra aplicativos que rodam num servidor que fica de pé por dias e dias. Mas num dispositivo móvel que você abre um aplicativo e fecha a qualquer momento, um JIT ajuda mas não tanto assim, porque ele não tem tempo pra otimizar como poderia. Fora que rodar um compilador JIT também consome processamento, e isso consome bateria, que é outra coisa que sempre falta em dispositivos móveis.

Então nas versões mais recentes o bytecode DEX é pré-compilado em binário nativo antes de rodar, esse é o processo que você vai ouvir falar como AOT ou Ahead-of-Time compiler. Que é o que um compilador normal como GCC ou Clang fazem: geram binários nativos. O processo de desenvolvimento no Android tem mais passos pra poder ter essa opção de compatibilidade com o bytecode Java, que foi uma jogada importante pra conseguir trazer programadores Java pro mundo Android sem precisar ensinar uma nova linguagem pra todo mundo.

Mas ao mesmo tempo temos a Oracle baforando no cangote do Google e a essa altura já disse várias vezes que Java é uma linguagem que já não é mais considerada agradável de trabalhar e nem tão produtiva se comparado a outras linguagens como o novo Swift. Então o Google foi bater na porta de outra empresa, a JetBrains, que a anos faz uma das melhores IDEs comerciais pro mundo Java, e em 2011 havia começado a criar uma nova linguagem, que assim como Groovy ou Scala ou Clojure também compilam em bytecode compatível com Java. Pro Google foi uma escolha fácil porque eles negociaram pra liberar as ferramentas da JetBrains de graça pra desenvolvedores Android e a evangelizar a nova linguagem deles, que é chamado de Kotlin. Kotlin que é finalmente uma linguagem moderna mas familiar e ser ser exótica demais como Clojure.

Então no mundo mobile, em iOS você ainda pode usar Objective-C que é considerado uma linguagem “velha” mas agora a maior parte do desenvolvimento é na linguagem Swift que é bem mais moderna e produtiva. Mesma coisa no mundo Android onde você ainda pode usar a linguagem Java e as bibliotecas Java que também já é considerado meio “velho” por muita gente mas também pode migrar pro Kotlin que está ainda em adoção por toda a comunidade Android. Você pode até misturar código Kotlin e Java no mesmo projeto. Na verdade, por coincidência, seja porque ambas se inspiraram em fontes parecidas na linhagem de linguagens, Swift e Kotlin tem sintaxes até que similares. Dependendo do código que você ver, pode até quase confundir um pelo outro. Claro, as bibliotecas de iOS e Android são bem diferentes, mas as duas linguagens são igualmente modernas e eu pessoalmente diria que são as melhores até agora para o mundo geral de programação de aplicativos, especialmente se comparar com Java ou C#.

Mas deixando o mundo mobile um pouco de lado, um dos resultados de tudo isso foi a evolução rápida do LLVM enquanto uma solução robusta pra desenvolvimento de compiladores. Em vez de ter que mexer no monolito complicado que é o GCC e ainda ter que lidar com a política da licença GPL v3, você pode ir pro LLVM e foi isso que muita gente fez, menos o Google. Pra ser justo, o Google contribui pro LLVM também mas não usa tão extensivamente quanto a Apple. A linguagem Go eles preferiram criar o compilador do zero, primeiro em C e depois traduzindo o código C no próprio Go. Lembra que eu falo que o Google tem a péssima mania de ficar reinventando a roda? A gente chama isso de NIH ou síndrome de Not-Invented Here, muitos programadores sofrem dessa síndrome de prima-donna de achar que pode fazer melhor que os outros.

Mas já sabemos que C/C++, Objective-C e Swift tem front-ends pra LLVM e sabemos que ele tem back-ends que geram binários pra Intel e ARM. E sabemos que ele tem um design mais moderno, mais modular e com ferramentas mais modernas pra desenvolvedores como o LLDB que muitos consideram melhor do que o antigo GDB. E ele ficou muito bom em otimizar o IR pra gerar binários nativos quase tão performáticos quanto o GCC. Isso abre uma oceano de possibilidades. E se decidíssemos criar mais front-ends pra outras linguagens?

E foi isso que a comunidade open source começou mesmo a fazer. Hoje temos front-ends de LLVM pra ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Fortran, Graphical G, Halide, Haskell, bytecode Java, Julia, Kotlin, Lua, Objective-C, a linguagem de shading de OpenGL, Pony, Python, R, Ruby, Rust, Scala, Swift, e Xojo. Mas claro, algumas estão mais avançadas do que outras, algumas são mais experimentais. Algumas usam só algumas funcionalidades como o Just-in-Time compiler do LLVM que é o caso da linguagem Julia e inclusive em lugares inusitados como o banco de dados PostgreSQL que hoje também usa o JIT do LLVM pra otimizar queries complexas.

Uma das linguagens que você mais deve ter ouvido falar que depende de LLVM é o Rust da Mozilla. Agora você sabe o que roda por baixo do Rust e quem gera os binários. A linguagem Rust é uma das mais diferentes de todas que já mencionamos até agora. Sem entrar em muitos detalhes hoje, ela tem um foco maior no problema do gerenciamento de memória combinado com preocupação de segurança. Mas seu maior problema é o que chamamos da ergonomia da linguagem. Apesar de ser uma sintaxe moderna, ela realmente exige mais do desenvolvedor se comparado a um Swift ou Kotlin. Partes do Firefox hoje são escritos com Rust e, adivinhem, alguns evangelistas da linguagem são ex-rubistas também.

Outra linguagem que compila com LLVM que ainda não é muito conhecida mas que eu pessoalmente gosto bastante é a Crystal. Ela se parece muito, mas muito mesmo com Ruby já que é inspirada diretamente nela, e em alguns casos você pode quase copiar e colar trechos de código Ruby e compilar com Crystal sem mexer em nada, então a curva de aprendizado pra quem vem de Ruby é muito mais simples. Ao contrário de Rust a ergonomia da linguagem é muito melhor. Mas Rust tem características que a tornam mais adequadas como substituto de C pra desenvolver código nativo rápido e leve. O Crystal se assemelha mais ao Go, ele tem um runtime maior e um garbage collector maior também. Diferente do Go que tem o investimento infinito Google por trás, o Crystal é um esforço quase voluntário da comunidade, por isso anda mais devagar. Mas graças ao LLVM os binários que o Crystal gera são competitivos com Go mesmo nesse estágio.

E mesmo sem ser programador você provavelmente usa tecnologias LLVM hoje e nem sabe disso. Por exemplo tanto o SpiderMonkey que é a engine, ou motor, de Javascript do navegador Safari no MacOS e no iOS quanto o V8 que é a engine de Javascript do Chrome possuem a funcionalidade de Just-in-Time Compiler ou JIT que eu mencionei já hoje e no episódio anterior. Repetindo: Javascript é uma linguagem interpretada, como Python ou Ruby. O SpiderMonkey e o V8 recebem o arquivo de texto escrito em Javascript e fazem um parsing e começam a interpretar o código.

Porém como vocês já sabem e eu expliquei no episódio da História do Front-end nesta série, começou a surgir o conceito de Single Page Application, que é basicamente um site que se comporta mais como um aplicativo de desktop do que um site web normal de conteúdo. Na prática são sites onde você não fica navegando entre diversas páginas, você carrega uma página e fica nela e por sua vez ela carrega muito javascript pra controlar o comportamento. Imagine Google Docs, ou Spotify. Nesses casos as engines de Javascript, quando percebem que estão rodando faz algum tempo começam um processo que é mais devagar, que é o JIT, e começam a otimizar e compilar as partes do código Javascript mais executadas em binário nativo, que ainda depende do runtime das engines, mas é bem mais eficiente do que interpretação. No caso, o SpiderMonkey usa o JIT do LLVM. SpiderMonkey e V8 passaram anos evoluindo e competindo pra ver quem era o melhor e acho que isso continua assim até hoje.

Por isso aplicativos como Spotify, Atom, Slack, Discord e outros conseguem rodar com performance aceitável. Some a isso que os navegadores por baixo hoje suportam CSS acelerado pelo hardware gráfico, as GPUs como o que já vem integrado no seu processador Intel ou placas externas como os GeForce da NVIDIA ou os Radeon e Vega da AMD. A evolução do que chamamos de GPU foi uma explosão neste século como o de CPUs foi nos anos 70 a 2000. Num determinado momento as GPUs passaram a suportar shaders, que como o nome diz, serviam pra controlar a sombra ou tonalidade das cores. Mas em breve elas passaram a ser programáveis numa linguagem similar a C. E adivinhem, podemos acelerar esses shaders compilando em tempo real, via um JIT, usando LLVM hoje em dia. Por isso se você executar um VirtualBox, a renderização gráfica via software, que é lento, hoje é compilado via JIT por um driver chamado llvmpipe. Se você lida com desenvolvimento com placas NVIDIA tem o compilador pros CUDA cores da GeForce, e a NVIDIA contribuiu os códigos de back-end pra permitir gerar shaders pras suas placas diretamente no LLVM abrindo as portas pra qualquer linguagem poder se beneficiar do processamento paralelo massivo em GPUs.

Agora, o último assunto de hoje pra você entender como o LLVM pode ir mais longe. O Front-end pode ser qualquer linguagem, ele cospe o IR, que é otimizado e depois passado pra um Back-end, que também pode ser qualquer coisa, por exemplo, os back-ends que geram binários de Intel ou ARM como já repeti várias vezes. Porém, vocês já viram que existem os transpilers, como o do Typescript que cospe Javascript. E se pudéssemos usar um front-end de C como o Clang e usar um back-end que cospe Javascript?

Esse é o projeto Emscripten. A demonstração mais impressionante se não me engano em 2014 foi quando a Epic Games pegou uma animação usando a engine de jogos Unreal e compilou com esse Emscripten, usando LLVM, de C pra Javascript e somado às capacidades de aceleração via GPUs dos navegadores via WebGL, conseguiu rodar o que antes era um programa nativo dentro de um navegador, com excelente performance graças a tudo que eu expliquei que dá pra fazer com LLVM. Pra fazer isso, eles limitaram o Javascript num sub-conjunto que ficou conhecido como ASM.js. O conceito é simples: CPUs tem instruções nativas, que podemos escrever em Assembly e usar um Assembler pra cuspir o bytecode nativo da máquina. Máquinas virtuais como a JVM tem seus bytecodes. E se considerarmos que o Javascript é um assembly da máquina virtual chamada navegador?

Isso abre todo um leque de possibilidades. E foi o que inspirou o projeto WebAssembly que surgiu pra formalizar esse sub-conjunto de Javascript que poderia ser o back-end pra compiladores baseados em LLVM. Hoje em dia ainda temos o Enscripten pra compilar em ASM.js e o novo projeto Brynaryen que nasceu sendo uma extensão do Enscripten mas foi reescrito do zero em C++ pra gerar WebAssembly - maldita síndrome de not-invented here, a Mozilla também sofre disso como o Google. Ainda não tivemos nenhum resultado bombástico, mas diversos grupos estão fazendo experimentos pra entender o que realmente podemos fazer. Se você procurar por emscripten vai ver demonstrações muito interessantes, inclusive uma pequena distribuição de Linux compilado inteiro com Emscripten e rodando dentro do navegador, sem emulação nem nada. Na prática, no futuro, poderíamos escrever aplicativos Web em qualquer linguagem e compilar tanto pra WebAssembly quanto pra binário nativo se quiséssemos. Mas ainda estamos no começo dessa jornada.

E por hoje vamos ficar por aqui, pra variar virou um episódio grande, mas eu queria contar essa história pra que você pudessem entender como política influencia a evolução das linguagens, ferramentas e arquiteturas que nós usamos hoje. Não é só uma questão se determinada linguagem é mais rápida que outra ou não. Como programador você precisa entender como diversos fatores externos e modelos de negócio e interesses políticos influenciam tudo que você usa.

Na semana que vem vou retornar ao tema de back-end falando sobre outro assunto que é controverso e muitos se confundem até hoje: concorrência e paralelismo e como diferentes linguagens lidam com isso de formas diferentes. Se ficou com dúvidas nesse episódio não deixe de mandar nos comentários abaixo, se curtiram mandem um joinha, compartilhem com seus amigos, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. A gente se vê semana que vem, até mais!

]]>linguagens-de-programacaoappleopen-sourceakitandoDa Microsoft para a Apple e de Voltahttps://akitaonrails.github.io/2017/11/21/da-microsoft-para-a-apple-e-de-volta/https://akitaonrails.github.io/2017/11/21/da-microsoft-para-a-apple-e-de-volta/Tue, 21 Nov 2017 21:51:00 -0200<p>Este vai ser um artigo bem longo, se preparem.</p> <p>Para quem tem pressa, o resumo é este:</p> <ul> <li>Windows 10 ainda é Windows, mas não chega nem perto do pesadelo dos anos 2000. Merece uma segunda chance de verdade.</li> <li>O OS X está a caminho de se tornar apenas um runtime do Xcode. Rumores dizem que a Apple nem tem mais uma equipe dedicada ao SO de desktop. O foco é total no iOS e em transformar o iPad no substituto do computador.</li> <li>Linux é ótimo. Se você é desenvolvedor web em tempo integral, consegue trabalhar confortavelmente com Ubuntu ou Manjaro/Arch (minha recomendação pessoal).</li> </ul> <p>Melhor custo-benefício: o Dell XPS 13. O Surface Book 2 vale cada centavo se você é nerd como eu. Mas, como sempre, há ressalvas a discutir.</p>Este vai ser um artigo bem longo, se preparem.

Para quem tem pressa, o resumo é este:

  • Windows 10 ainda é Windows, mas não chega nem perto do pesadelo dos anos 2000. Merece uma segunda chance de verdade.
  • O OS X está a caminho de se tornar apenas um runtime do Xcode. Rumores dizem que a Apple nem tem mais uma equipe dedicada ao SO de desktop. O foco é total no iOS e em transformar o iPad no substituto do computador.
  • Linux é ótimo. Se você é desenvolvedor web em tempo integral, consegue trabalhar confortavelmente com Ubuntu ou Manjaro/Arch (minha recomendação pessoal).

Melhor custo-benefício: o Dell XPS 13. O Surface Book 2 vale cada centavo se você é nerd como eu. Mas, como sempre, há ressalvas a discutir.

Book 2

As Especificações

Não vou duplicar cada review de hardware que você encontra por aí. Todos são verdadeiros. Como o iFixIt diz: é a pior pontuação em reparabilidade. Como o MacBook, a linha Surface é uma declaração. É a melhor combinação de design e funcionalidade. A contrapartida é que tem zero de expansibilidade e você precisa tomar cuidado para não quebrá-lo. Se quebrar, garanta que tem garantia e exija a substituição.

Em termos de especificações, fica próximo dos outros notebooks top de linha.

O Surface Book 2 top de linha custa USD 3.299 e vem com SSD de 1 TB, 16 GB de RAM, GTX 1060 com 6 GB GDDR5, Intel Core i7 8ª geração Kaby Lake R, display 4K. Caríssimo, mas dá para justificar. Explico mais abaixo.

O Dell XPS 15" Touch top de linha custa USD 2.459 e vem com SSD de 1 TB, 32 GB de RAM, GTX 1050 com 4 GB GDDR5, Intel Core i7 7ª geração Kaby Lake, display 4K. O design do XPS é impecável faz pelo menos 3 gerações. Para mim, é o melhor custo-benefício.

O Razer Blade top de linha custa USD 2.599 e vem com SSD de 1 TB, 16 GB de RAM, GTX 1060 com 6 GB, Intel Core i7 7ª geração, display 4K. É provavelmente o melhor design industrial do grupo, com a atenção impecável da Razer aos detalhes. Mas também é o que tem menos suporte disponível e mais problemas de construção relatados, então cuidado ao comprar no exterior.

O HP Spectre x360 top de linha custa USD 1.499 e vem com SSD de 512 GB, GeForce MX150 com 2 GB GDDR5, Intel Core i7 8ª geração, display 4K. O design é lindo, super fino e conversível. As especificações não são lá essas coisas, mas é o mais barato entre os notebooks premium.

O Lenovo Yoga 920 14" Vibe top de linha custa USD 1.899 mas vem apenas com gráficos integrados Intel (sem GPU secundária), SSD de 1 TB, 16 GB de RAM, Intel Core i7 8ª geração, display 4K, e já inclui a Caneta. O design é ótimo, com uma dobradiça de quase 360 graus para usar como tablet. Um bom 2-em-1.

Agora, o MacBook Pro 15" top de linha custa USD 3.399 e vem com SSD de 1 TB, Radeon Pro 560 com 4 GB, Intel Core i7 7ª geração, display UHD e a infame touch bar (50% de chance de gostar). É isso. O design industrial e a construção ainda são excelentes, mas os concorrentes chegaram bem perto.

Se você usa aplicações gráficas intensivas, a Radeon Pro 560 é boa, mas a GTX 1060 é superior. Os displays UHD IPS (LCD) da Apple têm resolução máxima de 2560x1060. Todos os notebooks premium hoje vêm com displays 4K completos (LED) com resolução máxima de 3840x2160. A diferença é perceptível. Se você nunca viu um display 4K moderno, o display do MacBook vai parecer bom. E isso sem mencionar que todos são touchscreens com 4.096 pontos de sensibilidade. O que antes era gimmick hoje rivaliza com o melhor que a Wacom tem a oferecer. A linha Surface chega perto do topo da linha Wacom Cintiq e do novo iPad Pro. Estão no mesmo nível.

Há 2 aspectos do Surface Book 2 que deixam a desejar. Primeiro, a ausência de uma porta Thunderbolt 3 de verdade. Sem ela, você não consegue conectar armazenamentos externos modernos ou GPUs externas. O segundo é a fonte de alimentação fraca. Relatos indicam que em jogos muito exigentes (como Destiny 2 sem configuração adequada), o sistema throttla e drena a bateria mais rápido do que consegue carregar da tomada. The Verge quebrou essa história e a Microsoft ainda não apresentou solução. Então, se jogos são prioridade máxima, compre um Razer ou qualquer notebook específico para games, como um Alienware. O problema de bateria não é tão dramático quanto alguns relataram anteriormente.

Em termos de construção: Macs são todos feitos com a mesma construção unibody de alumínio. O Book 2 usa magnésio. Fica muito sólido e bem leve. Aliás, depois de tantos anos, todo mundo dominou o alumínio. E estão indo em outras direções. A Dell, por exemplo, usa fibra de carbono nos apoios de pulso, o que acho muito mais confortável. O magnésio também não é tão gelado quanto o alumínio. Gosto que os fabricantes superaram a fase de copiar e estão experimentando materiais novos e interessantes.

it’s not as thin

A Proposta de Valor

Já estabelecemos que o Surface Book 2 é caríssimo e nem é bom o suficiente para jogos muito exigentes como Destiny 2.

Onde ele realmente brilha é no fato de não ser um 2-em-1 conversível comum como o Spectre ou o Yoga. Você já sabe que a tela pode ser desacoplada da base.

A grande conquista da equipe Surface é a dobradiça fulcrum dinâmica. Uma maravilha de engenharia. Quando acoplada, não balança nem perto do que se esperaria. É muito sólida — você pode pegar o conjunto inteiro pela tela sem se preocupar que a base vai cair ou quebrar.

Quando ouvi falar nisso pela primeira vez, 2 anos atrás, achei legal mas pensei que poderia quebrar com o tempo, então esperei. Agora estou totalmente convencido porque 2 anos depois não se vê nenhum “hinge-gate” ou relatos massivos de dobradiças se desfazendo. E 2 anos depois nenhum outro fabricante tem isso. Se você não vê uma cópia barata vinda da China, é porque é muito difícil de construir. A Microsoft acertou em cheio nessa parte.

Com a tela removível, os componentes principais ficam todos atrás dela. CPU, GPU, RAM, SSD. Você tem um Intel i7 top de linha em um tablet! A bateria é compreensivelmente pequena (no máximo 3 horas) para alimentar um display 4K de 15" com capacidade touch e precisão suficiente para rivalizar com o iPad Pro e o Wacom Cintiq ou Mobile Studio.

O que a maioria não menciona é que, por causa disso, é o chassi da tela que esquenta. A base de performance fica fria! É super confortável ficar com ele no colo por muitas horas sem risco de ficar estéril ou cozinhar ovos no processo.

Tem potência para conectar 1 display 4K externo a 60hz ou dois displays 4K a 30hz. O MacBook Pro, com sua porta customizada, consegue alimentar um display 5K. Algo que a maioria dos notebooks ainda não consegue. Aí vai depender do uso.

Não sou designer de profissão, mas sou hobbyista. Depois de muitos anos de trabalho duro, acredito que posso me dar ao luxo de ter algo assim. E não me entendam mal, o Surface Pro é outra ótima opção para designers. O Surface Pro top de linha tem tudo que o Book 2 tem, sem a GTX 1060, mas custando USD 600 a menos, em USD 2.699. Acho que é um produto mais adequado para a maioria das pessoas que querem uma solução de esboço fácil de carregar.

Profissionais criativos são os que precisam ser mais cuidadosos nas especificações. Mas para a maioria dos profissionais sem demandas tão pesadas, dá para pagar bem mais barato. Não precisam de GPU extra, nem do i7 (um i5 já resolve), 8 GB de RAM são suficientes, até 256 GB de SSD já dão conta porque tudo hoje está na “Nuvem”. Esse é o Dell XPS 13 de USD 999. Ou a única opção comparável da Apple é o MacBook de USD 1.299 com um ridículo processador Intel m3. Para a maioria dos profissionais, o Dell XPS 13 mais barato é uma proposta de valor muito melhor do que o MacBook.

Para profissionais com demandas pesadas, o Dell XPS 15 é o melhor custo-benefício. O Surface Book 2 é o premium para quem valoriza a touchscreen mais do que o fluxo de trabalho. Em termos práticos: designers vão de Book 2, editores de vídeo ou modeladores 3D vão de Dell XPS.

Ah, e mais uma coisa sobre preço. O MacBook Pro 15" custa USD 3.399 e o Book 2 custa USD 3.299. Mas se você quiser um tablet, ainda precisa adicionar USD 949 por um iPad Pro de 12" com Wi-Fi e 256 GB de armazenamento. E vai acabar carregando uma mochila mais pesada.

Por que não instalar Linux?

Você não compra um produto Surface a menos que tenha interesse na experiência e no ecossistema da Surface Pen. Isso me parece óbvio, caso contrário você está melhor com um Dell XPS ou qualquer outro notebook mais barato.

Também é óbvio por que não faz sentido perguntar “Por que não abandona o Windows e instala Linux nele?”. Porque nenhuma distribuição Linux tem suporte à Caneta. A base de performance também tem uma tecla física que você precisa pressionar para que a dobradiça libere a tela.

Você vai querer ter Adobe Photoshop, Autodesk Sketchbook, Sketchable ou qualquer outro pacote de software excelente disponível. Não vou repetir cada review disponível mostrando quão boa é a caneta. Confirmo apenas que sim, a caneta é excelente, precisa, fiel, e flui de forma muito natural. É um estúdio inteiro numa caixa só.

Desenvolvedores de software deveriam evitar esse tipo de produto porque a maioria das distribuições Linux não terá os drivers adequados para tantas soluções de hardware exclusivas. Para essas situações, recomendo muito o Dell XPS 13, especificamente a configuração de USD 1.759 com Windows 10 Pro (ou economize USD 60 pegando a edição Home se pretende instalar Linux por cima), o ótimo display touch InfinityEdge QHD+ (3200x1800), Intel Core i7 8ª geração, 16 GB de RAM, SSD de 512 GB. É, de longe, o melhor custo-benefício para um desenvolvedor de software em tempo integral.

O OS X tem uma comunidade excelente apesar da Apple não fazer muito para ajudá-la. Historicamente, a transição do MacOS legado para o OS X significou ter um kernel e toolchain compatíveis com UNIX disponíveis. Até hoje, ainda não é comparável a uma distribuição Linux moderna. Mas o OS X compensa isso por ter, de longe, o melhor Compositor Gráfico do mercado. A GUI é fluida, responsiva.

O kernel Darwin Mach suporta múltiplas políticas, e a mais importante para Profissionais Criativos, especialmente músicos, era a capacidade de soft real-time do scheduler. Até hoje, o Linux Real Time não é a opção padrão, e não é tão bem ajustado nem estável. E o kernel do Windows evoluiu, mas ainda está longe de ser tão polido.

O Soft Real-Time evita o efeito de travamento que observamos. E é um dos fatores pelo qual a experiência Mac é, no geral, superior mesmo em hardware menos potente.

Em particular, todos na comunidade do Homebrew merecem muito elogio pelo esforço de continuar trazendo ferramentas open source para o OS X, apesar de cada nova atualização do Xcode e do OS X quebrar tudo.

Meu Ambiente

Magnesium Body

Depois de muita experimentação, decidi usar o Windows 10 nativo como host e uma distribuição Linux completa (Manjaro GNOME) em um ambiente Virtualbox, alocando 4 dos 8 cores (2 cores físicos, cada um com 2 hyperthreads) e metade da memória (8 GB).

Por que não usar o novíssimo Windows Subsystem for Linux (WSL)?

Porque embora seja promissor, ainda precisamos esperar que resolvam as arestas. Em particular, um suporte melhor a GUI e uma abstração de I/O mais rápida. O que dói mais é como a camada de sistema de arquivos é dolorosamente lenta agora. É uma ordem de magnitude mais lenta do que usar Linux no Virtualbox.

Poderia usar uma solução híbrida estilo Vagrant, com uma distribuição Linux headless no Virtualbox e acessando arquivos via CIFS/NFS. Funcionaria bem se você gosta de editores como Sublime Text 3, Visual Studio Code ou Atom. Mas sou do time Vim e gosto do GVIM, que funciona melhor dentro do GNOME, dentro de uma distribuição Linux com GUI de verdade.

“Por que não usar Docker? É super rápido e tal.”

Me surpreende quando as pessoas perguntam isso, porque demonstra como pouco entendem das ferramentas que recomendam.

Docker faz sentido de verdade em uma distribuição Linux nativa. No Windows, precisa rodar Linux no Virtualbox ou Hyper-V. No Mac, usa o framework Hypervisor, que — como o Hyper-V da Microsoft — é uma camada de virtualização. É basicamente o mesmo que Virtualbox, para todos os efeitos práticos.

Docker, como o LXC, apenas faz um processo “acreditar” que está rodando sozinho no SO ao ocultar os outros processos. Então, no Linux, é super rápido. Em qualquer outra plataforma, precisa virtualizar o Linux e então rodar o Docker lá dentro.

O cliente Docker está na verdade se comunicando com um Linux virtualizado no Windows ou Mac. Se você acreditou que é mais rápido que Virtualbox ou Hyper-V de forma significativa, foi enganado. Não há mágica aqui.

“Por que não dar dual-boot então?”

Isso também não resolve meu cenário. Quero um ambiente GNOME completo com GUI. E não quero manter Outlook no Windows e Thunderbird ou Evolution no Linux, gerenciando contas diferentes em todo tipo de aplicação (e sim, prefiro muito binários nativos a web apps, sou old-school assim). Não quero reiniciar quando quiser usar o Photoshop e reiniciar de volta para Linux para usar o Vim.

Quero ter software de ambas as plataformas disponível ao mesmo tempo. Não acredito em cenários de dual-boot a menos que os usos sejam completamente separados. Por exemplo, usar uma distribuição Linux o dia todo e à noite reiniciar no Windows para rodar o Steam e jogar.

Sim, o Virtualbox terá uma UI menos responsiva por causa do pipeline gráfico virtualizado. Mas para desenvolvimento de software, funciona perfeitamente. Até vejo pessoas fazendo coisas mirabolantes como ter um ambiente de desenvolvimento inteiro em uma instância EC2 da AWS e acessar via SSH com Vim e Tmux. Isso é bem mais complicado, na minha opinião. Não iria tão longe.

Todo o hardware top de linha que listei acima tem Cores e RAM suficientes para rodar 2 SOs ao mesmo tempo. Não faça isso em hardware básico.

E se não precisar de um notebook para carregar, com o mesmo dinheiro você compra um computador desktop muito superior.

“Mas no OS X você tem tudo nativo, porque é UNIX e tal”

Sim, mas desconfio muito das grandes atualizações do OS X da Apple. Elas sempre, sempre estragam alguma coisa. Depois de ter minha cota de dias de trabalho perdidos pós-atualizações, migrei meu ambiente de desenvolvimento para o Vagrant pelo menos 5 anos atrás. Então já estava usando Linux no Virtualbox (ou VMWare) o tempo todo. Nunca olhei para trás. Ficava lendo as reclamações das pessoas depois das grandes atualizações e eu estava lá, ileso e produtivo. O Virtualbox era muito pior naquela época, hoje não é tanto. Não me lembro da última vez que travou, se é que travou alguma vez.

“Mas por que não usar Hyper-V em vez do Virtualbox?”

Tentei. E não recomendo agora. Foi construído para que o Windows rode caixas Linux em servidores. Então é excelente para particionar recursos de hardware entre diferentes instâncias virtuais. A menos que você seja sysadmin em treinamento ou precise de um servidor simulado no seu notebook, não é para você.

Tem suporte muito ruim para gráficos (servidores headless não precisam de gráficos). A resolução máxima no monitor virtual é um ridículo 1152x864. Meu Virtualbox suporta meu monitor LG Ultrawide 2560x1080 tranquilamente. O Hyper-V não consegue e isso é um dealbreaker.

Virtualbox, VMWare, Parallels e Hyper-V vão todos usar as mesmas instruções VT-X fornecidas pela Intel. A performance base não vai ser tão diferente. As ferramentas de guest podem diferir. Alguma estabilidade pode diferir. Mas no geral, são basicamente a mesma coisa do ponto de vista da usabilidade.

Sei que parece “estranho” rodar o Windows 10 como host nativo principal. Mas funciona bem no geral.

E também sei que parece ainda mais estranho rodar uma distribuição Linux como SO convidado secundário no Virtualbox. Mas posso dizer que quando estou usando em tela cheia, trabalhando, não tenho a sensação de que está lento ou sem resposta.

O Software

Se você está no OS X, provavelmente está acostumado com muitas ferramentas. Pagou dinheiro por algumas delas. E trocar de SO sempre é uma dor.

Em resumo, o único software que realmente senti falta no começo foi o Keynote. Mas superei meu preconceito contra o PowerPoint e tenho que admitir que ele faz tudo que preciso agora.

Sempre odiei Pages e Numbers — são ótimos para amadores. Mas nada, nem o LibreOffice, muito menos o Google Docs, substitui o Office. O Google Slides é terrível e o Impress é além de inútil para mim (e é super lento). Sério, o PowerPoint hoje é uma ferramenta muito melhor.

O Office no Mac sempre foi “suficiente”, felizmente. Mas o Office no Windows é muito superior. Sem dúvida na minha mente. Então um grande benefício de voltar ao Windows 10 é ter a experiência completa do Office.

Se você usa as ferramentas da linha Pro, vai sentir falta do Final Cut Pro. Se é músico profissional, vai sentir falta do Logic Pro. Não há nada como o GarageBand para músicos hobbyistas. Não há nada a fazer aqui. E mesmo tendo hardware melhor no PC, a Apple customiza o Final Cut para render excepcionalmente melhor no AMD Radeon Pro. Então os tempos de exportação do Final Cut ainda são superiores aos do Adobe Premiere. O Motion 5 ainda é mais fácil e responsivo que o After Effects.

Dito isso, a margem não é enorme. A Adobe Creative Suite é muito forte, e a menos que você seja um one-trick pony, qualquer profissional consegue migrar para a Adobe e fazer o trabalho.

Em termos de desenvolvimento de software, a menos que você seja um one-trick pony do .NET, vai querer toda a parafernália open source. O WSL deveria fornecer isso — no futuro. Agora mesmo, sua melhor aposta é rodar o Virtualbox e você não vai se arrepender.

Sim, existem pequenos softwares exclusivos como 1Password, Tweetbot, Alfred. Não sinto falta de nenhum deles. Especialmente porque meu último iPhone foi o 4, lá em 2010. Depois migrei para Android com o Galaxy S4 e também nunca olhei para trás. Estou usando um S8 e prestes a receber meu Pixel 2, então estou bem em termos de cliente de Twitter ou gerenciamento de senhas (uso o LastPass e, embora não seja perfeito, resolve).

Ou existe um substituto nativo bom o suficiente para desktop ou mobile, ou existe um serviço Web. Posso me sentir desconfortável com a mudança, mas na prática não há nada no macOS que me impeça de trocar. Mesmo que você tenha comprado músicas ou filmes no iTunes, existe iTunes para Windows.

“Mas espera, o Windows Update vai te enlouquecer!”

Achei o mesmo. A Microsoft finalmente resolveu isso. Ainda existe, você ainda precisa reiniciar. Mas não é nem de longe tão irritante quanto era antes. A maioria das atualizações roda em segundo plano e você nem vai notar. E há várias opções como agendar para rodar apenas à noite quando você não está trabalhando.

“E os problemas de segurança e vírus!?”

Sim, recomendo fortemente não navegar na Deep Web numa máquina Windows, você vai ser comprometido. Nem com um browser Tor. Vai ser comprometido.

Também recomendo usar o BitLocker (disponível apenas no Windows 10 Pro) para criptografar sua partição. E fazer backup em HDs externos com a maior frequência possível. Nada te protege melhor do que um backup frio prontamente disponível.

E sim, instale alguma solução de terceiros como o Avast antivírus. Tenha comportamento saudável de navegação e evite sites duvidosos. Você sabe do que estou falando. Vai ser comprometido.

Se necessário, instale uma distribuição Linux segura dentro do Virtualbox e abra o Tor de lá.

“E a bagunça que é o Registro!?”

Ainda existe. Se você nunca experimentou, o Registro é o equivalente Windows do “/etc” nas distribuições Linux. É um banco de dados binário. Fica corrompido. Fica com entradas sujas.

Mas minha recomendação é: esqueça-o. Se você ficar pensando e mexendo nele, vai corromper o sistema. Não tente limpá-lo (nunca, jamais use algo como o CCleaner).

O próprio Windows agora tem snapshots automáticos de restauração do sistema toda vez que algo importante acontece. E é bastante confiável. Chegam ao ponto de duplicar o diretório atual “C:\Windows” em um “C:\Windows.old” quando há uma grande atualização do Windows, só por precaução. Se atiraram no próprio pé tantas vezes que finalmente aprenderam a ter várias camadas de opções de recuperação.

Hoje você pode até baixar a ferramenta de Criação de Mídia diretamente do site da Windows. Não precisa nem se cadastrar em lugar nenhum. E a licença do Windows vem no firmware (BIOS) da máquina. Não precisa nem lembrar onde está sua chave de ativação do produto. Ativa automaticamente e como cada máquina já vem com uma licença, o processo é transparente. E a maioria dos fabricantes tem atualizações automáticas para drivers e firmware.

Então você deve ter uma experiência razoavelmente tranquila, aconteça o que acontecer.

“Mas o Windows não é open source!”

O OS X também não. E essa é uma vantagem do Linux. Então, se for obrigatório, use apenas Linux nativamente. O ponto da discussão é encontrar uma alternativa ao Mac. Então estamos alinhados.

O Efeito Ruby on Rails e os Hipsters

Sendo honesto: no mundo do desenvolvimento de software, migramos para o Mac principalmente por causa do Rails e do Textmate 2. Tínhamos acesso a algumas ferramentas open source embutidas, tínhamos GCC para compilar o resto. O Windows XP estava bem além da validade. O Windows Vista foi uma experiência horrível. Os fabricantes de hardware para PC nem estavam tentando, e a Apple lançava hardware bom e boa experiência o tempo todo.

Os desenvolvedores migraram em massa após a transição de PowerPC para Intel em 2005. Meu primeiro Mac foi um Mac Mini G4 com OS X 10.4 Tiger. Depois comprei o primeiro MacBook branco Intel e nunca olhei para trás.

As ferramentas de software no Windows eram risíveis. O Visual Studio .NET era terrível. IDEs baseadas em Eclipse eram terríveis. Não tínhamos PowerShell ainda. E definitivamente nunca tivemos nada como o WSL para linha de comando. Você podia instalar o Cygwin, mas era uma experiência sofrível.

E rodar Linux como SO principal também era terrível. O Wine ainda é terrível, apesar de seus melhores esforços. Infelizmente, as GPUs da NVIDIA e AMD só rodam no melhor de sua capacidade no Windows. E Linux nunca foi realmente bom para criação de conteúdo. Não é nem questão de aprender um novo fluxo de trabalho — as ferramentas são medíocres. Precisam fazer engenharia reversa de tudo, e isso leva tempo. E na velocidade das redes sociais, não temos tempo suficiente, então precisamos aceitar compromissos.

O ecossistema Windows parou de fingir e finalmente abraçou tudo que o ecossistema open source e da Apple construiu. Agora todos nos beneficiamos.

A propósito, se você gosta do iTerm 2, vai adorar instalar o Tilix para Linux, que é muito similar.

Com o Passar do Tempo

Acompanho a evolução da linha Surface ao longo dos anos. No começo, era muito cético. É muito fácil lançar um produto gimmick e descontinuá-lo. Confio em empresas que continuam evoluindo seus produtos ao longo dos anos. Não só um ecossistema se forma em torno deles, como você tem tempo para montar serviços de suporte, peças disponíveis nas lojas oficiais e no mercado secundário. Depois de todos esses anos, a Microsoft merece ser chamada de fabricante de hardware.

É a Microsoft finalmente cumprindo o que Alan Kay disse uma vez:

“Pessoas que são realmente sérias sobre software deveriam fazer seu próprio hardware.”

Só falharam de verdade no mercado de smartphones, onde a competição é muito mais difícil e as margens são super baixas por causa disso. Mas acertaram no mercado de tablets, no desktop, no notebook, nos games, nos servidores (com seus próprios serviços Azure). Então agora acredito que eles realmente entendem as necessidades específicas de todas essas áreas, e isso aparece no software. Têm um entendimento muito superior de cada mercado — exceto smartphones — em relação à Apple. Finalmente têm skin no jogo de verdade.

Porque agora a Microsoft fabrica seu próprio hardware e fez um negócio disso, há um incentivo real dentro das equipes da empresa para um ciclo de feedback positivo que resulta em mais refinamentos no código do Windows.

Ficaram tentando e falhando em soluções touch desde o início dos anos 2000. Agora a Caneta não é mais um gimmick, é um produto real, com qualidades reais e casos de uso reais.

Também mantiveram sua visão de se dar bem com o Open Source. Ninguém pode razoavelmente esperar que a Microsoft vire totalmente open source. Mas aparece. São os segundos apenas para o Google no GitHub em termos de contribuições open source. Adquiriram a Xamarin e sua estratégia de .NET Core está em andamento e forte. O próprio Visual Studio recebeu tratamento open source. Ainda há um longo caminho, mas é preciso reconhecer os passos gigantescos.

O que é muito mais do que podemos dizer sobre a Apple, onde os coitados do Homebrew sofrem a cada atualização do OS X.

A tentativa do Surface RT e do Windows Mobile até possibilitou que o Windows fosse finalmente compilado para rodar em processadores ARM. É um bom sinal para o futuro. Me lembra quando o OS X foi compilado pela primeira vez para rodar em processadores Intel (antes rodava em PowerPC) em 2005.

E o MacBook? Ganhou uma touch bar gimmick. A Apple está realmente desconectada da realidade.

Por Que Saí do Ecossistema Apple?

O foco da Apple não é no Mac. Pior: o Mac está rapidamente se tornando abandonware, apesar dos comunicados de relações públicas.

São claramente uma empresa de iPhone, com um negócio paralelo hobbyista que fabrica Macs e MacBooks, que existem principalmente para servir como toolchain de desenvolvimento de apps para iPhone. Esse é o modelo de negócios.

Você viu o último anúncio deles para o iPad?

Sim, é super fofo e eu curto.

Mas a mensagem é cristalina: a visão é para as pessoas usarem apenas iPhones e iPads. Não existe tal coisa como um “computador”.

São a empresa de tecnologia mais valiosa no momento. Mas desde o ano passado, não têm mais nem uma equipe dedicada ao OS X. O que isso diz?

A linha iOS é um “monopólio” dentro da linha Apple. O Mac não consegue competir. O próprio Steve Jobs alertou sobre o que acontece com os monopólios.

Estamos começando a ouvir a mesma história por toda a indústria:

A Microsoft jogou bem suas cartas. Levou quase 15 anos. Mas valeu muito a pena. A Apple realmente alienou os leais, os que costumavam “Think Different”.

A Apple é “vítima” do “Dilema do Inovador” de Clayton Christensen. Se ainda tivessem visão, poderiam se estender e manter. Mas ao invés disso, escolheram apostar tudo em uma única linha de produtos.

A Microsoft parece ter lido a “Solução do Inovador: Criando e Sustentando o Crescimento de Sucesso” de Clayton.

Quando o iPod estava no auge, a Microsoft havia “perdido”. Estavam fora do jogo. Era deprimente de ver. Steve Ballmer foi um CEO vergonhoso. O Windows Vista foi um SO vergonhoso. O Zune falhou em capturar a aura do iPod. O Windows Mobile era uma bagunça. E o Sharepoint… ah, o Sharepoint. Chegaram a comemorar quando o jQuery foi adicionado ao ASP.NET! Falar em tarde demais.

E a Amazon — uma loja de varejo — lançou com sucesso a melhor infraestrutura do mundo e se tornou sinônimo de “Nuvem”, enquanto a Microsoft ainda estava tentando entender o que era Linux.

Falha após falha, em vez de defender sua posição baixa, finalmente decidiram se erguer e seguir em frente um passo de cada vez. Refinar. Evoluir. Sustentar.

Agora, o Windows 10 recapturou a aura do XP no seu melhor. Está fazendo atualizações incrementais e sólidas. Primeiro a Anniversary Edition, depois a Creators Update e finalmente a mais recente Fall Creators Update. Todas atualizações sólidas.

A linha Surface está indo forte como a melhor referência de design industrial e funcionalidades em desktops, notebooks e acessórios. Sério, a Apple ainda vende aquele terrível Magic Mouse 2 escorregadio e difícil de segurar, mas a “mágica” é que alguém de fato compra. A Microsoft tem o Arc Touch e o Precision Mouse, dois dos melhores já fabricados.

Profissionais criativos, desenvolvedores de software — todos migramos em massa para o OS X quando era a “Coisa Diferente” da campanha “Think Different”. Ajudamos a evangelizar. Ajudamos a construir ferramentas. Ajudamos a construir serviços. Escrevemos toneladas de posts e documentação para ajudar.

Steve Jobs morreu e a Apple morreu com ele. Basicamente não fizeram nada novo desde então, e seus produtos antes bem-sucedidos foram deixados para decair e morrer. O que resta é o efeito halo, a inércia, e o crescente apetite por ordenhar a mesma vaca indefinidamente, abandonando todo o P&D.

A Apple Não Liga. Por Que Eu Deveria?

A Microsoft jogou com inteligência, continuou corrigindo e evoluindo, ano após ano. Perdeu a geração dos anos 90. Recuperou a geração dos anos 2010. E começaram cedo, atraindo atenção pelo Xbox até chegar ao Windows.

Sério, o Dashboard do XBox é melhor do que o do PS4. Prefiro muito mais.

E agora estão em boa posição. Os jogadores estão invertidos. O “Think Different” agora se refere ao Windows 10 e ao hardware PC. A Intel está conservadora. A NVIDIA fabrica as melhores GPUs. Há muitas ótimas opções que não estão disponíveis no Mac.

A transição de 32 para 64 bits e as necessidades do XBox até ajudaram a Microsoft a repensar como isolar e empacotar seu software. Mesmo que a Windows Store ainda seja uma piada de mau gosto neste ponto.

E Bill Gates estava absolutamente certo em meados dos anos 90: o browser tornaria o monopólio do Windows obsoleto. E tornou. Do lado bom, você tem os mesmos Chrome e Firefox disponíveis no OS X, Windows 10 e qualquer distribuição Linux. Isso significa acesso imediato a tudo que a maioria das pessoas precisa: Gmail, Google Docs, Office 365, Dropbox, LastPass, Spotify, Slack, Discord, Twitter, Netflix, HBO, Hulu, etc.

Odeio wrappers de desktop baseados em Javascript como a praga. O Electron é pesado demais. Mas o que posso fazer? Pelo menos hardware poderoso e RAM estão baratos hoje em dia, e podemos nos dar ao luxo de abas de browser que consomem 100 MB cada.

O browser é o novo SO para a maioria das pessoas. Muita gente se vira com Chromebooks! Todo o resto está nos celulares, não no desktop. Então ferramentas pesadas são necessárias. Ferramentas leves você já carrega no bolso.

O ecossistema Apple ainda não está morto. A Apple ainda tem tempo de corrigir a situação. Tenho esperado pelos últimos 3 anos, mas ainda zero sinais de melhora. Meu primeiro artigo sobre a troca foi publicado em 10 de novembro de 2015.

Diferente de outros artigos sobre troca de plataforma, não estou dizendo isso de forma leviana. Já fiz a troca, nos últimos 2 anos.

Como digo em muitos dos meus posts e palestras: não sou definido pelas minhas ferramentas. Não carrego bandeiras. Não sou leal a ninguém por padrão. Nunca fui pago pela Apple para defendê-la. E não sou pago pela Microsoft para dizer coisas boas sobre ela. Apenas analiso os fatos e aponto o melhor caminho a seguir.

E os fatos me dizem que o macOS chegou ao fim. Foi uma boa viagem. Adeus ao Mac e obrigado pelos peixes.

]]>applemicrosofthardwareDo MacBook Pro para o Dell XPS: Arch Linux para Usuários Criativoshttps://akitaonrails.github.io/2017/01/31/do-macbook-pro-para-o-dell-xps-arch-linux-para-usuarios-criativos/https://akitaonrails.github.io/2017/01/31/do-macbook-pro-para-o-dell-xps-arch-linux-para-usuarios-criativos/Tue, 31 Jan 2017 18:26:00 -0200<p>Como venho relatando em posts anteriores, estou migrando para Linux em tempo integral. Aqui quero mostrar como configurar o Arch Linux para deixá-lo adequado a Usuários Criativos <strong>Pro</strong>, onde o acesso à GPU secundária é fundamental.</p> <p>Se você é um Usuário Criativo Pro, não dá para rodar Final Cut Pro X (com Motion e Compressor), Logic Pro, Photoshop da Adobe e afins. Então você vai precisar mudar seu fluxo de trabalho se quiser entrar no ecossistema Linux. Felizmente, para muitos fluxos os aplicativos Linux amadureceram bem e dá para trabalhar sem precisar se contentar com software de baixa qualidade ou gambiarra.</p>Como venho relatando em posts anteriores, estou migrando para Linux em tempo integral. Aqui quero mostrar como configurar o Arch Linux para deixá-lo adequado a Usuários Criativos Pro, onde o acesso à GPU secundária é fundamental.

Se você é um Usuário Criativo Pro, não dá para rodar Final Cut Pro X (com Motion e Compressor), Logic Pro, Photoshop da Adobe e afins. Então você vai precisar mudar seu fluxo de trabalho se quiser entrar no ecossistema Linux. Felizmente, para muitos fluxos os aplicativos Linux amadureceram bem e dá para trabalhar sem precisar se contentar com software de baixa qualidade ou gambiarra.

Desenvolvedores de software raramente precisam de mais do que a placa Intel integrada barata, a menos que queiram instalar o Steam via Wine para jogar títulos pesados.

Depois de muita pesquisa (leia-se: YouTube!) fui com o Dell XPS 15" (modelo 9550). É uma máquina com quase um ano de vida, arquitetura SkyLake, usando o NVIDIA Optimus Híbrido Intel + GTX960M.

Dell XPS 15" 9550

Até hoje nada supera a coesão entre software e hardware da Apple. Isso não pode ser subestimado. O mundo PC/Windows melhorou bastante, mas ainda é assombrado por BIOS instável, drivers instáveis etc. No Linux, é ainda pior.

Aqui vai o primeiro protip: evite modelos super novos. A maioria não tem drivers estáveis nem para Windows 10, quanto mais para Linux. Deixe o pessoal do Windows sofrer os primeiros meses e dê tempo à Dell, à NVIDIA e à Intel para corrigir o caos com firmware de BIOS e drivers mais estáveis.

Se você realmente quiser comprar um dos modelos Kaby Lake de 2017 que acabaram de sair, está numa roleta russa. Até os primeiros MacBooks costumam dar problema. Regra geral: não compre no dia do lançamento, espere pelo menos 3 meses. Você foi avisado.

Dentre as máquinas de início de 2016 que a maioria das distros Linux suporta razoavelmente bem, as séries Dell XPS, Lenovo Thinkpad X1 Yoga e possivelmente Asus Zenbook Pro e HP ProBook estão bem.

Mas na maioria das categorias, a série XPS leva vantagem. A Dell fez um trabalho muito bom dessa vez.

O teclado, como na maioria dos PCs, é mediano: plástico, um pouco bamboleante, com curso aceitável mas clique duro e sem resistência suficiente. Para 99% das pessoas é bom o suficiente, mas não é o ideal para quem digita muito rápido.

O touchpad é um dos melhores em qualquer notebook PC, mas vale lembrar que a maioria dos touchpads de PC é vergonhosamente ruim, especialmente com gestos mais complexos do que rolar com dois dedos. Essa continua sendo uma área em que o Mac é imbatível. Dito isso, o da Dell é funcional e deve dar conta do recado, embora a rejeição de palma falhe aqui e ali para te irritar de vez em quando.

O monitor é outra história: o deslumbrante display 4K IPS do XPS 15 é excelente, superando de longe os Retina Displays do MacBook. O SSD Samsung PCIe NVMe M.2 também é o melhor da categoria. A carcaça de alumínio é simples mas bem usinada, e o acabamento em fibra de carbono é um bônus bem-vindo que faz da máquina algo que você genuinamente aprecia carregar.

Dell XPS Display

Se você não quer mexer muito na configuração de hardware, a aposta mais segura costuma ser o Ubuntu, e mesmo assim não vai ser perfeito.

Especialmente com displays HiDPI (acima de Full-HD), o Linux ainda está atrás. GNOME e KDE até suportam, mas outros ambientes desktop têm resultados mistos, e aplicativos mais antigos ainda não se adaptaram direito. Em distros LTS com pacotes velhos, você vai encontrar aplicativos com HiDPI errado, como o Libreoffice e o Spotify.

E se você for como eu, usando múltiplos monitores com DPIs diferentes, pode esquecer. Ou usa o notebook com a tampa fechada, aí só tem um monitor externo para se preocupar, ou o texto fica minúsculo no monitor HiDPI principal para o DPI ficar certo no segundo monitor externo.

Uma saída é configurar o display 4K para escalar para Full-HD (1080p). Mas aí fica a pergunta: qual é o sentido de ter um display 4K se você não consegue usá-lo direito? Então não compre o 4K sem entender isso.

MacOS e Windows lidam com essa situação muito melhor. No MacOS nunca tive nenhum problema de HiDPI. Nenhum. A Apple foi muito mais eficaz em empurrar um padrão mais alto do que o resto da indústria, e essa coesão, sem precisar fuçar drivers e configurações, tem um valor enorme.

Com Mac, você liga e usa. Com Windows, provavelmente vai ficar bem, a menos que apareça algum problema de driver. Com Linux, espere um volume razoável de ajustes para colocar o básico em ordem.

Notebooks PC novos também estão vindo com configurações esquisitas que fazem sentido no Windows, mas que dão trabalho para as distros Linux. Toda vez você começa desativando coisas no BIOS como Secure Boot, mudando para AHCI, etc. Então vamos direto ao ponto.

Configuração do BIOS

A primeira coisa a fazer é alterar as configurações do BIOS. Pressione F2 na tela do logo Dell para entrar no setup e faça as seguintes mudanças:

  • General - Advanced Boot Options - Enable Legacy Option ROMs
  • General - Boot Sequence - Legacy (o padrão é UEFI)
  • System Configuration - SATA Operation - AHCI (o padrão é RAID On)
  • System Configuration - Touchscreen (desabilite, pois é praticamente desnecessário e consome mais bateria)
  • Security - Secure Boot - Secure Boot Enable - Disabled
  • POST Behavior - Fastboot - Through (o padrão é minimal)

Ao fazer essas mudanças, o Windows 10 pré-instalado não vai mais iniciar, então certifique-se de que não precisa dele antes de prosseguir.

Ajustes no Kernel

Siga a página do Wiki do Dell XPS (9550).

O display 4K pode apresentar flickering, e para evitar isso edite o arquivo de configuração do Grub /boot/grub/grub.cfg e adicione os seguintes flags à linha existente:

GRUB_CMDLINE_LINUX_DEFAULT="... i915.edp_vswing=2 i915.preliminary_hw_support=1 intel_idle.max_cstate=1 acpi_backlight=vendor acpi_osi=Linux"

Essa linha já existe com alguns flags. Não apague, apenas adicione os novos, e não se esqueça de rodar em seguida:

sudo grub-mkconfig -o /boot/grub/grub.cfg

No mais, tudo deve funcionar bem, mas por precaução instalei também os pacotes Powertop e acpid:

sudo pacman -S powertop acpid

Fico feliz em reportar que consigo fechar a tampa do notebook e o sistema suspende corretamente. Ao abrir, ele volta do sleep sem problemas, economizando bateria e me poupando de reiniciar todo dia.

Distros Arch: Manjaro ao resgate

Estou me tornando um entusiasta do Arch, mas configurá-lo para funcionar num notebook moderno dá um trabalho absurdo. Não recomendo tentar se você estiver com pressa. Testei o Arch Anywhere, mas ele nem consegue passar pelo particionamento do disco (não gosta da configuração de SSD ou SATA). Testei o Antergos, mas por algum motivo as Contas Online do Gnome não funcionaram lá, mesmo reinstalando. No final fui com o Manjaro, que instalou e funcionou sem grandes problemas.

Existem várias distros baseadas em Arch. Arch Anywhere e Antergos são mais “instaladores” do Arch: os repositórios principais ainda são o Arch vanilla, e eles tentam tornar o processo de instalação mais fácil do que você ter de se virar num shell de linha de comando cru.

O Manjaro é mais uma distro independente. As fontes principais apontam para o Manjaro primeiro, então eles testam os pacotes mais recentes e os seguram por um tempo antes de liberar, evitando que pacotes problemáticos quebrem seu sistema com frequência. Mas você ainda tem acesso direto aos pacotes AUR. O grande diferencial é um instalador muito melhor, com particionamento automático mais sofisticado do que o Arch Anywhere, e o próprio software de detecção de hardware MHWD.

No geral funcionou bem, embora eu ainda tenha precisado ajustar a configuração gráfica, pois por padrão ele opta pelos drivers open source Nouveau. Confie em mim: vá para os binários proprietários.

Se você também é desenvolvedor de software, vai querer ler meu post anterior sobre Arch.

Gráficos Híbridos Optimus

O Dell XPS modelo 9550 usa a arquitetura Híbrida Optimus. Os drivers Prime são para GPUs NVIDIA standalone. A maioria dos notebooks funciona com a placa Intel integrada como única e principal (especialmente ultrabooks leves), e os modelos mais “Pro” conectam isso a uma NVIDIA GTX 960M secundária.

Se você tem apenas uma placa Intel simples, a maioria das distros vai fazer a coisa certa automaticamente e instalar os drivers e configurações corretas.

Agora, se você tem uma máquina de alta performance como este XPS 9550 ou 9560 (Kaby Lake), vai precisar de mais configuração. Primeiro, entenda a terminologia:

  • Você precisa instalar o Bumblebee. É um daemon que habilita o acesso à GPU secundária. Só instalar o Bumblebee já resolve a maioria dos problemas.
  • Depois instale o Primusrun, que é um back-end para o Bumblebee usado para rodar programas como o Steam de forma que tenham acesso à GPU secundária.
  • Às vezes você vai ver referências ao Optirun, que hoje em dia parece usar o Primusrun por padrão (caso contrário, usava um framebuffer X secundário, adicionando overhead extra).

Com tudo instalado, geralmente basta fazer:

primusrun kdenlive

Por exemplo, para carregar o editor de vídeo Kdenlive usando OpenGL pela GPU Nvidia. Ou para rodar o Steam via Wine:

primusrun wine ~/.wine/drive_c/Program\ Files\ (x86)/Steam/Steam.exe

Como mencionei, o Manjaro provavelmente vai instalar o driver Nouveau, que é open source. Você deve instalar os binários proprietários assim:

sudo mhwd -a pci nonfree 0300
sudo mhwd -r pci video-hybrid-intel-nouveau-bumblebee
sudo mhwd -i pci video-hybrid-intel-nvidia-bumblebee

Lembrando que estou falando do XPS 9550 com configuração Optimus Intel-Nvidia. Leia a página Configuring Graphics do Manjaro sobre o assunto.

Aqui me deparei com um problema estranho. Estou usando o kernel Linux 4.9:

$ uname -a
Linux arch42 4.9.6-1-MANJARO #1 SMP PREEMPT Thu Jan 26 12:29:20 UTC 2017 x86_64 GNU/Linux

Teoricamente o pacote core/linux49 4.9.6-1. Mas por algum motivo o comando mhwd -i estava instalando os drivers linux44-nvidia.

Os módulos da GPU Nvidia nunca eram carregados até eu removê-los manualmente:

sudo pacman -R linux44-nvidia

E então instalar a versão correta manualmente:

sudo pacman -S linux49-nvidia

Por precaução, desinstalei o pacote linux44 e todos os outros pacotes linux44-*:

sudo pacman -Ss linux44 | grep installed
# sudo pacman -R linux44-(nome do pacote)

Agora tenho isso:

$ sudo pacman -Ss linux4 | grep installed
core/linux49 4.9.6-1 [installed]
extra/linux49-bbswitch 0.8-6 (linux49-extramodules) [installed]
extra/linux49-ndiswrapper 1.61-4 (linux49-extramodules) [installed]
extra/linux49-nvidia 1:375.26-6 (linux49-extramodules) [installed]

No /etc/bumblebee/bumblebee.conf confirmo que está carregando explicitamente o driver nvidia correto (o linux49-nvidia mencionado acima). Caso contrário, você precisa editar com sudo vim:

$ cat /etc/bumblebee/bumblebee.conf | grep Driver
# The Driver used by Bumblebee server. If this value is not set (or empty),
Driver=nvidia

Ao final, se você abrir o Manjaro Settings Manager, deve ver algo assim:

Settings Manager

Edição 3D e Vídeo Profissional

Para testar esse setup, comecei instalando o Blender (uma das melhores ferramentas de edição 3D da indústria). Baixei um modelo 3D e animação gratuitos e tentei renderizar cycles via GPU Compute. Por segurança, instalei também o pacote Cuda:

sudo pacman -S blender cuda

Com os drivers corretos instalados, o Blender deve detectá-los e habilitar o uso dos cores CUDA:

CUDA GPU Compute

Você pode monitorar a placa Nvidia com o comando nvidia-smi, que mostra algo assim:

nvidia-smi monitoring

Isso cobre a modelagem 3D profissional se você precisar.

Blender

Possivelmente o melhor editor de vídeo disponível para Linux é o Kdenlive. É o mais próximo que você vai encontrar do Adobe Premiere ou do Apple Final Cut Pro.

A instalação é assim:

sudo pacman -S kdenlive ladspa movit sox ffmpeg frei0r-plugins breeze-icons

E para previews em tempo real mais rápidos, ele pode ser iniciado via Primusrun num terminal assim:

$ primusrun kdenlive
OpenGL vendor:  "NVIDIA Corporation"
OpenGL renderer:  "GeForce GTX 960M/PCIe/SSE2"
OpenGL Threaded:  true
OpenGL ARG_SYNC:  true
OpenGL OpenGLES:  false
OpenGL vendor:  "NVIDIA Corporation"
OpenGL renderer:  "GeForce GTX 960M/PCIe/SSE2"
OpenGL Threaded:  true
OpenGL ARG_SYNC:  true
OpenGL OpenGLES:  false

Se eu iniciar sem o Primusrun, ele detecta primeiro a placa Intel:

$ kdenlive
OpenGL vendor:  "Intel Open Source Technology Center"
OpenGL renderer:  "Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) "
OpenGL Threaded:  false
OpenGL ARG_SYNC:  true
OpenGL OpenGLES:  false
OpenGL vendor:  "Intel Open Source Technology Center"
OpenGL renderer:  "Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) "
OpenGL Threaded:  false
OpenGL ARG_SYNC:  true
OpenGL OpenGLES:  false

Não tenho certeza absoluta, mas acredito que o Kdenlive usa OpenGL para mostrar previews em tempo real dos efeitos aplicados às faixas de vídeo, e isso provavelmente pode ser redirecionado via primus para a placa Nvidia secundária.

Na verdade, o Kdenlive, assim como seu concorrente OpenShot, usa o MLT Multimedia Framework, o motor de edição de vídeo não-linear. Por sua vez, o MLT usa o movit, que são filtros de vídeo de alta performance e qualidade para a GPU. O comando de instalação via pacman que mencionei já cuida de instalar esses pacotes opcionais.

Kdenlive

E se você quiser aproveitar a GPU Nvidia até no GIMP, existe um esforço em andamento para portar filtros para usar GEGL/OpenCL. Você pode habilitar o GEGL iniciando o Gimp pelo terminal assim:

GEGL_USE_OPENCL=yes gimp

Depois, você pode usar os plugins portados pelo menu Tools - GEGL Operation:

GEGL Operation

E se você é fotógrafo profissional, vai querer instalar o Darktable, que é o mais próximo que você vai chegar do Apple Aperture ou Adobe Lightroom. Tem uma aparência bem cuidada e você consegue retocar suas fotos adequadamente.

O Darktable detecta automaticamente o driver Nvidia. Não precisa rodar via Primusrun nem passar nenhuma flag especial.

Darktable

Considerações Finais

Você pode verificar se o aplicativo está usando a GPU monitorando com nvidia-smi:

watch -n 0.5 nvidia-smi

Isso mantém o monitoramento da GPU a cada meio segundo. O aplicativo aparece na lista de processos com um PID e você consegue ver o uso de memória (minha GPU tem 2GB de DRAM dedicada), o uso de processamento e a temperatura, que pode chegar perto de 70 graus Celsius renderizando pelo Blender.

Acredito que isso é o máximo que dá para extrair do hardware com aplicativos multimídia de nível profissional. Não sou profissional de Blender, Kdenlive, Darktable ou Gimp, mas é bom saber que posso usá-los para minhas necessidades pontuais. Usuários Pro vão conseguir aproveitar ainda mais essa máquina com essa configuração.

Como disse no começo: se você é realmente um Usuário Pro, sempre em movimento e precisa fazer mudanças rápidas nos seus projetos multimídia on-the-go, provavelmente vai continuar melhor com o stack da Apple, um MacBook Pro com Final Cut Pro. Não esqueça que o Final Cut Pro e os outros softwares Pro da Apple são super otimizados para o hardware Mac, exportando vídeos em velocidades ordens de magnitude maiores do que o Premiere, por exemplo.

Mas você pode ser um Usuário Criativo Pro na indústria de games, desenvolvimento mobile, animação 3D, pós-produção, ou trabalhando num time misto com engenheiros de software. E ter a capacidade de construir seus assets multimídia numa plataforma Linux pode abrir possibilidades interessantes para fluxos de trabalho integrados no futuro.

Mesmo que você seja do mundo Mac ou PC, provavelmente vai querer usar software como o Blender, que é um competidor respeitável ou até complemento de ferramentas premiadas como o Maya.

Então, mesmo que você tenha que enfrentar algumas arestas na instalação e configuração inicial, uma vez feito isso funciona bem.

]]>linuxapplehardwareOff-Topic: Por que Estamos Todos Migrando para Longe da Apple?https://akitaonrails.github.io/2017/01/12/off-topic-por-que-estamos-todos-migrando-para-longe-da-apple/https://akitaonrails.github.io/2017/01/12/off-topic-por-que-estamos-todos-migrando-para-longe-da-apple/Thu, 12 Jan 2017 11:37:00 -0200<p>&ldquo;Todo mundo que é alguém acompanhou a Apple nas últimas décadas. Ame ou odeie, a única coisa que você não pode fazer é ignorá-la.&rdquo; - esse sempre foi o consenso geral.</p> <p>Os profissionais &ldquo;criativos&rdquo; (como se &ldquo;criativo&rdquo; fosse restrito a pintores e ilustradores) sempre foram os seguidores mais fiéis da Apple, e com razão. A plataforma foi o berço de ferramentas essenciais como Photoshop, QuarkXPress, PostScript, PDF e QuickTime. A Apple estabeleceu os padrões da criação de mídia, e qualquer um que era alguém usava essas ferramentas.</p>“Todo mundo que é alguém acompanhou a Apple nas últimas décadas. Ame ou odeie, a única coisa que você não pode fazer é ignorá-la.” - esse sempre foi o consenso geral.

Os profissionais “criativos” (como se “criativo” fosse restrito a pintores e ilustradores) sempre foram os seguidores mais fiéis da Apple, e com razão. A plataforma foi o berço de ferramentas essenciais como Photoshop, QuarkXPress, PostScript, PDF e QuickTime. A Apple estabeleceu os padrões da criação de mídia, e qualquer um que era alguém usava essas ferramentas.

A Microsoft focava no mercado corporativo, não nos criativos. O Linux ainda engatinhava, e a maioria dos desenvolvedores nem sabia a diferença entre CMYK e RGB. Ficavam satisfeitos em ter um bitmap tosco na tela.

Old Macintosh

Tenho uma teoria: achamos que dominávamos a tecnologia no final dos anos 90, que estávamos no topo do mundo. Essa euforia era fruto da Bolha da Internet, que estourou junto com o 11 de setembro. A depressão que se seguiu desperdiçou os próximos 3 a 4 anos enquanto todo mundo tentava descobrir o que fazer a seguir.

Dotcom burst

A Apple teve a sorte de escapar da explosão. Ela já estava no fundo do poço desde 1997. A reorganização do portfólio de hardware e o lançamento do iPod criaram uma bolhinha própria. Steve Jobs havia voltado e trouxe bons desenvolvedores que fizeram do OS X um prazer de usar, não só para criativos, mas também para desenvolvedores.

O processo antitruste contra a Microsoft em 2000, o estouro da Bolha da Internet em 2001, o lançamento do iPod em 2001, a transição do System 9 para o OS X/BSD em 1999, a troca do PowerPC para Intel em 2005, o lançamento do desejadíssimo Titanium PowerBook G4 em 2001. Tudo isso junto deu à Apple uma vantagem enorme. E enquanto todo mundo estava em baixa, a Apple parecia maior do que realmente era.

Microsoft Antitrust

Aí vieram 2007 e 2008 com um novo impulso: o iPhone, a App Store e a necessidade de usar o Xcode, disponível apenas em computadores Apple. Diferente de ficar preso ao Windows por causa do Visual Studio, usar o Xcode era um motivo a mais para comprar um Mac.

iPhone announcement

As distros Linux ainda sofriam. Até então, estávamos presos ao maldito X11. Se o núcleo de um sistema Linux era moderno, o X11 em cima era o pior dos mundos. A Apple foi esperta o suficiente para não adotá-lo e criou o Quartz do zero, melhorando-o a cada nova versão do OS X. Levou cinco anos para estabilizar direito. Só agora, em 2017, estamos finalmente saindo do X para o Wayland/Weston.

Steve Ballmer

A Microsoft também sofreu depois que Bill Gates passou as rédeas para Steve Ballmer. A trajetória do XP até o Windows 10 passou pelos desastres do Vista, do Windows 8 e do Windows Mobile, além das inúmeras tentativas de ressuscitar o Internet Explorer, o maior Walking Dead da história da tecnologia. A era Ballmer foi um desastre.

Aí veio o iPad. E Steve Jobs morreu.

Jobs Dies

A Apple está presa em 2010.

E nós também.

As grandes distros Linux, a Microsoft, os fabricantes de hardware para PC, as viradas de grandes empresas (Nokia, Blackberry, Motorola), o começo da era das GPUs, o fim das guerras de clock da Lei de Moore em direção à computação paralela, a ascensão do ARM. Levou dez anos para a poeira baixar, e foi preciso a Apple ficar parada por seis anos para que todos os outros conseguissem alcançá-la.

Ballmer passou o bastão para Satya Nadella. A Microsoft adquiriu a Xamarin, deu passos enormes em direção ao open source e até o Ubuntu passou a rodar nativamente no Windows 10.

Satya Nadella

E os asiáticos. Samsung, LG, Huawei, sul-coreanos e chineses forçaram os norte-americanos a se mexerem mais.

Um último legado da era Steve Jobs foi matar o Adobe Flash (finalmente!) e impulsionar as tecnologias HTML 5, comprimindo dez anos de evolução em cinco. Foi por causa do iPhone que a Web é o que é hoje.

HTML 5 kills Flash

O Google entrou em campo e assumiu o espaço deixado pelo Internet Explorer. O WebKit se tornou a referência obrigatória de navegadores. O JavaScript se transformou na nova plataforma de aplicações, impulsionado pelas redes sociais em constante evolução.

Para o bem ou para o mal, as redes sociais forçaram o surgimento de uma nova geração de aplicações web complexas e interativas. O Gmail e a Web 2.0 serviram de exemplo, e com o novo ambiente mobile, tudo convergiu para aplicações multiplataforma e ubíquas.

Hoje é mais fácil do que nunca trocar de sistema operacional no desktop, porque já treinamos o hábito de pular entre desktop e dispositivos móveis.

All devices

Por que ficou fácil migrar entre macOS, Windows ou distros Linux? Ou entre macOS e iOS, ou entre Linux e Android? Porque a maior parte do software está “na nuvem”. O Linux domina o mundo da nuvem que a Amazon estreou em 2006 com S3 e EC2, seguida de perto pelo Google Cloud, Microsoft Azure e outros competidores menores.

Porque em qualquer plataforma existe pelo menos um bom Chrome.

Porque os apps que usamos são majoritariamente web: Gmail, Spotify, Slack, Hangout, Twitter, Facebook, YouTube, Netflix, Amazon. E a outra metade está disponível nativamente no iOS ou Android: WhatsApp, Waze, Swarm, Snapchat, Instagram.

Dez anos atrás, com o lançamento do iPhone, a indústria de tecnologia finalmente começou a se organizar.

Foi um jogo de gato e rato até uns cinco anos atrás, quando as coisas começaram a se estabilizar.

Depois que Jobs morreu, ainda tínhamos a expectativa de que a Apple continuaria avançando, ainda que num ritmo mais lento sem o chicote do Jobs.

Não aconteceu. Foram decisão ruim atrás de decisão ruim, e a sensação é de que voltamos ao início dos anos 90, na era de Scully, Spindler ou Amelio.

Apple, Prey

Mas agora existem alternativas sólidas disponíveis: o Windows 10 Anniversary Edition é finalmente um Windows competente, recuperando a glória dos meados dos anos 90. E as grandes distros Linux são coesas, exigindo pouco ou nenhum ajuste nerd em arquivos de configuração obscuros, empurradas pela Canonical, para o bem ou para o mal.

E a maioria dos apps que usamos no dia a dia está disponível. Dá até para encontrar um bom editor de texto multiplataforma baseado na web na forma do Atom.

A Apple também deixou o legado da compilação multiplataforma ubíqua na forma do LLVM. Serviu às próprias necessidades deles de ter Objective-C disponível em PowerPC, Intel, ARM e nos processadores Apple Ax. Mas o LLVM é agora a melhor espinha dorsal para permitir que linguagens como Rust, RubyMotion e Crystal existam e criem binários rápidos em múltiplas plataformas.

Chris Lattner leaves Apple to Tesla

“O conselho da Apple precisa ir embora.” “Tim Cook precisa renunciar.” Tenho certeza que muita gente grita isso por aí, mas não tem Steve Jobs esperando para voltar. A Apple é grande o suficiente para que a inércia sozinha a mantenha andando por mais alguns anos, mas ela corre o risco real de cair na irrelevância.

Outras indústrias como energia, saúde e genética evoluem do jeito delas, mas a tecnologia da computação está num perigoso marasmo.

As linguagens de programação pararam de evoluir em meados dos anos 90. Todas as linguagens “novas” são amálgamas de recursos que já existiam desde os anos 70 e 80. Os processadores estão presos em fazer transistores menores e mais eficientes em termos de energia. E já chegamos lá: computadores de US$ 9 são suficientes para tarefas triviais como navegar na web. A ponto de estarmos colocando processadores em tudo: inclusive numa escova de dentes bluetooth que registra suas sessões de escovação.

Bluetooth Toothbrush

Viu os produtos da CES 2017? Travesseiros e camas que monitoram seu sono e sincronizam com um app. Máquinas de lavar. Aspiradores de pó. Dispositivos fitness. Dispositivos de saúde. Assistentes pessoais como a Alexa. Tudo captura dados seus e sincroniza na nuvem.

A nuvem também chegou ao pico. É ubíqua, acessível e barata. A tecnologia em geral está absurdamente barata hoje em dia.

Wearables e VR são boas novidades, mas mesmo que se tornem ubíquos, continuam sendo apenas uma extensão dos casos de uso que a revolução do iPhone iniciou.

Baby monitor

iSwimband

mobile

Mobile, wearables, redes sociais, só deixaram as pessoas mais ansiosas. Dar “voz” a todo mundo online não melhorou as coisas, só aumentou a ansiedade geral. Opiniões estão em oferta tão grande que valem cada vez menos.

Cada pessoa online é agora uma fonte de terabytes de informação inútil para gerar pseudo-estatísticas que não servem para quase nada. Cada pessoa é agora definida por um monte de dados na nuvem.

Trump

Não faço ideia para onde vamos daqui. Como testemunha da história, tenho que dizer que sinto falta da empolgação de explorar novas fronteiras. Tivemos isso a partir dos meados dos anos 90. Demos uma pausa depois do estouro da Bolha da Internet, mas recuperamos com tudo em 2004. Perdemos depois de 2010.

Windows 95 launch

2010 foi o ano mais longo que já vivi. Talvez estabilizar seja uma coisa boa. Quem sabe?

]]>applemercado-de-tecnologiapessoaloff-topicSituação Brasil: No Macs for the Rest of Ushttps://akitaonrails.github.io/2015/11/10/situacao-brasil-no-macs-for-the-rest-of-us/https://akitaonrails.github.io/2015/11/10/situacao-brasil-no-macs-for-the-rest-of-us/Tue, 10 Nov 2015 16:54:00 -0200<p>Este artigo quer ser prático, então vou direto ao ponto. Com o <strong>inquestionável</strong> governo inepto e corrupto que temos, um dos efeitos concretos para nós, desenvolvedores de software, é a incapacidade de comprar boas máquinas para fazer o nosso próprio trabalho.</p> <p><img src="https://akitaonrails.s3.amazonaws.com/assets/image_asset/image/523/cotacao_dolar.png" alt="Cotação do Dólar 2015" loading="lazy" /></p> <p>O Real entrou em queda livre no começo deste ano e só agora começa a estabilizar um pouco. Mesmo assim, ficamos cada vez mais longe do ideal de comprar um notebook profissional.</p>Este artigo quer ser prático, então vou direto ao ponto. Com o inquestionável governo inepto e corrupto que temos, um dos efeitos concretos para nós, desenvolvedores de software, é a incapacidade de comprar boas máquinas para fazer o nosso próprio trabalho.

Cotação do Dólar 2015

O Real entrou em queda livre no começo deste ano e só agora começa a estabilizar um pouco. Mesmo assim, ficamos cada vez mais longe do ideal de comprar um notebook profissional.

No site oficial da Apple do Brasil, somando a desvalorização do Real e o maldito Custo Brasil em impostos, a máquina ideal de desenvolvimento, o Macbook Pro 15" Retina com 16GB de RAM e 512GB SSD, chega à quantia impossível de R$ 23.499,00.

Nos Estados Unidos, essa mesma máquina custa USD 2.499 mais (pouco) imposto. Se fôssemos pelo mercado paralelo (que eu recomendo), com o dólar nos atuais R$ 3,80 mais uns 30% a 40% do “custo paralelo”, ainda assim não vamos pagar menos que R$ 13.500.

Mesmo escolhendo a versão 13" Retina com 8GB de RAM, que custa USD 1.799 nos EUA, aqui não sai por menos que R$ 9.700.

Ou seja, é mais que o dobro do que a maioria dos desenvolvedores consegue pagar, considerando um orçamento de R$ 4.000, até R$ 5.000 se esticarmos muito.

O TL;DR é simples: o melhor hardware (não só processador, mas teclado, trackpad, acabamento geral) continua sendo o Macbook Pro. Nenhuma outra máquina chega perto, e para mim o melhor sistema operacional continua sendo o OS X, com virtualização de Linux para desenvolvimento. Sem poder comprar um Macbook, resta escolher um bom PC e rodar Linux.

Qual Máquina Comprar?

Mesmo comprando uma máquina no Brasil, não dá para levar a melhor configuração, que empurra o preço para acima dos R$ 8.000.

Na faixa dos R$ 5.000, esqueçam SSD, não existe. O melhor custo-benefício que achei foi o Dell Inspiron 15 Series 5000, que no momento da publicação deste artigo estava R$ 4.117. Vale escolher com bastante RAM, mais de 8GB de preferência, para evitar ao máximo o swap no disco lento, normalmente mecânico de 5400 RPM.

Se alguém tiver boas opções nessa faixa, com pelo menos Core i5 de 3a geração, 8GB de RAM e 256GB de SSD, compartilhe nos comentários.

Em termos de hardware, um Lenovo Thinkpad ou mesmo um Sony Vaio (que também deve estar proibitivamente caro) têm acabamento melhor que o da Dell. Asus e Acer eu não considero boas opções para durar muito tempo, e o acabamento também não é grande coisa.

Já adianto que teclado e trackpad de PC são terríveis. Se possível, use teclado e trackpad externos da Apple. O modelo da Dell que estou testando tem um teclado horrível, fora o layout brasileiro que eu detesto: plástico leve, com feedback de clique muito ruim para quem digita rápido. O trackpad interrompe a digitação a cada leve toque, tem dificuldade de registrar múltiplos cliques corretamente e no geral atrapalha mais do que ajuda.

Perfis de Desenvolvedor

A ideia é uma máquina para desenvolvedores. A menos que você seja um desenvolvedor .NET, instale uma distribuição Linux. Qual distro depende do seu perfil: quanto mais low level, mais você se aproxima de querer um Arch Linux. Quanto mais high level, sobretudo desenvolvedor de web apps, mais eu recomendo um Ubuntu LTS, que no caso seria o Ubuntu 14.04.

Windows está fora de cogitação, sinto muito. Fui usuário de Windows por quase 15 anos antes de migrar para Macs em 2004. Sou muito experiente com Windows, conheço todos os meus caminhos tortuosos pelo Registry e a bagunça que é o famigerado C:\WINDOWS. Testei todos os últimos Windows (7, 8, 8.1, 10) e a conclusão é a mesma: não faço nenhuma questão de voltar.

Se tivesse que desenvolver em .NET, nem tentaria emular o ambiente, apenas usaria Windows mesmo, numa máquina virtual. A única solução, quando o ambiente de desenvolvimento exige um híbrido de .NET com open source, é rodar Linux com virtualização.

O ciclo de desenvolvimento open source num Mac também não é exatamente simples. Você precisa entender o XCode e precisa saber que o GCC deixou de ser a escolha default faz tempo, já que a Apple migrou para LLVM-Clang, e por conta disso muita coisa pode quebrar. Mesmo assim, o pessoal do Homebrew fez um excelente trabalho removendo a maior parte dos problemas. Dá para desenvolver confortavelmente, desde que você não seja um desenvolvedor system/low level.

Para desenvolvimento de iOS, você precisa do XCode. Não há alternativa. Nas outras linguagens dá para trabalhar com relativa facilidade, seja Python, Ruby ou as mais novas como Rust, Elixir e Go. Java também roda mais ou menos bem no Mac, então Java 8, Clojure, Scala e Groovy estão à disposição.

Opcionalmente, recomendo usar um ambiente Linux virtualizado dentro do Mac. Seja direto pelo Virtualbox, que não é a coisa mais estável do mundo no Mac, seja pelo VMWare Fusion, com Vagrant para facilitar. Essa segunda opção vai custar caro, USD 170.

Software Proprietário vs Código Aberto

Sim, no Linux temos diversas opções, como Inkscape, Gimp e Blender. Sim, “dá” para fazer muita coisa.

Na prática, usabilidade conta.

No OS X temos Keynote, iMovie e Garageband, sem iguais em usabilidade. Para fins mais high end, temos Aperture, Final Cut Pro e Logic Pro, de novo sem iguais em usabilidade e flexibilidade.

No Windows, dá para escolher o pacote da Adobe, que vai de Photoshop e Illustrator a Premiere Pro e After Effects, todos com versões também para Mac.

No mundo da produtividade, esqueçam LibreOffice ou mesmo Google Docs: o pacote Microsoft Office, em particular Word e Excel, ainda é imbatível. Dá para fazer parecido, dá para editar parecido, mas ainda não chega perto, especialmente em planilhas mais complexas e cheias de fórmulas, pivot tables e afins.

Todos eles custam, e custam caro. Obviamente não é justo comparar com as opções open source. Mas eu gostaria muito de ter a opção de pagar para rodar isso numa distro Linux. O problema é que distros Linux não são amigáveis para software proprietário. Vai ser sempre o dilema do 100% aberto contra o híbrido ou o 100% fechado. Que o digam os caras do Ubuntu.

Um exemplo pequeno é o 1Password, que uso no Mac, no Android, usava no iOS (quando tinha iPhone) e tem versão para Windows. Tudo, menos para Linux. Fui obrigado a rodar o 1Password de Windows via Wine para conseguir acessar minhas senhas de novo. “Bem feito, quem mandou usar software proprietário.”

Para o bem ou para o mal, o ideal de software 100% aberto nunca esteve tão longe, ainda mais hoje, quando todo app tem um componente online. Existe agora muito “client” open source, mas o back-end é totalmente closed source. Pior: nem é um binário na sua máquina, está no “cloud”.

Ninguém vai aderir ao ideal da Affero GPL, em que o código rodando no cloud também deveria ser aberto. E, mesmo se fosse, não seria prático para ninguém simular o mesmo ambiente cloud de todo mundo.

Hoje, o mundo open source não é um mundo de liberdade absoluta. Eu costumo sintetizar assim: ele é o melhor custo-benefício que as empresas já tiveram para manter software comoditizado.

Linguagens, frameworks, toolkits, ferramentas de desenvolvimento e bibliotecas de criptografia são software comoditizado.

Pacote Adobe, Office e afins ainda não são commodities. Continuam a todo vapor, com feature nova atrás de feature nova, todo semestre. É impossível um copy-cat open source, sem recursos, atingir o mesmo nível. E nem há interesse nisso.

Para quem precisa de software proprietário como ferramenta do dia a dia, o conselho é direto: não saia do Windows, não saia do Mac.

Eu preciso ocasionalmente. 80% das minhas necessidades dependem de software comoditizado ou de software que não é o core business de nenhuma empresa que o produz. Para o Google, o Chromium vale a pena ser open source, mas ninguém chega perto do código do Ad Sense, que é o verdadeiro core business.

Para todo mundo, vale a pena que os clients que consomem os serviços sejam open source. Vou achar um bom client para Dropbox, para Google Drive, mas nem tente procurar o resto: o core business ainda é e vai continuar fechado. É aí que o ideal do Free Software vai ficando cada vez mais distante.

Eu não sou idealista. Para a maioria dos desenvolvedores, o que temos já basta, se sustenta e vira viável num mundo híbrido. No mundo real, 80% do que preciso está disponível. Os outros 20% eu resolvo por virtualização, com o meu Office rodando via Wine ou via Virtualbox.

Talvez eu consiga rodar o Apple Keynote via Hackintosh num Virtualbox. Ou então resolvo os últimos 5% com um Macbook defasado, mas que rode o que preciso nas poucas horas em que preciso dele.

Tentei instalar um Hackintosh via Virtualbox e, embora tenha conseguido depois de várias tentativas e muitos tutoriais, ele fica absolutamente instável e lento, mesmo com 2 dos meus 4 Core i7, 4GB de RAM e 128MB de memória de vídeo. Não dá para usar. Se eu quiser usar Keynote, vai ter que ser um Mac de verdade, não tem substituto.

Por que Ubuntu + Unity?

Se tem uma coisa em que todo mundo tem opinião é em como usar o seu Linux. Depende de quem você é.

Se você for um programador mais idealista, vai odiar o Ubuntu justamente por pegar o que o Debian faz e adicionar a argh terrível camada de software proprietário por cima.

Se você for um programador mais hardcore, vai querer entender cada centímetro do seu Linux, e para isso sempre vai achar o Arch Linux (ou pelo menos o Antergos) uma opção superior. Para esse pessoal, o Pacman sempre será infinitamente superior ao Apt-Get ou ao Yum.

Se você for do tipo “seja estável sem mexer muito, mas não seja comum”, pode acabar indo para o lado do Fedora.

E, seja qual for a distro, sempre vai existir a eterna briga entre Window Managers. O pessoal do KDE com o seu Plasma falando mal do antiquado Gnome, o XFCE afirmando sua posição de “simples e estável”, ou uma distro nova como o Elementary OS criando o seu novo Pantheon. Isso não tem fim.

A maioria dos programadores novos, que usam Linux há 5 anos ou menos, não entende como alguém pode usar um Linux sem customizá-lo totalmente ao seu gosto. Editar cada arquivo do X11, cada tema e cada pacote de ícones para virar um “Windows-alternativo”, um “OS X-rebelde”.

No meu caso, o que muitos podem não entender, é que sou usuário de Linux das antigas. Meu primeiro Linux foi o Slackware 1.0 em 1996. Instalei RedHat pré-4 e depois vieram distros como o Mandrake, muito antes de um Kurumin. Instalei as primeiras versões da maioria das distros de hoje.

Já varei noite após noite customizando o meu X, baixando temas, baixando widgets, ajustando cada parte do sistema. Depois eu fazia alguma coisa errada, resolvia formatar tudo e começava do zero de novo. Passei muito tempo checando flags de compilação de kernel para deixar o meu o mais customizado possível.

Fiquei nessa vibe de 1997 até talvez 2001. É cansativo, sério. Se você é programador, na faixa dos 20 anos e nunca fez isso, eu diria que tem obrigação moral de passar por esse processo. Todo programador precisa achar legal ter controle total do próprio ambiente.

Mas não é saudável fazer isso por mais de 5 anos. Depois disso, você quer mesmo é ser produtivo, produzir em vez de customizar. A quantidade de horas necessária para deixar uma distro 100% “minha” simplesmente não compensa.

É por isso que eu gosto do OS X: não preciso customizar nada. Tudo já vem do jeito certo out-of-the-box, o melhor Window Manager, em cima de um dos melhores sabores tradicionais de Unix, com acesso razoavelmente simples tanto ao mundo open source quanto ao melhor do mundo closed source. É o melhor dos dois mundos.

No mundo Linux, você tem que lidar com a ideologia do GPL. Eu entendo perfeitamente os argumentos do Stallman, li e reli o site inúmeras vezes. Quantas vezes você realmente leu o gnu.org inteiro? Infelizmente não existe almoço grátis: ficar na ideologia significa abrir mão de muita coisa que eu realmente não tenho disposição de abrir.

No caso, o Dell que eu comprei veio com Ubuntu pré-instalado. É o que ele suporta, o que significa que todo o hardware funciona e os drivers estão atualizados. Pretendo ficar dentro do ecossistema Ubuntu, incluindo o Unity, que eu sei que muitos não curtem por ideologia ou porque acham que XFCE, Gnome, KDE ou sei lá o quê funciona melhor para o gosto deles.

De novo: o custo de customizar simplesmente não compensa. Software não se instala uma vez e funciona para sempre. Tem que atualizar, tem que ter suporte, tem que ser consistente. O pessoal da Canonical é a única empresa seriamente focada em usabilidade e consumidor final, e isso importa.

A Canonical é freada o tempo todo pela ideologia e por opiniões demais que nunca chegam a consenso, e é vilipendiada toda vez que toma uma decisão: sempre uma metade da comunidade fica sem o que quer e vai chiar. É um processo moroso e burocrático que uma Apple simplesmente decidiu ignorar por completo.

Só que a Apple tem como trazer a Microsoft, a Adobe e gerar modelos de negócio lucrativos para centenas de outras software houses. A Canonical ainda não consegue fazer isso e depende muito das horas vagas de programadores voluntários do mundo open source. Essa dependência é ao mesmo tempo uma grande força e o seu maior problema.

Última dica: tive problemas para manter o sistema em inglês (menus e tudo mais) e usar um teclado USB externo de Mac no layout English (US, alternative international). O normal, acentuar o “c” para sair o cedilha “ç”, não funcionava. Só funcionou depois que segui este tutorial do Kemel Zaidan.

Conclusão

Vou continuar usando Ubuntu como máquina principal? Ainda não sei. Estou mantendo as opções abertas para tempos mais difíceis, com o dólar acima de R$ 2,50. Abaixo desse patamar, fico com um Mac sem pensar duas vezes.

Para usuários domésticos, um Linux funciona bem. É a ideia do Chrome OS, um Linux rodando basicamente Web Apps como Google Docs, Gmail e afins. Nesse nível, tanto faz o OS ou a configuração. A vantagem de um Linux para o uso web de 90% da população é não ficar vulnerável aos malwares mais óbvios.

Para usuários de escritório, um Linux funciona razoavelmente bem, mas, como eu disse, o Office ainda não dá para substituir. A saída é a empresa inteira adotar um formato mais simples de documentos e não fazer nada muito complexo no Excel, por exemplo. No geral, Google Docs e Google Drive ou Dropbox, com Gmail Business, funcionam bem o suficiente.

Para desenvolvedores .NET, fiquem no Windows.

Para desenvolvedores open source, tanto faz ficar no Linux ou no Mac. Se for high end, escolha um Mac se puder pagar. Se for mais low level, fique no mundo Linux puro mesmo. Na dúvida: Ubuntu 14.04 LTS (com Unity!), instale a sua opção de Sublime Text 3 e o resto funciona perfeitamente.

Para usuários híbridos, que são desenvolvedores a maior parte do tempo mas também precisam de software proprietário (o meu caso), dá para ficar no Linux. Na maior parte do tempo não vai doer tanto. Mas naquele único momento em que você precisar editar um vídeo, mexer num Photoshop mais pesado ou montar um Keynote mais elaborado, tenha um Mac à mão. Para esse caso, não há alternativa.

]]>linuxapplehardwareoff-topicSwift para Rubistas, Funções e Closureshttps://akitaonrails.github.io/2014/06/07/swift-para-rubistas-funcoes-e-closures/https://akitaonrails.github.io/2014/06/07/swift-para-rubistas-funcoes-e-closures/Sat, 07 Jun 2014 12:38:00 -0300<p>Se tem uma coisa que nós rubistas estamos muito acostumados e gostamos bastante são closures, blocos ou fechamentos. Expliquei esse mecanismo pela primeira vez em 2007 aqui no blog, então se ainda não conhece bem o conceito, releia <a href="http://www.akitaonrails.com/2007/11/30/anatomia-de-ruby-blocks-closures#.U5MdTBYduzA"target="_blank" rel="noopener">meu post</a>.</p> <p>Em 2010 a Apple adicionou a funcionalidade de closures ao Objective-C também e modificou muitas de suas APIs para aproveitar esse recurso. Também postei sobre isso 3 anos atrás, então releia <a href="http://www.akitaonrails.com/2010/11/28/objective-c-brincando-com-categorias-e-blocos#.U5MdhxYduzA"target="_blank" rel="noopener">meu post</a> para aprender sobre isso.</p>Se tem uma coisa que nós rubistas estamos muito acostumados e gostamos bastante são closures, blocos ou fechamentos. Expliquei esse mecanismo pela primeira vez em 2007 aqui no blog, então se ainda não conhece bem o conceito, releia meu post.

Em 2010 a Apple adicionou a funcionalidade de closures ao Objective-C também e modificou muitas de suas APIs para aproveitar esse recurso. Também postei sobre isso 3 anos atrás, então releia meu post para aprender sobre isso.

Finalmente, Swift é basicamente Objective-C melhorado então temos o mesmo recurso.

Entendendo Funções e Blocos

A idéia é poder criar funções “customizáveis”, ou seja, um pedaço de código que espera outro pedaço de código. Existem duas formas de se fazer isso. No mundo C podemos passar diretamente uma função como parâmetro para ser executada dentro de outra função. Isso não é uma closure, é o que chamamos de “callback”. Em Objective-C e Swift, podemos passar uma função como parâmetro ou mesmo fazer uma função retornar uma função.

func soma(x: Int, y: Int) -> Int {
    return x + y
}

func calculadora(calculo: (Int, Int) -> (Int), a: Int, b: Int) {
    let resultado = calculo(a, b)
    println(resultado)
}

calculadora(soma, 10, 20)
// "30"

Veja o código acima, definimos uma função de soma, que recebe dois inteiros como parâmetro e retorna um inteiro. Depois definimos uma função genérica chamada “calculadora” que recebe como parâmetro uma função com a assinatura (Int, Int) -> Int que significa “uma função que receba dois inteiros e retorne um inteiro” e depois dois parâmetros inteiros.

Ao executar calculadora(soma, 10, 20), passamos a função soma, os números 10 e 20 e internamente atribuímos a função soma a uma variável chamada “calculo” e executamos passando os dois inteiros, que, obviamente, serão somados. E a resposta no final será 30.

func multiplicacao(x: Int, y: Int) -> Int {
    return x * y
}

calculadora(multiplicacao, 3, 5)
// "15"

Podemos agora criar quaisquer funções com a mesma assinatura e depois mandar para a calculadora. Em Ruby não temos a mesma funcionalidade:

def soma(x, y)
  x + y
end

def calculadora(calculo, a, b)
  puts calculo(a, b)
end

calculadora(soma, 10, 20)
# ArgumentError: wrong number of arguments (0 for 2)
# 	from (irb):1:in `soma'
# 	from (irb):9
# 	from /usr/bin/irb:12:in `<main>'

Em Ruby, parênteses são opcionais e ao tentar passar o método “soma” como parâmetro, na verdade ele está já tentando executar o método. Existe uma forma, não ortodoxa, que podemos ter um efeito similar, mas não é a mesma coisa, seria assim:

def calculadora(calculo, a, b)
  puts send(calculo, a, b)
end

calculadora(:soma, 10, 20)

O método send é uma das formas de se enviar mensagens a objetos (Objective-C também tem isso, na forma de seletores e do método performSelector que expliquei neste outro post). Então, em vez de passar diretamente o método, passamos apenas o nome dele como um symbol e internamente executamos o método passando os parâmetros. Isso é só “similar” porque na prática o método em si nunca foi passado como parâmetro.

O que podemos fazer em Ruby é não usar métodos, mas blocos:

soma = lambda do |x, y|
  x + y
end

def calculadora(calculo, a, b)
  puts calculo.(a, b)
end

calculadora(soma, 10, 20)

Aqui a semântica é diferente. Primeiro criamos um bloco, literalmente o que seria o “corpo de um método” usando lambda. Depois passamos o bloco com parâmetro ao método calculadora. E dentro dela executamos o bloco com um “ponto” antes dos parênteses, que é a forma curta de se fazer soma.call(a, b)

Um bloco, em Ruby, é diferente de uma método ou função. Isso porque ele também é um fechamento do estado ao redor do bloco. Blocos não são métodos. Em Ruby, o método está associado (“binding”) à classe que a define (mesmo sem definir um class, estamos dentro sempre dentro de um objeto, diferente de Swift ou Objective-C ou mesmo outra linguagem). Um bloco está associado à uma variável e por isso podemos mais facilmente repassá-la para outros métodos.

Em Swift também podemos devolver funções ou ter “Nested Functions”, por exemplo:

func calculo(tipo: String) -> (Int, Int) -> Int {
    func soma(x: Int, y: Int) -> Int {
        return x + y
    }
    func multiplicacao(x: Int, y: Int) -> Int {
        return x * y
    }
    if tipo == "soma" {
        return soma
    } else {
        return multiplicacao
    }
}

func calculadora(calculo: (Int, Int) -> Int, a: Int, b: Int) {
    println(calculo(a, b))
}

calculadora(calculo("soma"), 10, 20)
// 30

Em Ruby, o mais próximo, usando blocos, seria:

def calculo(tipo)
  soma = lambda { |x, y| x + y }
  multiplicacao = lambda { |x, y| x * y }
  if tipo == :soma
    soma
  else
    multiplicacao
  end
end

def calculadora(c, a, b)
  puts c.(a, b)
end

calculadora(calculo(:soma), 10, 20)
# 30

Entendendo Blocos em Swift

Sabendo dessa base podemos prosseguir para o próximo passo, blocos em Swift.

Primeiro, vejamos o uso mais comum de blocos em Ruby:

def numero(bla)
  yield(bla) if block_given?
end

numero 20 do |x|
  x * 10
end
# 200

Definimos um método chamado numero que recebe um parâmetro “bla”. Internamente chamamos yield que pega o bloco passado como último parâmetro do método e repassa o parâmetro “bla” a ele. Fora, executamos o método frase, passando 20 como parâmetro e um bloco (delimitado por “do..end”) que recebe uma variável x e apenas multiplica ela por 10.

Podemos reescrever o mesmo código da seguinte forma:

def numero(bla, &bloco)
  bloco.(bla) if bloco
end

numero(20) { |x| x * 10 }
# 200

É exatamente o mesmo código mas agora o bloco está definido como parâmetro mais explicitamente. O “&” diz que vamos passar o bloco fora dos parênteses do método. Executamos o bloco dentro com o “ponto” (no lugar de “call”, como explicamos antes). E ao executar o método, desta vez deixei os parênteses opcionais e no lugar de “do..end” usei “{}”, que é a mesma coisa. Por convenção, em Ruby, usamos “{}” quando um bloco tem somente uma linha de implementação e usamos “do..end” quando tem múltiplas linhas.

Obs, o @josevalim me explicou que há outra sintaxe que podemos usar e são equivalentes (embora pareça que só funcione em one-lines):

numero.map { (var x: Int) -> Int in return x * 10 }
numero.map { $0 * 10 } // equivalente ao de cima

Confinuando, podemos fazer a mesma coisa em Swift, assim:

func numero(bla: Int, bloco: (Int) -> Int) {
    println(bloco(bla))
}

numero(20, { (x: Int) -> Int in return x * 10 } )

Por causa da necessidade de definir o seletor/assinatura, com parâmetros e tipo de retorno, a execução da closure em Swift é bem mais verbosa do que em Ruby. A sintaxe é semelhante, usando chaves “{}” para delimitar o bloco, a assinatura para delimitar a função anônima e o corpo do bloco depois de “in”. Na prática é quase a mesma coisa.

Do livro oficial da Apple temos o seguinte exemplo que pode demonstrar um pouco melhor (eu mudei o exemplo pois no livro ele usa um Dictionary para “digitNames” mas as chaves são exatamente a posição num Array, então achei melhor usar diretamente um Array):

let digitNames = [
	"Zero", "One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine"
]
let numbers = [16, 58, 510]

let strings = numbers.map {
    (var number) -> String in
    var output = ""
    while number > 0 {
        output = digitNames[number % 10] + output
        number /= 10
    }
    return output
}
// strings is inferred to be of type String[]
// its value is ["OneSix", "FiveEight", "FiveOneZero"]

A mesma coisa em Ruby ficaria assim:

digit_names = [
  "Zero", "One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine"
]
numbers = [16, 58, 510]
strings = numbers.map do |number|
  output = ""
  while number > 0 
    output = digit_names[number % 10] + output
    number = number / 10
  end
  output
end
# ["OneSix", "FiveEight", "FiveOneZero"]

Veja como a lógica em si é bastante semelhante, se ignorar a definição mais exata de tipos do Swift, os dois códigos são praticamente idênticos.

No meu post de 2010 sobre como implementar o equivalente a “method_missing” em Objective-C eu parti deste exemplo comum de DSL do mundo Ruby:

require 'builder'
x = Builder::XmlMarkup.new(:target => $stdout, :indent => 1)
x.html do |h|
  h.body do |b|
    b.h1 "Hello World"
    b.p "This is a paragraph."
    b.table do |t|
      t.tr do |tr|
        tr.td "column"
      end
    end
  end
end

E cheguei neste equivalente em Objective-C:

XmlBuilder* xml = [[XmlBuilder alloc] init];
[xml htmlBlock:^(XmlBuilder* h) {
    [h bodyBlock:^(XmlBuilder* b) {
        [b h1:@"Hello World"];
        [b p:@"This is a paragraph."];
        [b tableBlock:^(XmlBuilder* t) {
            [t trBlock:^(XmlBuilder* tr) {
                [tr td:@"column"];
            }];
        }];            
    }];
}];

Absolutamente verborrágico! Não era divertido usar blocos em Objective-C pela quantidade de delimitadores com chaves, parênteses, colchetes. Em Ruby é bem mais simples porque parênteses são todos opcionais e blocos são delimitados quase como métodos.

Ainda não reimplementei esse experimento que fiz em Objective-C para Swift (fica como lição de casa). Farei isso num próximo artigo sobre metaprogramação e seletores em Swift. Mas se tivéssemos reescrito, provavelmente o código ficaria mais ou menos assim:

// Swift:                            // Ruby:
xml = XmlBuilder()                   // x = Builder::XmlMarkup.new
xml.html({ (var h) -> Void in        // x.html do |h|
    h.body({ (var b) -> Void in      //   h.body do |b|
        b.h1("Hello World")          //     b.h1 "Hello World"
        b.p("This is a paragraph")   //     b.p "This is a paragraph."
        b.table({ (var t) -> Void in //     b.table do |t|
            t.tr({ (var tr) -> Void  //       t.tr do |tr|
                tr.td("column")      //         tr.td "column"
            })                       //       end
        })                           //     end
    })                               //   end
})                                   // end

Veja que comparado à versão em Objective-C é “muito” melhor. Mesmo assim, se comparado ao que fazemos em Ruby, continua sendo mais verboso do que gostaríamos por causa dos parênteses obrigatórios e declaração de tipos das funções, mas agora sim fica muito mais prático ver que podemos fazer DSLs em Swift também.

Isso deve dar uma luz sobre como a nova sintaxe do Swift é de fato um real ganho de legibilidade e produtividade para programadores acostumados a Objective-C e como nós, de Ruby, podemos rapidamente nos adaptar a essa nova linguagem para produzir bibliotecas e frameworks. Uma vantagem do Swift é que ele é imediatamente compatível com toda a API escrita em Objective-C, portanto onde antes era chato escrever as closures, agora fica imediatamente mais simples.

]]>linguagens-de-programacaoappleaprendizadoSwift para Rubistas, Rápida Introduçãohttps://akitaonrails.github.io/2014/06/03/swift-para-rubistas-rapida-introducao/https://akitaonrails.github.io/2014/06/03/swift-para-rubistas-rapida-introducao/Tue, 03 Jun 2014 17:01:00 -0300<p>Como vocês devem ter assistido no keynote de abertura da <a href="http://startupi.com.br/2014/apple-esta-retornando-suas-formas-jobs-ficaria-orgulhoso/"target="_blank" rel="noopener">WWDC 2014</a>, a Apple lançou uma nova linguagem, mais moderna, para substituir o Objective-C como linguagem padrão para desenvolvimento de aplicações tanto OS X quanto iOS. Não se trata de uma nova &ldquo;camada&rdquo; mas uma linguagem que tecnicamente compila para o mesmo tipo de binário que o próprio Objective-C e mesmo C. Graças ao compilador que é implementado sobre LLVM isso se torna possível.</p>Como vocês devem ter assistido no keynote de abertura da WWDC 2014, a Apple lançou uma nova linguagem, mais moderna, para substituir o Objective-C como linguagem padrão para desenvolvimento de aplicações tanto OS X quanto iOS. Não se trata de uma nova “camada” mas uma linguagem que tecnicamente compila para o mesmo tipo de binário que o próprio Objective-C e mesmo C. Graças ao compilador que é implementado sobre LLVM isso se torna possível.

A linguagem Swift é um Objective-C com funcionalidades mais modernas e uma sintaxe mais elegante e menos verbosa. Já havia publicado neste blog anos atrás como o Objective-C e Ruby tem conceitos muito similares. E isso se deve à herança comum da linguagem Smalltalk.

Antes que algum afobado comece a trolar: o artigo não tem como objetivo dizer que Swift tem inspiração em Ruby ou que Ruby tem algum tipo de relação com Swift. Apenas aproveitando o fato de terem origens similares e funcionalidades que fazem sua programação ser próxima, quero usar o artigo para mostrar a rubistas algumas nuances do Swift.

Todos os exemplos de código foram extraídos do eBook “The Swift Programming Language.” que é uma boa introdução à linguagem. Mas para realmente tirar proveito é melhor conhecer a fundo Objective-C, C e obviamente, toda a documentação de APIs dos frameworks para iOS e OS X.

Exemplos de Sintaxe

Do ponto de vista da sintaxe, a linguagem está bem mais atraente. Vejamos um trecho muito simples em Swift:

if let actualNumber = possibleNumber.toInt() {
    println("\(possibleNumber) has an integer value of \(actualNumber)")
} else {
    println("\(possibleNumber) could not be converted to an integer")
}
// prints "123 has an integer value of 123"

E em Ruby:

if actual_number = possible_number && possible_number.to_i
  puts "#{possible_number} has an integer value of #{actual_number}"
else
  puts "#{possible_number} could not be converted to an integer"
end
# prints "123 has an integer value of 123"

Statements como “if” ou “for” não tem parênteses como em C, embora cada seção ainda seja separado por chaves “{}”. Visualmente falando a diferença é bem pequena. Interpolação em strings tem uma sintaxe um pouco diferente mas no geral é muito semelhante.

As convenções de nomenclatura são diferentes: no Ruby usamos tudo em caixa baixa separado por underline e Swift ainda tem a herança de Objective-C de camel casing. Além disso Swift identa código com 4 espaços e Ruby com 2.

Vejamos outro exemplo em Swift:

func alignRight(var string: String, count: Int, pad: Character) -> String {
    let amountToPad = count - countElements(string)
    for _ in 1...amountToPad {
        string = pad + string
    }
    return string
}
let originalString = "hello"
let paddedString = alignRight(originalString, 10, "-")
// paddedString is equal to "-----hello"
// originalString is still equal to "hello"

E o equivalente em Ruby seria:

def align_right(string, count, pad)
  amount_to_pad = count - string.size
  (1..amount_to_pad).each do
    string = pad + string
  end
  string
end
original_string = "hello"
padded_string = align_right(original_string, 10, "-")

A primeira semelhança é que Swift possui “Ranges” como em Ruby embora a notação seja oposta. Usamos “..” em Ruby para um range que inclui ambos os números extremos e “…” (3 pontos) para não incluir o último número. Em Swift é o contrário.

Em Swift, o correto é declarar os tipos dos argumentos e do valor de retorno e o “return” é explícito. No Ruby não tempos tipos pré-declarados e o retorno padrão é sempre o valor da última coisa executada. E falando em Ranges, tanto em Ruby quanto Swift podemos ter pattern matching de valores em intervalos:

let count = 3_000_000_000_000
let countedThings = "stars in the Milky Way"
var naturalCount: String
switch count {
case 0:
    naturalCount = "no"
case 1...3:
    naturalCount = "a few"
case 4...9:
    naturalCount = "several"
case 10...99:
    naturalCount = "tens of"
case 100...999:
    naturalCount = "hundreds of"
case 1000...999_999:
    naturalCount = "thousands of"
default:
    naturalCount = "millions and millions of"
}
println("There are \(naturalCount) \(countedThings).")

Em Ruby é praticamente a mesma coisa:

count = 3_000_000_000_000
counted_things = "stars in the Milky Way"
natural_count = case count
when 0 then "no"
when 1..3 then "a few"
when 4..9 then "several"
when 10..99 then "tens of"
when 100..999 then "hundreds of"
when 1000..999_999 then "thousands of"
else
  "millions and millions of"
end
puts "There are #{natural_count} #{counted_things}."

Swift e Ruby não precisam de “break” porque ele não cai para o próximo match. Ambos tem capacidade de comparar não só valores mas intervalos ou outros elementos. No caso, como Ruby tem return por default, não precisamos repetir a variável “natural_count” em cada ítem e o resultado geral do “case” vai para a única atribuição no topo.

Este outro trecho também é curioso:

if let roomCount = john.residence?.numberOfRooms {
    println("John's residence has \(roomCount) room(s).")
} else {
    println("Unable to retrieve the number of rooms.")
}
// prints "Unable to retrieve the number of rooms."

O “equivalente” em Ruby (se estivermos no Rails) seria:

if room_count = john.residence.try(:number_of_rooms)
  puts "John's residence has #{room_count} room(s)."
else
  puts "Unable to retrieve the number of rooms."
end

Não é exatamente a mesma coisa. No Swift o “?” denota uma propriedade opcional e enviar uma mensagem a um objeto opcional devolve “nil”. Na prática é quase a mesma coisa que o método #try do ActiveSupport do Rails.

E falando em ActiveSupport o Swift herda Categories de Objective-C com o nome de Extensions, que é uma forma de estender a funcionalidade de uma classe que já existe:

extension Double {
    var km: Double { return self * 1_000.0 }
    var m: Double { return self }
    var cm: Double { return self / 100.0 }
    var mm: Double { return self / 1_000.0 }
    var ft: Double { return self / 3.28084 }
}
let oneInch = 25.4.mm
println("One inch is \(oneInch) meters")
// prints "One inch is 0.0254 meters"
let threeFeet = 3.ft
println("Three feet is \(threeFeet) meters")
// prints "Three feet is 0.914399970739201 meters"

Em Ruby podemos facilmente fazer a mesma coisa diretamente porque classes são sempre abertas:

class Numeric
  def km; self * 1_000.0; end
  def m; self; end
  def cm; self / 100.0; end
  def mm; self / 1_000.0; end
  def ft; self / 3.28084; end
end

one_inch = 25.4.mm
puts "One inch is #{one_inch} meters"
three_feet = 3.ft
puts "Three feet is #{three_feet} meters"

Novamente, o resultado é similar mas os princípios são diferentes. A começar que no caso do Ruby estou abrindo a classe que é pai de todos os números, não só dos Floats (Doubles), caso contrário o segundo exemplo que é um Integer não funciona (“3.ft”, teria que ser explicitamente “3.0.ft”).

Além disso no Swift ele declara uma variável de processamento dinâmico. Nas semelhanças veja que tanto Swift quanto Ruby usam “self” para se referir ao objeto interno. Ambos permitem usar a notação de underline para delimitar milhares (“1_000”, por exemplo).

Um outro exemplo mais prático em Swift seria este:

extension Int {
    func repetitions(task: () -> ()) {
        for i in 0..self {
            task()
        }
    }
}

3.repetitions({
    println("Hello!")
    })
// Hello!
// Hello!
// Hello!

E em Ruby já temos o equivalente ao método “repetitions” desta extension já implementada:

3.times do
  puts "Hello!"
end

Em particular veja que o Swift define um método que recebe uma função anônima, um bloco propriamente dito. Ele passa esse bloco entre chaves como parâmetro do método. É o equivalente no Ruby que passamos o bloco também entre chaves ou entre “do; end”.

Outras coisas que lembram muito Ruby é como ele trata tipos de coleções:

var shoppingList = ["Eggs", "Milk"]
shoppingList += ["Chocolate Spread", "Cheese", "Butter"]
shoppingList[4...6] = ["Bananas", "Apples"]

Esse trecho quase que inteiramente se converte em como Ruby lida com arrays:

shopping_list = ["Eggs", "Milk"]
shopping_list += ["Chocolate Spread", "Cheese", "Butter"]
shopping_list[4...6] = ["Bananas", "Apples"]

O mesmo pode-se dizer de dicionários do Swift que são semelhantes a Hash no Ruby:

var airports = ["TYO": "Tokyo", "DUB": "Dublin"]
airports["LHR"] = "London"
for (airportCode, airportName) in airports {
    println("\(airportCode): \(airportName)")
}

Em Ruby seria:

airports = {TYO: "Tokyo", DUB: "Dublin"}
airports[:LHR] = "London"
for airport_code, airport_name in airports
  puts "#{airport_code}: #{airport_name}"
end

Em particular este último trecho, em Ruby, seria mais comumente escrito como:

airports.each do |airport_code, airport_name|
  puts "#{airport_code}: #{airport_name}"
end

A diferença é que Swift inicializa dicionários com a mesma sintaxe de arrays, com colchetes. Em Ruby diferenciamos arrays com colchetes e hashes com chaves. Além disso é comum usar chaves como strings em Swift e Objective-C pois eles são imutáveis por padrão. Em Ruby strings são tecnicamente mutáveis e o equivalente a uma “string imutável” em Ruby são symbols. Ao ser interpolado dentro de uma string, um symbol automaticamente se converte em string.

Já um tipo que Swift e outras linguagens como Python tem, e Ruby não tem, são Tuples. De forma simplificada, se trata de uma lista heterogênea (como um array) de constantes. Em Ruby usamos um Array para o mesmo fim. E temos, novamente, usos similares:

let http404Error = (404, "Not Found")
let (statusCode, statusMessage) = http404Error
println("The status code is \(statusCode)")
// prints "The status code is 404"
println("The status message is \(statusMessage)")
// prints "The status message is Not Found"

Veja que podemos decompor um Tuple de volta em variáveis de maneira similar em Ruby:

http_404_error = [404, "Not Found"]
status_code, status_message = http_404_error
puts "The status code is #{status_code}"
puts "The status message is #{status_message}"

Conclusão

Isso foi apenas um rápido “tour” sobre as partes mais superficiais da linguagem. Swift ainda tem:

  • tipos Enum (diferente de funcionalidades de Enumeration do Ruby, não confundir)
  • propriedades (getter, setter, weak references, etc)
  • inicialização, deinicialização, ARC (procedimentos para automatic reference counting)
  • tipos (type casting, nested types, generics, extensions, protocols)

Diferente de linguagens como Go ou Scala, ela não tem diretamente na linguagem nenhuma construção para abstrair atores ou outras coisas de concorrência. Isso porque no Objective-C e no Swift vamos subir para o nível dos frameworks, em particular para o Grand Central Dispatch que basicamente funciona como um sistema de filas de processamento.

Como podem ver, Swift em si é uma linguagem bem minimalista. Sua intenção é ser um “sugar coating” sobre a cansada sintaxe do Objective-C, a cansativa rotina de lidar com arquivos de header e implementação, declaração estática de tipos em todos os lugares. Mas o que a linguagem não tem como “consertar” é a extensiva quantidade de APIs do Cocoa. Não se engane, é tudo muito bem organizado e consistente, diferente de outras plataformas.

Por exemplo, hoje (1 dia depois do anúncio da linguagem, para verem como a sintaxe é trivial de simples) já saiu um pequeno demo que é basicamente um clone do famigerado Flappy Bird, usando o SpriteKit como fundação. E veja um trecho mais realista:

// skyline
var skyTexture = SKTexture(imageNamed: "sky")
skyTexture.filteringMode = SKTextureFilteringMode.Nearest

var moveSkySprite = SKAction.moveByX(-skyTexture.size().width * 2.0, y: 0, duration: NSTimeInterval(0.1 * skyTexture.size().width * 2.0))
var resetSkySprite = SKAction.moveByX(skyTexture.size().width * 2.0, y: 0, duration: 0.0)
var moveSkySpritesForever = SKAction.repeatActionForever(SKAction.sequence([moveSkySprite,resetSkySprite]))

for var i:CGFloat = 0; i < 2.0 + self.frame.size.width / ( skyTexture.size().width * 2.0 ); ++i {
    var sprite = SKSpriteNode(texture: skyTexture)
    sprite.setScale(2.0)
    sprite.zPosition = -20;
    sprite.position = CGPointMake(i * sprite.size.width, sprite.size.height / 2.0 + groundTexture.size().height * 2.0)
    sprite.runAction(moveSkySpritesForever)
    self.addChild(sprite)
}

Não é nada do outro mundo, só precisa se acostumar com as APIs. A documentação da Apple é muito bem feita e fácil de usar.

]]>linguagens-de-programacaoappleaprendizado[Off-Topic] Steve Jobs, The Lost Inverviewhttps://akitaonrails.github.io/2012/07/08/off-topic-steve-jobs-the-lost-inverview/https://akitaonrails.github.io/2012/07/08/off-topic-steve-jobs-the-lost-inverview/Sun, 08 Jul 2012 20:43:00 -0300<p>Quem acompanha o mundo Mac já deve ter visto que uma entrevista antiga, dada por Steve Jobs em 1995 e tida como perdida, apareceu numa fita VHS, foi restaurada e virou o documentário <em>Steve Jobs: The Lost Interview</em>. Agora dá para alugar no <a href="http://itunes.apple.com/us/movie/steve-jobs-the-lost-interview/id536749587"target="_blank" rel="noopener">iTunes Store</a>, entre outras fontes mais “geeky”, se preferir.</p> <p>Para quem já leu e assistiu tudo que saiu sobre Jobs, a maior parte dela não traz novidade. O interessante é ver ele mesmo dizendo essas palavras. Gostei de rever a forma como ele pensa sobre produtos, sobre gerenciar empresas e gerenciar pessoas, porque penso do mesmo jeito e gosto de trabalhar ao lado de quem também pensa assim.</p>Quem acompanha o mundo Mac já deve ter visto que uma entrevista antiga, dada por Steve Jobs em 1995 e tida como perdida, apareceu numa fita VHS, foi restaurada e virou o documentário Steve Jobs: The Lost Interview. Agora dá para alugar no iTunes Store, entre outras fontes mais “geeky”, se preferir.

Para quem já leu e assistiu tudo que saiu sobre Jobs, a maior parte dela não traz novidade. O interessante é ver ele mesmo dizendo essas palavras. Gostei de rever a forma como ele pensa sobre produtos, sobre gerenciar empresas e gerenciar pessoas, porque penso do mesmo jeito e gosto de trabalhar ao lado de quem também pensa assim.

Dito isso, vamos às palavras do próprio Steve Jobs:

Entrevista Perdida, faltando 37:15min

Entrevistador: O que sempre aparece é sua paixão, sua visão. Como você organiza suas prioridades? O que é importante para você no desenvolvimento de um produto?

Steve: (depois de longa pausa) Uma das coisas que machucou a Apple depois que eu saí foi que John Sculley pegou uma doença séria. E essa doença – e eu vi outras pessoas pegarem também – é a doença de pensar que uma grande ideia é 90% do trabalho. E se você simplesmente disser às pessoas “essa é a grande ideia”, então é óbvio que agora elas podem simplesmente e facilmente implementar essa idéia. E o problema com isso é que existe uma tremenda quantidade de habilidade e perícia (“craftsmanship”) entre uma grande idéia e um grande produto. E à medida que você evolui essa grande idéia, ela muda e cresce, nunca sai como você imaginou no começo, porque você aprende muito mais à medida que entra nas sutilezas.

Você também aprende que existem tremendos compromissos, “trade-offs” (escolhas entre o que é desejável e o que é possível), existem certas coisas que simplesmente não dá pra um elétron fazer, certas coisas que não dá para plástico fazer, ou vidro fazer, ou fábricas fazerem, robôs fazerem, e quando você vê tudo isso, desenvolver um produto é manter 5 mil dessas coisas em seu cérebro, esses conceitos, e encaixar todos eles juntos, continuar a empurrá-los, a encaixá-los juntos, de maneiras diferentes para fazer o que você quer. E todo dia você descobre alguma coisa nova, tem um novo problema ou uma nova oportunidade, você encaixa as coisas um pouco diferente, e é esse processo que é a mágica. Então tivemos várias grandes idéias quando começamos, mas o que eu sempre acreditei que é uma equipe de pessoas faz o que acredita é … (pausa, mudando pra próxima ideia pra explicar)

Quando eu era criança, havia um homem viúvo que vivia na rua de cima, e ele estava lá pelos seus 80 anos de idade, com aparência um pouco de dar medo, e eu o conheci um pouco – talvez tenha me pagado pra cortar a grama ou coisa assim – e um dia ele disse “venha até minha garagem, quero te mostrar uma coisa” e ele me mostrou esse velho tambor giratório de pedras, era um moldador, com uma lata de café, amarrado junto. Nós fomos pra trás e pegamos algumas pedras, pedras feias, normais, e colocamos no tambor, com um pouco de líquido, um pouco de areia, e fechamos a lata. Ele ligou o motor e ele disse “volte amanhã” e a lata ficou fazendo barulho enquanto as pedras rolavam. E eu voltei no outro dia, abrimos a lata, e retiramos essas maravilhosas pedras polidas, as mesmas pedras comuns, ficaram batendo umas nas outras, criando um pouco de fricção, criando um pouco de barulho, e saíram essas pedras polidas lindas. E essa tem sido, na minha mente, minha metáfora para uma equipe trabalhando realmente duro em alguma coisa pela qual tem paixão. É através da equipe, desse grupo de pessoas talentosas, esbarrando umas nas outras, discutindo, brigando às vezes, fazendo algum barulho, e trabalhando juntas, elas acabam se polindo, e eles polem as idéias, e o que sai são essas lindas pedras.

Então, é difícil explicar, e certamente não é o resultado de uma única pessoa, quero dizer, pessoas gostam de símbolos, eu sou um símbolo de certas coisas, mas realmente foi um trabalho de equipe no Mac. Agora, na minha vida eu observei algumas coisas desde cedo na Apple, que eu não sabia como explicar na época, mas pensei muito desde então. Muitas coisas na vida, a “distância dinâmica” entre a média e o melhor é de no máximo 2 para 1. Por exemplo, se estiver em Nova Iorque e comparar o taxista médio com o melhor taxista, você vai chegar ao seu destino com o melhor taxista talvez 30% mais rápido? Um automóvel, qual a diferença do médio pro melhor? Talvez 20%? O melhor tocador de CD e o médio? Não sei, 20%? Então 2 para 1 é uma enorme distância dinâmica na maior parte da vida. Em software – e costumava ser o caso em hardware – a diferença entre o médio e o melhor é 50 para 1, talvez 100 para 1. Ok? Muitas poucas coisas na vida são assim, mas onde eu tive sorte de gastar minha vida é assim. Então eu construí muito do meu sucesso encontrando pessoas assim, e não me acomodando em ficar com pessoas nível “C”, mas realmente procurando pelos nível “A”. E eu descobri uma coisa, descobri que se você tem suficientes níveis “A” juntos – e você tem um enorme trabalho pra encontrar 5 desses níveis “A” -, eles realmente gostam de trabalhar uns com os outros, porque nunca tiveram chance de fazer isso antes, e eles não querem trabalhar com níveis “B” e “C”, então eles se autopoliciam, só querem contratar mais níveis “A”, então você constrói esses grupos de níveis “A” e isso propaga. E é assim que a equipe Mac era. Eles eram todos nível “A”, eram pessoas extraordinariamente talentosas.

…

Entrevistador: O que significa quando você diz a alguém “seu trabalho é uma merda”?

Steve: Ah, normalmente significa “seu trabalho é uma merda”, algumas vezes significa “acho que seu trabalho é uma merda, mas posso estar errado”, mas normalmente significa “seu trabalho não está nem perto de ser bom o suficiente.”

Entrevistador: Tem uma citação de Bill Atkinson que diz que significa “eu não entendo bem o que significa, poderia explicar para mim?”

Steve: (risos) Não é normalmente o que eu quero dizer. Quando eu tenho pessoas boas, eles sabem que são realmente bons, e você não tem que ficar massageando o ego das pessoas demais, e o que importa é o trabalho. Todos sabem disso, é tudo que importa: o trabalho. Então contamos mesmo com essas pessoas para fazer pedaços específicos do quebra cabeça, e a coisa mais importante que eu posso fazer para uma pessoa que é realmente boa, e que realmente estamos contando, é apontar a elas quando seu trabalho não é bom o suficiente. E fazer isso bem claramente, articular o porquê, e trazê-los de volta aos trilhos. E você precisa fazer isso de uma maneira que não coloca em questão sua habilidade, mas que não deixe muito espaço para interpretação de que esse certo trabalho específico não foi feito de uma maneira boa o suficiente para suportar o objetivo da equipe. E isso é uma coisa difícil de fazer, e eu sempre usei uma forma bem direta. E se falar com as pessoas que trabalharam comigo, as pessoas realmente boas acharam que isso as beneficiou, mas algumas odiavam. E eu não me importo muito de estar certo, só me importo pelo sucesso. Vai encontrar muitas pessoas que vão dizer que eu tinha uma opinião muito forte e que elas apresentaram evidências do contrário e 5 minutos depois eu completamente mudei de idéia, porque eu sou assim: não me importo de estar errado, e eu admito que estive errado muitas vezes, mas isso não importa muito, o que importa é que fizemos a coisa certa.

Opinião Pessoal

Reforço por que cito esses trechos: o fato de Steve ter dito não faz nada disso virar verdade absoluta. Minha opinião é que a maioria das pessoas “average”, a minha odiada “média”, imagina as coisas da forma romântica, em que uma grande ideia já é a solução.

Mesmo nessa nova geração que se autointitula “empreendedores”, ainda reina a noção ridícula de que ter uma “grande ideia” é tudo, e que o resto, a implementação, é mero detalhe. Já vi gente querendo registrar a ideia, achando que precisa protegê-la. Todo mundo acha que a própria ideia vale alguma coisa.

Vou dizer da forma mais elegante que já ouvi, dita pelo meu sócio: uma ideia não implementada vale exatamente zero. E uma ideia que, ao ser ouvida, é facilmente replicada vale menos ainda, é lixo. Não tem talvez, nem meio talvez: uma ideia é vazia até ser implementada. Duvido que alguém tenha a cura do câncer na cabeça e “só falte implementar”.

A implementação de qualquer coisa que vale a pena, um produto, um serviço, o que for, é sempre difícil. Se fosse simples, qualquer um faria.

Isso tem uma consequência. Quando as pessoas a bordo, empregados, parceiros, colaboradores, têm orgulho do próprio trabalho e da própria habilidade, o dia a dia tende a ser de atritos, esbarrões, problemas e frustrações. E é assim mesmo, porque se trata de algo que vale a pena. Se fosse trivial, rotineiro e tranquilo, eu não teria vontade de fazer parte.

Brigamos porque nos importamos, discutimos porque queremos fazer melhor, temos atrito porque perseguimos um amanhã melhor do que o hoje. E de quem não tem essa paixão, essa ambição de ser melhor amanhã do que é hoje, sinceramente não sei nem por que acorda de manhã.

Eu sempre disse que “pessoas nível A contratam mais gente A, mas gente nível B contrata C, e os C contratam o lixo”. Não sei qual era a definição do Steve, mas, na minha, a pessoa nível “A” nunca é a tecnicamente mais habilidosa. A habilidade conta, só que está longe de ser o principal.

Alguém extremamente habilidoso que na hora “H” desaparece (o que eu chamo de “Ninja”, o cara que, quando o problema esquenta, joga a bomba de fumaça e some), em quem não dá para confiar, que não leva as próprias responsabilidades a sério, é nível “D”, ponto final. Já alguém com habilidade ainda não tão boa, por falta de experiência ou o que seja, mas que responde à altura dos desafios, não foge, não inventa desculpa, corre atrás com as próprias pernas e só para quando acha a solução, esse é nível “A”.

]]>appleengenharia-de-softwareoff-topic[Off-Topic] Comprei meu primeiro Mac, e agora? (Edição 2012)https://akitaonrails.github.io/2012/04/20/off-topic-comprei-meu-primeiro-mac-e-agora-edicao-2012/https://akitaonrails.github.io/2012/04/20/off-topic-comprei-meu-primeiro-mac-e-agora-edicao-2012/Fri, 20 Apr 2012 19:15:46 -0300<p>Um dos artigos mais lidos do meu blog é o <a href="http://akitaonrails.com/2009/07/19/off-topic-comprei-meu-primeiro-mac-e-agora"target="_blank" rel="noopener">Comprei meu primeiro Mac, e agora?</a>, que escrevi em Julho de 2009. Já atualizei ele uma vez e sempre achei que precisava atualizar de novo. O artigo inteiro, revisado, está no link acima. Para quem já leu, a seguir está só o que acrescentei hoje.</p> <p>Se você tem outras boas dicas, comente para compartilhar com todos. O foco aqui são usuários normais e Power Users, já que bons desenvolvedores sabem encontrar seu caminho sozinhos. Serve também para aquele amigo não-desenvolvedor que comprou um Mac e fica te perturbando toda hora com <em>“como faz isso? como faz aquilo?”</em>. Agora é só passar o link acima para o artigo inteiro :-)</p>Um dos artigos mais lidos do meu blog é o Comprei meu primeiro Mac, e agora?, que escrevi em Julho de 2009. Já atualizei ele uma vez e sempre achei que precisava atualizar de novo. O artigo inteiro, revisado, está no link acima. Para quem já leu, a seguir está só o que acrescentei hoje.

Se você tem outras boas dicas, comente para compartilhar com todos. O foco aqui são usuários normais e Power Users, já que bons desenvolvedores sabem encontrar seu caminho sozinhos. Serve também para aquele amigo não-desenvolvedor que comprou um Mac e fica te perturbando toda hora com “como faz isso? como faz aquilo?”. Agora é só passar o link acima para o artigo inteiro :-)

Aproveitem!

Edição 2012

  • Assim como no Windows e em outros sistemas, no Mac a velocidade de repetição do teclado vem configurada meio lenta por padrão. Abra qualquer editor de texto, use as setas para posicionar o cursor e vai notar como é demorado. Eu prefiro a velocidade no máximo: vá em “System Preferences, opção Keyboard”, deixe “Key Repeat” em “Fast” e “Delay Until Repeat” em “Short”. Você vai me agradecer:

  • Antes do Lion existia uma função para encriptar seus arquivos em tempo real, chamada FileVault, e ela era ruim o suficiente para ser ignorada. A partir do Lion surgiu o FileVault 2, completamente diferente e bom o bastante para virar item obrigatório. Abra “System Preferences, Security & Privacy”, aba “FileVault”, e habilite a encriptação total do seu HD. MUITO CUIDADO: ele vai gerar chaves de recuperação que permitem descriptografar os dados. Anote num local seguro e nunca perca. Uma dica é pegar seu iPhone ou qualquer smartphone com câmera e fotografar a tela quando ele exibir as chaves.

  • A partir do Lion existe o Mission Control, que você ativa colocando quatro dedos no touchpad e arrastando pra cima. Ele é o substituto do antigo Exposé e fica bem prático quando você se acostuma. Aplicativos “maximizados” viram seu próprio “Space” paralelo, e você navega entre eles arrastando três dedos no touchpad para a direita ou para a esquerda. O incômodo é a configuração padrão: os Spaces se rearranjam dinamicamente conforme o uso. Eu gosto de manter meus aplicativos e desktops sempre na mesma posição, então desabilito isso em “System Preferences, opção Mission Control”, na opção “Automatically rearrange spaces based on most recent use” (você ainda pode arrastar os Spaces para a ordem que preferir).

  • O Lion também mudou bastante a forma de salvar arquivos, com o novo recurso de “Auto Save”. Se acontecer um crash inesperado, se você precisar desligar a máquina no braço ou qualquer situação drástica dessas, não perde o que estava editando, porque o sistema salva sozinho. O incômodo é que o arquivo às vezes recebe um “Lock” que impede a edição. Dá para desbloquear manualmente, mas prefiro desligar isso em “System Preferences, Time Machine”, botão “options”, opção “Lock documents”. Aproveite a foto abaixo para ver onde fica e também o que eu coloco na lista de exclusão do Time Machine, coisas que prefiro não incluir no backup por não serem importantes (Software Images) ou por preferir fazer o backup na mão (iPhoto).

  • Ainda sobre a forma como o Lion lida com documentos e versões: nos aplicativos novos apareceu a opção “Save a version”, que grava momentos no tempo caso você precise voltar e recuperar algo feito antes. Pense nisso como um mini Time Machine, um backup granulado. Em compensação, o antigo “Save As”, que salvava o mesmo arquivo com outro nome, sumiu. Agora a operação é mais chata: primeiro “Duplicate” e depois “Save” (tudo no menu principal “File”) para gravar com outro nome. É chato no começo, mas vira rotina rápido.

  • O HomeBrew é o melhor instalador de softwares de código-livre como MySQL, PostgreSQL, Redis, Git, Android SDK e muito mais. Em alguns casos ele baixa direto o binário pra Mac, mas na maioria das vezes pega o código-fonte, aplica os patches necessários e compila. Para isso você precisa de compiladores e outras ferramentas, e a forma mais simples é baixar o XCode pela App Store. Esta dica é mais para desenvolvedores; se você não for, pode ignorar.

  • O Lion é a versão mais prática na hora de se recuperar de desastres. Acabou o DVD de boot: agora todo Mac tem uma partição escondida com o instalador, caso você precise reinstalar, checar discos e coisas assim. Basta dar boot segurando (Command-R) ⌘-R, ou segurar a tecla (Option) ⌥ durante o boot para abrir o menu de partições disponíveis e escolher “Recovery HD”.

Aplicações

Alguns dos aplicativos a seguir estão no Mac App Store, e recomendo sempre procurar por lá primeiro. Quando não estiverem, use os links e baixe manualmente. No fim da seção tem uma dica para manter tudo sempre atualizado.

  • Se tiver um iPad, dá para usá-lo como um segundo monitor ligado ao Mac via Wi-Fi (os dois precisam estar na mesma rede). Para isso, compre o programa Air Display.

  • Se tiver um novo Apple TV (o modelo pequeno preto), dá para espelhar a tela do iPhone 4S, iPad 2 ou superior via Wi-Fi usando o Air Play do iOS. A próxima versão do Mac, o Mountain Lion, vai permitir fazer o mesmo a partir do Mac. Até lá, você ainda pode espelhar o Mac numa HDTV via Apple TV comprando o Air Parrot. É a forma mais simples de assistir a filmes e vídeos do seu Mac direto na TV.

  • Eu gosto muito de ler os vários feeds RSS e Atom cadastrados na minha conta do Google Reader, e o melhor aplicativo para Mac e iOS é o Reeder.

  • Com tanto conteúdo na internet, você baixa muita coisa e nem sempre sabe quais arquivos estão consumindo mais espaço em disco. Para encontrá-los com facilidade (dica: na maioria das vezes são os vídeo podcasts no iTunes), existem ótimos aplicativos pagos como o DaisyDisk, mas eu ainda gosto do gratuito GrandPerspective.

  • O OS X sozinho dá conta de formatos comprimidos como zip e gz. Para descompactar formatos mais chatos como 7-zip e rar, instale o The Unarchiver.

  • A última dica é criar uma conta no MacUpdate e baixar o MacUpdate Desktop. De vez em quando abra o programa e ele mostra tudo que está desatualizado na máquina, deixando você escolher o que quer atualizar:

]]>appleprodutividadetutoriaisoff-topic[Off-Topic] Tributo a Steve Jobshttps://akitaonrails.github.io/2011/10/06/off-topic-tributo-a-steve-jobs/https://akitaonrails.github.io/2011/10/06/off-topic-tributo-a-steve-jobs/Thu, 06 Oct 2011 01:41:00 -0300<p><a href="http://www.apple.com/stevejobs"target="_blank" rel="noopener"><img src="http://s3.amazonaws.com/akitaonrails/assets/2011/10/6/the_hero_original.png?1317872992" alt="" loading="lazy" /></a></p> <p>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.</p>

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):

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

]]>applehistoria-da-computacaobiografiasoff-topic[Off-Topic] Disney, História do Computador e o Encarte Perdidohttps://akitaonrails.github.io/2011/09/25/off-topic-disney-historia-do-computador-e-o-encarte-perdido/https://akitaonrails.github.io/2011/09/25/off-topic-disney-historia-do-computador-e-o-encarte-perdido/Sun, 25 Sep 2011 02:41:00 -0300<p>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:</p> <p><img src="http://s3.amazonaws.com/akitaonrails/assets/2011/9/25/SCAN0001_original.png" alt="" loading="lazy" /> <img src="http://s3.amazonaws.com/akitaonrails/assets/2011/9/25/SCAN0024_original.png?1316928230" alt="" loading="lazy" /></p> <p>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.</p>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!

]]>historia-da-computacaoretrocomputacaoappleoff-topic[Objective-C] Distribuindo sua Static Libraryhttps://akitaonrails.github.io/2011/04/24/objective-c-distribuindo-sua-static-library/https://akitaonrails.github.io/2011/04/24/objective-c-distribuindo-sua-static-library/Sun, 24 Apr 2011 00:46:00 -0300<p>Se você não leu meus <a href="http://www.akitaonrails.com/2011/04/23/objective-c-it%27s-a-unix-system-i-know-this"target="_blank" rel="noopener">dois</a> <a href="http://www.akitaonrails.com/2011/04/23/objective-c-categories-static-libraries-e-pegadinhas"target="_blank" rel="noopener">últimos artigos</a>, recomendo fortemente que leia antes de continuar, porque vou usar o mesmo pet project, <a href="http://www.akitaonrails.com/2011/04/23/objective-c-it%27s-a-unix-system-i-know-this"target="_blank" rel="noopener">ObjC Rubyfication</a>, como exemplo neste artigo. A ideia é simples: você está escrevendo código reutilizável e quer aproveitar isso em mais de um projeto.</p> <p>A maior parte do que vou mostrar foi baseada no artigo do <a href="http://www.cocoanetics.com/2010/04/universal-static-libraries/"target="_blank" rel="noopener">Cocoanetics</a> sobre universal static libraries. Então, se você prestou atenção no <a href="http://www.akitaonrails.com/2011/04/23/objective-c-categories-static-libraries-e-pegadinhas"target="_blank" rel="noopener">artigo anterior</a>, viu este screenshot:</p> <!-- broken image (host offline/expired): http://s3.amazonaws.com/akitaonrails/assets/2011/4/23/Screen%20shot%202011-04-23%20at%2011.41.27%20PM_original.png --> <p>Eu disse que tinha apenas estes targets configurados: CocoaOniguruma, Kiwi, Rubyfication e RubyficationTests. Mas existem mais 3: CocoaOniguruma SIM, Rubyfication SIM e Build &amp; Merge Libraries. O motivo é simples:</p>Se você não leu meus dois últimos artigos, recomendo fortemente que leia antes de continuar, porque vou usar o mesmo pet project, ObjC Rubyfication, como exemplo neste artigo. A ideia é simples: você está escrevendo código reutilizável e quer aproveitar isso em mais de um projeto.

A maior parte do que vou mostrar foi baseada no artigo do Cocoanetics sobre universal static libraries. Então, se você prestou atenção no artigo anterior, viu este screenshot:

Eu disse que tinha apenas estes targets configurados: CocoaOniguruma, Kiwi, Rubyfication e RubyficationTests. Mas existem mais 3: CocoaOniguruma SIM, Rubyfication SIM e Build & Merge Libraries. O motivo é simples:

  • O Target “CocoaOniguruma” gera o binário libCocoaOniguruma.a, compatível com o processador ARM do iOS
  • O Target “CocoaOniguruma SIM” gera o binário libCocoaOnigurumaSimulator.a, compatível com o processador i386 do iPhone Simulator local
  • O Target “Rubyfication” gera o binário libRubyfication.a, compatível com o processador ARM do iOS
  • O Target “Rubyfication SIM” gera o binário libRubyficationSimulator.a, compatível com o processador i386 do iPhone Simulator local
  • O Target “Build & Merge Libraries” junta os binários específicos de cada target em um único Universal (Fat) Binary, fácil de distribuir e reutilizar.

Conceitos e História

Cabe uma explicação aqui. Quando você desenvolve aplicações iOS, pode testar diretamente no seu iPhone ou dentro do Simulator. Apple foi muito esperta nesse ponto: qualquer outro fabricante do mercado começaria criando um emulador de processador ARM para rodar em cima do seu i386. Aí pegaria os binários ARM e os executaria dentro desse emulador. O sistema operacional continuaria compilado para ARM, rodando dentro do emulador.

Só que isso é absurdamente lento, impraticável. Quem já experimentou um ambiente de emulação assim sabe o quanto é ridículo. E não confunda com soluções tipo VMWare ou Parallels, que são rápidas porque emulam o mesmo processador. Você consegue rodar Windows em cima do Mac porque os processadores e sistemas operacionais hoje suportam VT-x, ou seja, você quase não precisa emular o processador. Agora, todo smartphone e tablet do mercado usa processador ARM, que não tem nada a ver com i386.

Então, como a Apple entregou um emulador de iPhone/iPad super rápido que roda em tempo real no seu Mac? Simples: ela não entregou. Ele se chama “Simulator” e não “Emulator” por um motivo: tudo que roda dentro do Simulator é compilado para i386, e não para ARM. Ou seja, o que está rodando ali é um binário real, executando nativamente no seu Mac! Sem emulação alguma. O iOS é bem portável. Da mesma forma que o Mac OS X conseguiu fazer a transição do PowerPC para Intel lá em 2005, o iOS faz o mesmo truque, já que basicamente são o mesmo sistema operacional.

Quando você escolhe o scheme do iPhone no XCode, ele compila para ARM e sobe os bits no seu iPhone para rodar a aplicação. Quando você escolhe o scheme do Simulator no XCode, ele compila para i386, sobe os bits no Simulator e roda nativamente como qualquer outra aplicação no seu Mac.

Voltando ao ponto principal: quando eu distribuo um binário da minha Static Library, tenho que lembrar que o desenvolvedor vai linkar contra ela tanto para deploy no device ARM (iPhone/iPad) quanto no Simulator (i386). Ou seja, eu teria que entregar pelo menos 2 arquivos binários. Mas a Apple foi ainda mais esperta. Aliás, a NeXT foi. Quando eles fizeram a primeira transição do NeXTStep dos processadores Motorola para Intel lá no fim dos anos 80, criaram os Fat Binaries, que basicamente são um único binário contendo os bits específicos de cada processador num só pacote. Quando a Apple fez a transição do PowerPC para Intel, rebatizaram para Universal Binaries. E é exatamente isso que precisamos construir agora.

Operações

Já entendemos o que é um Universal Binary. Para facilitar, eu cliquei com o botão direito sobre os targets “Rubyfication” e “CocoaOniguruma” e dupliquei. Eles aparecem como “Rubyfication copy” e “CocoaOniguruma copy”. Podemos mudar o “Product Name” nas build settings de cada um para algo mais razoável:

No meu caso, renomeei para “RubyficationSimulator” e “CocoaOnigurumaSimulator”. Isso vai me dar tanto “libRubyficationSimulator.a” quanto “libCocoaOnigurumaSimulator.a”. Como dá para ver no grupo Products:

Importante: lembre que o target Rubyfication tinha o CocoaOniguruma como dependência. Você vai precisar mudar o target “Rubyfication SIM” para apontar para o novo target “CocoaOniguruma SIM”! Outra coisa: você precisa forçar os dois novos targets a compilar para “Latest Mac OS X” na opção “Base SDK" do Build Settings de cada um, e “32-bit Intel” na opção “Architectures”. Isso faz com que sejam compilados para processadores i386. Os targets originais devem ter o “Base SDK" em “Latest iOS” e “Architectures” em “Standard (armv6 armv7)”.

Agora precisamos criar um novo target do tipo “Aggregate”:

Eu chamei de “Build & Merge Libraries”. Na aba “Build Phases”, você começa apenas com a fase “Target Dependencies”. Basta adicionar os novos targets “Rubyfication SIM” e “CocoaOniguruma SIM”. Em seguida, adicione mais 3 fases: uma “Run Script”, uma “Copy Files” e mais uma “Run Script” no final.

Na fase “Copy Files” eu adicionei todos os public headers que quero distribuir junto com a universal binary library. O motivo é que outros desenvolvedores vão precisar adicionar esses headers nos próprios projetos para conseguir compilar contra a minha biblioteca. Repare que estou copiando para um “Absolute Path” definido como ${TARGET_BUILD_DIR}/../Rubyfication.

E é aí que entra a fase “Run Script” anterior, que deve ter o seguinte código:

# 1. cria uma nova pasta de saída
mkdir -p ${TARGET_BUILD_DIR}/../Rubyfication

# 2. combina os arquivos lib das várias plataformas em um só
lipo create "${TARGET_BUILD_DIR}/../Debug-iphoneos/libRubyfication.a" "${TARGET_BUILD_DIR}/../Debug-iphonesimulator/libRubyfication.a" -output "${TARGET_BUILD_DIR}/../Rubyfication/libRubyfication${BUILD_STYLE}.a"

A primeira coisa que ele faz é criar esse novo diretório “Rubyfication”. O segundo comando usa o lipo, que junta 2 binários dependentes de processador num único universal binary. Preste atenção nos PATHs se for reutilizar esse script em outro lugar. Pelo menos no XCode 4, é nesses caminhos que ele cria os binários de cada target:

  • ${TARGET_BUILD_DIR}/../Debug-iphoneos/libRubyfication.a – a versão ARM
  • ${TARGET_BUILD_DIR}/../Debug-iphonesimulator/libRubyfication.a – a versão i386
  • ${TARGET_BUILD_DIR}/../Rubyfication/libRubyfication-Debug.a – o universal binary resultante que criamos

Por fim, o último “Run Script”, depois da fase “Copy Files” descrita acima, precisa do seguinte script:

ditto c -k --keepParent "${TARGET_BUILD_DIR}/../Rubyfication" "${TARGET_BUILD_DIR}/../Rubyfication.zip"

–

Ele apenas cria um arquivo ZIP com a universal binary library e seus public headers companheiros. Qualquer outro desenvolvedor pode pegar esse zip, descompactar e adicionar os arquivos no próprio projeto. Se quiser saber onde esse ZIP foi parar, o jeito mais fácil é ir no project viewer (painel da esquerda) do XCode, abrir o grupo “Products”, clicar com botão direito no arquivo “libRubyfication.a” (ou qualquer outro arquivo gerado) e escolher “Show in Finder”. Daí navegue uma pasta acima na hierarquia (até a pasta “Products”) e você vai ver algo assim:

E pronto: aí está o seu ZIP com seu universal binary redistribuível novinho em folha!

Usando o Universal Binary

Para demonstrar como usar esse ZIP distribuível, eu criei um projeto iOS bem simples e enxuto chamado ObjC_OnigurumaDemo, que você pode baixar do Github e rodar no seu próprio device iOS.

Como dá para ver no screenshot abaixo, eu simplesmente descompactei o ZIP dentro de uma pasta “Dependencies” no meu projeto iOS e adicionei o universal binary “libRubyfication-Debug.a” na Library Linking Build Phase:

Isso me permite usar qualquer coisa dessa biblioteca no meu projeto, em particular um trecho de código que usa as expressões regulares do Oniguruma:

- (IBAction)runRegex:(id)sender {
    OnigRegexp* regex = [OnigRegexp compile:[regexPattern text]];
    OnigResult* res = [regex match:[initialText text]];
    NSMutableString* tmpResult = [NSMutableString stringWithString:@""];
    for(int i = 0; i < [res count]; i++) {
        [tmpResult appendString:@"("];
        [tmpResult appendString:[res stringAt:i]];
        [tmpResult appendString:@")"];
    }
    [result setText:tmpResult];
}

Essa aplicação de demonstração tem um text-field chamado “initialText”, onde você pode digitar qualquer string. Aí você prepara uma expressão regular no text-field “regexPattern” e, ao apertar o botão “Run”, ele dispara a action acima, que roda a expressão regular contra o texto inicial e escreve os matches entre parênteses na text view “result”. A aplicação fica assim:

E, voilá! Expressão regular ao estilo Ruby 1.9, direto do Oniguruma, dentro de uma aplicação iOS!

]]>appleprogramacaotutoriais[Objective-C] Categories, Static Libraries e Pegadinhashttps://akitaonrails.github.io/2011/04/23/objective-c-categories-static-libraries-e-pegadinhas/https://akitaonrails.github.io/2011/04/23/objective-c-categories-static-libraries-e-pegadinhas/Sat, 23 Apr 2011 23:44:00 -0300<p>Como alguns de vocês já sabem, eu tenho um pequeno pet project chamado <a href="https://github.com/akitaonrails/ObjC_Rubyfication"target="_blank" rel="noopener">ObjC Rubyfication</a>, um exercício pessoal de escrever uma sintaxe parecida com Ruby dentro de Objective-C. A maior parte do projeto se aproveita do fato de que dá pra reabrir as classes padrão do Objective-C – muito parecido com Ruby, diferente do Java – e inserir nosso próprio código – através de <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocCategories.html%23//apple_ref/doc/uid/TP30001163-CH20"target="_blank" rel="noopener">Categories</a>, que são parecidas com os módulos do Ruby.</p>Como alguns de vocês já sabem, eu tenho um pequeno pet project chamado ObjC Rubyfication, um exercício pessoal de escrever uma sintaxe parecida com Ruby dentro de Objective-C. A maior parte do projeto se aproveita do fato de que dá pra reabrir as classes padrão do Objective-C – muito parecido com Ruby, diferente do Java – e inserir nosso próprio código – através de Categories, que são parecidas com os módulos do Ruby.

A ideia desse pet project é ser uma Static Library que eu possa adicionar facilmente em qualquer outro projeto e ter todas as suas funcionalidades disponíveis. Nesse artigo eu queria mostrar como estou organizando os vários subprojetos dentro de um projeto só (e estou aberto a sugestões e dicas pra melhorar isso, já que ainda estou aprendendo a organizar as coisas dentro de projetos Obj-C) e falar sobre uma pegadinha que me tomou horas pra descobrir e que talvez ajude alguém.

Pra deixar esse exercício ainda mais divertido, eu também adicionei um target separado pra minha suíte de testes unitários (e ver como o XCode dá suporte a testes), depois outro target pro framework BDD Kiwi pra Obj-C, e mais um pro CocoaOniguruma que eu acabei de explicar no artigo anterior.

Eu venho brincando com formas de reorganizar o meu projeto e percebi que estava fazendo errado. Eu estava adicionando todos os arquivos fonte do meu target “Rubyfication” dentro do target Specs. Então tudo compilava direitinho, todas as specs passavam, mas a forma como eu definia as dependências estava errada. É meio complicado de entender no começo, mas deveria ser algo assim:

  • Target CocoaOniguruma: deveria ser uma static library, sem dependências de target e sem bibliotecas binárias pra linkar, apenas com uma dependência do framework Foundation padrão. Ele expõe os headers OnigRegexp.h, OnigRegexpUtility.h e oniguruma.h como public headers.
  • Target Kiwi: deveria ser outra static library, sem dependências de target e sem bibliotecas binárias pra linkar, apenas com as dependências dos frameworks Foundation e UIKit.
  • Rubyfication: deveria ser outra static library, com CocoaOniguruma como dependência de target, linkando contra o binário libCocoaOniguruma.a e dependendo do framework Foundation também. Ele expõe todos os seus arquivos .h como public headers.
  • RubyficationTests: deveria ser um Bundle criado junto com o target Rubyfication (você pode especificar se quer um target de testes unitários quando cria novos targets), com Kiwi e Rubyfication como dependências de target, linkando contra os binários libKiwi.a e libRubyfication.a, e os frameworks Foundation e UIKit também.

Se você ficar criando novos targets manualmente, o XCode 4 também vai criar um monte de Schemes que você nem precisa. Eu mantenho os meus limpos com apenas o scheme Rubyfication. Você pode acessar o menu “Product” e a opção “Edit Scheme”. Aí o meu Scheme fica assim:

Eu costumo configurar todos os meus build settings pra usar “LLVM Compiler 2.0” pras configurações de Debug e “LLVM GCC 4.2” pras configurações de Release (na verdade, eu faço isso por precaução porque não sei se o pessoal está realmente fazendo deploy de binários em produção compilados com LLVM).

Eu também configuro o “Targeted Device Family” pra “iPhone/iPad” e tento deixar o “iOS Deployment Target” em “iOS 3.0” sempre que possível. O pessoal normalmente deixa o padrão, que vai ser o release mais recente – atualmente 4.3. Cuidado porque o seu projeto pode não rodar em dispositivos mais antigos desse jeito.

Por fim, eu também garanto que os “Framework Search Paths” apontem pra estas opções:

"$(SDKROOT)/Developer/Library/Frameworks"  
"${DEVELOPER_LIBRARY_DIR}/Frameworks"

Tudo compila numa boa desse jeito. Aí eu posso apertar “Command-U” (ou ir no menu “Product”, opção “Test”) pra fazer o build do target “RubyficationTests”. Ele compila todas as dependências de target, linka tudo junto e roda o script final pra executar os testes (você precisa garantir que está selecionando o “Rubyfication – iPhone 4.3 Simulator” no menu de Schemes). Ele vai abrir o Simulator pra rodar as specs.

Mas aí eu estava recebendo:

Test Suite '/Users/akitaonrails/Library/Developer/Xcode/DerivedData/Rubyfication-gfqxbgyxicfpxugauehktilpmwzv/Build/Products/Debug-iphonesimulator/RubyficationTests.octest(Tests)' started at 2011-04-24 02:16:27 +0000  
Test Suite 'CollectionSpec' started at 2011-04-24 02:16:27 +0000  
Test Case '-[CollectionSpec runSpec]' started.  
2011-04-23 23:16:27.506 otest[40298:903] [__NSArrayI each:]: unrecognized selector sent to instance 0xe51a30  
2011-04-23 23:16:27.508 otest[40298:903] ***** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '[__NSArrayI each:]: unrecognized selector sent to instance 0xe51a30'

Ele diz que uma instância de NSArray não está reconhecendo o selector each: enviado pra ela no arquivo CollectionSpec. Provavelmente é esse trecho:

# import "Kiwi.h"  

# import "NSArray+functional.h"  

# import "NSArray+helpers.h"  

# import "NSArray+activesupport.h"

SPEC_BEGIN(CollectionSpec)

describe(@"NSArray", ^{  
 __block NSArray* list = nil;

context(@"Functional", ^{ beforeEach(^{ list = [NSArray arrayWithObjects:@"a", @"b", @"c", nil]; }); 

it(@"should iterate sequentially through the entire collection of items", ^{ NSMutableArray* output = [[NSMutableArray alloc] init]; 

[list each:^(id item) { [output addObject:item]; }];

[[theValue([output count]) should] equal:theValue([list count])]; });
…

Referência: CollectionSpec.m

Repare que na linha 3 está o import correto onde a category NSArray(Helpers) está definida com o método each: declarado certinho. O erro está acontecendo na spec da linha 18 do trecho acima.

Agora, isso não era um erro de compilação, era um erro de runtime. Então o import está achando o arquivo correto e compilando, mas algo na fase de linking não está indo bem e em runtime a category NSArray(Helpers), e provavelmente outras categories, não estão disponíveis.

Levou algumas horas de pesquisa, mas finalmente descobri uma flag simples que mudou tudo, a flag de linker -all_load. Como a documentação diz:

Importante: Para aplicações de 64-bit e iPhone OS, existe um bug no linker que impede o -ObjC de carregar arquivos de objeto de static libraries que contêm apenas categories e nenhuma classe. O workaround é usar as flags -all_load ou -force_load.

-all_load força o linker a carregar todos os arquivos de objeto de cada archive que ele encontra, mesmo aqueles sem código Objective-C. -force_load está disponível no Xcode 3.2 e posteriores. Ele permite um controle mais granular do carregamento de archives. Cada opção -force_load deve ser seguida por um caminho pra um archive, e cada arquivo de objeto naquele archive vai ser carregado.

Então todo target que depende de static libraries externas que carregam Categories tem que adicionar essa flag -all_load em “Other Linker Flags”, na categoria “Linking” dentro de “Build Settings” do target, assim:

Então tanto o meu target RubyficationTests quanto o Rubyfication tiveram que receber essa nova flag. E agora todos os testes passam sem problema!

]]>appleprogramacaotutoriais[Objective-C] É um sistema Unix! Eu sei mexer nisso!https://akitaonrails.github.io/2011/04/23/objective-c-e-um-sistema-unix-eu-sei-mexer-nisso/https://akitaonrails.github.io/2011/04/23/objective-c-e-um-sistema-unix-eu-sei-mexer-nisso/Sat, 23 Apr 2011 22:47:00 -0300<p>Enquanto experimentava formas de usar Objective-C de um jeito mais parecido com como eu programo em Ruby, duas coisas me incomodaram um pouco. Primeiro, formatação de datas e, segundo, expressões regulares.</p> <p>O framework Cocoa tem ambos implementados como <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DataFormatting/Articles/dfDateFormatting10_4.html%23//apple_ref/doc/uid/TP40002369-SW1"target="_blank" rel="noopener">NSDateFormatter</a> e <a href="http://developer.apple.com/library/iOS/#documentation/Foundation/Reference/NSRegularExpression_Class/Reference/Reference.html"target="_blank" rel="noopener">NSRegularExpression</a>, que por acaso também estão disponíveis para desenvolvimento iOS.</p> <p>Você pode formatar datas assim:</p> <div class="hextra-code-block hx:relative hx:mt-6 hx:first:mt-0 hx:group/code"> <div><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-objc" data-lang="objc"><span class="line"><span class="cl"><span class="n">NSDateFormatter</span> <span class="o">*</span><span class="n">dateFormatter</span> <span class="o">=</span> <span class="p">[[</span><span class="n">NSDateFormatter</span> <span class="n">alloc</span><span class="p">]</span> <span class="n">init</span><span class="p">];</span> </span></span><span class="line"><span class="cl"><span class="p">[</span><span class="n">dateFormatter</span> <span class="nl">setDateStyle</span><span class="p">:</span><span class="n">NSDateFormatterMediumStyle</span><span class="p">];</span> </span></span><span class="line"><span class="cl"><span class="p">[</span><span class="n">dateFormatter</span> <span class="nl">setTimeStyle</span><span class="p">:</span><span class="n">NSDateFormatterNoStyle</span><span class="p">];</span> </span></span><span class="line"><span class="cl"> </span></span><span class="line"><span class="cl"><span class="n">NSDate</span> <span class="o">*</span><span class="n">date</span> <span class="o">=</span> <span class="p">[</span><span class="n">NSDate</span> <span class="nl">dateWithTimeIntervalSinceReferenceDate</span><span class="p">:</span><span class="mi">162000</span><span class="p">];</span> </span></span><span class="line"><span class="cl"> </span></span><span class="line"><span class="cl"><span class="n">NSString</span> <span class="o">*</span><span class="n">formattedDateString</span> <span class="o">=</span> <span class="p">[</span><span class="n">dateFormatter</span> <span class="nl">stringFromDate</span><span class="p">:</span><span class="n">date</span><span class="p">];</span> </span></span><span class="line"><span class="cl"><span class="n">NSLog</span><span class="p">(</span><span class="err">`</span><span class="s">&#34;formattedDateString: %`&#34;</span><span class="p">,</span> <span class="n">formattedDateString</span><span class="p">);</span> </span></span><span class="line"><span class="cl"><span class="o">//</span> <span class="n">Saída</span> <span class="n">para</span> <span class="n">o</span> <span class="n">locale</span> <span class="nl">en_US</span><span class="p">:</span> <span class="s">&#34;formattedDateString: Jan 2, 2001&#34;</span> </span></span></code></pre></div></div><div class="hextra-code-copy-btn-container hx:opacity-0 hx:transition hx:group-hover/code:opacity-100 hx:flex hx:gap-1 hx:absolute hx:m-[11px] hx:right-0 hx:top-0"> <button class="hextra-code-copy-btn hx:group/copybtn hx:cursor-pointer hx:transition-all hx:active:opacity-50 hx:bg-primary-700/5 hx:border hx:border-black/5 hx:text-gray-600 hx:hover:text-gray-900 hx:rounded-md hx:p-1.5 hx:dark:bg-primary-300/10 hx:dark:border-white/10 hx:dark:text-gray-400 hx:dark:hover:text-gray-50" title="Copy code" > <div class="hextra-copy-icon hx:group-[.copied]/copybtn:hidden hx:pointer-events-none hx:h-4 hx:w-4"></div> <div class="hextra-success-icon hx:hidden hx:group-[.copied]/copybtn:block hx:pointer-events-none hx:h-4 hx:w-4"></div> </button> </div> </div> <p>E você pode usar expressões regulares assim:</p>Enquanto experimentava formas de usar Objective-C de um jeito mais parecido com como eu programo em Ruby, duas coisas me incomodaram um pouco. Primeiro, formatação de datas e, segundo, expressões regulares.

O framework Cocoa tem ambos implementados como NSDateFormatter e NSRegularExpression, que por acaso também estão disponíveis para desenvolvimento iOS.

Você pode formatar datas assim:

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];  
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];  
[dateFormatter setTimeStyle:NSDateFormatterNoStyle];

NSDate *date = [NSDate dateWithTimeIntervalSinceReferenceDate:162000];

NSString *formattedDateString = [dateFormatter stringFromDate:date];  
NSLog(`"formattedDateString: %`", formattedDateString);  
// Saída para o locale en_US: "formattedDateString: Jan 2, 2001"

E você pode usar expressões regulares assim:


NSError *error = NULL;  
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"\\b(a|b)(c|d)\\b"
 options:NSRegularExpressionCaseInsensitive  
 error:&error];

NSUInteger numberOfMatches = [regex numberOfMatchesInString:string  
 options:0  
 range:NSMakeRange(0, [string length])];

Mas eu tenho problemas com os dois. O equivalente em Ruby para o exemplo de formatação de datas seria:

require 'activesupport'  
date = Time.parse("2001-01-01") + 162000.seconds  
date.strftime("%b %d, %Y")

E o exemplo de expressão regular seria assim:


number_of_matches = /\W*[a|b][c|d]\W*/.match(string).size

Tem 2 coisas específicas que me incomodam:

  • as versões em Obj-C parecem desnecessariamente verbosas. Eu entendo que elas são de mais baixo nível e provavelmente permitem mais flexibilidade, mas acho que deveriam ter versões mais “porcelana”, mais diretas.
  • em Obj-C, a formatação de datas usa o padrão Unicode TR-35 e as expressões regulares usam o padrão ICU, que é inspirado nas expressões regulares de Perl com suporte a Unicode e vagamente baseado no java.util.regex do JDK 1.4.

Então, a solução ideal para mim seria:

  • ter versões de mais alto nível dessas funcionalidades;
  • ter formatação de datas com strftime compatível com C e expressões regulares no nível do Oniguruma do Ruby 1.9.

É um sistema Unix

Foi aí que me caiu a ficha do óbvio: Objective-C nada mais é que um superset de C, então qualquer coisa compatível com C é automaticamente compatível com Objective-C. Mais que isso, o iOS é um sistema Unix! Ou seja, ele tem todas as gostosuras do suporte Posix.

Então, como eu pego o strftime compatível com C? Fácil:

# import "time.h"  

…  

- (NSString*) toFormattedString:(NSString*)format {  
 time_t unixTime = (time_t) [self timeIntervalSince1970];  
 struct tm timeStruct;  
 localtime_r(&unixTime, &timeStruct);

char buffer[30]; 
strftime(buffer, 30, [[NSDate formatter:format] cStringUsingEncoding:[NSString defaultCStringEncoding]], &timeStruct); NSString* output = [NSString stringWithCString:buffer encoding:[NSString defaultCStringEncoding]]; 
return output;

}

Referência: NSDate+helpers.m

Agora siga cada linha pra entender:

  • Na linha 4 ele retorna o tempo atual representado como o número de segundos desde 1970. Esse método na verdade retorna um NSTimeInterval, que é um número essencialmente igual ao equivalente em C time_t
  • Na linha 6 a função C localtime_r converte o número unitTime na estrutura C timeStruct
  • Na linha 9 chamamos um método customizado que criei chamado formatter, que apenas devolve uma string de formato compatível com strftime. A string Obj-C (quando criamos com o símbolo “@”) é um objeto que precisamos converter para um array de chars usando cStringUsingEncoding:. Funções C não entendem string Obj-C, daí a conversão. Aí finalmente chamamos o próprio strftime, que vai armazenar o resultado no array de char buffer que declaramos antes.
  • Na linha 10 fazemos o caminho inverso e convertemos a C-string resultante (array de chars) de volta em uma String Obj-C.

Agora isso fica muito bom. Adicionei alguns outros métodos auxiliares que agora me permitem usar assim:

it(`"should convert the date to the rfc822 format", ^{
    [[[ref toFormattedString:`"rfc822"] should] equal:@"Fri, 01 Jan 2010 10:15:30"];  
});

Referência: DateSpec.m

E a string “rfc822” vai ser internamente convertida para @"%a, %d %b %Y %H:%M:%S" pelo seletor formatter: na classe NSDate.

Agora, pra ter expressões regulares no nível do Ruby 1.9 você pode ir direto na fonte e usar o próprio Oniguruma original baseado em C, exatamente o que o Ruby faz. Existem várias formas de integrar uma biblioteca C em um projeto Cocoa, mas alguém já fez todo o trabalho pesado. Satoshi Nakagawa escreveu um wrapper em Obj-C chamado CocoaOniguruma que torna a integração no seu projeto absurdamente fácil.

Existem várias formas de integrar uma biblioteca externa no seu projeto. A forma mais fácil (embora não exatamente a melhor) que mostro aqui é criando um novo Static Library Target dentro do meu projeto, chamado CocoaOniguruma:

Isso vai criar um novo Group chamado CocoaOniguruma no seu projeto. Depois é só adicionar todos os arquivos da pasta core do CocoaOniguruma nesse grupo, selecionar o novo target e todos os arquivos fonte e headers serão devidamente adicionados ao projeto, assim:

Por fim, você precisa ir no target principal original da sua aplicação e adicionar tanto o novo target nas dependências de target quanto o binário .a na seção de linking de binários, assim:

Com tudo isso configurado, recomendo explorar o OnigRegexp.m e o OnigRegexpUtility.m, que são wrappers Obj-C para a biblioteca Oniguruma. O autor já deixou uma sintaxe bem ao estilo Ruby pra você usar.

Embrulhei esses helpers nas minhas próprias classes assim:

- (NSString*) gsub:(NSString*)pattern with:(id)replacement {  
 if ([replacement isKindOfClass:[NSString class]]) {  
 return [self replaceAllByRegexp:pattern with:replacement];
 } else if ([replacement isKindOfClass:[NSArray class]]) {  
 __block int i = -1;  
 return [self replaceAllByRegexp:pattern withBlock:^(OnigResult* obj) {  
 return [NSString*](replacement objectAtIndex:(++i));  
 }];
 }  
 return nil;  
}

- (NSString*) gsub:(NSString*)pattern withBlock:(NSString* (^)(OnigResult*))replacement {  
 return [self replaceAllByRegexp:pattern withBlock:replacement];  
}

Referência: NSString+helpers.m

O que agora me permite usar essa sintaxe mais agradável:

context(`"Regular Expressions", ^{
    it(`"should replace all substrings that match the pattern", ^{  
 [[[`"hello world, heyho!" gsub:`"h\\w+" with:`"hi"] should] equal:`"hi world, hi!"];  
 });

it(@"should replace each substrings with one corresponding replacement in the array", ^{ NSArray* replacements = [NSArray arrayWithObjects:@"hi", @"everybody", nil]; [[[`"hello world, heyho!" gsub:`"h\\w+" with:replacements] should] equal:@"hi world, everybody!"]; }); it(@"should replace each substring with the return of the block", ^{ [[[`"hello world, heyho!" gsub:`"h\\w+" withBlock:^(OnigResult* obj) { return @"foo"; }] should] equal:@"foo world, foo!"]; });
});

Referência: StringSpec.m

Se você está achando estranho um trecho de código Objective-C ter palavras-chave como context ou it, elas vêm do Kiwi, que constrói um framework de testes BDD ao estilo RSpec em cima do SenTesting Kit para desenvolvimento Objective-C, e que você definitivamente deveria conferir. Mas o código acima deve ser fácil de entender mesmo sem conhecer o Kiwi. Se você é desenvolvedor Ruby, provavelmente vai notar que a sintaxe tem certa semelhança com o que você já está acostumado.

Então, linkar com bibliotecas C padrão existentes ou até com bibliotecas C open source de terceiros é moleza pra esses casos simples, sem precisar recorrer a nenhum tunelamento de “Native Interface” entre máquinas virtuais ou qualquer outra encanação. Se você quer C, ele está aí pra você integrar e usar facilmente.

]]>appleprogramacaotutoriais[Off-Topic] iOS Development and Open Source Librarieshttps://akitaonrails.github.io/2011/03/26/off-topic-ios-development-and-open-source-libraries/https://akitaonrails.github.io/2011/03/26/off-topic-ios-development-and-open-source-libraries/Sat, 26 Mar 2011 15:59:00 -0300<p>I&rsquo;ve been following the evolution of iOS development, and it keeps getting easier to assemble a quality application. Apple just released iOS 4.3.1 and Xcode 4.0.1, and the new Xcode is a big step forward. I think this is the first major IDE to support Git as a first class citizen in the development workflow. Every serious IDE should do that, and any serious developer should be comfortable with Git by now.</p>I’ve been following the evolution of iOS development, and it keeps getting easier to assemble a quality application. Apple just released iOS 4.3.1 and Xcode 4.0.1, and the new Xcode is a big step forward. I think this is the first major IDE to support Git as a first class citizen in the development workflow. Every serious IDE should do that, and any serious developer should be comfortable with Git by now.

The new LLVM Compiler 2.0 is impressive and helps a lot in writing memory leak free applications. I don’t buy the “it is too difficult doing memory management” complaint, which usually just means “I’m too lazy and cheap”. Come on, there are thousands of quality apps for both OS X and iOS.

Memory management is a bit harder than leaning on a full featured generational garbage collector, but it’s nowhere near as hard as some people claim. Any reasonable developer can handle it with minimal effort.

The community keeps releasing great libraries that push productivity even further. Let me list a few of my favorites:

  • Flurry is the iOS equivalent of Google Analytics. Everything is trackable now: who is using your app, how they use it, which features get the most and least use, and in which regions. You feed that data back into the product to refine it. It ships SDKs for Java ME, Blackberry, Android, Windows Phone and iOS. You sign up, register your application, and get a unique application key that you hard code into the app. It is literally as easy as this:
#import "FlurryAPI.h"
...
- (void) applicationDidFinishLaunching:(NSNotification*) notice {
    [FlurryAPI startSession:@"your_unique_app_key"];
    ...
}

There are several other methods to count events, log page views, log exceptions and errors, and even location. Mandatory for every app.

  • ASIHTTPRequest handles the fact that most apps integrate with some web based back-end. Twitter, Facebook, LinkedIn, everything logs into some cloud service to grab information and collaborate. Cocoa Touch has a rich set of networking capabilities, but they sit at a lower level than most people want. Making background connections, tracking success or failure, triggering events and loading cues for the user, it all gets tedious. ASIHTTPRequest makes reliable connections to any web endpoint strikingly easy. The documentation is good enough and the code is even simpler:
- (IBAction)grabURLInTheBackground:(id)sender
{
    if (![self queue]) {
        [self setQueue:[[[NSOperationQueue alloc] init] autorelease]];
    }

    NSURL *url = [NSURL URLWithString:@"http://allseeing-i.com"]; ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; [request setDelegate:self]; [request setDidFinishSelector:@selector(requestDone:)]; [request setDidFailSelector:@selector(requestWentWrong:)]; [[self queue] addOperation:request]; //queue is an NSOperationQueue
}

- (void)requestDone:(ASIHTTPRequest *)request
{
    NSString *response = [request responseString];
}

- (void)requestWentWrong:(ASIHTTPRequest *)request
{
    NSError *error = [request error];
}

The library creates network queues, so you can fire as many requests as you want and it manages the queue in the background. There are use case examples in the documentation. You can skip the low level base classes and delegate all HTTP requests to it. Highly recommended.

  • TouchJSON: if you consume online HTTP data, you will probably get a JSON payload (another trend of the moment) that you need to parse into meaningful Objective-C objects. Objective-C is dynamic and flexible in its type system, so converting anything is easy. The parsing itself is tedious, and this library takes care of it. Use ASIHTTPRequest to connect to the server, and once it returns, parse the response blob like this:
- (void)requestDone:(ASIHTTPRequest *)request
{
    NSString *response = [request responseString];
    NSError *theError = NULL;
    NSDictionary *theDictionary = [NSDictionary dictionaryWithJSONString:response error:&theError];
}

Super easy. It deserializes a JSON string into a graph of Objective-C objects, and it goes the other way too, turning objects back into JSON so you can POST it somewhere or save it to a local file.

  • ShareKit rides the trend that every piece of app content should be shareable. Whenever your users share something with their friends, your app gets more visibility, which is great marketing. You want the app to share content through email, Twitter, Facebook and other social networks. The documentation is good, the views are all customizable, and it takes care of the boring details of logging into each service and making the connections. It is also extensible, so adding a new online service later is easy. Follow the installation instructions; in the end it comes down to adding a UIBarButtonItem like this:
[[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemAction
    target:self
    action:@selector(share)]

And adding the event handler code:

- (void)myButtonHandlerAction
{
    // Create the item to share (in this example, a url)
    NSURL *url = [NSURL URLWithString:@"http://getsharekit.com"];
    SHKItem *item = [SHKItem URL:url title:@"ShareKit is Awesome!"];

    // Get the ShareKit action sheet
    SHKActionSheet *actionSheet = [SHKActionSheet actionSheetForItem:item];

    // Display the action sheet
    [actionSheet showFromToolbar:navigationController.toolbar];
}

Can’t get easier than that.

  • simple-iphone-image-processing covers another important area: dealing with images. Every new smartphone has a camera, and it pays to leverage it. Snapping a picture and saving the file is just the start; you will often want to process the image to extract meaningful information.

Want to be inspired? Look at this Sudoku application demo built on this image processing library. You point the camera at any Sudoku printed in a newspaper, and the app parses the image, detects the grid, and builds a fully functional digital representation you can then solve with well known algorithms. How cool is that?

One caveat: the library is old, with its last commit from 2009, so I am not sure how it behaves on current iOS releases. The documentation is close to none, so you will have to dig through the source. I haven’t tried it myself; I’m adding it here as a note to run further experiments later.

  • cocos2d steps in when simple list based apps get boring and you want animation and interactivity. You can use Apple’s standard Core Graphics and Core Animation APIs, or go crazy with cocos2d. It is an OpenGL accelerated 2D API, so great effects are easy to build, and the cross platform wrappers let you carry the knowledge to other platforms. There are plenty of tutorials online, such as this Box2D data tool writeup, this cross platform engine, and more. Worth studying.

  • iPhone AR Kit is not entirely mature yet, I think, but plenty of apps already use it and it should evolve fast. The idea is to turn on the camera, process the image frames, and lay 2D or 3D animation on top, so the digital objects seem to interact with the real time background. Pair that with the device’s motion sensors (compass, gyroscope, accelerometer) and you can build genuinely impressive apps. Worth studying.

  • Kiwi and Gh-Unit: unfortunately, testing is not well understood or practiced in the Objective-C community. Many Rubyists who also write Objective-C are trying to bring over the practices we take for granted in Ruby, so I hope this helps. Cocoa and Xcode ship basic unit testing tools like SenTestingKit. Documentation is close to zero; you can read Apple’s official logic testing article and this blog post. The default tools are basic, so it is worth checking out other frameworks like Gh-Unit and Kiwi. Kiwi in particular looks impressive, following an RSpec-like syntax:

describe(@"Team", ^{
    context(@"when newly created", ^{
        it(@"should have a name", ^{
            id team = [Team team];
            [[team.name should] equal:@"Black Hawks"];
        });

        it(@"should have 11 players", ^{ id team = [Team team]; [[[team should] have:11] players]; });
    });
});

Both are worth checking out. We should push more testing technique and tooling into Objective-C development. We did it in Ruby land, and there is no reason we can’t do the same here.

That’s it for now. There are many more great libraries and tools out there, and iOS is evolving fast, so all of this is exciting to follow and practice. I hope to contribute back soon.

]]>mobileappleprogramacaooff-topic[Documentário] The iPod Revolutionhttps://akitaonrails.github.io/2011/01/30/documentario-the-ipod-revolution/https://akitaonrails.github.io/2011/01/30/documentario-the-ipod-revolution/Sun, 30 Jan 2011 12:23:00 -0200<p>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”.</p> <p>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.</p>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:

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.

]]>applehistoria-da-computacaooff-topic[Objective-C] Method Missing!https://akitaonrails.github.io/2010/12/06/objective-c-method-missing/https://akitaonrails.github.io/2010/12/06/objective-c-method-missing/Mon, 06 Dec 2010 02:55:00 -0200<p><strong>Obs:</strong> Código disponível no <a href="https://github.com/akitaonrails/ObjC_XmlBuilder"target="_blank" rel="noopener">Github</a></p> <p>Uma das funcionalidades mais interessantes do Ruby é sem dúvida o famoso <tt>method_missing</tt>. Graças a ele podemos enviar mensagens arbitrárias a um objeto e ainda assim fazer com que responda como queremos. Por exemplo, o seguinte código dará uma exceção:</p> <div class="hextra-code-block hx:relative hx:mt-6 hx:first:mt-0 hx:group/code"> <div><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-ruby" data-lang="ruby"><span class="line"><span class="cl"> </span></span><span class="line"><span class="cl"><span class="o">&gt;</span> <span class="n">obj</span> <span class="o">=</span> <span class="no">Object</span><span class="o">.</span><span class="n">new</span> </span></span><span class="line"><span class="cl"> <span class="o">=&gt;</span> <span class="c1">#&lt;object:0x0000010092ac60&gt;</span> </span></span><span class="line"><span class="cl"><span class="o">&gt;</span> <span class="n">obj</span><span class="o">.</span><span class="n">foo</span> </span></span><span class="line"><span class="cl"><span class="ss">NoMethodError</span><span class="p">:</span> <span class="n">undefined</span> <span class="nb">method</span> <span class="sb">`foo&#39; for #&lt;object:0x0000010092ac60&gt; </span></span></span><span class="line"><span class="cl"><span class="sb"> from (irb):2 </span></span></span><span class="line"><span class="cl"><span class="sb"> from /Users/akitaonrails/.rvm/rubies/ruby-1.9.2-p0/bin/irb:17:in `</span><span class="o">&lt;</span><span class="n">main</span><span class="o">&gt;</span><span class="err">&#39;</span> </span></span><span class="line"><span class="cl"><span class="o">&lt;</span><span class="sr">/object:0x0000010092ac60&gt;&lt;/o</span><span class="ss">bject</span><span class="p">:</span><span class="mh">0x0000010092ac60</span><span class="o">&gt;</span></span></span></code></pre></div></div><div class="hextra-code-copy-btn-container hx:opacity-0 hx:transition hx:group-hover/code:opacity-100 hx:flex hx:gap-1 hx:absolute hx:m-[11px] hx:right-0 hx:top-0"> <button class="hextra-code-copy-btn hx:group/copybtn hx:cursor-pointer hx:transition-all hx:active:opacity-50 hx:bg-primary-700/5 hx:border hx:border-black/5 hx:text-gray-600 hx:hover:text-gray-900 hx:rounded-md hx:p-1.5 hx:dark:bg-primary-300/10 hx:dark:border-white/10 hx:dark:text-gray-400 hx:dark:hover:text-gray-50" title="Copy code" > <div class="hextra-copy-icon hx:group-[.copied]/copybtn:hidden hx:pointer-events-none hx:h-4 hx:w-4"></div> <div class="hextra-success-icon hx:hidden hx:group-[.copied]/copybtn:block hx:pointer-events-none hx:h-4 hx:w-4"></div> </button> </div> </div> <p>Agora, podemos redefinir o método <tt>method_missing</tt> do <tt>Object</tt> e veja o que acontece:</p>Obs: Código disponível no Github

Uma das funcionalidades mais interessantes do Ruby é sem dúvida o famoso method_missing. Graças a ele podemos enviar mensagens arbitrárias a um objeto e ainda assim fazer com que responda como queremos. Por exemplo, o seguinte código dará uma exceção:


> obj = Object.new  
 => #<object:0x0000010092ac60>
> obj.foo
NoMethodError: undefined method `foo' for #<object:0x0000010092ac60>
 from (irb):2
 from /Users/akitaonrails/.rvm/rubies/ruby-1.9.2-p0/bin/irb:17:in `<main>'
</object:0x0000010092ac60></object:0x0000010092ac60>

Agora, podemos redefinir o método method_missing do Object e veja o que acontece:


> def method_missing(method, *args)  
> "#{method}:#{args.size}"  
> end

> obj.foo  
=> "foo:0"

> obj.foo(1,2,3)  
=> "foo:3"

Este foi um resumo rápido, recomendo que se ainda não estiver familiarizado com esse conceito leia meu Micro-Tutorial de Ruby – Parte II onde eu explico isso em mais detalhes.

Um exemplo que gosto de usar é a classe Builder::XmlMarkup. Diferente de plataformas que fazem ou concatenação manual de Strings (péssimo) ou manipulação burocrática de nós (DOM), em Ruby temos essa excelente classe que minimiza a quantidade de código e ao mesmo tempo gera XML bem formatado e válido. Este é um exemplo:

require 'builder'  
x = Builder::XmlMarkup.new(:target => $stdout, :indent => 1)  
x.html do |h|  
 h.body do |b|  
 b.h1 "Hello World"  
 b.p "This is a paragraph."  
 b.table do |t|  
 t.tr do |tr|  
 tr.td "column"  
 end  
 end  
 end  
end

Esse código irá gerar diretamente este XML:


# Hello World

This is a paragraph.

| column |

Se nunca tinha visto isso, pare por um segundo e contemple a beleza desta API. A partir do objeto XmlMarkup enviamos mensagens como html e ele vai acumulando as tags. Usamos blocos exatamente para blocos de XML, garantindo que eles terão as tags corretas de fechamento.

Pensando nisso, resolvi tentar fazer algo semelhante em Objective-C. A funcionalidade que permite esse tipo de API no Ruby é o method_missing, algo que imaginamos que somente linguagens dinâmicas conseguem ter. Porém, ao final deste artigo, quero fazer este código funcionar:

XmlBuilder* xml = [[XmlBuilder alloc] init];  
[xml htmlBlock:^(XmlBuilder* h) {  
 [h bodyBlock:^(XmlBuilder* b) {  
 [b h1:`"Hello World"];
        [b p:`"This is a paragraph."];  
 [b tableBlock:^(XmlBuilder* t) {  
 [t trBlock:^(XmlBuilder* tr) {  
 [tr td:@"column"];  
 }];  
 }];
 }];  
}];

É bem mais verbose do que Ruby, obviamente, mas ainda assim bem mais interessante do que o jeito de manipular DOMs com métodos como createElement, appendElement, etc. De uma certa maneira dá pra ficar bastante semelhante à versão em Ruby. Mas como isso é possível?

Antes de continuar, leia meu artigo sobre Categorias e Blocos pois este artigo usará blocos.

Seletores

Recapitulando, em Ruby, quando chamamos um método de um objeto, por exemplo:

obj.foo("Hello World")

Na realidade podemos dizer que estamos “enviando a mensagem :foo ao objeto ‘obj’” ou seja, seria o mesmo que:


obj.send(:foo, "Hello World")

Em Obj-C temos algo semelhante. Quando fazemos:


[obj foo:@"Hello World"];

Seria o equivalente a fazer:


[obj performSelector:`selector(foo:) withObject:`"Hello World"];

A diferença é que em Ruby temos Symbols e em Obj-C temos Selectors, que é semelhante, uma forma de não desperdiçar espaço com Strings. Porém, selectores são mais do que apenas métodos: eles representam o nome do método e seus atributos que em Obj-C são nomeados. Por exemplo, um método foo, com dois argumentos, poderia ser assim:

- (void) foo:(NSString*)bar value:(NSString*)xyz;

Esse método seria enviado ao objeto assim:

[obj foo:`"Hello" value:`"World"];

E seu seletor seria assim:

SEL t = @selector(foo:value:);

Se o método tivesse apenas o primeiro argumento (que não tem nome), o seletor seria assim: foo: – note o “:” no final. Se não tiver nenhum argumento, não tem nenhum “:”. Isso é importante não confundir. Alguns erros podem passar em branco pela falta desse “:” na hora de montar o seletor.

Agora, quando se envia uma mensagem a um objeto e o método correspondente não está implementado, o Obj-C fará duas coisas: primeiro vai chamar o método methodSignatureForSelector:, que devolve um objeto NSMethodSignature. Em seguida vai criar um objeto NSInvocation a partir disso e passará como argumento ao método forwardInvocation:. Este último é quem mais ou menos faz o papel do method_missing de Ruby.

Na realidade, em Obj-C essa técnica é chamada de Message Forwarding. O objetivo na realidade é criar objetos que são Proxy para outros objetos. Nesse caso o framework facilita as coisas para passar mensagens que realmente existem no objeto de destino.

O pseudo-código seria mais ou menos assim:

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {  
 return [anotherObject methodSignatureForSelector:aSelector];  
}

- (void)forwardInvocation:(NSInvocation *)anInvocation {  
 [anotherObject performSelector:[anInvocation selector]];  
}

Os métodos são chamados nessa sequência mesmo. No primeiro ele consegue a assinatura do método no objeto destino com o método methodSignatureForSelector. A assinatura é um array que representa o tipo do valor de retorno e os tipos dos argumentos. Essa assinatura é usada em conjunto com o seletor para criar o NSInvocation. Daí no segundo método o seletor é enviado ao objeto de destino, sendo assim executado.

Se precisar criar Proxies ou Adapters, esse é o padrão para fazê-lo.

Proxy Dinâmico

O problema é que o padrão anterior pressupõe que o objeto de destino possui os métodos definidos a partir dos quais podemos extrair suas assinaturas. Porém, no nosso caso queremos um objeto que aceite qualquer tipo de mensagem representando tags arbitrários de um XML.

Para começar, quero definir uma classe chamada XmlBuilder e as variáveis internas que vão acumular o XML e controlar o nível de indentação:

# import <Foundation/Foundation.h>

@interface XmlBuilder : NSObject  
{  
 NSMutableString* buffer;  
 int indentationLevel;  
}  
@property (retain) NSMutableString* buffer;  
@property (assign) int indentationLevel;  
@end

@implementation XmlBuilder  
@synthesize buffer, indentationLevel;  

- (id) init {  
 self = [super init];  
 if (self) {  
 self.buffer = [[NSMutableString alloc] init];  
 self.indentationLevel = 0;  
 }  
 return self;  
}

- (void) dealloc {  
 [buffer release];  
 [super dealloc];  
}  
…  
@end

Até aqui nada de mais, apenas definição de interface, implementação, propriedades, construtor e destrutor. Coisa padrão.

Agora a coisa começa a esquentar:

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {  
 // não importa o retorno porque não vamos usar essa assinatura  
 return [NSMethodSignature signatureWithObjCTypes:"v@:@"];  
}

Esta primeira versão de implementação não precisa se preocupar com a assinatura. Vamos usar uma convenção para extrair os argumentos e não precisamos de assinaturas, então apenas devolvemos uma genérica qualquer.

Para começar, quero entender mensagens mais ou menos desse tipo:

Convenção para métodos dinâmicos:


- (id) entity:(NSString*)value; - (id) entityBlock:(id (^)(id))block; */

Ou seja, mensagens assim:

[xml p:@"Hello World"];  
[xml tableBlock:^(XmlBuilder* t) { … }];

Agora, vamos definir o método principal:


- (void)forwardInvocation:(NSInvocation **)anInvocation {  
 // #1  
 NSString** method = NSStringFromSelector([anInvocation selector]);

// #2BOOL hasBlock = [method hasSuffix:@"Block:"]; method = [method stringByReplacingOccurrencesOfString:@"Block" withString:@""]; method = [method stringByReplacingOccurrencesOfString:@":" withString:@""]; // #3 int tabsLength = self.indentationLevel * 2; NSMutableString* tabs = [NSMutableString stringWithCapacity:tabsLength]; int i; for ( i = 0 ; i \< tabsLength; i ++ ) { [tabs appendString:@" "]; } …

Vamos ver até a metade do método:

  1. Primeiro extraímos o nome do seletor em forma de String para conseguirmos manipulá-lo
  2. Nesta primeira versão, por convenção, assumimos que se seletor terminar com “Block:” significa que receberemos um bloco como argumento. Em seguida limpamos isso no nome do seletor para ficar só o nome da tag. Por exemplo: “htmlBlock:” ficaria “html” apenas. Eu faço isso porque ainda não aprendi a identificar o tipo do argumento recebido, pois se eu puder identificar que recebi um bloco, não preciso da convenção (fica como um TODO).
  3. Aqui geramos uma String com espaços em branco representando o nível de identação atual do XML, para que o resultado final esteja bonito.
… if (hasBlock) { 
// #4 id (^block)(id); 
[anInvocation getArgument:&block atIndex:2]; 
// #5 [buffer appendFormat:`"%`\<%@\>\n", tabs, method]; 
self.indentationLevel = self.indentationLevel + 1; 
block(self); 
self.indentationLevel = self.indentationLevel – 1; 
[buffer appendFormat:`"%`\</%@\>\n", tabs, method]; } 
else { 
// #6 NSString* value; 
[anInvocation getArgument:&value atIndex:2]; [buffer appendFormat:`"%`\<%`>\n%`%`%`\n%`</%`\>\n", tabs, method, tabs, @" ", value, tabs, method]; }
}

Continuando a partir da metade do código:

  1. Se a convenção disser que existe um bloco, assumimos que ele foi passado como argumento no 3o ítem do array do NSInvocation. Por convenção o primeiro elemento desse array (0) é o self e o segundo (1) o método, portanto o 3o. elemento (2) é o equivalente ao primeiro argumento.
  2. Agora vem a sequência para criar a tag que abre o bloco, depois aumentamos o nível de identação para o bloco; daí chamamos o bloco passado passando nós mesmos como parâmetro; o bloco é executado e quando retorna podemos diminuir o nível de identação; finalmente criamos a tag que fecha o bloco.
  3. Caso não tenha sido passado um bloco então é uma tag simples com um valor simples dentro. Agora no 3o. elemento do array, em vez de esperar um bloco podemos esperar um String. Finalmente basta criar a tag com o valor String dentro e acertar a identação de acordo.

Fazendo isso, podemos agora fazer chamadas assim:

int main (int argc, const char * argv[]) {  
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

XmlBuilder* xml = [[XmlBuilder alloc] init]; [xml htmlBlock:^(XmlBuilder* h) { [h bodyBlock:^(XmlBuilder* b) { [b h1:@"Hello World"]; 

[b p:@"This is a paragraph."]; 
[b tableBlock:^(XmlBuilder* t) { [t trBlock:^(XmlBuilder* tr) { [tr td:@"column"]; }]; }]; }]; }]; 
NSLog(`"%`", [xml buffer]); [pool drain]; return 0;
}

Impressionantemente, se abrirmos o Console (Shift+Command+R) ao executar teremos exatamente esta saída do comando NSLog:


# Hello World

This is a paragraph.

| column |

Que é o que queríamos e é semelhante ao gerado pelo equivalente Builder::XmlMarkup do Ruby. Claro, esta é uma versão hiper-simplificada, mas que pode ser o esqueleto para uma versão completa. O próximo passo é fazer a classe aceitar atributos de tags. E outra coisa é ver se é possível não precisar da convenção de “tableBlock:” para identificar se o argumento passado é um bloco e checar se é possível verificar o tipo do argumento passado em tempo de execução.

De qualquer forma, com isso podemos ver o quanto o Obj-C pode ser dinâmico e flexível mesmo em se tratando de uma linguagem de baixo nível como é C. Com um pouco de criatividade podemos criar bibliotecas que lembram em muito o que usamos em Ruby.

]]>appleprogramacaotutoriais[Objective-C] Brincando com Categorias e Blocoshttps://akitaonrails.github.io/2010/11/28/objective-c-brincando-com-categorias-e-blocos/https://akitaonrails.github.io/2010/11/28/objective-c-brincando-com-categorias-e-blocos/Sun, 28 Nov 2010 18:58:00 -0200<p>Continuando meus estudos com Objective-C, existem algumas funcionalidades que me deixam realmente surpreso. Duas delas são Categorias e Blocos.</p> <p>Para facilitar, vamos ver um código Ruby para dar um exemplo do que quero fazer:</p> <div class="hextra-code-block hx:relative hx:mt-6 hx:first:mt-0 hx:group/code"> <div><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-ruby" data-lang="ruby"><span class="line"><span class="cl"><span class="k">class</span> <span class="nc">Array</span> </span></span><span class="line"><span class="cl"> <span class="k">def</span> <span class="nf">each_element</span> </span></span><span class="line"><span class="cl"> <span class="k">for</span> <span class="n">elem</span> <span class="k">in</span> <span class="nb">self</span> </span></span><span class="line"><span class="cl"> <span class="k">yield</span><span class="p">(</span><span class="n">elem</span><span class="p">)</span> </span></span><span class="line"><span class="cl"> <span class="k">end</span> </span></span><span class="line"><span class="cl"> <span class="k">end</span> </span></span><span class="line"><span class="cl"><span class="k">end</span> </span></span></code></pre></div></div><div class="hextra-code-copy-btn-container hx:opacity-0 hx:transition hx:group-hover/code:opacity-100 hx:flex hx:gap-1 hx:absolute hx:m-[11px] hx:right-0 hx:top-0"> <button class="hextra-code-copy-btn hx:group/copybtn hx:cursor-pointer hx:transition-all hx:active:opacity-50 hx:bg-primary-700/5 hx:border hx:border-black/5 hx:text-gray-600 hx:hover:text-gray-900 hx:rounded-md hx:p-1.5 hx:dark:bg-primary-300/10 hx:dark:border-white/10 hx:dark:text-gray-400 hx:dark:hover:text-gray-50" title="Copy code" > <div class="hextra-copy-icon hx:group-[.copied]/copybtn:hidden hx:pointer-events-none hx:h-4 hx:w-4"></div> <div class="hextra-success-icon hx:hidden hx:group-[.copied]/copybtn:block hx:pointer-events-none hx:h-4 hx:w-4"></div> </button> </div> </div> <p>Sabemos que em Ruby, todas as classes podem ser abertas e extendidas, incluindo classes padrão da linguagem como Array ou String. Isso permite extender a própria linguagem e é o que o pacote ActiveSupport do Rails faz, ao adicionar métodos como <tt>#days</tt> à classe <tt>Fixnum</tt>, permitindo operações como <tt>2.days – 1.day</tt>, por exemplo.</p>Continuando meus estudos com Objective-C, existem algumas funcionalidades que me deixam realmente surpreso. Duas delas são Categorias e Blocos.

Para facilitar, vamos ver um código Ruby para dar um exemplo do que quero fazer:

class Array  
 def each_element  
 for elem in self  
 yield(elem)  
 end  
 end  
end

Sabemos que em Ruby, todas as classes podem ser abertas e extendidas, incluindo classes padrão da linguagem como Array ou String. Isso permite extender a própria linguagem e é o que o pacote ActiveSupport do Rails faz, ao adicionar métodos como #days à classe Fixnum, permitindo operações como 2.days – 1.day, por exemplo.

Em linguagens como Java isso não é possível porque as classes são fechadas, e inclusive muitas delas são finals o que impedem criar sub-classes a partir delas. Por exemplo, não se pode criar uma classe herdando de String. Isso acaba dando origem a muitas classes acessórias como StringUtils, o que eu acho particularmente não elegante.

No exemplo acima, reabri a classe padrão Array do Ruby e fiz minha própria versão do método each, que já existe, chamando-o de each_element somente com objetivos didáticos para este artigo. Agora podemos pegar um array normal e chamar esse método nele:


list = ["a", "b", "c"]  
list.each_element do |elem|  
 puts elem  
end

Mais do que extender classes, o Ruby possui outra funcionalidade muito flexível chamada blocos ou closures/fechamentos (eu já escrevi sobre blocos e closures antes pra RubyLearning. Sugiro ler para entender o conceito)

Essas são duas funcionalidades que muitos poderiam imaginar que só seriam possíveis em linguagens altamente dinâmicas como Ruby, Python ou Smalltalk. Já Objective-C é uma extensão da linguagem C, algo considerado por muitos como tão baixo nível que nem se imaginariam ser possível. Será?

Categorias

O Objective-C tem uma funcionalidade chamada Categories. Essencialmente isso permite “reabrir” classes já existentes e extendê-las com mais métodos.

Na minha interpretação o Obj-C, assim como Ruby, são linguagens orientadas a objeto mas, mais importante, eu diria que elas são orientadas a protocolo. Em vez de pensar em interfaces estáticas e “chamar um método” o correto é pensar em “enviar mensagens”. Protocolos definem quais mensagens o objeto sabe responder. A diferença é que você não busca uma coerência em tempo de compilação mas sim em tempo de execução. Você pode mandar mensagens que o objeto não entende se quiser sem receber um erro de compilação.

Uma convenção de nomenclatura que podemos usar é criar o arquivo header e a implementação usando o nome da classe a ser extendida, o símbolo “+”, e o nome da Categoria que queremos implementar. Por exemplo, digamos que eu queira a mesma funcionalidade do método each de Array do Ruby no equivalente NSArray do Obj-C, podemos fazer assim:

// NSArray+functional.h  
@interface NSArray (functional)

- (void) each:(void (^) (id))block;

@end

E a implementação seria:

// NSArray+functional.m

# import "NSArray+functional.h"

@implementation NSArray (functional)  

- (void) each:(void (^) (id))block {  
 int i;  
 for (i = 0; i < [self count]; i ++) {  
 block([self objectAtIndex:i]);  
 }  
}  
@end

A sintaxe é exatamente a mesma se estivéssemos definindo uma nova classe, mas neste caso declaramos o mesmo nome da classe que já existe NSArray e entre parênteses colocamos o nome da nossa categoria que, neste caso, chamei arbitrariamente de “functional” para ter diversos métodos funcionais.

Categorias não podem ter variáveis de instância entre chaves na declaração da interface, ela só pode comportar novos métodos, por isso falei que não era não flexível, mas isso já seria o bastante.

Essa funcionalidade pode ser usada principalmente para duas coisas: substituir a necessidade de criar sub-classes e, com isso, evitar usar herança sempre que possível e que fizer sentido; e a outra é quebrar classes com implementações muito grande em múltiplos arquivos de forma a melhor organizar os arquivos do projeto.

Blocos

Como vocês devem ter suspeitado, implementar o método each semelhante ao Ruby significa que deveríamos poder usar blocos. E o Obj-C também permite blocos, na forma de métodos anônimos (sem nome).

O parâmetro que implementamos é (void (^) (id))block. “block” é o nome da variável que vai receber o bloco. Seu tipo é de retorno “void” e parâmetro “id”. O “^” é o “nome” do bloco, no caso, sem nome algum, ou anônimo. Tendo em mãos o bloco podemos executá-la assim: block([self objectAtIndex:i]). O tipo id em Obj-C é um tipo genérico que denota um objeto arbitrário. Ele é usado por todo o framework Cocoa e seria, mais ou menos, o equivalente a dizer que o método recebe qualquer tipo de objeto.

E como podemos usar essa nova categoria com o novo método? Vejamos:

# import "NSArray+functional.h"

- (IBAction) foo:(id)sender {
 NSMutableArray *list = [NSMutableArray arrayWithObjects:";  
 [list each:^(id obj) {  
 NSLog(msg, obj);
 }];  
}

No caso, faça de conta que estamos numa aplicação de iPhone ou Mac, por isso criei um método que retorna IBAction. Para quem não sabe, IBAction é a mesma coisa que void, ou seja, que o método não retorna nada. A diferença é que o Interface Builder reconhece métodos que retornam IBAction como métodos que podem ser ligados diretamente a ações de um elemento visual na tela, por exemplo.

No corpo do método começamos criando um NSMutableArray. Fiz isso de propósito porque essa classe herda de NSArray e, portanto, também herdará o novo método each que implementamos.

Agora a parte importante é como chamamos o método nesse objeto: [list each:^(id obj) { … }]. Ou seja, estamos enviando a mensagem each ao objeto list passando como parâmetro um bloco anônimo “^” que tem parâmetro id obj. Se você não conhece blocos de Ruby ou de outra linguagem como Lisp, pode ser difícil entender o que está acontecendo, por isso recomendo novamente ler meu artigo sobre blocos antes.

Note que dentro do bloco o NSLog está usando a string msg que foi criada fora do bloco, exatamente como eu poderia fazer em Ruby, o bloco tem conhecimento do ambiente ao seu redor e eu posso usar variáveis criadas fora do bloco. Isso é uma das coisas que torna essa funcionalidade de blocos diferente de um simples “delegate” ou simplesmente passar um ponteiro de uma função.

Em Ruby, eu posso capturar um bloco em uma variável, assim:


bloco = lambda { |a| puts a }  
bloco.call("bla")

1. => "bla"

No exemplo acima, criamos um bloco e em seguida executamos esse bloco usando o método call. Em Obj-C podemos fazer algo similar assim:

void (^bloco)(NSString*) = ^(NSString* msg) {  
 NSLog(msg);  
};  
bloco(@"bla");

Veja que é muito parecido só que precisamos declarar os tipos. Na primeira linha definimos uma variável do tipo bloco, com o nome de “bloco” (o nome vem logo depois do “^”). Antes do nome temos o tipo de retorno, void, e depois o tipo do parâmetro que ele aceita, ponteiro de NSString. Daí criamos o bloco propriamente dito.

Em seguida basta chamar o bloco como se fosse uma função normal de C, usando a notação de passar parâmetros entre parênteses.

Conclusão

Categorias e Blocos podem ajudar muito a tornar a programação em Obj-C mais flexível e mais próxima dos conceitos de linguagens mais dinâmicas como Ruby. Como exercício que tal completar a minha Categoria NSArray+functional.h e acrescentar métodos como select, map, sort, etc? Coloquem links para Gist nos comentários com sugestões de implementação.

Para aprender mais sobre blocos, recomendo ler:

]]>appleprogramacaotutoriais[Objective-C] Entendendo NSAutoreleasePoolhttps://akitaonrails.github.io/2010/11/25/objective-c-entendendo-nsautoreleasepool/https://akitaonrails.github.io/2010/11/25/objective-c-entendendo-nsautoreleasepool/Thu, 25 Nov 2010 01:13:00 -0200<p>Ultimamente ando brincando de desenvolvimento iPhone e pra isso caí no Objective-C. Gosto muito da linguagem. Já conhecia um pouco do básico dele mas foi a primeira vez que comecei a codificar de verdade. Alguns podem não gostar da sintaxe ou de algumas das ferramentas (realmente o XCode não é completo nem robusto o suficiente, mas dá pro gasto). Mas no geral acho o fluxo de desenvolvimento bastante agradável.</p> <p>Logo de cara uma coisa que confunde os que sempre trabalharam com plataformas com Garbage Collector é o gerenciamento manual de memória. Vou me abster da discussão sobre se é melhor ou pior e os trade-offs. Na prática, é simples manter isso manualmente.</p>Ultimamente ando brincando de desenvolvimento iPhone e pra isso caí no Objective-C. Gosto muito da linguagem. Já conhecia um pouco do básico dele mas foi a primeira vez que comecei a codificar de verdade. Alguns podem não gostar da sintaxe ou de algumas das ferramentas (realmente o XCode não é completo nem robusto o suficiente, mas dá pro gasto). Mas no geral acho o fluxo de desenvolvimento bastante agradável.

Logo de cara uma coisa que confunde os que sempre trabalharam com plataformas com Garbage Collector é o gerenciamento manual de memória. Vou me abster da discussão sobre se é melhor ou pior e os trade-offs. Na prática, é simples manter isso manualmente.

Uma coisa que confunde no início é o NSAutoreleasePool. Todo projeto Cocoa começa com algo parecido com isto, no main.m:

int main(int argc, char *argv[]) {   
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
 int retVal = UIApplicationMain(argc, argv, nil, nil);  
 [pool release];  
 return retVal;  
}

O Obj-C trabalha com contagem de referência para limpar memória. Toda vez que se chama o método alloc ou new memória é alocada, um novo objeto é instanciado e seu contador sobe para 1. Toda vez se envia a mensagem retain a esse objeto o contador é incrementado, toda vez que se envia a mensagem release o contador é decrementado. Quando o contador chega a zero, o sistema pode destruir o objeto (chamando também seu método dealloc) e a memória é devolvida ao sistema.

O sistema devolve memória liberado ao sistema ao final de uma execução, mas existe um caso em específico que pode dar picos de consumo de memória antes do sistema ter chance de limpá-la. Veja este trecho:

- (IBAction) onClick:(id)sender {  
 int i;  
 for (i = 0; i \< 50000; i++) {  
 NSString * teste = [NSString stringWithFormat:`"Teste %i", i];
      NSLog(`"X: %@", teste);  
 }  
}

Imagine situações onde você está consumindo um stream de dados como de um arquivo, um web service, um parser, um tweet stream ou coisas assim, com cada ítem sendo processado em loop. Não é difícil sair criando milhares de Strings sem liberá-los.

No caso, estamos criando Strings usando o método stringWithFormat que, por convenção, devolve o String criado depois de ter já chamado o método autorelease. Explicando, você é responsável por criar e destruir objetos. Porém, quando você repassa um objeto que você criou para outro objeto, quem é o responsável por mandar release ao objeto?

Esse é o caso do stringWithFormat. Nesse caso não é nem a classe NSString nem nosso código que o chamou que vai liberar a memória ocupada por esse String. Quando você tem essa situação, em vez de mandar um release, deve enviar autorelease. Isso colocará o objeto no último NSAutoreleasePool criado. Os pools são empilháveis: os objetos sempre são colocados sob a responsabilidade do último pool criado.

Assim, como no main.m criamos um pool, os Strings serão todos colocados lá. Porém, eles serão apenas liberados depois do loop de 50 mil voltas. Por isso teremos um pico de consumo de memória até o término do loop. Dependendo do que está processando, você pode consumir toda a memória do sistema sem saber. Veja quando rodamos esse código num aplicativo via Instruments:

Note quanto de memória está sendo usada somente por CFString, mais de 1MB (!) Precisamos melhorar isso. E essa memória vai crescer quanto mais Strings forem criados dentro desse loop.

Esse padrão é fácil de identificar, basta procurar por loops que podem ser muito longos (centenas ou milhares de interações). Para “consertar” isso, podemos fazer o seguinte:

- (IBAction) onClick:(id)sender {
 int i;  
 // cria novo pool  
 NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];  
 for (i = 0; i \< 50000; i++) {  
 NSString * teste = [NSString stringWithFormat:`"Teste %i", i];
        NSLog(`"X: %@", teste);  
 if (i % 1000 == 0) {  
 // limpa o pool a cada mil interações  
 [pool release];  
 // cria um novo pool vazio  
 pool = [[NSAutoreleasePool alloc] init];  
 }  
 }  
 // limpa o último pool criado  
 [pool release];  
}

É o mesmo código, porém criamos um novo NSAutoreleasePool especialmente para os objetos criados pelo loop. Dentro do loop limpamos o pool depois de alguma certa quantidade de interações que faça sentido, no exemplo, a cada 1000 interações. Uma vez que o pool é liberado, criamos outro vazio para poder continuar o loop. E no final garantimos que estamos liberando o último pool criado.

Com isso o consumo de memória nunca passará de um certo teto bem mais baixo que o pico causado pelo exemplo anterior. Vejamos rodando esse novo código via Instruments:

Muito melhor! Não muito mais do que 100Kb. E esse consumo é constante e não crescente como antes, o que é mais importante. Mais do que consumir pouca memória é importante conseguir comportamentos onde o consumo não passe de um certo teto.

Esse é apenas um dos aspectos do gerenciamento de memória do Objective-C que é importante que os programadores se atentem. Vou fazer mais artigos sobre esse assunto, aguardem.

]]>performanceappleprogramacao