Google Code Jam Latinoamerica
|
En el blog oficial de Google, el dia de ayer se anuncio por fin la apertura del concurso Google Code Jam Latinoamerica. Que es GCJL? Es un concurso para programadores patrocinado por google en el que cualquiera puede inscribirse. Te presentan ciertos problemas y tienes que resolver la mayor cantidad de ellos en el menor tiempo posible, en un lapso de una hora. Se podra participar en los siguientes lenguajes: C#, C++, Java, VB.Net y python (con algunas restricciones para este último, por lo lento del lenguaje) Se harán varias rondas, la primera eliminatoria dejara 500 concursantes, la segunda 250, la tercera y ultima, 50 concursantes los cuales seran llevados a las oficinas de google en Brasil donde competiran para ser el mejor programador de latinoamerica (o del concurso al menos ;)). |
 |
Los premios para mi gusto, son un poco bajos, pero igual vale la pena por mera cuestión de ego. Van desde los 6000 reales (30 mil pesos, aproximadamente) para el primer lugar hasta los 350 reales (1800 pesos aprox) para los lugares 21 al 50.
Yo ya me inscribi. Si quieres inscribirte puedes hacerlo aqui. Pero apurate que las inscripciones terminan el 23 de enero.
La ronda de clasificación sera el 24 de enero. Ahi nos vemos
Reddit, seguridad y robo de contraseñas
Si alguien es usuario asiduo de Reddit talvez noto que hubo fallas en los servidores en esta semana. Ayer los programadores de reddit ofrecieron una disculpa por las fallas, pero revelaron otra cosa mucho mas interesante. Al parecer una parte de un respaldo de la base de datos de reddit fue robado y con el muchos nombres de usuario y contraseña.
Esto es sospechoso por dos motivos.
- Usualmente un respaldo de una base de datos no se hace en partes a menos que sea enooooooorme, del orden de muchos GB o TB. Y reddit no tiene tanto tiempo de activo, y solo guarda pequeños datos tipo texto por registro, aunque por supuesto, podria estar terriblemente equivocado
- Segundo, y mucho mucho mas importante. Si es posible que hayan robado usuarios y contraseñas quiere decir que estos estaban almacenados en texto plano.
Aqui es donde las alarmas se encienden. Este es un error super basico en el desarrollo de aplicacione seguras (y que yo cometi cuando empece, debo aceptar :P). NUNCA NUNCA NUNCA (y repito, NUNCA) guardes contraseñas en texto plano.
Es muy sencillo implementar el guardado de contraseñas mediante un hash + salt. El que no sepa, que pregunte. (si alguien lo requiere puedo poner un articulo al respecto)
Una vez que alguien se haga de las contraseñas de la base de datos, toda tu aplicacion estara abierta. Si tu crees que eres invulnerable o que tu sistema no le importa a los hackers, piensalo dos veces. En el caso de reddit tienen informacion privada, como correos electronicos. Una vez que tienen la contraseña, pueden intentar ingresar a esos correos con la misma contraseña y de ahi saltar hasta a servicios bancarios (lo cual es una razon mas para no guardar tus contraseñas en el correo electronico :P). En tu caso puede ser informacion aun mas sensible como informacion bancaria, nombres, direcciones, telefonos u otra informacion que permita identificar a tus usuarios. Teniendo esta informacion, para los hackers solo les falta un paso al cielo… y a sus cuentas bancarias, o peor…
Si valoras a tus usuarios (y a tu integridad fisica y economica), documentate por lo menos de los tips minimos de seguridad. O atente a las consecuencias.
Memory tips for PHP
Once upon a time a web programmer who was writing a complicated script. He tests it in his machine, and it works like a charm. Then he tries in the production server…
Craaash. And not even a trace of error. He checks that error logging is on, checks the logs, nothing. He is “without a trace”… or a core dump… or anything.
My psychic powers tells me that is a memory error.
This kind of errors are typical when you are using a thousands-lines report or sending a heavily attachment loaded mail via php. In fact, the last reason make me write this post. I detected a hard to find problem with a very well known email script. Specifically the error I found was in a bad use of the chunk_split function, which just refuses to work with very very long string and dies miserably with out even send any kind of error (at least in older versions of php which I’m forced to use :S, but that’s another history).
Usually PHP captures this kind of errors and throws the typical error “Allowed memory size of x bytes exhausted”. This is caused because the server’s admin limited the memory that any script can use and was made to protect the servers against bad programmers, and is used commonly in shared environments.
To be able to handle this kind of problems, here is some basic tips to make this experience a lot less painful.
- Check your script’s memory usage
The memory_get_usage function returns the bytes used by your script. But this function is not available in every system, just in those which were compiled with the –enable-memory-limit option. Usually if this function is not available, you can’t either recompile your php installation. If this is the case, you can emulate the function with this code:
if( !function_exists('memory_get_usage') ){
function memory_get_usage() {
exec("ps -orss -p ".getmypid(), $output);
return $output[1];
}
}This function is similar to the one included in php, even if is not perfect. But you can get an idea of what’s going on. Requires you have execution privileges because uses the ps command. It just works on Unix or Linux systems.
- When you are done, don’t forget to clean-
If you are not longer use a memory intensive variable, destroy it with unset($variable). This will free up the used memory.
- Say no to globals.
This is an extension from the last one. Be careful when you use global variables. When you use unset a global variable inside a function. you will just destroy the local variable, not the global one. So, you have one more reason to NOT use global variables (as if you need one more :))
- Don’t trust the garbage man!
I’ve noticed than when a function ends, local variables are unset. Although that is not always the case, sometimes even when the variables are unset, the memory doesn’t becomes available until the end of the script. So when you use heavy variables inside a function, unset em before the function ends if you will not longer use em.
- Forget as soon as you can.
If you are using a very long archive, don’t keep it in memory. That would be the easy way but it will give you some problems later. Instead process the file line by line and write the result in a temp file. tmpfile, fopen and fclose (and google :P) are your friends. This will be the most useful advice for this cases, trust me.
- Don’t ignore the warnings
As a general recommendation, when you are debugging scripts, use error_reporting(E_STRICT). That will give you a little more information than E_ALL. As times goes by, you won’t note the difference between those two.
- Brute force
As a last resource, if those last advices doesn’t work (but they will :)) you can make bigger the script memory limit, with the ini_set(”memory_limit”, “16M”) directive which would make the limit 16Mb. This directive is available with any server that allows the ini_set function. But be careful, especially if your are on a shared server, be a good neighbor and don’t blow the server. Don’t ask for free problems
This are some basic advices for those hard problems. If you people like this article, I could make some more deeper articles on the subject.
Uso de memoria en PHP
Erase una vez un programador web realizando un script relativamente complicado… Lo prueba en su maquina, funciona de maravilla. Lo sube al servidor de producción.
Craaash. Y ni siquiera un rastro de error. Revisa que los errores están habilitados, revisa los logs, y nada. Busca algún rastro y nada….
Mis poderes de psÃquico me dicen que es un error de memoria.
Estos errores son tÃpicos cuando se esta realizando un reporte con miles de filas, o mandando un mail con attachments pesados via php. De hecho lo que me motivo a realizar este post es que detecte un problema con cierto script famoso para enviar correos. EspecÃficamente encontré un error en una la función chunk_split en la que al trabajar con una cadena demasiado larga simplemente se niega a seguir trabajando y muere sin mandar ningun error.
Usualmente, PHP captura esos errores y nos lanza el ya tÃpico error “Allowed memory size of x bytes exhausted”. Esto es debido a que por precaución contra malos programadores, y especialmente en servidores compartidos, es posible limitar la memoria ocupada por cada script.
Para lidiar con estos problemas, he aquà unos tips básicos que harán tu experiencia un poco menos difÃcil.
- Revisa el uso de memoria de tus scripts
La función memory_get_usage te regresa el numero de bytes que tu script esta ocupando. Sin embargo esta función no esta disponible en todos los sistemas, ya que hay que compilar php con el parametro –enable-memory-limit. Si en tu servidor no existe esta función puedes emularla de la siguiente manera.
if( !function_exists('memory_get_usage') ){Es similar a la incluida en php, aunque no es tan exacta, pero te puedes dar una buena idea de lo que esta sucediendo. Requiere privilegios de ejecución, ya que utiliza el comando ps.
function memory_get_usage() {
exec("ps -orss -p ".getmypid(), $output);
return $output[1];
}
} - Cuando termines, no te olvides de limpiar
Si ya no utilizas una variable que contenga una fuerte cantidad de memoria, destrúyela con unset($variable). Esto liberara inmediatamente la memoria ocupada.
- DÃ no a las globales
Esta es una extensión de la anterior. Ten cuidado al usar variables globales. Cuando usas unset en una variable global adentro de una función solamente se destruye la variable local, no la global. Asà que una razón mas para NO usar variables globales. (como si hicieran falta
) - No confies en el barrendero
En general he notado que al finalizar una función, esta desactiva las variables locales. Sin embargo, no siempre es el caso o bien no se libera la memoria que estas variables usaron, por lo que cuando uses variables pesadas dentro de una función, desactivalas con unset antes de terminar el script si ya no haces uso de ellas.
- Olvida tan pronto como puedas
Si vas a utilizar por ejemplo, un archivo de muchas lineas, evita mantenerlo en memoria. Esto ultimo es lo mas facil pero puede provocar errores a la larga. En su lugar ve procesando el archivo linea por linea y escribe el resultado en un archivo. tmpfile y las funciones fopen, fclose y similares son tus amigos. Este consejo es el que mas te va a salvar la vida en estos casos, créeme.
- No ignores los avisos
Como recomendación general, cuando estés debuggeando scripts utiliza error_reporting con E_STRICT. Esto te dará un poco mas de información que E_ALL, aunque con el tiempo y conforme vayas mejorando tus habilidades no notaras la diferencia.
- Fuerza bruta
Como ultimo recurso, si nada de lo anterior funciona (que no he encontrado caso en que no funcione) es posible aumentar la memoria disponible para tu script, mediante la directiva ini_set(”memory_limit”, “16M”) la cual elevarÃa a 16 MB la capacidad de tu script. Esta directiva esta disponible en cualquier servidor que permita la ejecución de la funcion ini_set. Aunque se cuidadoso, especialmente si tienes un servidor compartido, se buen vecino y no acabes con el servidor. No te busques problemas gratis
Estos son solo unos cuantos consejos básicos para para esos casos difÃciles. Si este articulo tiene éxito, en algún tiempo pondré algunas técnicas un poquito mas a fondo sobre este tema.
Espero sus comentarios y sugerencias.
o deja comentario en alguna de las entradas del blog.