Entendendo Back-End para Iniciantes em Programação (Parte 1) | Série "Começando aos 40"

Entendendo Back-End para Iniciantes em Programação (Parte 1) | Série "Começando aos 40"

Introdução

Overview: Nesta introdução, Fabio Akita fala sobre o episódio anterior e a importância de entender o contexto das tecnologias. Ele também menciona que este episódio será sobre as tecnologias Back-end.

Tecnologia como ferramenta

  • As tecnologias são ferramentas criadas com um propósito específico.
  • Não existe uma única tecnologia que resolve todos os problemas.

O tamanho do Back-end

  • O Back-end é muito maior do que o Front-end.
  • Mesmo se ele tentar explicar tudo em um episódio de uma hora, não será possível cobrir tudo.

Qual linguagem aprender?

  • A pergunta mais comum quando se fala em programação back-end para Web é qual linguagem aprender?
  • Em episódios anteriores, Fabio Akita falou sobre a história das linguagens e como elas influenciaram umas às outras.

História da computação no Brasil

Overview: Nesta seção, Fabio Akita fala sobre a história da computação no Brasil antes dos anos 80 e como isso afetou o mercado de programadores.

Ditadura militar e reserva de mercado

  • Antes dos anos 80, o Brasil vivia sob uma ditadura militar e perdemos o timing da evolução dos transistores.
  • Não tínhamos um mercado decente de microprocessadores e nosso mercado era fechado a importações.
  • A reserva de mercado foi um erro.

Computadores nacionais

  • Havia computadores nacionais como os da Itautec e Microsiga que faziam clones de IBM PC.
  • Também havia computadores como os famosos Sinclairs e MSX.
  • A Unitron fazia clones de Apple II e chegou até mesmo a fazer um clone excepcional do Mac 512.

Sistemas operacionais nacionais

  • Havia sistemas operacionais nacionais como o Sisne, que era um clone de MS-DOS em português.

Experiência dos programadores

  • Programador no Brasil só se tornou uma carreira mainstream depois do advento da Web.
  • Por isso, há muito pouca gente realmente com décadas de experiência.

Linguagem Assembly

Overview: Nesta seção, Fabio Akita fala sobre a linguagem Assembly e seu papel na comunicação direta com a máquina.

Conjunto de instruções ou funções

  • Todo hardware, mais especificamente a CPU vem de fábrica entendendo um certo conjunto de instruções ou funções.
  • Eles têm registradores que é como se fosse um tipo de memória.

Assembly

  • A linguagem que usamos para falar diretamente com a máquina é Assembly.
  • Seu montador, o assembler, traduz o código escrito em texto com mnemônicos como JMP ou ADD ou MOV diretamente nas instruções binárias da máquina.

Syscalls ou chamadas de sistema

  • Além do hardware temos instruções específicas do sistema operacional, o que chamamos de syscalls ou chamadas de sistema.

Conclusão

Overview: Nesta seção final, Fabio Akita conclui o episódio falando sobre a importância da prática na programação e encorajando os espectadores a aprenderem a controlar a máquina que têm.

Aprender a programar

  • Você não precisa da máquina mais potente para aprender a programar, você precisa aprender a controlar a máquina que tem e tirar o absoluto máximo que ela pode dar.
  • Ninguém nunca vai dirigir bem uma Ferrari se sequer tem coordenação pra trocar marcha num Gol.

Programadores experientes

  • Mesmo hoje em dia, é muito raro encontrar programadores de cabelo branco.
  • Nos Estados Unidos você vê vários, incluindo famosos como os Uncle Bob da vida.

Escrevendo código Assembly e linguagens de programação

Nesta seção, o palestrante discute a dificuldade de escrever código Assembly diretamente e como as linguagens de programação modernas, como C, são mais eficientes e permitem que o mesmo código seja usado em diferentes CPUs.

Dificuldades do Assembly

  • Escrever código Assembly é chato, trabalhoso e ineficiente.
  • Programar para diferentes CPUs exige instruções diferentes.
  • O código escrito em Assembly é totalmente dependente da CPU usada.

Linguagens de programação modernas

  • As linguagens de programação modernas, como C, permitem que o mesmo código seja usado em diferentes CPUs.
  • O compilador faz otimizações para melhorar a eficiência do código na máquina.
  • O objetivo principal ao escrever um código deve ser torná-lo compreensível para outros humanos.

