Buscar

El Blog del Maldo

Si, es poco lo que escribo

Categoría

Desarrollo

Restaurar una base mongodb

Últimamente he estado trabajando con mongodb como base de datos, la verdad es que me ha sorprendido lo sencillo y potente de la herramienta, ha sido toda una experiencia que me ha parecido principalmente grata, aunque si, he tenido que cambiar el paradigma con el cual estaba acostumbrado a interactuar con las bases de datos, ha sido un desafío pero con más beneficios que problemas.

Dentro de las tareas que periódicamente he tenido que hacer, es restaurar la base de datos de desarrollo, principalmente cuando quiero alguna información, o un QA de alguna nueva funcionalidad con todo como corresponde. Como no es siempre, se me olvida el comando que tengo que escribir, me voy a hacer un ayuda memoria, y como no tengo entrada para hoy, lo voy a escribir acá.

Dos comandos son los que principalmente se utilizan, mongodump, para el backup de la base de datos, y mongorestore, para cargar un respaldo realizado de una base de datos.

Para la restauración de una base de datos, se utiliza el siguiente comando

$ mongorestore --drop -d <nombre-base-datos> <dirección-donde-está-el-respaldo>

Uno a uno los comandos

mongorestore es el comando de respaldo.
--drop le indica que elimine las colecciones de la base de datos, para ser restaurados con los nuevos, es importante incorporarlo si no se pueden producir inconsistencias ya que por defecto no elimina para reemplazar, hace algo raro que no entiendo mucho.
-d <nombre-base-datos> indica en qué base de datos debe ser restaurado
<dirección-donde-está-el-respaldo> indica la carpeta donde están los respaldos.

Hay que tomar en cuenta que los respaldos deben hacerse con mongodump para que queden el formato compatible, que es BSON con un archivo por cada una de las colecciones del sistema.

Sobre la arquitectura de software, qué se necesita

¿Que es la arquitectura de software? y ¿que se necesita para ser arquitecto?, primero, se confunde generalmente la arquitectura de software con la ingeniería de software, yo creo que la arquitectura de software forma parte de uno de los procesos de la ingeniería de software, mientras la ingeniería de software se preocupa del proceso de creación software completo, con una visión sistemática y completa, la arquitectura de software se enfoca sólo al proceso de diseño de un producto o sistema, donde no solo se tiene que preocupar del diseño de los algoritmos involucrados en el desarrollo, sino tener una visión general mucho más amplia teniendo clara las interacciones del software y enfocándose en los diferentes puntos que implican calidad del mismo, Philippe Kruchten lo explica mucho mejor que yo, dice:

”La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.”

Pese a no estar de acuerdo con Philippe Kruchten en aspectos metodológicos, que tienen que ver con la ingeniería del software más que con la arquitectura, creo que su definición es bastante acertada y me quedo con ella.

