O MMA e a civilização

Por Elton Frederick

O crescimento do MMA se deve à nossa própria reação hipnótica diante da violência. A sacada de eventos como o UFC está na capacidade de transformar esse fascínio em produto.

O país do futebol parece estar se transformando também no país das lutas. A popularização dos torneios de MMA (sigla, em inglês, para Artes Marciais Mistas) tem suscitado discussões sobre as causas e consequencias daquilo que alguns chamam de “espetacularização da violência”. Por que milhões de pessoas se deslumbram com um esporte que se caracteriza por exibir doses cavalares daquilo que, em nossas vidas cotidianas, mais evitamos? Em que medida esse deslumbramento pode ser encarado como uma “doença social”, um indício de que há um estado “selvagem” no homem que ainda precisa ser civilizado?

Talvez a chave para a compreensão desse fenômeno esteja no fato de a violência ser capaz de suscitar horror, repulsa, fascínio e deleite, mas nunca indiferença. Além de todas as condições que ora concorrem para a popularização do esporte – grandes ídolos, patrocínios milionários e a exibição eventual na tevê –, o crescimento do MMA se deve, em especial, à nossa própria reação hipnótica diante da violência. A sacada de eventos como o Ultimate Fighting Championship (UFC) está na capacidade de transformar esse fascínio em produto.

Os mais críticos dizem que o crescimento do esporte indica um retorno à barbárie, em que a violência é a única linguagem compreensível; seria um desnude daquilo que há de mais arcaico no homem: a elevação gratuita da violência. Não se pode negar que há algo de grotesco nesses eventos; mas merece reflexão a afirmação de que eles denotam o regresso a um estado primitivo ou uma negação da civilização.

Ao cunhar a expressão “Gladiadores do Terceiro Milênio” durante a transmissão de um desses espetáculos, o locutor Galvão Bueno, involuntariamente, trouxe subsídios para o debate. As comparações com os antigos guerreiros romanos – feitas, em geral, como forma de criticar a selvageria e “atraso” dos competidores – não levam em consideração a diferença fundamental entre os protagonistas do passado e os do presente: enquanto os gladiadores eram, em sua maioria, escravos aprisionados durante as campanhas romanas, os lutadores de hoje são homens livres que escolheram a luta como profissão.

A diferença não pode ser negligenciada. Se, para os antigos, as batalhas eram um imperativo – uma vez que os lutadores não eram donos dos próprios corpos –, aqueles que hoje sangram nas arenas para ganhar dinheiro e entreter o público o fazem por livre escolha, digladiando-se com outros igualmente livres. Além disso, a transformação do “Vale-Tudo” em MMA traz outro dado para a reflexão: a violência passa a ser promovida sob a supervisão de regras previamente estabelecidas. Há limites para a atuação dos lutadores e, por mais espantoso que isso possa parecer em um cenário supostamente bárbaro como uma arena, o público consumidor repudia aqueles que eventualmente transgridam algum desses limites.

Visto sob essa ótica, ao invés de o MMA ser um retrocesso à civilização, pode-se notar aí um indício de seu triunfo: a violência continua a ser consumida, mas dentro de regras e limites; os indivíduos são livres para colocarem seus corpos à prova, mas contam com uma organização que garante a igualdade de condições (limites de peso, controle de dopagem, golpes ilegais).

Se na Roma antiga as lutas serviam à dominação política, hoje lutadores e promotores dividem os lucros do show, por meio de contratos igualmente preestabelecidos; se, no passado, a glória alcançada pelos gladiadores era insuficiente para retirar-lhes da condição de escravos, hoje glamour e dinheiro caminham juntos, fabricando ídolos multimilionários que rivalizam em atenção com astros da teledramaturgia.

Não se pode negar que há aí um espetáculo devidamente adaptado à realidade do “terceiro milênio”. Ao mesmo tempo em que se promove fruição àqueles que consideram esse tipo de violência aprazível, determina-se o espaço no qual ela deve ser concentrada e estabelece seus limites. Não causa espanto, portanto, que a cantora Sandy – aparentemente a criatura mais meiga do planeta – seja uma das assíduas consumidoras do gênero. Se, na arena moderna, o mais forte continua a vencer, a regra é ainda mais forte que o forte. E isso conforta, permitindo um consumo sem grandes contraindicações.

O MMA, de fato, mostra um pouco do que somos, trazendo à luz este estranho fetiche pela violência. Mas, acima de tudo, a maneira como a violência é operacionalizada e consumida revela alguns dos mecanismos da civilização.

Elton Frederick, mestre em Ciência Política pela PUC-SP, é especialista em Política e Relações Internacionais pela Escola de Sociologia e Política de São Paulo. E-mail: eltonfrederick@gmail.com

Projetos versus Operações Continuadas

Bem pessoal, O tema Projetos e Operações continuadas estão presentes nas certificações CAPM e PMP e a sua reflexão contribui bastante na formulação do conceito real de projetos, por isso não podia deixar de escrever esse texto para ajudar aqueles que pretendem fazer algumas dessas provas de certificação e também para quem deseja entender um pouco mais sobre projetos. Projetos são executados desde os primórdios da civilização. A construção das Pirâmides do Egito ou a construção da Muralha da China são exemplos de projetos. No entanto, projetos não se restringem a empreendimentos grandiosos. Todos nós executamos projetos em nosso dia-a-dia: a construção de nossas casas, nossas viagens e, até mesmo, nossa própria vida são exemplos de projetos. Observando a definição formal retirada do PMI nos diz que: Um projeto é um empreendimento único, com início e fim definidos, que utiliza recursos limitados e é conduzido por pessoas, visando atingir metas e objetivos pré-definidos estabelecidos dentro de parâmetros de prazo, custo e qualidade. Podemos chegar a um conceito rápido sobre projetos baseados em temporalidade e exclusividade. O projeto é algo realizado apenas uma vez e associado aos diversos fatores presentes na realização do mesmo a sua exclusividade é garantida. Já no que se refere a operações continuadas o nosso cotidiano também é rico em exemplos como a produção de carros, relógios, a impressão de livros. Esses exemplos relatados são reflexos de projetos que já se encerraram e estão na fase de operação continuada. A operação continuada é iniciada após o termino do projeto, onde o produto resultante geralmente recebe o aceite para entrar nessa fase. A definição de operações continuadas tem como objetivo produzir o mesmo resultado repetidas vezes e não possuem um inicio e fim definidos. Basicamente essa é a diferença entre estas e projetos. Para melhor entendimento a tabela abaixo apresenta as diferenças entre ambos:

Projetos

Inicio e fim definidos
Temporário por natureza
Produz um só produto ou serviço
O encerramento é definido por critérios específicos

Operações Continuadas

Sem inicio e fim definidos
Contínuo
Produz o mesmo produto ou serviço constante
Os processos não são encerrados

Read more about Projetos versus Operações Continuadas | Projetos e TI on:
http://projetoseti.com.br/gestao/projetos-versus-operacoes-continuadas/?utm_source=INK&utm_medium=copy&utm_campaign=share

Algumas histórias que testemunhei de Marcos. O melhor goleiro e o melhor caráter que vestiu a camisa do Palmeiras…

Por Cosme Rímoli

