jueves, 26 de diciembre de 2013

SharePoint Online: Como añadir sugerencias de consulta al motor de búsquedas



En SharePoint Online tenemos la posibilidad de añadir sugerencias de consulta al motor de búsquedas al igual que podemos añadirlas en la Administración Central de SharePoint 2013:
  • Utilizando el bloc de notas, creamos un documento de texto en el que vamos a incluir las sugerencias de consultas a añadir.
  • Añadimos el siguiente contenido al archivo de texto y lo guardamos con el nombre QuerySuggestions_Informe. De esta forma, añadiremos sugerencias de consulta para la palabra Informe.
  • Es importante que al guardar el archivo de texto especifiquemos como tipo de codificación UTF-8.
imageimage
  • Navegamos a la Administración de SharePoint Online para poder importar las sugerencias de consultas en la configuración de las búsquedas. Hacemos clic en “Sugerencias de consulta”.
  • En la página que se abre, seleccionamos como idioma Español (España) y hacemos clic en el enlace “Importar desde archivo de texto” y cargamos el archivo de sugerencia de consultas creado.
imageimage
  • En la página que se abre, seleccionamos el archivo QuerySuggestions_Informe.txt y hacemos clic en “Aceptar”.
  • Finalmente, realizamos una búsqueda y comprobamos que las sugerencias están operativas.
  • De nuevo en la página de configuración de sugerencia de consultas hacemos clic en “Guardar configuración” y tendremos disponibles las sugerencias de consultas una vez que se ejecute el correspondiente Timer Job que en instalaciones On-Premise tiene una frecuencia de ejecución diaria.

viernes, 20 de diciembre de 2013

Cómo comprobar si un archivo es una imagen en PHP



Nuestro post de hoy lo dedicaremos a dedicar unas palabras al lenguaje de programación web PHP, muy usado actualmente en todo tipo de servidores y con un gran soporte por parte de comunidad global de desarrolladores, esta manera que expongo aqui la he usado varias veces en mis proyectos de desarrollo y funciona bastante bien, se admiten sugerencias, si conoces alguna forma mejor exponlo abiertamente, vamos con el código.

function esImagen($path)
    {
                $imageSizeArray = getimagesize($path);
                $imageTypeArray = $imageSizeArray[2];
                return (bool)(in_array($imageTypeArray , array(IMAGETYPE_GIF , IMAGETYPE_JPEG ,IMAGETYPE_PNG , IMAGETYPE_BMP)));

    }

Para usar esta funcion simpelmente escribimos:

 if(esImagen('path/a/tu/imagen.jpg'))
{
 //hago mi trabajo
}
else
{
            //hago lo que quiera aqui
}

jueves, 19 de diciembre de 2013

Emuladores de Android



