Tag Archives: Editorial

Luis Eduardo Barrueto
octubre 14, 2009

Gráficas sociales: seguridad, desarrollo y aplicaciones

PrivacidadLos dos grandes problemas al centro de la discusión sobre las gráficas sociales son la privacidad y la propiedad de la información.

Lo que esperamos es pasar la menor cantidad de tiempo registrándonos, configurando nuestros perfiles y diciéndole al sistema lo que queremos. Podemos hacer uso de la gráfica para conectarnos y comunicarnos más efectivamente, pero más importantemente no buscamos sentirnos en control, sino de verdad ESTAR en control de nuestra información personal: elegir no sólo con quién queremos ser amigos, sino decidir cómo va a ser usada nuestra información sobre ellos.

Cuando las redes sociales son apenas startups, parece que lo comprenden muy bien y el incrementar su cantidad de usuarios es el mayor incentivo para compartir información con nosotros, pero a medida que crecen dejan de actuar así. Es por eso que aquí entra en juego la utilización de una API, que tanto continúa beneficiando a la empresa como a los usuarios finales.

La API de la gráfica social

En su artículo, Brad Fitzpatrick explícitamente describía que era necesario una API o un servicio que serviría de “corredor” para la información entre las distintas redes sociales. Él visualiza una base de datos de código abierto que aceptará información de múltiples redes sociales y que la pone a disposición de los usuarios finales a través de una API o una interfaz de usuario. El usuario estaría en capacidad de autorizar a otras redes sociales a hallar esa información.

El primer reto técnico es construir un sistema que pueda crecer según la escala de usuarios crezca de la misma manera. Lo segundo es construir un sistema que sea seguro y una vez cumplamos con estos dos retos, hacer que las compañías utilicen esta API.

El problema tiene que ser abordado no desde el punto de vista de obligar a compañías como Facebook a importar su información a esta nueva base de datos, porque no lo van a hacer, sino que implementen facilidades para que los usuarios puedan exportar su información de forma personal: esto tampoco es la panacea, porque los usuarios estarían restringidos a un proceso manual en el que pueden ocurrir errores.

Un acercamiento más automatizado sería definir una API que todas las redes sociales puedan implementar para que todas las demás redes puedan consultar un subconjunto de la gráfica social. En términos prácticos, esto podría decirse así: “Cuando el usuario se une a una nueva red, esa red puede conectarse a las otras en las que la persona ya está registrada y obtener información sobre sus usuarios en todas ellas”. ¿Muy parecido a la función de importar a tus amigos desde el email? El reto es hacer labor de convencimiento con las redes sociales para que ofrezcan soporte a este tipo de funcionalidad.

Un punto de vista adicional: Tim Berners-Lee

Tim Berners-Lee
El inventor de la WWW, Berners-Lee, escribió un artículo en donde tomaba por referencia lo que dijo Brad Fitzpatrick y distinguió la “gráfica” como el tercer “nivel” de la computación en red.

Él distingue esos niveles de la siguiente manera:

  • La internet: establece nexos entre computadoras.
  • La web: establece nexos entre documentos.
  • La gráfica: establece nexos entre personas y/o documentos. – “No son los documentos los que important, sino las cosas [y personas] sobre las que son esos documentos”

La gráfica, para Berners-Lee se trata únicamente de conexiones y la reutilización de información. También nota que a medida que subimos de nivel perdemos cada vez más control, pero ganamos cada vez más beneficios. Uno de esos beneficios sería la reutilización de nuestra información personal y sobre nuestros contactos a lo largo y ancho de múltiples redes.

“Dejar tu información conectarse a la de las otras personas se trata un poco de “dejar ir” en ese sentido. Aún no se trata de darles a los demás la información a la que no tienen derecho. Es acerca de hacer posible que ésta se conecte a información de sitios peers, que se una a la información de otras aplicaciones. Esto es acerca de estar emocionado por crear conexiones, más que nerviosos”.

Las implicaciones dentro de la web móvil

Berners-Lee también nos dice que el uso de la gráfica social también tiene grandes implicaciones para la web móvil, que el resume planteándonos un escenario específico:

“Cuando reserve un vuelo es el vuelo lo que me interesa. No la página del vuelo en el sitio de viajes o en el sitio de la aerolínea, sino la URI (provista por las aerolíneas) del mismo vuelo. Eso es lo que yo quiero bookmarkear. Y cualquiera que sea el dispositivo que utilice, éste tendrá acceso a una vista (apropiada a la situación) de una integración de todo lo que necesito saber sobre ese vuelo por parte de diferentes fuentes. La tarea de reservar y tomar el vuelo involucrará varias interacciones. Y a través de todas ellas, esa tarea y el vuelo será lo principal, los sitios web involucrados serán cosas secundarias, y la red y los dispositivos serán terciarias”.

A manera de conclusión

Brad Fitzpatrick inició una discusión acerca de los conceptos básicos implicados en el tema de la gráfica social: ¿Qué es? ¿A quién le pertenece? ¿Cuál es la API?

Todas estas cuestiones deberán moldear la evolución de la web social y aunque las situaciones y retos dan la apariencia de ser relativamente simples, las soluciones llevarán bastante trabajo.

Los retos son conceptuales, técnicos, políticos, empresariales y educacionales. Tomará la convergencia de muchas personas (y sus mentes, claro) para que la utilización de las gráficas sociales como la plantea Brad pueda suceder. Tradicionalmente, la industria de la tecnología ha logrado satisfacer a los usuarios y así salir adelante, así que esperaremos que vuelva a suceder lo mismo en este caso.

Tim Berners-Lee ha hecho una gran contribución utilizando el término de la “gráfica social” y mezclándolo con su propia visión de la web semántica. Lo que él describe en su artículo es más amplio que lo que concierne a cualquiera de las redes sociales vigentes: es acerca de cómo interactuamos y compartimos nuestra información en la web (a través de cualquiera que sea el medio) y las conexiones de las que podemos tomar ventaja para utilizar la red de mejor manera: las aplicaciones semánticas.

Luis Eduardo Barrueto Luis Eduardo Barrueto para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Rundes
octubre 5, 2009

Entendiendo los modos multiproceso de Apache

apache-logoEl servidor web Apache 2.x puede ser configurado para manejar las peticiones de diferente forma, desde el punto de vista en que son creados y manejados los subprocesos necesarios que atienden a cada cliente conectado a este.

Multiproceso tipo Prefork

  • Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
  • Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
  • Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
  • Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
  • Prefork es la configuración predeterminada en la mayoría de instalaciones.

Multiproceso tipo Worker

  • Apache inicia varios subprocesos y estos a su vez mantienen varios hilos (threads) con los cuales procesaran las peticiones. Un subproceso proceso puede atender a varios clientes a la vez, según se indique en ThreadsPerChild.
  • El hecho de que un subproceso pueda manejar varias peticiones a la vez, hace que se requieran menos recursos para atender a cierto número de peticiones simultaneas.
  • El inconveniente de Worker está en que requiere que todos los módulos/extensiones que se vayan a usar sean Thread-Safe, limitando el tipo de procesamiento que se puede llevar a cabo con el servidor web.
  • Un fallo crítico (que el subproceso termine repentinamente) afecta a varias peticiones, por eso se requiere que se cumpla el Thread-Safe.
  • Ya que no se pueden usar aceleradores de PHP junto a Worker, el uso intensivo de este debería ser evitado con algún tipo de sistema de caché adicional (si fuera WordPress usaría WP-Cache).
  • Worker puede ser una buena solución para un servidor de contenido estático.
  • Worker solo está disponible desde Apache 2.x .

Prefork vrs Worker

Para darles una idea de la diferencia en el consumo de recursos entre Prefork y Worker, los he utilizado en las siguientes condiciones:

  • Prefork en un servidor bastante poderoso (8 núcleos y 4GB de RAM), manejando casi solo contenido generado desde PHP y con XCache instalado. El contenido estático se sirve desde otro servidor.
  • Worker en un servidor sencillo (2 núcleos y 4GB RAM), más que todo contenido estático. La mayoría del contenido generado con PHP queda almacenado en cachés (siendo a la larga contenido estático).

Carga promedio del servidor configurado con Prefork:

apache-prefork

Carga promedio del servidor configurado con Worker:

apache worker

  • El servidor de 8 núcleos (Prefork) promedia una carga del servidor mucho más alta, que el servidor de 2 núcleos (Worker).
  • Si hablamos solamente las peticiones simultaneas que cada uno puede manejar, el servidor con Worker puede manejar casi el doble que el servidor con Prefork, y aún con una carga en el servidor más baja. Manejaría muchas más antes de que el servidor llegue a su límite. Para que Prefork llegue a estos niveles, tendríamos que lidear con el ServerLimit (que en CentOS significa modificar el código de Apache) y apostar por más memoria RAM.
  • Obviamente la aplicación en el servidor con Prefork utiliza mucho más CPU, si modificáramos el servidor web para que use Worker, la misma aplicación tendría un menor rendimiento (no se puede usar un acelerador de php, recuerden).

Si me preguntan, yo preferiría hacer la aplicación más compatible con Worker (agregar un sistema de caché) que usar el servidor con Prefork, un servidor sencillo puede escalar mucho mejor. Si el contenido es muy dinámico (invalidar el caché resulta muy costoso) enviaría todo el contenido estático a otro servidor (con worker) para que solo atienda el contenido dinámico.

¿Por qué Prefork o Worker, y no FastCGI?

Hablamos de Prefork y de Worker porque en todos los servidores (dedicados) que tengan instalado WHM/Cpanel se puede hacer el cambio entre estos siguiendo los pasos de EasyApache, aún sin CPanel instalado es bastante sencillo hacer el cambio ya que solo significaría modificar la configuración, si se usan módulos compartidos, o recompilar si se manejaron como módulos estáticos. Comodidad más que todo.

Una diferencia importante entre Prefork/Worker y CGI/FastCGI, es que en los primeros PHP corre como un módulo de Apache, mientras que en FastCGI corre como un proceso (o grupo de) separado de Apache. Hechar a andar esta configuración puede ser bastante retador (y que mi experiencia con FastCGI es menor).

Si quieren leer mucho más de como aplicar esto en sus servidores, les recomiendo repasar la documentación oficial de Worker y Prefork, aprender como modificar la configuración de Apache (httpd.conf), saber como cambiar entre ambos modos (recompilar o editar la configuración), y claro experimentar ;)

Javier Aroche Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Rundes
octubre 5, 2009

Tips sonido para video en la Web

sound eqDetrás del funcionamiento de una cámara de video existen procesos técnicos coordinados por las matemáticas, que para un usuario común e incluso muchos profesionales resultan difíciles de entender. Lo negativo de esta relación lejana, son los limites sobre las posibilidades creativas que terminan entorpeciendo el trabajo. La velocidad con que se renueva la tecnología demanda una constante actualización del conocimiento, el simple hecho del cambio en la configuración de un menú, a más de alguno le ha hecho pasar malos momentos.

Estudia el manual

mi eqPara mejorar la calidad del audio que grabamos es indispensable, leer y releer detenidamente el manual de la cámara que usamos. No debemos desaprovechar el potencial de esa inversión y acumular trabajo para la postproducción. La teoría exige de la práctica, tomarse un tiempo para familiarizarse con la herramienta de trabajo, explorar las opciones y grabar bajo diferentes circunstancias, es el primer paso sobre el camino de cualquier aficionado al video.

Algunas de las opciones para la configuración del audio que ofrecen varias cámaras son:

  • Audio Level, Attenuation o Gain. Uno de los problemas más comunes cuando le conectamos un micrófono por medio de un mezclador o un sistema de sonido externo a la cámara es que los niveles de audio sean demasiado saturados y “sucios”, debemos moderar la intensidad de dicha fuente. Algunos modelos permiten una lectura exacta en decibeles, la cantidad recomendada es de -40 dB, a mayor valor debajo de cero será mayor la sensibilidad del micrófono.
  • Wind Filter, Low-Cut o High-Pass. Cuando grabamos una entrevista en exteriores el viento puede arruinar por completo el sonido. Para obtener un audio “limpio” lo que hace esta opción es cortar las frecuencias más bajas del mismo permitiéndole sólo a las altas pasar. Por desgracia el uso de este filtro tiene un efecto dramático en la calidad del audio, haciéndolo muy “delgado y sin vida”, debe usarse sólo en extrema necesidad.
  • Signal Limiter. Todas las cámaras tienen un techo de volumen que debemos vigilar mientras grabamos. Esta es una manera sencilla de mantenerlo bajo control; como resultado obtendremos un audio sin distorsiones y dentro de los rangos adecuados para la edición.
  • Incluso el Bit Rate en que capturan el sonido algunos modelos puede modificarse. Las opciones más simples están entre los 12 bits, graba dos canales de audio por separado en estéreo y, 16 bits, un sólo canal también en estéreo pero con una velocidad de muestreo mayor que brinda mejor calidad.