O único motivo de orgulho do palmeirense dos anos 2000 acabou.
E da maneira mais deprimente possível.
Como virou marca registrada do clube, sem festa, expectativa.
Marca registrada dessa incompetente diretoria.
Nunca o adeus deveria ter partido da boca de César Sampaio.
Mas de quem viveu, sofreu e comemorou tanto pelo Palmeiras.
Marcos parou porque não combinava com tanta decadência.
Nem Leão ou Oberdan Cattani tiveram tanta identificação com o clube.
Com a torcida.
Marcos era todo errado para o futebol moderno, sincero demais.
Sem frases feitas.
Dispensava assessores de imprensa.
Não conseguia se calar diante das injustiças.
Comprou brigas que não eram suas.
Tomou cafezinho durante jogo.
Fez defesas absurdas.
Falhou poucas e inesquecíveis vezes.
Nunca se escondeu, culpou a bola, o gramado.
Se o time era ruim, dizia e ponto final.
E como pegou times ruins que o Palmeiras montou nos últimos anos…
Acompanhei de perto a maior parte de sua carreira.
Aprendi a respeitá-lo como nunca respeitei nenhum jogador.
Sua sinceridade era cativante.
Jogador de caráter único.
O primeiro contato que tive com ele foi há exatos 19 anos.
Quando começava sua carreira no Palmeiras.
Ele era o terceiro goleiro do time que tinha Velloso como titular.
A equipe estava em Atibaia concentrada.
Naquele tempo a imprensa podia ficar no mesmo hotel.
Acordo de manhã e vou para o treinamento.
Me assusto com o que escuto.
“Vai tomar no …
Filha da p…
Eu tinha dito que esta porra não estava curada.”
Era um goleiro de mullet, cabelo comprido atrás, moda nos anos 80.
Ele xingava os médicos e pulava em um pé só.
O seu tornozelo estava inchado.
“Esse é um louco, mas será um dos melhores goleiros da história do Palmeiras.
Se não for para o hospício”, vaticinava Valdir Joaquim de Morais.
Excepcional arqueiro da história do clube.
E primeiro preparador de goleiros da história.
Pude acompanhar por décadas o talento e a caipirice de Marcos.
Corintiano na infância, tinha um prazer a mais em jogar contra o clube que amava.
“Aprendi a amar o Palmeiras.
Amor novo é muito melhor”, dizia, quando provocado.
Ele não podia negar a primeira paixão, revelada para a imprensa por seus pais.
Mas pelo Palmeiras ele foi além do que se esperava de um goleiro profissional.
Foi além do seu corpo.
Teve dores lancinantes.
Joelho, bacia, ombro, punho.
Tomou infiltrações, chorou no vestiário.
Disfarçava.
“Eu não consigo fechar a mão esquerda.
Também, que se foda, não sou costureira.
Sou goleiro”, desabafou em uma conversa descontraída.
Esse foi um dos motivos que o fizeram não ir para o Arsenal em 2003.
Foi um dos motivos.
O outro foi o apego aos pais em Oriente, sua caipirice e seu amor ao Palmeiras.
“Aqui eu me sinto em casa.
Vou ter um intérprete grudado em mim.
Passar frio, não saber nem o que comer.
O Palmeiras me deu um aumentinho, está ótimo.
A Inglaterra não precisa de mim.
E eu não preciso da Inglaterra.
Tenho o Palmeiras.”
Marcos sempre foi sincero demais.
Até se prejudicar.
Teve uma séria crise respiratória no Palmeiras.
Ficou vários jogos sem poder jogar.
Descobri que estava fumando, o que sempre fez.
Publiquei a notícia, ele ficou irritado, pensei que haveria briga, desmentido.
“É verdade.
Vou fazer o quê?
Talvez fumar um pouco menos”, disse ao dirigente do Palmeiras que pediu o desmentido que nunca houve.
Vanderlei Luxemburgo, Muricy e, principalmente, Felipão passaram pelo mesmo drama com ele.
“Não dá para calar o Marcão.
Ele não se controla.
Não esconde um problema.
Parece um torcedor no gol do Palmeiras.
Eu já desistir de mandar que ele cale a boca.
Ninguém cala o Marcão.
Nem eu”, jogava a toalha, Luxemburgo.
Ele teve uma proposta que seria irrecusável do Corinthians.
Jantou em 2005 com Kia Joorabchian.
Poderia ganhar pelo menos o triplo que recebia no Palmeiras.
Kia queria o melhor goleiro do Brasil.
Marcos falou que iria pensar e no dia seguinte daria a resposta ao iraniano.
O seu contrato estava acabando no Palestra Itália.
Era só ir embora e ganhar mais.
“Eu fiquei acordado a noite inteira.
Pensei bem, e cheguei à conclusão que a torcida do Palmeiras iria me matar.
Eu se fosse torcedor também iria me matar.
Pensei bem e achei que não valia a pena me vender por um pouco a mais de dinheiro.
Ganhei uma merreca de aumento e fiquei.
Sabia que estava no lugar certo.”
Outra mostra de coragem foi no rebaixamento do Palmeiras.
Fluminense, Vasco, Internacional, Cruzeiro tentaram convencê-lo a não disputar a Segunda Divisão.
Não combinava com goleiro pentacampeão do mundo.
Mas ele não quis nem saber.
Jogou em campos de dar vergonha em Ricardo Teixeira.
Comparou a pastos, sem o menor constrangimento.
E foi figura importantíssima na volta para a Série A.
“Fui para o inferno com o Palmeiras.
Não poderia fugir, virar as costas.
Me ralei todo em campos sem grama, mas voltamos.
Foi bom para aprender como é o inferno”, brincou.
As histórias de Marcos se sucedem na lembrança.
Sem ordem cronológica.
Quando defendeu o pênalti de Marcelinho Carioca que levou o Palmeiras à decisão da Libertadores.
“Foi foda.
Sabia onde ele iria cobrar.
Tinha certeza que defenderia.
O nosso time era muito pior do que o do Corinthians.
Mas a nossa torcida precisava ter o gostinho de tirá-los da final da Libertadores.
Foi uma das maiores alegrias da minha vida.”
No logo depois de uma disputa de pênaltis que vi Marcos tremer de alegria.
“Ser campeão da Libertadores é bom demais.
A primeira da história do Palmeiras.
Esse clube é sofrido demais.
Falam do Corinthians, mas aqui a gente sofre demais.
A nossa torcida é muito exigente, carente, sei lá.
Chega a ser apaixonada demais.
Aqui é céu ou inferno.
No inferno é um terror.
Mas no céu é mesmo o paraíso.
Não me lembro de estar tão feliz no futebol”, dizia com a faixa de campeão da Libertadores, em 1999.
Chorou também e muito depois da decisão do Mundial de Clubes.
Ele falhou feio no gol do Manchester United.
“Foi a primeira vez que ouvi para valer um conselho de um treinador.
O Felipão falou, mostrou teipe, insistiu que os putos só cruzavam no primeiro pau.
Eu dei dois passos para ir para a bola e ela veio no segundo, atrás de mim.
E quando vi o cara chegando para marcar, pensei: “Meu Deus…”
Eu queria me enfiar em um buraco.
Para piorar de vez, o nosso time perdeu uns três gols.
Fiquei para a história como o vilão da final do Mundial do Palmeiras.
Só comigo acontece essas porras.
Herói, santo na final da Libertadores.
E depois o vilão do Mundial.
Eu não merecia isso”, desabafou.
Soube que ele passou a noite inteira depois da decisão contra o Manchester United chorando.
Mas o destino lhe deu a chance de se vingar dos ingleses, do mundo.
Na Copa do Mundo de 2002.
“O Felipão foi foda.
Falou que eu seria o goleiro dele e ponto final.
Nossa, não sei o que me deu.
Eu fiquei tão contente, tão confiante que tinha de ganhar aquela Copa.
Não perderia de novo um Mundial.
O time era sensacional, mas sei que dei a minha ajudinha.”
A partida que ele mais gostou foi a que culminou com a eliminação da Inglaterra.
“Deu mesmo um gostinho especial.
Esses ingleses me fizeram sofrer demais em 1999.
Demorou três anos, mas dei o troco.”
Voltamos juntos para o Brasil, no mesmo voo.
Ele estava completamente encantado.
“Ainda não acredito.
Parece que foi um filme, um sonho, sei lá.
Não acredito que eu sou campeão do mundo.
Parece mentira, uma pegadinha.
Não acredito que eu mereço tanto.”
Encontrei Marcos novamente na saída de um banco.
Na agência que os torcedores bateram em Vagner Love.
“Eu não estou aguentando mais de tanta dor.
Cada treino é um sacrifício para mim.
Principalmente o joelho esquerdo.
Fico triste pelo Palmeiras não estar bem.
Queria encerrar a minha carreira com uma grande festa.
Com o time campeão, todos felizes.”
Mas esse último pedido ao destino não foi realizado.
O joelho esquerdo está em petição de miséria.
Depois de cada treino, ele incha pedindo clemência.
A incompetente atual diretoria queria que sua despedida fosse contra o Ajax.
Coisa improvisada, agora em janeiro.
Chegou o seu recado, sincero.
Ele não quis, de jeito nenhum.
Há a versão que soltou alguns palavrões.
A mensagem chegou.
Foi entendida.
Marcos quer dois meses para férias e se preparar para o seu último jogo.
Por mais incompetentes que sejam, os dirigentes vão organizar uma festa digna.
É o mínimo que ele merece.
O goleiro de melhor personalidade, mais sincero a vestir a camisa palmeirense.
De tanto talento, coração.
Marcos não merecia menos.
Por maior que seja a estátua no Palestra Itália, ela será pequena.
Diante de uma carreira tão brilhante com a camisa 12.
Marcos era a única coisa boa no atual Palmeiras.
Tristes torcedores do time verde.
Perderam o maior motivo de ir ao estádio.
Mas vão poder desafiar para sempre os rivais.
Ninguém teve Marcos.
Só o Palmeiras…

