| Autor |
Mensagem |
|
|
Luca,
Quanto vale uma hora de sua vida?
O Mac é para quem prefere trocar alguns dolares por mais tempo.
Essa listinha aqui é muito mais simples prá quem tem um MAC:
* Instalações
* Backups
* Configurações (wifi, RAID, etc)
* Ferramentas de automação
* Ferramentas de recuperação de dados, particionamento de HD
* Assistente de migração de uma máquina para outra
* Ferramenta de sincronização entre desktop, notebook e iphone
* E muitas outras tarefas chatas
Não gastará mais tempo rodando desfragmentador de disco, antivirus, antispyware, etc...
O MAC OS vem com muito mais aplicativos. Inclusive edição de vídeos!
O mundo Mac tem muitos detalhes que fazem muita diferença no nosso tempo. Alguns exemplos:
* O Itunes permite apagar músicas duplicadas.
* A agenda do Mac permite você agrupar contatos duplicados, realizando merge!
* O Safari é mais rápido do que IE, Firefox, Chrome e Opera.
* Com o Itunes você não precisa nem saber o que é um coded.
* As ferramentas de GTD do MAC são incrivelmente melhores
É tudo no Mac é muito mais simples. Não apenas no sistema operacional. A maioria de aplicativos também herdam essa filosofia. E nada de, recompilar kernel, compatibilidade entre pacotes, distros, etc.
Não, ao contrário do que muitos Apple Xiitas dizem, o MAC não é perfeito. Tem bugs sim. Trava sim.
Mas é muito, muito, MUUUIIIIITOOOO superior ao Ruindows. E muito mais fácil, coerente e conciso que qualquer distribuição Linux.
Nas primeiras semanas, existe sim um esforço para se adaptar. Mas prá quem já tentou sair do Windows para o Linux, se adaptar com o Mac é apenas uma coceirinha.
O principal:
Acredito que todo desenvolvedor deveria conhecer o máximo de sistemas operacionais possíveis. E estar atendo às diferenças.
Ser um desenvolvedor multi-paradigma vai muito além de saber meia dúzias de linguagens e bancos de dados. Utilizando o auto-atendimento do Itaú, por exemplo, aprendi que não precisa existir botão de OK após digitar a senha. Aprendi muito de interface
utilizando Palm e Linux. Mas com MAC minha noção de usabilidade virou ao avesso.
Outras observações:
* Desenvolver em Mac dá na mesma. Nenhuma grande diferença. A menos que sua linguagem de programação seja BASIC. 
* A Suite do Microsoft Office para Mac é muito boa. Só deveriam incluir o Microsoft Project.
* Você vai sentir falta de ter mais uns 2 USB. Mas com um hub dá prá suportar essa má decisão da Apple. Não troco um MAC por 10 portas USBs 
* Com BootCamp, sua migração pode ser em etapas. Você pode rodar MAC OS, Windows e Linux, um boot por vez. Ou usar uma máquina virtual como o VMWare para emergências. No início usei ambos. Hoje sou 100% MAC.
Com o hardware é possível fazer certos upgrades. Blu-ray ainda não está na moda. Dá para esperar. Até lá você já vai comprar seu segundo MAC.
Na pior das hipóteses, comprará um driver blu-ray externo USB.
Ter um MAC é uma experiência que não dá prá adiar. Vale qualquer centavo. Conheço raríssimos usuários que se arrependem. A grande absurda maioria os usuários MAC amam a Maçã e tudo o que vem nela.
Quanto comprar seu MAC, nos avise.
|
 |
|
|
|
Veja aqui: http://www.crionics.com/products/opensource/faq/swing_ex/JSliderExamples1.html
|
|
|
|
O que você quer: http://timetrackplugin.sourceforge.net
Minha opinião: uiahuiahiuhaiuhaiuhaiuahiuahiauhaui
|
|
|
|
|
|
|
|
Estávamos usando Joram mas tivemos sérios problemas para integrá-lo ao JOTAM (implementa JTA) mantendo o tunelamento http.
Agora estamos usando o Weblogic.
|
|
|
|
Dá uma olhada aqui:
https://betterpetshop.dev.java.net/
e aqui:
https://equinox.dev.java.net/
|
|
|
|
Tá faltando funcionalidades? Claro!
O Google Calendar é apenas mais uma demonstração da filosofia de desenvolvimento de software do Google. Ao invés de tentar fazer um serviço ultra-mega caro e cheio de features (e que nunca termina), eles sempre tentam dispor ao usuário algo que tenha o mínimo dos mínimos do indispensável para que os próprios usuários digam como o serviço deve evoluir.
|
|
|
|
Interfaces, Interfaces, Interfaces. Acho que houve uma certa confusão aqui.
Significado 1:
Interface da sintaxe de java, correspontende às classes abstratradas com permissão de herança múltipla.
Exemplo:
Significado 2:
Interface de um componente, correspontende a todas possibilidades de interação.
Exemplo: para o componente "Televisão" tenho uma interface que me possibilita ligá-la, mudar de canal, etc.
Suponha que uma classe C tenha uma dependência D. Dessa forma, Para os containers IoC Spring e Pico:
 Esta dependência D pode ser uma classe concreta, uma classe abstrata ou pode ser uma interface (siginificado 1).
