Mostrando entradas con la etiqueta los mejorcitos. Mostrar todas las entradas
Mostrando entradas con la etiqueta los mejorcitos. Mostrar todas las entradas

La Generación M: Al borde del un nuevo cambio

viernes 11 de abril de 2008 | categorías: , , | 0 comentarios -- da clic aquí para dejar el tuyo

Hoy me tocó dar una plática bastante diferente a la que estoy acostumbrado.  Resulta que los chavos de la carrera de Tecnologías Computacionales del Tec de Monterrey Campus Juárez (mi "alma mater") hicieron un evento llamado El Congreso con la finalidad de atraer a más chavos (y chavas, claro, si no qué chiste) de las prepas y secundarias locales hacia las carreras de "sistemas".

Aparentemente algunos de ellos habían leído mi blog y me enviaron un correo para invitarme a participar como expositor, lo cual se me hizo un honor.  Se siente medio raro regresar a la escuela de donde te graduaste para "enseñar algo".  Pero cuando me dijeron que la audiencia serían principalmente lepes de preparatoria comencé a ponerme un poco nervioso.  Después de todo, han pasado casi 10 años—a ver díaganlo: "uuuuuuuuuuuuu!"—desde que dejé de dar clases, y no me paraba a hablar enfrente de un grupo de esa edad.  Mi mente inmediatamente comenzó a dar vueltas: "Demonios, ¿de qué les puedo hablar? ¿De qué manera puedo encontrar un tema donde tengamos algo en común, y que hable de tecnología?" 

Pensándola un poco más caí en cuenta que muchos de estos chicos, son modelo 90 o más reciente—osea que nacieron después de 1990—lo cual me hizo sentir más ruco todavía porque yo soy setentayquíhúbole.  Mientras más lo pensaba más me era evidente que hay un a brecha entre esta generación y la mía.  Comencé a recordar cómo era el mundo cuando yo tenía la edad de ellos—hace 15 años más o menos—y cómo había cambiado el mundo desde entonces hasta ahora, hasta que me cayó el veinte: "¿y por qué no hablar precisamente sobre eso?".

Así que eché un poco de alucine este fue el resultado.

Generación i

La i es de internet.  Esta es la generación a la que creo que pertenezco.  En ella incluyo a las personas que eran adolescentes durante los pricipios de la década de 1990 y que nos tocó, por un lado, ver el nacimiento del internet—sí ya sé que el interné existía desde los 70s y 80s pero no fue sino hasta los 90s que el Web lo trajo a las masas ¿verdad?—y por otro lado presenciar cambios históricos a nivel mundial como la caída del comunismo.

 

Aún recuerdo ver en la televisión cómo derribaban el muro de Berlín.  Recuerdo ver también en la T.V. los tanques en Rusia mientras intentaron el golpe de estado contra Gorbachev y sentirme triste porque leí su libro sobre la perestroika y el glasnost.  Recuerdo la caída, país por país, de la cortina de hierro en Europa y también la primera Guerra del Golfo Pérsico donde una coalición de países decidió luchar contra Saddam Hussein.

Para cuando tuve edad de entrar en a la carrera en 1994, el mundo entero parecía enamorado de nuevo con el capitalismo y la apertura de mercados.  México llevaba poco que había firmado el TLC y en el Tec hasta inventaron carreras nuevas como la de Lic. en Comercio Internacional.  También por aquellos tiempos el internet comenzaba a salir de las escuelas y a entrar a los hogares.  El Tec, que hasta entonces había sido el único ISP de Cd. Juárez, le dejó eso a compañías como Infolink (si mal no recuerdo)—¿se acuerdan cuando tenían que pagarle a alguien y marcarles por teléfono con su módem para estar "en línea"? ¿No? Chin.

El caso es que se respiraba un ambiente de apertura.  En el lado tecnológico esa actitud comenzó a reflejarse en movimientos como el de Open Source.  Las personas comenzaron a colaborar a pesar de las grandes distancias gracias a la red que ahora cobraba vida.  Estábamos en plena "globalización 1.0", como lo describe Thomas Friedman y el mundo se estaba aplanando.  El internet había fomentado la globalización y la globalización ayudó al crecimiento de la red.  Por supuesto que ese momento no me dí cuenta de lo que ocurría porque estaba inmerso en él.  Para cuando me gradué de la carrera en 1998, "eso del e-mail" y de trabajar a distancia se había vuelto bastante común. 

Generación M

La M es de móbil, es decir un pochismo deformado mío de mobile phones, también conocidos como teléfonos celulares.  Esta es la generación que en estos momentos está en la adolescencia.

Cuando comencé mi plática, abrí con una pregunta: "¿Cómo sería tu vida... sin tu celular?"  Hubieran visto la reacción.  Fue una exclamación colectiva de auténtico horror: "¡Ay NOOoooo!", jejeje. "¿...sin Google? ¿...sin el Internet? ¿Qué música escucharías? ¿Qué sería diferente?"  Y ya cuando habían parado la oreja puse una diapositiva que decía: "Así era el mundo hace apenas 15 años".

A veces creo que no se le ha dado crédito a la impacto que han tenido los celulares—y sí, yo también considero que son odiosos y ojalá no los hubieran inventado, pero pues ni modo ya ganaron.  "En mis tiempos..."—como dicen los viejitos—los únicos que traían celulares eran los narcos y la gente de muuuucha lana.  Eran esos horrendos ladrillos Motorola que les duraba la pila una hora y podían se utilizados como arma de defensa personal.

 

