daniBlog

Antes de introducirnos de lleno a lo que es CGI, de qué se trata, debemos tener en claro dos conceptos:

• Página estática: una página estática generalmente tendrá como formato HTML, y será aquella que al ser solicitada al servidor web, éste no hace más que entregarla tal y como está, sin modificarle nada. Hoy en día ya casi no se utilizan este tipo de páginas, pero en los comienzos de la W3 era lo único que existia.
• Página dinámica: son armadas en el servidor web. Para ello se utilizan programas y lenguajes específicos, capaces de dar como resultado un HTML que luego se le entregará al cliente que la solicitó.

Con estos conceptos ya conocidos, veamos qué es CGI.

Como se dijo, cuando un servidor recibe una solicitud de una página dinámica, éste
le pasa la bola (con parámetros si así se requiere) a un programa externo. Dicho programa puede estar escrito en cualquier lenguaje (que el servidor soporte); normalmente son lenguajes interpretados (no es necesario compilaciones previas y son mucho más portables).

CGI define un estándar para transferir datos entre el navegador web y un programa externo. Volviendo al ejemplo de solicitud de una página web, CGI debe pasarle los datos al programa de algun modo; existen dos métodos: GET y POST, cada uno tiene sus características, pero aquí no hablaremos de ello. Una vez que pasó los parámetros, se procederá a la ejecución del script.

Como resultado de esta ejecución, se obtiene un objeto MIME, el cual define de que tipo de resultado estamos hablando (generalmente, documentos HTML). Éste objeto es capturado entonces por el servidor web (por la llamada salida estándar), y entregado al que realizó la solicitud.

Todas estas cosas suceden cada vez que uno de nosotros solicita una página web; nada complicado de entender.

Adentrándonos ahora un poco en el proceso de intercambio de información, veamos algunas de las variables de entornos que entran en juego:

• REQUEST_METHOD: puede ser GET o POST.
• QUERY_STRING: sólo tiene valores cuando se utiliza el método GET. Está compuesta por parejas como Variable1=Valor, concatenadas con &. Aquí, algunos caracteres (como acentos) son reemplazados por otros.
• PATH_INFO: el nombre nos dice todo; es la dirección de la solicitud realizada por el cliente (URL).
• SCRIPT_NAME: nombre del script invocado.
• SERVER_PORT: puerto por donde se recibió la petición.
• SERVER_PROTOCOL: nombre y versión del protocolo utilizado (ejemplo: HTTP/1.0 o 1.1).

Ya terminando, existen otras versiones por así llamarlas de CGI. Una de ellas es FastCGI, dónde se busca darle mayor velocidad a la ejecución de scripts creando un único proceso para múltiples peticiones y no uno por cada una como lo hace CGI. Otra, es SCGI, de la que no se mucho asique prefiero sólo nombrarla (si se quiere más información acerca de ésto, recomiendo leer aquí).

Algo que comúnmente hago es comprar libros; libros que sirvan para ir creciendo en lo que me dedico o al menos me apasiona: el desarrollo (diseño y programación) web.

Buscando en internet algunos libros, me encuentro con LibrosWeb.es, un sitio que se trae consigo algunos libros muy interesantes y completos de CSS, XHTML, JavaScript, AJAX y otros temas que -al menos a mí- me resultan más que atractivos.

Lo mejor de todo es que estos libros son 100% gratuitos y los podemos leer (o descargar) sin ningún tipo de restricciones.

Por otro lado tiene un libro llamado Symfony, la guía definitiva. Symfony es un framework para PHP bastante poderoso, y este libro promete darnos todas las herramientas para sacarle el mayor provecho en el menor tiempo posible.

¿De dónde salen estos libros? LibrosWeb.es se compone de libros que utilizan sus autores en los cursos que imparten, y prometen compartir siempre (gratuitamente) todos sus materiales, diciendo: “creemos que la información debe ser libre”.

Enlace: LibrosWeb.es

Este video explica de modo muy sencillo el concepto de RSS, usando ejemplos y diagramas básicos. Creo que cualquiera con algo de conocimientos de internet podría comprenderlo a la perfección.

Está en ingles básico, no creo que tengan problemas en comprenderlo; si los tienen pueden verlo doblado al español o subtitulado.

Sin duda, todo lo relacionado con desarrollos webs es un arte por si mismo. Asimismo, es muy interesante tomar consejos de personas que ya han pasado años en el ámbito, para no perder el tiempo para darnos cuenta por nosotros mismos.

En LiveOnStyle (para los que la visiten: si, el contenido está bajando un poco)

1. ¡Las imagenes también son contenido!
2. ¡No todo es una lista!
3. Mi nombre es h1 h1′ h1”
4. Los hacks no son una solución, son un problema
5. ¡Hola! Me llamo “naranja”
6. ¿A none voy?
7. ¡No soy gordo! ¡Soy funcional!
8. Las tablas no son de satanás, ¡usalas!

