| Autor |
Mensagem |
|
|
Olá
Deu no jGuru e copio aqui para facilitar os interessados:
Mueve Tus Ideas con Telcel y Java (Java/J2ME Application Contest in Mexico)
http://www.muevetusideas.com/
Vigencia del concurso
:: Apertura Convocatoria: 13 de Octubre del 2003
:: Cierre Convocatoria: 13 de Febrero del 2004
:: Premiación: 16 de Marzo del 2004
Convocatoria
Podrán participar todos los desarrolladores en cualquier parte del mundo, no obstante, los premios solamente serán exigibles y entregados en la Republica Mexicana.
Nota: Los trabajadores de Telcel, Nokia, Sun Microsystems y de sus empresas subsidiarias, filiales, afiliadas, controladas y controladoras no podrán participar en este concurso.
Objetivo del concurso
El principal objetivo del Concurso es el de fomentar el interés entre la comunidad de programadores de Java del desarrollo de aplicaciones para dispositivos ?móviles?, haciendo uso de su capacidad creativa y de su curiosidad por los avances tecnológicos en el área de las telecomunicaciones privadas. Asimismo, se busca difundir el uso tanto de Java como lenguaje de programación para estas plataformas como el uso de nuevas aplicaciones más sofisticadas en la nueva generación de terminales
Inscripción
Para inscribirse se deberá de presentar, dentro del plazo de la convocatoria, un solo proyecto por participante, en el cual se deberá presentar un documento, de máximo dos (2) cuartillas en donde se especifique el nombre, una descripción general, la justificación, el alcance del mismo y el software a utilizar. Deberán incluir cuál sería el interés para el desarrollo de la telefonía móvil en México y el beneficio para los usuarios respecto de su aplicación. La participación podrá ser individual o por equipos, sin embargo, los premios se darán solamente al proyecto que resulte ganador.
Critério de evaluación
El Comité de Evaluación fungirá como jurado para la evaluación de los proyectos de conformidad con los Criterios de Evaluación. Los Criterios de Evaluación que serán empleados son los siguientes:
:: Utilidad para el usuario final
:: Factibilidad (dadas las condiciones actuales d el mercado mexicano)
:: Facilidad de uso
:: Creatividad
:: Innovación
:: Interactividad
:: Orientación a mercado mexicano
Entrega de proyectos:
La entrega de proyectos se hará vía Internet, al registrarte se te asignara un Usuario y un Password con el que posteriormente podrás enviar tu proyecto con la siguiente información:
a) Una presentación ejecutiva del proyecto de máximo 10
diapositivas (slides), en donde deberá explicarse el desarrollo y su
aplicación.
b) Un Código Fuente comentado, documentado y funcional en el
emulador correspondiente. El ejecutable debe considerar las
limitantes técnicas de la terminal correspondiente.
Requisitos técnicos
Las aplicaciones deberán cumplir con los siguientes requisitos técnicos.
:: Deberán ser ideas originales y de completa y exclusiva autoría de los participantes
:: Deben ser desarrolladas para servicios de tecnología móvil
disponibles en México (Java, SMS, WAP)
:: Deberán estar desarrolladas y documentadas en español
:: Se requiere de una aplicación que al momento de ser entregada,
sea operable al 100% en su caso, las pruebas se pueden hacer
con una muestra representativa (prototipo funcional)
:: Todos los participantes deberán presentar y entregar el código
fuente, manteniendo todos los derechos sobre sus desarrollos
:: La aplicación que desarrollen podrá residir en los teléfonos con
capacidad para Java o bien residir en los servidores de
aplicaciones y hacer uso de las características de los teléfonos
:: La programación de las aplicaciones deberán ser en: Java,
J2me, MIDP, JSP.
Premio
Habrá 2 (dos) ganadores del Concurso elegidos de entre 10 (diez)
finalistas. Los ganadores recibirán un premio y una suma de dinero
en efectivo, equivalente a UD$20,000.00 en el caso del ganador en
primer lugar, y a USD$10,000.00 en el caso del ganador en segundo
lugar. Los 8 (ocho) finalistas restantes recibirán un premio, según
se señala más adelante.
:: Ganador :: Primer Lugar
Segundo Lugar
:: Premio ::
SunBlade150 + Nokia 9290 + 20,000USD
SunBlade150 + Nokia 9290 + 10,000USD
:: Finalista ::
Tercer Lugar
Cuarto Lugar
Quinto Lugar
Sexto Lugar
Séptimo Lugar
Octavo Lugar
Novemo Lugar
Décimo Lugar :: Premio ::
Java One + Nokia 9290
NOKIA Course + Nokia 9290
Sun_Edu Course + Nokia 3650
Sun_edu Course + Nokia 3650
Sun_Voucher Certification + Nokia 3650
Sun_Voucher Certification + Nokia 3650
Sun_Voucher Certification + Nokia 7210
Sun_Voucher Certification + Nokia 7210
Obligaciones de los ganadores:
Todos aquellos participantes que sean electos ganadores dentro del presente concurso, deberán ceder los derechos patrimoniales a favor de RADIOMOVIL DIPSA S.A. DE C.V.; o bien a favor de cualquier otra empresa o persona que este ultimo designe (a su sola discreción) para tal efecto.
[]s
Luca
|
 |
|
|
Olá
Se for por votaçãO voto com vegeto. Mas pensando bem, em muitos casos meu voto iria para o Rafael. Conclusão: não há regra fixa, cada caso é um caso. E ainda bem que é assim, senão qualquer máquina sairia programando e a gente iria vender pastel na feira.
Programar computadores é uma tarefa completamente subjetiva e ao contrário que a turma de humanas pensa, é bastante criativa. Escolher o caminho a gente faz baseado na experiência com as melhores práticas , na intuição e até no humor do dia (principalmente do chefe). Daí as vezes a gente relê nosso código tempos depois e sente uma vontade danada de melhorar um pouquinho. Isto é uma das piores práticas. Depois que fechamos os testes unitários e integramos nosso código, deve haver um bom motivo para refatorar, nunca só por estética ou elegância.
[]s
Luca
|
|
|
|
Olá
Estude as classes de javax.crypto.*. Procure entender de criptografia para saber exatamente qual grau de segurança vai obter. Quanto maior a segurança pior a performance.
Um começo pode ser achado em http://www-106.ibm.com/developerworks/java/edu/j-dw-javasec1-i.html e http://java.sun.com/developer/technicalArticles/Security/JCE/
Não desenvolva seu próprio método para criptografar a menos que suas necessidades de criptografia sejam muito simples. O melhor método que inventar poderá ser aberto em poucos minutos. Use um método consagrado por todo o mundo.
Há bons livros de criptografia para Java. E sobre criptografia em geral recomendo bastante o livro Practical Cryptography de Niels Ferguson e Bruce Schneier. Ver detalhes em http://www.schneier.com/book-practical.html
[]s
Luca
|
|
|
|
Olá
1) Java não tem ponteiros
2) Java não é C
3) Estude Strings e depois reflection. Com reflection a gente faz o que quer fazer à moda C.
[]s
Luca
|
|
|
|
Olá
Alguém conhece alguma posição no ramo de informática sem enorme pressão? Quem está neste ramo é porque gosta de pressão, de trabalhar com prazos impossíveis e de administrar cliente histérico. Tenho muitos anos de estrada e se pressão matasse já estava morto desde meus tempos de Fortran. Nessa profissão quem está certo é aquele cara que diz: "Quer moleza, senta no pudim"
[]s
Luca
|
|
|
|
Olá
A interface dele é muito fácil e qq dúvida veja o HELP. Basta instalar o driver jdbc do seu banco de dados e conectar como costuma fazer em Java. Depois vá em "References" e brinque desenhando o relacionamento do seu sistema. Não é o ERWIN, mas também não custa nada.
Download da versão 4.02 em http://www.minq.se/products/dbvis/
[]s
Luca
|
|
|
|
Olá
Sem entrar em muitos detalhes...
Na prática não precisa nada disso. Falei em envio de dados por XML sobre HTTP/HTTPS e não em envio de objetos. Na verdade o uso do XML nem chega a ser necessário. Podia ser usado um protocolo posicional daqueles bem antiquados. A diferença em não enviar objetos é que cada transação precisa conhecer seu contéudo e novas transações exigem novos métodos específicos.
Melhor desempenho versus facilidade de desenvolvimento esta é a questão. Imagine um aplicativo em execução em 1000 terminais, cada terminal enviando 100 transações/dia, distribuídas de modo não uniforme ao longo do dia (com horários de pico). Na hora que o bicho pegar seu patrão vai mandar refatorar tudo e provavelmente "web services" vai para o saco. Melhor começar logo enxutinho (sem esquecer que otimização precoce também é ruim).
[]s
Luca
|
|
|
|
Olá
Soluções pagas: JDUN e SerialIO
JDun: http://www.javaapis.com/jdun/
[]s
Luca
|
|
|
|
Olá
DBVisualizer tem versão free e é fundamental no micro de todos que usam Java.
[]s
Luca
|
|
|
|
Olá
Louds, penso que a gente sempre deve balancear onde devemos economizar. Se a aplicação tem muitos clientes e precisa de bom desempenho as vezes é melhor uma solução feita com um pouco mais atenção na fase de desenvolvimento.
O uso de web services tal como sugeriu pode ser prático mas em alguns casos há o risco do retrabalho para atender aos requisitos de performance.
XML sobre http/https precisa apenas de jsse e um parser. O resto é puro Java. Já com Axis/JAX-RPC pode aparecer um monte de intermediários na troca de mensagens. Se as especificações do projeto não forem muito exigentes em termos de throughput então não haverá problemas em usar soluções elegantes porém de baixo desempenho.
[]s
Luca
|
|
|
|
Olá
Sei bem o que é usar XML na troca de mensagens por HTTP/HTTPS pois trabalho aplicações que fazem exatamente assim. Não há nenhum problema em mandar XML pela Internet. Os problemas do XML são os seguintes:
a) performance tanto no cliente como principalmente num servidor com milhares de clientes.
b) tamanho do parser quando é necessário fazer download na Internet com JWS ou Java Plugin
A grande vantagem de enviar objetos serializados nas mensagens é fazer o sistema bastante genérico e os métodos que enviam e recebem mensagens não precisam saber o que estão enviando e recebendo. Fica bem elegante e rápido de codificar.
Em termos de performance melhor seria ser menos genérico na codificação para ser mais específico na execução. Em outras palavras, escrever métodos diferentes para objetos diferentes ao invés de usar reflection. Mas mesmo assim me parece bastante interessante o tal de XStream que eu não conhecia.
[]s
Luca
|
|
|
|
Olá
1) SAX fornece um framework baseado em eventos que os parser usam para ler o documento sequencialmente que logo vai sendo decodificado. Não temos a visão global do documento.
2) DOM lê o documento completo na memória e só depois inicia o trabalho de decodificação. Use DOM apenas se seu arquivo for pequeno.
Como vê será sua aplicação que responderá o que deverá ser usado.
Servlet é um programa como outro qualquer, não precisa de tutorial para explicar como uma coisa vai funcionar especificamente num servlet.
Um conselho: nunca coloque em sua aplicação um "esquema" que não entenda completamente. Melhor seria que realmente desse uma estudada em XML, XSLT, XPATH, e XSL. O uso destas tecnologias pode até mesmo evitar as etapas de transferir XML para algum objeto Collection "da vida"
e manipular o Colletion. Do XML poderia passar direto para o HTML.
[]s
Luca
|
|
|
|
Olá
Acredito que sua aplicação não deve ser do tipo daqueles antigos programas de arquitetura obsoleta como o pacote Office da poderosa que roda tudo na mesma máquina. Sendo assim, deve haver possibilidade de enviar POSTs e GETs a partir de sua aplicação Delphi. Caso afirmativo, porque não fazer o lado servidor com servlet recebendo as transações de um servidor de aplicações qq? Ao invés de enviar objetos, envie apenas os dados.
Em uma googlada rápida achei este treco: http://www.badfan.com/delphi/
A persistência faça como lhe aprouver no servidor.
[]s
Luca
|
|
|
|
Olá
A resposta do CV já esgotou o assunto. Apesar das promessas do Java Server Faces que ainda vai ser lançado, o negócio é mesmo usar Java Web Start com as features do jardiff para fazer download somente do que foi alterado em cada atualização de versão.
Se optar por usar swing poderá obter uma interface mais amigável com diferentes look&feels. Há muitos livros sobre swing e penso ser mais fácil encontrar profissionais que conheçam swing do que swt. Este último é uma opção nova e caso você se sinta confortável com ele vá em frente.
Não é verdade que applets estejam mortas. Se você examinar os milhares de terminais do Banco Postal vai ver uma applet assinada com mais de 1200 classes (fora as libs tipo foxtrot, commons, etc.). O seu desenvolvimento começou quando o JWS ainda era uma promessa. O JWS ficou bom mesmo depois do J2SDK 1.4 e o Banco Postal usa J2SDK 1.3. O problema do uso de applets é a necessidade de desenvolver um classloader específico (e mais alguns veneninhos) para não precisar fazer download de toda a aplicação a cada mudança de versão.
Quanto ao uso ou não de servlets a questão não tem nada a ver com a interface gráfica do usuário e sim com sua vontade de usar um servidor de aplicações já pronto que receba as transações por http ou então que você mesmo desenvolva este servidor. O uso de http (ou https) é mandatório pois passa facilmente por firewalls e você não precisará entrar em disputa com o depto de segurança de redes.
Atualmente com java.nio se pode desenvolver um ótimo servidor para receber solicitações http (ou https). Mas vai ser dificil convencer seus chefes de que será melhor do que já existe pronto.
[]s
Luca
|
|
|
|
Olá
O de sempre para todos. Muita grana, saúde, esporte, prazer de trabalhar, seu time campeão, paixões, amores, tudo o mais.
E 2 sites para brincar clicando nas renas:
http://web.icq.com/friendship/swf/0,,7944_rs,00.swf
http://web.icq.com/friendship/swf/0,,16959_rs,00.swf
E uns balões para estourar:
http://web.icq.com/friendship/swf/0,,16961_rs,00.swf
[]s
Luca
|
|
|
|