No siempre tendremos un dispositivo Android a mano. Incluso teniéndolo, necesitamos verificar de alguna manera que nuestra aplicación funcionará bien en tantos modelos Android diferentes como sea posible. Aquí entran en escena los emuladores. Con ellos podremos evitar caer en algunos errores frecuentes en el desarrollo. Pero, como veremos más adelante, para tener una mayor seguridad lo mejor es echar mano de dispositivos reales.
Creación y gestión de emuladores
Accederemos al gestor de emuladores (Android Virtual Device Manager) a través de este botón:
Veremos una ventana donde podremos acceder a dos listas: la de los dispositivos virtuales que tenemos creados, y de las definiciones de dispositivos. Para crear un dispositivo virtual (AVD) nuevo, pulsaremos en New, y lo rellenaremos de la siguiente manera:
Con esto, habremos creado nuestro primer emulador. Cuando necesitemos editar nuestros AVDs, lo seleccionaremos en la lista y pulsaremos “Edit”, para volver a ver esta pantalla. En ella podemos editar detalles como la cámara frontal, la trasera, las opciones de memoria y almacenamiento, etc. Pero para los primeros desarrollos, estas opciones las dejaremos sin tocar, nos interesan solamente “Device” y “Target”. Con “Device” elegiremos un dispositivo de entre las definiciones que tenemos. Todos los modelos de uso frecuente ya están predefinidos, por lo que en principio no necesitaremos crear nuevas definiciones. Con “Target” podremos decidir la versión del sistema operativo que tendrá nuestro emulador. A día de hoy el valor más adecuado es el API 16 (v 4.1.2), que cubre la mayoría de los terminales. Si necesitamos crear una nueva definición de dispositivo, lo haremos a través de esta pantalla:
Normalmente no lo necesitaremos, ya que las definiciones predefinidas incluyen la mayoría de los modelos que existen. Si necesitamos crear un nuevo modelo de dispositivo -normalmente será porque no tenemos ninguno con una determinada resolución de pantalla-, indicaremos su nombre, tamaño de pantalla en pulgadas, y resolución en píxeles. Los valores “size”, “screen ratio”, y “density” se autocalcularán y lo más probable es que no necesitemos tocarlos. También podemos decidir qué elementos hardware queremos añadir, como el acelerómetro o el GPS, el teclado físico, etc.
Uso de emuladores
Si aún estamos empezando a manejar Android, veremos que al ejecutar nuestro proyecto se elige automáticamente el dispositivo (o AVD) en el que se ejecuta nuestra aplicación. Si necesitamos que se ejecute en un dispositivo (real o emulado) concreto, tendremos que cambiar un ajuste primero. Dentro de Run → Run Configurations, elegiremos la configuración de nuestro proyecto, y en la pestaña Target activaremos elegir siempre el dispositivo:
Con esto, ya estaremos preparados para usar tantos emuladores como necesitemos o queramos.
Ventajas y limitaciones de los emuladores
Un emulador es una aproximación no del todo perfecta hacia un dispositivo real. Hay utilidades que no tendremos disponibles, normalmente relacionadas con características avanzadas. Por ejemplo, no se puede emular Bluetooth, ni Google Maps. Si se diese el caso de estar diseñando juegos que utilicen OpenGL, el emulador nos servirá más bien poco. Entonces, ¿por qué usar emuladores si tienen limitaciones y si tenemos un dispositivo real? Hay una razón muy importante, y es lidiar con los diferentes tamaños de pantalla que existen.
Si sólo trabajamos con el dispositivo que tenemos, podemos encontrarnos con la desagradable sorpresa de que para los demás tamaños no hemos diseñado bien las pantallas. Una de las formas que hay de evitar esto es trabajar siempre con proporciones y medidas relativas y escalables, nunca absolutas. Con el emulador tendremos más fácil el poder comprobar otros tamaños de pantalla sin tener que comprar varios dispositivos.
Este problema es muy importante porque hoy día no hay control sobre los tamaños de pantalla existentes. En la práctica podemos considerar que hay infinitos, y que no podemos hacer una solución expresa para cada uno. Porque el aspect ratio, o relación entre el ancho y el alto, también es variable. En cualquier momento un fabricante puede diseñar un nuevo tamaño y dejar nuestra aplicación obsoleta. Por eso hay que asumir que no podremos comprobarlos todos, porque no podremos comprar todos los modelos existentes.
La mejor solución consiste en trabajar con valores relativos, y comprobar nuestra aplicación con tamaños variados de pantalla. No tendremos el 100% de seguridad, pero si nuestra aplicación funciona bien en una buena variedad de tamaños, tendremos más posibilidades de ir por el buen camino. Por lo tanto, ésta es la razón más importante para combinar nuestro dispositivo real con emuladores: poder probar diferentes tamaños de pantalla sin tener que comprar todos los dispositivos que existen.
Más información - Curso de desarrollo en Android


miércoles, 18 de diciembre de 2013

El lenguaje de programación Dart será estándar

Cuando Google anunció su lenguaje orientado a objetos para la escritura de aplicaciones web complejas lo hizo con bastantes miras de futuro.

Y es que, según explicaba en su momento la compañía de Mountain View, Dart cuenta con una veloz máquina virtual capaz de superar a la competencia en ciertos benchmarks.
Aunque para garantizar su pervivencia no basta con lanzar dicho lenguaje a la calle y confiar en su evolución, sino que tiene que ser respaldado por la comunidad. Algo que acaba de conseguir ahora que la organización dedicada a la elaboración de normas Ecma ha formado un comité para publicar una especificación estándar del mismo.

