¿Qué es arquitectura de software?

 Escribir sobre arquitectura de software, que destila la experiencia de muchas personas, presupone que:

1. Tener una arquitectura de software razonable es importante para el desarrollo exitoso de un sistema de software, y
2. Existe un cuerpo de conocimiento suficiente sobre arquitectura de software para llenar un libro.

Hubo un tiempo en el que ambas suposiciones necesitaban ser justificadas. Hoy en día, parece haber poca controversia sobre ambos objetivos..

El principio básico de la arquitectura de software es que todo sistema de software se construye para satisfacer los objetivos empresariales de una organización, y que la arquitectura de un sistema es un puente entre esos objetivos (a menudo abstractos) y el sistema final (concreto) resultante. Aunque el camino de los objetivos abstractos a los sistemas concretos puede ser complejo, la buena noticia es que las arquitecturas de software pueden diseñarse, analizarse y documentarse utilizando técnicas conocidas que apoyan el logro de estos objetivos empresariales. La complejidad puede ser domada y hecha manejable.

Qué es y qué no es la arquitectura de software

Existen muchas definiciones de arquitectura de software, fácilmente accesibles con una búsqueda en la web, pero la que más nos gusta es esta:

La arquitectura de software de un sistema es el conjunto de estructuras necesarias para razonar sobre el sistema. Estas estructuras comprenden elementos de software, relaciones entre ellos y propiedades de ambos.

Esta definición contrasta con otras que mencionan las decisiones "tempranas", "principales" o "importantes" del sistema. Si bien es cierto que muchas decisiones arquitectónicas se toman temprano en el proceso, no todas lo son, especialmente en proyectos con desarrollo ágil o en espiral. También es cierto que muchas decisiones tomadas al inicio no son lo que consideraríamos arquitectónicas. Además, no siempre es fácil determinar si una decisión es "principal". A veces, solo el tiempo lo revela. Y dado que decidir sobre una arquitectura es una de las responsabilidades más importantes del arquitecto, necesitamos saber cuáles decisiones forman parte de una arquitectura.

En cambio, las estructuras son relativamente fáciles de identificar en el software y constituyen una herramienta poderosa para el diseño y análisis del sistema.

Así que aquí estamos: la arquitectura trata de estructuras que permiten razonar.

Veamos algunas de las implicaciones de nuestra definición.

La arquitectura es un conjunto de estructuras de software

Esta es la primera y más obvia implicación de nuestra definición. Una estructura es, simplemente, un conjunto de elementos unidos por una relación. Los sistemas de software están compuestos por muchas estructuras, y ninguna de ellas puede reclamar ser la arquitectura. Las estructuras pueden agruparse en categorías, y estas categorías proporcionan maneras útiles de conceptualizar la arquitectura. Las estructuras arquitectónicas pueden organizarse en tres categorías útiles, que desempeñarán un papel importante en el diseño, documentación y análisis de arquitecturas:

1. Estructuras de componentes y conectores
2. Estructuras de módulos
3. Estructuras de asignación

Aunque el software contiene un suministro casi interminable de estructuras, no todas son arquitectónicas. Por ejemplo, el conjunto de líneas de código fuente que contienen la letra “z”, ordenadas por longitud de menor a mayor, es una estructura de software. Pero no es una muy interesante, ni tampoco arquitectónica.

Una estructura es arquitectónica si apoya el razonamiento sobre el sistema y sus propiedades. Este razonamiento debe centrarse en un atributo del sistema que sea importante para algunos de los interesados. Estos atributos incluyen propiedades como:

• La funcionalidad que el sistema logra,
• La capacidad del sistema para seguir funcionando de manera útil frente a fallos o intentos de ataque,
• La facilidad o dificultad de realizar cambios específicos en el sistema,
• La capacidad del sistema para responder a solicitudes de los usuarios,
• Y muchas más.

Por lo tanto, el conjunto de estructuras arquitectónicas no está fijado ni es limitado. Lo que se considera arquitectónico depende de lo que sea útil para razonar en tu contexto y para tu sistema.

La arquitectura es una abstracción

Dado que la arquitectura consiste en estructuras, y las estructuras se componen de elementos y relaciones, se deduce que una arquitectura incluye los elementos de software y cómo estos se relacionan entre sí. Esto significa que la arquitectura omite, de manera específica e intencionada, cierta información sobre los elementos que no es útil para razonar sobre el sistema. Por lo tanto, una arquitectura es, ante todo, una abstracción de un sistema que selecciona ciertos detalles y suprime otros.

En todos los sistemas modernos, los elementos interactúan entre sí a través de interfaces que dividen los detalles de un elemento en partes públicas y privadas. La arquitectura se ocupa del lado público de esta división; los detalles privados de los elementos—aquellos relacionados exclusivamente con la implementación interna—no son considerados arquitectónicos.

Esta abstracción es esencial para manejar la complejidad de una arquitectura: simplemente no podemos, ni queremos, lidiar con toda la complejidad todo el tiempo. Queremos—y necesitamos—que la comprensión de la arquitectura de un sistema sea varios órdenes de magnitud más sencilla que entender cada detalle de ese sistema.

No puedes retener todos los detalles de un sistema, incluso de tamaño modesto, en tu mente; el propósito de la arquitectura es hacer que no sea necesario hacerlo.

Arquitectura versus diseño

La arquitectura es diseño, pero no todo diseño es arquitectura. Es decir, muchas decisiones de diseño no están determinadas por la arquitectura—ya que, después de todo, esta es una abstracción—y dependen del criterio y buen juicio de los diseñadores posteriores e incluso de los implementadores.

Todo sistema de software tiene una arquitectura de software

Todo sistema tiene una arquitectura, porque todo sistema tiene elementos y relaciones. Sin embargo, esto no significa que la arquitectura sea conocida por alguien. Tal vez todas las personas que diseñaron el sistema se hayan ido hace tiempo, la documentación se haya perdido (o nunca se haya producido), el código fuente haya desaparecido (o nunca se haya entregado) y todo lo que tengamos a mano sea el código binario en ejecución.

Esto revela la diferencia entre la arquitectura de un sistema y la representación de esa arquitectura. Dado que una arquitectura puede existir de manera independiente de su descripción o especificación, esto destaca la importancia de la documentación de la arquitectura.

No todas las arquitecturas son buenas arquitecturas

Nuestra definición es neutral respecto a si la arquitectura de un sistema es buena o mala. Una arquitectura puede tanto apoyar como dificultar el cumplimiento de los requisitos importantes de un sistema.

Asumiendo que no aceptamos el ensayo y error como la mejor manera de elegir una arquitectura para un sistema—es decir, seleccionar una arquitectura al azar, construir el sistema a partir de ella y luego modificarla improvisadamente con la esperanza de obtener buenos resultados—esto resalta la importancia del diseño de arquitectura y de la evaluación de arquitectura.

