Jorge Serrano
  • Home

Lo que hay detrás de las pruebas unitarias

  • By jorge
  • Sep-29-2010
  • Sin categoría
  • 11 Comments.

Leo en el blog de David Salgado una entrada acerca de pruebas unitarias que no tiene desperdicio, y leo aún con más interés si cabe los comentarios que dejan los lectores de su blog y de los que siempre se aprende algo.

Tentado me he visto desde el principio para escribir un comentario en su blog, de hecho, después de escribirlo y apunto de darle al botón de publicar he pensado que qué mejor sitio que mi propio blog para comentar algo con lo que me he «pegado» no una, sino mil veces, y que dada la extensión que puede tomar el tema, mejor abrir un nuevo hilo.

Paulovila hace unos comentarios acerca de si las pruebas unitarias no tienen sentido sino hay dinero para hacerlas, y no puedo estar más de acuerdo… con matices, matices que van a favor del comentario pero que ahora trataré de expresar de la mejor forma posible (espero que se me entienda perfectamente).

A niveles de coste, un proyecto debe ser iniciado solo si el coste del proyecto va a devolver un beneficio mayor que el propio coste, y siempre si ese beneficio está dentro de unos ratios marcados. El ROI o retorno de inversión es la mejor explicación para entender esto.

Para explicarlo de una forma más práctica, un proyecto debe ser iniciado si vamos a recuperar lo que hemos invertido y si tenemos claro que nos va a revertir un beneficio adicional al propio gasto, es decir, que no vamos a vender únicamente para cubrir los gastos porque entonces habremos perdido realmente tiempo con respecto a nuestra competencia y nuestra empresa no habrá crecido. Es lo que en castellano se diría la frase de comidos por servidos.

Dicho esto que es obvio, el problema fundamental de las empresas reside en lo que esas empresas contabilizan como gastos y partidas presupuestarias.

Evidentemente, y tampoco querría extenderme con muchísimo detalle, existen gastos directos y gastos indirectos. Los directos son muy claros y evidentes, mientras que los indirectos son más estimativos que los directos. Y no entro en valorar lo que se entiende por estimaciones porque daría para otra entrada mucho más larga que esta.

El caso es que muchas personas y empresas olvidan detallar gastos como por ejemplo la tinta y el papel de impresora, los bolígrafos, las libretas, los rotuladores para las pizarras, los cafés o incluso la luz por citar algunos pequeños ejemplos. Por eso muchas empresas deciden poner una partida presupuestaria de gastos generales.

Otro gasto son los sueldos del personal que va a trabajar en el proyecto, y ahí se prorratea siempre, ya que a lo mejor es necesario disponer de un Arquitecto de Software, pero ese Arquitecto estará en el proyecto durante un 7% del proyecto, por lo que los gastos a imputar se prorratean, y así hasta un largo etcétera que tampoco es cuestión de comentar ahora.

Tampoco trataríamos los gastos derivados de las licencias de Software y partida a través de su amortización. Y así podría seguir nombrando aspectos que muchas veces pasan desapercibidos… por lo menos en primera instancia.

Sin embargo, aún no he nombrado la base principal de esta entrada, de uno de esos «gastos», me refiero como no al gasto de las pruebas unitarias.

Aquí es donde quiero detenerme con más precisión para comentar algunas cosas que considero importantes y que cuando hablo con algunas personas veo que no quedan del todo claras.

Muchas empresas ven las pruebas unitarias como gasto que tendrían que salir de sus presupuestos. Algo que a todas luces es más que evidente.

El problema es que muchas empresas ven en ese gasto una pérdida y no una inversión. Ahí es donde se comienza a liar el asunto y donde debemos abrir bien los ojos.