Y ahora ¿que se necesita para ser arquitecto?, me parece que es una lista de características que puede llegara ser infinita, por lo que sólo resumiré algunas de las que encuentro más importantes.

  • Conocimiento: Claramente una característica de un arquitecto de software es el conocimiento, de la plataforma, de la forma de trabajar, del negocio, de la tecnología y del equipo, no es necesario que lo sepa todo a la perfección, ya que para eso son los especialistas, pero sí debe tener el conocimiento suficiente para poder tomar decisiones que ayuden a mejorar la sinergia de todos los aspectos mencionados, ya que todas esas son las aristas de conocimiento que se deben tomar en cuenta, que se saca con impulsar una iniciativa de tecnología si nadie puede trabajar en ella, o hace que el negocio responda lento y sea inviable, o que no se tengan los medios económicos necesarios para soportarla.
  • Experiencia: No solo el conocimiento teórico es necesario, entre las funciones del arquitecto está lidiar con personas y problemas de la tecnología, y problemas que en teoría no ocurren y problemas que en la teoría ocurren y están bien documentados, pero en la práctica no son importantes o que el modelo de negocio está construido de tal forma que tales condiciones no se dan, para esos casos la experiencia es necesaria y absolutamente importante.
  • Liderazgo y negociación: No vivimos en un mundo ideal donde todo el mundo nos espera y podemos escribir un código muchas veces hasta que estemos orgullosos de ellos, estamos supeditados a tiempos, plazos, expectativa y factores humanos, es por eso que un buen arquitecto debe saber qué hacer, cómo lidiar con las circunstancias y que sacrificios hacer para poder cumplir con las expectativas y plazos, sin dejar de lado la motivación al equipo, la capacitación constante al mismo y trabajar como facilitador para eliminar problemas y prácticas que entorpecen el desempeño normal y correcto del equipo.
  • Visión del negocio: Una de las cosas más importantes bajo mi punto de vista, la informática es una ciencia de apoyo, y, amenos que sea en un contexto de investigación, no se hace arquitectura de software por arquitectura de software, si no para resolver problemas en función del negocio, no hay que perder de vista el negocio, el arquitecto es la pieza clave que debe tener la capacidad de alinear los proyectos con la realidad tecnológica y hacerlos coexistir en función del negocio y las metas de negocio.

Uno de los mejor libros que he leído sobre arquitectura de software es Software Architecture: Foundations, Theory, and Practice, tiene una visión moderna de la arquitectura de software, es muy detallado y se mezcla con los conceptos de Ingeniería de Software, muestra como se involucra la arquitectura en cada una de las etapas de la ingeniería de Software, y sobretodo mantiene la visión que muestra la arquitectura no como una etapa de la construcción del software, si no como parte integral del proceso de desarrollo, no importando en que etapa se encuentra. Si tienen oportunidad de leer este libro, se los recomiendo, es un libro que parece ser de carácter universitario, con ejercicios y todo al final del capítulo, muy bueno para reforzar el conocimiento, para el resto de los puntos, solo la experiencia es lo que mejor puede ayudar.

Apple y Samsung se unen para eliminar al chip SIM

Gaceta Tecnologica

Las tarjetas SIM, conocidas como el famoso chip que permite poder cambiar de smartphone sin perder la línea, tiene sus días contados ante una iniciativa de Apple y Samsung, que busca transformar este sistema en una nueva tecnología virtual que facilite el cambio entre operadoras de telefonía celular.

Según el reporte del Financial Times, las dos compañías, acérrimos rivales en el segmento de los dispositivos móviles, están desarrollando un nuevo estándard denominado e-SIM, que permite definir el número de línea sin tener la necesidad de utilizar una tarjeta física. Se espera que esta modalidad llegue al mercado en algún momento del próximo año, aunque Apple ya está experimentando algunos cambios similares mediante la Apple SIM, que permite elegir la operadora para la iPad Air 2 desde un único chip físico.

Virtualizar las prestaciones de la tarjeta SIM permitiría que los fabricantes puedan ganar un espacio pequeño pero vital para reducir…

Ver la entrada original 69 palabras más

Sobre la arquitectura de software, ¿qué se necesita?

Un colega hace unos días me preguntó que podía leer para poder mejorar su conocimiento, básicamente pidiendo consejo sobre cómo partir ya que tiene muy poca experiencia programando, lleva solo unos meses trabajando y aún está terminando su carrera. Bueno luego de conversar con él para saber que esperaba, que estaba interesado en aprender y cual era el foco de la pregunta, me confesó que le gustaría llegar algún día a ser arquitecto de software, por eso se acercó a hablar conmigo, porque pese a tener un cargo de arquitecto si no más de gestión, a falta de un arquitecto he estado supliendo el rol en la empresa donde trabajo.