Así lo han confirmado los propios responsables del proyecto, que se muestran "entusiasmados" con este logro, ya que es la base para "un futuro en el que Dart se ejecute de forma nativa en los navegadores web".

"La aplicaciones Dart pueden ser rápidas cuando se compilan para JavaScript", añaden, "pero una Dart VM incorporada permite un rendimiento aún mejor".

Dart alcanzó la versión 1.0 hace un mes, lo que implica que tras dos años de vida por fin está listo para que los desarrolladores web creen aplicaciones basándose en su código.
Entre otras características, el kit de Dart 1.0 incluye el entorno de desarrollo Dart Editor, su propia versión de Chromium bautizada como Dartium, el traductor dart2js con JavaScript mejorado y el gestor de paquetes Pub.

martes, 17 de diciembre de 2013

Documentación en Java - Javadoc

Tanto la biblioteca estándar de Java como la de la ACM son muy extensas 
–  Multitud de clases 
–  Multitud de métodos 
Es imposible conocerlos todos con detalle suficiente como para utilizarlos correctamente 
Por ello es muy importante disponer de una muy buena documentación. 
Es por ello que los diseñadores de Java, definieron un método sencillo para generar la documentación de las clases y métodos: 
–  La documentación se inserta en el mismo fichero que el código (en forma de comentarios) 
    •  De esta manera es más fácil que evolucione con él 
–  La herramienta javadoc extrae esos comentarios especiales y genera páginas html para ser vistas desde 
el navegador 
    •  De esta manera facilitamos poder navegar de una clase a otra. 
Añadiendo comentarios javadoc 
•  Añadir documentación es tan simple como poner un comentario que empiece por /** y acabe con */ 
•  Para poder estructurar mejor los comentarios dentro del comentario usaremos las marcas @param y @return para describir con detalle los parámetros y el resultado. 
•  Hay muchas marcas interesantes como por ejemplo @author, @version, @since, @throws, etc. 
Cómo generarlo 
•  Generar la documentación en Netbeans es tan fácil como, desde el proyecto, marcar en el menú contextual la opción “Generar javadoc” 
•  Una vez generada, nos abrirá el navegador para acceder a ella. 
Accediendo al javadoc 
•  Los ficheros generados los encontraréis en el subdirectorio dist/javadoc dentro del proyecto. 

lunes, 16 de diciembre de 2013

Manejo de sesión con Asp.Net

En este tutorial veremos el manejo de la sesión con ASP.NET, pero de una forma diferente, generalmente cuando se crean paginas con cierta seguridad se requiere al uso del Session[], una vez que este se llena la forma convencional de preguntar si el usuario esta o no logueado es en el page load del archivo .cs
if (Session["idusuariobs"] == null) { Response.Redirect("Default.aspx"); }
Con esta sentencia se evita que los usuarios puedan acceder a paginas restringidas sin la correspondiente autenticacion.
Lo tedioso de ello es que si tenemos una aplicación muy grande debemos colocar lo mismo tantas veces como paginas con restricciones allá.
Para evitar esto podemos desarrollar una clase que contenga la clase base Page y sobrescribir el evento OnInit
public abstract class clsPaginaSegura : Page { protected override void OnInit(EventArgs e) { base.OnInit(e); clsSesionPersona clsPersona = clsSesionPersona.ObtenerUsuarioSesion(); if (clsPersona == null) Response.Redirect("~/Login.aspx"); else this.Persona = clsPersona; } }
Como vemos se pregunta por el objeto clsPersona, dicho objeto puede servir incluso para guardar ciertos datos de la persona que se quiere autenticar, que por lo general se guardar en variables generalmente en la misma pagina login de la siguiente manera: Session[idUsuario]; Session[nombresUsuario] entre otros datos,  para evitar esto podemos crear una clase que almacene el objeto usuario en un objeto de sesión de la siguiente manera:
public clsSesionPersona(int intIdUsuario, string strLogin, string strNombre, string strApellido, int intIdPerfil) { IdUsuario = intIdUsuario; Login = strLogin; Nombre = strNombre; Apellido = strApellido; Perfil = intIdPerfil; }
public static clsSesionPersona ObtenerUsuarioSesion() { return HttpContext.Current.Session[strKEY] as clsSesionPersona; }
public static void CrearSesionUsuario(clsSesionPersona Persona) { HttpContext.Current.Session[strKEY] = Persona; }
Si observamos tenemos un método constructor donde llegan los datos de usuario y dos métodos estáticos uno para crear la sesión del usuario y otro para obtenerla, se usa el objeto  HttpContext.Current.Session[strKEY], que sirve para usarlo dentro de la clase.
Hasta aqui tenemos una clase que nos permitira evitar preguntar con un if en cada pagina que requiera autenticacion.
Ahora de una manera mucho mas sencilla solo colocamos el nombre de la clase que contiene obtener usuario sesion. Como funciona esto?, al momento de cargar la pagina la clase clsPaginaSegura pregunta por el metodo clsSesionPersona.ObtenerUsuarioSesion(); al instanciarlo en clsSesionPersona clsPersona = clsSesionPersona.ObtenerUsuarioSesion(), se procede a preguntar si viene vacio
if (clsPersona == null)  Response.Redirect("~/Login.aspx");  else  this.Persona = clsPersona;
Si el objeto viene vacío se procede a redireccionar o a realizar cualquier otro evento que se desee, de lo contrario se puede navegar en la pagina que estuvo restringida
Aqui vemos que con tan solo sustituir el System.Web.UI.Page por clsPaginaSegura ya tenemos una pagina que evita el acceso no permitido.
public partial class Administracion_Seguridad : clsPaginaSegura { }