Hoy en día parece que los chavitos nacen con el celular en la mano.  He visto niños de 7 y 8 años—entre ellos algunos de mis sobrinos—con celular propio, lo cual me parece absurdo, pero es la realidad.  Todo tipo de vagancias y mal comportamiento es videograbado con su teléfono para subirlo a YouTube.  Para ellos se ha convertido en una extensión de su persona.  Algunos de ellos incluso se identifican con su celular, lo cual es en verdad preocupante. 

Esto está ocasionando cambios interesantes.  Por ejemplo, todos esos mensajitos de texto—y la flojera que causa tener que teclearlos, supongo—están ocasionando cambios informales y deformaciones al español escrito.  Una conversación típica podría ser:

—Ke rollo?
—No ps nada
—Vas a ir al cine vdd?

Este tipo de deformaciones también están creciendo por el uso de mensajería instantánea (Messenger, Google Chat, Skype, etc.).  Cuando intento platicar con una de mis sobrinas por Messenger, a veces me dan ganas de darle un sape virtual y decirle: "¡escriba bien, no sea payasa!", pero me las aguanto.  Estos programas, también los están acostumbrando a que ahora se puede tener conversaciones de video o voz internacionales gratis o a muy bajo costo.  En otras palabras, la dimensión de la distancia comienza a cambiar.  El mundo no solo es plano sino que comienza a encogerse.

Una característica más que se me ocurre sobre la generación M es que, los chicos de ahora están (¿mal?)acostumbrados a tener las cosas on-demand, es decir, cuando ellos quieren y como ellos quieren.  Si quieren música, se van a iTunes, o BitTorrent o <inserte aquí la herramienta de piratería de moda>, la bajan y listo; ya no están limitados por la música de la radio o los discos en la tienda del mall.  Si quieren un libro es cuestión de pedirlo por Amazon o similares y obtenerlo.  ¿Aburrido? Solo "prende" YouTube y puedes perder horas enteras viendo todo tipo de tarugadas; ya no están limitados a lo que ofrece la tele.  La palabra clave, supongo, es opción.  Ahora tienen más opciones que nunca.  Lo cual quizá es bueno y malo a la vez.

Por otro lado también se pueden observar una serie de cambios y situaciones sociales interesantes.  Una de ellas me la apuntó Alex Briseño: los hijos de los dueños de muchas empresas están comenzando a tomar las riendas.  Es decir, un empresario que hoy tiene 50-60 años y que puso su negocio propio ahora está dándole el control a su hijos para que se hagan cargo.  Estos "hijos de dueños" son de la generación i, y no se sienten intimidados por la tecnología, lo que es más, lo ven como algo favorable, algo que trae un valor agregado.  Si alguna vez se han dedicado al negocio de vender "sistemas" se habrán quizá dado cuenta que con excepción de empresarios con mucha visión, la mayoría de la generaciones anteriores percibían esto como un costo, no como algo que les pudiera ayudar a ganar dinero.  Los "hijos de dueño", sin embargo, no solo no tienen problema con esto, sino que te buscan para que les hagas un sistema.  Eso a su vez comienza a cambiar la dinámica de la competencia en muchos ámbitos.

Combinado con la maduración de la globalización 2.0, el inicio de la 3.0 esto está permitiendo que los David comiencen a competir con los Goliat.  La Cola Larga está comenzando a esparcirse.  Dos ejemplos locales son que en Cd. Juárez, en los últimos 6 u 8 meses, Cablemás comenzó a competir con Telmex en telefonía; Volaris e InterJet, dos aerolíneas de bajo costo comenzaron a competir con Aeroméxico.

Pero con todas las maravillas de la tecnología hay otra cosa que está ocurriendo: está creciendo la brecha digital, el digital divide.  Es decir después de darte cuenta que el internet es maravilloso y que el acceso a la información es una necesidad porque uno como individuo está compitiendo con personas de todo el mundo, la siguiente pregunta inevitablemente es "¿y qué hay de los millones de mexicanos que aún viven en extrema pobreza? ¿Cómo sobreviviran en este nuevo mundo?"

Desgraciadamente no hay respuestas alentadoras.  La única manera de competir es a través de la educación y de ofrecer algo más.  En otras palabras, no competir en la maquilada de las cosas o de la información—siempre habrá mano de obra más barata en un país más desesperado—sino competir ofreciendo las cosas que requieren de más coco, de más intelecto. Seguro, un ingeniero hindú o chino de sistemas promedio sale más barato que yo, pero ninguno, de todos los que conozco y con los que he trabajado tiene la misma capacidad que yo.  Y no es por ser arrogante, simplemente les ha faltado cayo y colmillo.  No significa que no haya ingenieros competentes en otros países, significa que esos ingenieros no son de bajo costo.  Incluso eso está cambiando claro, al punto que en 10 años quizá estemos hablando de otros países.

Esta es una realidad difícil de aceptar.  Aunque hay que mencionar que sí hay algunas personas haciendo algo concreto al respecto.  Proyectos como el de Una Laptop Por Niño (OLPC) están tratando de atacar este tipo de problemas, pero la tecnología en sí es una solución insuficiente.

Generación W

