Just Blogging
Bruno Borges, about Java and Everything Else
26 maio 2014
Java FAQ Brasil - Tudo o que você precisa saber
Com frequência recebo e-mails de clientes com dúvidas sobre "quando sairá a próxima versão do Java?", ou então "quando vai expirar o Java?" ou ainda "quais as mudanças da próxima versão?".
Por isso resolvi escrever o Java FAQ Brasil, respondendo estas dúvidas e muitas outras.
Para continuar lendo o FAQ, siga para o meu Oracle blog.
15 maio 2014
Oracle no TDC2014 Florianópolis
Este ano a presença da Oracle no The Developers Conference 2014 - Edição Florianópolis vai fazer a diferença! Sem contar que fomos até mencionados pelo Cacau Menezes, grande figura da região da Ilha da Magia. Vejam só o que ele disse em seu blog:
"Já pensou em controlar uma torneira de chopp via dispositivos móveis e ser avisado pelo Twitter quando você já tomou todas? Pois é, essa ideia se tornou realidade pelos profissionais da gigante tecnológica Oracle Bruno Borges (@brunoborges) e Marco Antonio Maciel (@marcomaciel)." - Cacau MenezesEnfim, estaremos presente no evento com as seguintes palestras e trilhas:
Trilha Games - Quinta
15:40 - Como criar o game 2048 em JavaFX
Trilha Javascript - Quinta
17:40 - Nashorn: novo motor Javascript no Java
Trilha Java EE - Sexta
10:10 - Criando uma aplicação HTML5 com Java EE 7 e WebSockets
Trilha SOA & BPM - Sexta
15:40 - Integrando Oracle BPM com Java EE e WebSockets
Trilha Java - Sábado
10:10 - Migrando de Applets para JavaFX, e novos modelos de distribuição de aplicativos Java
Trilha Internet das Coisas - Domingo
15:40 - Controle de Eventos em Tempo Real através de Java Embarcado
17:40 - Tweet para cerveja! Torneira de chopp controlada por Java, JavaFX, e IoT!
Se você quiser saber mais sobre os palestrantes da Oracle que estarão presentes no evento, acompanhe o Giovani Bassan, o Marco Maciel, e o Bruno Borges (eu) no LinkedIn :-) E acompanhe no Twitter com a hashtag #TDC2014!
Tweets about "#TDC2014"
13 maio 2014
Test your website on JavaFX WebView
If you are building (or considering to build) a two-tier Java application that loads remote content from your webserver into a WebView component inside JavaFX, here's a quick and dirty Javascript code that you can use to test your website and make sure it is compatible.
To invoke, download the file browser.js and execute it on your command-line like the following example:
And if you liked this, you may want to check out the WebFX project as well. :-)
To invoke, download the file browser.js and execute it on your command-line like the following example:
$ jjs -fx browser.js -- http://www.twitter.com/brunoborges
And if you liked this, you may want to check out the WebFX project as well. :-)
28 abril 2014
Git SSH over HTTP Proxy
If you are like me and you are using Linux behind an HTTP proxy, you will probably want to access GitHub and other Git remote repositories through SSH. For that to work, you will likely need to use some sort of utility that will enable you to connect to an SSH server through an HTTP proxy server.
To do that, you can use the connect-proxy command. The repository has no binary, so you will have to compile it on your own. But it is not hard if you are a good Linux user . If you run the install.sh script, you will end up with the binary at /usr/local/bin.
The last thing to do is to setup your SSH config file accordingly:
$ cat ~/.ssh/config
Host *
ServerAliveInterval 30
Host *.amazonaws.com
ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p
Host github.com
ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p
To do that, you can use the connect-proxy command. The repository has no binary, so you will have to compile it on your own. But it is not hard if you are a good Linux user . If you run the install.sh script, you will end up with the binary at /usr/local/bin.
The last thing to do is to setup your SSH config file accordingly:
$ cat ~/.ssh/config
Host *
ServerAliveInterval 30
Host *.amazonaws.com
ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p
Host github.com
ProxyCommand connect-proxy -H proxy.myserver.com:80 %h %p
Extra bonus: access to Amazon EC2 with SSH over HTTP Proxy.
If you know a better way to do this, please comment!
12 abril 2014
Had Heartbleed showed us a new business model for Open Source?
This is what I wrote on my Twitter the day I heard about Heartbleed:
Isn't time for Open Source foundations such as Apache or Eclipse, charge for the use of their Open Source projects by companies who profit from these projects? Consider "charge" as either through money, contribution, or developers paid by these companies to work on these Open Source projects.
UPDATE #2 13/04/2014
Here is another blog post titled "Heartbleed, an ASL business model failure?" by Bruno Lowagie, original author of iText, covering similar ideas I wrote above.
UPDATE #3 14/04/2014
Interesting article aobut the weakenesses of Open Source: "Heartbleed and the misconceptions about Open Source". Here's a quote:
Were #OpenSSL a paid-only software (but still open source), would have been #Heartbleed avoided? http://t.co/WV8nKUNMV8
— Bruno Borges (@brunoborges) April 10, 2014
Some say this bug is the worse bug ever found, affecting the Internet as a whole, since most servers have OpenSSL. With paid and closed source software, it is easy to blame someone. At some point, there are companies who prefer paid and closed source just because of that. But what about a Free and Open Source? Who is to be blamed about the issue? I would say there are three entities to be blamed for the Heartbleed bug, each with different weights:- The developer who introduced the bug is the least to be blamed. Developers make mistakes, some big, some small. This one just happened to be a small bug but with a big consequence.
- The QA developer who didn't see the bug is the least to be blamed. A developer reviewing code. In the end, continues to be a developer mistake like in (1).
- The whole IT industry (companies and developers of all kind; FOSS or not) who uses OpenSSL for free but does not pay anything for it, and although being Open Source, don't look at it, don't review commits. Just expect it to work without bugs. These are the most to be blamed. (including myself)
As the article in my tweet above says:
Jackson also says a lesson to be drawn from the Heartbleed Bug is that "we as an industry have dramatically underinvested in software integrity and generally ignored, for a security perspective, the open source building blocks on which the Internet functions. Open source is everywhere. It is the foundation of all modern software applications."
So my question to you now is: if we, the IT industry, had put more investment into the OpenSSL development team, would the chances had been higher for the Heartbleed bug to be found? Being Open Source helps, of course, but if there is no incentive (or obligation) for people to look at it, to review the code, then most people won't look at it and instead, just use it for free. This is what happened. All companies and developers are to be blamed.
Should we consider a different business model for Open Source software? What about a model where a company (not individual) willing to use an Open Source software has to either:
Should we consider a different business model for Open Source software? What about a model where a company (not individual) willing to use an Open Source software has to either:
- pay for a license and/or subscription support;
- provide resources (developers and/or QA) dedicated to the software itself;
- discount on license/support based on contributions;
Is it time for a new business model for Open Source?
What are your thoughts?
UPDATE #1 13/04/2014
A headline on Slashdot shows that Apple is far from supporting Open Source. The news says:
Apple bundles software from the Apache Software Foundation with its OS X operating system, but does not financially support the Apache Software Foundation (ASF) in any way.
A headline on Slashdot shows that Apple is far from supporting Open Source. The news says:
Apple bundles software from the Apache Software Foundation with its OS X operating system, but does not financially support the Apache Software Foundation (ASF) in any way.
Isn't time for Open Source foundations such as Apache or Eclipse, charge for the use of their Open Source projects by companies who profit from these projects? Consider "charge" as either through money, contribution, or developers paid by these companies to work on these Open Source projects.
UPDATE #2 13/04/2014
Here is another blog post titled "Heartbleed, an ASL business model failure?" by Bruno Lowagie, original author of iText, covering similar ideas I wrote above.
UPDATE #3 14/04/2014
Interesting article aobut the weakenesses of Open Source: "Heartbleed and the misconceptions about Open Source". Here's a quote:
As Heartbleed showed, even mission critical software used by a large portion of the Internet does not necessarily have the resources to be professionally maintained. The OpenSSL team receives only about $2000 yearly in donations.
Assinar:
Postagens (Atom)
| |||
|