Bibliotecas e Linkers

Nesta seção, o palestrante discute bibliotecas reutilizáveis ​​e linkers. Ele explica as diferenças entre linkagem estática e dinâmica e os prós e contras de cada uma.

Bibliotecas reutilizáveis

  • Existem bibliotecas reutilizáveis ​​como LIBC no C e Boost no C++.
  • No Windows, as bibliotecas binárias são chamadas de DLLs e no Linux, a extensão é ponto SO.

Linkagem estática vs dinâmica

  • A linkagem estática mescla o binário do programa com o da biblioteca em um único arquivo.
  • A linkagem dinâmica usa um arquivo de cabeçalho para declarar quais funções estão expostas na biblioteca.
  • Ao copiar um binário para outra máquina, a biblioteca dinâmica também deve ser copiada.
  • Ambas as opções têm vantagens e desvantagens.

Compilação Estática vs Dinâmica

Nesta seção, o palestrante discute os prós e contras da compilação estática versus dinâmica.

Compilação Estática

  • Se você tem todo o código-fonte disponível e quer um binário que possa ser copiado sem preocupações com dependências, pode compilar tudo estaticamente.
  • Você só precisa do arquivo de cabeçalho que lista as funções da biblioteca.

Compilação Dinâmica

  • Se todos os programas estiverem linkados dinamicamente, basta recompilar apenas a biblioteca afetada por bugs ou atualizações.
  • Você não precisa ter o código-fonte das bibliotecas, apenas o arquivo de cabeçalho que lista suas funções.

Aprendendo a fazer escolhas em programação

Nesta seção, o palestrante fala sobre como a programação envolve fazer escolhas entre opções que não estão erradas e que é preciso saber o contexto. Ele compara isso com arte, onde não existe cor certa, mas sim saber usar a cor certa no lugar certo.

Escolhas em programação

  • Programação envolve fazer escolhas entre opções que não estão erradas
  • É preciso saber o contexto para tomar as decisões corretas
  • Assim como na arte, não existe uma resposta certa ou errada
  • O importante é saber usar a solução certa no lugar certo

Gerenciadores de pacotes em distribuições Linux

Nesta seção, o palestrante fala sobre os gerenciadores de pacotes nas distribuições Linux e como eles funcionam. Ele menciona alguns exemplos de gerenciadores de pacotes, como RPM e yum no Redhat e DEB e apt no Ubuntu.

Gerenciadores de pacotes em distribuições Linux

  • Na maioria das distribuições Linux há um gerenciador de pacotes
  • Exemplos incluem RPM e yum no Redhat, DEB e apt no Ubuntu
  • Em algumas situações pode ser necessário baixar um tarball para instalar um programa específico
  • Para instalar programas a partir do código fonte é necessário executar três comandos na linha de comando: ./configure, make e make install

Interpretadores vs Compiladores

Nesta seção, o palestrante fala sobre a diferença entre interpretadores e compiladores. Ele explica que um interpretador lê o código fonte e traduz em instruções para a máquina sem precisar compilar em binário nativo.

Interpretadores vs Compiladores

  • Um interpretador lê o código fonte e traduz em instruções para a máquina
  • Não é necessário compilar em binário nativo
  • O interpretador contém partes de um compilador, como o parser
  • O parser é responsável por ler o código e transformá-lo numa representação interna que pode ser executada pelo interpretador

Linguagens que usam interpretadores

Nesta seção, o palestrante fala sobre algumas linguagens de programação que usam interpretadores. Ele explica que essas linguagens dependem do código fonte e não precisam ser compiladas em binário nativo.

Linguagens que usam interpretadores

  • Algumas linguagens de programação dependem de um interpretador, como Perl, PHP, Python, Ruby e Javascript
  • Essas linguagens não precisam ser compiladas em binário nativo
  • O parser é usado para ler o código fonte e transformá-lo numa representação interna que pode ser executada pelo interpretador

Perl and Web Servers

In this section, the speaker talks about how to call Perl and the different options available. They also discuss servers and processes, including how UNIX handles processes differently from Windows.