La W es de wireless.  Esta generación serían los hijos de la generación M, nacidos quizá unos 15 o 20 años más en el futuro.

Si todo progresa como hasta ahora, más temprano que tarde la idea de las redes inalámbricas a nivel ciudad o región se harán realidad a través de cosas como WiMAX o mesh networks.  En otras palabras para entonces ya no estarás atado a tu casa o tu restaurante favorito para estar conectado.  Esto no solo dará a pie a dispositivos más sencillos y a la vez sofisticados—¿imaginas el iPhone del futuro?—sino que haría el sueño de OLPC una realidad.

Una vez liberados de los cables, estos niños podrán asimilar información y tecnología de manera casi instantánea.  De hecho, la idea de adiciones bio-tecnológicas al cuerpo humano no está completamente fuera del rango de posibilidades.  Imagina que en lugar de cargar un dispositivo como un celular o tableta inteligente que te brinda información, ésta esté integrada a ti.  Una red inalámbrica ubicua y un "chip" integrado podría darle la capacidad a los niños de este siglo de comunicarse y compartir información pseudo-psíquicamente en una red verdaderamente P2P.  Piensa en los Borg, de Star Trek, pero no tan feos y con independencia de acción.

¿Todavía suena como ciencia ficción?  Considera que en unos 15 años seguramente habrá avances significativos en la nanotecnología y que según algunos expertos para el 2029 también habrá tanto el hardware como el software necesario para tener inteligencia artificial a nivel humano.  Supon que se retrasen algunos años, el doble aproximadamente, y esto no se de sino hasta mediados de siglo.  Los niños de la generación W estarán apenas entrando a la adolescencia.

Sin embargo hay cosas que podrían descarrilar todo esto.  Conflictos globales persistentes, como la actual guerra en Irak podrían llevar a un des-aplanamiento del mundo y a que se vuelvan a cerrar las fronteras, regresándonos a la era Reagan.  Simplemente consideren algunos de los argumentos de los actuales candidatos demócratas a la presidencia de EE.UU., Barack Obama y Hillary Clinton.  Ambos han expresado que quieren re-negociar el TLC.  Entre eso, y el muro—perdón, "barda"—fronterizo que tan insistentemente y están construyendo, no inspira precisamente un ambiente de apertura para el futuro.  Siguiendo esta línea de pensamiento, no es tampoco descabechado pensar en un Great Firewall estadounidense o europeo modelado después del de China.  Si esto llegara a ocurrir y regresáramos a un mundo cerrado, la humanidad en mi humilde opinión, se estaría dando en la torre de motu proprio.

Pero todas estas son meramente posibilidades.  Lo bonito del futuro es que aún no está escrito, ¿verdad?

Aguas con el SDC (Síndrome del Desarrollador Callado)

miércoles 27 de febrero de 2008 | categorías: , | 1 comentarios -- da clic aquí para dejar el tuyo

Ya van varias veces que veo esto ocurrir en diferentes proyectos y diferentes compañías, así que asumo que es algo relativamente común.

La historia casi siempre es la misma: se vende un proyecto grande a un cliente, quizá algo ajustado de tiempo, pero suficiente para hacerlo.  Se hace el análisis y se bosqueja el diseño rápidamente.  Se reparte la chamba y todos en el equipo se ponen a jalar: "Tú aviéntate este módulo, tú este y yo este otro".

Ves a uno de los desarrolladores involucrados en el proyecto todos los días en su esquinita, tecleando como hormiga.  Sabes que está chambeando (o al menos crees saber que está chambeando).  Cuando le preguntan:

—¿Qué rollo? ¿Cómo vas con eso?

—Bien—contesta sencillamente.  No se queja, no da detalles.  Así que asumes que todo va bien, ¿verdad?

Pasa una semana, quizá un mes o dos... tres meses, y de pronto esa persona comienza a enfermarse o a faltar misteriosamente y de buenas a primeras decide renunciar.  Para entonces ya estás a una semana de entregar el sistema que prometiste, y cuando comienzas revisar el código que el cuate hizo, te das cuenta que: 1) lo que hizo no funciona o 2) lo que hizo hace algo pero no era lo que se supone que tenía que hacer.  En otras palabras estás jodido en aprietos.

Entonces el proyecto entra en pánico.  Se oprime el botón rojo y comienzan a sonar alarmas.  Llamadas desesperadas.  Baja de unas cuerdas del techo un equipo S.W.A.T. de desarrolladores externos (o si no tienes pues con los mismos de tu equipo) y se junta a la raza en el war room para ver cómo canijos se puede hacer en una semana lo que un chango no hizo en 3 o 4 meses.  Todo mundo entra en overdrive codificando día, noche y fines de semana casi sin dormir.

Si tienes suerte, y gente MUY talentosa, igual y logras la meta.  Pero muchas veces no es suficiente.

¿Qué fue lo que pasó?  Acabas de ser víctima del SDC, o Síndrome del Desarrollador Callado.

Una de las cosas que a menudo hacemos al desarrollar software es que cuando el schedule anda apretado, lo primero que se hace es mandar a la goma las revisiones de código, las pruebas unitarias, etcétera.  Es decir, lo primero en sacrificarse en aras del calendario, normalmente son las buenas prácticas de desarrollo de software, que irónicamente son tu más valiosa herramienta para terminar a tiempo y con calidad. 