Aquí podríamos definir que el gasto inicial de las pruebas unitarias y siempre y cuando las pruebas unitarias estén bien hechas (que no haya que repetirlas más de una vez porque están mal enfocadas o diseñadas), tendrá un retorno de inversión en modo de menos errores (nadie asegura que las pruebas unitarias resuelvan todos los males), mejor aspecto funcional, mejor experiencia y mayor satisfacción por parte del usuario, más seguridad y más convencimiento de que el Software hace lo que tiene que hacer, y por lo tanto, mayores posibilidades de que nuestro Software sea vendido a más usuarios o empresas que estarían satisfechos con la inversión (a modo de licencia) que han realizado por nuestro Software.

Evidentemente, cuanto mayor cualificado esté el equipo de desarrollo en
hacer esas pruebas unitarias, menor será el coste asociado a la
elaboración de esas pruebas unitarias, sin embargo, siempre habrá un
coste fijo asociado a la creación del propio conjunto de pruebas unitarias, y a medida que el proyecto avance, se irán cumplimentando y creando más pruebas unitarias. Porque otra cosa que no quiero tampoco discutir ahora, es que las pruebas unitarias deben hacerse al mismo tiempo que el desarrollo, porque sino luego, el coste para hacerlas es excesivamente elevado (no me acuerdo bien como estaba hecho, se me olvidan pasar pruebas que antes tenía claras, etc).

En todo esto siempre surge la misma pregunta: «¿para qué hacer pruebas unitarias?. Yo lo que quiero es tener mi Software ya hecho.».

A veces el tiempo apremia y muchas empresas están dispuestas a sacrificar parte de ese tiempo tan escaso a partes del desarrollo, y una de esas partes son las pruebas unitarias.

¿Con qué choca todo esto?. Con una sola cosa, la mentalidad de que las pruebas unitarias no revierten ningún beneficio ni afecta al ROI en nada más que los costes, cuando esto no es así.
Otra cosa es hacérselo ver a quienes tienen que tomar las decisiones, que ese es otro cantar.

En muy muy pocas empresas en las que he trabajado directa o indirectamente (y son unas cuantas), he podido ver a personas con las ideas claras sobre las pruebas unitarias. En un gran número de casos por no decir casi todos, las pruebas unitarias se entienden como gastos y sólo eso, gastos.

Siempre hago la misma pregunta. ¿Te comprarías un coche que nunca nadie lo ha probado?. Alguien diría, si no se ha probado yo no lo compraría,… pues bien, ese es el principio del ROI en cuanto a pruebas unitarias formuladas como gastos que retornan una inversión indirecta, porque si nadie ha probado nuestro Software… ¿con qué cara se lo instalamos a un cliente o lo vendemos?.

Indudablemente en esto hay una trampa manifiesta, y es que nadie nunca admite cual es la cantidad o calidad de esas pruebas unitarias y la cobertura de las mismas en su Software, y ya no hablemos de otros temas aparte de este hilo y que tienen que ver con las pruebas funcionales, etc.

Quizás en un futuro próximo se obligue al Software a llevar un sellito de «Probado», o como dicen algunas marcas «Testado», pero lo que está claro es que eso hoy por hoy no existe, y mucho menos mientras pensemos que las pruebas unitarias son evitables, que no ahorran tiempo y dinero en cuanto a mantenimiento del Software, que no aportan calidad al Software final o que son chorradas.

Lo único cierto es que nuestra cultura (al menos hablo de España) no está preparada para realizar pruebas unitarias al Software, y cambiar esa mentalidad cuesta más de una úlcera de estómago.

Finalmente y por asociarlo con las pruebas unitarias, nunca olvidaré una de las clases que recibí en la Universidad en la asignatura de marketing. Allí nos comentaban que es
difícil hacer un cliente, pero mantenerlo es más difícil, y perderlo
está chupado. Ahora bien un cliente perdido es casi imposible volverlo a
recuperar. ¿Alguien no se ha comprado «algo», le ha salido mal y no ha
querido volver a comprar esa misma marca nunca más y cada vez que le
pregunta alguien le cuenta su experiencia o dice… «esa marca ni de
coña»?.

Lo único cierto es que esto último que he puesto lo he podido constatar cada día, y aquí simplemente digo: que cada uno en su empresa haga lo que quiera, pero muchas veces no es lo que uno quiere sino lo que a uno le dejan hacer, y ahí es donde muchos desarrolladores nos mordemos las uñas hasta dejarnos los dedos casi pelados.

Yo lo tengo claro, las pruebas unitarias no son una elección y aportan calidad, pero ¿cómo cambiar el hábito y esta mentabilidad al menos a las empresas en España?. Si alguien tiene la fórmula de la coca-cola que la cuente por favor…

Comments

11 Responsesso far

  1. mllopis dice:
    30 septiembre, 2010 a las 8:03 am

    Buenas Jorge,

    Uff! Cuántas cosas que me gustaría comentar tanto en éste como en el otro post que citas, y qué poco tiempo. Dejo una reflexión de 5 minutos…

    Sin tener ni **** idea de cómo se planifican/presupuestan proyectos en «la vida real en España» y sin conocer de primera mano la mentalidad del cliente (aunque, por lo que cuentas tú y otros, me voy haciendo una idea…); ¿no sería mucho más lógico, coherente con la filosofía de un ingeniero (de software) y ético de cara al cliente, vender el software como un «paquete» de funcionalidades/features y realizar cortes en el mismo en sentido vertical (features) en lugar de horizontal (etapas del desarrollo)?

    Es decir, teniendo una lista de 15 funcionalidades que me gustaría que una aplicación tuviera, y considerando los recursos disponibles para este proyecto, sólo soy capaz de implementar con un nivel de calidad superior a los mínimos de calidad que mi empresa (mi marca!) tiene establecidos 12 de dichas funcionalidades. Esto, de entrada, se puede planificar en base a la prioridad de cada una de dichas funcionalidades (especificacion? requisitos? product backlog?) y la experiencia del gestor del proyecto hará que dichas estimaciones iniciales sean más o menos precisas. Posteriormente, quizá podamos añadir 1 ó 2 funcionalidades más, si con el paso de las iteraciones del proyecto vemos que le ganamos tiempo a la agenda del mismo. O quizá, algunas de las funcionalidades que en un principio habíamos acordado, no han llegado a un mínimo de calidad que nos permita sacarlas como parte de este producto… seguimos trabajando en ellas y pronto os llegarán… (Service Packs!).

    Así es, a grandes rasgos y sin entrar en mucho detalle (y por tanto, dejando muchas imprecisiones en el camino), cómo funcionan las empresas con las que he tenido oportunidad de trabajar.

    Una última objeción, quizá no debería hacértela a ti sino a bastante más gente por estos foros, y dicha sin acritud por supuesto: ¿Por qué hay tanta gente que emplea el término «pruebas unitarias» cuando, en realidad, muy pocos de ellos hablan (ya no digo implementan) otros tipos de pruebas? «Unitarias» no es una cualidad inherente al sustantivo «pruebas», ni nosotros somos el poeta Azorín, para emplear sistemáticamente epítetos (la nieve blanca, los verdes prados, las aguas cristalinas…). Esto, si el tiempo lo permite, me da pie a un puñado de posts… A ver si saco tiempo de algún sitio…

    No me déis muchos palos en las respuestas, que ya anticipo que, seguramente, no voy a tener oportunidad de defenderme… : )

    Saludos y a cuidarse,
    M.

    Responder
  2. anonymous dice:
    30 septiembre, 2010 a las 8:07 am

    Si a los gurus y MVPs no les hacen caso en sus empresas, ´como para que nos lo hagan a los del montón…en España estamos perdidos, así nos va…

    Responder
  3. jorge dice:
    30 septiembre, 2010 a las 8:30 am

    @Miguel, no solo no voy a darte yo palos por tu entrada (que de hecho no soy ni quien para hacerlo), sino que entiendo plenamente lo que dices. Por suerte no solo he trabajado en España, también fuera o con empresas de fuera, y lo que indicas de solo «comprometerse» (creo que es la palabra) «a lo que puedes cumplir» (que es el otro matiz) es lo que en España creo que no sabemos hacer (y generalizo sabiendo que hay empresas que sí lo hacen, vaya esto por delante).
    Lo que dices a mí es lo que me gustaría hacer, pero… el día a día es lamentablemente otro en la inmensa mayoría.

    Sobre las pruebas unitarias, totalmente de acuerdo en que no es lo último. Me he centrado en ellas por el post de David, pero en mi entrada hablo también de otras pruebas como las funcionales, etc… es decir, las únicas pruebas y válidas NO son las unitarias, son unas pruebas más de todas las que hay que hacer, pero esto como dices es para otra entrada que pensaba escribir más adelante.

    No obstante, espero que saques tiempo para hacer tú una entrada de estos temas, porque realmente en la diversidad de opiniones o en las experiencias y puntos de vista de cada uno, nos enriquecemos más.

    Muchas gracias por opinar. 🙂

    Responder
  4. jorge dice:
    30 septiembre, 2010 a las 8:36 am

    @pregunton cojonero, te lo digo totalmente como lo pienso, no es cuestión de MVPs o gurús (lo primero lo soy todavía hoy, sobre lo segundo no me considero entrar en ese grupo igual que tampoco admito para nadie la palabra experto) es cuestión de mentalidad.
    En España (en mi modesta opinión) hay esa mentalidad, por lo menos en cuanto al desarrollo del Software. En otras empresas o actividades industriales, si les dices que podemos ahorrar en pruebas directamente te echan o te dicen si estás loco, pero en Software no porque se piensa como un gasto sin retorno de inversión.
    ¿Cómo cambiar esta mentalidad?. No es una batalla perdida, pero sí de desgaste y de generar muchas úlceras estomacales. 🙁

    Responder
  5. etomas dice:
    30 septiembre, 2010 a las 9:00 am

    Buenas,
    Interesantes reflexiones…
    A ver por partes… 😉

    Empecemos por las pruebas unitarias: Yo creo que no debería ser necesario decir a un cliente que vamos a realizar pruebas unitarias. Para empezar a realizarlas debes estar convencido de que son necesarias y por lo tanto que las usas sí o sí. Forma parte de tu forma de trabajar y el cliente no tiene porque saber eso.
    En este caso, si el cliente te pide valoración tu ya contarás el tiempo necesario para implementar las pruebas unitarias. El cliente no tiene porque conocer que un % de tu tiempo de desarrollo es de pruebas unitarias.
    Evidentemente, siempre puede haber un competidor que valore lo mismo que tu en menos tiempo/más barato: Luego te toca «convencer» al cliente argumentando otras cosas… 🙂 Sí, ya se que es dificil…

    Resto de pruebas (llamésmolas integración, funcionales, carga, stress, UATs).
    Estas si que suelen tener una visibilidad y ahí si que muchas veces se choca con que el cliente las ve como «costos», en lugar de como ahorro.
    Ahí si que en muchas empresas hay resistencia a realizar las pruebas: nos toca explicar mejor las ventajas, que aunque para nosotros sean evidentes para quien paga pueden no serlo tanto.

    @Miquel
    Tu planetamiento es realmente bueno. Pero con muchos clientes simplemente no se puede trabajar así: no les hables de que algunas funcionalidades vas a sacarlas a posteriori, porque el te dirá que quiere todo su proyecto. Hay clientes con mentalidades muy cerradas. No les expliques que iremos implementando cosas en base a sus prioridades y que iremos reestimando según vaya el tiempo, porque directamente no quieren ni oírlo.
    Aquí como proveedor tienes dos opciones: tragar y trabajar con ese cliente, o ir a por otro cliente que entienda mejor como deben ser las cosas… Bueno, a veces puedes «buscar» dentro del cliente a alguien con mentalidad más abierta y que actúe de sponsor de esa manera de pensar, pero para lo bueno y para malo (y hay más de malo que de bueno) «this is spain».

    Saludos! 😉

    Responder
  6. jfortes dice:
    30 septiembre, 2010 a las 10:30 am

    Hola,

    este es un asunto que genera siempre mucha polémica, en mi opinión Eduard da en el clavo con:

    «Empecemos por las pruebas unitarias: Yo creo que no debería ser necesario decir a un cliente que vamos a realizar pruebas unitarias. Para empezar a realizarlas debes estar convencido de que son necesarias y por lo tanto que las usas sí o sí. Forma parte de tu forma de trabajar y el cliente no tiene porque saber eso.

    En este caso, si el cliente te pide valoración tu ya contarás el tiempo necesario para implementar las pruebas unitarias. El cliente no tiene porque conocer que un % de tu tiempo de desarrollo es de pruebas unitarias.»

    En mi opinión, en las estimaciones de un proyecto pueden (y deben) ir incluidas las pruebas, no ya las unitarias sino toda la batería de pruebas y validaciones que debe pasar el software para asegurar su calidad. Posiblemente la mejor manera de incluir este tiempo en un proyecto es simplemente presupuestarlo como parte integral del mismo.

    Como bien dice Eduard, a un cliente no hay por qué desglosarle que dentro de la fase de desarrollo están incluidos ciertos tipos de pruebas, es que para mi eso es desarrollo como lo es la instrumentación de la aplicación, punto. El desarrollo tarda tanto tiempo con tantos recursos y cuesta esto. Hasta ahí llega el conocimiento de la gente externa al proyecto y de puertas adentro en la fase de desarrollo hay lo que tenga que haber.

    Se han puesto ejemplos de otras disciplinas, supongo que cuando un ingeniero de obras públicas presupuesta una obra tiene en cuenta sus pruebas y verificaciones de calidad de manera integral y transversal en el proyecto, sin especificarle al cliente cuántos segundos exactos se va a dedicar a eso dentro de la fase X, forma parte del proyecto.

    Dicho esto, la pega fácil que se le puede poner es que vas a ser más caro que tu competencia por dedicar más tiempo/esfuerzo. Esto ya es matizable y no necesariamente cierto, pero ya no es una cuestión técnica, es una cuestión de filosofía de la empresa. Se trabaja poniendo el acento en entregar software de calidad, por encima de la media, sólido y que atraiga a clientes en el futuro o se apuesta por fabricar churros que en cuanto no exploten demasiado se liberan y a facturar…

    Este es un tema de estrategia empresarial, no técnico y ahí es donde mucha gente técnica encontrará sus dilemas morales sobre cómo se hacen las cosas en muchas empresas cuando esa persona piensa que deberían hacerse de otra manera.

    En España hay de ambas, tal vez los porcentajes de cada tipo es lo que alarma un poco.

    Responder
  7. jorge dice:
    30 septiembre, 2010 a las 11:24 am

    @José, sí y no a lo que comentas y que cita @Eduard. Me explico:
    Creo que debemos diferenciar entre clientes internos o clientes finales y consultoras. Cada uno de ellos actúa de forma dispar.
    En todos ellos no obstante hay una máxima y es que cuanto más detallado quede todo mejor, o al menos, en cuestiones financieras es así y se pide todo lo más detallado posible. Otra cosa es que haya empresas de todo tipo y pasen de esto, pero lo normal debería ser así. Es lo que podríamos llamar como control del gasto… en otras palabras, a donde va mi dinero como empresa, donde lo gasto, donde lo invierto,… que hago con él.
    Si inicias un proyecto y no detallas las pruebas, y tu coste es 1000, otra oferta u otra empresa podrá ganar el concurso poniendo 650 por ejemplo, y con esto no digo que el de 650 fuera mejor, sino que si se detallara justificaría porqué coger la de 1000 en lugar de la de 650 pese a que sea más cara. Si pones una partida general de desarrollo sin especificar, corres el riesgo de que no se valore todo el trabajo que se está llevando a cabo, o dicho de otra manera, que no se justifique correctamente el gasto. También podrías poner una partida del tipo Desarrollo + Pruebas, pero te aseguro que la mayoría de las ocasiones te pedirán especificar con concreción cada una de ellas.
    A la hora de asumir y analizar gastos la cosa se complica, y eso… queramos o no, llega al equipo de desarrollo, a veces por medidas impuestas y otras porque sino el proyecto no sería «rentable» (y pongo rentable entre comillado por la cantidad de variables que conlleva).
    ¡Muchas gracias por opinar! 🙂

    Responder
  8. jfortes dice:
    30 septiembre, 2010 a las 1:14 pm

    @Jorge, desde luego, estoy al tanto de ese tipo de cuestiones y con eso en mente he escrito el comentario.

    A nivel interno es una cosa y externo es otra a nivel de detalle, seguro que en eso estamos de acuerdo, y me refería en mi comentario anterior a la pata externa en ese caso.

    Una fase de desarrollo y pruebas es muy común en una oferta a un cliente, sin detallar al centímetro cómo se va a desgranar dicha fase, no especificas cuánto se va a dedicar a instrumentación, por ejemplo, otra cuestión que podría ser polémica para un cliente, decía antes.

    Iba a escribir algo más pero me doy cuenta de que lo podemos hablar mañana en el TTT, con lo que mejor podemos seguir hablando allí 🙂

    Responder
  9. jorge dice:
    30 septiembre, 2010 a las 2:18 pm

    Genial José. 🙂
    Aunque apuesto lo que sea a que todos estamos de acuerdo y en desacuerdo al mismo tiempo, porque los matices son miles. 🙁

    Responder
  10. lontivero dice:
    2 octubre, 2010 a las 1:39 am

    Jorge, negociar las pruebas unitarias es negociar calidad. Hay quienes creen que se la puede negociar y otros piensan que no, yo estoy entre los segundos. Es una práctica de ingeniería y no debería discutirse con clientes.
    En mi última entrada sobre este tema puse links a unos papers sobre la efectividad de TDD en algunas empresas: en IBM (en un projecto) redujeron la tasa de defectos en un 91%.
    En otro, los resultados del estudio indicó que la densidad de defectos de 4 productos decreció entre un 40% y un 90% relativo a projectos similares en los que no se utilizó TDD, esto a un costo de entre un 15% y un 35% más en el esfuerzo de desarrollo.

    Con estos números en la mano, la negociación podría ser distinta.

    Responder
  11. msierra dice:
    3 octubre, 2010 a las 12:32 am

    Parece que como informáticos que somos somos muy «BINARIOS», hacer o no hacer pruebas unitarias, esa es la cuestión, ya que eso implica un coste. Habéis hablado de dinero, de costes, de ROI… yo creo que las pruebas aportan calidad interna al producto, y hay que ofrecer la calidad justa y necesario, es decir, lo que el presupuesto permita. Entiendo que deberemos de alguna manera indicar ese nivel de pruebas en función de la cobertura de código, ¿no? … habrá algún proyecto que por su naturales y características, únicamente tenga un 10% de cobertura y otro del 80%.
    En cualquier caso si descuidas la calidad a la larga lo pagas y el coste de cubrir garantías es mayor que el coste de establecer una buena política de pruebas unitarias e IC. Veáse la gráfica «cost of fixing bug»:
    http://www.developertesting.com/archives/month200501/20050127-TheDeveloperTestingParadox.html

    Responder

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.