enlace:

From Swift Mailer to Zend_Mail

tiene varios ejemplos y casos de uso; muy útil para quien todavía no a utilizado esta clase

1. <?php

3. /* Read page 1 */

4. $im = new imagick( 'test.pdf[0]' );

6. /* Convert to png */

7. $im->setImageFormat( "png" );

9. /* Send out */

10. header( "Content-Type: image/png" );

11. echo $im;

13. ?>

(el cero que está entre [ ] es el numero de páginas)
Articulo original: Creating a PDF preview
Gracias a: http://valokuva.org

Hoy he visto el correo y en el boletín de Zend venía un vídeo bastante interesante.

Un vídeo en el que podremos ver como podemos multiplicar por 30 el rendimiento de server con Zend Plataform

intro: el perfil ideal de un diseñador web también tiene que saber maquetar y conocer todos los elementos xhtml y componentes que se puedan crear; sí a esto le añadimos que también sabe javascript y lo que es la estructura de información, posiblemente sea un diseñador web.

Al contratar a un diseñador, para diseñar web’s, muchas veces no se le pide que sepa del mundo web.

Este error suele salir muy caro en el momento de producción. Algunos diseñadores no son capaces de entender que el navegador web no es Photoshop.

Cuando juntas a este tipo de diseñador “web” con la persona encargada de maquetar y desarrollar la página, no podrán ponerse de acuerdo en muchas cosas. El problema viene porque la web no es algo estático y fijo, algo que el diseñador no sule tener en cuenta cuando se pone a hacer sus diseños.

Posiblemente veas sus diseños y quedes impresionado por lo bonito que es; pero si le haces una pregunta tan simple como:

“¿si pincho aquí que pasa?, si paso el ratón por encima ¿qué pasa?”, …

Es muy probable que este tipo de cosas no vengan reflejado en su precioso Psd, ni tampoco en ningún lado.

Este tipo de “contratiempos” son realmente triviales, se solucionan hablando con el diseñador y dándole ideas.

El verdadero problema viene cuando tienes que hacer un portal con numerosas páginas y distintos tipos de contenido (tablas, listas, imágenes,…). En este punto es probable que el diseñador desarrolle un diseño para cada pagina con:

• distintos tipos de colores en las fuentes,
• muchas “cajitas” con sombras, degradados,…
• tipos de fuente que no vienen por defecto en el sistema(windows, linux, mac, …),
• suelen utilizar un sistema de reticulas modular(no sigén un patron fijo),
• sus cajas son fijas y no están pensadas para ser más o menos grande
• piensan que los fondos aparecen solos y se autoajustan

a todo esto hay que sumarle:

• haran diseños raros para los formularios
• se enfadán cuando les cambies la tipografía en el diseño(se la cambias, porque no hay ese tipo de tipografía el ordenador del usuario)
• no suelen entender la idea de “componente”(cajaDestacado, cajaImage, tabs, …)

En fín; este tipo de cosas minan la moral del maquetador(en este caso yo) .

Todo esto se puede corregir con la “actualización”, por parte del diseñador y tendrá que pasar muchas horas mirando cientos de web, apuntado a feed de diseño web, ver las ultimas cosas que están saliendo en la web

http://docs111.mootools.net/

allí tenemos la documentación de la versión anterior en mootools

Como es visible no he podido escribir mucho últimamente. Esto a sido debido a mi incorporación en un gran proyecto(grande para mí).

Mi trabajo consistía en desarrollar toda la parte frontend de 5 portales.

Aquí hago una lista de las experiencia que me ha reportado este trabajo, por el que tenía mucha ilusión.

• trabajar con una empresa de gran nombre, no significa que sus empleados sean buenos; aunque la empresa sea una IT internacional. Nunca olvides la segunda ley de la estupidez humana del doctor Cipolla
• es cierto todo lo que he leído; una mala planificación de proyecto cuesta muchos dolores de cabeza y dinero
• Un diseño sin wireframes y creado según se va avanzando el proyecto; puedes volverte loco con los css; porque nunca sabrás que componente nuevos habrán ni como evolucionarán.
• si sabes que tienes razón y ves la cosa mal; defiende tus ideas porque al final tendrás que hacerlo y perderás todo el entusiasmo.
• si ves a un tío de traje, pregúntale si sabe programar. Es muy probable que te diga que no
• si ves a un tío de traje; háblale con tecnicismos, dispara todas las siglas que te sabes, no dudes en corregirle, explícale tu experiencia y lo que conlleva hacer eso que sabes que está mal
• asiste a todas las reuniones; si el responsable de proyecto no sabe diferenciar un <select/> de un <ul/>
• deja todas las opiniones y consejos por correo electrónico; que haya pruebas de que tu avisaste de las catástrofes
• si la coordinadora de proyecto no tiene mucha idea: no le des ideas, impón soluciones, 2 como mucho
• la maquetación frontend es importante, y es una gran responsabilidad. has que ellos se enteren
• no te enfades cuando te mandan cambiar 6 veces una maquetación; no vale la pena amargarse por lo que te pagan
• el contenido tiene que ser similar al “real” es muy importante; da buena impresión.(Loren ipsun, no ayuda mucho)
• los malos jefes le dan más importancia al volumen de la documentación que ha tu código.

Para los que van a empezar un gran proyecto con gente que no sabe lo que es internet: Puede que tus jefes se llenen los bolsillos de dinero, tu no ganaras para aspirinas.