Lo que acaba ocurriendo es que si las sacrificas y tienes uno de esos desarrolladores con SDC, lo más probable es que esa persona no esté entendiendo los requerimientos y/o no tenga las habilidades para pasarlos a código y tiene demasiado temor de que se sepa.  Así que no pide ayuda, no se queja, no hace preguntas.  Simplemente se va a su esquinita y hace el intento.  Cuando va pasando el tiempo y se acerca el deadline (por algo trae dead la palabra) esa persona comienza a sentir la presión que a menudo se manifiesta en enfermedad/desaparición.

No me malinterpreten, conozco dos o tres desarrolladores excelentes, algo anti-sociales, que chambean en su cubículo/esquina, calladitos, enclaustrados una semana o dos y cuando emergen salen con una fregonería de código.  Pero son dos o tres de un montononal que conozco.

Lo peor es que la solución al SDC casi siempre es bien simple: hacer revisiones frecuentes del avance, no solo a lo que se ve (es decir, las pantallas, páginas, o lo que sea visible del sistema), sino a nivel código.  Cada semana (cuando MUCHO) juntar a otro desarrollador, y a un tester o persona que conozca los requerimientos: —A ver, vamos a ver cómo va esa pantalla.

No se trata de traer a la raza a latigazos, y tampoco se trata de hacer que la raza no le busque por su cuenta.  Se trata de no esperarse para descubrir las broncas cuando es demasiado tarde para hacer algo al respecto.  Sobre todo de que no se atasque el proyecto por cosas sencillas.  Yo, personalmente, si me atoro con algo (ya googulié, y ya lo intenté de dos o tres formas distintas) más de 3 o 4 horas y no puedo salir de ahí, inmediatamente agarro uno de mis compañeros y comienzo a explicarle el problema.  A veces con solo explicarlo se me viene una idea que resuelve el atorón, y cuando no, ellos me pueden dar ideas nuevas o enfoques que a mí no se me habían ocurrido.  Por muy chicho que creas ser, nunca faltan los días—o meses jejeje—en los que puedes caer en un lapsus brutus.

Así que si son uno de esos desarrolladores con SDC, por amor de Diosito, levanten la mano cuando se les atore la carreta.  No se esperen a que sea demasiado tarde.  Les prometo que nadie los va a morder.

smile_shades

¿Dónde quedó el usuario ASPNET en Windows Vista? ¿Y qué $#!N&@2 es eso de los Application Pools?

viernes 25 de enero de 2008 | categorías: , , , | 0 comentarios -- da clic aquí para dejar el tuyo

Hoy aprendí algunas cosas más al continuar con mis aventuras de desarrollo ASP.NET en Windows Vista.  Muchas de estas cosas aparentemente no son nuevas, vienen desde IIS 6 que era la versión incluida con Windows Server 2003, pero yo nunca los usé, así que hasta ahora me vengo enterando.

La primer lección salió cuando andaba buscando el usuario ASPNET de mi máquina para asignarle permisos de escritura sobre un directorio donde mi aplicación permite que los usuarios suban archivos.  Después de un rato de jugar Where's Waldo con el usuario, me convencí que simplemente no existía.  Resulta que el ASP.NET Worker Process—el proceso bajo el cual se ejecuta el código de ASP.NET—corre ahora por default bajo la cuenta NETWORK SERVICE (aunque esto se puede cambiar fácilmente).  Ah, y por cierto, el Worker Process ahora se llama w3wp.exe, en lugar de aspnet_wp.exe.

La segunda lección vino cuando quise correr mi aplicación.  Resulta que si usas módulos HTTP (<httpModules>) en tu web.config, recibirás un mensaje de error porque IIS 7 intenta correr las aplicaciones por default en un Application Pool llamado—duh—DefaultAppPool, y éste tiene un Managed Pipeline Mode puesto a Integrated.

¿Güat?  A ver si me puedo explicar.  Si abres la consola administrativa de IIS y te vas a Application Pools, verás algo como esto:

De cajón, Vista traía los dos primeros—Classic .NET AppPool y DefaultAppPool.  El tercero fue creado cuando instalé SQL Server Reporting Services, así que por ahora ignóralo.

Lo primero que me pregunté fue ¿qué $#!N&@2 demonios es eso de los Application Pools?

Resulta que es una manera muy padre de segregar y asignar una aplicación Web—o más correctamente su Application Domain—a un Worker Process determinado.  Un Pool puede tener varios AppDomains, y estos estarán separados de los que corran en otros pools. Considera este ejemplo:

 

Aquí tenemos tres aplicaciones de ASP.NET, cada una con su directorio virtual.  Las primeras dos están asignadas al primer Application Pool, y la tercera aplicación está asignada al segundo.  Esto es EXCELENTE por varias razones:

¿Que pasaba antes si una falla en una de las aplicaciones web hacía que se reciclara el Worker Process?  Pues todas las aplicaciones se "reiniciaban"—botando posiblemente a las sesiones y todo el show—porque los Application Domains están corriendo en el mismo proceso ejecutable. Me ha pasado. Teníamos una applicación Web corriendo en el mismo servidor que un servicio Web (en una máquina con Windows 2000 si mal no recuerdo), y de vez en cuando la aplicación hacía que se reciclara el Worker Process—maldito Crystal Reports—llevándose entre las patas al Web Service.  Ahora es posible asilar ese tipo de fallas.