La verdad es que no le quise contestar de inmediato, pese a que lo primero que se me vino a la cabeza fue el libro de patrones de diseño del GOF, o los videos de clean code de Martin Fowler, no me pareció sensato que partiera por ahí, puede ser mucho digerir para cuando uno recién está partiendo, y no me malinterpreten, no tiene que ver con capacidad, ya que creo que aprende muy rápido y está alcanzando el paso del resto de los programadores de la oficina, sin embargo es empezar por el lugar incorrecto, pese a este ser conocimiento crucial para un arquitecto, siempre es mejor partir por la base, poner los cimientos firmes y duraderos para que el resto de las cosas encaje de manera coherente y no se tengan que dejar espacios. Además por otro lado en una pelada de cable vía chat con mi amigo Gómez (que últimamente es la única forma de comunicación que estoy teniendo con él) le dije que me hacía falta y que yo no conocía un manual de referencia de arquitectura de software, donde se tocaran no sólo las técnicas de arquitectura de software, sino además las herramientas y los conocimientos necesarios, para que uno pueda consultarlo y repasar cuando haga falta, quedamos de tomarnos un café y pelar el cable para ordenar la idea y hacer una especie de investigación si encontrábamos material adecuado para ello. Cuento corto juntando las dos cosas voy a escribir algunas entradas adicionales a mi blog que trate temas de arquitectura y conocimiento sobre arquitectura de software, la idea es que sea una guía de referencia y no un lugar donde se describe y define a cabalidad cada uno de los conocimientos, por lo que puede ser que falte posteriormente una investigación sobre el tema tratado, o incluso se puede solicitar que ahonde en el tema en caso que algo no halla quedado claro.

Bueno dejándose de rodeos, partiremos por lo temas más básicos, ¿que es la arquitectura de software? y ¿que se necesita para ser arquitecto?, primero, se confunde generalmente la arquitectura de software con la ingeniería de software, yo creo que la arquitectura de software forma parte de uno de los procesos de la ingeniería de software, mientras la ingeniería de software se preocupa del proceso de creación software completo, con una visión sistemática y completa, la arquitectura de software se enfoca sólo al proceso de diseño de un producto o sistema, donde no solo se tiene que preocupar del diseño de los algoritmos involucrados en el desarrollo, sino tener una visión general mucho más amplia teniendo clara las interacciones del software y enfocándose en los diferentes puntos que implican calidad del mismo, Philippe Kruchten lo explica mucho mejor que yo, dice:

”La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.”

Pese a no estar de acuerdo con Philippe Kruchten en aspectos metodológicos, que tienen que ver con la ingeniería del software más que con la arquitectura, creo que su definición es bastante acertada y me quedo con ella.

Y ahora ¿que se necesita para ser arquitecto?, me parece que es una lista de características que puede llegara ser infinita, por lo que sólo resumiré algunas de las que encuentro más importantes.

  • Conocimiento: Claramente una característica de un arquitecto de software es el conocimiento, de la plataforma, de la forma de trabajar, del negocio, de la tecnología y del equipo, no es necesario que lo sepa todo a la perfección, ya que para eso son los especialistas, pero sí debe tener el conocimiento suficiente para poder tomar decisiones que ayuden a mejorar la sinergia de todos los aspectos mencionados, ya que todas esas son las aristas de conocimiento que se deben tomar en cuenta, que se saca con impulsar una iniciativa de tecnología si nadie puede trabajar en ella, o hace que el negocio responda lento y sea inviable, o que no se tengan los medios económicos necesarios para soportarla.
  • Experiencia: No solo el conocimiento teórico es necesario, entre las funciones del arquitecto está lidiar con personas y problemas de la tecnología, y problemas que en teoría no ocurren y problemas que en la teoría ocurren y están bien documentados, pero en la práctica no son importantes o que el modelo de negocio está construido de tal forma que tales condiciones no se dan, para esos casos la experiencia es necesaria y absolutamente importante.
  • Liderazgo y negociación: No vivimos en un mundo ideal donde todo el mundo nos espera y podemos escribir un código muchas veces hasta que estemos orgullosos de ellos, estamos supeditados a tiempos, plazos, expectativa y factores humanos, es por eso que un buen arquitecto debe saber qué hacer, cómo lidiar con las circunstancias y que sacrificios hacer para poder cumplir con las expectativas y plazos, sin dejar de lado la motivación al equipo, la capacitación constante al mismo y trabajar como facilitador para eliminar problemas y prácticas que entorpecen el desempeño normal y correcto del equipo.
  • Visión del negocio: Una de las cosas más importantes bajo mi punto de vista, la informática es una ciencia de apoyo, y, amenos que sea en un contexto de investigación, no se hace arquitectura de software por arquitectura de software, si no para resolver problemas en función del negocio, no hay que perder de vista el negocio, el arquitecto es la pieza clave que debe tener la capacidad de alinear los proyectos con la realidad tecnológica y hacerlos coexistir en función del negocio y las metas de negocio.

 