Como foi o ano de 2011? Você ficou mais rico ou mais pobre?

Todo o final do ano é comum perceber na maior parte das pessoas a intenção de mudar, começar algo novo e ser mais feliz. Claro, eu não sou diferente e já comecei a pensar nos projetos (e existem vários) para os próximos anos. Se a análise para o futuro quase sempre tem a perspectiva positiva, o que podemos aprender com o que acabamos de superar durante o ano de 2011? Afinal, você ficou mais rico ou mais pobre em 2011?

Não existe uma maneira mais prática de encarar a evolução natural das coisas do que pensar nas conquistas. Como está o seu lado profissional, você conseguiu avançar? E sua qualidade de vida, melhorou? Os dias e momentos ao lado de sua família e amigos foram mais completos, harmoniosos? Você conseguiu investir algum dinheiro e livrar-se do endividamento?

Hoje melhor que ontem, amanhã melhor que hoje

Se pensarmos objetivamente, um bom termômetro para conferir o que de fato aconteceu é olhar paro o crescimento de seu patrimônio e, numericamente, descobrir se ele aumentou ou não. Preste atenção também aos detalhes, já que a resposta para essa questão pode ser também muito subjetiva: em alguns casos, um grande projeto iniciado nesse ano pode ser o trunfo para o futuro ou longo prazo – dessa forma, você pode considerar a resposta como positiva.

A verdade é que muitas variáveis precisam ser consideradas para responder essa pergunta sobre o patrimônio. O ideal é analisar seu crescimento primeiro pelo lado do desenvolvimento pessoal. Depois dos desafios, conquistas e dificuldades de 2011, você acredita ser uma pessoa melhor?

Repare que nossa conversa hoje é um pouco diferente. Estou convencido de que toda experiência adquirida durante a vida nos torna pessoas mais bem preparadas para tomar as melhores decisões, inclusive e principalmente aquelas relacionadas ao dinheiro.

Há aqueles que não aprenderam a lidar com o planejamento financeiro, por exemplo. Por que não o fizeram? Está mais do que claro que planejar os gastos e manter uma harmonia entre as receitas e despesas é indispensável para uma vida tranquila e de futuro garantido. Aprender a planejar é, sem dúvida, um ganho espetacular que contribuirá sempre para a realização de nossos sonhos. Você percebeu isso em 2011?

Aprenda com os bons exemplos

Observe seus amigos mais bem sucedidos. Afinal, você aproveitou o ano que agora termina para perguntar como ele chegou lá? Mais, tentou absorver os pontos positivos que o levaram ao sucesso? Preste atenção: estou falando aqui de pessoas que chegaram ao sucesso com boas práticas e não dos picaretas, que usaram e abusaram de práticas condenáveis. O que você aprendeu com essas pessoas diferenciadas?

Por um 2012 diferente, melhor!

Se o ano que acaba agora não foi tão bom para você, não fique se lamentando. Separei algumas atividades que podem motivá-lo a fazer de 2012 um ano melhor. Veja:

Invista no conhecimento. Deixe de lado a ideia de que não é possível mudar. Desenvolva o hábito da leitura e aproveite a oportunidade (se ela surgir) de voltar a estudar;

Crie novos hábitos. Procure aprender com os erros. Deixe de comprar na base do impulso e passe a planejar os gastos para que, nos momentos de grande emoção, você não tome as piores decisões financeiras;

Invista no relacionamento online. O mundo nunca se tornou tão pequeno. Você está a um clique de começar a ampliar seu relacionamento profissional com milhares de pessoas que podem ajudá-lo no desenvolvimento de sua carreira. A Internet não pode ser utilizada apenas para diversão. “Think different”, já dizia a Apple de Steve Jobs;

Aprenda a investir. Chega de tomar decisões baseadas apenas nos conceitos ou aprendizados de terceiros. Aprenda a valorizar o conhecimento específico sobre economia, finanças pessoais e investimentos e busque aperfeiçoar suas decisões neste sentido. Onde investir? Quanto poupar? Por que essa e não aquela alternativa? Seu futuro pode depender disso;

Tente, sim, mudar o mundo. Em 2011, morreu Steve Jobs, alguém que passou grande parte da vida com a intenção de mudar o mundo. Ele conseguiu. Você não acredita que também tem uma colaboração a fazer? Cada um ao seu estilo, podemos fazer a diferença, ainda que seja para uma pessoa, pequeno grupo ou comunidade. Uma boa alternativa são os trabalhos voluntários. Atualmente, as grandes empresas valorizam os profissionais que dão sua parcela de colaboração com causas consideradas nobres. Faça mais que apenas a sua parte!

Valorize o que realmente é importante. Cada pessoa tem o seu próprio conceito de o que é realmente importante. Minha experiência pessoal mostra que o que é mais valioso e importante normalmente não custa dinheiro; não é algo que se possa comprar. Estou falando do tempo, o tempo que muitas vezes desperdiçamos com atitudes pequenas e pouco produtivas. Invista mais no contato com as pessoas e aprendendo coisas novas.

Ainda dá tempo? Claro! Ora, ainda faltam alguns dias para o ano se encerrar de vez. Portanto, dá tempo de fazer muitas coisas. Comece fazendo algo especial para alguém; comece aceitando a responsabilidade de reorganizar suas finanças e sair do vermelho; comece fazendo mais que apenas prometer. Aceita o desafio?

Fonte: Dinheirama

NET – Desenvolvimento de software com uma abordagem corporativa

É quase sempre a mesma coisa: começamos o desenvolvimento de uma aplicação e no princípio ela começa pequena e com requisitos limitados e parece que vai permanecer assim no futuro. Mas logo vemos que novos requisitos e novas funcionalidades são adicionadas à aplicação e ela começa a crescer e a crescer e a ficar fora do controle. Então começamos a refletir sobre o fato de que se soubéssemos que a aplicação iria se tornar tão importante e crescer tanto a teríamos construído de uma forma diferente levando em conta a extensibilidade e escalabilidade mas agora temos que correr atrás do prejuízo.

Por que será que essa história tem se repetido anos a fio no processo de desenvolvimento de software ?

Porque não tomamos uma decisão de mudar a forma de encarar o problema e de por em prática princípios que achamos que somente em aplicações corporativas devem ser aplicados ?

Neste artigo eu apresento os princípios básicos para que o desenvolvimento de software seja feito levando em conta as boas práticas visando sempre a extensibilidade e escalabilidade e sem perder de foco a simplicidade.

O objetivo é mostrar que isso é mais simples do que imaginamos e, que embora pareça mais complexo trás um ganho de produtividade.