¿O qué pasaría si quiero correr una aplicación de ASP.NET v1.x en el mismo servidor que una de ASP.NET v2.x?  Un Worker Process solo puede correr una versión del .NET Framework, hasta donde sé, así que con Application Pools ahora puedes lograrlo.

Y más relevante para el problema que yo tenía, IIS 7 tiene una manera distinta de manejar los httpModules—llamado Managed Pipeline Mode. DefaultAppPool usa Integrated. Así que lo que tenía que hacer en mi caso era asignar el directorio virtual de mi aplicación al Classic .NET AppPool que utiliza el modo Classic, para no tener que cambiar la configuración (y posiblemente código) de mi aplicación.

Si inspeccionas las opciones avanzadas de un Application Pool te das cuenta que puedes configurar cosas interesantes. 

Las que me llamaron la atención fueron:

  • .NET Framework Version. Para seleccionar qué versión quieres utilizar para las aplicaciones Web que corren en el Pool, o si no quieres permitir que corra código administrado (p.ej. una aplicación de ASP clásico o PHP que no tenga nada que ver con .NET).
  • Managed Pipeline ModeIntegrated utiliza el modo IIS 7, donde la configuración de los httpModules están centralizados y supuestamente tiene varios beneficios que aún no conozco; Classic permite que cada aplicación web mantenga su configuración.
  • Identity.  La cuenta de usuario y bajo el cual corre el Worker Process. Esto afecta directamente los permisos de seguridad de las aplicaciones en el Pool.  Los valores posibles son: NetworkService, LocalService, LocalSystem, SpecificUser; este último por si quieres especificar una cuenta creada por ti.
  • Identity Specific User Credentials.  Para poner las "credenciales" (el password pues) del usuario si usas Identity=SpecificUser.
  • CPU Limit, Limit Interval y Limit Action.  Sirven para limitar el porcentaje de CPU que consume el Worker Process en un tiempo determinado y hacer algo si se excede, como por ejemplo, matarlo.
  • Private Memory Limit y Virtual Memory Limit.  Sirven para limitar la memoria real y virtual que utiliza el Worker Process. ¿Alguna vez le has pegado a un System.OutOfMemoryException? Yo si, y no es divertido.

Una vez que comencé a entender este rollo, asignar mi aplicación al Pool correcto fue súper sencillo.  Simplemente te vas a las opciones avanzadas de tu directorio virtual y lo cambias.

 

Enjoy smile_shades

Cómo configurar IIS 7 en Windows Vista para desarrollar con Visual Studio 2005 y SQL Server 2005

martes 22 de enero de 2008 | categorías: , , , , , | 0 comentarios -- da clic aquí para dejar el tuyo

Aunque Windows Vista ya tiene más del año que salió, apenas hasta estos días pude migrar mi máquina primaria de trabajo a este sistema operativo—solo digamos que la empresa para la que chambeo es muuuuuuy cautelosa con este tipo de cambios.  Y aunque también ya salió Visual Studio 2008, aún tengo que utilizar la versión 2005.

Desarrollo principalmente aplicaciones ASP.NET y también necesito tener SQL Server 2005 Developer instalado localmente para correr tanto la base de datos como Reporting Services. 

Pero al intentar instalar estas herramientas me topé inmediatamente con los cambios en la manera que instalas IIS en Windows Vista.  Ya me habían platicado que IIS 7 era más modular, pero no me habían dicho qué tanto.  Por default, IIS ni siquiera viene habilitado, así que lo primero que tienes que hacer es instalarlo. 

Es sencillo, te vas a Control Panel > Programs > Turn Windows features on or off.

De las opciones que aparecen, palomea (osea dale clic en el checkbox) a lo siguiente, en este orden:

  1. Internet Information Services.  Esto selecciona automáticamente lo necesario para correr IIS.
  2. IIS > WWW Services > Application Development Features > ASP.NET.  Esto selecciona automáticamente lo necesario para correr aplicaciones de ASP.NET.
  3. IIS > Web Management Tools > IIS 6 Management Compatibility > IIS Metabase and IIS 6 configuration compatibility.  Este componente es necesario para Visual Studio 2005.
  4. Ya que andas por ahí, selecciona IIS 6 WMI Compatibility.  Este lo necesita SQL Server 2005.
  5. IIS > WWW Services > Common Http Features > HTTP Redirection.  Este también lo necesita SQL Server.

Da clic en OK, y se instalarán los componentes seleccionados.

Como puedes ver, solo necesitas 1, 2 y 3 para desarrollar ASP.NET con Visual Studio 2005.  Y si necesitas SQL Server 2005, agregas las opciones 3, y 4.

Si intentas instalar SQL Server sin lo anterior, es muy probable que recibas una advertencia como la siguiente:

Enjoy smile_shades

Cómo leer archivos planos con ADO.NET (versión Visual Basic 2005)

jueves 13 de diciembre de 2007 | categorías: , , , , | 4 comentarios -- da clic aquí para dejar el tuyo

Hace poco más de un año escribí este artículo que describe una técnica para leer archivos planos utilizando el OleDB provider de ADO.NET.  Es uno de los artículos de este sitio que ha recibido más comentarios, y entre ellos está uno que dejó fredy que me hizo re-hacer el ejemplo en Visual Basic 2005 para comprobar que no fuera un error de código—en realidad él hizo la mayor parte de la chamba para "traducir" la rutina.

