tutorial online gratis caracteristicas sharepoint

online - ¿Cuál es el perfil de un desarrollador de SharePoint?



sharepoint tutorial (7)

Tengo un equipo de desarrollo especializado en ASP.NET. Entonces, las soluciones que proporcionamos están basadas en la web, se ejecutan en IIS y usan el servidor MS SQL. Todo dentro de la intranet de la empresa. El equipo tiene esta experiencia, y son excelentes en C # y .Net en general.

La compañía está implementando SharePoint MOSS 2007. Esta implementación forma parte de un proyecto en el que no participo y del que tengo muy poca información. Sin embargo, sé que han establecido la capa de "pensadores" (los que dirán qué hacer), la capa de integraciones (quién configurará, implementará y gestionará la producción) y que necesitan establecer la llamada capa de desarrollo ( aquellos que harán las cosas los otros dos no pueden).

Se me pide que evalúe la posibilidad de aumentar la experiencia de mi equipo al agregar el desarrollo de SharePoint. Esta es la parte fácil, solo tengo que encontrar la capacitación requerida y enviar a mi gente.

Sin embargo, en la actualidad, el desarrollo de la palabra puede significar muchas cosas y, a veces, descubro que la configuración se usa en lugar del desarrollo. No tengo ninguna objeción para hacer evolucionar al equipo desarrollando nuevos conocimientos, pero quiero asegurarme de que todo sea estimulante para mis desarrolladores. En segundo lugar, no quiero decir que tenemos experiencia en el desarrollo de SharePoint, y en realidad lo que hacemos es simplemente modificar archivos css o xml. Además, no creo que el uso de asistentes para producir una solución sea el mejor camino para impulsar a un desarrollador de C # a seguir.

Las preguntas que me hago primero es: ¿cuál es el trasfondo de un desarrollador de SharePoint? ¿Cómo podrían los desarrolladores de .Net sentirse solicitados para convertirse en desarrolladores de SharePoint?

Cualquier pensamiento será muy apreciado.

Empecé en el desarrollo Sharepoint hace más de un año cuando heredé una solución WSS 3.0 en mi empresa.

Personalmente, creo que fue un gran paso para conocer un poco el desarrollo de Sharepoint, hay muchos problemas (por ejemplo, seguridad, equilibrio de carga, fantasmas) que fue bueno para ver cómo fue resuelto por el equipo de WSS y me ayuda a resolver problemas en otras soluciones en las que estoy trabajando. Pero no trabajo en soluciones de WSS a tiempo completo, por lo que otros tienen que saber cómo funciona con WSS todos los días.

WSS y Sharepoint son una extensión de la plataforma ASP.NET, por lo que cualquier experiencia en ASP.NET y .NET en general debería ser una buena base para un desarrollador que está comenzando a crear soluciones Sharepoint. Leí el libro Inside Microsoft Windows Sharepoint Services 3.0 para obtener los conceptos básicos y la arquitectura de solución wss antes de comenzar a trabajar en proyectos de WSS.

Descubrí rápidamente que tiene que tener un entorno de máquina virtual para el desarrollo de Sharepoint, esto es porque es un dolor trabajar en un cliente y conectarse a un proceso remoto en el servidor para entrar en modo de depuración. Por lo tanto, recomiendo crear una máquina virtual MOSS que tenga instalado Visual Studio que tenga acceso a su sistema de control de origen. Desarrolle soluciones en esa máquina y cuando finalice, controle el control de la fuente.

También recomiendo mirar las herramientas de desarrollo, como stsdev y wspbuilder para ayudarlo a construir su solución, esto le facilitará bastante el proceso de desarrollo. También hay muchas herramientas disponibles en la web, por ejemplo codeplex para ayudarte.

A veces puede ser complicado desarrollar estas soluciones, los cambios pueden requerir el reciclaje del conjunto de IIS o un IISReset de fuerza bruta, los mensajes de error a veces pueden ser crípticos, etc. Pero rápidamente te das cuenta y sabes dónde mirar. Sharepoint también te ayuda mucho, he tenido millones de preguntas de clientes que se pueden resolver con piezas web estándar, para que no tenga que codificar nada para mantener contentos a mis clientes :)

Sharepoint también espera que las soluciones se codifiquen de cierta manera, p. Ej., 12 archivos de la estructura de la colmena, por lo que le ayuda a estandarizar sus soluciones.

Hay una gran falta de documentación, por lo que debe confiar mucho en Reflector y esas herramientas, solo para saber qué está sucediendo en el marco, ojalá esto mejore con 2010.

La curva de aprendizaje inicial es alta y hay muchos conceptos nuevos y tecnologías para aprender, por ejemplo, flujos de trabajo dentro de sharepoint, características, fantasmas y seguridad de acceso a código. Hay mucha configuración Xml que usa sharepoint que los desarrolladores deben aprender, esto incluye el sitio definición, plantillas de listas y más. A veces hay días en los que estoy atascado en el modo de edición Xml y no puedo entender por qué las cosas no funcionan como deberían.