Calling Perl

  • Two ways to call Perl:
  • By typing "perl" and passing the code file as an argument.
  • By turning on the execution flag directly in the code text file with a "shebang" line that includes the absolute path to the interpreter executable.
  • Another option is to create a package that embeds both the interpreter and source code representation into a single executable. This was possible with Perl and Visual Basic before version 6.

Servers and Processes

  • All operating systems handle processes, but creating them is cheaper in UNIX/Linux than in MacOS or Windows due to overhead requirements.
  • In UNIX, for example, a programmer would naturally create a program that can only serve one TCP client at a time. To serve multiple clients simultaneously, they would use FORK to create a copy of the running program in memory for each new connection.
  • The Apache web server initially used FORK exclusively. Later on, it gained the ability to execute programs depending on requested URLs through CGI standards.
  • The first workaround for not having to load interpreters every time was mod_perl and mod_php modules compiled within Apache that gave access to internal structures. However, this was insecure since bugs could give access to everything Apache had access to on the machine.
  • FastCGI was another workaround where an interpreter/server runs parallel with Apache or another web server. It keeps both active in memory so that multiple requests can be served without restarting every time.

UNIX vs. Windows

  • Windows does not have the FORK concept in its high-level system API, CreateProcess. Although the kernel of Windows allows something similar to FORK, it is not used as much and is still slower. This explains why early Apache versions were terrible on Windows compared to Linux, and why Microsoft's IIS was preferred over Apache.

Process and Threads

Nessa seção, o palestrante explica a diferença entre processos e threads, como eles funcionam na memória do computador e as vantagens e desvantagens de cada um.

Processos vs Threads

  • Processos com fork não estão obsoletos, mas hoje em dia usamos muito mais threads.
  • Um programa é executado pelo sistema operacional num espaço de memória isolado chamado processo. O sistema operacional tem o poder de matar ou pausar esse processo.
  • Cada processo pode ser clonado via fork no Linux. E cada processo pode rodar uma ou mais threads dentro dele.
  • Se é caro ou não é possível fazer forks, a única outra solução é dentro de um único processo iniciarmos múltiplas threads que são bem mais baratas que forks.

Memória Virtual

  • A memória virtual permite que todo mundo comece na página 1 da memória, mas o sistema operacional se encarrega de traduzir a página 1 da memória virtual do Excel para a página 100 da memória real.
  • Não existe memória isolada para cada thread dentro do processo. Dentro do processo, cada thread tem acesso a toda a memória virtual do processo.

Thread-Safety

  • Escrever programas que são multi-thread é uma dor de cabeça porque você precisa garantir o que chamamos de thread-safety ou seja código seguro pra rodar em threads.
  • Toda vez que você precisa escrever algum dado em memória, primeiro você notifica o sistema que vai escrever, pega o que chamamos de um lock, escreve e depois libera esse lock. Se falhar em pegar o lock, se arrisca a corromper a memória de outra thread.

Servidores Web

  • Um servidor web é um processo e para servir múltiplas requisições ele faz um fork pra cada uma.
  • Em Windows como forks são ordens de grandeza mais caros, o servidor web IIS precisa de outro truque e isso veio na forma do padrão ISAPI que é como se fosse um programa escrito pra CGI mas com modificações pra ser thread-safe e compilado dentro de uma biblioteca DLL que é carregado pelo IIS.

Introdução à programação multi-thread

Nesta seção, o palestrante introduz conceitos básicos de programação multi-thread e explica como a linguagem Java surgiu.

Conceitos básicos de programação multi-thread

  • O uso do lock é importante para evitar que outras threads interfiram no código em execução.
  • A programação multi-thread é considerada uma das coisas mais difíceis para um programador entender, competindo com gerenciamento de memória e segurança.

Surgimento da linguagem Java

  • Em 1991, a Sun criou uma nova linguagem chamada Oak com o objetivo inicial de ser um sistema para set-top-boxes.
  • A JVM (Java Virtual Machine) foi criada para abstrair a máquina real por baixo e permitir que programas escritos em Java rodem independentemente do sistema operacional ou processador.
  • A JVM compila o código fonte escrito em Java em bytecode intermediário que pode ser executado em qualquer tipo de computador ou sistema operacional que tenha uma JVM instalada.