La arquitectura incluye el comportamiento

El comportamiento de cada elemento forma parte de la arquitectura en la medida en que este comportamiento pueda ayudarte a razonar sobre el sistema. El comportamiento de los elementos refleja cómo interactúan entre sí y con el entorno. Esto claramente está incluido en nuestra definición de arquitectura y tiene un impacto en las propiedades que exhibe el sistema, como su rendimiento en tiempo de ejecución.

Algunos aspectos del comportamiento están por debajo del nivel de preocupación del arquitecto. Sin embargo, en la medida en que el comportamiento de un elemento influya en la aceptabilidad del sistema en su conjunto, este comportamiento debe considerarse parte del diseño arquitectónico del sistema y documentarse como tal.

Arquitecturas de sistemas y de empresas

Dos disciplinas relacionadas con la arquitectura de software son la arquitectura de sistemas y la arquitectura empresarial. Ambas tienen preocupaciones más amplias que el software y afectan a la arquitectura de software mediante el establecimiento de restricciones dentro de las cuales un sistema de software, y su arquitecto, deben operar.

Arquitectura de sistemas

La arquitectura de un sistema es una representación del sistema en la que hay un mapeo de la funcionalidad en componentes de hardware y software, un mapeo de la arquitectura de software en la arquitectura de hardware, y una consideración de la interacción humana con estos componentes. Es decir, la arquitectura de sistemas se ocupa de la totalidad del hardware, el software y los humanos.

Por ejemplo, la arquitectura de sistemas influirá en:

• La funcionalidad asignada a diferentes procesadores,
• Los tipos de redes que conectan esos procesadores.

La arquitectura de software determinará cómo se estructura esta funcionalidad y cómo interactúan los programas de software que residen en los distintos procesadores.

Una descripción de la arquitectura de software, mapeada a los componentes de hardware y redes, permite razonar sobre cualidades como el rendimiento y la confiabilidad. Una descripción de la arquitectura de sistemas permitirá razonar sobre cualidades adicionales como:

• Consumo de energía,
• Peso,
• Dimensiones físicas.

Al diseñar un sistema en particular, es común que haya una negociación entre el arquitecto de sistemas y el arquitecto de software sobre la distribución de la funcionalidad y, en consecuencia, las restricciones impuestas a la arquitectura de software.

Conceptos básicos de Java: variables, tipos de datos, operadores, estructuras de control (if, switch, for, while).

 What will the following code print when run?

public class TestClass {
    public static void main(String[] args) throws Exception { //1

         var flag  = true; //2
         switch (flag){ //3
             case true -> System.out.println("true");
                 default -> System.out.println("false");
         }
              
    }
}

Compilation error at line marked //3.

A boolean cannot be used for a switch statement/expression. It needs an integral type (including wrappers), an enum, or a String.

Using a continue in a while loop causes the loop to break the current iteration and start the next iteration of the loop

True

Java champion path (de acuerdo a Chat-GPT)

 

Día 1: Fundamentos y Preparación

1. Revisión de Fundamentos

• Duración: 2 horas
• Actividades:
  • Repasar conceptos básicos de Java: variables, tipos de datos, operadores, estructuras de control (if, switch, for, while).
  • Ejercicios prácticos en estos temas para asegurar comprensión y fluidez.

2. Configuración del Entorno de Desarrollo

• Duración: 1 hora
• Actividades:
  • Instalar o actualizar el JDK (Java Development Kit) a la última versión.
  • Configurar un IDE (Eclipse, IntelliJ IDEA o VS Code con extensiones para Java).
  • Configurar las herramientas de línea de comandos necesarias (Maven, Gradle).

3. Lectura Técnica

• Duración: 1.5 horas
• Actividades:
  • Leer capítulos iniciales de un libro recomendado para desarrolladores avanzados de Java, como "Effective Java" de Joshua Bloch.
  • Tomar notas sobre las mejores prácticas y los principios fundamentales discutidos en el libro.

4. Práctica de Programación

• Duración: 2 horas
• Actividades:
  • Escribir programas simples que incorporen los conceptos repasados en la revisión de fundamentos.
  • Resolver problemas de programación en plataformas como HackerRank o LeetCode, enfocándose en problemas de dificultad baja a media.

5. Participación en la Comunidad

• Duración: 1 hora
• Actividades:
  • Unirse a foros y comunidades en línea de Java, como Stack Overflow, Reddit (r/java), y grupos en LinkedIn.
  • Leer y participar en discusiones relevantes, plantear preguntas y compartir conocimientos.

6. Reflexión y Planificación

• Duración: 30 minutos
• Actividades:
  • Escribir un diario o un blog breve sobre lo aprendido durante el día y cualquier desafío encontrado.
  • Planificar las actividades del día siguiente basado en los aprendizajes y ajustes necesarios.

¿Listo para comenzar? Si tienes alguna pregunta específica o necesitas más detalles sobre alguna de estas actividades, no dudes en preguntar.

Procedimientos para realizar revisiones sistemáticas

Revisiones sistemáticas

Una revisión sistemática de la literatura es un medio para identificar, evaluar e interpretar toda la investigación disponible relevante para una pregunta de investigación en particular, un área temática o un fenómeno de interés. Los estudios individuales que contribuyen a una revisión sistemática se denominan estudios primarios; Una revisión sistemática es un estudio secundario.

Razones para realizar revisiones sistemáticas

Hay muchas razones para emprender una revisión sistemática. Las razones más comunes son:

• Resumir la evidencia existente sobre un tratamiento o tecnología, por ejemplo para resumir la evidencia empírica de los beneficios y limitaciones de un método ágil específico.
• Identificar las lagunas en la investigación actual para sugerir áreas para futuras investigaciones.
• Proporcionar un marco / antecedentes para posicionar adecuadamente nuevas actividades de investigación.

Sin embargo, también se pueden realizar revisiones sistemáticas para examinar en qué medida la evidencia empírica apoya o contradice las hipótesis teóricas, o incluso para ayudar a la generación de nuevas hipótesis.

La importancia de las revisiones sistemáticas

La mayoría de las investigaciones comienzan con una revisión de la literatura de algún tipo. Sin embargo, a menos que una revisión de la literatura sea exhaustiva y justa, tiene poco valor científico. Esta es la razón principal para realizar revisiones sistemáticas. Una revisión sistemática sintetiza el trabajo existente de manera justa y considerada justa. Por ejemplo, las revisiones sistemáticas deben realizarse de acuerdo con una estrategia de búsqueda predefinida. La estrategia de búsqueda debe permitir evaluar la integridad de la búsqueda. En particular, los investigadores que realizan una revisión sistemática deben hacer todo lo posible para identificar e informar la investigación que no respalda su hipótesis de investigación preferida, así como identificar e informar la investigación que la respalda.

