Category: VARIAS


Charla de socialización realizada en la empresa INTCOMEX Américas sobre Cloud Computing con el enfoque Professional Cloud Solution Architect del Cloud Credential Council.  Charla que hace parte del proceso de competencias transversales del 2016 con MinTIC e ICETEX.

El video no esta completo ya que durante la charla se acabó la batería :/ .. de igual forma deseo compartirles parte de la experiencia. Bienvenida la retro alimentación que nos permita fortalecer los conceptos de cloud computing para los retos actuales.


 

 

A veces necesitamos hacer transiciones de un sitio web a otro y tal vez por temas de integración (diferente plataforma) o importancia en el negocio (no se requiere un desarrollo que requiere tiempo para salvaguardar la integridad y privacidad de datos), se puede optar por una clasica opción la cual es pasar los datos por querystring (GET); un caos puntual que me sucedio era pasar datos de un sitio web comercial a un formulario de registro de un aplicación; ya que por un lado los de comercial deseaban saber quien le interesaba un producto y por el lado de la aplicación facilitarle diligenciar datos a un usuario donde no tenga que repetir los mismos datos que habia puesto desde el sitio web comercial.

Primero en el html debe existir un link, en este caso pongo uno oculto:

<a href=»» id=»principalwebsitelink» target=»_blank» style=»display:none;»>Link Falso</a>

Seguido hacemos una funcion JS que procese el formulario, para los datos a leer (en este caso solo input de tipo «text y html»), luego por cada campo se arma query string con los datos «llave»=»valor» y por ultimo con la función:  document.getElementById(‘[id de mi link]’).click(); emula el clic a el vinculo:

function procesarForm(formsend){
var elLength = formsend.elements.length;
var queryString = "";
for (i=0; i<elLength; i++)
{
var type = formsend.elements[i].type;
if (type=="text" || type=="email"){
if(queryString ==""){
queryString = "?";
}else{
queryString = queryString + "&";
}
queryString = queryString + document.forms[4].elements[i].name.toLowerCase() + "="+ document.forms[4].elements[i].value;
}
}
if(queryString!=""){
document.getElementById('principalwebsitelink').click();
}
}

 

Si depronto con la solución de un link falso no les suena, puede usar la opción:

