Tuesday, July 9, 2013

Pidgin Google Talk using Port 443

If you're having trouble connecting to google talk from Pidgin, it might be you have your outbound tcp 5223 blocked. (you can test it by "telnet gmail.com 5223").

You can configure pidgin with the following settings then:
"The Google Talk program contains a number of fallback methods. In your GTalk account on the advanced tab, set Connect Server to "talk.google.com", Connect Port to 443, and check "Force Legacy (port 5223) SSL"."

Also, you might want to delete the pidgin "Account" and create a new one, since if you use "Modify" it might not refresh it properly.

Tuesday, March 12, 2013

Debugging with Visual Studio Development Server fails: SocketException was unhandled

System.Net.Sockets.SocketException was unhandled
  Message="Only one usage of each socket address (protocol/network address/port) is normally permitted"
  Source="System"
  ErrorCode=10048
  NativeErrorCode=10048
  StackTrace:
       at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
       at System.Net.Sockets.Socket.Bind(EndPoint localEP)
       at Microsoft.VisualStudio.WebHost.Server.Start()
       at Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[] args)
This is probably because for some reason the last time you run debug, VSDS didn't stop running.

You can check which process is hung on the given port, and kill it with the following:

netstat -ano | findstr "5001"
Taskkill /F /PID

Tuesday, February 5, 2013

IMDB Searches

For future reference:
num_votes = min, max
sort = user_rating, desc
year = min, max
genres = sci_fi (action adventure animation biography comedy crime documentary drama family fantasy film_noir history horror music musical mystery romance sci_fi short sport thriller war western)
title_type = feature (movie)

Highest Rated Sci-Fi Feature Films Released No Later Than 2012 With At Least 20,000 Votes
http://www.imdb.com/search/title?num_votes=20000,&sort=user_rating,desc&year=,2012&genres=sci_fi&title_type=feature

Monday, February 4, 2013

localhost waits to load applet using chrome

O meu colega tinha um problema. Sempre que acedia à aplicação por localhost o browser chrome ficava pendurado (durante cerca de um minuto) nas páginas que utilizavam um componente java (applet).

Ligamos o debugger no java (control panel -> java -> advanced -> debugging -> enable tracing / enable logging / show applet life cycle exceptions) / Java Console -> Show Console)

A JVM considerava o componente como tendo expirado de validade e tentava fazer download novamente, mas como este estava por trás de autenticação integrada, e esta por alguma razão aparentemente falhava, demorava algum tempo até que a jvm se decidisse a carregar o componente com o ficheiro .jar em cache.

O workaround encontrado foi colocar a virtual folder onde o ficheiro se encontra com anonymous authentication.

Fica a pergunta se a jvm consegue fazer autenticação integrada (kerberos e/ou ntlm) e como configurar a mesma. Aparentemente pelos pedidos que eram efectuados (um dos pedidos era ao dc, e era este que ficava pendurado), seria possível realizar tal autenticação, no entanto no ambiente de qualidade as pastas referentes aos .jar também se encontram com anonymous authentication.

PS: da última vez que tive um problema semelhante também coloquei excepções no web server para permitir anonymous ao servir ficheiros com a extensão .jar, no entanto esta solução pode não ser aceitável onde os ficheiros .jar contenham regras de negócio.