No voy a explicar mucho la lógica del código—para eso te dejo de tarea que leas el artículo original—aquí simplemente te comparto cómo se vería la rutina en VB:

Imports System.IO
Imports System.Data
Imports System.Data.OleDb
 
Module Utilerias
   Public Enum TipoDeArchivoPlano
        Delimited
        Fixed
   End Enum
 
   Public Function LeerArchivoPlano(ByVal archivo As FileInfo, _
        ByVal tieneEncabezado As Boolean, _
        ByVal tipoDeArchivo As TipoDeArchivoPlano) As DataTable
 
        If (Not archivo.Exists) Then
            Throw New FileNotFoundException("No se encontró el archivo especificado")
        End If
 
        Dim conEncabezado As String = IIf(tieneEncabezado, "YES", "NO")
 
        Dim connectionString As String = _
            String.Format("Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};" + _
            "Extended Properties='text;HDR={1};FMT={2}'", _
            archivo.DirectoryName, conEncabezado, tipoDeArchivo.ToString())
 
        Dim dt As DataTable = New DataTable("miTabla")
 
        Using conn As OleDbConnection = New OleDbConnection(connectionString)
            Using da As OleDbDataAdapter = New OleDbDataAdapter( _
               "SELECT * FROM " + archivo.Name, conn)
 
               da.Fill(dt)
            End Using
        End Using
 
        Return dt
   End Function
End Module

Para probarla, hice una aplicación sencilla en ASP.NET que mostrara los datos de un archivo .CSV que está dentro de un subdirectorio del sitio web.

El archivo jason.csv contiene:

Producto,Cantidad,Precio
Sierra eléctrica,1,250
Máscara de hockey,1,15.50
Machete,5,2.70
Detergente para ropa (con quita-manchas),1,10
Delantal,2,7.25
Afilador,3,5

La página dentro de la solución que en realidad solo tiene un GridView.  Este es el contenido de Default.aspx:

<%@ Page Language="VB" AutoEventWireup="false" 
   CodeFile="Default.aspx.vb" Inherits="_Default" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
   <title>Leer un archivo plano con VB 2005</title>
</head>
<body>
   <form id="miFormulario" runat="server">
   <div>
        <asp:GridView ID="miGridView" runat="server">
        </asp:GridView>
   </div>
   </form>
</body>
</html>

Finalmente, para mandar llamar la rutina y bindear—¿enlazar?—los datos al GridView, solo agregué esto en el code-behind:

Partial Class _Default
   Inherits System.Web.UI.Page
 
   Protected Sub miFormulario_Load(ByVal sender As Object, ByVal e As System.EventArgs) _
        Handles miFormulario.Load
 
        If Not Page.IsPostBack Then
            Dim archivo As FileInfo = _
               New FileInfo("D:\WebSites\LeerArchivosPlanosVB\Archivos\jason.csv")
 
            Dim tabla As New DataTable
            tabla = Utilerias.LeerArchivoPlano(archivo, True, TipoDeArchivoPlano.Delimited)
 
            If tabla.Rows.Count > 0 Then
               miGridView.DataSource = tabla
               miGridView.DataBind()
            Else
               Response.Write("No hay datos para mostrar.")
            End If
 
        End If
   End Sub
End Class

El resultado de correr la página:

 

Whew! Funcionó smile_teeth

Enjoy. smile_shades


PD.  Puedes descargar el código de este ejemplo del sitio de la Comunidad .NET de Cd. Juárez.

Cómo subir un archivo a tu servidor web mediante el control FileUpload de ASP.NET

jueves 6 de diciembre de 2007 | categorías: , , , | 10 comentarios -- da clic aquí para dejar el tuyo

Este es un tip súper sencillo, pero bastante útil, y como ya van varias personas que me lo preguntan, mejor lo explico aquí.

A menudo se ofrece que los usuarios de nuestra aplicación web nos envíen (o "suban") algún archivo al servidor web donde corre nuestra aplicación ASP.NET. Pudiera ser que el gerentoide tiene un archivo de texto o .CSV que necesitamos leer para cargarlo en la base de datos, o una imágen que vamos a poner como avatar en el perfil del usuario, qué se yo.

Con ASP.NET 2.0 o posterior, subir un archivo a tu servidor es sencillísimo mediante el control FileUpload. Supongamos que tenemos una forma de ASP.NET como esta:

Una forma ASP.NET para subir un archivo a tu servidor web

El markup sería el siguiente:

<%@ Page Language="C#" AutoEventWireup="true" 
   CodeFile="Default.aspx.cs" Inherits="_Default" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
   <title>Subir un archivo</title>
</head>
<body>
   <form id="form1" runat="server">
        <div>
            <h3>
               Cómo subir un archivo a tu servidor web mediante ASP.NET</h3>
            <p>
               Elige el archivo a subir:
               <asp:FileUpload ID="trepador" runat="server" />
            </p>
            <p>
               <asp:Button ID="subir" runat="server" 
                    Text="Subir Archivo" OnClick="subir_Click" />
            </p>
            <p>
               <asp:Label ID="estatus" runat="server" 
                    Style="color: #0000FF"></asp:Label>
            </p>
        </div>
   </form>
</body>
</html>