Não é preciso ser um mestre ou ter muitos anos de experiência para aplicar tais princípios basta apenas querer fazer um bom trabalho: um trabalho de qualidade.(ISO 9126)

Princípios básicos no desenvolvimento de software

Ao projetar e desenvolver um produto de software devemos aderir a certos princípios básicos de arquitetura que permitirão que os alicerces de nosso projeto esteja bem fundamentado.

Modularidade e baixo acoplamento

Ao projetar e desenvolver um software procure sempre dividir as funcionalidades relacionadas em vários módulos e faça isso de uma forma que não exista interdependências entre os módulos ou que ela seja a mais baixa possível.

Em projetos orientado a objetos, que é nosso foco, temos que os objetos são interligados trocando mensagens uns com os outros. O termo baixo acoplamento indica que as classes de um projeto sestão pouco interligadas e têm apenas o conhecimento sobre o que devem fazer. Isso facilita o entendimento, a reutilização e evita a propagação de mudanças.

Separação de responsabilidades

Ao projetar e desenvolver um software procure sempre aplicar a separação de responsabilidades que é o processo de dividir sua aplicação em unidades específicas de funcionalidades de tal forma que cada unidade atenda somente às necessidades de sua responsabilidade tendo o mínimo de sobreposição possível com outras unidades em termos de funcionalidade; ou seja, nenhum elemento do sistema deve compartilhar as responsabilidades de outro ou abranger responsabilidades não relacionadas.

Isto é alcançado estabelecendo limites, onde um limite é qualquer restrição lógica ou física que delimita um determinado conjunto de responsabilidades.

Extensibilidade

Ao projetar e desenvolver um software procure sempre construir a maior parte da aplicação de forma extensível para que se for necessário possamos substituir partes da funcionalidade sem ter que recompilar ou redesenhar a aplicação inteira.

Desenvolva sempre pensando no futuro de forma que o sistema possa ser estendido(extendido) sem traumas.As extensões podem ser feitas através da adição de novas funcionalidades ou através da modificação de funcionalidades existentes. O objetivo central é estar preparado para mudanças e ao mesmo tempo minimizar o impacto que isso poderá ter nas funções já existentes do sistema.

Arquitetura em camadas

Uma das maneiras de obtermos a separação das responsabilidades é dividir as principais áreas da aplicação em camadas. Na maioria das aplicações essa divisão pode ser feita criando 3 camadas as quais são :

camada de apresentação
camada da lógica de negócios
camada de acesso a dados

A organização em camadas é a chave para a independência entre os componentes e esta independência é que vai atingir os objetivos de eficiência , escalabilidade , reutilização e facilidade de manutenção.

obs: É importante deixar claro que estamos falando em camadas lógicas e não em necessariamente em camadas físicas quando uma ou mais camadas estão hospedadas em locais distintos.

A separação em camadas lógicas torna os sistemas mais flexíveis permitindo que as partes possam ser alteradas de forma independente. As funcionalidades da camada de negócio podem ser divididas em classes e essas classes podem ser agrupadas em pacotes ou componentes reduzindo as dependências entre as classes e pacotes ; podem ser reutilizadas por diferentes partes do aplicativo e até por aplicativos diferentes. O modelo em 3 camadas tornou-se a arquitetura padrão para sistemas corporativos com base na Web.

A modelagem orientada a objetos ajuda a promover a modularidade pois os objetos encapsulam seus dados (propriedades, estados) e oferecem funcionalidades através de seus métodos. Projetando-se de forma adequada os objetos podem ter reduzidas as dependências entre si ficando assim fracamente acoplados e serão mais fáceis de manter e evoluir.

Essa abordagem é adequada para a maioria das aplicações de baixa e média complexidade. Para aplicações mais complexas talvez haja a necessidade de acrescentar outras camadas levando-nos a uma arquitetura em n-camadas.

Camada de apresentação : Esta camada normalmente esta relacionada com a interface do usuário de sua aplicação incluindo itens como: botões, links, e outros controles com os quais o usuário interaja enquanto estiver usando o aplicativo.

Camada de negócios : Esta camada é o local onde estão as regras do negócio de sua aplicação. O objetivo da camada de negócios é implementar a lógica da aplicação,
expondo esta lógica para a camada de apresentação.

Camada de Acesso a dados : A camada de acesso a dados é responsável pelo acesso e interação com uma fonte de dados a qual poderia ser: um banco de dados, arquivos XML, arquivos de texto,um serviço web, etc.

Nas referências existem implementações que levam em contas esses princípios e que podem ser consideradas como uma introdução básica da aplicabilidade dos mesmos na prática.

Eu procurei ser bem objetivo e o mais simples possível sem entrar em detalhes que deverão ser considerados para quem desejar se aprofundar no tema.

Veja neste link um ebook grátis que serve como um guia para melhorar o desempenho de sua aplicação: Improving .NET Application Performance and Scalability

Fonte: Macoratti.NET

Desenvolvedor Profissional… Será?

Segundo o dicionário da língua portuguesa a definição de profissional é “pessoa que exerce uma certa profissão”.

Então, se você exerce profissionalmente o papel de desenvolvedor de software, logo, você pode ser classificado como um “desenvolvedor profissional”, correto? Em tese, infelizmente, sim.

Digo em tese porque meu conceito de desenvolvedor profissional é diferente do que consta no dicionário. Tem muito desenvolvedor amador por ai no mercado, botando banca de super-herói, mas que na verdade gera mais bugs do que features de software.

Mas como podemos identificar a diferença entre desenvolvedores profissionais e desenvolvedores amadores, segue algumas dicas:

- Desenvolvedores profissionais planejam suas implementações antes de sair despejando linhas de código na aplicação. Desenvolvedores amadores freqüentemente trabalham com o método de tentativa e erro, ou seja, sem nenhum planejamento prévio ou analise de impacto em outras classes/módulos da aplicação.

- Desenvolvedores profissionais se preocupam com o desempenho de suas soluções e não apenas se a especificação recebida foi atendida. Desenvolvedores amadores não se preocupam com desempenho, o importante é entregar o que foi pedido. Funcionar rápido é outra história!

- Desenvolvedores profissionais produzem códigos legíveis, e não se importam de fazer refactoring em seus códigos ou códigos gerados por terceiros. Enquanto isto, os desenvolvedores amadores procuram no dicionário de inglês o significado da palavra refactoring.

- Desenvolvedores profissionais trabalham com desenvolvimento orientado a testes, ou pelo menos estão ligados no assunto e gostariam de trabalhar no futuro. Desenvolvedores amadores não são pagos para testar; Azar do testador compilou sem erros está pronto!

- Desenvolvedores profissionais estão atentos para outras atividades do ramo de desenvolvimento de software como analise de requisitos, banco de dados, padrões de projeto, metodologias de desenvolvimento, teste de software, etc. Desenvolvedores amadores apenas programam!

- Desenvolvedores profissionais trazem os problemas a tona sempre que os encontram. Desenvolvedores amadores varrem para debaixo do tapete.

- Desenvolvedores profissionais geram códigos em menos tempo porque sabem que fazer uma coisa certa é mais rápido do que explicar porque a fez errado. Desenvolvedores amadores estão sempre se explicando para alguém.

E ai, você é amador ou profissional?

Artigo originalmente publicado em 5 de fevereiro de 2010 por Thiago Belem: Desenvolvedor Profissional… Será?

.NET – Princípios básicos de um projeto de software

In the beginner’s mind there are many possibilities. In the expert’s mind there are few. (Shunryu Suzuki)

A manutenção de uma aplicação é provavelmente mais difícil e trabalhosa e definitivamente menos empolgante do que criar uma aplicação desde o início.

Uma grande parte do tempo de um desenvolvedor é gasta com tarefas relacionadas com a manutenção de software ao invés de tarefas como planejar e codificar uma nova aplicação.

Então seria lógico que ao construir uma aplicação deveríamos ter em mente um projeto robusto que demandasse pouca manutenção.