viernes, 13 de diciembre de 2013

¡¡Feliz Navidad!!

De parte de toda la familia que compone la Asociación Española de Programadores Informáticos os deseamos de todo corazón que paséis una feliz navidad y un próspero 2014. 

Daros las gracias a todos los que nos seguís día tras día tanto en nuestro Blog así como en las distintas redes sociales, ya que sin vosotros esta labor social no sería posible.

Seguro que este año 2014 que está por llegar mejorará en todos los sentidos al que se va y deciros que este 2014 AEPI vendrá cargada de novedades. Muchas gracias y feliz navidad.



Mini curso de Log4j - Segunda parte

Paso 3: Personalizando los mensajes


Veremos un ejemplo más avanzado para ilustrar estos conceptos. Modifiquemos el archivo .properties para que tenga el siguiente contenido:

log4j.rootLogger=debug, stdout, R
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log
log4j.appender.R.Append=false
log4j.appender.R.MaxFileSize=100KB
log4j.appender.R.MaxBackupIndex=1
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

Destallaremos cada línea de esta configuración:

log4j.rootLogger=debug, stdout, R
Aquí estamos definiendo que nuestro Logger serán stdout y R. Ambos serán para atender el nivel debug.

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
En esta línea el appender stdout será de tipo ConsoleAppender. Esta clase se encargará de mostrar los mensajes a la pantalla.

log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
La clase “PatternLayout” nos permite configurar nuestro appender por una cadena. En el API del framework podemos ver más detalle de estas clases.

log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
Aquí ya estamos definiendo nuestro formato el cual consiste en mostrar en un espacio de 5 caracteres (%5) el nivel del mensaje (p). Luego sigue de un espacio. Entre llaves mostrará el hilo que generó el mensaje (%t). Luego de un espacio, entre paréntesis el nombre del archivo fuente (%F) y después de dos puntos muestra la línea dentro del código fuente (%L). Después sigue un guión y luego muestra el mensaje que se ha mandado desde el programa. Finaliza con un salto de línea.

Tenemos otro appender que es el R. Este es de clase RollingFileAppender. Esta clase permite agregar a un archivo y si este llega a un límite especificado es renombrado y el registro seguirá en un archivo nuevo. Esto es muy útil si queremos mantener todos los registros de eventos partidos en archivos de un tamaño manejable.
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log
log4j.appender.R.Append=false
Aquí estamos diciendo que el archivo que creará será “example.log”y que sobreescriba los mensajes cada vez que se ejecute la aplicación.



log4j.appender.R.MaxFileSize=100KB
Que tendrá un tamaño máximo de 100KB



