martes, 29 de enero de 2013

Visual SourceSafe (VSS)

Con VSS podemos controlar las versiones que forma parte de Visual Studio, en la actualidad esta tecnología es sustituído por Team Foundation Server.

Para trabajar con VSS, debemos configurar un servidor con los requerimientos mínimos para instalar Visual Source Safe, luego debemos establecer el repositorio que será nuestro proyecto. Cada cliente podrá descargar y trabajar con una copia de trabajo (check-out o desproteger), realizar los cambios y volver a subir o proteger los archivos trabajados al repositorio.

Una  desventaga de VSS es que usa protócolo SMB, donde el compartir archivos pueda resulta lento. VSS es inestable con archivos binarios de grán tamaño, ya que espera sólo fiches de texto, por lo tanto no vale para guardar documentación sólo código fuente.

Pasos para descargar una versión de un proyecto

Cuando usted haya establecido y ordenado los proyectos en VSS podrá descargar una copia y trabajar con ella en cada cliente.

FOTO1


  • Cree un nuevo proyecto vacio, si es un proyecto de clases, asp.net, etc.
FOTO2
  • Si usted instaló VSS de manera satisfactoria, verá una opción en el menú Archivo de Visual Studio .NET, seleccione cambiar control de código fuente.
FOTO3
  • Enlace el proyecto creado con el proyecto del repositorio en VSS.
FOTO4

FOTO5



  • Seleccione la carpeta donde está el proyecto a enlazar.

FOTO6

  • Luego de agregar y enlazar el proyecto, puede descargar la última versión haciendo clic derecho y pulsando la opción "Obtener última versión"

FOTO7
  • Cuando usted realice cambios o modificaciones en su código fuente, debe actualizar sus cambios al repositorio de VSS, para ello haga clic derecho sobre el archivo, carpeta o proyecto y seleccione "Proteger", tal como se muestra en la siguiente imagen.
FOTO8

jueves, 28 de abril de 2011

CONCEPTOS BASICOS .NET DE MVA

Acontinuación describiré los enlances donde existe los materiales de estudio para el aprendizaje de la programación en .NET difundidos por MVA (Microsoft Virtual Academy).

Programación Orientada a Objetos

martes, 1 de marzo de 2011

5 PRINCIPIOS DE DISEÑO ORIENTADO A OBJETOS - SOLID

 SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion
Son principios de diseño orientado a objetos que aplicados se permite la creación de sistemas fácil de mantener y extender su código. Permite al equipo tener fácil entendimiento del diseño y reutilizar código.

itialStands for
(acronym)
Concept
SSRP
Single responsibility principle
the notion that an object should have only a single responsibility.
OOCP
Open/closed principle
the notion that “software entities … should be open for extension, but closed for modification”.
LLSP
Liskov substitution principle
the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract.
IISP
Interface segregation principle
the notion that “many client specific interfaces are better than one general purpose interface.”[5]
DDIP
Dependency inversion principle
the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”[5] Dependency injection is one method of following this principle.


1.- Principio de responsabilidad única (I) 
Comenzamos con el Principio de Responsabilidad Única, una de las bases fundamentales sobre la programación oriendada a objetos.Entrar

2.- Principio de responsabilidad única (II)
Continuamos con el Principio de Responsabilidad Única, una de las bases de la programación oriendada a objetos. Entrar
3.- Principio Open/Closed (I)
Este es el segundo de una serie de cinco principios SOLID y su aplicación en la Programación Orientada a Objetos. Entrar
4.- Principio Open/Closed (II)
Continuamos con el segundo principio SOLID sobre la Programación Orientada a Objetos. Entrar
5.- Principio de Sustitución de Liskov
Tercer principio de programación SOLID. En esta ocasión presentamos los fundamentos del Principio de Sustitución de Liskov y cómo la aplicación de este principio tiene una repercusión directa sobre las jerarquías de herencia entre clases. Entrar

6.- Principio de Segregación de Interfaces
Principio de Segregación de Interfaces (Interface Segregation Principle, ISP), que trata sobre las desventajas de las interfaces "pesadas" y guarda una estrecha relación con el nivel de cohesión de las aplicaciones. Entrar
7.- Inyección de Dependencias
Como colofón de la serie de cinco artículos dedicados a los principios SOLID, en esta ocasión toca hablar del Principio de Inyección de Dependencias (Dependency Inyection, DI). Entrar