Tipo de Dato Bag

Nuevamente hace un rato que no escribía, ya se me había incluso quitado la costumbre, sobre todo porque el público objetivo del tutorial no lo leyó nunca ¬¬, pero bueno, mejor volver a la modalidad ecléctica donde escribo lo que se me ocurre y no me preocupo de mucho más, es más sano, que sea solo una catarsis  y una forma de dejar registro de las cosas que sean interesantes e importantes para mí. Luego del preámbulo aburrido y culposo clásico de cada periodo sin escribir ataquemos el punto, estructuras de datos.

Últimamente he estado leyendo el libre Algorithms, de Robert Sedgewick y Kevin Wayne, para refrescar conocimientos y repasar las materias ya añejadas en el inconsciente (esas cosas que siempre usas de una u otra forma pero no recuerdas al pie de la letra) y en la parte de las estructuras de datos me encontré con una que no conocía, así que para que no se me olvide la voy a escribir por acá, les presento el tipo de dato Bag (bolsa o bolsón sería en español).

Bag es un tipo de dato de colecciones de ítems cuya particularidad es que no soporta la eliminación de elementos, se puede instanciar un nuevo Bag, tiene un método para añadir un ítem al Bag, un método que pregunta si está vacío, uno que entrega el tamaño, y la posibilidad de iterar sobre todos los ítems, solo eso, no está ordenado, no deben los objetos ser iguales, no exige nada de eso. Por lo que una interfaz para este tipo de dato sería como la siguiente:

Este tipo de dato es muy útil para impedir que se eliminen ítems, ya que no implementa esta función y que no importe el orden en el cual se guardan los ítems en la estructura de datos. Un ejemplo de utilización puede ser por ejemplo cuando se quieren sacar datos estadísticos de un conjunto, con el conjunto definido no se quiere que se eliminen datos de este porque modifica los cálculos de la estadística y el orden en que ingresa no es importante ya que lo interesante es el resultado estadístico.

Eso, interesante, un tanto específico pero muy útil bien implementado.

Code Chef

He estado un poco flojo este último tiempo y no he posteado nada de nada en los últimos días, como este blog no lo lee nadie la verdad como que da un poco lo mismo XD, pero lo importante es que me propuse escribir todos los días y no lo he echo, aunque la falta fue justificada igual no viene al caso y estoy en deuda, me pongo al día si o si esta semana, pero como no comenta nadie a veces a uno le da un poco de lata, bueno… comenten y me animaré mas.. si alguien lee esto 😦

Bueno enfoquemos, hoy es martes, el día del link interesante, la semana pasada postie pex for fun, que es un enlace donde en línea se resuelve un problema, es tan bueno que un amigo lo usa como examen para las personas que entrevista cuando recluta personal, esta semana voy a poner otra opción de preguntas con un grado mayor de dificultad.

