A continuación, paso a comentar cuáles son estas reglas y las veo yo, según mi experiencia. Los comentarios a estas reglas son para sitios pequeños y para sitios en servidores dedicados con acceso sólo al .htaccess. Si tienes una web en una instancia de Linode o Amazon, no te digo que estas reglas no sirvan, pero tienes a tu disposición herramientas potentísimas como Varnish para acelerar tu sitio de mejor modo. Del mismo modo voy a comentar estas reglas desde el punto de vista de alguien que tiene un sitio pequeño/mediano. Si trabajas en Tuenti, seguramente deberías hacer las cosas de otra forma.

• 1. Cuantas menos peticiones HTTP, mejor

  para iconos y pequeñas imágenes se recomienda el uso de imágenes inline

• 2.Usa un CDN

  Esto es ridículo para un sitio pequeño y está fuera de lugar

• 3. Añade un “ExpiresHeader” a tu .htaccess

  Aquí caemos en el debate de que si añades a todos los elementos un expire en el futuro lejano, cuando cambies un js o un css, el usuario no pillará los cambios a no ser que cada vez le cambies de nombre al fichero

• 4. Usa compresión

  AddOutputFilterByType DEFLATE text/html text/css

• 5. Hojas de estilo al principio

  [link]dentro de [head]

• 6. Scripts JS al final

• 7.Evita las expresiones CSS

  Tranquilo, no lo hace casi nadie

• 8. JS y CSS en ficheros externos

  No tengo muy claro en qué medida acelera la carga, pero pondrá orden en tu vida

• 9. Pocas búsquedas al DNS

  Poner un TTL y controlar el Keep-Alive

• 10. Optimiza tu JS

  La herramienta que usa todo el mundo es JSMin

• 11. Evita los redirect

  301, 302, etc .. en general, ralentizan todos

• 12. Evita scripts duplicados

  Revisa también llamadas a ficheros que ya no usas

• 13. Configura los ETags

  Yo prefiero quitarlos con FileEtag none

• 14. Haz Ajax cacheable

  De nuevo, atención al Expires

Con sólo seguir unas pocas de estas recomendaciones el tiempo de carga de la página se puede reducir entre un 40 y un 60%

Para acabar os dejo unos enlaces para profundizar en el tema:
- https://developers.google.com/pagespeed/
- http://gtmetrix.com/
- http://webperformanceoptimization.es

Share on Facebook

Share on Facebook

Bajar Drupal e instalarlo desde la consola:
1. Bajamos el código
drush dl drupal
2. Hacemos una instalación estándar
drush si standard --db-url=mysql://admin:admin@localhost/drupal7
3. Si tenemos alguna duda el comando help es nuestro amigo
drush help dl

Para administrar Drúpales remotos podemos teclear:
drush site-alias @self --full en el directorio local donde tengamos instalado drupal
Esto nos proporciona un código como el siguiente:

$aliases['local'] = array (
'root' => '/var/www/html/dev',
'uri' => 'http://dev.com',
);

Bien, este código lo pegamos en el fichero
~/.drush/aliases.drushrc.php
(si no tenemos el directorio .drush, lo creamos)
A continuación vamos a crear tantos arrays como éste como sitios remotos tengamos, por ejemplo añadimos al fichero otro array tal que

$aliases['remoto'] = array (
'root' => '/var/www/miweb',
'uri' => 'http://mi-super-web.com',
);


Vale, ahora drush se encarga de acceder al sitio «remoto» por medio de SSH por medio de vuestra clave RSA. Si no la tenéis creada, la creáis y después sólo queda añadir vuestra clave para que el servidor remoto deje actuar a drush.
Dejar claro que Drush para operar en remoto utiliza SIEMPRE claves SSH.
Lo normal es bajarse el paquete drush_extras de la web de Drupal y descomprimirlo en ~/.drush Drush_extras nos proporciona el comando pushkey.
Por lo tanto, debemos ejecutar el siguiente comando:

drush pushkey usuario@servidor

En mi caso, utilizo los servicios de la nube de Amazon, por lo que puse en usuario el usuario que normalmente uso para entrar con SSH en el servidor y en la parte del servidor puse el nombre de Host que tengo en
~/.ssh/config
Este comando no retorna nada. Si no os da error, ha funcionado.
A partir de aquí podéis acceder al servidor remoto con drush con la siguiente sintaxis

drush @servidor comando

Pongo a continuación algunos comandos, de los mas usados:

drush @servidor status

muestra el estado de Drupal, da la siguiente salida


drush sql-cli

nos abre una sesión de mysql con el usuario de drupal

drush sql-sync @maquina-desde @maquina-hacia

sincroniza las bases de datos de dos máquinas

drush @servidor vs maintenance_mode 1

para poner el servidor en mantenimiento con drush
«vs» es «variable-set» y «vg», «variable-get»

drush ws

muestra el watchdog de nuestro Drupal, como véis aquí

Y ya me he aburrido de poner comandos, pero existen muchos más y muy útiles. Podéis comprobarlo vosotros mismos en la documentación de Drush.

Toda esta información y mucha mas nos fué ofrecida por Manuee en la charla del de la Asociación Drupal Madrid el día 24 de Noviembre de 2011. Si vives en Madrid, las charlas de Drupal Madrid son una excelente forma de aprender y de hacer networking. ¡Aprovecha la oportunidad!

Share on Facebook

Los argumentos se pasan de la siguiente manera:

php fichero.php arg1 arg2
Además contamos con las siguientes variables y funciones:
$argc: número de argumentos
$argv: los argumentos pasados en un array (el propio fichero php ocupa la primera posición)
getopt: para manejar los argumentos

A su vez, el binario de PHP desde la consola nos ofrece las siguientes funcionalidades:
php -a → shell interactiva [con tab completion :-) ]
php -r → ejecuta código Ejemplo:   php  -­‐r  "echo  date('Y-­‐m-­‐d  H:i:s');”
php -i → ofrece información del php.ini [Ejemplo: php -i | grep "log_errors" ]
php -l → chequea errores de sintaxis (lo uso a diario)
php -m → da una lista de los módulos incluídos en tu distribución de PHP
php -s →  resaltado de sintaxis (utilísimo para formatear código en html) [Ejemplo: php -s hola.php > hola.html]
php -v → información de la versión de PHP
php --rf → da una pequeña referencia sobre la función que le pases [Ejemplo: php --rf print_r]
php --ri → información sobre la extensión que le pases [Ejemplo: php --ri pdo]

Recuerda que con PHP desde la consola ya no estás recluído en /var/www, sino que puedes ejecutar cualquier script desde cualquier lugar! Incluso con el shebang adecuado (#!/usr/bin/php) puedes ejecutar con PHP un fichero sin extensión .php

Échale un ojo, ¡hay gente que con scripts de PHP para consola maneja hilos!

Esta información la aprendí en la PHPConference 2011 de Barcelona en la charla de Thijs Feryn y me ha encantado compartirla con vosotros :-)

La presentación que dio Thijs está aquí

Share on Facebook

• la base de datos en binario de Maxmind (para geolocalizar las ips)
• una user key de Google Maps
• token y secret de usuarios en el API de 11870

y poco mas. Se configura todo en 10 minutos.
La instalación es la acostumbrada: subís el módulo, lo habilitáis, lo configuráis (tiene pantalla de configuración) y lo añadís a vuestro theme como bloque.

La salida del html del bloque está harcodeada en el código. A partir de aquí sois libres para modificarlo/mejorarlo como queráis.

Podéis ver un ejemplo funcionando (restaurante vegetariano cercano) en mi web personal http://leandro.org
Bon apetit! :)

Share on Facebook