Funcionamento da JVM

  • A JVM é como se simulasse um computador, abstraindo o sistema real por baixo.
  • A técnica JIT (compilador Just In Time) mede como o programa roda e otimiza em tempo real para binário nativo da máquina por baixo para ficar mais rápido.

Uso ideal do Java

Nesta seção, o palestrante explica qual é o caso de uso ideal do Java e como a JVM substitui o sistema operacional para gerenciar programas rodando em paralelo.

Uso ideal do Java

  • O caso de uso ideal do Java é rodar um único processo, sozinho na máquina, e seus programas rodam em paralelo dentro da JVM.
  • Cada programa precisa usar Threads para executar coisas em paralelo dentro dele.

Funcionamento da JVM

  • A JVM praticamente substitui o sistema operacional quando não roda mais nada além dela e dá todos os recursos da máquina para ela gerenciar.
  • A vantagem do Java compilar num binário intermediário de bytecode e rodar numa JVM é que eliminamos o problema de ter que ter compiladores para cada arquitetura de computador como Intel ou ARM.

Compilador JIT

Nesta seção, o palestrante explica como funciona o compilador JIT (compilador Just In Time).

Funcionamento do compilador JIT

  • O compilador JIT fica medindo como seu programa roda e otimiza em tempo real para binário nativo da máquina por baixo para ficar mais rápido.
  • É um meio termo entre um compilador AOT (Ahead of Time), como em C, e um interpretador.

Java vs. Interpreters

Neste trecho, o palestrante discute as diferenças entre a linguagem Java e interpretadores como Perl, Python, PHP e Ruby. Ele explica que em Java, praticamente tudo é escrito em Java e embutido dentro da JVM, enquanto os interpretadores dependem bastante do sistema operacional por baixo.

Diferenças entre Java e Interpretadores

  • Em Java, praticamente tudo é escrito em Java e embutido dentro da JVM.
  • Interpretadores como Perl, Python, PHP ou Ruby dependem bastante do sistema operacional por baixo.
  • Em vez de escrever uma biblioteca de criptografia toda em Python, ele simplesmente mapeia para o que o OpenSSL já instalado no sistema operacional oferece.
  • Interpretadores muitas vezes rodam em todos os sistemas operacionais mas algumas funcionalidades são diferentes ou têm qualidade inferior porque as mesmas dependências não existem em todos os sistemas operacionais.

Problemas com Interpretadores

  • Nunca faça programas complexos que rodam num interpretador no Windows esperando que vá funcionar igualzinho em Linux ou Mac.
  • Se vai codar em linguagens interpretadas como essas, prefira sempre Linux ou Mac.

A Promessa do Java

  • O Java nasceu com a promessa de permitir que você pudesse escrever programas que rodavam em qualquer lugar porque havia JVM para Linux, Solaris, Mac e Windows.
  • Por isso ele se popularizou tanto tão rápido.

A Diferença entre Java e .NET

  • Embora ambas sejam máquinas virtuais e os códigos compilem em bytecodes, o Java tinha como meta rodar no maior número de dispositivos quanto possível e o .NET só em Windows.

Bibliotecas nativas do Windows

Nesta seção, o palestrante explica como as bibliotecas nativas do Windows são usadas para gerar janelas nativas em aplicativos desktop, e como isso foi um dos maiores problemas para conseguir compatibilidade no Linux.

Uso de bibliotecas nativas do Windows

  • As bibliotecas para fazer aplicativos desktop usam bibliotecas nativas do Windows para gerar janelas nativas.
  • Isso foi um dos maiores problemas para conseguir compatibilidade no Linux.

Aquisição da Xamarin pela Microsoft

Nesta seção, o palestrante explica como a Microsoft se tornou mais amigável ao mundo open source e acabou comprando a empresa de Miguel De Icaza, a Xamarin. O Mono foi renomeado como .NET Core e hoje está em caminho de substituir o antigo .NET framework.

Aquisição da Xamarin pela Microsoft

  • Depois de muitos anos e com a troca de CEO com a saída de Steve Balmer e a entrada de Satya Nadella e sua política de boa vizinhança, a Microsoft se tornou finalmente mais amigável ao mundo open source.
  • A Microsoft acabou comprando a empresa de Miguel De Icaza, a Xamarin.
  • O Mono foi renomeado como .NET Core e hoje está em caminho de substituir o antigo .NET framework.