Estoy totalmente asombrado por la calidad del artículo publicado en LiveOnStyle (la fuente), aconsejo hecharle un vistazo; está muy completo, con ejemplos, algunas recomendaciones; sin dudas: excelente.

Traducir de inglés a español es, para un blogger, una tarea cotidiana y muy común. Si bien, con una pequeña base de inglés, y alguna herramienta de traducción podemos hacer traducciones presentables, suelen cometerse errores muy básicos.

Veamos a continuación algunos de esos errores que cometemos:

Uso excesivo de la voz pasiva

En inglés es muy común su uso, pero si la traducimos el 100% de las ocasiones nos quedarían muchas oraciones impropias. Se debe evitar la voz pasiva en todos los casos, excepto cuando el sujeto agente no es de importancia o no existe.

Signos de interrogación y exclamación

En inglés, sólo se utilizan signos de cierre para las interrogaciones o exclamaciones; parece tonto decirlo, pero en la práctica muchos olvidan que en español se utilizan tanto en la apertura como el cierre (¿? ¡!).

Uso de las mayúsculas

Hay muchas palabras que en inglés se escriben en mayúsculas, pero en español no (días de la semana, los meses, las estaciones del año, etc.).

Orden de los adjetivos

En la teoría el adjetivo va después del nombre (gato grande), pero a veces puede ser al contrario.

Mas información

La información que les comentaba anteriormente la adquirí en GNU y en Debian. Allí podrán encontrar más información del tema, con ejemplos y muy bien explicadas.

Sin dudas me parece de suma importancia para un blogger tener (y poner en práctica) estos conocimientos a la hora de traducir algún artículo.

Días atrás recibo un llamado telefónico de una conocida empresa de Software, comentándome que estaban interesados en mi perfil. Entre varias preguntas, una de ellas fue si sabía hablar inglés.

Mi respuesta fue que sí; que no lo uso habitualmente pero, en general, leo mucho en inglés y tengo un nivel aceptable. Minuto más tarde, esta persona me hizo algunas preguntas en inglés para ver como andaba, y al parecer mi performance no fue tan mala para el. Personalmente, creo que fue de media para abajo.

Investigando un poco sobre éste tema, me encuentro en RedRRPP con un excelente artículo donde nos listan las preguntas más comunes que se suelen hacer en una entrevista para evualuar nuestra habla inglesa:

• Tell us about yourself: ésta es una pregunta general sobre tu carácter, experiencia, estudios, ambiciones, historia laboral, etc.
• Why should we hire you? El entrevistador está preguntando sobre tus cualidades y puntos fuertes.
• Why did you leave your last job? El entrevistador quiere saber si te despidieron o renunciaste y cuál fué la razón.
• Are you willing to relocate? Esto signigica si estarías dispuesto a vivir en otra ciudad o país.
• Tell me about your scholastic record: Esto se refiere a tus calificaciones y resultados en tus estudios superiores o universitarios.
• Tell me about your extra-curricular activities and interests: Esta pregunta es sobre tus intereses fuera de clases, por ejemplo deportes, pasatiempos, membresías a clubes, etc.
• How would your last boss describe you? Es lo mismo que decir, ¿qué piensa sobre tu desempeño tu último jefe?.
• What salary are you expecting? El entrevistador quiere saber sobre tus solicitudes o requerimientos

Más allá del significado de cada pregunta, lo interesante de todo esto es intentar responder (en inglés, obviamente) a éstas preguntas, para estar más preparado ante una nueva entrevista de este tipo.

Una hoja de estilo en cascada (Cascading Style Sheets, CSS) no es más que un archivo de texto, que contiene código para definir la presentación de un documento en HTML o XML. Las especificaciones para este lenguaje son dadas por el W3C (World Wide Web Consortium), y definen pautas tanto para hacer una página web como para desarrollar un navegador.

Hay personas que al entrar en el mundo del diseño web, o mejor dicho, en el mundo de la maquetación web, recurrer en primera instancia a las tablas. Hacen todo el sitio en unas cuantas tablas, quedando el código totalmente desagradable a la vista y ni hablar de lo poco que le gusta ésto a los motores de búsqueda.

Implementando CSS se logró dejar el código fuente de una página totalmente limpio, con las etiquetas justas para cada parte del contenido.

Yo llevé en alto la bandera de las tablas por mucho tiempo, hasta que un día, mi amigo personal Diego, me comentó así por arriba lo de CSS. En un principio, como siempre me costó el cambio. Pero con el tiempo fui adoptando algo de conocimiento en el tema, y logré hacer algunas maquetaciones bastante lindas a puro CSS.

