| Autor |
Mensagem |
|
|
Sergio Figueras wrote: Eu só sei que o titulo do blog é algo como "Delirios sobre linguagem de programação".
É o do louds... http://www.kumpera.net/blog/
|
 |
|
|
Uma DSL? Não seria só uma interface fluente não? Eu ACHO que não podemos chamar isso de DSL...
Edit:
Bem.. Acho que pode sim.. http://fragmental.tw/research-on-dsls/language-oriented-programming-lop/language-adaption/
Shoes, qualquer uso de fluent interface pode ser considerado DSL? Quando seria possível e quando não?
|
|
|
|
Eu pratico Kung Fu.
|
|
|
|
|
Uso o TextMate também.
|
|
|
|
maurenginaldo wrote:
Bom se perdeu 1000 ou 2000 posts ainda não chegou na 500.000, pois ainda faltam mais de 10.000.
Só ele perdeu 1000 ou 2000 posts... Eu perdi mais uns 500, e por ai vai. :)
|
|
|
|
Alguns que eu uso:
- Adium, para IM.
- Eclipse
- Firefox
- Flip4Mac, codec WMV
- IntelliJ
- iReport
- iWork
- Jude
- MySQL e ferrmentas administrativas
- Perian, conjunto de componentes para o Quick Time
- pgAdmin
- Quick Silver
- Screenflick, para screencasts
- Stuffit Expander, compressor de arquivos
- TextMate
- Ant, Maven, Tomcat, JBoss, etc.
[]s
David
|
|
|
|
Uma solução fácil seria criar um arquivo csv com extensão xls. Uma outra seria usar o Jakarta POI.
|
|
|
|
Luiz Aguiar wrote:Mas já aviso, se comprar um Mac (book ou iMac) nunca mais saíra dele, tenha isso em mente!
É a mais pura verdade.
|
|
|
|
windsofhell wrote:A minha unica questao sobre o Mac eh ainda jogos. O pessoal que tem Mac, esses jogos populares pra pc tem versoes pra mac ?
Eu não costumo jogar, mas sei que alguns jogos têm versão para mac sim. Aqui deve ter alguma informação: http://www.insidemacgames.com/
|
|
|
|
|
Eu tenho um Mac Book Pro, nunca tive nenhum problema. Creio que você não vai precisar nem de uma semana para se acostumar. Gosto muito de usar o OS X e hoje em dia acho bem estranho quando preciso usar alguma máquina com windows (Linux nem tanto). Em termos de desempenho, aqui onde eu trabalho o Mac Book Pro dá um pau em todas as outras máquinas.
|
|
|
|
javaBeats wrote:E são vários motivos. JSF e sua árvore de componentes não é algo que nasceu para ser manipulado com javascript; Além disso, otimizações como compressão de javascript e pre-processing do código também devem rolar (não consigo confirmar, mas o código cuspido pelos componentes indica isso). Enfim, não é trabalho fácil, ou que possa ser orientado pelos preceitos do desenvolvimento tradicional em javascript.
Bem, um dos motivos para se usar javascript em tudo no JSF é que ele trabalha com POST, já que é necessário enviar o viewstate salvo no cliente para o servidor, e essa informação normalmente é muito grande para ser enviada através de uma URL. Então, qualquer link tem que dar um submit em um formulário por causa disso. Mas e nos casos em que salvamos o viewstate no servidor? Isso continua sendo necessário? Se não for, por que não dar uma alternativa ao desenvolvedor?
Esse tipo de coisa dificulta a utilização de JSF em sistemas que necessitam de urls amigáveis, "bookmarkable pages" (não encontrei uma tradução boa), etc. Não é possível fazer isso com JSF sem utilizar o suporte de uma outra ferramenta como o RestFaces, por exemplo, ou sem escrever uma porrada de código num PhaseListener..
|
|
|
|
bobmoe wrote:E vc acha que uma pessoa com navegador sem suporte a javascript realmente consegue navegar na maioria dos sites? isso pq vc ama javascript, imagine se odiasse. Aliás, usar javascript não está na especificação JSF. (Se não me engano o MyFaces tem a opção de não utilizar javascript, mas ninguem usa isso pq é um retrocesso)
E dai? Se existe a possibilidade de você oferecer um mínimo de recursos, você vai optar por não oferecer nada a esse pessoal? Entendam que eu não estou falando dos componentes do RichFaces, estou falando de um simples link. Obviamente, pra se usar componentes mais complexos eu preciso de Javascript, mas você quer dizer que usar um link sem Javascript é um retrocesso? Outra coisa, porque eu "amo" javascript, quer dizer que eu tenho que usar em todo canto? 
|
|
|
|
Leozin wrote:Seguindo essa tua lógica, quem usa Prototype, Dojo, scriptaculous ou algo do gênero deve odiar javascript também, porque os código-fonte são seguindo esse nível
Opa, que é isso, parecido com aquilo ali? Onde você viu isso? E eu não gosto mesmo do prototype ou script.aculo.us, prefiro jQuery.
Leozin wrote:mas, antes de tudo, você tem alguma solução melhor que essa para efetuar A MESMA OPERAÇÃO?
Bem, primeiro, um simples link não deveria precisar de Javascript. Cadê a acessibilidade? Se você usar um pocket com internet explorer não vai poder acessar um sistema feito com JSF por que o browser não suporta Javascript. Sobre a solução, eu falo já.
Leozin wrote:e também, o que há de tão ruim com Javascript? Você nem encosta, quem faz isso é o JSF, não sei porque o stress. Vale lembrar que esses component-based apps sempre vão gerar javascripts malucos. Você já mexeu com asp.NET? Já viu o que ele gera?
Eu adoro Javascript, gosto MUITO mesmo. Mas quem disse que frameworks component-based precisam de javascript? Já viu como o Wicket (http://wicket.apache.org/examples.html) funciona, por exemplo? Tá ai uma solução muito melhor.
Leozin wrote:a propósito, esse números malucos que aparecem provavelmente é de algum desenvolvedor amador que não conhece boas práticas. Esses números são gerados porque o usuário não colocou um id para o form e um id para o commandLink. Se esse mesmo desenvolvedor reclama de "muitos javascripts", ele é um tanto quanto hipócrita, porque ele simplesmente "cospe" código na tela da maneira que lhe convém sem nenhum conhecimento de boas práticas, ao ponto de reclamar de javascript como se fosse "algo não-bonito"
Eu não reclamei dos números loucos, como você falou. Reclamei da forma como o javascript foi gerado para criar um link.
Leozin wrote:Não me leve a mal hehehe é que esses argumentos realmente não "estão descendo", por mais que o código gerado possa ser tosco, porque devemos nos importar? Se pensar assim também, o código que o netbeans gera pra criar telas do swing é HORRÍVEL, muito pior do que qualquer javascript que o jsf gera
De jeito nenhum eu vou levar a mal. Estamos apenas discutindo idéias. E, assim como você não se importa com o Javascript gerado, eu não me importo com o código que o Netbeans gera porque eu não uso Netbeans.
foxpv wrote: Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs
Mas quem falou em fazer na mão? Eu falei que o framework deveria fazer isso de uma forma diferente, e não que a gente deveria fazer na mão.
|
|
|
|
Leozin wrote:Eu conheço JSF
por que você não mostra soluções mais elegantes do que as que são geradas? Eu sinceramente não ví nenhuma gambiarra (ai meu deus, não é w3c compliance?), e html eu não preciso ficar fuçando em código, ainda mais que o destino final é o usuário e não um desenvolvedor que vai ter um analizador de "html bonito". É estranho esse tipo de crítica, sinceramente...
Bem, isso aqui é um commandLink:
Pra quem gosta de Javascript isso é ridículo, sinceramente...
|
|
|
|
Leozin wrote:Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.
Desculpe a ignorância, mas o que seria um "html quebrado" nesse contexto?
Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia! 
|
|
|
|
|
|