log4j.appender.R.MaxBackupIndex=2
Y cuantos backups deberá crear antes de que el más antiguo deba borrarse.



log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
Aquí estamos definiendo el formato de salida que tendrá: la prioridad del evento (%p) seguido del nombre del thread que generó el evento (%t), el nombre completo de la clase incluyendo el paquete (%c) seguido de un guión y luego mensaje. Termina con una línea nueva.

Por último, agregaremos estas líneas a la configuración para enviar un email cuando suceda un error.
log4j.rootLogger=debug, stdout, R,email
....
log4j.appender.email.Threshold=error
log4j.appender.email=org.apache.log4j.net.SMTPAppender
log4j.appender.email.SMTPHost=smtp.provider.com
log4j.appender.email.From=events@jugperu.com
log4j.appender.email.To=user@jugperu.com
log4j.appender.email.Subject=Mensaje de Log4j!
log4j.appender.email.layout=org.apache.log4j.PatternLayout
log4j.appender.email.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
Para que este funcione deberemos de agregar la biblioteca de JavaMail.


Conclusiones

Cómo hemos visto, el cambio de la manera de registrar los eventos fue solo en el archivo .properties y no en nuestro programa. Muchas aplicaciones hechas en java que utilizamos – como el Tomcat – utilizan este framework de registro de mensajes. Puedes personalizar sus mensajes de acuerdo a tus exigencias. 


miércoles, 11 de diciembre de 2013

Mini curso de Log4j - Primera parte

Quién no ha utilizado System.out.println() para saber qué está haciendo en ese momento el programa, a veces ponemos mensajes mostrando el valor que tiene una variable, un array, etc. El problema sucede cuando el programa tiene que estar en producción y estos mensajes pueden resultar incómodos. Se torna una tarea tediosa buscar estas instrucciones para “comentarlas”. Y si hay error después ¿dónde está? ¡voy a tener que editar y recompilar el código para ver lo que pasa!. Afortunadamente programadores como nosotros han tenido el mismo problema y han desarrollado un framework que permite administrar estos mensajes – en inglés el término utilizado es logging – de tal manera que nuestros programas no tengan que pasar por el quirófano cada vez que esté “enfermo”. Este framework es Log4j.
Log4j permite registrar eventos de nuestro programa sin necesidad de modificar el código a cada instante. Estos eventos (o logs) pueden ser mostrados en pantalla, guardados en un archivo, enviados por correo electrónico, etc. Por ejemplo, cuando nuestra aplicación web se levantó correctamente deseamos que se guarde en un log la hora y fecha con un mensaje “SUCCESS”, pero cuando nuestra misma aplicación que atiende a más quinientos mil usuarios al día tenga un error crítico queremos que nos avise por correo electrónico a nuestro celular. Todo esto puede ser posible gracias a Log4j.


Desarrollaremos un ejemplo y a medida que lo hagamos iremos explicando cada parte del Log4j.

Paso 1: Obteniendo, instalando y configurando

Naturalmente para poder utilizar Log4j debemos obtenerlo de algún lado. Este framework se encuentra enhttp://logging.apache.org/. Descomprimimos su contenido en un directorio. Al descomprimir se habrá creado un subdirectorio con un nombre como logging-log4j-1.2.12. Este subdirectorio tiene otros subdirectorios que incluye la documentación, ejemplos, el código fuente y las bibliotecas necesarias. Dentro del subdirectorio “dist/lib” hay un archivo .jar que no pesa más de 400KB. Este es un nuestro framework que usaremos en nuestros programas.
Para usarlo recomiendo crear una biblioteca en nuestro IDE para así poderlo reutilizar en otros proyectos. Solo bastaría con agregar a nuestra biblioteca el archivo .jar del framework.
Recordemos que al crear un proyecto con nuestro IDE favorito, este crea una estructura de directorios especial. Generalmente crea el directorio src donde estarán todos los .java, un directorio class para nuestras .class, y un directorio build donde está la aplicación lista para ejecutar. Esto varía dependiendo de nuestro IDE.

Paso 2: Construyendo nuestro ejemplo.

Crearemos la clase demolog4j.Main (es decir, la clase Main dentro del paquete demolog4j)
package demolog4j;

