Dia 13 — Saindo um pouco do Python e dando alguns passos para trás — parte 1
Eae gente?!
Fiquei esses últimos dias voltada para carreira, para o inglês e para outros tipos de leitura, e fiquei meio ausente daqui… estou tentando pegar o hábito de estudar inglês todo dia (e a cada dia que passa eu sinto que fica mais difícil falar esse raio desse idioma mas ok hahhahaha).
WELL… vocês vão ler o título e falar:
“Mi, que po**a é essa? C num tava estudando Python?”
Sim cara pálida… mas eu tenho um projeto de um BOT engavetado (lembra dele? Já falei bem pouquinho dele aqui)… isso + um evento do trabalho que participei semana passada (no qual assisti uma palestra sobre um cara que está fazendo um BOT para o messenger em nodeJS) + uma promoção no UDEMY (de um curso de NodeJS + MongoDB) + o curso do Mastertech que eu estou namorando há QUASE 2 ANOS + ver artigos de pessoas que fizeram um BOT em nodejs = me fizeram me afastar um tico do curso da UDACITY e começar esse da UDEMY… pois bem
Antes que o meu brother Yuri Teixeira me xingue, ainda não estou totalmente decidida, nem pelo SIM, e nem pelo NÃO de fazer esse raio desse curso do Mastertech (segundo meu brother, eu consigo aprender as coisas que tem na grade sozinha, o que eu particularmente duvido… veremos…)
Pois bem…
Eu até comecei o curso de nodeJS da UDEMY e comecei a ficar muito confusa (tiver que rever as aulas algumas vezes). Então cheguei a uma conclusão inevitável:
Amiga, tá na hora de você dar alguns passos para trás e entender o básico do negócio, não tá não??
Pois é… passou da hora na verdade… achei melhor procurar ler o básico da arquitetura de sistemas WEB e dessas arquiteturas modernas e tal, antes de começar qualquer curso (até porque convenhamos, se eu não entender isso, não adianta nada saber todas as linguagens web do mundo RYSOS)
Mas nossa Mi, você não conhece arquitetura de um sistema WEB? Você realmente trabalha na área?! RYSOS
Olha… eu conheço, mas não conheço. Vou explicar:
Trabalhei 2/3 da minha vida profissional com sistemas batch mainframe usando cobol, DB2, JCL… enfim, só coisa nova (RYSOS). Isso significa que nunca vivenciei na prática a realidade de se trabalhar em um sistema WEB (e logo, nunca precisei pensar em como implementar um bom sistema WEB).
Nos meus 3 últimos anos venho trabalhando como Hadoop, SAS, DB2 unix, mas não tão próxima do lado técnico (digamos que eu fico entre o negócio e a equipe de desenvolvimento, com um pé em cada área), então mesmo saindo do mainframe, ainda não me deparo no trabalho com muitas situações as quais eu precise entender, pensar “WEB”. E fazer isso tudo por conta própria é bem complicado.
Importante para quem tem amiguinhos coboleiros e/ou mainframeiros da alta plataforma: sair do paradigma da programação estruturada e batch e estudar WEB é MUITO difícil — o caminho contrário não é difícil, só é chato (pesquisa de mercado RYSOS)
Dando alguns passos para trás para poder evoluir
Ok, aceitei enfim que é preciso dar alguns passos para trás antes de colocar qualquer projeto ou curso na cabeça e entender como são as arquiteturas de sistemas mais modernos (isso é um GAP gigantesco na minha bagagem e ao mesmo tempo um baita desafio pra mim). Comecei uma pesquisa no nosso amigo google:
“como funciona a arquitetura cliente-servidor”
Já no primeiro link me deparei com conceitos de protocolos de comunicação da rede que eu aprendi, mas como não preciso pensar neles no meu dia-a-dia, não consegui me lembrar de absolutamente nada.
Aí fiz um desenho na minha lousa para guiar as minhas pesquisas:
Com base nele, comecei a pensar no que eu preciso entender da arquitetura de um sistema WEB. Antes de pesquisar os itens individualmente, joguei no google:
“arquitetura de sistemas distribuídos”
Achei um link muito legal que tem uma abordagem introdutória:
O post se trata do meu meu entendimento da leitura deste e de outros posts que fui pegando ao longo do dia:
Características:
- Compartilham recursos de hardware e software e, por isso, podem entrar em concorrência e são um mais complexos de gerenciar do que sistemas centralizados (na questão recursos, segurança, etc)
- Apresentam tolerância á defeitos
- Transparência = a natureza distribuída do sistema não é visível para o usuário
- Podem apresentar respostas imprevisíveis
Questões importantes quando se trata de um projeto de um sistema distribuído:
- Identificação de recursos
- Comunicação do sistema (o protocolo utilizado)
- Arquitetura do sistema
- Linguagem de programação do back-end
- Linguagem de programação do front-end
Quando falamos de arquitetura de sistemas distribuídos, estamos falando de cliente-servidor (seja ele um servidor físico seu, embaixo da sua mesa, ou um servidor cloud). E falando de cliente-servidor, estamos querendo dizer que sua aplicação vai disponibilizar uma série serviços através de um (ou vários) servidor, e os clientes da sua aplicação (de forma transparente) através desses serviços.
Ainda falando dessa arquitetura, podemos considerar que uma aplicação pode ser estruturada em camadas. Então para melhorar meu entendimento pesquisei no google:
“como funciona uma aplicação de 3 camadas”
E achei um links interessantes! Li só dois para não me perder no mar de informação:
- Arquitetura em 3 Camadas: (disponível em: http://outratecno.blogspot.com.br/2013/03/arquitetura-em-3-camadas.html?m=1)
- Arquitetura em três camadas — Parte 1 — [Conceito]: (disponível em: http://wp.me/p1g6qz-2A)
Agora finalmente falando sobre as camadas, podemos dividir em 3:
- Apresentação: responsável pela interação com o usuário, apresentação e entradas das informações.
- Processamento de aplicação (regra de negócio): responsável pela lógica da aplicação. Controla todo fluxo da informação intermediando a camada de apresentação e de dados. É onde está a inteligência do sistema.
- Gerenciamento de banco de dados (acesso aos dados): responsável pelas operações do banco de dados da aplicação.
Foi legal fazer isso porque eu vivencio essas coisas no dia-a-dia o tempo todo, e nunquinha tinha parado para pensar nisso… que coisa, não?
Algumas aplicações de cliente-servidor usam um modelo que no post do Manoel Veras aparece como cliente magro ou gordo:
- cliente-magro: O cliente fica responsável pela apresentação e o servidor fica responsável pelo processamento da aplicação e pelo gerenciamento do banco de dados. Este modelo pode apresentar problemas de desempenho e escalabilidade.
- cliente-gordo: o cliente é responsável pela apresentação e pelo processamento da aplicação. Este modelo pode dia vez pode apresentar problemas de gerenciamento.
Importante: os problemas de cliente magro e gordo (desempenho, escalabilidade e gerenciamento) para mim não ficaram claros. Coloquei pelo que entendi do Manoel Veras, ok?!
No texto da Marcela Peres ela cita que esse tipo de divisão, que faz o isolamento das funcionalidades, apresenta algumas facilidades:
- no desenvolvimento
- na manutenção
- no reaproveitamento do código
- permite aos desenvolvedores focar nas diferentes partes da aplicação durante a implementação
Bem, no próximo post começarei a falar dos itens listados na minha lousa hoje. 😉
Arrivederci,
Mi
