Para los players en HTML, me he encontrado con un problema a la hora de usar el fullscreen. Este problema se me ha dado tanto en Internet Explorer como en Chrome, mientras que en Firefox no tenía ningún problema. En mi caso ha sido usando el FlowPlayer, pero puede apicarse a otros players.
El efecto del problema es que al pulsar sobre el maximizar se puede observar cómo el navegador trata de maximizarlo, en Explorer dentro del espacio que hay bajo los botones (es como funciona el fullscreen a día de hoy en Explorer), y en Chrome se puede ver la pantalla completa en negro, pero el video se sigue reproduciendo al mismo tamaño que antes de maximizar.
Es como si el video se quedara del mismo tamaño que el contenedor en el que está metido.
Pues se trata de algo obvio en realidad, el css que contiene los estilos del player, tenía un !important en el height y width del player. Esto hace que aunque el navegador pase a modo maximizar se respete dicho ancho y alto establecido en la hoja de estilos. Lo lógico es evitar siempre que sea posible el uso de !important, aunque seguro que siempre hay un buen motivo detrás de cada uno de ellos...
viernes, 21 de febrero de 2014
NEAR en MySQL
MySQL ofrece a través del MATCH AGAINST una serie de funcionalidades "avanzadas" de búsqueda, que pueden aprovecharse de los índices fulltext. Concretamente con el Boolean mode, podemos buscar cuando están o no unas determinadas palabras, otorgar pesos, truncamiento...
Pero podemos necesitar la funcionalidad NEAR que ofrecen los motores de búsquedas, como el Sphinx.
NEAR sirve para buscar registros en los que unas determinadas palabras aparezcan a determinada distancia la una de la otra, por ejemplo, para el registro:
Esta mañana el presidente del gobierno ha desayunado con el ministro de agricultura
La query con la condición presidente NEAR/6 ministro devolvería el registro indicado, mientras que NEAR/3 o NEAR/4 no lo encontrarían.
Básicamente es un método para asegurarnos de que las palabras que buscamos están cerca, y por lo tanto, que sea más probable que se refieran al mismo contexto.
Si tratamos de aplicar expresiones regulares directamente sobre los registros, y tenemos un gran volumen de datos (muchos registros y mucho texto en cada uno de ellos), veremos que la ejecución es excesivamente lenta.
La idea consiste en aprovechar los índices fulltext para filtrar rápidamente el número de posibles "candidatos", y luego aplicar la expresión regular para confirmar que las palabras se encuentran a la distancia deseada. Cuantas más palabras metamos en el proceso, la expresión regular se volverá más compleja, pero a su vez el número de registros candidatos será cada vez menor.
Además podemos usar algo del tipo NEAR/2-5, de forma que las palabras tengan que estar separadas por 2,3,4 o 5 palabras intermedias. NEAR/0-5, NEAR/5-5,...
Supongamos que tenemos una tabla NOTICIAS con (entre otros) un campo TEXTO que contiene el texto de nuestras noticias (se supone que TEXTO tiene el ínidice fulltext creado), veamos cómo quedaría la query:
SELECT * FROM NOTICIAS WHERE MATCH (TEXTO) AGAINST ('+presidente +ministro' in boolean mode) AND TEXTO REGEXP 'presidente([[:space:][:punct:]]+[^[:space:]]+){0,6}[[:space:][:punct:]]+ministro'
El + delante de las palabras en el AGAINS en boolean mode nos sirve para asegurarnos de que dichas palabras están en el registro que vamos a analizar, y será lo que nos permita tener un buen filtrado para que la query sea lo más rápida posible. No voy a detenerme mucho en explicar la expresión regular, ya que hay mucha documentación al respecto en la web.
Queda como ejercicio al lector jugar con la expresión regular para hacer el NEAR en los dos sentidos o añadir o quitar determinados caracteres... Lo importante es intentar mantenerla lo más simplificada posible, ya que la complejidad aumenta muy rápidamente.
Pero podemos necesitar la funcionalidad NEAR que ofrecen los motores de búsquedas, como el Sphinx.
NEAR sirve para buscar registros en los que unas determinadas palabras aparezcan a determinada distancia la una de la otra, por ejemplo, para el registro:
Esta mañana el presidente del gobierno ha desayunado con el ministro de agricultura
La query con la condición presidente NEAR/6 ministro devolvería el registro indicado, mientras que NEAR/3 o NEAR/4 no lo encontrarían.
Básicamente es un método para asegurarnos de que las palabras que buscamos están cerca, y por lo tanto, que sea más probable que se refieran al mismo contexto.
Si tratamos de aplicar expresiones regulares directamente sobre los registros, y tenemos un gran volumen de datos (muchos registros y mucho texto en cada uno de ellos), veremos que la ejecución es excesivamente lenta.
La idea consiste en aprovechar los índices fulltext para filtrar rápidamente el número de posibles "candidatos", y luego aplicar la expresión regular para confirmar que las palabras se encuentran a la distancia deseada. Cuantas más palabras metamos en el proceso, la expresión regular se volverá más compleja, pero a su vez el número de registros candidatos será cada vez menor.
Además podemos usar algo del tipo NEAR/2-5, de forma que las palabras tengan que estar separadas por 2,3,4 o 5 palabras intermedias. NEAR/0-5, NEAR/5-5,...
Supongamos que tenemos una tabla NOTICIAS con (entre otros) un campo TEXTO que contiene el texto de nuestras noticias (se supone que TEXTO tiene el ínidice fulltext creado), veamos cómo quedaría la query:
SELECT * FROM NOTICIAS WHERE MATCH (TEXTO) AGAINST ('+presidente +ministro' in boolean mode) AND TEXTO REGEXP 'presidente([[:space:][:punct:]]+[^[:space:]]+){0,6}[[:space:][:punct:]]+ministro'
El + delante de las palabras en el AGAINS en boolean mode nos sirve para asegurarnos de que dichas palabras están en el registro que vamos a analizar, y será lo que nos permita tener un buen filtrado para que la query sea lo más rápida posible. No voy a detenerme mucho en explicar la expresión regular, ya que hay mucha documentación al respecto en la web.
Queda como ejercicio al lector jugar con la expresión regular para hacer el NEAR en los dos sentidos o añadir o quitar determinados caracteres... Lo importante es intentar mantenerla lo más simplificada posible, ya que la complejidad aumenta muy rápidamente.
viernes, 10 de enero de 2014
Límite en tamaño máximo de subida en PHP (upload_max_filesize)
Para hacer subidas de ficheros grandes a un servidor web Apche con PHP, es ncesario cambiar dos variables de configuración del php.ini:
- upload_max_filesize: Que establece el tamaño máximo que puede tener un fichero que se va a subir-
- max_post_size: Establece el tamaño máximo total que puede subirse en el POST. Aquí se debe incluir cualquier otra información que se suba en ese momento.
Para estas variables se puede usar la M para indicar megabytes y la G para gigabytes.
Si se establece el upload_max_filesize a 100M y el max_post_size a 210M, se podrán subir simultáneamente 2 ficheros de hasta 100M.
Pero he encontrado un problema en Windows (Server 2008 R2), con Apache 2.2.8 y PHP 5.2.4, no sé si afectará en otras versiones más modernas (pero imagino que sí).
Si se establecen unos valores a partir de 2048M o 2G para estas variables, TODAS las peticiones POST llegan al servidor vacías. Da la sensación de que se está interpretando mal el valor introducido (overflow) y se está usando un 0 como tamaño máximo del post.
Usando un máximo de 2000M para ambas varibales no tenemos dicho problema, pero estamos limitados a ficheros de casi 2GB.
Por otro lado hay que tener en cuenta que muchos navegadores no permiten sobrepasar el límite de los 2GB, por lo que en realidad no tenemos mucho más margen (si estamos trabajando con navegadores, ya que para servicios web sí podría interesarnos ir a otros tamaños).
- upload_max_filesize: Que establece el tamaño máximo que puede tener un fichero que se va a subir-
- max_post_size: Establece el tamaño máximo total que puede subirse en el POST. Aquí se debe incluir cualquier otra información que se suba en ese momento.
Para estas variables se puede usar la M para indicar megabytes y la G para gigabytes.
Si se establece el upload_max_filesize a 100M y el max_post_size a 210M, se podrán subir simultáneamente 2 ficheros de hasta 100M.
Pero he encontrado un problema en Windows (Server 2008 R2), con Apache 2.2.8 y PHP 5.2.4, no sé si afectará en otras versiones más modernas (pero imagino que sí).
Si se establecen unos valores a partir de 2048M o 2G para estas variables, TODAS las peticiones POST llegan al servidor vacías. Da la sensación de que se está interpretando mal el valor introducido (overflow) y se está usando un 0 como tamaño máximo del post.
Usando un máximo de 2000M para ambas varibales no tenemos dicho problema, pero estamos limitados a ficheros de casi 2GB.
Por otro lado hay que tener en cuenta que muchos navegadores no permiten sobrepasar el límite de los 2GB, por lo que en realidad no tenemos mucho más margen (si estamos trabajando con navegadores, ya que para servicios web sí podría interesarnos ir a otros tamaños).
Suscribirse a:
Entradas (Atom)