Ventajas y desventajas

Las revisiones sistemáticas requieren mucho más esfuerzo que las revisiones tradicionales. Su principal ventaja es que proporcionan información sobre los efectos de algún fenómeno en una amplia gama de entornos y métodos empíricos. Si los estudios dan resultados consistentes, las revisiones sistemáticas proporcionan evidencia de que el fenómeno es robusto y transferible. Si los estudios dan resultados inconsistentes, se pueden estudiar las fuentes de variación.

Una segunda ventaja, en el caso de los estudios cuantitativos, es que es posible combinar datos utilizando técnicas metaanalíticas. Esto aumenta la probabilidad de detectar efectos reales que los estudios individuales más pequeños no pueden detectar. Sin embargo, el aumento de potencia también puede ser una desventaja, ya que es posible detectar pequeños sesgos y efectos reales.

Características de las revisiones sistemáticas

Algunas de las características que diferencian una revisión sistemática de una revisión de literatura convencional son:

• Las revisiones sistemáticas comienzan definiendo un protocolo de revisión que especifica la pregunta de investigación que se está abordando y los métodos que se utilizarán para realizar la revisión.

• Las revisiones sistemáticas se basan en una estrategia de búsqueda definida que tiene como objetivo detectar la mayor cantidad de literatura relevante posible.

• Las revisiones sistemáticas documentan su estrategia de búsqueda para que los lectores puedan acceder a su rigor e integridad.

• Las revisiones sistemáticas requieren criterios de inclusión y exclusión explícitos para evaluar cada posible estudio primario.

• Las revisiones sistemáticas especifican la información que se obtendrá de cada estudio primario, incluidos los criterios de calidad para evaluar cada estudio primario.

• Una revisión sistemática es un requisito previo para el metanálisis cuantitativo.

El proceso de revisión

Una revisión sistemática involucra varias actividades discretas. Las pautas existentes para las revisiones sistemáticas tienen diferentes sugerencias sobre el número y el orden de las actividades (ver Apéndie 1). Este documento resume las etapas de una revisión sistemática en tres fases principales: planificación de la revisión, realización de la revisión, informe de la revisión.

Las etapas asociadas con la planificación de la revisión son:

1. Identificación de la necesidad de una revisión.
2. Desarrollo de un protocolo de revisión.

Las etapas asociadas con la realización de la revisión son:

1. Identificación de la investigación.
2. Selección de estudios primarios.
3. Estudio de evaluación de calidad
4. Extracción y monitoreo de datos.
5. Síntesis de datos.

Informar la revisión es una fase de una sola etapa.

Cada fase se analiza en detalle en las siguientes secciones. Otras actividades identificadas en las pautas discutidas en el Apéndice 1 están fuera del alcance de este documento.

Las etapas enumeradas anteriormente pueden parecer secuenciales, pero es importante reconocer que muchas de las etapas involucran iteración. En particular, muchas actividades se inician durante la etapa de desarrollo del protocolo y se refinan cuando tiene lugar la revisión adecuada. Por ejemplo:

• La selección de los estudios primarios se rige por los criterios de inclusión y exclusión. Estos criterios se especifican inicialmente cuando se define el protocolo, pero se pueden refinar después de definir los criterios de calidad
  
• Los formularios de extracción de datos preparados inicialmente durante la construcción del protocolo se modificarán cuando se acuerden los criterios de calidad.
• Los métodos de síntesis de datos definidos en el protocolo pueden modificarse una vez que se hayan recopilado los datos.

La hoja de ruta de revisiones sistemáticas preparada por el Grupo de Revisiones Sistemáticas en Berkley demuestra la naturaleza iterativa del proceso de revisión sistemática muy claramente

Planificación

La necesidad de una revisión sistemática

La necesidad de una revisión sistemática surge del requisito de los investigadores de resumir toda la información existente sobre algún fenómeno de manera exhaustiva e imparcial. Esto puede ser para sacar una conclusión más general sobre algún fenómeno de lo que es posible a partir de estudios individuales, o como un preludio para futuras actividades de investigación.

Antes de emprender una revisión sistemática, los investigadores deben asegurarse de que sea necesaria una revisión sistemática. En particular, los investigadores deben identificar y revisar cualquier revisión sistemática existente del fenómeno de interés contra los criterios de evaluación apropiados. CRC [12] sugiere la siguiente lista de verificación:

• ¿Cuáles son los objetivos de la revisión?
• ¿Qué fuentes se buscaron para identificar estudios primarios? ¿Hubo alguna restricción?
• ¿Cuáles fueron los criterios de inclusión / exclusión y cómo se aplicaron?
• ¿Qué criterios se usaron para evaluar la calidad de los estudios primarios y cómo se aplicaron?
• ¿Cómo se extrajeron los datos de los estudios primarios
• ¿Cómo se sintetizaron los datos?
• ¿Cómo se investigaron las diferencias entre los estudios? ¿Cómo se combinaron los datos?
• ¿Fue razonable combinar los estudios?
• ¿Las conclusiones fluyen de la evidencia?

Desde un punto de vista más general, Greenlaugh [9] sugiere las siguientes preguntas:

• ¿Puede encontrar una pregunta clínica importante, que la revisión abordó? (Claramente, en ingeniería de software, esto debería adaptarse para referirse a una pregunta importante de ingeniería de software).
• ¿Se realizó una búsqueda exhaustiva de las bases de datos apropiadas y se exploraron otras fuentes potencialmente importantes?
• ¿Se evaluó la calidad metodológica y los ensayos se ponderaron en consecuencia?
• ¿Cuán sensibles son los resultados a la forma en que se realizó la revisión?
• ¿Se han interpretado los resultados numéricos con sentido común y con la debida consideración a los aspectos más amplios del problema?

Desarrollo de un protocolo de revisión

Un protocolo de revisión especifica los métodos que se utilizarán para llevar a cabo una revisión sistemática específica. Es necesario un protocolo predefinido para reducir la posibilidad de sesgo del investigador. Por ejemplo, sin un protocolo, es posible que la selección de los estudios individuales o el análisis puedan estar impulsados ​​por las expectativas del investigador. En medicina, los protocolos de revisión generalmente se someten a una revisión por pares.

Los componentes de un protocolo incluyen todos los elementos de la revisión más información adicional de planificación:

• Antecedentes. La justificación de la encuesta.
• Las preguntas de investigación que la revisión pretende responder.La estrategia que se utilizará para buscar estudios primarios, incluidos los términos de búsqueda y los recursos a buscar, los recursos incluyen bases de datos, revistas específicas y actas de congresos. Un estudio de alcance inicial puede ayudar a determinar una estrategia adecuada.
• Estudiar criterios y procedimientos de selección. Los criterios de selección de estudios determinan los criterios para incluir o excluir un estudio de la revisión sistemática. Por lo general, es útil probar los criterios de selección en un subconjunto de estudios primarios. El protocolo debe describir cómo se aplicarán los criterios, por ejemplo, cuántos evaluadores evaluarán cada estudio primario prospectivo y cómo se resolverán los desacuerdos entre los evaluadores.
• Estudie las listas de verificación y los procedimientos de evaluación de calidad. Los investigadores deben desarrollar listas de verificación de calidad para evaluar los estudios individuales. El propósito de la evaluación de calidad guiará el desarrollo de listas de verificación.
  
• Estrategia de extracción de datos. Esto debería definir cómo se obtendría la información requerida de cada estudio primario. Si los datos requieren manipulación o se deben hacer suposiciones e inferencias, el protocolo debe especificar un proceso de validación apropiado
• Síntesis de los datos extraídos. Esto debería definir la estrategia de síntesis. Esto debería aclarar si se pretende o no un metanálisis formal y, de ser así, qué técnicas se utilizarán
• Calendario del proyecto. Esto debería definir el plan de revisión.

La pregunta de investigación

Tipos de preguntas

La actividad más importante durante el protocolo es formular la pregunta de investigación. Las Directrices australianas de NHMR [1] identifican seis tipos de preguntas de atención médica que pueden abordarse mediante revisiones sistemáticas:

1. Evaluar el efecto de la intervención.
2. Evaluar la frecuencia o tasa de una afección o enfermedad.
3. Determinación del desempeño de una prueba de diagnóstico.
4. Identificar la etiología y los factores de riesgo.
5. Identificar si una condición puede predecirse.
6. Evaluar el valor económico de una intervención o procedimiento

En ingeniería de software, no está claro cuál sería el equivalente de una prueba de diagnóstico, pero las otras preguntas se pueden adaptar a los problemas de ingeniería de software de la siguiente manera:

• Evaluar el efecto de una tecnología de ingeniería de software.
  
• Evaluar la frecuencia o tasa de un factor de desarrollo del proyecto, como la adopción de una tecnología, o la frecuencia o tasa de éxito o fracaso del proyecto.
  
• Identificar los costos y los factores de riesgo asociados con una tecnología.
  
• Identificar el impacto de las tecnologías en los modelos de confiabilidad, rendimiento y costo.
• Análisis de costo beneficio de las tecnologías de software.

Las pautas médicas a menudo proporcionan diferentes pautas y procedimientos para diferentes tipos de preguntas. Este documento no llega a este nivel de detalle. El tema crítico en cualquier revisión sistemática es hacer la pregunta correcta. En este contexto, la pregunta correcta suele ser una que:

• Sea significativo e importante tanto para los profesionales como para los investigadores. Por ejemplo, los investigadores podrían estar interesados ​​en saber si una técnica de análisis específica conduce a una estimación significativamente más precisa de los defectos restantes después de las inspecciones de diseño.
  Sin embargo, un profesional puede querer saber si la adopción de una técnica de análisis específica para predecir defectos restantes es más efectiva que la opinión de expertos para identificar documentos de diseño que requieren una nueva inspección.
• Conduzca a cambios en la práctica actual de ingeniería de software o a una mayor confianza en el valor de la práctica actual. Por ejemplo, los investigadores  y los profesionales desearían saber en qué condiciones un proyecto puede adoptar con seguridad tecnologías ágiles y en qué condiciones no debería.
• Identificar discrepancias entre las creencias comunes y la realidad.
  Sin embargo, hay revisiones sistemáticas que hacen preguntas que son principalmente de interés para los investigadores. Dichas revisiones hacen preguntas que identifican y/o abarcan futuras actividades de investigación. Por ejemplo, una revisión sistemática en una tesis de doctorado debe identificar la base existente para el trabajo del estudiante de investigación y dejar en claro dónde encaja la investigación propuesta en el cuerpo de conocimiento actual.

Estructura de preguntas

Las pautas médicas recomiendan considerar una pregunta de tres puntos de vista:

• La población, es decir, las personas afectadas por la intervención.
• Las intervenciones suelen ser una comparación entre dos o más tratamientos alternativos.
• Los resultados, es decir, los factores clínicos y económicos que se utilizarán para comparar las intervenciones.

Además, se pueden identificar los diseños de estudio apropiados para responder las preguntas de revisión.

Población

En experimentos de ingeniería de software, las poblaciones pueden ser cualquiera de los siguientes:

• Una función específica de ingeniería de software, p. probadores, gerentes.
• Un tipo de ingeniero de software, p. Un ingeniero novato o experimentado.
• Un área de aplicación, p. Sistemas informáticos, sistemas de mando y control.

Una pregunta puede referirse a grupos de población muy específicos, por ejemplo, evaluadores novatos o arquitectos de software con experiencia que trabajan en sistemas de TI. En medicina, las poblaciones se definen para reducir el número de estudios primarios prospectivos. En ingeniería de software, se realizan estudios mucho menos primarios, por lo tanto, es posible que debamos evitar cualquier restricción en la población hasta que lleguemos a considerar las implicaciones prácticas de la revisión sistemática.

Intervención

Las intervenciones serán tecnologías de software que aborden problemas específicos, por ejemplo, tecnologías para realizar tareas específicas, como la especificación de requisitos, las pruebas del sistema o la estimación de costos de software.

Resultados

Los resultados deben relacionarse con factores de importancia para los profesionales, como una mayor confiabilidad, menores costos de producción y menor tiempo de comercialización. Se deben especificar todos los resultados relevantes. Por ejemplo, en algunos casos requerimos intervenciones que mejoren algún aspecto de la producción de software sin afectar a otro, por ejemplo, mayor confiabilidad sin aumento en el costo.

Un problema particular para los experimentos de ingeniería de software es el uso de medidas sustitutas, por ejemplo, defectos encontrados durante las pruebas del sistema como un sustituto de la calidad,

Apéndice 1: Pasos para una revisión sistemática

Optimizar Eclipse Neon

Pasos para optimizar Eclipse Neon

1. Instalar Java en RAM
2. Deshabilitar AppXRay
3. Deshabilitar SpellChecking
4. Deshabilitar Animaciones
5. Deshabilitar Programas que se inician

Instalar Java en la memoria RAM

Pasos para instalar Java en la memoria RAM:

1. Asegurar que se tiene tmpfs: se digita el comando mount
2. Se crea un directorio donde se alojará java: sudo mkdir /media/java_ram
3. Se monta el directorio: sudo mount -t tmpfs tmpfs /media/java_ram
4. Se instala squashfs: sudo apt install squashfs
5. Se crea el archivo de squash: sudo mksquashfs /opt/java/jdk1.8.0_131/ /opt/java/java.sqsh
6. Se monta la partición: sudo mount /opt/java/java.sqsh /media/java_ram/ -t squashfs -o loop
7. Se instala la nueva versión en las alternativas: sudo update-alternatives --install /usr/bin/java java /media/java_ram/bin/java 1; sudo update-alternatives --install /usr/bin/javac javac /media/java_ram/bin/javac 1
8. Se selecciona: sudo update-alternatives --config java; sudo update-alternatives --config javac

Para hacer los cambios permanentes, se hace:

1. Se edita fstab: sudo nano /etc/fstab
2. Se agrega:
   
   tmpfs   /media/java_ram/        tmpfs   defaults,mode=1777      0       0
   /opt/java/java.sqsh     /media/java_ram squashfs        ro,defaults,loop        0       0
   

La delincuencia y el caos: Aplicación de los principios dinámicos no lineales a los problemas en la criminología

Glenn D. Walters

Abstract: Holism, nonlinear dynamics, sensitive dependence on initial conditions, and self-

organization are examined in an effort to determine whether these concepts have applicability

to research and theory on crime, criminals, and the criminal justice system. It is concluded that

these concepts, all part of a growing science of chaos, show promise of clarifying conflicting

empirical findings and resolving important theoretical issues within the general field of crimi-

nology. The topics covered in this article include empiricism and the problem of prediction, the

reconciliation of polar opposites, reaffirming choice, and learning and socialization. A case

example is used to illustrate how a chaotic interpretation of individual criminal behavior and

change differs from the traditional positivist, classical, and rehabilitative perspectives.

Nonlinear dynamical systems theory, better known as chaos, has been used to

explain such elusive and diverse phenomena as human brain waves (Basar, 1990),

cardiac arrhythmias (May, 1989), ecosystems (Bak & Chen, 1991), international

relations (Grossmann & Mayer-Kress, 1989), and the New York stock exchange

(Corcoran, 1991). Insomuch as chaos appears to have clarified the behavior of

inorganic systems, the next logical step would seem to be an examination of its

ability to elucidate the behavior of organic, in this case, criminal, systems. Being a

systems theory, chaos focuses on relationships between variables and seeks to

explain how these variables interact to form larger systems of influence. This article will consider whether principles borrowed from chaos theory can help clarify

several long-standing problems in criminology. First, however, crime must be

defined and key chaotic concepts described.

DEFINING CRIMINAL BEHAVIOR

There is probably no definition of crime that will satisfy all criminologists. The

present definition is therefore offered with the understanding that it suffers from

obvious limitations. Crime will be defined in this article as a quantifiable behavioral act that violates an established societal norm and is of sufficient severity

and/or frequency to elicit a corrective response from the governing structure of

that particular society. Violations of societal norms that do not come to the atten-

tion of criminal justice authorities are consequently not covered under this defini-

tion. It should be noted that this is a practical, rather than moral, definition, and

one that reflects the fluidity and relativity of human behavior. Laws change, as do

those in authority. Revolutionaries are often classified as criminals by those cur-

rently in power because they threaten the existing power structure. However, if

successful in overthrowing the existing government, the revolutionaries become

the lawmakers and the outgoing leaders become the criminals. Prior to the com-

munist takeover in Cuba, the supporters of Castro were portrayed as criminals by

the sitting Cuban government. However, once Castro assumed power, the sup-

porters of Batista suddenly became the criminals.

The practical definition of crime employed in this article, although it may be

viewed with skepticism by some, is actually in keeping with a chaotic view of the

universe. Chaos theory contends that people are in continual interaction with their

environment. As such, human behavior can only be understood with respect to

this environment. Conclusions based on an analysis of the person independent of

his or her current physical, social, or political environment are artificial and mis-

leading. Criminologists must consequently consider the behavior of the victim

and offender, the actions of the criminal justice system, and the general cultural

context of the interaction before crime can be understood. In the final analysis, no

single definition of crime is capable of capturing the complexity of the act for

which it was intended. Be this as it may, there is still a need to define crime in as

precise terms as possible. Mindful of the fact that any definition of crime will be

incomplete and less than fully satisfactory, the present article defines crime as a

behavioral act in violation of a societal rule, which is of sufficient severity and/or

frequency, that if known to the authorities would, in most cases, be followed by a

negative or corrective response from the societal body responsible for dispensing

criminal “justice.”

THE CHAOTIC PERSPECTIVE

In proposing chaos as a paradigm for criminology, it is important to keep in

mind that chaos is actually a compilation of assorted beliefs, ideas, and principles

connected by a common interest in holism, universality, and the behavior of sys-

tems. Accordingly, it is uncertain whether chaos has achieved the level of concep-

tual elegance and integration to be called a theory. Furthermore, because this

model asserts that order frequently arises out of disorder, the term chaos is some-

what misleading. Whether we decide on the term chaos, complexity, or unpredict-

ability, or call the ideas developed by Lorenz, Feigenbaum, Mandelbröt, and oth-

ers, a theory, a model, or a set of loosely connected ideas, chaotic interpretations

of the universe have had a major impact on the physical sciences. Chaos is actually

the third revolution in physics to take place in the 20th century, having been pre-

ceded by relativity and quantum mechanics (Gleick, 1987), and has all but

replaced the Newtonian view of an ordered universe. Unfortunately, the social sci-

ences have lagged behind the physical sciences in appreciating the nature of cha-

otic phenomena. In fact, many of the more popular models of human behavior still

rely on reductionistic principles borrowed from Newtonian physics. The goal of

this article is to demonstrate how chaotic principles like holism, nonlinearity, sen-

sitive dependence on initial conditions, bifurcation, and self-organization can be

applied to criminal systems, and in so doing address problems that have long

plagued the field of criminology.

HOLISM

Chaos is concerned with the behavior of systems. As such, it holds that the

actions of any single part of the system can only be understood with reference to

the entire system. Owing to the fact that every variable in a system is potentially

capable of influencing every other variable, chaos provides researchers with a

mechanism for evaluating variable interaction, without having to resort to the

cumbersome task of measuring each potentially relevant variable. Proponents of

chaos would argue that the universe is both ordered and disordered, simple and

complex, predictable and unpredictable. Chaos, it would seem, is a science of

contradiction and the reconciliation of seemingly antithetical phenomena and

processes. Whereas Aristotle and his followers were drawn to the separation of

opposites, Newton to the mutual neutralization of opposites, and Freud to the con-

flict between opposites, chaos is concerned with synthesizing opposites. It is the

complementary nature and potential union of opposing forces, according to

Sabelli and Carlson-Sabelli (1989), that stimulate growth and move the organism

toward increased levels of differentiation and adaptability. This dynamic interac-

tion of variables gives rise to what advocates of this approach refer to as system

flow, a process that requires both sensitivity and flexibility (Weiss, 1973). Sensi-

tivity encompasses a system’s overall awareness of the need for change, whereas

flexibility is an estimate of the system’s ability to implement such change.

NONLINEAR DYNAMICS

Linear models of mathematics assume that solutions are contained in multi-

variable equations. Unfortunately, open systems may not operate along linear

lines and so are frequently unamenable to simple linear analysis. Research on

open systems—an open system being defined as one that is influenced by and/or

interacts with other systems—demands a working knowledge of nonlinear

mathematics. Owing to the fact that nonlinear equations are nonadditive, they

often yield more than one solution (Barton, 1994). However, because nonlinear

equations frequently do a better job of modeling the behavior of open systems,

theorists operating out of a chaotic framework generally prefer nonlinear models to the more simplistic linear procedures employed by most behavioral scientists.

The principle of nonlinearity suggests that there is no single cause of an event and

no simple way to conceptualize the behavior of systems.

SENSITIVE DEPENDENCE ON INITIAL CONDITIONS

It has been speculated that a butterfly flapping its wings in Brazil could poten-

tially set off a tornado in Texas a month later (Lorenz, 1979). This seemingly

absurd scenario, although admittedly improbable, illustrates the principle of sen-

sitive dependence on initial conditions. Succinctly stated, this means that seem-

ingly insignificant events can sometimes have a major impact on the long-term

behavior of systems. This is because small differences can become amplified over

time and are therefore potentially capable of radically altering the movement of

the entire system. Sensitive dependence on initial conditions is most commonly

observed in unstable systems like the stock market, the weather, and human

behavior. Also known as the “Butterfly Effect,” in honor of Lorenz’s original flap-

ping butterfly wings analogy, sensitive dependence on initial conditions makes it

exceedingly difficult to predict the long-term behavior of open, relatively unstable

systems.

BIFURCATION

System growth depends on a process known as bifurcation. Around the middle

of the last century, P. F. Verhulst discovered that a population grows in linear fash-

ion until it reaches a certain critical level. The “Verhulst Process,” as it is now

called, occurs when a change in an important parameter drives the system to even

greater rates of growth despite the presence of certain limiting external conditions

(Peitgen & Richter, 1986). As a consequence of this process, population growth

tends to fluctuate between higher and lower values on successive years, a process

known as bifurcation or period doubling. Bifurcation involves the doubling of

points and contributes to the development and transformation of a system’s out-

come field (Feigenbaum, 1978).

SELF-ORGANIZATION

Self-organization is the capacity of a dynamic system to generate new forms. A

system will become unstable when infused with energy sufficient to bring about

changes in time, temperature, or space. However, this instability often gives rise to

system growth owing to the fact that systems possess the ability to self-organize

(Prigogine & Stengers, 1984). Self-organization requires communication

between individual cells for the purpose of establishing a common solution to a

problem, and the creation of a new and more complex pattern of organization.

Systems that vacillate between different values are in a better position to process

information, shift into an alternative mode of activity and adapt, than systems that

remain fixed on a specific value, action, or idea (Packard, 1988). That unstable

systems enjoy greater opportunities for adaptation than stable ones is underscored

by the fact that epileptics exhibit less flexibility and variety in their EEG patterns

than nonepileptics, and heart patients manifest less variation in EKG than healthy

adults (Freedman, 1995).

THE CHAOTIC PARAMETERS

OF CRIMINOLOGIC PHENOMENA

With a rapidly expanding base of information, it would stand to reason that

criminology should be in a position to answer many of the questions that have

plagued the field since its inception. However, with only a few exceptions (e.g.,

Gottfredson & Hirschi, 1990), the theories that have been generated by this prolif-

eration of criminologic data have been of the mini-model variety in which circum-

scribed features or aspects of crime or criminal justice are scrutinized. Although

these mini-models have furnished researchers with new insights and have encour-

aged further data collection, they have also added to the growing sense of theoreti-

cal fragmentation that appears to characterize the field of criminology. Williams

(1984), in fact, takes the field to task for what he sees as its lack of theoretical

imagination. Arguing that criminology has sacrificed innovation and intuition for

methodological rigor and statistical precision, Williams calls for renewed interest

in creative theorizing as a means of understanding crime, criminals, and the crimi-

nal justice system. It is proposed here that chaos may be capable of supplying

criminology with an organizing framework from whence disparate theoretical tra-

ditions and empirical findings might be integrated.

EMPIRICISM AND THE PROBLEM OF PREDICTION

In an effort to determine the “causes of crime,” positivists have taken the

empirical road to knowledge acquisition. Scholars adhering to a positivist

philosophy of criminological investigation assume that absolute or flawless pre-

diction is possible with the proper combination of variables, save the variance

attributable to measurement error. Identifying the variables that predict who will

become delinquent is therefore one of the primary goals of empirical criminology.

Exploring such issues as parental deviance, social class, genetics, intelligence,

and peers, positivists have been able to identify, with modest success, those

individuals who eventually become delinquent. However, as Rutter and Giller

(1984) point out, a substantial number of juveniles classified by investigators as

“high risk” on the basis of their background and behavior never become delin-

quent, and a fair number of youth classified as “low risk” become seriously delin-

quent despite predictions to the contrary. Thus, although certain conditions and

characteristics may distinguish between delinquents who do and do not go on to

become adult offenders, the percent of variance these predictors account for is

Solución de javax.net.ssl.SSLHandshakeException a lo dummy para glassfish

Hola! Hace un rato que no escribo y hoy os vengo a contaros la historia de cuando tuve que enfrentarme al problema de que el servidor glassfish (o java en general), necesita consumir algún servicio de una página web segura. La bitácora (o log) que nos entrega glassfish nos muestra el error javax.net.ssl.SSLHandshakeException 
el cual, como su nombre loo indica, significa que no se ha podido hacer el apretón de manos entre los servidores. Para que esto suceda, ellos deben entender que cada uno es confiable. Es decir, no le voy a dar la mano a cualquiera, salvo que yo confíe en él. Claro, si él me muestra su identificación y ésta es válida en todo el territorio nacional (como la cédula) o internacional (como el pasaporte), es más fácil confiar en él. Ahora, que no hace falta el amigo retardado que piensa que mostrando el carnet del colegio se puede identificar en cualquier parte. Yo confío en él, pero porque se que tiene sus problemas, pero, ya le expliqué que eso no está bien, que lo mejor es que él saque su identificación en una entidad certificadora. Claro, eso implica tener que pagar, y que la entidad lo vea (salvo que seas hijo del registrador).

Ahora bien, todos confíamos en la registraduría o en la central que expide los pasaportes, pero si no, explícitamente tenemos que decirle a los demás que confíe (por favor), en nosotros. Y para ésto hacemos lo siguiente:

Primero, identificar dónde está ese archivo, carpeta o en nuestros recuerdos, que nos muestra quiénes son confiables. En glassfish, normalmente está en el archivo domains.xml (glassfish/domains/domain1/config/domain.xml) y buscamos la línea que dice:

-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}

Generalmente está configurada con el archivo cacerts.jks

Entonces, nos bajamos ese archivo, y luego lo abrimos con un programa similar a key store explorer [1] 

Entonces, la idea es agregar el certificado a este depósito de certificados de confianza. Conseguimos el certificado, así, en chrome, hacemos click en:

Lo exportamos, luego vamos al programa antes mencionado, lo importamos con Tools->Import trusted certificate, Le damos Aceptar, OK, Aceptar. Luego guardamos el archivo cacerts, lo subimos y reiniciamos glassfish. Dudas? Comentarios? Felicitaciones? Escríbanme! :-)

[1] http://keystore-explorer.sourceforge.net/downloads.php

Imprimir datos de tipo enum en una lista desplegable en cakephp

Supongamos que se debe tener 'datos conocidos' de una tabla, algo así como en una tabla llamada 'sexo' y los campos son 'Masculino' y 'Femenino', pero todavía no tenemos la tabla. Se puede implementar 'mientras tanto' un campo de tipo enum[1] con esos datos.

Ahora, supongamos que tenemos dos o mas tablas y queremos traer datos de ellas para luego mostrarlos en una lista desplegable, entonces podemos hacer lo siguiente:

En el controlador se define una función llamada addEnums que toma como parámetros el nombre del campo de la tabla y el modelo que se va a usar:

public function addEnums($name, $modelo){
$this->loadModel($modelo);

$type = $this->$modelo->getColumnType($name);
preg_match_all("/'(.*?)'/", $type, $enums);
foreach ($enums[1] as $n){
$data[$n]=$n;
}

$this->set($name, $data);
}

Luego, en el mismo controlador, se llama de la siguiente forma (tengo dos tablas, Users y Players. Users tiene un campo que se llama 'sex' y Player un campo que se llama 'position'):

$this->addEnums('sex','User');
$this->addEnums('position', 'Player');

Y luego, en la vista, se muestran de la siguiente forma:

echo $this->Form->input('sex', array('options'=>$sex));
echo $this->Form->input('position', array('options'=>$position));

Y listo!

[1] http://dev.mysql.com/doc/refman/5.0/en/enum.html

Agregar tipos de archivo a Bluefish

Uno de los editores por defecto que tiene ubuntu es bluefish. Cuenta con resaltado de sintaxis y reconoce muchos lenguajes, pero no los tiene todos, por ejemplo la extensión ctp, que es la que usa CakePHP[1] para mostrar las vistas. Entonces, éste tipo de archivo se ve en blanco y negro. Horrible.

Otra de las cosas que tiene bluefish es que no se puede añadir otro tipo de archivo desde la interfaz gráfica, por lo que aquí está una solución a ese problema.

Lo hacemos con ctp, que es igual a php, pero para cake.

Se copia el archivo donde se especifica cómo se comportará el editor para un lenguaje (php) con el nombre que queremos que aparezca (ctp)

sudo cp /usr/share/bluefish/bflang/php.bflang2 /usr/share/bluefish/bflang/ctp.bflang2

Luego se edita ese archivo

sudo gedit /usr/share/bluefish/bflang/ctp.bflang2

Y reemplazamos con coincidencias de capitalización las palabras PHP por CTP y php por ctp

Y listo!

Al iniciar bluefish coloreará nuestro ctp

[1]http://cakephp.org/

SFTP con otra instancia de SSH

Buen día

Supongamos que se contrata un servicio de VPS al que se puede acceder solo por ssh y con una llave como en amazon ec2, y que este VPS va a ser un servidor web. Los usuarios desarrolladores del VPS necesitan acceder a este servidor, pero el administrador no puede dar la llave por seguridad. ¿Solución? Un servidor ftp, por ejemplo, pero ftp es inseguro [1], pero podemos asegurar mediante ssl o pasarlo por un túnel ssh. Supongamos que no queremos todavía ssl, y accedemos a la segunda opción. ¿Cómo hacerlo en la instancia de amazon?

Bueno, he aquí una solución:

Seleccionamos un puerto que no esté siendo usado y lo abrimos en el firewall de amazon añadiéndolo a las reglas de seguridad del grupo. Para el ejemplo será el 2221.

Se crea un usuario para editar los archivos web. En amazon el usuario por defecto es www-data. Así que podemos cambiarlo. Para nuestro ejemplo, creamos el usuario con nombre http. Hacemos que apache arranque con este usuario.

Detenemos apache

sudo service apache2 stop

Editamos /etc/apache2/envvars

Cambiamos www-data por http

Editamos /etc/passwd

Cambiamos /home/http por /var/www

Cambiamos los permisos del directorio /var/www PERO no del directorio en si. Este debe ser de root

chown http:http -R /var/www
chown root:root /var/www

Reiniciamos apache

sudo service apache2 start

Copiamos /etc/ssh/sshd_config con otro nombre /etc/ssh/sshd_ftp_config y editamos ese archivo

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_ftp_config

sudo nano /etc/ssh/sshd_ftp_config

Cambiamos 22 por 2221

Cambiamos ChallengeResponseAuthentication no por ChallengeResponseAuthentication yes

Cambiamos PasswordAuthentication no por PasswordAuthentication yes

Cambiamos Subsystem sftp /usr/lib/openssh/sftp-server por Subsystem sftp internal-sftp

Y agregamos al final

Match User http
    ChrootDirectory /var/www
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no

Y arrancamos el nuevo servicio

sudo /usr/sbin/sshd -f /etc/ssh/sshd_ftp_config

Y listo, Ya podemos conectarnos por filezilla por sftp

sftp://[ip] 

[1]http://juan0022.blogspot.com/2012/09/ftp-es-un-protocolo-inseguro.html

Descargar fuentes de Mac y iOS

Esto es para que no se me olvide y, para futuras referencias. Para descargar las fuentes de Mac e iOS, proporcionadas oficialmente por Apple, ir a la página:

http://opensource.apple.com/tarballs/

Encriptar y desencriptar entre java y php con AES

Para pode recuperar una contraseña haciendo cifrado simétrico entre java y php, encontré esta solución, pero se me perdió la fuente, tan pronto la sepa la pongo....

Java encriptación:


/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package cifrado;

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;


/**
 *
 * @author thaednevol
 */