import org.apache.log4j.Logger;

public class Main {
  static final Logger log = Logger.getLogger(Main.class);

  public static void main(String[] args) {
    log.info("iniciando aplicación");

    for (int i = 10; i >= 0; i--) {
      try {
        double n = 100 / i * 1.0;
        log.debug("el valor de n=" + n);
    }
      catch (Exception ex) {
      log.error(ex);
    }
  }
}
}

Es un ejemplo bastante forzado para mostrar tres de los cinco niveles de mensajes: info, debug y error. El nivel más detallado es el debug, que nos será de mucha utilidad al momento de depuración. Esto sirve, por ejemplo, para mostrar el nuevo valor de una variable. No debería estar activado cuando se encuentre el producción.

El siguiente nivel es info. Este nivel es para informarnos de cosas que ya se hizo algo concreto, tal como haberse conectado a la base de datos, el inicio satisfactorio de un servlet o un thread, etc. Es similar al modo “verbose” de las aplicaciones.
El siguiente nivel es el warn. Este es para advertir de eventos que no necesariamente pueda ser un error. Por ejemplo el que no haya definido un archivo de configuración pero se puede cargar valores por omisión,
El nivel error está relacionado para informar errores.
Y un nivel mucho más crítico es el fatal. Este es para informar de eventos que no tienen solución. Por ejemplo cuando una aplicación está a punto de cerrarse a causa de un error.
Para que nuestro ejemplo funcione crearemos un archivo llamado log4j.properties que debe estar en la raíz de los código fuente. Es decir, en el directorio src de nuestro proyecto. Debe encontrarse aquí ya que cada vez que el IDE construya el proyecto se copiará al directorio junto con las .classes.
El archivo log4j.properties deberá tener el siguiente contenido:

log4j.rootLogger=DEBUG, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
Y ejecutamos el programa. Lo que mostrará es algo similar a esto:
0    [main] INFO  demolog4j.Main  - iniciando aplicación
15   [main] DEBUG demolog4j.Main  - el valor de n=10.0
15   [main] DEBUG demolog4j.Main  - el valor de n=11.0
15   [main] DEBUG demolog4j.Main  - el valor de n=12.0
15   [main] DEBUG demolog4j.Main  - el valor de n=14.0
15   [main] DEBUG demolog4j.Main  - el valor de n=16.0
15   [main] DEBUG demolog4j.Main  - el valor de n=20.0
15   [main] DEBUG demolog4j.Main  - el valor de n=25.0
15   [main] DEBUG demolog4j.Main  - el valor de n=33.0
15   [main] DEBUG demolog4j.Main  - el valor de n=50.0
15   [main] DEBUG demolog4j.Main  - el valor de n=100.0
15   [main] ERROR demolog4j.Main  - java.lang.ArithmeticException:

Puedes editar la primera línea del log4.properties cambiando el texto “debug” por alguno de los demás niveles: info, warn, error o fatal para ver los resultados.


Estructura de Log4j.

Log4j tiene tres componentes principales: loggers, appenders y layouts. Estos tres tipos de componentes trabajan juntos para permitir a los desarrolladores registrar mensajes según el tipo y nivel de estos, y controlarlos en tiempo de ejecución para mostrarlos de acuerdo a un formato que le especifiquemos.

Loggers

La principal ventaja del Log4j comparado con el tradicional System.out.println() es su capacidad para habilitar o deshabilitar los registradores de mensajes sin afectar a los demás. Un registrador de mensajes (Logger) son entidades autónomas con configuración independiente, de tal manera que uno tenga cierta funcionalidad que otro no lo tenga. Los nombres de los loggers son sensibles a mayúsculas.

Appenders

La habilidad para activar o desactivar cualquier logger es solo una parte de Log4j. El framework permite registrar los eventos en varios destinos. Para Log4j una salida (pantalla, archivo, etc) es un appender. Actualmente, existe appenders para consola (como hemos visto), archivos, componentes visuales, servidores de sockets, JMS, Registro de Eventos de NT, y demonios de registro Unix.

Layouts

El layout es el responsable de formatear los mensajes de acuerdo a criterio del programador. Existen dos tipos de Layout: SimpleLayout, que básicamente muestra el nivel del mensaje y el mensaje en sí, y el PatternLayout que consiste en formatear la salida. 

