Ir al contenido principal

Política de Privacidad

Última actualización: 29 de enero de 2025

Esta Política de Privacidad describe nuestras políticas sobre la recopilación, uso y divulgación de información en relación con el uso de este blog.

"En Materia: Programación .NET" no recopila ni solicita datos personales de los usuarios. Sin embargo, este blog está alojado en la plataforma Blogger, propiedad de Google, quien puede utilizar cookies y tecnologías de seguimiento con fines publicitarios, estadísticos y de optimización del servicio.

Interpretación y Definiciones

Interpretación

Las palabras con la primera letra en mayúscula tienen el significado definido en las siguientes condiciones. Estas definiciones tendrán el mismo significado independientemente de que aparezcan en singular o plural.

Definiciones

Para los fines de esta Política de Privacidad:

  • Blog: Se refiere a "En Materia: Programación .NET", accesible desde https://programaciondotnetdb.blogspot.com/.
  • Google: Se refiere a Google LLC, propietario de la plataforma Blogger donde está alojado este blog.
  • Cookies: Pequeños archivos que se almacenan en su dispositivo y que pueden ser utilizados por Google para recordar preferencias, mostrar anuncios personalizados y analizar el tráfico del blog.
  • Usted: Se refiere al usuario que accede y navega en este blog.

1. Recopilación de Datos

"En Materia: Programación .NET" no recopila datos personales de los usuarios ni solicita información de ningún tipo.

Sin embargo, dado que el blog está alojado en Blogger (Google), Google puede recopilar información automáticamente mediante cookies y tecnologías de seguimiento.

Datos que Google puede recopilar automáticamente:

  • Dirección IP y tipo de navegador.
  • Páginas visitadas dentro del blog.
  • Tiempo de permanencia en cada página.
  • Ubicación aproximada basada en la IP.
  • Datos sobre cómo interactúa con los anuncios, si están activados.

Para más detalles sobre cómo Google maneja los datos de los usuarios, puede revisar su Política de Privacidad en:
https://policies.google.com/privacy

2. Uso de Cookies y Tecnologías de Rastreo

Este blog no instala cookies propias ni usa herramientas de rastreo personalizadas, pero Blogger (Google) puede colocar cookies con fines de análisis y publicidad.

Si desea deshabilitar las cookies, puede hacerlo desde la configuración de su navegador. También puede administrar sus preferencias de anuncios en Google Ads desde:
https://adssettings.google.com/

3. Enlaces a Otros Sitios Web

Este blog puede contener enlaces a sitios externos. No nos hacemos responsables de sus políticas de privacidad, por lo que recomendamos leerlas antes de interactuar con esos sitios.

4. Cambios en esta Política de Privacidad

Nos reservamos el derecho de actualizar esta política en cualquier momento. Cualquier cambio será publicado en esta página con la fecha de actualización correspondiente.

5. Contacto

Si tiene preguntas sobre esta Política de Privacidad, puede contactarnos a través de nuestro blog en:
https://programaciondotnetdb.blogspot.com/

Resumen en términos sencillos:

No recopilamos información personal ni pedimos datos a los usuarios.
Google puede usar cookies para analizar el tráfico y mostrar anuncios.
Los usuarios pueden gestionar las cookies desde la configuración de su navegador.

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...
Más entradas »

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...
Más entradas »

Guía Completa para Crear un README.md Profesional en GitHub

¿Qué es un README.md y por qué es importante? El archivo README.md es la primera impresión que un desarrollador obtiene al visitar un repositorio en GitHub que hayas creado. Sirve como documentación principal de un proyecto, proporcionando información sobre su propósito, estructura y uso. Un README.md bien elaborado puede mejorar la comprensión del proyecto, facilitar la colaboración y también atraer contribuyentes. Estructura recomendada de un README.md Una estructura comúnmente utilizada para hacer que tu README.md sea claro, informativo y atractivo: 1. Título y Descripción El título debe ser claro y descriptivo. Pensalo también, como un término de búsqueda que alguien podría buscar en Google. Luego, una breve explicación del proyecto: # Nombre del Proyecto Una breve descripción sobre qué hace tu proyecto. 2. Insignias (Badges) Podés agregar insignias para indicar el estado del build, cobertura de pruebas, licencias, entre otros: !...
Más entradas »

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Más entradas »

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...
Más entradas »

Principio de Inversión de Dependencia (DIP) – SOLID explicado con ejemplos

Estamos cerrando este ciclo de definiciones para SOLID , y en esta entrada vamos a dar un vistazo al último principio de la lista: DIP o Dependency Inversion Principle . El Principio de Inversión de Dependencia (DIP) establece que: Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones. El Problema de la Dependencia Directa Imaginate que estás construyendo una aplicación que envía notificaciones. Para empezar rápido, decidís crear un controlador que usa directamente un servicio de correo electrónico: public class NotificationController { private EmailNotificationService _service = new EmailNotificationService (); // Acá tenemos dependencia directa } Al principio, todo parece estar bien. El controlador puede enviar correos sin problema. Pero luego surge un requisito: ta...
Más entradas »