public class Crypto {
//iv length should be 16 bytes
private String iv = "fedcba9876543210";
private String key = null;
private Cipher cipher = null;
private SecretKeySpec keySpec = null;
private IvParameterSpec ivSpec = null;

/**
* Constructor
*
* @throws Exception
*/
public Crypto(String key) throws Exception {
this.key = key;

// Make sure the key length should be 16
int len = this.key.length();
if(len < 16) {
int addSpaces = 16 - len;
for (int i = 0; i < addSpaces; i++) {
this.key = this.key + " ";
}
} else {
this.key = this.key.substring(0, 16);
}
this.keySpec = new SecretKeySpec(this.key.getBytes(), "AES");
this.ivSpec = new IvParameterSpec(iv.getBytes());
this.cipher = Cipher.getInstance("AES/CBC/NoPadding");
}

/**
* Bytes to Hexa conversion
*
* @param data
* @return
*/
public String bytesToHex(byte[] data) {
if (data == null) {
return null;
} else {
int len = data.length;
String str = "";
for (int i = 0; i < len; i++) {
if ((data[i] & 0xFF) < 16)
str = str + "0" + java.lang.Integer.toHexString(data[i] & 0xFF);
else
str = str + java.lang.Integer.toHexString(data[i] & 0xFF);
}
return str;
}
}

/** Encrpt the goven string
*
* @param plainData
* @throws Exception
*/
public String encrypt(String plainData) throws Exception {

// Make sure the plainData length should be multiple with 16
int len = plainData.length();
int q = len / 16;
int addSpaces = ((q + 1) * 16) - len;
for (int i = 0; i < addSpaces; i++) {
plainData = plainData + " ";
}

this.cipher.init(Cipher.ENCRYPT_MODE, this.keySpec, this.ivSpec);
byte[] encrypted = cipher.doFinal(plainData.getBytes());

return bytesToHex(encrypted);
}

public static void main(String[] args) throws Exception {
Crypto c = new Crypto("D4:6E:AC:3F:F0:BE");
String encrStr = c.encrypt("Hello World");
System.out.println("Encrypted Str :" + encrStr);
}
}

Java desencriptación


/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

package cifrado;

/**
 *
 * @author thaednevol
 */
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

public class Decrypto {
//iv length should be 16 bytes
private String iv = "fedcba9876543210";
private String key = null;
private Cipher cipher = null;
private SecretKeySpec keySpec = null;
private IvParameterSpec ivSpec = null;

/**
* Constructor
*
* @throws Exception
*/
public Decrypto(String key) throws Exception {
this.key = key;

// Make sure the key length should be 16
int len = this.key.length();
if(len < 16) {
int addSpaces = 16 - len;
for (int i = 0; i < addSpaces; i++) {
this.key = this.key + " ";
}
} else {
this.key = this.key.substring(0, 16);
}
this.keySpec = new SecretKeySpec(this.key.getBytes(), "AES");
this.ivSpec = new IvParameterSpec(iv.getBytes());
this.cipher = Cipher.getInstance("AES/CBC/NoPadding");
}

/**
* Hexa to Bytes conversion
*
* @param str
* @return
*/
public byte[] hexToBytes(String str) {
if (str == null) {
return null;
} else if (str.length() < 2) {
return null;
} else {
int len = str.length() / 2;
byte[] buffer = new byte[len];
for (int i = 0; i < len; i++) {
buffer[i] = (byte) Integer.parseInt(str.substring(i * 2, i * 2 + 2), 16);
}
return buffer;
}
}

/** Decrypt the given excrypted string
*
* @param encrStr
* @throws Exception
*/
public String decrypt(String encrData) throws Exception {
this.cipher.init(Cipher.DECRYPT_MODE, this.keySpec, this.ivSpec);
byte[] outText = this.cipher.doFinal(hexToBytes(encrData));

String decrData = new String(outText).trim();
return decrData;
}
public static void main(String[] args) throws Exception {
Decrypto c = new Decrypto("D4:6E:AC:3F:F0:BE");
String decrStr = c.decrypt("1f50a943601d8e29206c716f82e58b8d");
System.out.println("Decrypted Str :" + decrStr);
}
}

Encripción en PHP


$cipher = "rijndael-128"; 
$mode = "cbc"; 
$secret_key = "D4:6E:AC:3F:F0:BE"; 
//iv length should be 16 bytes 
$iv = "fedcba9876543210"; 

// Make sure the key length should be 16 bytes 
$key_len = strlen($secret_key); 
if($key_len < 16 ){ 
$addS = 16 - $key_len; 
for($i =0 ;$i < $addS; $i++){ 
$secret_key.=" "; 
} 
}else{ 
$secret_key = substr($secret_key, 0, 16); 
} 

$td = mcrypt_module_open($cipher, "", $mode, $iv); 
mcrypt_generic_init($td, $secret_key, $iv); 
$cyper_text = mcrypt_generic($td, "Hello World"); 
mcrypt_generic_deinit($td); 
mcrypt_module_close($td); 
echo bin2hex($cyper_text); 
?> 

Desencriptar en PHP


$cipher = "rijndael-128"; 
$mode = "cbc"; 
$secret_key = "D4:6E:AC:3F:F0:BE"; 
//iv length should be 16 bytes 
$iv = "fedcba9876543210"; 

// Make sure the key length should be 16 bytes 
$key_len = strlen($secret_key); 
if($key_len < 16 ){ 
$addS = 16 - $key_len; 
for($i =0 ;$i < $addS; $i++){ 
$secret_key.=" "; 
} 
}else{ 
$secret_key = substr($secret_key, 0, 16); 
} 

$td = mcrypt_module_open($cipher, "", $mode, $iv); 
mcrypt_generic_init($td, $secret_key, $iv); 
$decrypted_text = mdecrypt_generic($td, hex2bin("444e6969a269829a3e59a86300614fc5")); 
mcrypt_generic_deinit($td); 
mcrypt_module_close($td); 
echo trim($decrypted_text); 

function hex2bin($data){
$bin = "";
$i = 0;
do {
$bin .= chr(hexdec($data{$i}.$data{($i + 1)}));
$i += 2;
} while ($i < strlen($data));

return $bin;
}
?> 

Quitar una pestaña (o tab) de un tabhost en android

Para quitar una pestaña en un tabhost en android, se situa el widget en la pestaña cero, y luego se borra la que queremos borrar, eso si, sabiendo el id, así:

tabhost.setCurrentTab(0);

 tabHost.getTabWidget().removeView(tabHost.getTabWidget().getChildTabViewAt(ID));

Donde ID es el id de la pestaña que queremos borrar

Android “Only the original thread that created a view hierarchy can touch its views.”

Si les sale esto en android, significa que se ha  creado o se han creado elementos en un hilo y se trata de modificar en otro. Para resolverlo haz:

runOnUiThread(new Runnable() {
     public void run() {
//El código que hace lo que vos querás....

    }
});