El poder de Dios en nuestras vidas

Comparto una reflexión sobre un tema que me estaba circulando por mi mente desde hace años.


“¡Cuán innumerables son tus obras, oh Jehová!
Hiciste todas ellas con sabiduría; la tierra está llena de tus beneficios.” (Sal 104:24)

“Porque lo que de Dios se conoce les es manifiesto, pues Dios se lo manifestó. Porque las cosas invisibles de él, su eterno poder y deidad, se hacen claramente visibles desde la creación del mundo, siendo entendidas por medio de las cosas hechas, de modo que no tienen excusa. Pues habiendo conocido a Dios, no le glorificaron como a Dios, ni le dieron gracias, sino que se envanecieron en sus razonamientos, y su necio corazón fue entenebrecido. Profesando ser sabios, se hicieron necios.” (Ro 1:19:22)

Dios es el creador, sustentador y centro de todo el universo con su poder y su gloria creó todo lo que conocemos y que aún nos falta conocer, toda forma de vida y el hombre a su imagen y semejanza. Ese mismo Dios es quien controla toda su creación como un padre amoroso que escucha los pedidos de sus hijos y siempre responde conforme a su voluntad.

El apóstol Pablo en su carta a los romanos exhortaba a todo aquel que confiando es su propia sabiduría usaban los conocimientos que tenían en su propio beneficio, negando la existencia de un Ser Supremo creador de todas la cosas. Pero el Señor obra en los corazones de muchos que luego de aprender más sobre las maravillas del mundo quedan profundamente convencidos del poder de Dios.

El Señor reveló completamente el amor para con el mundo al enviar a su Hijo Unigénito para vivir como un hombre más, a excepción que no tenía pecado, sentir hambre y sufrimiento y a pesar de que nosotros seguimos siendo pecadores se ofreció en sacrificio por nuestros pecados.

Pero el plan de Dios no terminó en la cruz, pues con la muerte y resurrección de Cristo nos dió la oportunidad de reconciliarnos con Él. ¡¡¡Que gran muestra de amor!!!

El mismo poder que creó todas las cosas, cosas que nos maravillan en cada momento, es el mismo que resucitó a Cristo y es el mismo que nosotros como iglesia por medio de la oración podemos ser testigos.

¿Querés ser testigo del poder del Dios en nuestra iglesia?

¿Por qué confiar en nuestras propias fuerzas cuando podemos ponernos a disposición de su Santo Espíritu para que no las dé y en abundancia?

¿Podemos seguir viviendo a espaldas de Dios?

Citas Bíblicas: Salmos 104:24-35 / Romanos 1:19:22 / Salmos 24:1

“Feliz aquel que en su observación aprende, contemplando las maravillas de este vasto universo, ante tanta belleza, ante tanta grandeza, dobla tu rodilla y reconoce al Creador Divino”


Ampere (físico francés del siglo XIX)

Tip para el SoapUI

Hay casos en que desde el SoapUI no se puede importar wsdls que están hosteados en un sitio con autenticación integrada. Se desconoce el motivo del error. Pero de todas formas se puede importar el wsdl bajándolo como archivo y luego importar el archivo utilizando la opción Browse de Projects->"New SoapUI Project" o "Proyecto Ya creado"->Add WSDL

Debugging de formularios infopath

El presente post tiene como fin indicar los tips a seguir para poder debuguear formularios infopath que requieran prámetros de entrada desde el Visual Studio 2008 SP1.

• Seleccionar las propiedades del formulario a debuguear.
• Configurar el path del infopath.exe y los parámetros que se les quiera enviar (si aplica).
• El Visual Studio no puede levantar el formulario infopath por eso se debe llamar a una aplicación externa para que se encargue. En este caso la aplicación infopath.exe

Ejemplo
Dentro de Debug
Start externa programs:
Infoapth 2007: C:\Program Files\Microsoft Office\Office12\INFOPATH.EXE
Infopath 2010: C:\Program Files\Microsoft Office\Office14\INFOPATH.EXE

Publicación:
Luego de la compilación se deben publicar los formuario, en este ejemplo lo publicamos en la carpeta InfoPath_Publish en la raiz del proyecto.

Command line arguments:
"..\..\..\..\..\InfoPath_Publish\Formulario.xsn" /InputParameters "modo=parametro1=12345&parametro2=P&parametro3=54321&configpath=D:\MyProject\ProjectName\FormPath"

• Agregar breakpoints y ejecutar el debugging de la forma habitual con F5.
• Este proceso levantará en forma externa al Infopath y luego el Visual Studio adjunta el proceso del Infopath para poder debugguearlo.

Mica en fiesta bicentenario

 

Arquitectura de software, rol e integracion de aplicaciones

En el presente post, comparto un documento académico que hice con respecto al tema de referencia.

http://bit.ly/bfSKOR

El resumen de este documento fue posteado en

My Software Architecture Presentation

Habilidades de un arquitecto de software

 

La visión general de  un arquitecto de software es un experto en tecnologías de desarrollo, sería el encargado de proveer soluciones tecnológicas óptimas para los problemas del negocio. Además se espera que esas soluciones se integren correctamente con los componentes y soluciones existentes y planeadas.

El arquitecto se tiene que comportar como un arqueólogo, con inventiva, innovación, capacidad de mediación, negociación y liderazgo.