A seguir vou relacionar alguns dos maiores problemas encontrados em um sistema de software e que poderiam ser evitados :

Rigidez – O sistema foi feito de forma a ser duro de mudar, qualquer alteração provoca uma cascata de operações por todo o sistema;

Fragilidade – O sistema foi feito de forma que qualquer mudança feita o desestabiliza;

Imobilidade – O código foi feito de forma a ser difícil de ser reusado; nenhuma parte do sistema pode ser aproveitada em outro sistema;

Complexidade – O código foi feito com a aplicação de diversos padrões de projeto a um problemas simples;

Repetição de código desnecessária – O mesmo trecho de código esta esparramado por todo o sistema;

Diante desse cenário seria razoável então dedicar uma atenção especial a um atributo do projeto de software durante a sua criação: A manutenibilidade.

Manutenibilidade é uma característica inerente a um projeto de sistema ou produto, e se refere à facilidade, precisão, segurança e economia na execução de açãoes de manutenção nesse sistema ou produto. (BLANCHARD, Benjamin. Logistics engineering and management. 4th ed. Englewwod Cliffs: Prentice Hall, 1992. p. 15).

Em engenharia de software, manutenibilidade é um aspecto da qualidade de software que se refere à facilidade de um software de ser modificado a fim de corrigir defeitos, adequar-se a novos requisitos, aumentar a suportabilidade ou se adequar a um ambiente novo. Tais atividades são conhecidas como a manutenção de software, assim como definido pela ISO/IEC 9126. http://pt.wikipedia.org/wiki/Manutenibilidade

Talvez o maior desafio que os arquitetos de software enfrentam hoje em dia é como projetar e implementar uma aplicação que atenda todos os requisitos em sua primeira versão e que depois de sua implementação possa ser estendida para atender outros requisitos de forma simples e a um baixo custo.

A manutenibilidade é um dos atributos fundamentais do projeto de software tratado desde a primeira versão no artigo ISO/IEC 9126 que fornece uma descrição formal da qualidade de software descrevendo um conjunto de características sobre este atributo. Uma versão PDF pode ser obtida em http://www.iso.org.

O grande desafio dos arquitetos é estar focado nos requisitos atuais do projeto durante a fase de desenvolvimento de forma que o mesmo seja flexível o suficiente para suportar futuras alterações e novas implementações sem quebrar o projeto inicial. Neste escopo a manutenibilidade representa o melhor compromisso pois com um alto grau de manutenibilidade no seu código é muito mais fácil obter desempenho, segurança e escalabilidade.

Colocando as coisas dessa forma parece ser simples mas como escrever software que seja fácil de manter ?

Existem alguns princípios básicos de um projeto de software que se forem propriamente aplicados podem tornar o código mais maleável e flexível. Tenha em mente que não estamos pregando que o software será infalível mas que os erros devem ser mais facilmente encontrados e resolvidos.

Big Ball of Mud (BBM) (A grande bola de lama)