Diferenças entre linguagens compiladas

Nesta seção, o palestrante explica as diferenças entre linguagens compiladas de forma estática e dinâmica, o que são interpretadores e o conceito de máquinas virtuais e bytecodes. Também explica as diferenças de rodar coisas em paralelo com forks e com threads.

Diferenças entre linguagens compiladas

  • O palestrante explica as diferenças entre linguagens compiladas de forma estática e dinâmica.
  • Ele também explica o que são interpretadores e o conceito de máquinas virtuais e bytecodes.
  • Além disso, ele fala sobre as diferenças de rodar coisas em paralelo com forks e com threads.

Conclusão

Nesta seção, o palestrante conclui a apresentação explicando que os anos 90 foram um terreno para o crescimento do Java e .NET no mundo mais proprietário. Ele também menciona que estamos apenas começando o século XXI, deixando espaço para futuras discussões.

Conclusão

  • Os anos 90 foram um terreno para o crescimento do Java e .NET no mundo mais proprietário.
  • Estamos apenas começando o século XXI, deixando espaço para futuras discussões.
  • O palestrante encerra a apresentação incentivando os espectadores a enviar suas dúvidas nos comentários, curtir o vídeo, compartilhar com amigos, assinar o canal e clicar no sininho.
Video description

Este é o 5o episódio da série "Começando aos 40". Você deve assistir os episódios anteriores da série pra entender onde estamos e recomendo assistir os 2 vídeos da série "Sua Linguagem Não É Especial". No episódio de hoje vou começar a introduzir os conceitos básicos para o que chamamos de "back-end", que na prática é a própria introdução à programação. A intenção do vídeo não é serem aulas nem tutoriais, mas conectar os pontos de diversos assuntos que vocês vão encontrar de forma desconexa se sair pesquisando pelo Google. Se você fez faculdade, já deveriam saber tudo que vou dizer aqui, então veja o que faltou nos estudos e acelere! Em resumo, vou falar rapidamente sobre os conceitos mais simples, linguagem Assembly, compiladores, interpretadores, máquinas virtuais, bytecode, processos, forks, threads, tudo que qualquer programador tem obrigação de saber na ponta da língua e em paralelo vou passar rapidamente de novo pelos anos 90. Como o episódio ficou longo, eu dividi em 2 partes. Na de hoje vou só até o crash das ponto coms em 2001, e vamos continuar dali na Parte 2 da semana que vem. Links: * Playlist "Começando aos 40" (https://www.youtube.com/watch?v=O76ZfAIEukE&list=PLdsnXVqbHDUc7htGFobbZoNen3r_wm3ki) * Sua Linguagem Não É Especial Parte 1 (https://www.youtube.com/watch?v=p9-WuJbVHHc) * Sua Linguagem Não É Especial Parte 2 (https://www.youtube.com/watch?v=XcTTajFENHI) * Conheça a história (brasileira) da informática (https://keepgeek.wordpress.com/2010/08/01/conheca-a-historia-brasileira-da-informatica/) * Meet the Unitron Mac 512 – the World’s First Macintosh Clone (https://www.cultofmac.com/266710/meet-unitron-mac-512-worlds-first-macintosh-clone/) Canais Retro: * The 8-bit Guy (https://www.youtube.com/channel/UC8uT9cgJorJPWu7ITLGo9Ww) * Modern Vintage Computer (https://www.youtube.com/channel/UCjFaPUcJU1vwk193mnW_w1w) * LGR (https://www.youtube.com/user/phreakindee) Me sigam também em outras redes sociais: * Twitter (https://twitter.com/akitaonrails) * Instagram (https://instagram.com/akitaonrails) * Facebook (https://facebook.com/akitaonrails) * Quora (https://www.quora.com/profile/Fabio-Akita) * Blog (https://www.akitaonrails.com) * Transcript: https://www.akitaonrails.com/2019/02/20/akitando-40-entendendo-back-end-para-iniciantes-em-programacao-parte-1-serie-comecando-aos-40 * Audio: https://anchor.fm/dashboard/episode/eav9tl