Code Chef, es una comunidad en línea que hace concursos de programación constantemente, en este caso se compite contra las demás personas de la comunidad y no contra una solución secreta, tiene el formato de las competencias de la ACM ICPC, con una entrada por la entrada estándar, que es básicamente leer por consola los datos de entrada, una salida con un formato por defecto, el programa se prueba contra muchas entradas y se ranquea si soluciona el problema en el tiempo determinado, los problemas como entrenamiento están clasificados y constantemente hay concursos, se están buscando una base de problemas para dar a personas que recién aprenden a programar o problemas complejos que se pueden solucionar con algoritmos avanzados, este es el lugar para encontrarlos, es muy bueno muy completo y no solo miden si la solución resuelve el set de problemas completo, si no si lo resuelve rápido y quien lo resuelve más rápido.

Eso, si quieren una base de problemas más complejo que se corrija en tiempo real, acá es su lugar, hay de todos los grados de complejidad, ojalá les guste.

 

Test de método privado estático C#

Hace 2 semanas escribí un post, sobre como testear métodos privados, no me percaté que con esta forma solo se podían escribir test unitarios para métodos de instancia, para los métodos estáticos privados se utiliza otra modalidad.

Supongamos que por alguna razón usted necesita métodos estáticos (que según yo, junto con la sentencia if, son el diablo, un cáncer que hay que aprender a vivir con el, pero intentar erradicarlo) y que por una razón aún más oscura se deben testear (como acotó Erwin en el post anterior, se debe testear comportamiento y no implementación), esto no debería suceder, pero supongamos.

Modifiquemos la clase matemática que teníamos antes para hacer la maldad de dejarla estática 😥 … debo insistir…

Con esto se debe crear otro método de prueba para esta clase, esto quedaría de la forma

Como se ve, se crea un objeto para envolver la clase Matemática que es estática, este objeto es de tipo PrivateType, con este objeto creado y a través de ese objeto, se puede acceder al método InvokeStatic, entregando como parámetro el nombre del método estático privado que se quiere testear y hacia al lado los parámetros de entrada de dicho método estático, como resultado entrega un objeto de tipo object, que como la vez anterior debía ser convertido al tipo del resultado que entrega el método para hacer el assert.

Eso, se los dejo, espero sinceramente que nunca lo usen, pero si no hay de otra, acá como se hace.

Tutorial: Desarrollo de software para productores audio visuales – Hola Mundo

La semana pasada partimos con este post, para introducir un poco de conceptos antes de partir con algunas prácticas de desarrollo, como dije, el paradigma más utilizado actualmente para desarrollar software es el paradigma orientado a objetos, pero, para iniciarse en el desarrollo de software el más utilizado es el imperativo, básicamente porque uno puede partir con la estructura de pensamiento algorítmico, sin tener toda la complejidad de la orientación a objetos, y como casi tradición en el mundo de la computación, hay que partir con el clásico hola mundo, un programa muy simple que solo imprime por pantalla.

Para poder hacer este primer programa, vamos a necesitar el ambiente de desarrollo, solo porque es más fácil vamos a utilizar visual studio express 2012 en su versión para Windows Desktop y con un sistema operativo Windows 7 en mi caso, pero puede funcionar perfectamente en windows 8, aunque existen algunas alternativas como sharpdevelop o xamarin studio, la más fácil de instalar en ambientes windows es visual studio. No voy a indicar paso a paso como instalar porque se pueden encontrar guías de instalación en el mismo sitio de microsoft.

Bueno, con el programa instalado, si voy a dar instrucciones paso  a paso de como hacer este primer programa.

  1. Abrir visual studio esperar el rato que se demora en levantar y cargar, si lo estás abriendo por primera vez, probablemente tomará un tiempo más largo del habitual.
  2. Seleccionar en la pantalla nuevo proyecto, y seleccionar aplicación de consola, en la parte inferior puedes seleccionar donde quedará la aplicación, si no sabes donde dejarla, te recomiendo que uses la ubicación por defecto, en el nombre de la aplicación usaremos HolaMundoConsola, antes de apretar aceptar deberías ver una pantalla similar a esta.Pantalla de Creación de Aplicación
  3. Se demorará unos segundos en crear la nueva aplicación para desarrollar, si todo salió bien deberías tener abierta la aplicación en el programa principal donde vamos a desarrollar, un ejemplo de pantalla a continuación, aunque no será idéntico porque tengo añadido algunos plugins, pero será muy parecido.Pantalla Hola Mundo

