August 2008 - Artículos
Se ha publicado SharePoint Administration Toolkit 2.0.
Encontrareis esta información en el blog de Zach Rosenfield, Program Manager de SharePoint, en este enlace.
En este mismo enlace, encontrareis además los enlaces para descargar SharePoint Administration Toolkit 2.0 en versión 32 bits y 64 bits.
Algunas de las características más interesantes añadidas en esta nueva versión, tienen que ver con la alta disponibildiad y con la replicación geográfica.
Recuerda que el propósito fundamental de esta herramienta es la de ayudar a los administradores de SharePoint con las tareas de administración del producto.
Continuando con este mes loco de Agosto en el que Microsoft no ha parado de publicar cosas, ahora le llega el turno al SDK (Software Development Kit) de WSS 3.0.
Este SDK, de versión 1.4, actualiza al anterior SDK que se había publicado, y como todo buen SDK que se precie, contiene información de interés para los desarrolladores, con ejemplos y referencias, todo ello relacionado con Windows SharePoint Services 3.0.
El SDK solo está disponible en inglés y en japonés (de momento) y su descarga ocupa aproximadamente 42 Mb.
Podreis acceder a la descarga del SDK en este enlace.
Nota: La única duda que tengo ahora mismo y que no he podido verificar aún es si los ejemplos del SDK están preparados para Visual Studio 2008 o no. Por la información que he podido ve, están preparados únicamente para Visual Studio 2005, pero no he podido confirmar aún esto.
Actualización: Además de la confirmación por parte de Juan Carlos de que el soporte en Visual Studio 2008 estaba incluido, en el blog oficial del equipo de trabajo de SharePoint indican este hecho también. La duda surgió porque en la página Web oficial de descargas de Microsoft, indicaban el soporte para Visual Studio 2005, pero no indicaban nada de Visual Studio 2008, algo que me extrañaba porque aseguraron muchos meses atrás que a mediados de año se incluirían las plantillas de SharePoint para trabajar con ellas en Visual Studio 2008. Gracias por el chivatazo Juan Carlos.
Microsoft ha publicado la versión Windows Live Agents 5.0 SDK, disponible en inglés y con un tamaño de descarga cercano a los 110 Mb. Esta versión se integra en Visual Studio 2008 y nos permite desarrollar y depurar nuestros propios agentes.
Recordemos que con este SDK, podemos desarrollar nuestros propios agentes o robots, que permitirán interactuar con los usuarios a través de Microsoft Windows Live Messenger.
Si quieres saber más acerca de los agentes para Windows Live Messenger, puedes acceder a Wikipedia o al sitio oficial de Windows Live Agents.
Si lo que quieres es acceedr a Windows Live Agents 5.0 SDK, puedes hacerlo en el siguiente enlace.
Como todos sabeis, SQL Server 2008 ha hecho aparición durante este mes de Agosto... muchas son las preguntas que nos hacemos todos sobre lo nuevo que trae SQL Server 2008. A vista de pájaro, una nueva versión de SQL Server 2008 ha hecho aparición, con el objetivo de frenar los impulsos que están teniendo otros gestores Web en la red, hablo lógicamente de SQL Server 2008 Web, que ofrece un sistema gestor de base de datos de bajo coste, escalable y con disponibilidad para aplicaciones Web.
Pero no todo lo nuevo y relacionado con SQL Server 2008 ha visto la luz en su versión RTM, de hecho tenemos que acudir a SQL Server 2008 Report Builder 2.0 RC1 para comprobar que ha aparecido en versión RC1 (Release Candidate 1), es decir, los cambios que se han realizado en esta versión son cambios menores y está a punto de ver la luz como versión RTM final, pero aún hay que esperar un poco.
SQL Server 2008 Report Builder 2.0 RC1 nos proporciona un entorno intuitivo para crear nuestros propios informes. SQL Server 2008 Report Builder 2.0 RC1 soporta todas las capacidades de SQL Server 2008 Reporting Services.
Se asegura que SQL Server 2008 Report Builder 2.0 RC1 trabaja perfectamente con SQL Server 2008 RTM.
El esfuerzo de la gente de Microsoft por mejorar Reporting Services y todo lo relacionado con los informes es muy grande. Reporting Services implica a muchas más aplicaciones como SharePoint, y es interesante echarle un vistazo.
Podrás acceder al paquete de instalación de SQL Server 2008 Report Builder 2.0 RC1, disponible en inglés y con cerca de 19 Mb de tamaño, en este enlace.
Podrás acceder también a un breve listado de las mejoras añadidas a esta última RC en este enlace.
Si lo que quieres, es saber las 6 diferentes versiones de SQL Server 2008 existentes, podrás conocerlas en este enlace.
Microsoft ha publicado las SPG con fecha 26/08/2008, o lo que es lo mismo, los P&P (Patterns & Practices) de SharePoint Guidance.
El fichero con ejemplos y con su fichero de ayuda de Windows (CHM) ocupa unos 3.5 Mb.
En la página principal de Releases del proyecto en CodePlex (donde se encuentra el proyecto), encontrarás el enlace directo y la información adicional del SPG en este enlace.
Recuerda que estas guías, pretenden ayudarnos e indicarnos como debemos crear aplicaciones en SharePoint para nuestras Intranet. Las guías contienen datos y mejores prácticas para los arquitectos, diseñadores y desarrolladores.
Hace unas horas os hablaba de StyleCop 4.3. Ahora le llega el turno a FxCop 1.36.
Microsoft ha publicado recientemente la última versión de su herramienta para analizar el código de los ensamblados de .NET, hablo de Microsoft FxCop 1.36.
La herramienta está disponible en inglés y tiene un tamaño de aproximadamente 2 Mb.
Podrás acceder a la noticia oficial en el siguiente enlace. También es interesante leer una entrada de David Kean que trata sobre la regla de mult-targeting añadida en Visual Studio 2008 SP1 y en FxCop 1.36. Podrás acceder a esa información aquí.
Para acceder a FxCop 1.36 haz clic en el siguiente enlace.
StyleCop es una herramienta que nos permitirá revisar el código de nuestras aplicaciones C# respecto al estilo y consistencia de violación de acuerdo a las reglas de nomenclatura.
La última versión de esta herramienta es StyleCop 4.3, y puede ser descargada desde el siguiente enlace. En ese enlace encontraremos no solo el paquete instalable de la última versión, sino además, un fichero zip que contiene un fichero CHM de ayuda Windows con las reglas de verificación de la nomenclatura de código.
La parte más positiva de esta herramienta es que permite su integración con Visual Studio 2005 y Visual Studio 2008, así como con MSBuild.
El único "pero" es que aún no hay soporte de esta herramienta para Visual Basic, y que el equipo que está detrás de la herramienta no ha dicho nada al respecto pese a haber sido preguntado en más de una ocasión... de momento... los desarrolladores de Visual Basic tendremos que esperar. ¡Que remedio!
Para acceder a la información oficial de StyleCop 4.3, deberemos acceder a este enlace, donde encontraremos información adicional que recomiendo leer.
No obstante, cabe destacar que existen diferencias de nomenclatura entre StyleCop y las famosas Framework Design Guidelines. Para más información al respecto, acceder al siguiente enlace.
Hace algunos meses comenté en mi blog el camino de ruta de Open XML SDK.
Un recordatorio no viene mal:
Ahora le toca el turno de encajar la versión 1.0 de Open XML SDK dentro del camino de ruta o Roadmap.
Hace algunas fechas apareció el esperado Open XML Format SDK en su versión definitiva.
Con este paquete ha aparecido también información adicional del paquete que puede ser localizada en este enlace.
No obstante, Open XML SDK está disponible en inglés y japonés y ocupa unos 3 Mb. Podrás acceder al SDK en este enlace.
[Ref.: La anarquía de los programadores de Visual Basic (I)]
En todas las oportunidades en las que tuve la posibilidad de hablar de .NET cuando éste apareció por primera vez, comenté que era importantísimo para el desarrollador tener muy claro los conceptos base de la programación orientada a objetos. Daba igual que hubiera decidido dar el salto a .NET en ese instante o más adelante, independientemente de esto, era muy valorable que comprendiera los conceptos de la orientación a objetos.
Un desarrollador de Visual Basic puede entrar en el mundo de .NET sin tener ni idea de programación orientada a objetos, pero le costará mucho más esfuerzo comprender algunos de los mecanismos fundamentales del desarrollo de aplicaciones en .NET que un programador que tiene esos conocimientos ya asentados. Además, mantener y entender el código le resultará una odisea en un primer momento.
Sin embargo, hay algo intrínseco a los desarrolladores de Visual Basic en general, y es esa anarquía que siempre hemos tenido a la hora de desarrollar aplicaciones en .NET. Gracias a esa anarquía, hemos logrado construirnos una gran fama según la cual, un desarrollo de Visual Basic no puede poseer una calidad adecuada por estar escrito en eso, en Visual Basic. La frase de que en Visual Basic puede desarrollar cualquiera denota bajo mi punto de vista, cierta ignorancia o desconocimiento respecto al propio desarrollo del Software con Visual Basic. El auténtico mérito de Visual Basic ha sido hacer fácil lo que para muchos era difícil, el desarrollo rápido de aplicaciones Windows. De hecho, gracias a Visual Basic, tenemos hoy una gran cantidad de lenguajes de desarrollo visuales.
La anarquía que aquí comento no obstante, tiene o puede tener su origen en diferentes fuentes, y una de esas fuentes es el hecho de que Visual Basic no es case sensitive, es decir, podemos declarar una variable como variableDeclarada y otra variable como variabledeclarada, y el entorno nos dará un error indicándonos que no se puede declarar la misma variable dos veces.
Otra característica que voy a comentar ahora es algo que no le gusta escuchar a mucha gente, sobre todo a los desarrolladores de C#, pero que es así como lo voy a contar, y es lo que en Visual Basic se denominan métodos y funciones. Para un desarrollador de C#, todo son métodos. Para un desarrollador de Visual Basic, los métodos no son funciones, y las funciones no son métodos. Es decir, un método no devuelve nada, y una función por su propia naturaleza, devuelve algo. Esto que parece muy poco importante, genera a veces discusiones interminables, y en otros casos, impiden que un desarrollador de Visual Basic entienda perfectamente lo que se indica en un libro o el comentario del código de una aplicación. En mi modesta opinión, me gusta más como se plantea esto en Visual Basic que en otros lenguajes de programación como C#, pero sé que no todo el mundo estará de acuerdo conmigo con esta afirmación.
Además de todo esto, en otros lenguajes de programación como C# hay algunas cosas que el propio compilador no deja hacer. Con Visual Basic, esas mismas cosas que no se pueden hacer con C#, sí se pueden llevar a cabo con Visual Basic, en buena parte para ayudar a los desarrolladores que vienen de Visual Basic 6.0 o anteriores.
Algunas de esas libertades que se pueden hacer en Visual Basic para .NET y que se permiten hacer por compatibilidad, no hacen nada más que alargar y ser más permisivos con esa anarquía de la que hablo. De todos los modos, aconsejo a quien lea esto, que abandone el uso de instrucciones mantenidas en Visual Basic para .NET por compatibilidad. Así por ejemplo, si utilizamos MsgBox() en lugar de MessageBox.Show() tendremos el mismo efecto, y el compilador se encargará de cambiar MsgBox() por MessageBox.Show() en la compilación, pero la lógica nos invita a sustituir MsgBox() por MessageBox.Show() en nuestro código aunque sea un poco más largo de escribir. Sin embargo, veo en muchos ejemplos de código para .NET en Internet, incluso en ejemplos mostrados por responsables del lenguaje Visual Basic, el uso de MsgBox(), algo que personalmente me irrita.
Pero con todo y con esto, es importante que el desarrollador de Visual Basic trate de minimizar al máximo la anarquía que tiene a la hora de escribir código sacando provecho eso sí, de las bondades de Visual Basic como lenguaje. Es en sí, responsabilidad del desarrollador. Pero no sólo se le puede achacar la responsabilidad de esta decisión al desarrollador, sino también a todo el equipo de desarrollo, desde su Jefe de Proyecto hasta el programador. A veces las decisiones vienen impuestas, y no sería la primera vez que se obliga a trabajar de una forma caótica porque así se lleva haciendo desde hace muchos años y no se va a cambiar ahora que todo el mundo está acostumbrado a trabajar así (esta frase la he oído tantas veces…).
De esa manera, podríamos dar una serie de consejos y pistas iniciales para tratar de evitar en lo posible esa anarquía. Los siguientes consejos, los considero básicos para hacer frente a un desarrollo con Visual Basic en .NET.
Además de comprender y conocer la base de la orientación a objetos, es bueno que escribamos el código de nuestras aplicaciones basándonos en primer lugar en una adecuada nomenclatura de código. El uso de una adecuada nomenclatura de código ayuda a que todo el mundo escriba aplicaciones .NET de una forma homogénea, o al menos lo más homogénea posible, de modo que el mantenimiento de las aplicaciones sea lo más efectivo y práctico posible. La reutilización de código aquí no tendría ningún riesgo, y sería trasparente al propio desarrollo del Software.
La gestión de errores debe realizarse siempre que se pueda de la misma forma, de manera que siempre que desarrollemos una nueva aplicación sepamos tener unas directrices generales sobre la gestión de errores que aplicaremos en todos nuestros desarrollos.
Con posterioridad tendremos que aplicar un conjunto de acciones como por ejemplo las pruebas unitarias. Las pruebas unitarias son o deben ser tan importantes como el propio desarrollo. Aún mucha gente no entiende esto, pero es esta una fase más del desarrollo del Software que es obviada en muchos proyectos, y su importancia es vital.
A veces, podemos utilizar herramientas externas para analizar el código tratando de que este tenga una calidad aceptable, no sólo en cuanto a su nomenclatura, sino en cuanto a líneas de código escritas por método o profundidad del código, etc. Recuerden todos esto… ¡Refactoring existe!.
En resumidas cuentas, no es que estos pequeños consejos nos ayuden a eliminar o erradicar la anarquía que los desarrolladores de Visual Basic tenemos a la hora de desarrollar nuestras aplicaciones, de hecho podríamos seguir enumerando más consejos muy importantes todos ellos, pero sí es cierto que estas pequeñas ayudas nos permitirán asentar las bases de cualquier desarrollo. La práctica y la prueba/error harán el resto… nadie hemos nacido enseñados.
Entonces, ¿cuál es la frontera entre anárquico y estricto a la hora de escribir el código para nuestras aplicaciones Software en Visual Basic para .NET?. En mi opinión, cuando un desarrollador de Visual Basic para .NET escribe una aplicación, debería pensar en que esa aplicación es para .NET, por lo que cualquier desarrollador de la plataforma .NET podría mantenerlo, y ese desarrollador no necesariamente debería venir del mundo Visual Basic, incluso podría venir del mundo C# por poner un ejemplo. El programador de Visual Basic para .NET debería evitar por lo tanto el uso de librerías de compatibilidad incluidas en .NET para facilitar a los desarrolladores el paso de Visual Basic 6.0 a .NET. El motivo principal es el mantenimiento de las aplicaciones y en otros casos incluso, el rendimiento de las mismas.
Muchas de las criticas que recibimos los desarrolladores de Visual Basic es que debido a esa fama anárquica que nos hemos ganado a veces escribiendo el código de nuestras aplicaciones en ese lenguaje, muchos piensan erróneamente que las aplicaciones escritas en Visual Basic no se merecen ese respeto que sí tienen otros lenguajes, que las aplicaciones escritas en Visual Basic no poseen una calidad respetable, que los desarrolladores de Visual Basic no sabemos realmente programar, que las aplicaciones de Visual Basic no son tan potentes como una misma aplicación escrita en C# por ejemplo, o que con C# por ejemplo, se pueden hacer más y mejores cosas que con Visual Basic. Siento mucho citar en varias ocasiones C#, pero quiero que se entienda que todas esas afirmaciones, por mucho que se repitan, son mentiras. Lo que sí es cierto es que muchos programadores de Visual Basic, han o hemos sido tan anárquicos al escribir nuestras aplicaciones Software, que nos hemos ganado con pulso algunas injustas dudas depositadas en Visual Basic como lenguaje de programación, pero solo eso.
Como dice un dicho, créate fama y échate a dormir.
En otras futuras entradas, tengo previsto hablar de algunos aspectos relacionados con el camino hacia .NET que deben, en mi opinión, emprender los desarrolladores de Visual Basic 6.0 hacia .NET, así como temas o aspectos relacionados con la migración de aplicaciones de Visual Basic 6.0 hacia .NET.
Microsoft ha publicado una interesante guía o mejor dicho documentación, en formato CHM (fichero de ayuda de Microsoft Windows) sobre WSS 3.0 (Windows SharePoint Services 3.0).
En sí, el fichero de ayuda en inglés y de casi 4 Mb, contiene información general sobre WSS 3.0 publicada en TechNet.
Si quieres conocer algunos de los aspectos más específicos relacionados con WSS 3.0 o si eres una persona que tiene responsabilidad directa con el departamento de TI, quizás encuentres en este documento una base importante de apoyo y conocimiento.
Podrás acceder a este contenido en este enlace.
Microsoft ha publicado recientemente Microsoft SQL Server 2008, y con él, han empezado a aparecer todos los paquetes de distribución relacionados con SQL Server 2008.
Entre estos paquetes se encuentra SQL Server 2008 with Advanced Services, disponible en inglés y español, además de en otros idiomas más como Portugués, Francés, Italiano o Alemán.
La descarga de casi 500 Mb contiene SQL Server 2008 Express Edition y otras características como el SQL Server 2008 Management Studio Basic, la aplicación de administración de bases de datos, o el nuevo SQL Server Reporting Services que nos permitirá ejecutar informes de datos relacionales.
Podemos acceder a la información adicional de SQL Server 2008 Express en este enlace donde encontraremos información adicional de las novedades de SQL Server 2008 que no son pocas. Por otro lado, podremos acceder a la descarga de SQL Server 2008 Express with Advanced Services en este otro enlace.
¡Que lo disfruteis!
He podido constatar en los últimos años, que muchos desarrolladores de Visual Basic no se han atrevido aún a dar el salto a .NET, quizás por miedo, quizás por desconocimiento, no lo sé exactamente, pero lo que sí sé es que por esa falta de decisión esas personas y empresas están perdiendo el ritmo y la posibilidad de luchar en un mercado como el informático, cada vez más competitivo y preparado.
Recuerdo con cariño mis primeros pasos en esto de la informática. Fue en la Universidad, y allí, una de las tareas que más me gustaron de todas las diferentes materias que recibí durante la carrera, fue la programación por encima de cualquier otra como la administración de sistemas, el diseño gráfico, las bases de datos y otras tantas, que aunque me parecieron muy atractivas e interesantes también, no me atraían tanto como la programación en sí, esa tarea creativa, ese arte, porque para mí es eso, arte, desvirtuado eso sí al menos en España, donde no se rinde honor a su esfuerzo, no se reconoce como lo que es.
Fue entonces cuando aprendí en esas clases de la Universidad las nociones básicas de la programación, mi primera y real toma de contacto con la programación de aplicaciones, y adquiriendo esos conocimientos genéricos base, con cosas como la toma de requerimientos, los pseudocódigos, los flujos de trabajo, los cuadernos de carga, la gestión de proyectos informáticos, los árboles de decisión, los Pert y su gestión con programas como Microsoft Project, etc., y con todo ello las instrucciones básicas y genéricas de los lenguajes de programación como Fortran y Cobol, y un par de años después un poquito de C, C++ y SmallTalk, pero todo ello basado en unos pilares de programación que en la Universidad en la que estudiaba nos los apuntaban como indispensables pero carentes de profundidad, muy básicos, y que por aquel entonces ya criticaba por considerarlos no solo escasos sino también arcaicos respecto a lo que el mercado pedía. Las respuestas eran siempre las mismas, nuestros conocimientos debían encaminarse hacia otras áreas como gestión de proyectos, estadística, contabilidad, marketing, etc., conocimientos todos ellos que me han servido mucho, pero desmereciendo un poco la labor del desarrollo del Software y pensando quizás en que las tareas de desarrollo las debían hacer otros, y es que para mí, tan importante es la tarea del desarrollo del Software como lo puede ser cualquier otra tarea relacionada con la informática. Incluso me prestaría a afirmar que la primera tarea fundamental en la informática es el desarrollo del Software por encima de cualquier otra, porque sin aplicaciones Software, no hay usuarios que trabajen, administren y aceleren productivamente sus tareas diarias.
Un pequeño traspiés personal en el primer curso de carrera hizo que me replanteara algunos retos personales, y así aproveché para bucear en los entresijos de Windows 3.1 y comprobara que era un entorno de ejecución de aplicaciones ideal para las empresas y usuarios particulares, e intentara además, crear mis primeras páginas Web HTML y mis primeras aplicaciones Windows, dos ambientes de desarrollo muy diferentes pero que por aquel entonces se veía como extraño.
Intenté aprender entonces en mi tiempo libre como crear una aplicación Windows con Visual C++ 1.0, pero eso era para mis pequeños y débiles conocimientos de programación un dolor de cabeza más que una solución, así que di el salto después a Turbo Pascal 7.0 pensando en que era más adecuado para mí, pero mi base de conocimiento respecto a la programación era aún muy pobre e insuficiente.
El caso es que remontándome a los años de los que hablo, solo puedo recordar que no había tanta documentación, libros e información que facilitara el aprendizaje como los que hay ahora, y por aquel entonces solo podía bucear en las BBS (incluida la BBS de Microsoft,… ¡qué recuerdos!), algo conocido como Infovía (realmente lento y caro para un estudiante) y algún pequeño recurso más como las revistas de informática en inglés que llegaban a la biblioteca de mi Universidad (creo recordar eran Bit y PC World).
Con todo y con esto, Pascal como lenguaje de programación me parecía tan interesante como difícil de entender, y eso me desanimaba un poco, así que siguiendo mi camino autodidacta de aprendizaje por lo que se estaba convirtiendo en una pasión, me tropecé accidentalmente con Visual Basic (bendito el día), concretamente con Visual Basic 1.0, y éste sí me enganchó.
Eso de que con apenas conocimientos de programación pudiera desarrollar una aplicación Windows en cuestión de menos de 5 minutos fue para mí un argumento indiscutible y suficiente para apostar por ese lenguaje. Además, la forma de codificar aplicaciones en Visual Basic era muy sencilla de comprender, hacía fácil lo que para otros era complejo, por lo que me pareció lógico apostar por este lenguaje de programación en lugar de otro.
Un poco más tarde y al mismo tiempo que aumentaban mis conocimientos y comprensión de Visual Basic me puse a trabajar en mi tiempo libre con la versión Beta de Java, lenguaje moderno, actual y con Sun Microsystems como empresa de referencia. Me gustó mucho, incluso me apunté a un concurso internacional de desarrollo con su versión Beta, pero seguía teniendo unos conocimientos insuficientes como para entender todo de forma clara y directa. Mi nivel de C++ era básico, y aunque SmallTalk me ayudaba a conocer las bases de la programación orientada a objetos, veía en Java la misma dificultad que tuve con Pascal, y al final terminé tirando la toalla focalizando todos mis esfuerzos en Visual Basic.
No obstante, eso fue hace aproximadamente unos 14 años, y desde entonces ha llovido mucho. Por suerte, han cambiado mucho las cosas desde entonces y a mejor. De hecho, por aquellos años se oía comentar en diferentes círculos cosas como los paradigmas de la programación estructurada, la programación orientada a eventos y por supuesto, la programación orientada a objetos, pero ésta última de forma muy ligera. Y es que tan importante es tener buenos medios técnicos para crecer en el conocimiento como buenos profesores que impartan los conocimientos más actuales posibles y de una forma adecuada, algo que siempre critiqué en mi época de estudiante por no estar a la altura de lo que a mi juicio debía seguirse, al menos en lo que respecta a la programación y el desarrollo Software en la Universidad en la que estudié. Al final y pasados algunos años después de acabar la carrera, hablé con otros compañeros de Universidad sobre sus carreras profesionales, y considero que teniendo en cuenta la experiencia personal de la gente con la que he hablado, el tiempo me ha terminado de dar la razón.
El caso es que en toda esta historia llego a la conclusión de los vicios adquiridos respecto a la programación, vicios compartidos por muchos desarrolladores en todo el mundo, y que de forma más frecuente de lo habitual, están instalados en los desarrolladores de Visual Basic. La base de una buena enseñanza ayuda a acortar la curva de aprendizaje, la práctica es siempre necesaria y es la única forma de aprender a desarrollar, y con eso, no digo aprender a escribir programas y aplicaciones, sino aprender a desarrollar, que es otra cosa diferente. Una buena enseñanza con los criterios suficientes favorecen y permiten reducir los vicios al máximo posible. Tan importante es ser un buen alumno como ser un buen profesor, en caso contrario, sacaremos la mitad del provecho o menos de lo que podríamos obtener, y arrastraremos durante toda nuestra vida, unos vicios adquiridos difíciles de solventar.
Debido a la facilidad de desarrollo de aplicaciones con Visual Basic, muchas personas con pocos conocimientos de programación, incluso profanos en este arte, se adentraron en este campo, y con ello, desarrollaron aplicaciones Windows como Dios les dio a entender (respeto el trabajo de todas las personas, que he visto grandes maravillas hechas en Visual Basic 6.0 por personas que tenían pocos conocimientos de desarrollo Software, pero entended lo que quiero decir). Para mí, todos son o somos (mejor dicho) desarrolladores, pero no es menos cierto que mientras unos poseen unos pilares base que hacen que su trabajo sea más efectivo, otros trabajan de una forma más caótica.
Los desarrolladores de Visual Basic, antes de la orientación a objetos, veían a Visual Basic ese lenguaje de programación ideal, no solo porque les permitía desarrollar aplicaciones Windows en tiempo récord, sino porque además, no requería de unas normas rígidas que obligaran a los desarrolladores a actuar de una forma ordenada o estricta en cuanto al método de trabajo con respecto a la programación. Es decir, podían desarrollar aplicaciones de una forma más anárquica y caótica, como les diera la gana. En pocas palabras, no tenían porqué saber las reglas básicas del desarrollo del Software ni tampoco tener grandes conocimientos de programación. ¿Alguien acaso no recuerda el famoso GoTo o el famoso On Error Resume Next de Visual Basic 6.0?. Quizás sean de las instrucciones más utilizadas en el mundo, pero no por ello constituyen una buena práctica en el desarrollo del Software.
Visual Basic sin embargo, evolucionó con el tiempo, y con la aparición de .NET introdujo los paradigmas de la programación orientada a objetos (por fin). En ese instante, se abrió una pequeña brecha entre los programadores tradicionales de Visual Basic y los programadores de Visual Basic para .NET.
Los desarrolladores que no poseían esa base o pilares fundamentales se encontraban en un segundo plano, mientras que los desarrolladores con conocimientos de orientación a objetos y los desarrolladores que entendían ese cambio como natural, se encontraban mucho más cómodos y preparados de cara al futuro.
(Continuará…)
¡Por fin estoy de vuelta!.
El mes de Agosto de este año que está a punto de finalizar lo he dedicado casi por completo a estar totalmente desconectado del mundo informático, no han sido los 10 días en el desierto de otros, pero han sido los 10 días por Irlanda entre lluvia, sol, paisajes verdes y gente agradable, conduciendo eso sí por el lado contrario al que estaba acostumbrado, 2368 kilómetros exactamente, y estaba creo yo tan preocupado en llegar vivo de regreso a casa que de pensar en un ordenador. El GPS no obstante, me ayudó muchísimo,... ¡que gran invento!.
El caso es que durante este mes he estado en Burgos (España), Irlanda, Andorra y Madrid (España), y me ha servido para oxigenar la mente, hacer otras cosas diferentes que durante el resto del año normalmente no puedo hacer, coger aire y pensar en los nuevos retos que deseo afrontar durante el próximo año, en fin, tener tiempo para uno mismo y para los que le rodean, que es una parte importantísima (sino la que más) de la propia vida humana.
Pero todo termina al igual que empieza y vuelve siempre a su cauce, y en este caso, nada más llegar a Madrid he intentado ponerme al día y he visto algunas cosas que no sé si se habrán contado ya en Geeks o no, o incluso si las habré contado yo antes, pero no puedo dejar pasar este primer contacto con el blog para informar de un curso online muy interesante y recomendable sobre Silverlight.
El curso está en inglés y es de carácter introductorio, pero a mi modo de ver muy interesante, sobre todo para aquellas personas que deseen aprender lo que es Silverlight.
Podréis acceder a este curso online en el siguiente enlace.
Finalmente, me veo en la obligación de salirme un poco del ámbito del blog y sacar un OT. Me gustaría recordar a las víctimas del fatídico accidente del avión de Spanair de hace unos días y dar un par de tirones de orejas. Desgraciadamente sí conocía a alguna de las víctimas y familiares del accidente, aunque no de una forma estrecha. De todos los modos, y aunque no conociera a ninguna de esas víctimas y/o a sus familiares o amigos, lo cierto es que siempre que ocurre una catástrofe de esta envergadura, me da mucha pena al pensar en la cantidad de ilusiones truncadas de un solo golpe. Por eso siempre digo que tratemos de aprovechar la vida al máximo, respetando eso sí las reglas básicas y generales del respeto hacia el prójimo, algo que precisamente no me pareció percibir en cadenas de televisión como TVE1, Tele 5, Cuatro, la Sexta, o medios escritos como El País o El Mundo en algunos momentos. Me da la sensación de que lamentablemente hay veces que el periodismo de nuestro país toma todas las noticias como si fuera el Tomate o la Prensa Rosa, perdiendo a veces el norte y la sensibilidad hacia las personas, actuando con una irresponsabilidad y una falta de tacto muy parecida a la que tienen hoy día muchos de nuestros políticos y dirigentes. Carpe Diem, descansen en paz, y no hagas a otros lo que no te gustaría que te hicieran a tí.