Como puedes ver la forma en realidad consiste de únicamente de un control FileUpload, un botón para iniciar el postback, y un Label que usaré para mostrar un mensaje. Al botón le asociamos un manejador para el evento Click—que veremos un poquito más abajo.

Las propiedades y métodos relevantes del control FileUpload son:

  • SaveAs(), que se usa para decir dónde quieres guardar el archivo que se está subiendo. Debes proporcionar la ruta completa y el nombre.
  • HasFile, que indica si el usuario ya escribió el nombre de un archivo o lo seleccionó mediante el botón "Browse..."

Ahora, este es el código para manejar el evento:

using System;
using System.IO;
 
public partial class _Default : System.Web.UI.Page
{
   protected void subir_Click(object sender, EventArgs e)
   {
      if (trepador.HasFile)
      {
         string directorio = @"C:\Archivos de Usuario\";
 
         if (Directory.Exists(directorio))
         {
            string archivo = directorio + trepador.FileName;
 
            if (File.Exists(archivo))
            {
               // ya existe un archivo con el mismo nombre en el directorio,
               // así que hay hacer algo al respecto (p.ej. renombrar el que 
               // está en el servidor o asignarle otro nombre al que se está 
               // subiendo), de lo contrario el archivo en el servidor será 
               // sobreescrito
            }
            else
            {
               trepador.SaveAs(archivo);
               estatus.Text = "Tu archivo ha sido enviado exitosamente.";
 
               // 
               // TODO: código para procesar el archivo va aquí...
               //
            }
         }
         else
         {
            throw new DirectoryNotFoundException(
               "El directorio en el servidor donde se suben los archivos no existe");
         }
      }
   }
}

Consideraciones adicionales

Hay dos aspectos más que debes cuidar con esto de la "trepada" de archivos.

Primero, debes asegurarte que la cuenta de usuario bajo la que corre el ASP.NET Worker Process (típicamente la cuenta se llama ASPNET) tenga suficientes permisos de seguridad sobre el directorio donde quieres escribir los archivos en el servidor, de lo contrario verás una excepción de seguridad. Creo que el permiso mínimo que necesita es de Write, aunque yo casi siempre uso el de Modify en mi máquina local.

 Permisos necesarios para que ASP.NET pueda subir (escribir) archivos en el servidor

Y segundo, ASP.NET, por default, está configurado para subir archivos de hasta 4 Mb únicamente (4096 bytes). Esto es porque la petición la recibe IIS primero y debe "tragársela" completa antes de pasársela al Worker Process. Si lo que vas a subir son archivos de texto, pues 4 Mb es un chorro, pero si es otro tipo de archivos—imágenes p0rno, archivos de Word, etcétera—pues esto podría ser terriblemente insuficiente. Si el archivo es muy grande, el otro problema es que la petición de HTTP pudiera exceder el tiempo máximo por petición y hacer timeout. Afortunadamente podemos alterar esto mediante el archivo de configuración del sitio (web.config):

<?xml version="1.0"?>
<configuration>
   <system.web>
      <!--  Requerido para subir archivos grandes. En este caso 
         especificas un tiempo máximo de 10 minutos (600 segundos)
         y un tamaño máximo de archivos de 50Mb
   -->
      <httpRuntime executionTimeout="600" maxRequestLength="51200"/>
   </system.web>
</configuration>

En la configuración anterior exageré un bastante, y deberías tener cuidado de valores como estos, ya que estás indicando que puede haber peticiones de ASP.NET que duren hasta 10 minutos ejecutándose, y esto podría llevar a que tu servidor se sature si de pronto hay varias peticiones grandes. Para la mayoría de las aplicaciones el valor default de 110 segundos (minuto y medio) como executionTimeout es suficiente. Especificar valores grandes para el maxRequestLength, de manera similar, expone tu servidor a ser saturado, así que debes alterar estos valores solo si en verdad lo requieres, y solo para los valores máximos que se necesiten para tu aplicación.

Por último, la documentación de ASP.NET dice que se debe especificar el valor de executionTimeout debe especificarse como un TimeSpan (p.ej. "00:01:50"), pero en la práctica, no he podido utilizarlo así. Siempre he tenido que especificarlo como el número de segundos.

Conclusión

El control FileUpload hace que el problema de subir achivos a tu servidor web sea pan comido. Solo necesitas agregarlo a tu página ASPX y agregar un botón u algún otro control para que invoque la lógica necesaria para copiar el archivo a tu servidor mediante el método SaveAs(). Solo debes cuidar que la cuenta ASPNET tenga los permisos adecuados, y que la configuración del servidor sea apropiada para los tipos de archivos que vayas a subir.

Hay muchas mejoras que se le puede hacer al ejemplo de este artículo. La primera que se me ocurre a mi es proporcionar algún tipo de retroalimentación al usuario de que el archivo se está procesando, o deshabilitar el botón inmediatamente después del click para que el usuario no le de click dos veces hasta que termine de subirse el archivo—estos son problemas bastante comunes cuando quieres subir archivos grandes y ya sea que tu servidor esté algo ocupado o tu usuario sea un neurótico desesperado que no puede esperar ni los 7 segundos promedio como el resto de los seres humanos normales... smile_baringteeth smile_wink pero en fin, esa ya es harina de otro costal, y tendría que hablar de ASP.NET AJAX. Quizá en la próxima.

Enjoy. smile_shades