Muchas gracias a los que nos habéis leído y a los que no también, en breve continuaremos con la siguiente parte.

martes, 10 de diciembre de 2013

Cómo obtener el elemento activo de un formulario con JavaScript





Para obtener el elemento activo de un formulario en Internet Explorer lo podemos hacer fácilmente con la propiedad activeElement, pero en navegadores Mozilla, como Firefox, no existe esta propiedad, aunque eso no quiere decir que no podamos hacerlo.
Podemos averiguar qué elemento está activo recorriendo los elementos del formulario y asignándoles una función en el evento onfocus y onblur que nos permitirá averiguar qué elemento está activo.

<script type="text/javascript">
var activeElement;
function blurFunc() {
activeElement = null; /* Cuando el elemento deja de estar activo el elemento activo pasa a ser nulo (null) */
}
function focusFunc(evento) {
 if(!evento) { // Para IE
evento = window.event;
activeElement = evento.srcElement; /* Cuando un elemento se activa (focus) lo indicamos */
} else { // Para otros navegadores
activeElement = evento.target;
}
alert(activeElement.name); // Lo utilizaremos para hacer la prueba
}
function init() {
for (var i = 0; i < document.forms.length; i++) {
for(var j = 0; j < document.forms[i].elements.length; j++) {
document.forms[i].elements[j].onfocus = focusFunc;
document.forms[i].elements[j].onblur = blurFunc;
}
}
}
window.onload = init;
</script>

El código que acabamos de ver, lo pondremos entre <head> y </head>. Luego, para probarlo, utilizaremos este formulario entre <body> y </body>
<form name="HolaMundo" action="">
Nombre: <input type="text" name="nombre">
Apellidos: <input type="text" name="apellidos">
<input type="button" name="activo" value="Enviar">
</form>


Cuando probemos este formulario, tanto con IE como con Firefox, al pulsar sobre un campo del formulario nos aparecerá una ventana con el nombre del elemento activo.

lunes, 9 de diciembre de 2013

Cómo usar adecuadamente el Log de Android en tus aplicaciones


Cómo usar adecuadamente el Log de Android en tus aplicaciones

Buenos días desde la Asociación Española de Programadores Informáticos os traemos un nuevo post sobre Android.
Es posible que durante el desarrollo de una aplicación Android, surja la duda de qué nivel de Log se debe usar, qué cosas se deben loggear y cuales no. En la documentación de Android se trata este tema, el cual traduzco para ponerlo a disposición de todos. Aunque el logging es necesario, tiene un impacto negativo significante en el rendimiento y pierde rápidamente su utilidad si no se mantiene razonablemente breve. La herramienta de logging de Android proporciona cinco niveles distintos para el log. A continuación se describe cada uno y se explica brevemente cómo y cuando deberían usarse:
  • ERROR: Este nivel de logging debe usarse cuando haya ocurrido algo fatal, por ejemplo, algo que tendrá consecuencias visibles para el usuario y que no se podrá recuperar sin eliminar explícitamente algunos datos, desinstalar aplicaciones, borrando las particiones de datos o reseteando el dispositivo por completo. Este nivel se loggea siempre. Los problemas que jusifiquen mostrar un log con este nivel son típicamente buenos candidatos para ser recolectados por un servidor de recopilación de estadísticas (statistics-gathering server).
  • WARNING: Este nivel de logging debe usarse cuando haya pasado algo serio e inesperado, por ejemplo, algo que tendrá consecuencias visibles para el usuario pero es probable que pueda recuperarse sin implicar la pérdida de datos realizando alguna acción explícita, oscilando entre esperar o reiniciar la aplicación por completo descargándola para reinstalarla, o reiniciar el dispositivo. Este nivel se loggea siempre. Igual que el nivel anterior, los problemas que impliquen registrar un WARNING son candidatos a ser reportados a un statistics-gathering server.
  • INFORMATIVE:Este nivel de logging debe usarse para indicar que ha pasado algo que puede resultar interesante a la mayoría de la gente, por ejemplo, cuando se detecta una situación que probablemente tenga un amplio impacto, aunque no es necesariamente un error. Esta condición debe ser loggeada sólo por un módulo que sea el considerado más apropiado en ese dominio (Para evitar registrar más de una vez el evento por componentes no autoritativos). Este nivel se loggea siempre.
  • DEBUG: Este nivel de log debe usarse para dar a conocer qué eventos están ocurriendo en el dispositivo que puedan ser relevantes para investigar y depurar comportamientos de la aplicación inesperados. Se debe loggear únicamente lo necesario para obtener la información suficiente sobre qué está pasando. Si los mensajes de log de en este nivel inundan el log, es probable que deban usarse en el nivel VERBOSE.
    Este nivel será loggeado, incluso en las versiones definitivas de la aplicación. Es necesario que estén en un bloque condicional del tipo if(LOCAL_LOG) o if(LOCAL_LOGD). Donde LOCAL_LOG[D] se define en una clase o sub-componente, para que exista la posibilidad de desactivar todos los mensajes de log en este nivel, por tanto, dentro de éstos bloques no puede haber ninguna lógica del programa, solo los mensajes de log.
  • VERBOSE: Este nivel de logging debe usarse para cualquier otra cosa. Solo se mostrará en las aplicaciones destinadas a depuración y debe estar dentro de un bloque if(LOCAL_LOGV) para permitir su desactivación.