Optimiza los detalles

earsDe la misma manera que se recomienda observar a través del viewfinder para ordenar la composición de elementos en la imagen, centrar el horizonte, e incluso examinar la temperatura del color, el uso de audífonos es indispensable para analizar detenidamente todas las fuentes de sonido, el ambiente, los ruidos, la intensidad; todo aquello que el público va a escuchar en el producto final y que pueda interferir con la “claridad” y “limpieza” del audio. No es necesario comprarse audífonos de DJ, los del Ipod funcionan bien.

Si estás cansado de escuchar como los niveles que grabaste varían caprichosamente, por aquello de la distancia de la fuente, considera invertir un poco y no abuses del uso del micrófono que trae tu cámara. Este tipo de problema convierte el material en algo mediocre y confuso. Observar el primer plano de un sujeto y escucharlo a kilómetros de distancia o por debajo del ruido de los carros que pasan, son algunos síntomas.

Antes de invertir en audio

shotgunExisten varios tipo de micrófonos, entre los más usados en video están:

  • Cardioide. Se les llama así porque el rango de cobertura que abarcan es intenso al frente y un poco menor a los lados, como la forma de un corazón. Es el más común entre los reporteros y bastante versátil, puede ser ubicado en bases o colgado del techo.
  • Lavalier. Funcionan con baterías y tienen el tamaño de un botón, gracias a su clip pueden ponerse en la solapa de una camisa o el cuello de un suéter. Le permite al sujeto desplazarse libremente y gesticular con las manos. Son bastante útiles para la Web, como recolectan el sonido frontalmente la calidad y el tono de la voz es muy bueno.
  • Shotgun. Extremadamente direccionales, son los menos sensibles a los lados que existen, por lo cual, se utilizan bastante en las producciones de cine y TV. Exige ser dirigido perfectamente a la fuente sonora.

Enriquece el producto final

Un recurso utilizado habitualmente en el Cine es grabar el sonido ambiente de la locación por unos 30 segundos, sirve como base para montar todo el audio de una escena y poder eliminar el ruido no deseado. El único requisito además del silencio, es que, tanto las personas como los objetos que ocupan el espacio durante la grabación deben permanecer en el sitio, de lo contrario la acústica se modifica porque las ondas no van a absorberse y rebotar igual.

Finalmente, los recursos de postproducción como música y efectos de sonido pueden enriquecer el material si son bien mezclados con el fin de realzar, enfatizar y ambientar adecuadamente el concepto. Te recomiendo ampliar la colección de samples y efectos para evitar la monotonía, Freesfx y Soundsnap son una buena opción. ¿Vas a continuar ignorando el audio en tus videos?

Dany Correa Dany Correa para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Rundes
septiembre 30, 2009

La ICANN ya no estará bajo control del gobierno de Estados Unidos

ICANN La ICANN es una organización sin fines de lucro encargada de gestionar diversas tareas en la administración de Internet, y la principal encargada en decidir sobre el futuro de los nombres de dominio de primer nivel (TLD).

Desde su creación, hace 11 años, a un acuerdo con el Gobierno de Estados Unidos, concretamente con el Departamento de Comercio, con el cual podían ejercer cierto control sobre las decisiones de la ICANN. Dicho acuerdo generó muchos años de críticas sobre porque una organización como la ICANN (y a la larga, Internet) estaba ligada a un Gobierno en particular.

A partir del 1 de Octubre dicho acuerdo deja de estar vigente, y la ICANN pasa a ser una entidad global y privada sin fines de lucro. Esto tampoco significa que puedan hacer lo que quieran, pero sin duda quita un peso en las políticas internacionales del manejo y el futuro de Internet.

Para los que estamos en el «nivel más bajo de la cadena» esta noticia no debería representar cambios a corto plazo, si no más bien tener la esperanza que ahora la organización de Internet estará en «manos de todos».

Javier Aroche Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo