How to use WASM or WebAssembly

--Originally published at S' Nami Bog. Servitas Vitae

Follow this short and quick tutorial on how to use WASM!

From top to bottom- we have 10 different steps in order to get a Hello World from C without writing anything in our js file.

  1. We will select an Empty C Project although you can use C++ and Rust for using WASM aka High Level Languages.
  2. You will get three files, main.c main.html and main.js
  3. If you open the js file- you will see that the frist line of code is fetching the WASM that will later be instantiated into the wasm code
  4. As you can see we cleaned up the code and started using async
  5. Then we will run the code and get the result for output build running and build is complete
  6. After running it for the ou you will see a main.wasm file
  7. By checking the console you will see a related object named instance and module
  8. In the c file we have a reference to the js that calls the function
  9. We will next create a simple c code to run the Hello World
  10. Sadly we will have a null pointer so we will fix that
  11. Next step will be to get the memory buffer
  12. Fnally we will create a for function in order to get our string hello world variable
  13. Calling it and getting ID will print our Hello World named WASM

Herramientas para V & V

--Originally published at Luis Codes

Afortunadamente para el proceso de V & V tenemos varias herramientas que nos ayudarán a realizarlo paso a paso. A continuación veremos algunas de las mas fomosas o que me parecieron mas interesantes, de manera resumida:

TOOLS FOR VERSION CONTROL

Los sistemas de control de versiones, son una categoría de herramientas de software que ayudan a un equipo de software a gestionar los cambios en el código fuente a lo largo del tiempo. Realizan un seguimiento de todas las modificaciones en el código en un tipo especial de base de datos. Por ejemplo, si surge algun error, los desarrolladores pueden ir atrás en el tiempo y comparar las versiones anteriores del código para ayudar a resolver el error al tiempo que se minimizan las interrupciones para todos los miembros del equipo.

GIT

Que es GIT? (desde 0). Ahora nos toca hablar de una… | by Carlos López |  Medium

Es una herremienta que nos ayuda a tener un control de versiones de código de forma distribuida.

Características

  • Proporciona un fuerte apoyo para el desarollo no lineal
  • Modelo de repositorio distribuido
  • Capaz de manejar de manera eficiente proyectos de tamaño pequeño a grande.

Pros

  • Rendimiento rápido y eficiente.
  • Multiplataforma.
  • Los cambios de código se pueden rastrear de manera fácil y clara.

Contras

  • El registro histórico complejo y más grande se vuelve difícil de entender.
  • No admite la expansión de palabras clave ni la conservación de la marca de tiempo.

CVS

TortoiseCVS - Wikipedia

Características

  • Modelo de repositorio cliente-servidor.
  • Varios desarrolladores pueden trabajar en el mismo proyecto de forma paralela.
  • Mantiene una instantanea historica del proyecto.
  • Utiliza la técnica de compresión delta para un almacenamiento eficiente.

Pros

  • Multiplataforma.
  • El cliente de línea de comandos robusto y con todas las funciones permite una potente secuencia de comandos.
  • Se adapta espléndidamente a la naturaleza colaborativa del mundo del código abierto.

Contras

SOFTWARE TESTING

--Originally published at Luis Codes

Es un método para verificar si el producto de software real coincide con los requisitos esperados y para tratar de que el software tenga los menos defectos posibles. Se dice que las pruebas de software son una caja balnca y una pruba de caja negra.

El software testing es importante porque si hay un error, se puede identificar temprano y se puede resolver antes de la entrega del software. Con esto garantizamos fiabilidad, seguridad y alto rendimiento, lo que se traduce en ahorro de tiempo, rentabilidad y satisfacción del cliente.

  • Rentable: probar cualquier software a tiempo le ayuda a ahorrar dinero a largo plazo.
  • Seguridad: ayuda a eliminar riesgos y problemas antes.
  • Calidad del producto: las pruebas garantizan que se entregue un producto de calidad a los clientes.
  • Satisfacción del cliente: las pruebas de UI / UX garantizan la mejor experiencia de usuario.

TIPOS DE PRUEBA

Se clasifican en tres categorías:

  1. Pruebas funcionales: como UAT, localización, examen de la unidad y pruebas de integracion.
  2. Pruebas no funcionales: Actuación, resistenciam escalabilidad, usabilidad.
  3. Mantenimiento: regresión y mantenimiento.

ESTRATEGIAS DE PRUEBA

  • Prueba unitaria: ayuda a los desarrolladores a saber si la unidad individual del código funciona correctamente o no.
  • Purbe de integración: se enfoca en la construcción y diseño del software.
  • Prueba de sistema: verifica la funcionalidad, seguridad, portabilidad, entre otros.

NIVELES DE PRUEBA

El proposito de los niveles de prueba es hacer que las pruebas se software sean sistematicas e identificar fácilmente todos los casos de prueba posibles en un nivel particular.

Existen muchos niveles de prueba y los cuatro principales son:

  • Unit Testing: comprueba si los compponentes del software cumplen con las funcionalidades o no.
  • Prueb de integración: verifica el flujo datos de un modulo a otros modulos.
  • Prueba del sistema: evalúa las necesiades funcionales y no funcioanles para la prueba.
  • Continue reading "SOFTWARE TESTING"

SOFTWARE REVIEW

--Originally published at Luis Codes

Cuando piensas en “Software Review”, es muy probable que pienses en algo similar a lo anterior mente visto: validación y verificación. Si bien tiene de eso, este parte es otro proceso completoque implica probar el producto, otra paso en mas en el ciclo de vida del desarollo de software, pues ayuda a los ingenieros de software a alidar la calidad, la funcionalidad y otras caracteristicas y componentes vitales del software.

Una revisión de software es un proceso o reunión durante el cual un producto de software es examinado por toda la gente implicada en el proyecto como: gerentes, los usuarios, los clientes, los representantes de los usuarios u otras partes interesadas para obtener retroalimentación o aprobación. 

Este proceso es importate porque el equipo puede verificar si el software se ha desarrollado según los requisitos solicitados o no, y realizar los cambios necesarios antes de su lanzamiento. Otras razones importantes son:

  • Mejora de la productividad del equipo de desarrollo.
  • Hace que el proceso de prueba sea rentable, ya que dedica más tiempo a probar el software.
  • Se encuentran menos defectos en el software final.
  • Es solo en esta etapa que se eliminan deficiencias
  • Este proceso da como resultado una reduccion drástica del tiempo necesario para producir un documento tecnicamente sólido.

Fuente: https://www.geeksforgeeks.org/software-engineering-software-review/#:~:text=It%20is%20a%20whole%20process,test%20plans%20and%20test%20cases.

PEER REVIEW

Es un proceso que se utiliza en diferentes areas para verificar el trabajo realizado por el equipo para garantizar que cumpla con criterios especificos. En el desarrollo de software, la revisión por pares se usa a veces en el desarrollo de código, donde un equipo de codificadores se reunirá y revisará el código línea por línea para buscar error.

Las caracteristicas son:

V & V

--Originally published at Luis Codes

Cuando escuchaba los terminos validación y verificación, pensaba que tenían el mismo significados, y entonces los utilizaba como sinonimos. Sin embargo, si bien estan muy relacionados, en el ámbito de la ingeniería de software estos terminos tienen su diferencia. Los dos son procesos de comprobación, que nos ayudan a segurar que el software que estamos desarrollando esté acorde a las especificaciones y necesidades del cliente, pero a continuación veremos como se diferencian:

  • Verificación: En este proceso es donde se comprueban los requisitos funcionales y no funcionales de su especificación.
  • Validación: Aquí se comprueba que el software cumple con las expectativas que el cliente espera.

