Recent Posts
Neste fim de semana me mudei de mala e cuia, com direito a caminhão de mudança e tudo mais. Literalmente mudei.
Tudo muito legal, tudo muito bom até que tentei conectar meu Vivo Zap. PAM ! Até consigo autenticar mas navegar é inviável. Seria mais rápido conectar por uma conexão discada. Isso, se a casa já tivesse um telefone instalado, claro…
Pelo próximos dias, estarei ilhado.
Instalei o Opera Mini no meu Black Berry Bold. Não é muito melhor que o navegador padrão do BB. Mas, pelo menos consegue abrir páginas PHP com maior facilidade.
O Browser original do BB Bold não consegue abrir, por exemplo, o Forum do meu site. Neste quesito, ponto para o Opera Mini.
Há poucos instantes acabei o meu trabalho. Trabalhei durante todo o domingo. Cansado, resolvi ligar na Net e solicitei o jogo Corinthians x Goiás, e quem sabe, tentar aproveitar o restinho do domingo.
Fui informado que o canal seria liberado em 15 minutos. Não aconteceu.
40 minutos se passaram, até que eu liguei novamente perguntando o que estava acontecendo e o por que da demora. Eis que surge uma atendente que GRITOU COMIGO no telefone e disse que EU NUNCA HAVIA SOLICITADO nada na NET.
Isso mesmo. Ela disse que a ligação inicial nunca existiu e que eu inventei isso. Ou seja, ela me chamou de louco. Pedi para que ela me transferisse para a supervisão para eu formalizar a reclamação. Não o fez. E pior, desligou a ligação.
Lamentável. Esse país é uma piada. E nós, consumidores somos os palhaços da história. Não tenho palavras para descrever como me sinto. Pois, convenhamos, vou trocar para qual ? Pela Telefônica, recém multada por problemas no atendimento ?
O que me restou a fazer foi abrir um solicitação junto a Anatel. Quem quiser fazer o mesmo, o link é este. Só me resta aguardar.
E como para o pior não há limites, só falta a Anatel não me retornar. Espero que isso não aconteça.
PS : o site da Anatel não funciona corretamente no FireFox para Windows.
#fail.
Print do navegador FireFox 3.5
Hoje meu FireFox foi atualizado automaticamente. Um novo complemento instalado foi o Persona, que permite você escolher uma roupagem personalizada para o seu navegador.
Tecnicamente inútil. Mas não da para negar que o visual pode ficar bem bacana – ou bem feio, dependendo o gosto de cada um.
Gostei do logotipo. É a máscara da raposa e logo abaixo um cabide com várias “roupas”. Muito bem bolado.
Já escrevi aqui o quanto é difícil gerenciar egos. Já escrevi aqui também o quanto é difícil gerenciar pessoas. Como se já não bastassem essas dificuldades, existe uma terceira etapa na vida de alguém com o cargo gerencial que não se pode evitar : a dificuldade de escolher pessoas.
Contratar uma pessoa é uma arte. Arte no sentido próprio da palavra. Se preferir o leitor pode ao invés da palavra arte, utilizar a palavra Ciência. Desse jeito mesmo, com letra maiúscula. O resultado final será o mesmo.
No começo, quando você sai de uma posição operacional e passa para um primeiro nível de coordenação tudo é novo. As atividades, o tratamento das pessoas de outras áreas, o tratamento das pessoas que até então eram seus pares e agora passam a responder para você e assim por diante. E apesar das novidades, você acredita já ser capaz de entrar em uma sala para entrevistar uma pessoa e com uma simples conversa saber tudo o que precisa para tomar uma decisão : contratar ou não essa pessoa.
Decisão essa que pode mudar significativamente a dinâmica da sua equipe, seja para melhor ou para pior. Quando comecei a formar minha primeira equipe, muitas pessoas me diziam que eu levaria jeito para dar aulas e após ouvir isso algumas vezes, me aventurei nesse desafio. Não me arrependi. E não, não estou afirmando que levo jeito. Seria pretensão demais…
Posso dizer apenas que gosto do desafio de entrar em uma sala de aula e passar o pouco que sei para outras pessoas. Sempre entro na sala de aula com mesmo objetivo : agregar algo de bom aos meus alunos.
E o que uma coisa ( contratar pessoas) tem a ver com outra (lecionar) ? Vou tentar explicar …
Amanhã entrevistarei 6 ou 7 candidatos para uma vaga na minha equipe. Preparei cuidadosamente uma prova. Li os currículos dos candidatos com atenção. Me atentei a cada detalhe. Investi 2 horas do meu dia nisso – e a considerar pelo ritmo de trabalho que estou enfrentando, duas horas é uma eternidade.
Depois de algumas dezenas de vezes entrevistando pessoas, você acaba desenvolvendo “técnicas pessoais” de como lidar e como se comportar nessa situação. Aprende a conduzir a conversa de forma produtiva. E produtividade nesse caso representa apenas uma coisa : entender o candidato. Saber quem realmente ele é.
Apesar dessa experiência, o fato de dar aulas para um curso de tecnologia tem me ajudado a refletir (e muito) sobre minha conduta, não só nas entrevistas mas como em todo o processo seletivo. Em sala de aula, com mais tempo e sem carregar a “tensão” de uma entrevista de emprego, os alunos ou por que não dizer, “candidatos” a uma vaga em qualquer empresa, se expressam de outra forma. Utilizam outra linguagem, tem outras reações. Parecem ser outras pessoas !
Essa observação me leva a crer o seguinte : o método de entrevista é, em geral, inadequado e/ou pouco eficiente. Em sala de aula consigo observar muito mais coisas do que em uma entrevista, mesmo sem conversar com o aluno de forma direta. Por exemplo, vez ou outra sou surpreendido por aquele aluno que tem uma ótima desenvoltura, conversa bem e que no momento de executar uma tarefa em grupo não consegue interagir com os demais.
Ou ainda, vem até mim para tirar uma dúvida sobre o exercício da aula aquele aluno que eu nunca tinha ouvido a voz e quando observo o resultado do seu trabalho fico admirado com tamanha eficiência ! Aquele cara que qualquer um diria que não está sequer acordado, é o cara que de repente lhe traz a melhor solução do exercício ! Como assim ?!?!
Tem também aqueles que as vezes tem dificuldade de entender um ou outro item mas que me impressionam pela persistência e dedicação. Esses também são admiráveis. Tentam, tentam, tentam até conseguir. Quando os observo, de certa forma me identifico com eles. Sua determinação lembra a minha.
E existem muitos outros perfis. Como uma vez me disse um grande amigo, quanto maior o universo amostral, maior a chance de encontrar situações extremas. E isso em uma sala de aula é um fato.
Com tudo isso, chego a conclusão que o dia-a-dia em sala de aula talvez possa ser uma forma de conhecer um candidato. Na entrevista de emprego você até consegue medir algumas coisas, como por exemplo, o raciocínio lógico. Mas existem pontos que considero fundamentais que não consigo imaginar como medir de forma eficiente, como por exemplo habilidade para trabalhar em equipe, espírito coletivo, coleguismo, paciência, comprometimento, persistência, etc.
E nem pense em me dizer que as tais “dinâmicas de grupo” servem para isso, pois não servem. E não servem por um único motivo : elas reunem pessoas que estão concientes que tem alguém as avaliando e suas condutas não são as mesmas que teriam em outras situações. É disso que estou falando. Estou falando condições normais, como em uma sala de aula.
Ao entrevistar alguém a partir de agora, esse será o meu novo objetivo : tentar de alguma forma visualizar essa pessoa em condições normais, situações do dia-a-dia. Se um dia eu conseguir isso, com certeza farei melhores contratações.
É claro que essa é uma missão (quase) impossível, mas não é por isso que vou deixar de tentar. No pior caso, as coisas continuarão como são atualmente. Uma mistura de “técnica”, experiência e um bocado de sorte…
No dia da Independência, a homenagem do Google. Se bem que, eu pelo menos, sou cada dia mais dependente do Google.
Desde os primeiros modelos dos celulares, sempre tive interesse em conhecer suas novas funcionalidades, recursos e formas. Hoje, estava pensando e estes mesmos celulares que eu sempre queria trocar tem me atrapalhado um pouco.
Carregar um celular é ruim. Carregar 3 celulares é muito pior. Além do meu telefone pessoal, agora uso um BB e um Nextel.
Pode parecer bobagem, mas com certeza os motociclistas de plantão sabem o quanto um item a mais faz diferença em um dia de chuva. Quem anda de moto conta os itens que pode carregar a dedo. Qualquer coisa a mais atrapalha.
Black Berry Bold 9000
Nokia e71
Nextel Aí vem a pergunta clássica : para que tudo isso ?!!? Explico. O de uso pessoal, é por motivos óbvios. O BB é corporativo e serve para falar entre as pessoas da equipe e tem ferramentas corporativas e de organização pessoal. Contudo, no mercado financeiro não é permitido utilização de aparelhos celulares dentro das corretoras, especialmente para aqueles que tem acesso a mesa de operações por questões de segurança. É nessa hora que entra o rádio, que não permite fazer ou receber chamadas celulares e sim, apenas se comunicar com as pessoas do grupo. Funciona como um ramal sem fio, inclusive quando estou fora da mesa ou mesmo fora da empresa...
A estratégia é ótima, mas carregar continua sendo chato. A solução deste “problema” seria a convergência destes aparelhos. Algo como um 3 em 1 que me permitisse, de forma segura, atender a todos os requisitos e funcionalidades que tenho com 3 aparelhos distintos. Quando esse dia chegar, minha mala vai ficar mais leve e eu, mais feliz.
Para quem tem os primeiros contatos com a Linguagem C, uma boa opção é utilizar o Visual Studio 2005 para dar os primeiros passos.
No vídeo acima, mostro como criar a primeira aplicação Console Application (“Hello world !”).
Reproduzo abaixo o conteúdo de um tópico deixado no Forum. Ficou tão bem elaborado que eu não poderia deixar de publica-lo no formato de um post.
O autor é o Celso Endo , aluno do 4º semestre do curso de Análise e Desenvolvimento de Sistemas (POO II), a quem eu pedi autorização para publicar o conteúdo e que gentilmente me permitiu compartilha-lo com os leitores deste blog.
Lá vai…
“Bom, alguns por aí andam dizendo que "ainda hoje existem pessoas malucas que gostam de javascript"... 
Eu com certeza faço parte dessa turma e com muito orgulho! 
E se você pretende desenvolver aplicativos para ambiente web, você também deveria se juntar a essas "pessoas malucas".
Anter de eu falar mais um pouco do javascript, aqui vai um resumo do que vem acontecendo de uns anos para cá:
Fato é que muitas empresas estão deixando os softwares desktop de lado e partindo para softwares em ambiente web. Isso porque com a tecnologia avançando nesse ritmo acelerado, as pessoas não precisam mais depender de estar fisicamente em uma empresa para poder tomar devidas ações, responder emails, etc... As pessoas podem fazer isso aonde quer que estejam, seja via um smartphone (viva ao E71! rs...) ou uma conexão wi-fi no aeroporto, cafés, etc.
Agora imaginem uma pessoa que há anos utiliza um software desktop de CRM ou qualquer outro tipo (contábeis, ERP's, outlooks, word, excel, etc...). Uma característica comum a todos esses softwares desktops utilizados no dia-a-dia de uma empresa, independente se o software é Microsoft ou se o software é para Linux, a característica comum é a facilidade (concordo que às vezes nem tanto..) de manuseio, riqueza nos detalhes de botões, janelas, tooltips, coisas para se arrastar pra lá, pra cá... enfim... USABILIDADE e, principalmente, INTERATIVIDADE do software com o usuário.
Se essa pessoa optar por trocar seu antigo software de CRM por um software CRM na web, o mínimo que ele espera são as funcionalidades e "frescuras" (eu costumo chamar de frescuras...rs) que os softwares desktops oferecem. Se ela acessar um aplicativo web e simplesmente ver um formulário mal formatado, numa página com fundo cinza, tudo estático e "morto", com certeza a pessoa vai se arrepender de ter feito a troca e logo vai querer voltar a usar seu bom e velho CRM.
E daí vem o termo RIA (Rich Internet Applications ou Aplicações ricas para internet). E é nessa hora que entra o tão poderoso Javascript e outras muitas tecnologias que vem crescendo com esse boom de softwares para web: Silverlight, Flex, etc...
Mas calma! Todo mundo quando fala de aplicativos para web ou web 2.0, sempre fala do AJAX... onde entra o AJAX nessa história? hmmmm... o Ajax... um componente poderoso e quase indispensável para se desenvolver RIA's... Basicamente, o AJAX (Assynchronous JAVASCRIPT and XML) é um componente (XmlHttpRequest) para ser utilizado, como no próprio nome diz, com Javascript (aquela coisa de maluco....) que permite ao desenvolvedor fazer requisições ASSÍNCRONAS ao servidor, ou seja, se você está desenvolvendo um aplicativo utilizando AJAX, você automaticamente está também utilizando Javascript.
Resumo da história: algumas pessoas dizem que fazem aplicações para web utlizando ajax, mas são contra o javascript.... pra mim isso é você se contrariar... afinal, você não usa os recursos do Ajax sem utilizar javascript. O Javascript é o responsável por fazer o uso desse componente. E acho que é quase impossível desenvolver um aplicativo rico sem encostar a mão em algum código em javascript.
Mas cuidado! Nem tudo é mil maravilhas. Os aplicativos para web devem ser bonitos, sim, devem. Devem ser cheio de frescuras pro usuário se sentir num ambiente desktop, sim, devem. Devem fornecer o máximo de interação com o usuário, sim, com certeza. Mas tudo isso tem um custo: memória. Não, não é a memória de seu servidor que está em jogo. Não se esqueça: javascript é client-side e não server-side (como php, asp.net, etc...). Isso significa que todo código javascript (e ajax) é interpretado no client, ou seja, no browser do usuário. Em outras palavras: tudo pode ser lindo e maravilhoso, mas se fizer mal feito você consegue travar (literalmente) o browser do usuário e acabar com a memória ram do usuário. E aí entramos em outro tópico indispensável para esse tipo de aplicativo: como funciona o garbage collector dos browsers? Como os browsers fazem a limpeza da memória alocada em uma página web? E, com isso, entramos em outro tópico: infelizmente o garbage collector dos browsers não seguem um padrão (pra variar....) e cada um tem sua forma de alocar e desalocar a memória de uma página. Isso é assunto para outro tópico...
Enfim, o javascript é uma linguagem poderosíssima, mas deve ser bem utilizado. Com javascript você consegue praticamente todas as "frescuras" de um software desktop (drag & drops, redimensionamentos, popups (não popups de browsers, mas sim os chamados dialogs), validações "on-the-fly" de campos de formulário, etc...). Isso aliado ao Ajax, com certeza uma combinação perfeita para fazer um ótimo aplicativo web. Claro que além disso você vai precisar de uma linguagem server-side (eu sou suspeito pra falar, mas eu diria php... rs... mas existem outras tantas que obviamente podem ser utilizadas).
Só pra terminar: Todos devem saber (ou se não souber e pretendem aprender javascript..) que para fazer uma página em javascript cross-browser (que funcione nos principais browsers do mercado) é um parto! Cada browser interpreta de um jeito e no fim se você não fizer algo bem estruturado, tudo que você vai ver em seu código são milhões de if's para fazer tratamento dos browsers. Com isso surgiram muitos e muitos frameworks feitos em javascript feitos especialmente para você desenvolver aplicações ricas em detalhes, sem ter que se preocupar com a compatibilidade nos browsers (os frameworks cuidam disso). Geralmentes esses frameworks já são estruturados de uma forma também que não irá sobrecarregar tanto a memória do client (isso não é regra!!!). A idéia principal desses frameworks é fazer com que o desenvolvedor não perca tempo se preocupando se o código será cross-browser ou não e sim se preocupar nas regras de negócio do código. Isso facilita e muito a vida dos desenvolvedores, mas as vezes atrapalha (chegando ao ponto das pessoas se amarrarem muito aos frameworks e esquecerem que ajax e javascript andam juntos).
Segue abaixo alguns exemplos dos frameworks mais utilizados hoje em dia para desenvolver aplicações web:
http://www.extjs.com (em termos de frescuras, na minha opinião, é o mais poderoso de todos...)
http://developer.yahoo.com/yui
http://www.dojotoolkit.org
http://www.jquery.com (pelo ranking do google o Jquery é o framework mais utilizado atualmente....)
http://www.backbase.com (um dos mais complexos que eu já vi...)
http://www.prototypejs.org (como fui esquecer desse... o que eu mais uso atualmente...rs)
Na página de todos, existem centenas de exemplos do que é possível fazer com eles. Surpreenda-se! Tudo com JAVASCRIPT e ajax!
E para quem se interessar com performance do javascript, segue algumas dicas de Nicholas Zakas (mais um maluco expert em javascript): http://james.padolsey.com/javascript/zakas-javascript-performance-tips/
E também não deixem de visitar o site de Douglas Crockford (mais um maluco expert no assunto!): http://www.crockford.com”
O assunto do momento é a únião anunciada entre Amazon, Microsoft e Yahoo contra o Google, na tentativa de evitar o que, segundo eles, seria o monopólio dos sistemas de bibliotecas.
Um dos inúmeros artigos que falam sobre o assunto é este, do IDG Now. Mas o que eu não li em lugar algum é como isso vai prejudicar o usuário. Até agora, o zum zum zum me parece mais uma briga marketing/ política do que qualquer outra coisa.
Aliás, Microsoft e Yahoo uniram-se recentemente para assuntos relacionados aos serviços de busca, conforme publicado no site do próprio Yahoo.
E agora se unem pelo bem a humanidade, da liberdade de expressão, da indústria de livros, para evitar monopólios, etc ?
Ok. Agora conta a do papagaio…
Depois das três primeiras aulas de Linguagem e Técnicas de Programação, já falamos sobre algoritmos, fluxogramas e chegamos ao momento de escrever o primeiro pseudocódigo.
O objetivo é escrever um pseudocódigo que , leia dois números dados pelo usuário, efetue a soma e mostre o resultado para o usuário.
Desta forma, temos :
//nome do programa
Programa soma
//declaração de variáveis
Var
//variáveis primeiroValor, segundoValor e resultado são do tipo inteiro
primeiroValor, segundoValor, resultado : inteiro
//bloco de processamento
inicio
//escreve a mensagem para o usuário informar o primeiro número
escreva : "Informe o primeiro valor :"
//lê o número informado e atribui o valor na variável primeiroValor
leia primeiroValor
//escreve a mensagem para o usuário informar o segundo número
escreva : "Informe o segundo valor :"
//lê o número informado e atribui o valor na variável segundoValor
leia segundoValor
//atribui o resultado da soma de A + B , na variável X
resultado ← primeiroValor + segundoValor
//escreve a mensagem para informar o resultado
escreva : "O resultado da soma é :"
//escreve para o usuário o resultado propriamente dito
escreva resultado
fim
Texto extraído de um bate-papo por e-mail e no Forum com alunos da turma de Programação Orientada a Objetos II :
Dúvida :
Minha dúvida sobre interfaces e classes abstratas é mais relacionada à utilização/prática das mesmas. Vou pegar como exemplo o seu próprio exemplo da sala... sobre as 2 telas com o user control contendo 3 botões.... O user control seria uma classe que implementa a interface, digamos, Crud (responsável pelas ações dos botões...), certo? Nessa classe, como ela implementa essa interface, ela vai declarar todos os métodos (remover, incluir, etc...) dessa interface, porém não vai implementá-las... apenas declarar, certo? Aí na tela de cadastro de clientes (seu exemplo preferido...rs), essa classe (de clientes) também vai implementar a interface Crud, pois um contrato deve ter pelo menos 2 pessoas que o assinem, certo? E dentro da classe clientes, vai existir um objeto da classe user control... certo? Aí o coitado que tá lá navegando no sistema preenche o bendito formulário e clica, por exemplo, em incluir. Ele está clicando em um botão que está dentro da classe user control..... minha pergunta é: a classe user control tem que chamar o metodo incluir, mas não dela própria.... e sim da classe clientes... ou seja.... a classe user control tem que chamar um método da classe que está instanciando ela... é isso mesmo? eu não programo em C#, mas em C# como que seria feito isso?
outra questão que me surgiu agora: apesar da gente falar que a interface é como um contrato onde pelo menos 2 elementos devem assiná-lo (implementá-lo), isso é regra? Digo, SEMPRE que eu tiver interface, obrigatoriamente eu vou ter que ter pelo menos 2 classes que a implementem? eu sei que na prática, no código, não é regra, porque nada me impede de ter uma interface e que só uma classe a implemente... mas no conceito de interfaces... isso é uma regra?
Agora, voltando um pouco na parte de utilização de interfaces e classes abstratas... no semestre passado, após o professor explicar o que era interface e classe abstrata, da forma como ele explicou, pra mim e acho que pra todos que assistiram essas aulas, ficou na cabeça que a interface é uma gambiarra (um workaround...) pro problema de herança multipla porque uma classe pode implementar várias interfaces, porém só pode extender de uma única outra classe (pelo menos no c#)... foi difícil de engolir isso, mas eu até cheguei a perguntar pra ele em que situações eu devo criar uma classe abstrata ou uma interface... ele não soube me explicar muito bem com algum exemplo prático, mas resumindo, ele disse: "nas linguagens de heranca simples (caso do c#), qdo vc está modelando as classes você tem que ter em mente se essa classe algum dia poderá extender de mais de uma classe... se sim, você cria interfaces e não "gasta" a única herança que você tem.. reserva a única herança que você tem para uma classe que você tem certeza que deve ser abstrata
Minha opinião :
Aqui está o exemplo da Barra.
Agora... sobre a Interface ser uma "gambiarra" para compensar a falta da herança múltipla:
"Muitos vezes o programador é confrontado com o complicado problema de decidir de qualquer classe herdar. Há muitas situações em que seria útil poder herdar de mais de uma classe. Por exemplo, imaginemos que temos uma classe-base que representa leitores de CD, assim como uma outra classe-base que representa leitores de cassetes. De qual classe-base deveria herdar uma classe que represente uma aparelhagem de som ?
Talvez, neste caso fizesse mais sentido utilizar composição (juntar a classe cassete e cd em uma só). No entanto, ao utilizar composição perdemos a capacidade de converter um objeto numa classe-base e utilizá-lo independentemente das suas especificidades.
Para resolver este tipo de problemas, em C# existe o conceito de interface. Uma interface permite obter quase a totalidade dos benefícios da herança múltipla, mas sem os seus problemas. Uma interface espeficifica um conjunto de de métodos que tem que ser implementados por uma classe. Uma classe pode implementar uma ou mais interfaces, bastando para isso indicar quais as interfaces implementadas, tendo os respectivos métodos definidos. As interfaces são extremamente importantes e amplamente utilizadas tanto na plataforma .Net como na programação do dia-a-dia."
Definição do livro C# 2.0
Minha opinião : não entendo como uma gambiarra por conta da falta do recurso da herança múltipla. Entendo sim que é uma característica da plataforma .Net, e por sinal, muito útil.
Outra parte : interface é como um contrato onde pelo menos 2 elementos ?
Como foi bem lembrado na pergunta, o .Net permite que seja uma criada uma interface e que esta interface seja assinada por apenas um único objeto.
Pensando no sentido de Contrato, como as literaturas explicam, um contrato nunca é assinado sozinho. Por exemplo, se você fizer o contrato de compra e venda de uma casa, tanto o vendedor como o comprador assinam o mesmo contrato. Logo, duas assinaturas.
Isso nos leva a sua dúvida. Se duas pessoas assinam um contrato, faria sentido, de forma análoga, que apenas um objeto assinasse a interface ?
Difícil dizer que faz sentido. Eu, por exemplo, não tenho nenhum exemplo prático nos sistemas que desenvolvi que a interface foi assinada por um único objeto.
Porém, um argumento que talvez faça sentido seria o seguinte :
Pense em um objeto que seja responsável pela autenticação de um usuário. Normalmente, em uma aplicação orientada a objetos, esse objeto é único. Vamos supor que, para atender as regras de negócios da sua empresa ou a padrões de segurança, para que um usuário seja autenticado, você deva seguir um conjunto obrigatório de procedimentos.
A utilização da Interface, neste caso, seria uma forma de garantir que o objeto responsável pela autenticação implemente os passos estipulados. Apesar de que, o fato da implementação do método pode não ter "recheio" ( um método vazio) e isso não garantiria que o passo seria executado.
Por outro lado, tornaria a implementação formalizada e, arquiteturalmente falando, tornaria a leitura do código bastante clara.
Desta forma, para mim, faria sentido sim ter uma interface implementada por um único objeto...
Não encontrei literatura que diga de forma explícita que isso seria certo ou errado. Desta forma, infelizmente, preciso embasar a resposta apenas em uma opinião pessoal.
Por fim, falando das classes abstratas, podemos dizer que ela traz consigo as características de uma classe base aliada as características de CONTRATO como acontece com a interface. Porém, como você já herdou uma vez, não poderá ter nova herança na classe-filha.
Nesse momento você pode fazer uma opção. Ao invés de utilizar a classe abstrata, você pode ter na classe-base apenas as operações e propriedades que você tem certeza que serão genéricos e, para operações que você deseja garantir que existam, mas não tem como implementar já na classe-base a operação propriamente dita, você pode utilizar a Interface para fazer o papel do CONTRATO, obrigando a classe-filha a ter o método em questão.
E você, o que acha ?
Texto extraído de um bate-papo por e-mail com alunos da turma de Linguagem e Técnica de Programação :
Dúvida :
Fiquei com uma duvida que é a seguinte. Aqui no serviço, faço algumas queries pra tirar relatórios ou mesmo fuçar um pouco. Além do BI que temos que usar e eu faço algumas manutenções. Gostaria de saber se isso vai me ajudar alguma coisa na área de programação, que é uma área que particularmente estou gostando muito e gostaria de me aprofundar.
Outra coisa, gostaria de já dar uma olhadinha mais de perto neste mundo e começar a fazer alguns esboços ... apenas para teste mesmo.
Gostaria que o Sr. me indicasse um software pra eu baixar e começar a dar uma olhadinha mais de perto.
Pode ter certeza que não vou atropelar as aulas que o sr. esta passando, é pq aqui no serviço tenho algumas facilidades para isso e gostaria de começar a usufruir delas já!
Minha opinião :
Query é pode ser encarada como uma forma de programação. A diferença é que seria uma programação onde o produto final do "programa" é a extração (ou inclusão, exclusão, atualização) de dados da base ou, por exemplo, uma Stored Procedure (View, Trigger, etc) que será executada por outra aplicação.
Com certeza vai te ajudar (e muito!).
Afinal, na criação de uma query você desenvolve uma sequência de passos que tem como objetivo uma saída ( ou entrada). Além disso, existe uma lógica nesse fluxo. Em outras palavras, a query é um algoritmo também !
Além de te ajudar com a parte lógica e estrutural, em geral as aplicações acessam a base de dados e os desenvolvedores precisam ter o mínimo de conhecimento nisso. Ou seja, podemos dizer que você "começou de traz para frente".
Sob o ponto de vista didático, normalmente, ensina-se primeiro a construção de aplicações e depois acessa-se a base de dados. Você já conhece a base de dados e agora vai partir para as aplicações. Considere-se um privilegiado !
Para começar a brincar com a Linguagem C, o DevC++ é a ferramenta mais indicada, por ser mais simples de instalar. Atende perfeitamente para este primeiro momento. Depois, você pode passar para o Eclipse, NetBeans, Visual Studio, etc...
O uso da ferramenta, vai muito de gosto.No fim das contas, o efeito prático é basicamente o mesmo. Meu único alerta é o seguinte : cuidado com os recursos que estas ferramentas oferecem para auto-completar o código. Este tipo de recurso aumenta muito a produtividade e é utilizado no dia-a-dia de um desenvolvedor.
Contudo, para fins didáticos, é melhor que você evite utiliza-los ( ou se apegar a eles) para que você não encontre dificuldade no momento da prova, por exemplo, onde você fará no papel e não terá ajuda deste tipo de recurso.
No mais, é só seguir em frente e se divertir.
E você, o que acha ?
Durante muito tempo acreditei que desenvolver sistemas era uma tarefa complicada. Acreditava que estratégias arquiteturais, plataformas, infra-estruturas e afins eram temas realmente desafiadores.
Acreditava. Não acredito mais. Desenvolver sistemas é uma tarefa que pode ser classificada como extremamente fácil, se compararmos com uma outra tarefa que está intimamente ligada com o desenvolvimento propriamente dito : o gerenciamento de egos.
Oracle, Sql Server, Linux, Windows, Sun, Scrum e qualquer outro termo técnico é muito fácil, comparado com o fator humano. Gerenciar egos sim, é uma missão realmente difícil.
Quando fiz o curso de extensão sobre PMBOK na Unicamp, aprendi que uma das 9 áreas de conhecimento do método é o Gerenciamento de Pessoas (Stakeholders). No começo não fazia muito sentido ter uma área de conhecimento inteira voltada para isso. Mas com o passar do tempo, passei a entender o porque. Aprendi que existem 3 tipos de stakeholders :
Incentivador é o cara que apoia o projeto. Mas apoia, desde que o projeto lhe favoreça, direta ou indiretamente.
Os Neutros são aqueles que não se manifestam, pois o projeto em si não lhes traz benefícios, nem prejuízos. Desta forma, eles não se importam em participar.
Já os Contrários… Ah os Contrários… Esses sim, são os que mais ativamente participam do projeto. Aparecem rapidamente quando percebem que o projeto pode, segundo suas pobres visões, lhes prejudicar de alguma forma.
Para exemplificar, vamos pensar que o projeto é a mudança do layout físico da empresa. Os Incentivadores aparecerão assim que visualizarem os próprios benefícios. Aquele funcionário que tinha uma sala bem pequena e, com o novo projeto, vai ganhar uma sala enorme, com vista privilegiada passa a apoiar o projeto como se fosse o projeto de sua vida !
Os Neutros, serão aqueles que o novo layout não os afetará. Se tinham salas grandes, continuarão tendo. Se tinham salas, pequenas, também não mudarão. Neste momento o funcionário percebe que para ele, a mudança de layout não trará benefícios, nem prejuízos. Desta forma, fica neutro. Se isola. Assiste de camarote o desenrolar do projeto.
Os Contrários surgem assim que, perdem espaço. Percebem que a sala enorme que tinham até o momento, irá se transformar em uma modesta sala, com uma vista nem tão privilegiada. Aí sim, ele aparece e com muita vontade de mostrar que o projeto não é bom. Não que ele esteja querendo defender seus interesses. Não ! Longe disso ! Ele quer apenas, segundo a sua ótica, o “bem da empresa”…
Essa história parece um pouco exagerada. Mas não é. Acredite. Infelizmente não há exagero algum nisso. E pior, é um cenário comum.
Atualmente estamos com um projeto em andamento, que eu poderia classificar como uma “mistura de ERP com CRM”. Adivinhem qual a maior dificuldade !?
Quem disse, gerenciar as pessoas, infelizmente, acertou. Dando um passo para trás, fica fácil de enxergar isso. Cristalino como água. As pessoas esquecem que o objetivo principal é a implantação do sistema e os benefícios que tal implantação traria para a empresa e focam única e exclusivamente em interesses menores, individuais.
Como produto disso vemos, todos os dias, horas e mais horas de trabalho desperdiçadas com retrabalho e idéias mirabolantes que na prática, não funcionam.
E como resultado, temos : um sistema em desenvolvimento correndo sério risco de nascer com data de morte marcada. Isso, sem contar nos inúmeros problemas estruturais que ele terá em função de mudanças mau planejadas e sem nenhum critério, implicando em incontáveis prejuízos para a empresa.
Por isso, digo e repito. Desenvolver sistemas é moleza ! Difícil, é gerenciar os egos.
Triste. Mas real.
UPDATED : tive aulas de PMBOK com o Prof Alvaro Camargo, que além de um grande amigo, é um gerente de projetos excepcional e grande professor.
Texto extraído de um bate-papo com aluno no forum :
Dúvida :
Gostaria de saber se analistas/desenvolvedores tem que saber criar websites
Minha opinião :
Sua pergunta pode ser respondida de três formas :
1) Todo conhecimento é sempre bem vindo. Ou seja, quanto mais conhecimento tiver, mais oportunidades (inclusive de trabalho) você terá. Desta forma, a resposta para sua pergunta é SIM.
2) Sistemas em ambiente Web (web based), sejam eles sites ou qualquer outro tipo de sistema, estão presentes na (imensa) maioria das empresas. Ao passo que sistemas Desktop (instalados localmente) cada vez perdem mais espaço por serem mais complicados de manter, controlar versões, etc (podemos falar sobre isso e escrever uma lista enorme de razões), além de serem dependentes do sistema operacional em que rodam. O mesmo não acontece com sistemas web, que precisam apenas de navegador (browser) para que possam ser executados, não importando se a máquina do usuário tem sistema operacional Linux, Windows ou qualquer outro. Por esses (e muitos outros motivos) , a resposta (para a sua pergunta) também é SIM.
3) Na contra-mão das duas respostas anteriores, nem todos os sistemas podem ser web based. Por exemplo : sistemas embarcados ( que rodam em aviões, trens, elevadores, etc). Esse tipo de sistema (tradicionalmente) não é web e na maioria dos casos, não tem sequer interface com usuário. Outro exemplo : sistemas de monitoração - utilizados para monitorar serviços e processos. E existem centenas de outros cenários onde sistemas web não se encaixam. Nesses casos, para o desenvolvedor que não tem esse know-how (conhecimento), não faz muita diferença pois ele não aplica no seu dia-a-dia. Nesse contexto, a resposta para a sua pergunta é NÃO.
Por fim, a MINHA opinião ( não é uma lei universal, é apenas o que eu acredito) : um desenvolvedor tem que estar pronto para todo e qualquer tipo de projeto. Do mais simples aos mais complexos. Desta forma, com maior versatilidade, sempre terá boas oportunidades sem precisar se preocupar em um contexto específico.
E você, o que acha ?
Texto extraído de um bate-papo com um aluno no forum :
Dúvida :
Onde eu trabalho, utilizo a base de dados em postgre e já utilizei Oracle e gostei muito. Para se ter oracle, devo pagar uma fortuna por isso nessa empresa nova utilizamos o que é de graça. A minha dúvida é. Em que condições eu teria obrigatoriamente de comprar o Oracle ? Seria com um número de dados suficientemente grande ou acesso mais rápido ou quando ?
Digo porque minha empresa tem crescido bastante. Até quando o Postgres vai aguentar ?
Minha opinião :
Falando do Postgres...
Sua dúvida é muito pertinente. Contudo, não existe uma resposta exata, matemática, como por exemplo "você deve trocar sua base quando...".
Essa é uma decisão difícil, especialmente porque envolve custos. Não apenas o custo do Oracle, mas também de hardware, capacitação humana, adaptação dos sistemas legados (sistemas que já existem) ,etc, etc, etc.
O que eu sugiro sempre é fazer um acompanhamento rigoroso do crescimento da base e da utilização do sistema. Tenha em mente que o sistema atende a uma determinada realidade da sua empresa e que essa realidade pode mudar.
Exemplificando : sua empresa abre uma filial e dobra o número de funcionários, consequentemente de usuários. Ou ainda, sua empresa lança um novo produto e as vendas se multiplicam, etc, etc, etc
O comportamento da base pode mudar de acordo com rumo que a empresa segue e por esse motivo, para que você tenha margem de manobra (antecipar ao problema) é importante que você entenda bem o seguinte : eu tenho uma base de dados, que tem um número x de objetos, um número y de registros, um número z de acessos simultâneos, tamanho h de espaço físico ocupado e assim por diante. Tenha todas as métricas em mãos. Conheça sua base em detalhes ( é isso que o DBA faz, diga-se de passagem).
Munido dessas informações, é vital que você acompanhe esses números e sua evolução. Em paralelo a isso, você deve ter métricas de performance.
Após saber tudo isso, aí sim, você terá condições de saber se, no seu contexto, chegou a hora ou não de buscar outras ferramentas e/ou soluções.
Os números não mentem. Veja as recomendações do fabricante para situações de concorrência de acesso e crescimento das bases. Procure aplicar as melhores práticas recomendadas.
Talvez você chegue a conclusão que, no seu contexto, você não vai precisar mudar tão cedo de base (até pq a base que você utiliza é uma ótima opção).
Lembre-se sempre : não importa qual a ferramenta, se você não sabe como está o seu cenário.
E você, o que acha ?
O Twitpic funciona como o album de fotos do Twitter. Além disso, também é possível enviar também fotos a partir do telefone celular.
O mais interessante é o que o procedimento é exatamente igual ao que é feito pelo computador : selecionar foto, upload e pronto. Simples assim.
Abaixo uma prova de conceito :
Foto mau batida com um Nokia E51 : Viaduto do Chá x R. Líbero Badaró – São Paulo
Outra alternativa, mas menos atratativa, é enviar um e-mail com a foto. Também pode ser feito a partir do celular. Porém, neste caso, fica menos funcional.
Nunca tinha reparado nestas informações de segurança do GMAIL. Veja abaixo o print screen do meu in box :
Abaixo em detalhes :
Tipo de acesso, IP de origem, horário e o mais interessante : você consegue derrubar outras sessões abertas com a sua conta.
Esse é o tipo de requisito não-funcional que faz a diferença…
