martes, 30 de julio de 2013

Blogger: fanbox para twitter, ¿solucionado?

Si has leído nuestro artículo Seguidores en Facebook, Twitter, Google+ y LinkedIn o Blogger: plugin de seguidores para twitter y has probado el fanbox para twitter posiblemente verás que no funciona.

Desde hace un tiempo el fanbox de twitter desarrollado por Mopz ha dejado de funcionar, lo mismo sucede con el de MatiasMX que os indicaba en el artículo Blogger: plugin de seguidores para twitter. Te presento una alternativa basada en este último:

<div id="twitter-box"></div>
<script>
var tw_user = 'areaTicnet';
var tw_width = 300;
var tw_height = 260;
var no_face = 10;
var tw_color='light';
(function() {
var tw_box = document.createElement('script'); tw_box.type = 'text/javascript'; tw_box.async = true;
tw_box.src = 'http://areaticnet.260mb.net/scripts/twitter.js';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(tw_box);
})();
</script>

Donde:

  • En la variable "tw_user" indicaremos nuestra cuenta de twitter; cuidado con es key sensitive (tiene en cuenta mayúsculas / minúsculas.

  • En la variable "tw_width" indicaremos el ancho del fanbox de twitter.

  • En la variable "tw_height" indicaremos el alto del fanbox de twitter.

  • En la variable "no_face" indicaremos el número de caras que queremos aparezcan en el fanbox de twitter.
  • En la variable "tw_color" indicaremos el color del que queremos que aparezca fanbox de twitter; las opciones son light/dark.

Y obtendremos el siguiente resultado:


Y hasta aquí el artículo de hoy, espero que os sirva para solucionar el problema con el plugin de seguidores (fanbox) de twitter de Mopz y MatiasMX. Recordad también que dentro de areaTIC podéis encontrar otros artículos interesantes, no dudéis en consultar nuestro archivo, también podéis seguirnos por RSS o las principales redes sociales (twitter, facebook, linkedin...) 


martes, 23 de julio de 2013

HTTP, C#: URI no válido: la cadena URI es demasiado larga

El error se produce al crear una nueva instancia de

System.Net.Http.FormUrlEncodedContent

pasándole una lista de clave-valor cuando superamos un límite de caracteres… (es fácil de superar si enviamos binarios codificados en base 64). Cabe decir que la petición no llega ni a salir, al intentar generar una instancia de esta clase de .NET ya genera una excepción quejándose que la URI es demasiado larga:

URI no válido: la cadena URI es demasiado larga

->

Invalid URI: The Uri string is too long



Al crear un cliente

REST

para peticiones con verbo POST esta es la codificación por defecto que se suele usar para enviar parámetros en el request al servidor. El error se produce al superar un límite de caracteres en la URL, tendríamos que mirar de cambiar el tipo de codificación en el que enviamos el contenido del request (siempre que el servidor entienda igual el mensaje con otro tipo de codificación) o bien buscar alguna trampa para poder saltarnos la limitación de caracteres con la que trabaja esta clase.

En mi caso el servidor de destino de la petición es un Apache y testeando con un cliente

REST

no .NET me deja enviar la petición con binarios pesados y el servidor la acepta sin problemas. Me gustaría remarcar que la solución más óptima a nivel de performance es recurrir a MultiPartFormDataContent como codificación si vamos a enviar ficheros en el request. Aún así si necesitáis forzar un envío desde .NET con binarios codificado como

formUrlEncoded

también es posible a continuación os paso una altenativa en c#.

Yo estoy usando el cliente

REST

genérico que desarrollé para areaTIC, a medida que lo voy usando se han ido añadiendo sobrecargas para contemplar otros tipos de encoding y para enviar en el POST objetos complejos con sub-listas, ya publicaré un post con el código más adelante cuando lo tenga 100 % pulido.

En el artículo de hace unos meses planteaba un método POST que usa

FormUrlEncodedContent

por defecto siempre para enviar el request y es aquí donde se origina la expcepción:
List<KeyValuePair<string, string>> oListTest = new AreaTICJavaScriptSerializer().GetKeyValuePair(pValue, serialiceListAsParamArray);
FormUrlEncodedContent contentencoded = new FormUrlEncodedContent(oListTest);
Os paso ahora el código alternativo para enviar el contenido en formato

FormUrlEncodedContent

evitando usar la instancia que genera la excepción:
List<KeyValuePair<string, string>> oListTest = new AreaTICJavaScriptSerializer().GetKeyValuePair(pValue, serialiceListAsParamArray);
string pURLEncodedContent = "";

foreach (KeyValuePair<string, string> item in oListTest)
   pURLEncodedContent += string.Format("{0}={1}&", System.Web.HttpUtility.UrlEncode(item.Key), System.Web.HttpUtility.UrlEncode(item.Value));

pURLEncodedContent = pURLEncodedContent.Substring(0, pURLEncodedContent.Length - 1);

ByteArrayContent content = new ByteArrayContent(Generic.Utiles.UtilesFichero.ConvertStringToByteArray(pURLEncodedContent));
content.Headers.ContentType = new MediaTypeHeaderValue("application/x-www-form-urlencoded");
HttpResponseMessage response = _Client.PostAsync(_ServiceName, content).Result;
Os paso también el código de las funciones ConvertStringToByteArray que es una librería propia (no tiene ningún misterio pero os evito buscar por internet).
public static byte[] ConvertStringToByteArray(string psCad)
{
    Encoding oEnc = Encoding.GetEncoding("ISO-8859-15");
    return oEnc.GetBytes(psCad);
}
El “truco” está en generar un string codificado para URL, convertirlo a un array de Bytes, modificar el Header contentType y enviar al PostAsync una instancia de ByteArrayContent. Como en PostAsync se espera alguna clase derivada de HttpContent y ambas tanto

FormUrlEncodedContent

como ByteArrayContent derivan de HttpContent deja enviar y en mi caso el servidor la procesa ok.

Espero os sea de ayuda, como siempre vuestras dudas, comentarios y/o aportaciones son bienvenidas… no os cortéis un pelo. Por otro lado recordar que podéis seguir

areaTIC

en las principales redes sociales.

martes, 9 de julio de 2013

Blogger: plugin de seguidores para twitter

Si has leído nuestro artículo

Seguidores en Facebook, Twitter, Google+ y LinkedIn

y probado el

plugin de seguidores (fanbox) para twitter

verás que no funciona.

Desde hace un tiempo el

plugin de seguidores de twitter

desarrollado por Mopz ha dejado de funcionar así que necesitamos una alternativa. En su lugar puedes utilizar el

plugin de seguidores de twitter

de MatiasMX, el código será similar a:

<div id="twitter-box"></div>
<script>
var tw_user = 'areaTicnet';
var tw_width = 300;
var tw_height = 260;
var no_face = 10;
(function() {
var tw_box = document.createElement('script'); tw_box.type = 'text/javascript'; tw_box.async = true;
tw_box.src = '//www.musicpaax.com/twitter/tw.js';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(tw_box);
})();
</script>

Donde:

  • En la variable "tw_user" indicaremos nuestra cuenta de

    twitter

    ; cuidado con es key sensitive (tiene en cuenta mayúsculas / minúsculas.

  • En la variable "tw_width" indicaremos el ancho del

    plugin de seguidores

    .

  • En la variable "tw_height" indicaremos el alto del

    plugin de seguidores

    .

  • En la variable "no_face" indicaremos el número de caras que queremos aparezcan en el

    plugin de seguidores

    .

Y obtendremos el siguiente resultado:


Y hasta aquí el artículo de hoy, espero que os sirva para solucionar el problema con el

plugin de seguidores de twitter

de Mopz. Recordad también que dentro de

areaTIC

podéis encontrar otros artículos interesantes, no dudéis en consultar nuestro archivo, también podéis seguirnos por RSS o las principales redes sociales (twitter, facebook, linkedin...) 


martes, 2 de julio de 2013

HTML5, SEO - ¿Es recomendable usar los nuevos tags de contenido desde el punto de vista SEO?

En el articulo de hoy lanzaremos el debate sobre si es recomendable o no usar los nuevos tags de contenido que incorpora

HTML5

de cara a posicionar mejor nuestras páginas en buscadores (

SEO

).

Como sabéis SEO es un conjunto de técnicas que influyen en los motores de búsqueda a la hora de posicionar nuestra página entre los resultados.

SEO

es muy extenso y poca gente conoce realmente el algoritmo exacto que aplica para valorar mejor o peor una página cada buscador. Una parte está basada en como estructuremos el contenido

HTML

de nuestra página lo que también es conocido como

SEO

in Page.

HTML5

incluye nuevos tags de contenido como Section, Article, Figure (FigCaption), Footer, Header, Aside, Nav.

En realidad, enfocado desde el punto de vista práctico todos estos tags no aportan nada nuevo respecto lo que ya podíamos hacer a afectos de maquetación usando el tag Div, BlockQuote y PullQuote.

Antes de seguir hagamos un inciso rápido sobre como usar los tags (sin profundizar demasiado).
  • Nav: Permite agrupar un conjunto de enlaces a otras páginas. En resumen facilita la navegación.
  • Section: Permite estructurar nuestra página en secciones, por ejemplo imaginemos una página donde tenemos varias pestañas. Gracias a este tipo de maquetación podríamos destacar contenido y posicionar palabras clave por secciones a las que podemos asociar cabecera y pie.
  • Article: Imaginemos un blog o una revista on-line. Este tag permitiría diferenciar cada entrada o notícia y asociarle cabecera y pie.
  • Header: Puede aparecer varias veces en una misma página, permite destacar contenido de cabecera dentro de un artículo, sección o página.
  • Footer: Puede aparecer varias veces en una misma página, permite clasificar contenido al final del artículo, sección o página.
  • Aside: Se recomienda su uso para un bloque con contenido adicional al bloque principal que lo contiene. Es decir dentro de una página podría ser el lateral donde aparecen anuncios o contenido extra.

La tendencia de los motores de búsqueda es valorar mejor aquellas webs que aplican bien el estándar donde se usan elementos descriptivos

HTML

que permiten clasificar el contenido a sus "robots". Estos nuevos tags permiten al desarrollador/maquetador organizar mejor su contenido y facilitar el trabajo al "robot" por lo que la lógica lleva a pensar que es recomendable usarlos.

Leyendo por internet veo posturas muy críticas en blogs donde recomiendan NO usar estos tags por diversos motivos. Hay quien decide no usarlo porque considera que no le aporta ningún beneficio SEO respecto a maquetar con divs y no quiere complicarse la vida. Hay motivos que aún tienen algo más de peso como que versiones antiguas de navegadores no soportan estos tags y hay incluso quien dice que los motores de búsqueda penalizan este tipo de maquetación cosa que dudo realmente.

Desde mi punto de vista recomendaría este tipo de maquetación, por el argumento que exponía anteriormente sobre facilitar el trabajo a los "robots" y además porque a mi parecer si más de un desarrollador ha de tocar una misma página en determinados momentos con estos tags tienes una visión más clara sobre el código

HTML

que si todo esta maquetado con Div.

En definitiva SEO cambia a medida que los motores de búsqueda van afinando sus técnicas de rastreo por lo si quieres dedicarte a esto no tienes otra que estar al día e ir incorporando mejoras en las páginas a medida que evolucionan los buscadores y el lenguaje

HTML

.

Hasta aquí el artículo, espero resulte interesante. Recordar como siempre que podéis aportar vuestra opinión o valoraciones vía comentarios ya sea en el post o en la página de

AreaTIC

en las principales redes sociales.