Es realmente pequeño el mundo del CSS, fácil de aprender y acostumbrarse. Pero, obviamente algún problema debíamos tener, y claro, Microsoft se encargó de ser el responsable del mismo. El problema, es que Internet Explorer no respeta los estándares del consorcio de las tres W. Este problema es lastimosamente solucionado con algunos hacks que debemos agregar a nuestras hojas de estilo, esperemos que en las nuevas versiones de IE esto deje de ser necesario.

Si bien son muy diferentes los fines y funcionalidades que tienen los diferentes sitios webs, todos tienen -o deberían- algo en común; y ésto es una serie de archivos que hacen al sitio un poco mas profesional y ningún desarrollador debería olvidarlos.

Sentidoweb ha traducido un listado publicado en IBM, que nos muetra cuáles son los 10 archivos que todo sitio debería tener:

1. 404.html: para mostrar un mensaje de error que indique que la página visitada no existe, algo que ocurrirá más veces de las que pensamos.
2. about.html: una buena página about ofrece información de forma rápida sobre lo que el sitio hace, indicando por qué ha sido creada, qué deben tener en cuenta los usuarios, algunos enlaces de navegación. Eso sí, ante todo debe ser concisa y no muy extensa, porque entonces la gente no obtiene la información deseada.
3. contact.html: información sobre quién está detrás de la página y un medio para comunicarse con ellos, ya sea por internet u otros medios.
4. copyright.html: protege tus contenidos, ya sea con copyright o Creative Commons, pero que quede claro a quién le pertenece el contenido y que se puede hacer sobre él.
5. index.html: aunque tu página principal no sea esa, es conveniente que este fichero apunte a tu página principal. Si se es generoso también habría que hacerlo con el fichero index.htm e index.cgi.
6. index.rss: para aquellos que quieren leer la información que se ofrece de forma rápida mediante feeds.
7. privacy.html: si vas a obtener información de los usuarios, es necesario indicar qué se va a hacer con esta información y cómo se va a tratar.
8. robots.txt: para que los contenidos que deseas de tu web sean indexados automáticamente por los buscadores.
9. security.html: el uso no es siempre el mismo, pero si existen temas que conciernan a la seguridad es conveniente usarlo, por ejemplo si se usan datos sensibles de los usuarios o si existen procedimientos de seguidad.
10. sitemap: un lugar donde el usuario puede tener un vistazo de la estructura general de la web y así poder moverse con facilidad.

Entonces, si lo que deseamos es desarrollar sitios profesionalmente, no debemos dejar esta lista de lado por nada del mundo; ya que implicaría deficiencias en el desarrollo, y por lo tanto, una mala o mediocre calidad.

Existen en el mundo del HTML, decenas de etiquetas. Si bien la mayoría denota su utilidad, algunas son tan poco comunes que no tenemos ni idea para que sirven, hasta incluso las desconocemos.

HTML Playground es una aplicación web que reúne a todos estos elementos, con la siguiente información para cada una: utilidad, descripción, atributos y ejemplos de aplicación. De este modo, si nos encontramos con una etiqueta que no sabemos para que sirve, no sabemos como usarla, o bien, no sabemos con qué etiqueta hacer tal o cual cosa; HTML Playground nos será de mucha ayuda.

Como ven, su interfaz es muy amigable. Cuenta con 4 paneles: etiquetas, descripción, atributos (se incluyen algunos CSS), y un scritp a modo de ejemplo (nos muetra código + resultado).

Enlace: HTML Playground
Vía: blogandweb

Muchas veces se habla de lo que es WYSIWYG pero pocos son los que saben a que se refiere este término.

La palaba WYSIWYG proviene de las siglas What You See Is What You Get (traducido, “lo que ves es lo que obtienes”), y se refiere justamente a eso; poder ver en tiempo real el resultado de por ejemplo un bloque de código XHTML. En sí es una vista preliminar del código, ya que no hace más que renderizarlo en algún sector de la aplicación.

Ejemplos de editores WYSIWYG son Dreamweaver, Netscape, Mozilla, Writer, FreeRichTextEditor, Front Page, etc. Además existen interesantes editores WYSIWYG web desarrollados en HTML y JavaScript, que trabajan en tiempo real.

WYSIWYM, que si lo miran bien no tiene las mismas letras que WYSIWYG (de quién venimos hablando), es una “alternativa” de WYSIWYG que significa “lo que ves es lo que quieres decir”. No varía en nada, son conceptos equivalentes.

Llevándolo a la práctica, si somos de abrir seguido Dreamweaver, vayamos a la pestaña del código, escribamos algo, y luego vamos a la de diseño. Ahí se renderizó lo escrito en la anterior pestaña. Lo mismo sucede en el mismo Wordpress. Tenemos las 2 solapas, donde podemos ver el fuente y los resultados.