jueves, 5 de diciembre de 2013

Servicio de traducción automática en SharePoint 2013

Una nueva aplicación de servicio que trae consigo SharePoint 2013 es la de traducción automática. En este post vamos a ver un ejemplo de uso, partimos de la base de que ya la tenemos configurada y lista para usar.
¿Cómo funciona? 
Microsoft nos proporciona un servicio de traducción automática alojado en la nube, este servicio es el que realmente realizará la traducción. Por lo tanto la aplicación de servicio simplemente lo que hace es reenviar esta petición de traducción al servicio de traducciones de Microsoft.
NOTA: El servidor donde se ejecutan las traducciones automáticas debe ser capaz de conectarse a internet.
Tendremos 2 tipos de traducción automática:

  • Síncrona: Se procesan en cuanto se envían.
  • Asíncrona: El proceso es realizado por un Timer Job llamado “SharePoint Translation Services” que está puesto a 15 minutos por defecto.


¿Qué vamos a poder traducir?
Con esta aplicación de servicios vamos a ser capaces de traducir archivos y sitios.
¿Cómo lo vamos a utilizar?
Para hacer uso del servicio de traducción automática de SharePoint 2013 podremos utilizar Modelo de Objetos de Servidor, Modelo de Objetos de Cliente y API REST.
¿Un ejemplo?
Para comprobar que la traducción funciona, voy a poner todo el contenido de este mismo post en un archivo de Microsoft Word y haremos que el servicio traduzca este contenido al inglés.
Por lo tanto para realizar esta comprobación, crearemos una aplicación de consola y realizaremos la traducción de forma síncrona.
El código que aparece a continuación coge el documento llamado “Traducción.docx”, lo traduce y lo pone en otra biblioteca que he utilizado para guardar las traducciones realizadas. El archivo traducido se llamará  “TraduccionIngles.docx”

SPServiceContext spContext = SPServiceContext.GetContext(spSite);
SyncTranslator timerJobTranslate = new SyncTranslator(spContext, CultureInfo.GetCultureInfo(1033));
timerJobTranslate.OutputSaveBehavior = SaveBehavior.AlwaysOverwrite;
timerJobTranslate.Translate(“http://xxxxxxx/Documents/Traduccion.docx” , “http://xxxxxxx/DocumentsTranslate/TraduccionIngles.docx”);

Como podéis ver, la forma síncrona usa la clase SyncTranslator, pasándole el contexto y la cultura nos bastaría para realizar la traducción instantánea, en cambio la forma asíncrona utilizaría la clase TranslationJob.
Con este simple bloque de código ya podríamos realizar una traducción del documento de español a inglés.
Por último solo nos queda ver el resultado de la traducción.
Inicialmente el documento tenía este aspecto
traduccionEspañol

y el resultado final después de la traducción es este
traduccionIngles



fuente: solidq