Ver por etiquetas
Todas las etiquetas »
Investigaciones »
Conceptos (
RSS)
Crackear una aplicación tiene algo de arte y de ingenio pero crackear una aplicación .Net es demasiado sencillo para mi gusto, y representa un problema para la empresa o desarrollador que la comercializa y vive de mantener y mejorar el producto. Ya no vale eso de “total quien se va a dar cuenta”, eso no es válido para ninguna aplicación pero esto es aún peor cuando se trata de herramientas de desarrollo de software las cuales serán utilizadas por profesionales que conocen como pueden saltearse los...
Introducción Existen ocasiones en las que almacenar y organizar nuestros datos en una estructura tabular puede no ser lo ideal, en las que por conveniencia queramos guardar un conjunto de datos fuertemente relacionados en un sencillo xml pero a la vez necesitemos muchas de las características propias de SQL. Si bien SQL Server nos permite guardar XML (con o sin esquema asociado) e indexarlo, estos índices son muchas veces demasiado grandes y algo lentos y, aunque funcionan obviamente muy bien, podríamos...
Muchas veces uno cree que el código que .Net Reflector muestra es fiel reflejo de lo que el desarrollador escribió, pero obviamente eso no puede ser cierto ya que esta herramienta toma el IL de un ensamblado y trata de mostrar su equivalente en los lenguajes que se le pida (C#, VB.NET, F# entre otros). Claro que muchas veces hacen tan buen trabajo que uno se olvida de eso. Como a ILSpy le falta una vueltita de rosca en este aspecto, esto se hace más evidente ya que uno termina...
Pensaba acerca de las cosas que podríamos hacer si el compilador de C# fuese un assembly reutilizable (Compilar as a service). Lo primero, y menos original, que se me ocurrió es que podríamos tener algo como JSON pero para C# en lugar de Java Script. 1: class Program 2: { 3: static void Main( string [] args) 4: { 5: const string data = @"results[" "professional" "] = 6: new 7: { 8: FirstName = " "Juan Pablo" ", 9: LastName = " "Ibañez" "...
Las recientes experiencias en la industria confirman que para obtener mejoras sustanciales mediante pruebas unitarias es necesario incorporar TDD (Test-Driven Development) como práctica integral del desarrollo. Aunque TDD no es una práctica nueva, solo experiencias recientes en Microsoft, IBM, HP y Ericsson comprueban la efectividad y factibilidad de ésta en proyectos reales y de reputación mundial. Los números de los resultados en realmente asombrosos. Les recomiendo leer las siguientes publicaciones...
Hoy todos reconocemos el potencial que tiene (LOP) Language Oriented Programming, pero no solo eso sino que muchos ya están invirtiendo para hacerse con las ventajas prometidas por este paradigma(?). Muchos incluso diseñan la sintaxis de aquellos lenguajes que entienden, pueden hacerles alcanzar la productividad, calidad y mantenibilidad que buscan. Ahora bien, una vez decididos a crear el lenguaje (textual) propio para un dominio particular, hay que implementarlo. Aquí es donde deben estudiarse...
Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran. En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código...
En mi último post presentaba una métrica (verdaderamente muy mala) sobre mi productividad en un proyecto realizado completamente utilizando TDD de manera estricta. Esta mostraba aproximadamente 9 LOC/Hs. Al mismo tiempo, y como las pruebas y el código los escribí interactivamente, escribía 11 LOC/Hs de pruebas. Esto hace un total de 19 LOC/Hs. Ahora bien, cada 2 o 3 pruebas el código era refactorizado para eliminar duplicaciones, del mismo modo que luego de observar un patrón común en un conjunto...
Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme. La primera parte de ese desarrollo está completado y estos son los números: 66 pruebas unitarias. 15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y...
Intro Como ya sabemos, un DSL es un lenguaje de programación que se construye para atacar una familia de problemas que se presentan habitualmente en un dominio particular. Aunque su denominación actual (DSL) es relativamente nueva, estos han sido utilizados desde siempre, en particular los que Martin Fowler llama “external DSL” los cuales muchas veces los utilizamos dentro de otro lenguaje huésped. Por ejemplo, es muy común encontrar SQL, XPath, RegEx, Xml...
Key Padawan es un herramienta para presentaciones, una especie de keylogger visual....