Por lo tanto se pretende que sea especialista pero a su ver tenga una visión general de todas las etapas del ciclo de vida del desarrollo del software. Esto le permite al arquitecto controlar aspectos de calidad en el desarrollo desde el inicio hasta la implementación en ambiente productivo y su posterior mantenimiento

Dado que es prácticamente imposible ser especialista en todas las áreas del ciclo de vida del desarrollo del software y a su vez tener una visión general del proceso existen las clasificaciones de los diferentes tipos de arquitectos de IT.

 

Joseph Hofstader agrega una visión del arquitecto desde el punto de vista de las habilidades de diseño. En la etapa inicial del proyecto debe tener una visión conceptual del mismo en base a los requisitos funcionales y las restricciones del negocio, en una etapa posterior se debe diseñar desde el punto de vista del modelo de dominio, puede ser horizontal o vertical, horizontal es aplicable a través de diferentes industrias y la vista de dominio vertical es aplicable a un industria en particular, se suele subestimar las habilidades para modelar dominios verticales, pero no es lo mismo el modelo de dominio para una empresa de banca, de telecomunicaciones, servicios o metalúrgica,  está habilidad tiene que ser estimada por los CIOs y aprovechada para brindar valor agregado a los diseños de los sistemas de la compañía.

Estos dos aspectos definen la definición del problema, tal como se muestra en la figura existe una segunda etapa que se basa a el desarrollo de la solución

 

 

 

 

Conocer cómo trabaja una tecnología no es lo único que se debe saber para diseñar aplicaciones robustas, dedicarle esfuerzo a esta etapa no es menos importante que las anteriores, pues un profundo conocimiento de la tecnología a aplicar permite al arquitecto alinear las especificaciones funcionales al diseño técnico. Es recomendable trabajar con el mínimo de tecnologías posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo, monitoreo etc, teniendo grupos con menos perfiles técnicos etc. [Hofstader Joseph, 2008].

 

 

 

Existe otra clasificación de los roles difundida por el IASA [Akenine Daniel, 2008] que está relacionada con ciertas actividades que debe realizar un arquitecto clasificada en 3 niveles y 40 artefactos a generar.

 

• Nivel 1: Los arquitectos y los responsables del negocio crean estrategias juntos  de cómo alinear las estrategias del IT con las del negocio. Estos principios y políticas tienen influencia en toda la organización. Ejemplos de entregables en este nivel son planes de desarrollo de software , visiones y estrategias
• Nivel 2: Los arquitectos crean artefactos que soportan la relación entre el negocio y la tecnología. A este nivel, los arquitectos intentan entender el proceso de la organización y como pueden mejorarlo usando las capacidades que provee el área de IT. Ejemplos de este tipo de artefactos son diagrama de procesos y de servicios.
• Nivel 3: Producen artefactos para el modelado técnico de la arquitectura, utilizan las mejores practicas de diseño posibles para crear buenas soluciones, tales como equilibrio entre costo y funcionalidad, escalabilidad, flexibilidad, seguridad y otros atributos de calidad. Dentro de este nivel están los modelos de aplicación, de datos, de dominio, de componentes, capas, objetos etc.

 

 

Habilidades blandas

 

Un arquitecto tiene que tener la habilidad de manejar relaciones inter personales entre los miembros de su equipo, los líderes de los proyectos, los clientes y usuarios manejando una adecuada comunicación y lenguaje acorde con cada perfil de interlocutor.  Es un error común hablar con lenguaje excesivamente técnico con un analista funcional o líder de usuario cuando en realidad se debería expresar en términos de procesos de negocio e interfaces de usuario y que valor agregado otorga el sistema al negocio.

Debe tener la habilidad de bajar a un nivel de atracción adecuado las especificaciones recibidas desde los usuarios que solicitan determinado sistema, para ello se requiere la habilidad de relevar la información necesario de esas personas.

 

Habilidades técnicas

 

La visión general que tiene el arquitecto le permite diseñar el sistema con un cierto nivel de abstracción que le permita describir todo el sistema.

En sistemas muy grandes estos diseños iniciales se subdividen en sistemas más pequeños que para poder simplificar el diseño. Estos subsistemas pueden estar construidos en diferentes tecnologías, implementados en infraestructuras diferentes, pudiendo ser construidos dentro de la empresa, por un tercero o bien ser un producto comercial. El diseño debe permitir integrar todos los sub sistemas mediante la utilización de estándares de integración de aplicación aplicables en la empresa.

Para un correcto diseño se debe tener bien identificados los requisitos funcionales, tener un adecuado conocimiento de las tecnologías, productos y sistemas implementados en la compañía, conocer sus ventajas y desventajas y luego decidir si utilizar productos y sistemas ya existentes, adaptarlos a las necesidades, construir nuevos o impulsar la adquisición de productos comerciales que se adapten a todo o parte de la necesidad del negocio. En el capitulo referentes a Diseño de Arquitecturas se analizará con más detalle este tema.

 

Referencias

 

1. [Akenine Daniel, 2008], “A Study of Architect Roles by IASA Sweden”, Architecture Journal 15, MSDN Architecture Center,  http://msdn.microsoft.com/en-us/architecture/cc505968.aspx 
2. [Hofstader Joseph, 2008], “We Don't Need No Architects”, Architecture Journal 15, http://msdn.microsoft.com/en-us/architecture/cc505974.aspx

 

 

 

Tutorial de Linq

Comparto este tutorial sobre linq a nivel introductorio muy intresante, principalmente porque empieza con lso conceptos básicos necesario para entender linq.

Linq

View more presentations from blo85.