El examen 70-519 es parte del camino para la MCPD (Microsoft Ceritified Professional Developer). Al ser un examen nuevo no existen aun materiales programáticos para prepararlo. Encontraremos material en el examen 70-562 TS: Microsoft .Net Fameqork 3.5 Asp.Net development, (hay que tener en cuenta que este examen era relacionado al framework 3.5 y se utilizaba la version 2008 del VIsual Studio, mientras que el que voy a preparar utiliza el framework 4 y la version 2010 del Visual Studio)
Por ser un examen beta tengo chance para rendirlo hasta el 30 de abril, pero lo schedulee (valga el anglicismo) para el 20 de abril. Con lo que empecemos.
Guia
| Designing the Application Architecture (19%) -
Plan the division of application logic.
This objective may include but is not limited to: choosing between client-side and server side processing, planning separation of concern, (for example, partitioning functionality between controllers and evaluating business and data service consumption), planning for long-running processes (for example, synchronous vs. asynchronous) - Analyze requirements and recommend a system topology.
This objective may include but is not limited to: designing interaction between applications, mapping logical design to physical implementation, validating nonfunctional requirements and cross-cutting concerns (for example, communications, operations management, and security), evaluating baseline needs (for example, scale and quality of service) - Choose appropriate client-side technologies.
This objective may include but is not limited to: JavaScript, ASP.NET AJAX, jQuery, Microsoft Silverlight - Choose appropriate server-side technologies.
This objective may include but is not limited to: user controls, server controls, partials, custom HtmlHelper extensions, Web parts, inheriting controls, dynamic data controls - Design state management.
This objective may include but is not limited to: designing an application for the proper use of application state, session state, and request state (for example, ViewState, ControlState, Cache object, cookies, and client-side persistence) Designing the User Experience (17%) -
Design the site structure. This objective may include but is not limited to: designing application segmentation for manageability and security (for example, using areas, shared views, master pages, and nested master pages), appropriate use of style sheets, client-side scripting, themes, client ID generation, rendering element modes, routing engine -
Plan for cross-browser and/or form factors. This objective may include but is not limited to: evaluating the impact on client side behaviors, themes, bandwidth, style sheets (including application design - task based or scaled rendering of existing page), when to apply Browsers file, structural approaches, user agents, different platforms (mobile vs. desktop) -
Plan for globalization. This objective may include but is not limited to: designing to support local, regional, language, or cultural preferences, including UI vs. data localization (for example, implementing at database level or resource level), when to use CurrentCulture vs. CurrentUICulture, globalization rollout plan (for example, setting base default language, planning localization), handling Unicode data (for example, what fields to include, request encoding), right-to-left support, vertical text and non-Latin topographies, calendars, data formatting, sorting Designing Data Strategies and Structures (18%) -
Design data access. This objective may include but is not limited to: choosing data access technologies such as ADO.NETData Services, Entity Framework, Windows Communications Foundation (WCF), and ASP.NET Web Services -
Design data presentation and interaction. This objective may include but is not limited to: pulling data from data layer and binding into views, pages, and controls, and pulling data back to data layer by using ModelBinders, data source controls, and HtmlHelper extensions, or programmatically -
Plan for data validation. This objective may include but is not limited to: contextual validation vs. data integrity, where to validate data, synchronization between UI and data layer, data annotations Designing Security Architecture and Implementation (17%) -
Plan for operational security. This objective may include but is not limited to: approaches for process- and resource-level security, including local and remote resources, Code Access Security (CAS), including trust level, process identity, application pool, and identity tag -
Design an authentication and authorization model. This objective may include but is not limited to: authentication providers, including WindowsForms, and custom user identity flowthrough (for example, trusted subsystem), role management, membership providers, URL authorization (for example, AuthorizationAttribute), file authorization, Authorization Manager (AzMan) -
Plan for minimizing attack surfaces. This objective may include but is not limited to: input validation, throttling inputs, request filtering, where to use Secure Sockets Layer (SSL) Preparing For and Investigating Application Issues (15%) -
Choose a testing methodology. This objective may include but is not limited to: black box, white box, integration, regression, coverage, API testing, performance testing, security testing
This objective does not include: load testing, Web testing, unit testing -
Design an exception handling strategy. This objective may include but is not limited to: HandleError attribute in MVC, common error pages, post-error processing, global vs. page level -
Recommend an approach to debugging. This objective may include but is not limited to: tools and approaches for a given scenario (for example, memory dumps, DebuggingAttributes, crashes vs. hangs, deadlocks, assembly binding), when to attach to process (Visual Studio Development Server vs. IIS vs. Internet Explorer), root cause analysis This objective does not include: basic breakpoints -
Recommend an approach to performance issues. This objective may include but is not limited to: which instrumentation to watch or create (including performance counters and event tracing) to analyze performance issues, page and fragment caching Designing a Deployment Strategy (14%) -
Design a deployment process. This objective may include but is not limited to: Windows Installer (MSI) vs. xcopy vs. Web Deployment Tool, scaling, rolling deployments -
Design configuration management. This objective may include but is not limited to: using the ConfigSource attribute (for example, connection strings), staging vs. production vs. development, topologies, machine.config vs. web.config, using IIS vs. Visual Studio Development Server during development, application pools, configuration inheritance -
Plan for scalability and reliability. This objective may include but is not limited to: scaling up, scaling out, at physical level and at architectural level, impact of offloading technologies on load balancing, including state, synchronizing machine and encryption keys -
Design a health monitoring strategy. This objective may include but is not limited to: when to monitor application or business-related events (e.g., on UI every time clicked or in business layer), determining a strategy for using ASP.NET Health Monitoring, throttling, filtering, delivery method |
Materiales
Indispensable. Visual Studio 2010 profesional o superior. Se puede bajar el RC.
MSDN y seleccionar las opciones de .Net Framework 4
Material de Microsoft Learning no hay disponible aun.
Material bibliográfico Self-Pace Training Kit. Para el framework 3.5 (verificar las diferencias)
Diferencias entre los frameworks
En MSDN y en StackOverflow
Al parecer un gran mercado se está moviendo en éste sentido. Y a pesar de todas las posibilidades que brindan los dispositivos actualmente para acceder a internet, que tal si queremos realizar una aplicación para los dispositivos?
Voy a fijarme un poco en lo que son los principales SO para dispositivos móviles (por favor, favoritismos aparte, pude olvidarme de algunos, por ejemplo Symbian o Blackberry, sólo quiero hacer una enumeración general).
Windows mobile
Windows mobile es una plataforma conocida (al menos para mi), casi cualquier programador .Net (a mi juego me han llamado) a jugado alguna vez con el .Net Compact Framework. El desarrollo desde el Visual Studio es muy sencillo, en la parte 2 del post voy a incluir un ejemplo sencillo.
Android
El SO Android, un proyecto de la Open Handset Alliance, es un desarrollo Open Source de Google. Aunque actualmente sólo existe un teléfono, HTC G1, es probable que el 2009 veamos una explosión (a al menos varios modelos).
Para desarrollar una simple aplicación (el ejemplo provisto con el SDK de Android es HelloAndroid) me tuve que meter en un mundo poco conocido por mí, y debo decir que quedé gratamente sorprendido.
Bajé el Eclipse, el SDK de Android, instalé el Eclipse, que anduvo sin problemas desde el primer momento, instalé el plugin para el desarrollo de Android en el Eclipse. Y voilá, ya estamos funcionando. Debo decir que además de que en 15 minutos estaba funcionando no tuve que regsitrarme en ningún sitio!
En el segundo post de la serie voy a mostrar el ejemplo desarrollado, pero mientras tanto les dejo una imagen del emulador con mi aplicación (HelloAndroid) funcionando.
Apple IPhone
El desarrollo para el IPhone, es otro tema. Para este caso tenemos que registrarnos, debemos utilizar las herramientas provistas por Apple (esto es similar en todos los casos), utilizar ObjetiveC como lenguaje (a leer!) y si queremos participar del mundo de las aplicaciones para IPhone (aunque no querramos lucrar) tenemos que participar del IPhone Developer Program que tiene costo.
Tal vez pueda hacer algo en éste terreno también.
Primera conclusión
Hay un mercado muy interesante para aplicaciones para dispositivos móviles, y además resulta muy interesante ver como la interacción con otras cosa que nos resultaban inimaginables en el desarrollo para desktop o para web, como por ejemplo la interacción con GPS, acelerómetros, voz, cámáras, etc. generan un montón de posibilidades para los que nos gusta jugar!. Como ejemplo se pueden ver miles de aplicaciones locas e interesantes para el IPhone en el repositorio de ITunes o los resultados del Android Development Challenge de Google.
Tecnologías
CC.Net / Subversion/ TortoiseSVN / Commit Monitor / AnkhSVN /VS 2008 / Resharper /TestDriven / NUnit / Watin / TDD
Un poco de historia
Años atrás (y lamentablemente lo seguimos viendo), desarrollábamos aplicaciones en forma colaborativa. Nos íbamos pasando desarrollos entre programadores y de ésta forma íbamos sumando desarrollo y entregando al cliente. El proceso del desarrollo del software ha dejado de ser un insight artesanal para convertirse en un proceso ingenieril (sin embargo es interesante escuchar el panel de cierre de Ágiles 2008, donde entre otros Mary Poppendieck y Micah Martin proponían volver al craftsman, al artesano).
Cuantas veces escuchamos la famosa frase ¨En mi máquina funciona¨. Para eliminar estas problemáticas debemos utilizar distintas sencillas prácticas que nos permitirán armar un ambiente de desarrollo tal que no tendremos que preocuparnos por esos viejos problemas.
Repositorio
El repositorio nos permite mantener la información centralizada, mantener log, generar tags/branchs, volver a revisiones anteriores, etc.
Nosotros utilizamos Subversion y para el ejemplo que vamos a realizar crearemos un repositorio en code.google.com que nos provee como repositorio SVN.
Para administrar el repositorio en forma local utilizamos TortoiseSVN, que nos integra el manejo de la copia en checkout del repositorio local con el explorer de Windows.
AnkhSVN nos realiza la integración del Subversion en Visual Studio.
Existen otras opciones que iremos analizando, mientras tanto se puede ver este artículo.
TDD
Nuestra forma de trabajar está basada en TDD (Test Driven Development). Hay mucho para investigar sobre el tema. Lo único que proponemos aquí es tener en cuenta el patrón RED, GREEN, REFACTOR. Esto es realizamos el test necesario para verificar una funcionalidad que estamos agregando a nuestra aplicación. Al no estar desarrollado el código que satisface el test, el mismo va a fallar por el motivo esperado, estaremos en rojo. Se realiza el código que satisface el test, por lo tanto estaremos en verde. por último realizamos el refactor, que nos permitirá eliminar código repetido, innecesario, etc. Volvemos a probar los test que deberán seguir en verde.
Las herramientas que utilizamos son NUnit como framework de tests. Y para ejecutarlos desde el ambiente de Visual Studio utilizamos ReSharper (que también nos provee muchísima otra funcionalidad espectacular, es adictivo!) o TestDriven, un plugin gratuito.
CruiseControl
Cada desarrollador trabaja en una copia local del repositorio y realiza las modificaciones necesarias, en el momento que ha finalizado alguna parte de una tarea que se encuentra funcional decide subir al repositorio. Para ello verifica que su aplicación compile, corre los test unitarios y de aceptación que corresponden y luego realiza commit al repositorio (si es necesario llevar un control en tiempo real de los commits se puede recurrir al Commit Monitor) .
Una vez que se sube al repositorio, contamos con el CruiseControl .Net que es el encargado de realizar las mismas tareas en el ambiente de integración.
Decargará todo lo necesario del repositorio, verificará triggers, colas, prioridades, realizará las tareas de compilación, correrá test unitarios, test de aceptación, puede correr aplicaciones de verificacion como el FXCop, NCover, NDepend, etc.
Recién luego de todas éstas tareas estamos seguros que tenemos una aplicación integrada correctamente.
Existe una herramienta complementaria CCTray, que nos permite ver en el Tray el estado en que se encuentra la integración de la aplicación en forma constante. Es necesario tener reglas claras para mantener el repositorio en verde constantemente.
Watin
Este framework nos permite realizar test contra la web. Utilizamos nosotros esta herramienta dado que nos permite realizar tests unitarios (usando NUnit) por medio de COM obtenemos una instancia del browser y probamos la funcionalidad , no sólo, el alcance de nuestras interfaces. Esto también lo integramos al CC y lo verificamos en un night test.
Comentarios
Espero recibir comentarios, es sólo una forma de trabajar. Espero poder ampliarlo con ejemplos de cada una de las aplicaciones. para primer post está bien!
Entradas
