Desenvolvendo uma view do VCNews utilizando algumas coisas de CSS3 como border-radius, veja os screen-shots.

Internet Explorer 8

Firefox 3.5.9

Safari

Opera

Bem, sempre gostei e usei o Opera… Recomendo. =)

Nao tinha Google Chrome instalado na maquina (viper) onde rodo os navegadores para teste (post sobre a viper). Irei instalar e ver a diferenca. Quem sabe nao escrevo sobre isso aqui mais tarde.

Hoje foi um dia muito produtivo, fiz algumas mudancas no VCNews. Agora nao temos mais acesso via autenticacao basica, ja’ que dia 30 agora o pessoal do Twitter ira’ tirar esse recurso, ja’ mudei todo o sistema para OAuth. Usei uma lib chamada oauth2 para fazer a autenticacao. Gostei muito do projeto. Esta’ com varios casos de testes. O que realmente faltou foi uma documentacao melhor.

Bem, tirando o Objects.Twitter.Drive, temos o Objects.Twitter.Client. Ja’ fiz todas as mudancas para nao utilizar mais o Drive e atualizei os testes. Considero stable ja’.

Outra modificacao que vale a pena comentar foi a transferencia de todos os Objects para o seguinte padrao:

universeObject >> Object_core >> interface 1/2/3/4

Assim temos maior liberdade para modificar os objetos  garantindo que nao ira’ causar nenhum erro no sistema.

==

Coloquei a maquina Viper para funcionar como terminal remoto usando o Windows 7 para essa tarefa. Com o dll que consegui, veja, consigo deixar varios users conectados/usando a maquina ao mesmo tempo. Gostei muito desta solucao para manipular o Internet Explorer 7 e 8 (IE6 pessoalmente nao dou suporte, nenhum, quem usa nao deveria estar na frente de um computador ou ate’ mesmo respirando, existe varias otimas opcoes como Opera, Firefox, Google Chrome, Safari, Dillo e ai vai…), melhor que deixar uma maquina virtual para fazer esse trabalho. Imagino que uma boa maquina como a Viper e’ (AMD Athlon 7750 Dual-Core Processor 2.70GHZ com 4GB de ram) fica otimo para 3 usuarios (fiz o teste conectando 3 users ao mesmo tempo via rede e um usando a maquina normalmente), colocar um workstation para essa tarefa em uma equipe e’ muito mais “barato” e simples que obrigar a equipe que ira’ fazer o front-end utilizar 2 ou mais maquinas virtuais.

Uma lista de scripts de grande uso como o Jquery, Dojo, Prototype entre outros pronto para usar.

http://scriptsrc.net/

• novo modelo de objetos no universe
• portei os objetos do ShakeIt para o novo modelo (eles nao seguiam modelo universe)
• mudei a api do Linkaaa para um novo modelo utilizando o univese.object
• fiz um sisteminha de pegar todas as cidades e estados do Brasil para o ShakeIt, quero colocar isso como um service depois. =)
• e o mesmo sistema esta’ pegando estilos de musica eletronica tambem para o ShakeIt
• melhorei o desempenho de cache das apis para Google Chart
• melhorei/terminei (stable) sistema de msgs do ShakeIt, tenho de alinhar agora com o Tiveron apenas
• temos universe supernova-rc2
• comecei a criar uma api para uprofile tratando agenda de contatos — tenho de terminar um design para implementar de verdade

Quero dar um tempo e tratar melhor a solucao de fotos que fiz para o ShakeIt, talvez criar algo mais pratico do que um sistema de “albuns de fotos”. Ja’ que vai ser usado para quase tudo do site.

Novos recursos no Universe e Universe.Apps.Google.Chart. =)

Universe conta agora com um sistema de entregar JPG/PNG direto. Entao podemos ter referencias assim por exemplo:

http://universeDomain.com/image.py?id=800

Agora o Charts ganharam mais recursos nesse pequeno espaco de tempo (quando foi o ultimo post? nao deve ter passado nem 12 horas):

• Grafico do Tipo Line
• Grafico do Tipo Venn
• Grafico do Tipo QR
• Grafico do Tipo Google-o-meters
• Posicionamento de legenda
• Labels

Grafico QR

Grafico Google-o-meters

Grafico Venn

Novos recursos:

• Suporte a cores
• Suporte a legendas

Exemplo gerado pela Universe.App:

Ainda tenho de fazer scripts para gerar outros tipos de grafico e facilitar o uso da App. Hoje temos de saber cada modelo que o Google oferece de cor. =/ O problema que cada tipo de grafico tem um comportamento diferente na sua chamada. Pretendo fazer isso o mais rapido possivel. =)

Agora o Universe conta com objeto do Google’s Chart!

Essa primeira versao (0.1 — acabei de fazer) dessa UniverseApp mas ja’ retorna o chart desejado. Essa nova UniverseApp vai ser muito utilizado pelo VCNews, por isso mais uma Task dele feita.

Melhorias (To do)

• Criar UniverseScripts para cada tipo de grafico.
• Adicionar o recurso de cores.
• Adicionar o recurso de legendas.

August 2004

In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.

I didn’t mean by this that Java programmers are dumb. I meant that Python programmers are smart. It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.

Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they’re exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.

A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.

At the mention of ugly source code, people will of course think of Perl. But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually.

So far, anyway. Both languages are of course moving targets. But they share, along with Ruby (and Icon, and Joy, and J, and Lisp, and Smalltalk) the fact that they’re created by, and used by, people who really care about programming. And those tend to be the ones who do it well.

Fonte: http://www.paulgraham.com/pypar.html