Para ser mas claro, cuando verificamos nuestro programa, estamos comprobando que cumple con las especificaciones previamente acordadas, y cuando estamos validando, es cuando se le muestra el programa al cliente y este nos dice si es realmente lo que él esperaba, o sea esperemos que nos de el visto bueno porque de lo contrario el programa puede cumplir con todo los requisitos, sin errores encontrados y funcional, pero si no es lo que el cliente tenía en mente no sirve de nada lo anterior.

El estándar más famoso para este proceso es el estándar IEEE 1012. Consiste en la verificación y validación de un software, es un procedimiento basado en normas de calidad en algunos modelos de vida de un software. Nos ayuda a determinar la calidad de un producto conforme a los requisitos a través de un método qu implica la evaluacion optuima del software y cada uno de sus componentes. Este estandar intervienen varios procesos, y en cada uno de ellos, implican varias tareas:

  1. Gestión
    • Revisión continua del esfuerzo V&V
    • Seguimienro de los SVVP según sea necesario
    • Establecimiento de auditorias y avaluaciones
  2. Gestión de esfuerzo

Calidad del Software

--Originally published at Luis Codes

¿Qué define que un software sea de “calidad”? Leí algo muy interesante en la página de xbosoft y es que dicen que es difícil percibir un software de calidad, PERO sí es fácil detectar su ausencia; unas palabras bastante profundas en mi opinión.

Así que vamos por pasos, primero veamos la definición. De acuerdo con el portal UNED, la calidad del software, trata los conceptos, los métodos, las técnicas, los procedimientos y los estándares necesarios para producir productos y procesos de software de alta calidad.

Lo primero que vemos es que, si bien es difícil decir que un software es calidad, sí debe de tener como mínimo algunas características porque de lo contrario no encontraríamos con diferentes problemas que el usuario final notaría. ¿ Y cuales son esas características? Bueno, en general son las siguientes:

  • Funcionalidad: que sirva con un propósito.
  • Ejecución: que sea práctico.
  • Confiabilidad: que haga lo que debe.
  • Disponibilidad: que funcione bajo cualquier circunstancia
  • Apoyo: a solución de errores o añadir futuras características.

Fuente: http://estandarescalidadsoftware.blogspot.com/2013/09/iso-9126_13.html

Afortunadamente no estamos solos, existen estándares para ayudarnos con esto ¿pero cómo?. Lo estándares definen un conjunto de criterios que guían la forma en que se aplican procedimientos y metodologías al software desarrollado, la certificación de calidad permite una valoración independiente de la organización, donde se demuestra la capacidad de desarrollar productos y servicios de calidad. Algunos de ellos son:

  • CMM para software: que tiene como propósito la mejora de procesos y que funciona en organizaciones de desarrollo de software.
  • ISO 9000: también para mejora de procesos y que si bien no esta enfocada directamente para el desarrollo de software, puede funcionar bien para organizaciones que producen productos, incluido el software.

En mi opinión es subjetivo decir que un software es de mejor calidad que otro, sin embargo Continue reading "Calidad del Software"

Estándares y modelos para el mejoramiento del proceso del software.

--Originally published at Luis Codes

Antes de empezar con los modelos, creo que es importante preguntarse: ¿por qué es importante usar un modelo para el desarrollo de software?

Bueno, de acuerdo con mi investigación esto es fundamental porque es lo que permite comprender cuales son los elementos específicos de una organización y ayuda en concentrarse en lo que se debe mejorar. Además, tiene ventajas como: producir productos y servicios de alta calidad y ayuda a que los desarrolladores puedan enfocarse en la mejora continua.

CMMI (Capability Maturity Model Integration)

Este es un modelo que contiene buenas practicas y que provee a los equipos de trabajo de aquellos elementos que son esenciales para que los procesos de negocio de las mismas sean efectivos. Aunque puede variar según el enfoque, en todos el propósito es hacer la evaluación de “madurez” de los procesos de una organización.

Veamos algunas ventajas de CMMI:

  • La gestión y la ingeniería de las actividades se encuentran entrelazadas de una manera explicita.
  • Ayuda a incorporar practicas como la medición, gestión de riesgo y de proveedores.
  • Cumplir de forma más completa las normas ISO.