Miremos el código fuente que se genera automáticamente y veamos que significa cada uno de sus partes.

Se creo un programa con un solo archivo, al principio de este archivo se ponen las directivas using esta es una palabra clave reservada, lo que significa que no se puede usar para nada más al escribir un programa, no puede existir una variable que se llame igual que una palabra reservada, aquí una lista de estas palabras, bueno la palabra using significa que este programa usará funcionalidades que están en otra parte, en una librería externa, ya veremos como se hace esto más adelante, luego vemos la frase namespace HolaMundoConsola, esta frase quiere decir (mas o menos, porque es un poquito más complejo que eso) que si este programa fuera a ser utilizado como librería por otro programa, esta librería se llamaría HolaMundoConsola, luego dice class Program, como dijimos en el post anterior, el paradigma más utilizado es el paradigma Orientado a Objetos, y como c# es orientado a objetos, se debe crear una clase (que es algo así como una forma de hacer objetos) para poder hacer un programa, por defecto el nombre que le pone Visual Studio es Program se puede cambiar y tiene un significado mayor, pero por el momento trabajaremos así, cosa de no confundirnos porque son muchos conceptos, finalmente tenemos la frase static void Main(string[] args) que por ahora diremos que es la forma de indicar por donde se debe partir un programa, luego todo lo que esté entre { y }, es el programa propiamente tal.

Hasta ahora tenemos un programa completo que puede funcionar perfectamente, no hace nada pero puede funcionar perfectamente, si se presiona el botón Play verde al inicio de la en la parte del medio de la aplicación se puede ver como se ejecuta el programa.Iniciar Programa

Se debería levantar una pantalla negra y luego cerrarse inmediatamente, como no tiene instrucciones adicionales, no hace nada. Ahora pongamos algo para que se muestre en pantalla.

Debajo de static void Main(string[] args) entre las llaves { y } vamos a usar una funcionalidad que permite escribir un mensaje para ser visualizado por pantalla, dentro de la clase System, que indicamos que usaremos en la parte superior, existe una clase que permite escribir por pantalla y así mostrar al usuario algo de interacción, la clase que tiene esta funcionalidad es la clase Console, y la funcionalidad es WriteLine() si escribimos Console.WriteLine(“Hola Mundo”); el programa escribirá hola mundo, pero pasará tan rápido que no nos daremos cuenta, por lo que usaremos otra función de la clase consola la función ReadLine(), con esta función se puede esperar recibir información desde la pantalla que escriba el usuario, para nuestro caso servirá para esperar un enter antes de seguir. El programa debe quedar de la siguiente manera.

Ya con esto creamos un simple programa hola mundo, como se ve hay mucho involucrado en esto, no solo es escribir por pantalla si no que además vimos las partes que componen un programa.

TAREA:

Vamos a desarrollar un pequeño juego por partes, que será un juego de trivia, de preguntas y respuestas, como primera tarea escribe un programa que escriba por pantalla preguntas de trivia y que se detenga a esperar el enter luego de cada una de ellas.

Código:

El código del ejemplo de hola mundo se puede encontrar en https://github.com/sebmaldo/HolaMundoConsola y se puede bajar presionando Download Zip.

Test de Integración vs Test Unitarios

Me quería dar la lata de hablar sobre los tipos de test y de algunas definiciones, pero encontré un post muy bueno e interesante así que, ante eso, solo lo dejo como referencia y ustedes hacen como que lo escribí yo y me felicitan XD, en serio muy buen post, claro y entretenido, aunque está pensado en aplicaciones java, los conceptos son universales.

Test de Integración vs Test Unitarios.

Blog de WordPress.com.

Subir ↑