window.open(‘http://www.misitio.com’+queryString);

El problema de ambas soluciones (clic en link falso o window.open) es si el usuario tiene bloqueado los «popups», no lo deja ver, tal vez lo mejor es que la misma pagína navegue:

location = ‘http://www.misitio.com’+queryString;

 

Seguramente nos hemos preguntado esto cuando estamos actualizando nuestras herramientas de desarrollo o producción.. en este caso al SQL server que tenemos instalado.. es sencillo peor me pareció practico por si en algún momento se requiere saber nuestra versión exacta por si tenemos algún problema y estamos en proceso de solución.. bueno en la consola de Queries se ejecuta:

Select @@Version

Y listos! la salida sería la siguiente:

Imagen

Estuve buscando un poco sobre el uso de la nueva versión del API de twitter 1.1, encontré en http://stackoverflow.com una respuesta bastante completa de los señores @lackovic10 and @rivers!. A continuación adjunto el tutorial:

So you want to use the Twitter v1.1 API?

Note: the files for these are on Github.

Version 1.0 will soon be deprecated and unauthorised requests won’t be allowed. So, here’s a post to help you do just that, along with a PHP class to make your life easier.

1. Create a Developer Account: Set yourself up a Developer account on Twitter

You need to visit the official Twitter developer site and register for a developer account. This is a freeand necessary step to make requests for the v1.1 API.

2. Create an Application: Create an Application on the twitter dev site

What? You thought you could make unauthenticated requests? Not with Twitter’s v1.1 API. You need to visit http://dev.twitter.com/apps and click the «Create Application» button.

enter image description here

On this page, fill in whatever details you want. For me, it didn’t matter because I just wanted to make a load of block requests to get rid of spam followers. The point is you are going to get yourself a set of unique keys to use for your application.

So, the point of creating an application is to give yourself (and twitter) a set of keys. These are:

  • The consumer key
  • The consumer secret
  • The access token
  • The access token secret

There’s a little bit of information here on what these tokens for.

3. Create Access Tokens: You’ll need these to make successful requests

OAuth requests a few tokens. So you need to have them generated for you.

enter image description here

Click «create my access token» at the bottom, then once you scroll to the bottom again, you’ll have some newly generated keys. You need to grab the four previously labelled keys from this page for your API calls, so make a note of them somewhere.

4. Change Access Level: You don’t want read-only, do you?

If you want to make any decent use of this API, you’ll need to change your settings to Read & Write if you’re doing anything other than standard data retrieval using GET requests.

enter image description here

Choose the «Settings» tab near the top of the page.

enter image description here

Give your application read / write access, and hit «Update» at the bottom.

You can read more about the applications permission model that Twitter uses here.


5. Write code to access the API: I’ve done most of it for you

I combined the code above, with some modifications and changes, into a PHP class so it’s really simple to make the requests you require.

This uses oAuth and the Twitter v1.1 API, and the class I’ve created which you can find below.

require_once('TwitterAPIExchange.php'); /** Set access tokens here - see: https://dev.twitter.com/apps/ **/ $settings = array( 'oauth_access_token' => "YOUR_OAUTH_ACCESS_TOKEN", 'oauth_access_token_secret' => "YOUR_OAUTH_ACCESS_TOKEN_SECRET", 'consumer_key' => "YOUR_CONSUMER_KEY", 'consumer_secret' => "YOUR_CONSUMER_SECRET" );

Make sure you put the keys you got from your application above in their respective spaces.

Next you need to choose a URL you want to make a request to. Twitter has their API documentation to help you choose which URL and also the request type (POST or GET).

/** URL for REST request, see: https://dev.twitter.com/docs/api/1.1/ **/ $url = 'https://api.twitter.com/1.1/blocks/create.json'; $requestMethod = 'POST';

In the docs, each url states what you can pass to it. If we’re using the «blocks» URL like the one above, I can pass the following POST parameters:

/** POST fields required by the URL above. See relevant docs as above **/ $postfields = array( 'screen_name' => 'usernameToBlock', 'skip_status' => '1' );

Now that you’ve set up what you want to do with the API, it’s time to make the actual request.

/** Perform the request and echo the response **/ $twitter = new TwitterAPIExchange($settings); echo $twitter->buildOauth($url, $requestMethod) ->setPostfields($postfields) ->performRequest();

And for a POST request, that’s it!

For a GET request, it’s a little different. Here’s an example:

/** Note: Set the GET field BEFORE calling buildOauth(); **/ $url = 'https://api.twitter.com/1.1/followers/ids.json'; $getfield = '?username=J7mbo'; $requestMethod = 'GET'; $twitter = new TwitterAPIExchange($settings); echo $twitter->setGetfield($getfield) ->buildOauth($url, $requestMethod) ->performRequest();


Final Code Example: For a simple GET request for a list of my followers.

$url = 'https://api.twitter.com/1.1/followers/list.json'; $getfield = '?username=J7mbo&skip_status=1'; $requestMethod = 'GET'; $twitter = new TwitterAPIExchange($settings); echo $twitter->setGetfield($getfield) ->buildOauth($url, $requestMethod) ->performRequest();

I’ve put these files on Github with credit to @lackovic10 and @rivers! I hope someone finds it useful, I know I did (I used it for bulk blocking in a loop).

If anyone finds it useful – an upvote / comment on Github would go a long way. Cheers!

Hace un tiempo tuve un incoveniente con una validación de un check con jQuery donde usaba attr() para activar si un valor venia en true o removía el valor si venia en false, esto en HTML lo hacia, pero en el DOM no se veía reflejadoo el chulo de activación, revisando encontré lo siguiente en desarrolloweb.com, que me sirvió bastante:

El método prop() disponible desde jQuery 1.6 sirve para acceder y modificar propiedades de elementos y attr() para atributos. Veamos las diferencias.
Por Miguel Angel Alvarez

Antes de jQuery 1.6 teníamos un único método para el acceso y modificación de todos los atributos de los elementos de la página por medio de jQuery, llamado attr(). A partir de jQuery 1.6 tenemos dos métodos que vamos a tratar de distinguir en este artículo. Por un lado tenemos prop() y por otro lado tenemos attr().

El método attr() sirve para acceder a atributos de la página y ya lo explicamos en un par de artículos del Manual de jQuery. En el texto Acceder y modificar atributos HTML desde jQuery repasamos los usos generales de este método y en el artículo Método attr() de jQuery, otros usos y removeAttr() vimos otros usos y el método «hermano» removeAttr().

Nota:

Nota: Además, tenemos el método val() que sirve específicamente para acceder y modificar el atributo value. En principio ese método val() es el que deberíamos usar siempre que queremos ver el valor que haya cargado en «value», o modificarlo.
Ahora en el API de jQuery tenemos un nuevo integrante del ecosistéma de métodos para trabajo con los atributos de la página, llamado prop(), que sirve para acceder y modificar propiedades.

Qué son atributos y qué son propiedades

En la documentación de jQuery tienes una explicación sobre todo esto, aunque a veces puede resultar algo confusa, porque habitualmente utilizamos el término ?attribute? y ?property? (atributo y propiedad) para la misma idea, es decir, atributos de las etiquetas HTML. Al menos en los manuales de DesarrolloWeb .com utilizamos esos dos términos indistintamente como sinónimos cuando nos referimos al HTML e incluso muchas veces al hablar de programación.
Pues bien, para clarificar esto, tengamos en cuenta a qué nos estamos refiriendo en este caso como atributo y a qué nos referimos con propiedad:

Atributo: cualquier cosa que tengamos en una etiqueta HTML para personalizarla.

<a style=»color: red»>…</a>

En ese caso «style» es un atributo de la etiqueta HTML.

Propiedad: cualquier cosa a la que podamos acceder desde una propiedad de un objeto nativo Javascript.

document.forms[0].elements[0].checked

En el ejemplo, tenemos varias propiedades en funcionamiento, pero veamos el «checked» final, que es una propiedad de un elemento de formulario. A esa propiedad accedemos desde el DOM de Javascript.

Por lo tanto, para concretar todavía más y ver lo confuso que puede llegar a ser, esa propiedad nativa Javascript «checked» sería diferente de este atributo «checked»:

<input type=»checkbox» checked=»checked»>

En ese caso «checked» es el atributo de HTML.

Uso del método prop() en jQuery

El método prop() sirve para modificar propiedades nativas de Javascript de los elementos de una página. Como otros métodos de jQuery el uso es ligeramente distinto dependiendo del juego de parámetros que le enviemos.
En principio, enviando un único parámetro nos sirve para acceder al valor de una propiedad, aquella que indiquemos en el parámetro. La otra opción nos sirve para modificar una propiedad y para ello debemos indicar dos parámetros, el primero sería la propiedad a modificar y el segundo el valor que queremos introducir.

$(elemento).prop(«checked»);

Esto nos devolvería el valor de la propiedad Javascript «checked», que seguramente sepamos, es un booleano que indica con true o false si un campo checkbox está o no marcado.

Si quisiéramos modificar el estado del checkbox, hacemos lo siguiente:

$(elemento).prop(«checked», true);

Esto haría que el checkbox estuviera marcado como confirmado.

Cuándo utilizar prop() y cuándo usar attr()

Antes de jQuery 1.6 solo existía attr(), por lo que no existía una duda concreta sobre cuándo usar uno o el otro. El problema es que attr() tenía algunos problemas/bugs y se hacía difícil su mantenimiento. Especialmente daban problemas con attr() muchas de las propiedades de objetos Javascript que eran boleanas, como el mencionado checked u otros como disabled o readonly.
En la actualidad tenemos que usar los métodos con cuidado porque pueden producirse casos confusos. ¿Qué hacemos campoCheck.attr(«checked») o mejor campoCheck.prop(«checked»)?

Para evitar esos casos, attr() solo te dará el valor de atributos HTML y prop() te dará el valor de las propiedades del DOM de Javascript para un elemento dado. En versiones más nuevas de jQuery todas las propiedades boleanas de los objetos del DOM se tienen que acceder por prop() y se han desactivado en attr(). Por ejemplo campoCheck.attr(«checked») se ha desactivado para que no te devuelva ningún valor y siempre deberías acceder por campoCheck.prop(«checked»).

Para ver algunos ejemplos.

Atributos que se modifican con attr(): class, id, href, label, src, title…
Propiedades que se modifican con prop(): autofocus, checked, async, multiple, readOnly…
Espero que esto resuelva la duda que muchos de nosotros hemos tenido cuando intentamos acceder a propiedades y valores de atributos.

 

 

 

Este articulo que les presento a continuación lo encontré en el sitio web:  http://www.itworld.com/development/303295/ajax-requests-not-executing-or-updating-internet-explorer-solution, es bastante bueno si han tenido este problema usando algun tipo de MVC basado en javascript al consumir un servicio web; esta es la traducción con Google translate, peor pueden encontrar el original en link de arriba:

By 

Con las bondades de AJAX – no se espera que , cuando de repente te das cuenta de que algunas de las llamadas AJAX no están regresando datos actuales de Internet Explorer. Si eres como yo , esto por lo general cae en la cuenta que al final de un proyecto, mientras que se está probando , encunetras error en IE y no se uso en base diaria de desarrollo?

Esto puede ser un problema frustrante para depurar. Es posible sin embargo que es un problema muy común . De hecho, surgió en mi oficina tres veces en las últimas 2 semanas!

Los síntomas
La primera vez que se intenta hacer el llamado funciona; a medida que se modifican, se da cuenta de que todavía estás viendo resultados antiguos pero todo parece funcionar correctamente en otros navegadores

Usted está lentamente se esta volviendo loco

depuración
Cuando un asunto de esta naturaleza aparece por lo general comienzan la investigación mediante el uso de Firebug en Firefox. Con esta herramienta invaluable reviso para asegurarse que las peticiones se realizan correctamente, comprobar que no existen problemas de respuesta , etc .

Con Internet Explorer, las herramientas de desarrollo son tan pobres que apenas se puede depurar problemas de CSS , por no hablar de los problemas de javascript . Es entonces cuando me dirijo a Fiddler , el fantástico inspector de tráfico http . Cuando el fuego hasta Fiddler y empezar a poner algunas de las solicitudes mediante el uso de un navegador IE no verá la solicitud se envían y la respuesta vuelve sin ningún problema. Al hacer lo mismo con Internet Explorer te darás cuenta de que algo extraño sucede, o más bien , no sucede. Las solicitudes que no se están haciendo nada , están siendo totalmente ignorados por Internet Explorer.

La cuestión
Lo que pasa es que es muy probable que hacer una petición GET a un servicio web de su llamada AJAX. Internet Explorer, en su sabiduría, hace un caché automático de las respuestas de las solicitudes GET , mientras que otros navegadores le permitirá decidir si desea almacenar en caché el resultado o no. Una vez que IE ha realizado con éxito una petición GET, hace caché  hasta que expire en ese objeto .

La Solución
Afortunadamente, la fijación de la cuestión es más fácil que lo identifique . Hay varias maneras de evitar peticiones AJAX para el cache .

PUBLICAR
Una opción es utilizar simplemente las peticiones POST en lugar de GET de la aplicación. Por lo general es un pequeño cambio para cambiar de GET a POST en el cliente y en el servidor .

Buster caché
Otra opción es utilizar un parámetro » Buster Caché» en su solicitud . Una caché -buster es un parámetro dinámico que anexar a la solicitud que hace cada solicitud única , por lo general un número al azar o las garrapatas de fecha / hora actuales. Esto no impide que el navegador almacene en caché la respuesta sin embargo, sólo le impide volver a utilizar el valor almacenado en caché . Por ejemplo :

var myRequestURL = ‘/ get / algunaFuncion destructor = ‘ + new Date ( ) getTime (). ;

encabezados de respuesta
También puede evitar que el almacenamiento en caché mediante el envío de encabezados adicionales junto con su respuesta. Al especificar el encabezado » Cache- Control» con un valor de » no-cache , no-store » y devolverla con la respuesta del servicio web puede indicarle al navegador que no almacenar en caché el resultado. Por ejemplo, en C #:

HttpContext.Current.Response.AddHeader ( » Cache- Control» , » no-cache , no-store «);

jQuery
Por último , si usted está usando jQuery, se puede especificar que no desea almacenar en caché la respuesta de sus peticiones AJAX ya sea a través del tablero con el $ . Método ajaxSetup () o en una base por solicitud .

/ Cache / Disbable para todas las peticiones AJAX jQuery
. $ ajaxSetup ( {cache : true } ) ;

– OR-

/ / Desactivar la caché para sólo esta solicitud
$ . ajax ({
cache : false,
/ / otras opciones …
} ) ;

Comentarios finales

Hay razones por las que es posible que desee almacenar en caché la respuesta para las solicitudes GET . Por ejemplo , una aplicación de alto tráfico que recibe su nombre del perfil en cada carga de la página . Esa información no cambia muy a menudo lo que no hay necesidad de hacer una nueva solicitud cada vez. También hay algunos que van a decir que no se debe utilizar una solicitud POST para cada llamada AJAX como he sugerido . Como siempre, sus necesidades de aplicación específicas determinarán la forma de proceder y una solución no sirve para todos .

Estuve buscando una librería que permitiera hacer zoom a un contenido de un div y que este a su vez permitirá tomar todos sus elementos hijos HTML y los re dimensionara manteniendo las posiciones absolutas que se le fueron asignadas por temas de presentación.. encontre bastante para imagenes muy especiales para tiendas de mercado o galerias de arte.. pero solo eran para objetos img; por otro lado enocntre la función animate de jquery, que le podemos decir:

$(«#midiv»).animate({ ‘zoom’: scale }, 1) ;

Donde scale es la escala que deseamos del original, la original es 1, entonces si queremos el doble es 2, el tripple 3, etc…

Es bastante util pero la mala noticia es que solo sirve Chrome ya que lo que hace es añadir un tag: zoom al estilo del div padre; cosa que no reconoce aun mozilla ni IE.

Entonces el paso siguiente fue hallar que tags CSS  permitían esta actividad nativa mente, aquí fue donde halle en este link la respuesta de Matt en la que dice que los tags son:

ms-transform: scale(your value);
-moz-transform: scale(your value);
-o-transform: scale(your value);
-webkit-transform: scale(your value);
transform: scale(your value);

Ahora aca es donde entra JQuery, lo unico que se debe hacer es un metodo que reciba ese valor de la escala y lo actualice dada una acción, por ejemplo:

function updateSizeOfCategories(difZoom){

//aqui se realiza un calculo que sea mayor a la unidad sobre un valor porcentual
scale=1+(difZoom/100);
$(«#midiv»).css(‘-moz-transform’,’scale(‘+scale+’)’);
$(«#midiv»).css(‘-ms-transform’,’scale(‘+scale+’)’);
$(«#midiv»).css(‘-moz-transform’,’scale(‘+scale+’)’);
$(«#midiv»).css(‘-o-transform’,’scale(‘+scale+’)’);
$(«#midiv»).css(‘-webkit-transform’,’scale(‘+scale+’)’);
$(«#midiv»).css(‘transform’,’scale(‘+scale+’)’);
}

Y listos, esta acción se llama dada una acción (click, scroll, controles externos,slider, etc.) que necesitamos y el hace el zoom desde el div padre a todos sus elementos hijos; recomendable que el div padre del que le estamos haciendo zoom tenga un overlay: hidden, para no generar scroll y tal vez usar un drag para navegar.

Aveces necesitamos obtener datos sencillos de una URL externa frente actividades en facebok como por ejemplo cuantas veces ha sido compartido, No. likes, No. compartidos pero no necesitamos hacer todo un App en facebook para tener estos datos.

Usando el API de facebook por XML nos retorna esta información dada una URL:

http://api.facebook.com/restserver.php?method=links.getStats&urls=[URL a consultar]

Ya dependiendo de cada plataforma hacen el proceso de lectura y procesamiento, por ejemplo para PHP vi una muy interesante que pueden consultar la fuente original en allfacebook.com es la siguiente:

<?php
$source_url = «https://xdeamx.wordpress.com»; //This could be anything URL source including stripslashes($_POST[‘url’])
 
$url = «http://api.facebook.com/restserver.php?method=links.getStats&urls=».urlencode($source_url);
$xml = file_get_contents($url);
$xml = simplexml_load_string($xml);
$shares = $xml->link_stat->share_count;
$likes = $xml->link_stat->like_count;
$comments = $xml->link_stat->comment_count;
$total = $xml->link_stat->total_count;
$max = max($shares,$likes,$comments);
?>
O a través de un navegador como Chrome pueden ver la estructura de datos que retorna probando por ejemplo con la URL de su sitio.

Revisando alguna documentación recomiendan que los sitios web si se ingresa: tusitio.com, debe redirigir a http://www.tusitio.com, ya que de lo contrario para los buscadores da la impresión que son dos sitios diferentes.

Sin entrar del detalle de cuando realmente se requieren prefijos para los sitios web como: deportes.tusitio.com ó cocina.tusitio.com.. vamos abordar solo el tema de redireccionamiento de un «non www» a http://www.tusitio.com; para esto se debe editar el archivo .htacces de la raíz de tu sitio principal (si usas un CMS para soportar tu sitio generalmente lo trae por defecto activado para URL´s amigables, en caso de Joomla 1.5! viene como htaccess.txt, lo que se hace es renombrarlo a .htaccess y se activa en backend), en la edición de este archivo se agrega las siguientes lineas (o verificar si ya estan en el archivo activas y solo agregar las ultimas dos):

»

Options +FollowSymLinks

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www.

RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

»

Revisemos en la ultima linea el lugar que dice: %{REQUEST_URI}, aquí le decimos que el redirect que elabore lo haga para todos los contenidos que estén asocisiados a ese dominio de nuetro host. Lo comento ya que por ejemplo haciendo pruebas de otras fuentes el ejemplo salia de la siguiente forma:

» RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1  [R=301,L] »

Observemos que el  %{REQUEST_URI} se cambia por /$1, esta regla también funciona correctamente, pero si por ejemplo el usuario ingreso: http://tusitio.com/galeria.html lo re-direcciona a  http://www.tusitio.com/, es decir lo envía a la raíz del sitio .. pero creo que nos es mas funcional que le agregue el: www y le mantenga la URL que desea el usuario, por ejemplo: http://tusitio.com/galeria.html lo re-direcciona a  http://www.tusitio.com/galeria.html.

Siguiendo lso temas de fase de analisis..es muy importante saber que meotdología nos conviene más implementar en nuestro poryecto de software; en el presente post adjunto una evaluación muy personal sobre: RUP. XP y MSF, esta evaluación ha sido desarrollada tomando algunas fuentes de la web, testimonios y opiniones personales.

Adjunto el archivo de la guia 2: aqui