TSP/PSP

PSP (Personal Software Process)

Se define como un proceso personal que se basa en la constante mejora, y por consecuencia un mejor trabajo. Este marco ayuda a los desarrolladores en:

  • Definir sus procesos
  • Planear y dar seguimiento a su propio trabajo
  • Administrar la calidad de su propio trabajo.

TSP  (Team Software Process)

Este modelo se centra en el trabajo en equipo, aunque tiene inspiración en PSP para realizar procesos y principios de ingeniería de software en un ambiente de trabajo en equipo.

TSP se enfoca en el trabajo en equipo porque:

Laboratory WebAssembly

--Originally published at Python learning

Georgina González Enríquez

Sebastián Cedeño González

Web Applications Development Laboratory

Basic 

  • Imagine what kind of applications you can do using WebAssembly

Some applications that can be done using WebAssembly are interactive pages for a business or academic entity, game applications, or streaming of content.

  • Do you see a future for WebAssembly?

Yes, because since it can be implemented along with web developing languages, it can bring together the advantages of the language WebAssembly is compiling, like C, with the advantages of web languages, like javascript.

Research

  • Write a mini-tutorial for using WebAssembly with another language. You must write at least three simple examples. 

Compile and run a hello world program in C

  1. Clone precompiled Toolchain repo to compile C to WebAssembly:

$ git clone https://github.com/emscripten-core/emsdk.git

$ cd emsdk

$ ./emsdk install latest

$ ./emsdk activate latest

2. In current command prompt, setup an Emscripten compiler environment (variables and directory entries):

$ source ./emsdk_env.sh –build=Release

3. Create our hello world program in C:

$ mkdir hello

$ cd hello

$ cat << EOF > hello.c

#include <stdio.h>

int main(int argc, char ** argv) {

  printf(“Hello, world!\n”);

}

EOF

4. Compile our program to WebAssembly:

$ emcc hello.c -o hello.html

5. Serve compiled files over HTTP:

$ emrun –no_browser –port 8080 .

6. Open http://localhost:8080/hello.html in your browser. The result should display “Hello, World!”:

1

Reference: https://webassembly.org/getting-started/developers-guide/

Compile and run a hello world program in C++

Note: since the toolchain used in the previous lesson works also with c++, the steps are almost the same.

  1. Clone precompiled Toolchain repo to compile C to WebAssembly

$ git clone https://github.com/emscripten-core/emsdk.git

$ cd emsdk

$ ./emsdk install latest

$ ./emsdk activate latest

2. In current command prompt, setup an Emscripten compiler environment (variables

2
3
Continue reading "Laboratory WebAssembly"

HFOOAD Ch 8. “Originality is Overrated” Indeed…

--Originally published at S&#039; Nami Bog. Servitas Vitae

One of the hardest parts of building or wanting to build an app/software is the design. Specially having lots of design principles to follow up and understand.

Thinking on building one on your own most likely will stress you out and you will not get somewhere, there is no point on breaking your head thinking about if your design is innovative enough to fulfill the expectations of someone else or even worst trying to innovate the OO. Time has proven that principles that have been implemented actually work and those are more flexible in terms of maintenance and the future possible extensions.

Here are some of the principles that could work for you and your software:

  1. Open-Closed Principle: Allows you to modify the code without erasing any line, just by adding. Of course in order to be elegible it must be open for an extension otherwise it won’t work. Also it must be closed for a modification.
  2. DRY or more commonly known as Do not repeat yourself: Is a principle that focus on avoiding duplicate code that could potentially be repeated. Mainly focuses on abstract things that are usually located in a single location.
  3.  LSP: Liskov Principle is mainly focus on the subtypes which must be able to be substituted for any given base type without breaking the code and its functions.
  4. SRP: We can relate this principle with two brothers. If the younger brother gets harmed the responsibility would be of the older brother. Same goes for the objects, this way we know which class would affect the other amd be responsible.