En Blackslot tenemos reservado un sitio para tí. Buscamos un analista desarrollador php apasionado de las últimas tecnologías en internet y con inquietudes en este campo para trabajar con nosotros.
Entrarías a nuestro equipo para desarrollar proyectos SaaS, redes sociales, i+d tanto propios como para clientes.
Valoraremos si tienes experiencia en las siguientes áreas:
symfony
.net
java, especialmente si has trasteado con android
Como valor extra nosotros ofrecemos al margen del sueldo lo siguiente:
Desde nuestra experiencia podemos decir que no es tanto culpa de la base de datos el que ocurran estos problemas, sino de la programación en la aplicación web o una mala o desatendida gestión en la base de datos y configuración del servidor.
En muchas ocasiones se suele comentar que un cms tiene una muy mala gestión de consultas sobre la base de datos que utiliza, que abusa de ellas o incluso que hace auténticas chapuzas. En algunos casos puede ser cierto, en otros como en el caso de Wordpress mayormente esas afirmaciones radican en un desconocimiento técnico en cómo funcionan realmente esta herramienta y qué cuidados requiere las misma.
Wordpress
Si bien es cierto que podemos ahorrarnos muchas consultas a la base de datos desde Wordpress evitando el uso de algunas de sus Template Tags (funciones que ayudan a crear themes) o plugins que hacen consultas que wordpress ya hace previamente desde su core, esto puede ser totalmente ineficaz si por ejemplo no tenemos especial cuidado en la gestión de la base de datos.
Deshabilitar el motor innodb o los logs del servidor pueden ahorrarnos mucha carga en el servidor, pero no nos libra de tener que hacer una optimización en los valores de query_cache por ejemplo.
Es importante también prestar especial atención en la actualización del propio cms, ya que puede efectuar cambios en el esquema de base de datos, pero mantener funcionalidad obsoleta por compatibilidad, especialmente con plugins o funciones que se puedan seguir usando.
En un caso concreto nos hemos peleado con algún wordpress que hacía consultas antes de lanzar la acción init, que es la acción que activa plugins como WP SuperCache. Esto hacía ineficaz toda posibilidad de cacheo a través de plugins.
Podríamos evitar esta situación cacheando todo el sitio en archivos estáticos html, en memoria a través de módulos memcached a nivel de servidor web, usando sistemas de proxy caché tipo Squid o infinidad de soluciones más. Personalmente creo que este tipo de cosas hay que hacerlas después de asegurarse que la parte de la aplicación web está optimizada o al menos no abusa demasiado de la base de datos. Más que nada porque este tipo de soluciones conllevan una serie de costes asociados, por ejemplo si optamos por cachear todo a disco necesitaremos, en sitios web con medio o alto tráfico, disco SAS a 10k o 15k revoluciones para evitar los cuellos de botella que tendríamos con discos SATA. Muchos proveedores venden esto como “un servidor más grande”, nosotros preferimos abordarlo de otra forma. Evidentemente tiene más sentido optar por soluciones basadas en memoria, como memcached, pero no disponemos de estas opciones en todos los entornos.
Hay otras situaciones en las que un sólo plugin puede ser el culpable de problemas de rendimiento. Muchas veces se confía demasiado en el buen hacer de los desarrolladores de plugins muy utilizados como el All In One Seo Pack, que resulta no ser tan óptimo como cabría esperar.
Nosotros en Blackslot empezamos por hacer un diagnóstico de la aplicación web, en el caso de basarse en wordpress limpiar el theme y el sitio web de funciones y plugins desactualizados, comprobar el buen estado de la base de datos para el CMS en cuestión, desarrollar plugins o themes que utilicen la última versión de la api y si fuese necesario buscar soluciones a nivel de sistema que mejoren el rendimiento de la aplicación.
Estas soluciones pueden ser desde realizar optimizaciones del servidor web y la base de datos, implantar soluciones de cache en memoria, opcode cache para php, distribuir el contenido estático del blog entre varios servidores o servicios de terceros (cloud o no, dependiendo de los requisitos del cliente) hasta soluciones más avanzadas para sitios web de gran cantidad de datos y tráfico.
No siempre una solución puede ser la cura a todas las enfermedades. Se suele escuchar por ejemplo que un tipo de motor de almacenamiento en mysql frente a otro, como el caso de myisam frente a innodb, es más rápido en lectura pero esto no siempre es así. También se pueden ver casos como que una solución memcached de menos rendimiento que algún otro tipo de servidor de base de datos, o frecuentemente que cachear en disco penalice mucho más que almacenar en la base de datos. No se pueden tratar todos los casos por igual en problemas de rendimiento web.
Por lo general hemos tenido alguna experiencia con clientes que teniendo un servidor dedicado saturado con prestaciones no precisamente moderadas, hemos podido migrarles a uno de nuestros servidores HyperV R2 con Linux ahorrándose, con sólo algunos cambios en su cms y últimas versiones en tecnologías de servidor, bastante dinero en hardware al mes.
En las versiones de openSuse x64 me he encontrado con que el SFTP no funciona correctamente, debido a un problema en la configuración del sshd_config. El error que se obtiene al intentar acceder al servidor es el siguiente:
sshd[25558]: error: subsystem: cannot stat /usr/lib/sftp-server: No such file or directory
La solución es tan sencilla como localizar donde se encuentra el archivo “sftp-server” y corregir la ruta en el sshd_config.
Para localizar el archivo:
find / -name sftp-server
En mi caso está en /usr/lib64/ssh/sftp-server
Para arreglarlo basta con hacer un enlace simbólico al archivo
He confirmado que al instalar Plesk 9.3 sobre openSuse, al tratar de ejecutar Yast2 fallará su ejecución:
# yast
//sbin/yast: line 27: //lib/YaST2/bin/yast2-funcs: No such file or directory
//sbin/yast: line 250: set_lang_from_sysconfig: command not found
//sbin/yast: line 279: check_ncurses: command not found
package yast2-qt is not installed
package yast2-gtk is not installed
Something is wrong with the YaST user interface.
El problema es que Plesk modifica $PATH añadiendole de forma incorrecta una doble barra. Basta con quitarla y comprobar que ya funciona.
Obviamente, lo anterior sólo solucionará el problema mientras tengamos la sesión abierta. Para que se conserven los cambios, lo mejor, meterlo en el .bashrc.
Unos rápidos apuntes a tener en cuenta a la hora de virtualizar un entorno SQL Server.
Discos:
- De espacio fijo: En SQL Server es muy importante el I/O de los volúmenes con los que se trabaja, por ello la recomendación es utilizar siempre discos fijos.
- Controladora SCSI: Al igual que sucede en entornos físicos, en virtual sólo podremos colocar hasta 4 discos IDE, por lo que si necesitamos más discos lo mejor es utilizar un bus SCSI.
- Usar varios VHD: Es decir, uno para el propio sistema y los archivos de instalación de SQL, otro para tempdb, otro para los logs, otro para los datos… Esto al igual que en un entorno real permite mejorar el I/O, sobre todo si disponemos de una cabina y dedicamos discos separados (spindles) o LUN para mejorar aún más el I/O. Aún cuando no dispongamos de discos separados sigue siendo recomendable utilizar diferentes VHDs.
- Sistema de archivos: NTFS con unidad de asignación a 64 K para obtener mejor rendimiento.
Red:
- Importante que la red sea Gigabit y la velocidad esté configurada en full-duplex.
- Siempre usaremos los adaptadores sintéticos que usan los Servicios de Integración instalados en la VM para funcionar, ya que ofrecen mucho mejor rendimiento que los emulados, los cuales sólo son útiles por razones de compatibilidad en sistemas que no soportan los Servicios de Integración (anteriores a MS Windows Server 2003 R2, kernels de linux no soportados, etc…).
- Si es posible usar teaming para mejorar el rendimiento y ofrecer redundancia, sobre todo para conexiones a una cabina vía iSCSI.
Memoria:
La memoria se comporta exactamente igual que en una máquina física, a diferencia de otros hypervisores en Hyper-V no se permite el sobreuso (aunque MS ya está trabajando en ello) por lo que la cantidad asignada a una VM se reserva en el anfitrión por completo. Es importante dejar al propio nodo anfitrión 2 GB libres para el sistema y sus tareas.
En alguna situación, sobre todo cuando necesito hacer listados con consultas que tienen muchos joins, condiciones where, orders y similares, necesito hacer una consulta count (que por supuesto posteriormente cacheo) para realizar las paginaciones.
Si generamos este tipo de consultas dinámicamente, lo habitual y desaconsejado consiste en hacer un count contra una subquery que sea esa misma consulta pero sin los limits:
SELECT count(*) FROM ( SELECT ...la query sin los limits) as tuplas
Esto puede ocasionar serios problemas de rendimiento, sobre todo si la consulta contiene cláusulas de tipo ORDER.
Para mejorar esto podemos hacer uso de las funciones strrpos y substr de php, que encuentran la última coincidencia de una cadena o caracter en una cadena dada y parten esa cadena dada según unos límites que establezcamos.
De esta forma podemos tener una consulta count para nuestra query principal, sin tener que reescribir lo mismo dos veces.
/*
eliminamos todos los caracteres en una cadena contenida en $query
desde el final hasta la última coincidencia de la palabra ORDER (contando desde el principio)
Esto hace que eliminemos de la query original los últimos ORDERs y LIMITs
*/
$count_query = substr($query,0,strrpos($query,"ORDER"));
/*
Eliminamos todo desde el pincipio de la query hasta el último FROM encontrado
*/
$count_query = substr($count_query,strrpos($count_query,"FROM"),strlen($count_query));
/*
Agregamos la sentencia COUNT a la query
*/
$count_query = "SELECT COUNT(*) as total ".$count_query;
En ocasiones, cuando necesitamos optimizar ciertas consultas sql o simplemente hacer querys algo complejas, lidiar con el código DQL para generar nuestra query puede llevarnos mucho tiempo.
Para evitar esto, tenemos la posibilidad de ejecutar código nativo desde doctrine
//definimos la consulta
$query = "select id from tabla";
//recuperamos el singleton de la conexión
$con = Doctrine_Manager::getInstance()->connection();
//ejecutamos la consulta
$st = $con->execute($query);
//recuperamos las tuplas de resultados
$rs = $st->fetchAll();
El grupo videoweb lo forman profesionales, entusiastas, empresas y creadores de contenido en formato video para internet.
VideoWeb 2010 es la segunda edición de un evento que este grupo organiza en Bilbao y que este año desde Blackslot patrocinamos junto a otras empresas y profesionales de la talla de Dailymotion.com, Factoría Crossmedia, Hombrelobo.com y EiTB entre otros, en la que se debatirá el presente y futuro del video en la red.
Os animamos a participar ya que todas estas personas están cambiando la forma en que consumimos este tipo de contenido y su transcendencia es clave para el futuro de internet.
La i18n o internacionalización es algo crítico hoy en día para los medios de comunicación online, que se basan mayormente en aplicaciones web.
La plataforma cms más usada en internet es sin duda Wordpress, aplicación web que desde hace años cuenta con soporte i18n para sus themes y funciones internas. El problema siempre ha estado en la i18n del contenido.
Aunque muchos nos básabamos en filtrar por un tag determinado que representase la cultura del post o página que el usuario solicitase, las cosas han evolucionado y gracias a la dedicación e innovación de algunos profesionales en el sector de las traducciones online contamos con herramientas como wpml.
Esta herramienta nos permite no sólo traducir el theme del sitio web, sino que podemos además separar y asociar el contenido en base a su idioma o cultura de una forma muy sencilla. Esta separación tiene en cuenta las urls del sitio web, que pueden ser mediante subdirectorios o subdominios dinámicos.
Wpml es además, un servicio online que a través de este plugin nos permite solicitar una traducción del contenido que queremos publicar a un idioma específico, hecho por un traductor nativo en ese idioma.
En su sitio web disponen de themes de ejemplo para poder estudiar cómo el plugin hace su trabajo, aunque basta con respetar el motor de i18n de wordpress a la hora de desarrollar el theme.
No hay nada como una herramienta hecha por y para profesionales de su sector.
Desde hace ya unos cuantos años, en el desarrollo de aplicaciones web se tiende a utilizar herramientas que contribuyen no a que trabajemos más rápido, sino más ágil.
Ya no tiene sentido contar con grandes equipos de desarrollo, de hecho el nivel de productividad de un equipo formado por programadores y analistas suele verse afectado negativamente cuanta más cantidad de personas estén involucradas en el proyecto.
Normalmente las aplicaciones web conllevan un montón de tareas que son repetitivas o que pueden abstraerse o automatizarse. Conseguir reducir el tiempo que necesitamos invertir para realizar dichas tareas es clave para conseguir ser productivos.
Al igual que en otros lenguajes como ruby, python o c#, en php disponemos de varios frameworks diseñados para conseguir reducir estas tareas y ofreciéndonos una plataforma de calidad, compatible con TDD y centrada en ofrecernos arquitecturas REST, cosas claves en aplicaciones web.
Además de contar con un potente y seguro motor para desarrollar formularios, un sistema de enrutamiento muy avanzado fácilmente internacionalizable, una arquitectura extensible por diseño, y la posibilidad de usar módulos de otras plataformas con Zend Framework o los nuestros propios, los creadores de symfony han desarrollado su propio orm llamado Doctrine que podemos utilizar para atacar a cualquier base de datos cuyo cliente sea compatible con PDO de php.
Doctrine viene por defecto con Symfony, pero también podemos usar la genial alternativa Propel, que personalmente nos permite hacer de forma mucho más elegante la i18n.
Como todo desarrollador con experiencia sabe, el crear el modelo de base de datos para nuestra aplicación y las clases que van a permitirnos operar con ellas, es la parte que probablemente conlleve más tareas automatizables o potencialmente abstraibles. Por ello, es muy importante el uso de un orm que nos automatice todo el trabajo.
Para muchos programadores esto les parecerá un error, ya que a veces solemos preocuparnos demasiado pronto por temas de rendimiento cuando en realidad deberíamos preocuparnos por terminar unas cuantas fases previas que son las que realmente nos van a permitir tener el proyecto online con calidad en un tiempo aceptable.
Crear el modelo
Como la mayoría de cosas en symfony, para crear nuestro modelo podemos hacerlo mediante un archivo de configuración yaml.
Este archivo se llama schema.yml y se ubica en el directorio config/doctrine, siendo relativo a todas las aplicaciones de nuestro proyecto symfony.
La sintaxis es bastante comprensible y nos permite de una forma limpia y sencilla representar nuestro modelo de datos.
Este archivo de configuración nos permite tener un esquema fácilmente mantenible que permitirá a symfony automatizar las tareas de creación del código sql para crear la base de datos, además de todas las clases php que usaremos para trabajar con la misma.
#creamos el código sql encargado de crear la base de datos
php symfony doctrine:build-sql
#creamos las clases php para trabajar con esta base de datos
php symfony doctrine:build-model
Esto nos ha ahorrado una cantidad increíble de tiempo, que tendríamos que haber invertido en tareas que en principio no son costosas en complejidad pero si en tiempo.
Vemos ahora cómo insertar un registro en la tabla que hemos creado, hacemos un select, un update y lo borramos.
//hacemos un insert en la base de datos
$user = new User();
$user->name = "Manolo";
$user->bord_date = date("d-m-Y",strtotime('1974-02-11'));
$user->save();
//hacemos un update
$user->name ="María";
$user->save();
//eliminamos el registro
$user->delete();
//hacemos un select
$q = Doctrine_Query::create()->select('u.name')->from('User u')->where("u.user_id = ? ") ;
$items = $q->execute(array(1));
foreach($items as $item){ echo $item->name; }
Generando el schema.yml desde Mysql Workbench
Hasta ahora nuestro mayor trabajo a la hora de crear nuestro modelo, sin contar el tiempo que hemos invertido en pensar su diseño, ha sido crear el archivo schema.yml.
Esto también se puede automatizar mediante un plugin para mysql workbench que nos permitirá exportar nuestro diagrama e/r directamente a un archivo.yml.
Con nuestra tabla ahora podremos crear nuestro schema.yml desde el menú plugins/catalog, pudiendo generar un archivo o directamente pegarlo en el portapapeles.
Hay que tener cuidado con este plugin ya que nos nombres de las clases del modelo, que represantan las tablas de nuestro modelo, las escribirá en minúsculas cuando por convención deberían empezar con la primera letra capitalizada.
Conclusión
Actualmente existen diferentes herramientas y técnicas que nos permiten ser muy productivos a la hora de desarrollar aplicaciones web, como es el caso de Symfony y Doctrine.