A expressão “big ball of mud” (BBM-http://www.laputan.org/mud), a grande bola de lama (em uma tradução livre), indica um anti-padrão para arquitetos e desenvolvedores e refere-se a um software que possui todas as qualidades que resultam em um código difícil de entender, manter e estender.

Um sistema BBM é o resultado de uma combinação de efeitos oriundos das seguintes causas:

Mudanças freqüentes nos requisitos;
Capacidade limitada da equipe de desenvolvimento;
Alta taxa de rotatividade entre os membros da equipe de projeto;

A melhor coisa a fazer diante de um situação que nos leva a tratar um sistema BBM talvez seja reescrever a aplicação novamente baseada nos novos conjuntos de requisitos. Mas na prática isso quase nem sempre é viável em termos do tempo e do custo envolvido. Então temos um elefante branco que provavelmente terá uma longa vida.

Quais os sintomas para identificar um sistema BBM ?

Você pode dobrar um pedaço de madeira ?

E o qual o risco que você corre se você insistir em tentar fazer isso ?

Um pedaço de madeira geralmente é dura e rígida e é caracterizada por alguma resistência à deformação. (resistência a mudança)

Quando uma força suficiente é aplicada pode-se causar uma deformação e a deformação torna-se permanente.

Um sistema inflexível tem um o mesmo comportamento.

Infelizmente o BBM ainda parece ser o projeto de software mais produzido nos dias atuais.

O resultado ??

Um código mal definido e mal estruturado produzindo sistemas rígidos que são difíceis de testar , manter , entender, usar , estender, enfim uma grande bola de lama.

Como identificar um projeto BBM ?

Faça uma alteração aqui e o código quebra ali

E o que você acha que acontece com um software “rígido” ?

Um Software ‘rígido’ caracteriza-se por ser resistente às mudanças. A resistência é medida em termos de regressão. Você faz uma alteração em um módulo, mas os efeitos de sua alteração se propagam em cascata para baixo na lista de módulos dependentes. Como resultado, fica muito difícil prever o quão grande será o impacto feito por qualquer mudança, mesmo a mais simples, e isso fragiliza o software.

Como fragilidade e rigidez andam de mãos dados quando uma alteração feita ocasionar uma quebra de outro módulo por causa de dependências ocultas fica claro que você tem um sistema ruim e que precisa corrigir esta situação o mais rápido possível.

Mais fácil de usar do que reutilizar

Você tem um código que funciona muito bem em um projeto e deseja usá-lo em seu projeto atual mas apenas copiar o código no novo projeto simplesmente não funciona.

Se o código não funciona quando é movido para outro projeto, é por causa da dependências. No entanto, o verdadeiro problema não é apenas dependências, é o número e profundidade de dependências. O risco é que para obter a reutilização de um pedaço de funcionalidade em outro projeto, você terá que importar um conjunto muito maior de funções. Nestes casos geralmente procura se reescrever a funcionalidade novamente do início causando a duplicação de código.

Isso agrega um atributo negativo ao seu projeto de software chamado : imobilidade.

Mais fácil de remendar do que corrigir

Ao aplicar uma mudança de um módulo de software, não é incomum você encontrar mais de uma maneira de fazer isso. Na maioria das vezes, uma forma de fazer as coisas é elegante e coerente com o projeto, mas terrivelmente trabalhosa para implementar por causa de certas restrições. A outra forma é, ao contrário, muito mais fácil e mais rápida de codificar, mas ela é uma espécie de remendo que “cheira mal”(“bad-smells”).

Definido por Martin Fowler e Kent Beck, o termo “bad-smell” (mal cheiro) se refere às características
encontradas nas estruturas de códigos que devem ser refatorados.

Alguns dos “bad-smells” que podem ser encontrado no livro do Martin Fowler (2004) são:

* Código Duplicado;
* Método Longo;
* Classes Grandes;
* Lista de Parâmetros Longa;
* Alteração Divergente;
* Grupos de Dados;
* Hierarquias Paralelas de Herança;
* Classe Ociosa;
* Campo Temporário;
* Cadeias de Mensagens;
* Biblioteca de Classes Incompleta

Aplicar um remendo não é uma situação ideal, porque uma remendo (solução alternativa) pode ser mais fácil de aplicar que a solução certa, e se for assim isso significa que seu código possui muitas dependências desnecessárias entre as classes e que suas classes não são coesas.

Isto agrega um atributo negativo ao seu projeto chamado: viscosidade.

E como evitar um projeto BBM ?

Podemos evitar um projeto BBM aplicando os seguintes princípios:(pelo menos é o que se recomenda fazer)

Alta coesão e baixo acoplamento
Separação de responsabilidades
Diminua o acoplamento

As expressões “acoplamento fraco” ou “acoplamento forte” são comuns em quase todas as discussões sobre projeto de software. O acoplamento entre classes ou subsistemas é uma medida da interconexão entre essas classes ou subsistemas. O acoplamento forte significa que as classes relacionadas precisam conhecer detalhes internos umas das outras, as alterações se propagam pelo sistema, e o sistema é potencialmente mais difícil de entender e manter.

- Acoplamento é o nível de dependência/conhecimento que pode existir entre as classes;
- Uma classe com acoplamento fraco não é dependente de muitas classes para fazer o que ele tem que fazer;
- Uma classe com acoplamento forte depende de muitas outras classes para fazer o seu serviço;
- Uma classe com acoplamento forte é mais difícil de manter, de entender e de ser reusada;

Resumindo, os objetivos por trás da obtenção de um acoplamento fraco entre classes e módulos são:

Tornar o código mais fácil de ler;
Tornar nossas classes mais simples para o consumo de outros desenvolvedores, ocultando a parte “feia” do funcionamento interno em APIs bem projetadas;
Isolar possíveis alterações em uma área pequena do código;
Reutilizar classes em contextos completamente novos;
Aumente a coesão

Coesão é o nível de integralidade interna de uma classe; (Veja o principio da responsabilidade única – SRP)

- A coesão mede o grau que um classe ou seus métodos fazem sentido, ou seja, quão claro é o entendimento do que a classe ou método possui
- Uma classe com alta coesão possui responsabilidades bem definidas e são difíceis de serem desmembradas em outras classes;
- Uma classe com baixa coesão possui muitas responsabilidades, geralmente que pertencem a outras classes, e podem ser facilmente desmembradas em outras classes;
- Uma classe com baixa coesão é difícil de entender, manter e reusar;

Portanto quanto mais forte o acoplamento e mais baixa a coesão de um código mais difícil ele será de entender, manter e ser reusada.

Separe responsabilidades (Separation of Concerns)

O princípio da separação de responsabilidades (ou conceitos ou interesses) (SoC) foi introduzido por Edsger W. Dijkstra em seu artigo “Sobre o papel do pensamento científico” de 1974. Se você está interessado, pode baixar o documento completo em http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF.

A separação de interesses é objetivo essencial do processo de decomposição de um problema onde :

Decomposição deve continuar até que cada unidade do problema possa ser compreendida e construída;
Cada unidade deve lidar com apenas um interesse;

A separação de interesses eficiente promove um código de melhor qualidade pois possui:

- Maior modularidade;
- Facilidade atribuição de responsabilidades entre módulos;
- Promoção da reutilização;
- Facilita a evolução do software;
- Viabiliza a análise do problema dentro de domínios específicos;

Sistemas de software consistem de um conjunto de “áreas de interesse” ou responsabilidades distintas como, por exemplo, responsabilidades funcionais (lógica de negócio) e não-funcionais (performance, persistência de dados, logging, autenticação de usuários, segurança, verificação de erros, etc.). Existem também as preocupações relacionadas com o processo de desenvolvimento de software, como clareza de entendimento, facilidade de manutenção, rastreabilidade, simplicidade de evolução do software, etc. (http://www.dextra.com.br/empresa/artigos/aspectprog.htm)

O princípio é simples: fazer com que duas funcionalidades tenham o mínimo de sobreposição.

O princípio trata em como dividir o sistema em responsabilidades distintas e não sobrepostas onde cada recurso que você quer no sistema representa uma funcionalidade e um aspecto do sistema.

O principio sugere que você se concentre em uma responsabilidade especial em um dado momento sem ignorar as outras funcionalidades do sistema. Depois que você atribuir uma funcionalidade a um módulo de software você se concentra na construção desse módulo a partir da perspectiva do módulo.

Separar responsabilidades, implica fazer com que uma aplicação seja modularizada, com o objetivo de resolver um único problema. A separação de responsabilidades, pode também ser aplicada a classes, métodos e componentes. O objetivo e fazer cada parte resolver um único problema.

A eficiência do desenvolvimento aumenta na medida em que conseguimos separar as suas diferentes responsabilidades em módulos estanques. Este princípio é razoavelmente antigo, e a OOP nos trouxe uma importante resposta a ele: a classe como uma dimensão para a decomposição de responsabilidades.
(http://www.dextra.com.br/empresa/artigos/aspectprog.htm)

Na prática podemos aplicar o princípio em dois níveis:

- nivel conceitual :

Identificar conceitualmente os interesses, conceitos, responsabilidades;
Assegurar que as responsabilidades identificadas não possam ser divididas;

- nivel de código :

Fornecer organização para isolar as responsabilidades;
Separar os blocos de código;

A separação de conceitos é concretamente alcançada por meio de um código modular e fazendo amplo uso do ocultamento de informações (encapsulamento).Programação modular incentiva o uso de módulos separados para cada característica significativa. Aos Módulos são dados a sua própria interface pública para se comunicar com outros módulos e podem conter pedaços internos de informação para uso privado.

Apenas os membros na interface pública são visíveis para outros módulos. Dados internos ou não são expostos ou são encapsulados e expostos de forma filtrada.

A ocultação de informações é um princípio de projeto em geral que se refere a esconder atrás de uma interface alguns detalhes de implementação de um módulo de software que estão sujeitos a alterações. Desta forma, módulos conectados continuar a ver a mesma interface fixa e não são afetados por alterações.

Separação de interesses é o pilar teórico usado em sistemas com várias camadas (ou apenas de múltiplas camadas)

Você essencialmente consegue a separação de responsabilidades ao isolar dependências e abstraindo-as em interfaces. Isso é chamado baixo acoplamento, ou programação baseada em interface, ou também, o principio da inversão da a dependência. Nomes diferentes, cada um adequado ao seu própria contexto.

Aplique os princípios SOLID

Os princípios SOLID para programação e design orientados a objeto são de autoria de Robert C. Martin (mais conhecido como Uncle Bob) e datam do início de 2000.

A palavra SOLID é um acróstico onde cada letra significa a sigla de um princípio: SRP, OCP, LSP, ISP e DIP.

Os princípios SOLID devem ser aplicados no desenvolvimento de software de forma que o software produzido tenha as seguintes características:

Seja fácil de manter, adaptar e se ajustar às constantes mudanças exigidas pelos clientes;
Seja fácil de entender e testar;
Seja construído de forma a estar preparado para ser facilmente alterado com o menor esforço possível;
Seja possível de ser reaproveitado;
Exista em produção o maior tempo possível;
Que atenda realmente as necessidades dos clientes para o qual foi criado;

Cada um dos princípios pode ser consultado nos links a seguir:

- OOP – Herança x Composição
- OOP – O princípio da substituição de Liskov (LSP)
- OOP – O princípio Open-Closed (OCP)
- Padrões de Projeto – Os 7 princípios básicos do desenvolvimento de software

Conclusão:

Assim como um arquiteto que projeta uma casa não iria ignorar os códigos de construção que se aplicam ao contexto, um arquiteto de software que trabalha em um contexto orientado a objetos não deve ignorar os princípios de padrão de projetos tais como os princípios SOLID que envolvem o baixo acoplamento, a alta coesão e o princípio das separação de responsabilidades ao projetar um software.

Fonte: Macoratti .NET

C# – Retornando ID com o método ExecuteScalar

Olá pessoal, nesta dica rápida mostrarei como recuperar o ID gerado após um INSERT, com o método ExecuteScalar, da classe SqlCommand.

Muitas vezes precisamos não só fazer um INSERT de um registro no banco, como também recuperarmos o ID que gerado para o utilizarmos em outras situações. Lembrando que para que o SQL Server nos gere um ID após realizarmos o INSERT, nossa coluna deve ser do tipo Identity e ser chave primária (Primary Key).

Ignorando as instruções SQL vamos se focar no método em si e na instrução SQL. A Listagem 01 nos exibe o INSERT, com o uso do SELECT SCOPE_IDENTITY(), para retornar para nós o ID gerado.

Listagem 01 – Instrução SQL

string strInstrucaoSql = “INSERT INTO Clientes VALUES (@Nome, @Endereco, @Telefone, @Sexo, @Ativo, @DataCadastro) SELECT SCOPE_IDENTITY()”;

Na Listagem 02 é criado uma variável do tipo Int32 que recebe o método ExecuteScalar convertido para o tipo da variável, da classe SqlCommand, necessária para nos retornar o ID que é gerado após a execução da instrução SQL da Listagem 01.

Listagem 02 – Variável que receberá o ID gerado pelo ExecuteScalar

Int32 idRetorno = Convert.ToInt32(objCommand.ExecuteScalar());

A figura abaixo representa o ID gerado para nossa variável. Assim poderemos utilizá-lo para outras operações relacionadas ao banco.

Assim finalizo a dica rápida. Muito obrigado a todos!

Fonte: Programando .NET

Batman: Arkham City

Batman: Arkham Asylum foi lançado em 2009 e é considerado o melhor jogo do Homem Morcego de todos os tempos. Desde o seu final, já tinhamos pistas de que uma sequência era esperada, e recentemente foi lançado Batman: Arkham City, que promete expandir as idéias do primeiro game, além de te levar ao encontro de mais personagens memoráveis das histórias do Batman. E pra grata supresa dos fãs, a nova aventura do morcegão melhora o que já era bom no game anterior, e expande muito mais o que você pode fazer por Arkham City.

A premissa do jogo é interessante: logo após os eventos de Arkham Asylum, o seu antigo diretor Quincy Sharp ganha os créditos por contornar a rebelião criada pelo Coringa, e lança seu projeto mais ambicioso, na forma da cidade-presídio Arkham City. O projeto leva Sharp ao status de Prefeito de Gotham, e ele aponta o psiquiatra gênio Hugo Strange como diretor do novo complexo presidiário. Todas as peças estavam prontas para o grande show: capturar o Homem-Morcego.

O jogo começa bem diferente de Arkham Asylum, já que Bruce Wayne escolheu combater o novo presídio na frente política, e está fazendo um discurso contra a própria existência de Arkham City. Durante o comício, a empresa de segurança contratada por Strange, chamada TYGER, leva o bilionário preso. Você começa o jogo já dentro do grande “viveiro” de criminosos de Gotham. A DC Comics lançou um quadrinho especial, contando vários detalhes desta trama, assinada por Paul Dini, o mesmo roteirista de Arkham Asylum e de várias histórias memoráveis do Morcegão.

O ponto mais interessante de Arkham City com relação ao seu antecessor, é a total quebra de linearidade que as paredes do asilo impunham em você. Claro, você podia mudar de direção durante uma missão e procurar por alguns troféus do Charada, ou atacar alguns bandidos, mas sua rotina era basicamente fechada, quase linear.

Em Arkham City, isso mudou, e pra melhor. O resultado é que podemos viver um dia na pele do Batman realmente, com algumas missões mais prioritárias na sua vista, mas com vários case files diferentes para cumprir na forma de missões secundárias. É quase que um sandbox do Homem-Morcego, mas que em nenhum momento você perde o foco na situação ao redor. Mesmo se você se fixar somente aos objetivos principais, basta uma mudada para o detective mode para aguçar sua curiosidade sobre o que mais acontece em Arkham.

A história corre ao redor do grande embate entre Hugo Strange e Bruce Wayne, mas com várias outras ao redor, e o que mais vai te desvirtuar é sobre o Coringa e sua doença fatal. Alguns meses depois de injetar em si mesmo uma overdose do soro TITAN (final de Arkham Asylum), o Palhaço Príncipe do Crime começa a ter sua saúde debilitada, e descobre que está morrendo aos poucos, graças ao efeito do veneno.

Mesmo sequestrando vários médicos e levando eles para dentro de seu esconderijo, não parece haver uma cura, e então ele e Arlequina resolvem incluir Batman nesta equação em busca de uma solução. E tudo isso no meio de uma cidade que está em estado de tensão, dados seus principais líderes de gangues, sendo eles o Pinguim, Duas-Caras e o próprio Coringa.

Ao contrário do game anterior, Batman está armado desde o início, assim como prometido pela Rocksteady, mas não quer dizer que as opções param por aí. Muitas novas opções podem ser desbloqueadas em menos de 2 horas de jogo, no mesmo sistema de upgrades do game anterior. A diferença agora é que por causa da organização mais “orgânica” dos inimigos pelo meio da cidade, você pode arrumar XP facilmente, bastando procurar por grupos e aplicar todos os conhecimentos de combate do game anterior, que são bem semelhantes.

Das novidades dos dispositivos (gadgets), muitos são conseguidos derrotando vilões, ou em parcerias com antigos inimigos, como Mr Freeze, por exemplo, ou em entregas feitas por Alfred quando solicitado. São muitas as opções de upgrades, que criam um verdadeiro senso de recompensa, e que você ainda vai gastar algum tempo coletando mesmo após terminada a história principal.

Na movimentação, Batman pode planar pelos céus de Arkham, recuperando altura com seu arpéu, e fazendo verdadeiros mergulhos para logo em seguida planar por mais tempo, ou para afundar a cabeça de um adversário na nova versão do seu chute planando. E quando entra em combate, novos inimigos aparecem.

Adversários armados com facas e bastões elétricos já são velhos conhecidos por te obrigar a usar uma tática especial, mas agora temos inimigos com armaduras e alguns com escudos improvisados, outros que são resquícios do projeto Titan, além de grandes inimigos de um braço só armados com marretas, e cada um leva sua parte de estratégia para ser derrotado.

Nos combates deste game, vários inimigos podem te atacar ao mesmo tempo, e seu counter pode funcionar com até 3 inimigos, impedindo que seu free-flow seja perdido por estar sendo cercado por mais de 15 adversários ao mesmo tempo. Ainda foram acrescentados alguns golpes especiais como o atordoamento que atinge vários adversários ao seu redor, e mais movimentos de finalização foram adicionados.

No game anterior, o batarangue e a bat-garra podiam ser acionados para dar continuidade ao seu combo, e esse sistema ganhou mais inclusões dos seus dispositivos para infernizar a vida dos inimigos. Transformar a cara dos adversários em purê já era bom antes, só que agora chega a ser ainda mais divertido e não fica repetitivo.

Ainda temos vários inimigos armados com fuzis e rifles de elite (os velhos snipers), mas eles recebem o mesmo tratamento do predador mostrado em Arkham Asylum. Circulando e se escondendo dos inimigos, Batman consegue retirar um a um com os golpes sileciosos, ou simplesmente desativar remotamente as armas sem que seus inimigos percebam, somente para ver a cara de perplexidade deles ao tentar atirar e descobrir uma arma falha.

E se tudo der errado e você se encontrar no alvo de vários tiros, as bombas de fumaça (uma muito bem-vinda adição por sinal) simula um ambiente de fumaça te dando a chance de derrotar seus oponentes, enquanto eles estão cegos. Vale salientar, não existe mais distinção entre “áreas de mano-a-mano” e “áreas de stealth” como havia anteriormente. Em Arkham City, qualquer lugar é bom para se ter uma briga, assim como qualquer topo de prédio é bom para se ter um alvo.

Vários personagens das histórias do Batman aparecem no jogo, e assim como no game anterior, nenhuma aparição soa forçada, ou incluída por “”pressão dos fãs”. Aliás, essa inclusão de personagens algumas vezes age contra você, seja ao procurar pistas sobre alguém e inadvertidamente entrar no território inimigo (o que ocasiona uma chuva de balas ou um pelotão de inimigos raivosos), seja sendo desviado do seu objetivo por causa de um outro chamado, que muitas vezes pode representar uma armadilha.

Mas um ponto onde realmente ficou falho foi o pouco desenvolvimento dado para alguns dos vilões mais memoráveis das histórias, como o Duas-Caras, que aparece numa animação, e depois leva um soco da mulher gato e nunca mais aparece de novo na história principal. Acontece com alguns outros personagens também, mas vamos nos abster de spoilers.

Outro ponto negativo é a batalha com chefes. São poucos pela cidade, assim como Arkham Asylum, mas desta vez elas estão bem mais fáceis, e você consegue descobrir o padrão de ataque depois do segundo ataque. Mesmo jogando no modo mais difícil, em vários momentos achei mais fácil os chefões do que lutar contra um grupo de 20 inimigos variados.

Cada vez que temos um encontro com novos personagens, ou quando coletamos os troféus do Charada, novas informações são desbloqueadas, que você pode conferir na tela do Bat-computador. Alguns toques te levam ao sistema de upgrades e aos desafios do Charada, que mapeiam onde você encontrou ou marcou os troféus, onde viu os reféns dele ou onde estão objetos quebráveis.

O Charada vai te dar mais dor de cabeça dessa vez, mas uma mudança boa na jogabilidade adicionou estratégia ao seu combate, já que alguns inimigos na cidade são também informantes do Charada. Deixa-los por último te garante a chance de um interrogatório, revelando todas as localizações desses ítens colecionáveis numa determinada área, substituindo os mapas do jogo anterior.

Você coleciona os troféus, tira fotos com o detective mode de cenas para responder às questões dadas pelo vilão, e encontra os grandes pontos de interrogação pintados pelo cenário. A novidade são alguns troféus dentro de armadilhas que requerem algumas pequenas tarefas para serem abertas, utilizando seus gadgets.

Ainda sobre personagens, uma inclusão muito bem vinda neste game é a Mulher-Gato. Não somente ela tem sua própria história (inclusa num DLC, que vem nas versões em pré-venda gringa ou na versão básica brasileira), ela tem seus próprios movimentos e objetivos. Caso você tenha o código pra ativar a personagem logo de cara, faça isso.

Uma das primeiras missões do Morcegão é descobrir o que está realmente havendo dentro de Arkham City, e ninguém melhor do que uma espiã pra saber disso, já que a Mulher-Gato usa Arkham como seu quintal.

Habilitando a personagem, você terá acesso à uma trama paralela somente dela, o que incluiu seu próprio sistema de movimentação e combate. Do alto dos prédios, Selina Kyle mergulha para as profundezas de Arkham contando somente com seu chicote e suas habilidades felinas. Basicamente, basta mirar num ponto e acionar o chicote, e mesmo que você não alcance o local exato do pulo, uma mira surge, para ela se deslocar aos seus comandos, em timing perfeito até atingir seu objetivo.

O mapa de Arkham City está pelo menos 4x maior do que o asilo, o que era mais uma promessa da Rocksteady bem cumprida. Mas não é somente uma mapa maior, é realmente caracterizado em diversas áreas, como partes industriais, museus, a antiga delegacia de polícia de Gotham, e o antigo Tribunal de Gotham, que cada cabeça do crime toma cada área como base de operações.

Ainda temos uma seção subterrânea graças ao antigo sistema de metrôs, além de alguns quilometros de tubulação e áreas secretas que podem ser exploradas. Localizada ao Norte de Gotham, os detalhes de decoração e os cartazes já precários devido ao tempo imprimem uma sensação de história ao ambiente, que eventualmente sucumbiu e foi usado às pressas como esse mega-presídio.

Todo o visual do jogo assusta. A Gotham criada para esse jogo, representada pelos cenários de Arkham, é uma dissociação de qualquer outra, seja dos filmes anteriores, seja dos quadrinhos, seja das animações. Toda a cidade tem aquele aspecto cinzento, sombrio e depressivo, com exceção do terreno do Coringa, que leva algumas pinturas florescentes, mantendo o mesmo nível de insanindade do seu principal habitante. Existe uma grande área central, inacessível até perto do fim da história principal, mas que ficou sub-utilizada por ser quase 1/5 do terreno que você acessa por menos de 30 minutos.

Posso afirmar sem dúvida que a espera valeu a pena. Batman: Arkham City é grande, é diversificado, eleva todos os bons aspectos que tínhamos em Arkham Asylum, inova em boas partes, e mesmo com uma crítica ou outra, o jogo parece ser bem fechado, como uma autêntica experiência na vida do Homem-Morcego. Mesmo que você queria se concentrar só na história, você vai investir algo como 10 horas de jogo, e pode expandir esse número até 3 vezes buscando cada detalhe que a cidade tem pra oferecer.

Combater inimigos ficou maior e mais complexo, mas ao mesmo tempo mais gratificante quando você engata aquele combo de 30+ hits. Caçar e neutralizar seus inimigos também ficou mais variado graças aos novos aparelhos, e você terá chance de colocar tudo em prática nos challenges (que chegam em maior quantidade e muito mais variados) após terminada a história principal.

Para quem é fã do Homem-Morcego, e que realmente mergulha no universo criado nos quadrinhos, Arkham City é um verdadeiro fan-service, por respeitar os mais de 60 anos de história do Batman. E pra quem curte games, é um balanço ideal entre uma história densa com vários objetivos e um free-play responsável com horas de opções. Definitivamente, é o melhor jogo de super-herói já feito.

Fonte: Jovem Nerd

C# – Por que usar o coletor de lixo (garbage colector)?

No C#, você nunca pode destruir um objeto. Não há nenhuma sintaxe que faça isso e existem boas razões para os projetistas do C# terem decidido assim. Se fosse sua responsabilidade destruir os objetos, mais cedo ou mais tarde uma das situações abaixo poderia correr:

Você poderia esquecer-se de destruir o objeto, a limpeza não ocorreria e a memória não seria desalocada de volta para o heap. Você poderia ficar sem memória.

Você poderia destruir um objeto ativo. Lembrem-se, os objetos são acessados por referência. Se uma classe mantivesse uma referência a um objeto destruído, essa seria uma referência pendente. A referência pendente terminaria referenciando uma memória não utilizada ou talvez um objeto totalmente diferente na mesma parte da memória. De qualquer maneira, o resultado de uma referência pendente seria indefinido.

Você poderia tentar e destruir o objeto mais de uma vez, e isso poderia ser bem desastroso, dependendo do código do destrutor.

Esses problemas são inaceitáveis em uma linguagem como C#, que coloca a robustez e a segurança no alto de sua lista de metas de projeto. Em função disso, o coletor de lixo é responsável por destruir os objetos para você. O coletor de lixo garante que:

Cada objeto será destruído e seu destrutor, executado. Quando um programa termina todos os objetos realçados serão removidos.

Cada objeto é destruído exatamente uma vez.

Cada objeto é destruído somente quando se torna inacessível; isto é, quando não há referências a ele.

Essas garantias são muito úteis e liberam o programador das enfadonhas tarefas de limpeza, que são passíveis de erro. Elas permitem que você se concentre na lógica do programa e seja mais produtivo.

Quando o coletor de lixo atua?

Essa pode parecer uma pergunta estranha. Afinal de contas o coletor de lixo trabalha quando um objeto não é mais necessário. Isso mesmo, mas ele não entra imediatamente em ação. O coletor de lixo pode ser um processo caro, portanto o runtime só coleta o lixo quando há necessidade (quando ele verifica que a memória disponível está começando a ficar lenta) e, em seguida, coleta o máximo possível. É melhor executar algumas limpezas grandes do que muitas limpezas pequenas.

Você pode invocar o coletor de lixo em um programa chamando o método estático System.GC.Collect(). Entretanto, exceto em alguns casos, isso não é recomendado. O método System.GC.Collect() inicia o coletor de lixo, mas o processo é executado de modo assíncrono e quando a chamada do método termina você ainda não sabe se seus objetos foram destruídos. Permita que o runtime decida qual o melhor momento de coletar o lixo.

Outra característica do coletor de lixo é que você não sabe a ordem na qual os objetos serão destruídos. O fundamental é: os destrutores não são executados até que os objetos sejam coletados como lixo. Se você escrever um destrutor, sabe que ele será executado, apenas não sabe quando.

No próximo artigo, vou explicar como funciona o coletor de lixo, com gerenciamento de recursos, métodos de descarte seguro e alguns exemplos.