[Ahora, si tu eres tan listo que te consideras capacitado para superar el trabajo de Rasmus y demás, creo que la discusión está de mas ...]

3. no nos engañemos, PHP ha tenido y tiene éxito porque es rápido y se pueden hacer ñapas. Veamos como se resuelve un bug en RoR: el gurú de turno tardará 10 minutos, si, pero, si es como debe ser, se pasará 2 días haciendo tests unitarios. Veamos en java: tardará mas forzosamente porque tiene que lidiar con el obligatorio andamiaje de objetos con el que capean a diario. En PHP se tarda 10 minutos y en otros 5 está en producción. Es así, PHP es guarro y efectivo, por eso ha triunfado.
Ojo, no estoy diciendo que la POO sea una mala idea. Al contrario, digo que no siempre es adecuada para PHP. Lo entiendo como lo más adecuado para un framework (Zend, CodeIgniter …) o una librería, pero se me ocurren muchos casos en los que no merece la pena.
Por ejemplo: cualquier tarea de sistemas, scripts de control o monitorización, micro-sites, una página personal, etc. Veamos en detalle el ejemplo de un micro-site comercial que vivirá lo que dura una campaña (unos meses) Pues no merece la pena usar POO, es más, ni siquiera plantillas. Señores, si no vas a reutilizar el código, las líneas van a ser pocas y no va a haber mantenimiento la POO no merece la pena. La POO se inventó para equipos de desarrollo de muchas personas donde se iba a reutilizar el código en el futuro ¿Sois pocos desarrollando? ¿No vas a reutilizar el código? Pues no uses POO, está claro.

El problema es que eres una persona (con o sin carrera) que se cree inteligente y le gusta admirar las cosas complejas. Empezaste a programar en un numeroso equipo picando Java. Te metieron a fuego en la cabeza cosas como patrones de diseño, closures, namespaces y cosas de esas … y ahora, claro, llegas a PHP y pretendes hacer lo que sabes hacer.
Para eso está Java, no trabajes con PHP: serás mas feliz.

¿De verdad el patrón fachada, por ejemplo, es necesario en PHP? ¿Sólo porque viste que era lo mas usado en Java ahora tienes que repetirlo en PHP aunque sea con calzador? ¿Hay alguna razón objetiva para ello?
¿De verdad te merece la pena complicarte la vida y tardar más sólo para satisfacer tus exigencias estéticas o académicas?
¿Por qué hacer las cosas bien es hacerlas como se hace en un entorno empresarial?
Me gustaría saber, en serio, de dónde vienen estas ideas.

Share on Facebook

Share on Facebook

Hoy en día todos compartimos media vida (la digital) con empresas privadas como Facebook, Google, Apple o Microsoft. Estas empresas venden o ceden gratuitamente nuestros datos e información al mejor postor o a los gobiernos.
Ya lo advirtió Richard Stallman hace un par de años: «Uno de los peligros del sistema de software privativo, es que se usa para conocer datos de los usuarios y controlarlos: “Los usuarios aceptan lo que debería ser un escándalo“»

Precaución, amigos!

Share on Facebook

cp -r mantis mantis-1.2.4

2. a) ahora nos bajamos el repo de desarrollo de mantis y hacemos un diff entre las 2 últimas versiones:

git clone https://github.com/mantisbt/mantisbt.git
git diff –no-prefix release-1.2.4..release-1.2.5 > mantis-1.2.4-to-1.2.5.patch

b) si ya tenemos descargado el repo, simplemente actualizamos haciendo un pull:

git pull
git diff –no-prefix release-1.2.4..release-1.2.5 > mantis-1.2.4-to-1.2.5.patch

3. por último aplicamos el parche al código original:

cd /tu/directorio/de/mantis
patch -p0 < mantis-1.2.4-to-1.2.5.patch

4. ¡Hecho!

nota original de Wim Leers

Share on Facebook

options.ui.muc.userlist.avatars.show

Share on Facebook