C não precisa implementar uma interface Dware (siginificado 1) que exija um setter de um D.
C precisa ter uma interface (siginificado 2) para injeção da dependência D.
Em outras palavras, C não precisa ter implements Dware mas precisa implementar os métodos setters.
Tirar esta última exigência tá parecendo muito estranho. Acho que este é o tipo de situação onde anotação cai bem. Marcar os atributos que podem ser injetáveis.
|
|
|
|
Não entendi exatamente a sua dúvida mas a resposta é: não faz sentido. 
IoC não te obriga a usar interfaces.
|
|
|
|
danieldestro wrote:
vamorim wrote:
fazer algo assim...
Para mim é a mesma coisa.
Não reparou que o segundo é bem menos verboso?
Contando apenas os caracteres não-brancos temos 25 no primeiro e 13 no segundo. Ou seja uma economia de 50%.
Imagina a diferença em larga escala. Um arquivo XML de 1000 linhas por exemplo... Dá uma baita diferença na legibilidade...
|
|
|
|
kuchma wrote:Pode nao ter caido minha ficha ainda, mas acho isso um retrocesso. Primeiro faziamos tudo no codigo com numeros magicos. Depois foram movidos pra constantes. Depois extraiu-se as configuracoes relevantes para properties/XML/TXT/[qualquer coisa que nao seja compilado no codigo].
Nessa ultima etapa perdeu-se os recursos de verificacao em tempo de compilacao - mas a flexibilidade de poder alterar as configuracoes sem recompilar o codigo vale a pena na maioria dos casos.
Agora as anotacoes parecem querer trazer as coisas para o codigo, misturando configuracao e codigo e ainda perdendo a capacidade de deteccao de erros em tempo de compilacao (isso talvez seja contornavel).
Oras, o que eh de configuracao "complicada" (isso eh discutivel), como EJBs, Hibernate, etc, vai continuar sendo complicado, exceto se arrumarem um jeito "magico" de fazer a coisa - e esse jeito, IMHO, nao se resume a simplesmente mover as configuracoes de um lugar para outro.
Eh isso ai - desculpem se nao entendi o "espirito" das anotacoes e viajei na maionese.
Marcio Kuchma
A questão é que Anotações são menos verbosas que XML. Mas eu acho que seria muito melhor criar uma linguagem específica para fazer configurações. Groovy talvez seja a solução. Ou pelo menos ao invés de fazer assim:
fazer algo assim...
|
|
|
|
marcioa1 wrote: Não tenho certeza, mas acho que a Sun quis simplificar, para ficar mais parecido com C#. A M$ sempre diz que faz o mesmo com menos comandos ( linhas ) e talvez isto também tenha inspirado o aparecimento de Generics.
Mas quem não gosta, não precisa usar. Eu uso.
Márcio
Essa história que quem não gosta não precisa usar é meio fraca. Você pode não usar no código que você cria, mas é obrigado a conhecer quando vai fazer manutenção... Ou seja, já que existe não pode-se simplesmente ignorar a sua existência. 
O mesmo vale para o do/while e tantas outras redundâncias existentes.
Sempre que se cria mais uma forma mais simples de se fazer alguma coisa, aumentam-se as possibilidades. Logo, o profissional aumenta o volume de coisas a se estudar.
|
|
|
|
fabgp2001 wrote:
vamorim wrote:A questão é: será que a estratégia de contratação via PJ está ameaçada?
Nao. Sempre tem um jeito de burlar o que os caras pensam.
Tenho um colega que faz pos na FGV e um professor comentou justamente isso.
Uma das coisas que alegam que poderia comprovar caso de CLT seria o local de trabalho nas dependencias da empresa. Ai ja tem empresa cobrando aluguel pelo local. Nao importa se é R$ 0,50, a cobranca ja descaracteriza o ato e ja foi por agua denovo a teoria.
Brasileiro nao adianta, sempre arruma uma solução. 
]['s
Pois é. Parece então que a contratação PJ é um ato legal, porém não legítimo. Certo?
Vinci
|
|
|
|
Tudo bem gente. Não quis criar mais um tópico para debater as vantagens e desvantagens da contratação via CLT e PJ.
A questão é: será que a estratégia de contratação via PJ está ameaçada?
|
|
|
|
marcelomartins wrote:
vamorim wrote:Pessal, ouvi um boato que o Ministério Público do Trabalho estaria dando um prazo até dezembro para que as empresas de TI passem os empregados de PJ para CLT.
Isso procede? Não achei nada no site.
( http://www.pgt.mpt.gov.br)
Poderia nos contar a procedencia do boato? Eu acho que não tem como eles controlarem isso, mesmo porque muita gente trabalha como PJ que é mesmo PJ
Justamente por se tratar de um boato que resolvi confirmar.
O governo realmente não tem como controlar isso. Da mesma forma que não tem como controlar todas as ilegalidades que ocorrem. Mas no site existe uma área onde pode-se fazer denúncias...
|
|
|
|