Enigma LABS

Pepito, el arquitecto de software que vive en mi cabeza, ha irrumpido en mi pensamiento vociferando - ¡ Esto es insostenible ! Al parecer ha clonado nuestro bonito proyecto y ha encontrado flagrantes fallos de diseño. He tratado de explicarle que tenía muchas ganas de sacar adelante las primeras versiones, que las cosas no salen perfectas a la primera, le he reconocido que hay margen de mejora, y que tengo varias cosas apuntadas en mi libreta para retocar. Él seguía enfurecido. - ¡ No puedes enseñar esto al público, qué van a pensar ! En la eterna pugna entre desarrollador y arquitecto, siempre el arquitecto tiene la razón (¿o no? jjj) Me encantaría que fueran Uds. mismos queridos lectores quienes me propusieran mejoras y alternativas para la plataforma de test, lamentablemente este blog es de muy reciente creación, y no creo que ello vaya a ocurrir, así que de momento nos arreglaremos Pepito y yo solos. No obstante les animo una y otra vez a participar activamente. Recuerden ...

¡¡ Bien !! Después de unos cuantos arreglos, ya tenemos disponible el primer TEST para nuestra plataforma. Puesto que me gustaría mediante este blog interactuar con las entradas de Stackoverflow , para este primer test he seleccionado este interesante tema:  multithreading slower than singlethreading Y para introducirnos en la filosofía de los TEST, no es mi intención impartir una conferencia sobre este asunto, sino simplemente implementar las casuísticas que nos interesa evaluar, y medir los rendimientos. Vamos a ello. En primer lugar grabamos en BBDD (a través del recién desarrollado interfaz) el test, y los testcases . La cosa quedaría así: A nivel programático, debemos definir una clase cuyo nombre se corresponda con el campo "Clase" del Test. Y tantos métodos como "Casos" asociemos al test, haciendo igualmente coincidir los nombres. En este punto les recuerdo que pueden descargar el proyecto íntegro en  EnigmaLABS - GitHub Para que la comparació...

Ya tenía muchas ganas de poner a prueba nuestra recién desarrollada plataforma para Test, pero me di cuenta de que necesitaba unos cuantos ajustes antes de ponerla en marcha. Os recuerdo que todo el código está disponible en  Enigma Software - ZM LABS He habilitado un menú en las ramas secundarias del TreeView para grabar un nuevo test: Para que solo se despliegue en las ramas secundarias de tipo "Categoría" programo el evento Opening del Menú: private void contextMenuArbol_Opening ( object sender, CancelEventArgs e) { if (treeCatalogo.SelectedNode != null ) { objects.treeElement _treeelem = (objects.treeElement)treeCatalogo.SelectedNode.Tag; if (_treeelem.ElemType == objects.enumElemType.Categorie && _treeelem.Categorie.categorie_dad != null ) { e.Cancel = false ; } else { e...

En pocas palabras: vamos a probar y estresar distintas soluciones de software para un mismo problema, en busca de realidades matemáticas. Para ello, lo primero que necesitamos en averiguar el modo de publicar código aquí en Blogger . Para ello voy a usar un sistema súper sencillo y eficiente. Ahí va un ejemplo de código C# private void frmMonitor_Load ( object sender, EventArgs e) { TreeNode _tr = new TreeNode( "SQL Server Tips" ); TreeNode _tr2 = new TreeNode( "C# Code" ); treeCatalogo.Nodes.Add(_tr); treeCatalogo.Nodes.Add(_tr2); //splitContainer.Panel1.Focus(); //lstMonitor.Focus(); } Hilarante ¿verdad?   hilite.me  lo hace posible. Bien, paso 2, fácil y sencillo: vamos a crear una plataforma de testeo para C# en una bonita solución que compartiré en el repositorio GIT, para disfrute de todos. Enigma Software - ZM LABS Como posteriormente me dive...