Ya están disponibles las presentaciones y archivos de ASP.NET

lunes 5 de noviembre de 2007 | categorías: , , , | 0 comentarios -- da clic aquí para dejar el tuyo

Ya tenía un buen sin poder escribir por andar con las carreras del trabajo, pero de alguna forma tuve tiempo de dar el tema y el taller del mes de Septiembre y de Octubre de la Comunidad, donde el tema fue, primero ASP.NET "para novatos", y luego ASP.NET "intermedio".

El primer tema surgió, porque había muchas personas interesadas en comenzar a aprender ASP.NET pero que solo necesitaban una orientada de por dónde empezar.  Así que ese fue el espíritu de la reunión.  Vimos los conceptos fundamentales, basicotes pero necesarios para que entendieran qué estaba sucediendo.  Vimos algunos de los controles básicos, manejo de eventos, y hasta algo de DataBinding con controles como el GridView y DetailsView para hacer una página maestro/detalle.  Para la presentación tomé prestadas algunas de las diapositivas del material que viene en el Desarrollador Cinco Estrellas (que la verdad está excelente), pero le agregué algunas otras ilustraciones que a mi me ayudaron mucho.  Eventualmente, si Diosito me da licencia lo convertiré en uno o dos artículos para este blog porque el rollo que mareador que yo tiro no sale en los archivos jejeje.

 

Como la gente se quedó "picada", votaron por un tema "intermedio".  Así que en la siguiente reunión les platiqué acerca de controles de usuario (user controls), que son controles compuestos a partir de otros controles, de Master Pages, que es una manera de aplicar elementos comunes a todo tu sitio y también sobre todo el armazón de seguridad que agregaron con ASP.NET 2.0.  Escogí esos temas porque creo que son de los más útiles y prácticos en la chamba del día a día.  En el taller vimos con detalle y calma cómo instalar la base de datos de membresía, cómo aplicar seguridad a diferentes áreas del sitio y cómo utilizar todos los controles de membresía y navegación que vienen con Visual Studio.

En fin, me divertí bastante.  Si no pudiste asistir, aún puedes descargar las presentaciones y las soluciones de los talleres desde área de descargas del sitio de la Comunidad.

Enjoy.

Reseña: The Principles of Beautiful Web Design

miércoles 27 de junio de 2007 | categorías: , , , , | 2 comentarios -- da clic aquí para dejar el tuyo

En una plática que di, donde presenté las herramientas Expression de Microsoft, le platiqué al público que cuando se diseña la interfaz de una aplicación--ya sea tipo desktop o Web--hay dos tipos de personas: las que nos gusta tirar código y las que les gusta hacer rectángulos con esquinas redondas y cosas que brincan y hacen fade-in en la pantalla. En el caso de las aplicaciones Web, a los primeros les dicen desarrolladores Web (web developer) y a los segundos diseñadores Web (web designer)--una distinción que al parecer los reclutadores que me llaman nunca han podido entender.

Expression es para el segundo grupo. Pero yo, definivamente pertenezco al primero. Soy de ese tipo de personas que si les pides una aplicación, te sabe hacer la arquitectura, la capa de objetos de negocio, la capa de acceso a datos, servicios, etcétera, es decir, un sitio que funcione perfectamente de pe a pa, pero no me pidas que te diga qué móndrigos colorcitos o que tipo de layout deberíamos usar para las "paginitas", porque no sabría ni por donde comenzar.

Últimamente traía la idea de cambiar el diseño "gráfico" de este sitio/blog, tomando en cuenta que: A) no quería uno de los diseños estándares de Blogger, B) quería algo completamente original, lo cual descartaba usar los templetes que están disponibles en otros sitios como este, este y este, y C) a pesar de que domino CSS a un buen nivel, no sé ni p*** de "diseño gráfico".

Portada - The Principles of Beautiful Web Design Así que se me hizo una buena oportunidad para aprender. Comencé a interesarme por el tema, busqué libros y cuando me topé con The Principles of Beautiful Web Design de Jason Beaird (SitePoint, ISBN 978-0-9758419-6-9) supe que había encontrado el indicado. Este es un excelente libro de apenas 165 páginas--y con muuuchas ilustraciones--donde en apenas 5 capítulos pretende enseñarle a los "programadores" las bases para el diseño de un sitio Web: composición y arreglo (layout), color, textura, tipografía e imágenes. También contiene un montón de enlaces útiles que comparto a continuación.

Composición y arreglo

Aunque algunos de los arreglos en el web son casi estándar--y ni siquiera tienes que quebrarte el coco para echar el CSS requerido--el libro explica bastante bien la teoría de cuadriculado (grid theory), la regla de tercios--así es, no solo se utiliza en la fotografía--y los layouts estándar. Además hace un buen trabajo identificando algunas tendencias recientes que quizá ustedes ya hayan notado.

Un buen argumento que hace el autor, es que para que uno pueda hacer un buen diseño es importante ver varios diseños buenos. Algunos recursos en este departamento son:

Color

Si son como yo, y no saben ni qué colores escoger y combinar para la ropa que se ponen en la mañana, mucho menos para un sitio Web, entonces este capítulo les servirá. Explica desde las asociaciones psicológicas que tenemos con algunos colores, hasta la teoría RGB para combinarlos y poder desarrollar un esquema y paleta de colores basándonos en cuÃ