Estos son solo algunos de mis pensamientos, he estado trabajando principalmente en el desarrollo de WSS y sería genial si alguien pudiera comentar sobre la configuración de los elementos web en Sharepoint, por ejemplo, configurando la búsqueda. Que es algo que no he estado haciendo mucho.

Es bueno ver que notó que Dev y Admin estaban siendo utilizados "incorrectamente".

Aunque Developing for SharePoint podría ser solo eso, desarrollo, como la creación de partes web, etc., le recomiendo encarecidamente a usted y a su equipo que se familiaricen con la implementación, instalación y configuración de SharePoint también. Estoy completamente certificado por SharePoint (WSS Config / Dev y MOSS Config / Dev) y tener conocimiento de ambos extremos ha sido invaluable para mí.

Saber qué está configurado donde ayudará a la depuración y solución de problemas en el camino. Sugiero tomar una capacitación de configuración MCS WSS 3.0 / o una capacitación de Configuración MOSS para al menos 1 o 2 de su equipo. El resto del equipo recogerá los elementos esenciales a medida que avanzan, teniendo esos 2 colegas certificados como ir a los chicos con respecto a la configuración y la administración.

En mi humilde opinión, ser un consultor de Sharepoint implica saber cómo crear una pieza de funcionalidad como desarrollador y luego ser capaz de implementar, configurar y mantener esa función como administrador (o al menos un usuario informado / experto).

Según lo que he escuchado, el SharePoint es una tecnología popular desde el punto de vista del cliente, pero un objeto de odio entre los desarrolladores.

Mi compañero de trabajo estudia SharePoint en este momento. Burlarse de él todo el tiempo. Con frecuencia habla algo así como "¡¡¿si es eso? !!". Y luego me siento un poco triste, porque lo sé, hay una probabilidad de que tenga que aprender eso también (supongo que no es tan fácil obtener proyectos hoy en día).

Lo veo más como configuración y personalización que como desarrollo de software (algo así como cazar la casilla fing durante 3 días seguidos). Recoges un poco de arcilla a través de esos locos diseñadores de sitios compartidos y luego la personalizas infinitamente.

Por todo lo que ya sé, hay un nuevo nombre (es decir, spGridView) y un comportamiento inesperado debajo.

Html que se procesa es bizzare (tablas y montón de viewstate serializado en todas partes).

Pero esas configuraciones xml`s ... o_0
Ahora que es un obstáculo que no puedo superar. Incluso las cosas hardcore de SQL comienzan a parecer un juego infantil.

Tal vez estoy equivocado, pero como he escuchado, Microsoft desarrolló ''columnas espaciales'' (le permite expandir el recuento de columnas para tablas de más de miles) para SQL principalmente debido a Sharepoint. Eso me aterroriza

Por supuesto, mi opinión es ALTAMENTE subjetiva y un poco ofensiva. Pero espero que eso ayude a revelar mejor lo que pienso y siento sobre Sharepoint.

Es de esperar que los desarrolladores con los que estás trabajando vean esto diferente.

En breve:
No. No me gustaría convertirme en desarrollador de sharepoints.

Editar:
Podría manejar esa complejidad inicial. Pero la razón principal por la que no quiero hacerlo es que no creo que el desarrollo en Sharepoint sea el camino correcto. Es decir, últimamente la gente comenta que los formularios web proporcionan demasiada abstracción. Entonces, ¿qué decir de Sharepoint?

gracias a todos por las respuestas, todos son realmente útiles.

por lo que leo aquí, veo dos cosas para considerar.

Primero es el contexto de utilización que creo que es un factor importante. En algunos lugares, el "desarrollo" de SharePoint podría llegar muy lejos, y podría implicar el desarrollo de cosas realmente emocionantes, con el fin de satisfacer las necesidades de nuevos clientes. podría implicar escribir código, etc. Y en otros lugares podría ser solo administración y configuración, para mantener las soluciones ya establecidas.

En segundo lugar está la motivación personal. Realmente depende de la persona. Algunos desarrolladores de .Net con buena experiencia preferirán no ir en una dirección, donde no codificarán la "forma de SharePoint", y les gustaría escribir el código en C # o en algunos otros idiomas. Sin embargo, habrá otros que elegirán este camino y estarán felices de tener tales carreras. Estarán motivados y, por lo tanto, proponen soluciones realmente agradables.

Por ejemplo, desde mi perspectiva personal y si me hubiera quedado en desarrollo y programación, no elegiría el desarrollo de SharePoint usando asistentes y menús de alto nivel, como una ruta de progreso para mi carrera. Aunque no lo hago en estos días, todavía disfruto de la codificación, la compilación, la depuración, etc., pero este soy solo yo.

Para ser un desarrollador exitoso de SharePoint debe tener un umbral alto para el dolor y la paciencia de un Buda.