Consulta para obtener comentarios de una base de datos en #Mysql – diccionario de datos

Algunas veces es necesario obtener los comentarios ingresados en las columnas en una base de datos (diccionario de datos). Sobre todo cuando llevamos una buena .

Aquí anexo un script que sirve para obtener los comentarios de una base de datos en particular:


select table_name,column_name,data_type,COLUMN_COMMENT from information_schema.columns
where table_schema = 'nombreDeLaBD'
order by table_name,ordinal_position

Ya solo es cuestión de remplazar «nombreDeLaBd» por tú base de datos y listo.

Como detectar un verdadero programador senior

Este tema es un poco rebuscado, ya que muchos de los que trabajan en el ambiente de contratar personal desconocen los aspectos técnicos y es por ello que se crea la problemática de no poder diferenciar un programador experto tan fácilmente.

guagua

Yo soy de los que tienen la idea que un currículum es una carta de mentiras donde uno puede ser un súper héroe pero existen puntos clave que te sugiero puedas tomar en cuenta para detectar si un programador es senior o no:

  1. El currículum: el currículum es un medio que presta a la persona a cometer mitomanía pero igual puede la persona misma ahorcarse sola por medio de este. Un currículum lleno de lenguajes de programación es la primera señal de que la persona no tiene nada de senior, así de simple.Es más factible un currículum lleno de herramientas, frameworks o librerías que se engloben a 2 o 3 lenguajes de programación, que todo un libro de colección de lenguajes de programación que no lo hace un experto solo un mentirosillo.
  2. El trabajar en equipo: es poco común que una persona indique en una entrevista de trabajo, cuanto y como ha trabajado en equipo. El trabajar en equipo es de las cosas primordiales, la mayoría de desarrollos son en equipo, y si la persona demuestra que ha trabajado con equipos en lugar de ser un programador solitario (esos programadores que se sienten estrellas) es otro punto extra para demostrar que es un programador senior, un programador senior no es un súper hombre es solo una persona que sabe hacer las cosas bien.
  3. Arquitectura de Software: el conocer conceptos fundamentales de la arquitectura de software, desde básicos como el UML, tipos de arquitecturas, patrones de diseño es tan importante como el saber programar, y a un nivel de senior es algo que debe conocerse por ley.
  4. Base de datos: un senior sabe diseñar una base de datos de cero, también sabe utilizar procedimientos, triggers y funciones en un lenguaje relacional, eso es básico, no digo que sea un DBA pero si tener el nivel de diseñar bien la estructura de la base de datos. Si no sabe hacer esto, esta lejísimos de ser un senior.
  5. Tipos de sistemas: las personas pueden ser senior cuando han resuelto distintos tipos de sistemas, si una persona se la ha pasado haciendo puntos de venta que siempre es lo mismo, el mismo tipo de problema, eso lo aleja demasiado a ser un senior. Un programador senior ha creado sistemas distintos, viéndose en la problemática de diferentes escenarios a los cuales pudo resolver.
  6. Modelo de procesos: si la persona no conoce un modelo de procesos ya sea CMMI, MoProSoft u otro, es probable que no realice software de calidad (es probable porque he conocido personas que no utilizan nada de esto pero crean su propio modelo de procesos sin saberlo y su software es bueno, no excelente pero si es bueno). El no separar el desarrollo del software en procesos indica un sinónimo de ser novato.
  7. Control de versiones: un senior sabe y conoce distintos programas o herramientas de control de versiones de código, si la persona en su vida ha utilizado esto, está lejos de ser un senior. También está lejos de ser un senior una persona que conoce programas de control de versiones pero no le sirve de mucho, nunca sube sus avances (he conocido muchos así y que han perdido hasta 3 semanas de trabajo porque se descompuso su computadora).
  8. Documentar: las personas que no documentan no respetan su trabajo, por lo tanto no son senior (abre un software creado por ti sin documentar hace 2 años, y veras a que me refiero). Documentar el software es tan importante como codificar (esto incluye los comentarios en el código), no documentar el software es crear algo que más tarde nadie sabrá cómo se realizó y se deberá invertir tiempo en ingeniería inversa (como los platillos de marcianos de Roswell).
  9. Honestidad: la honestidad de decir: “No, ese tiempo de entrega es imposible”, la honestidad de decirle al líder de proyecto o al cliente: “eso no está dentro del presupuesto”. La honestidad de saber las limitaciones personales representadas al tiempo del desarrollo son más benéficas que decir si a todo, se beneficia el cliente por no esperar algo que no se le dará, se beneficia el equipo de desarrollo por no involucrarse en tareas imposibles respecto al tiempo, y se beneficia la empresa ya que no quedara mal con nadie. Un senior es honesto en este aspecto.

Existen algunos otros puntos, pero estos para mi son lo primordial para identificar a un senior de un mentirosillo.

EL problema de los departamentos de sistemas en México

Esta entrada está dedicada a un problema que se presenta en la mayoría de empresas mexicanas ajenas al software (que se dedican a otro giro) pero que cuentan con un departamento de sistemas en el cual se desarrolla el software a la medida el cual requiere la compañía.
Enumerare una lista de puntos que para mí engloban la gran problemática en los departamentos de sistemas:

  1. El primer problema radica en que la empresa se dedica a vender un producto que nada tiene que ver con software, por lo cual su departamento de sistemas no es su prioridad, esto ocasiona que el departamento tenga bajo presupuesto, lo cual afecta tanto el equipo a utilizar como el personal a contratar, una empresa de este tipo termina contratando personal por 12,000 pesos al mes en promedio y lo único bueno que tiene para ofrecerle es las prestaciones ya que el ambiente en el que trabajaran deja mucho que desear. Si ofreces bananas, pues obtendrás changos (frase de Alex).
  2. El segundo punto lo centrare en la documentación, en la mayoría de departamentos de sistemas no les pasa por la cabeza documentar su software, no piensan en que pasara cuando el personal encargado de cierto proyecto renuncie o sea despedido, o el nuevo personal que corregirá los bugs o se encargara de terminar sistemas a medias, todo esto solo dirige que su personal siga renunciando, si se tiene un software sin documentación, esperen contratar adivinos ya que ningún programador piensa igual.
  3. Como tercer punto, mencionare a los programadores de la vieja escuela que siguen programando con lenguajes de programación antiguos y lo peor aún es que son lenguajes que ya tienen problemas con los mismos sistemas operativos, todo esto nos dirige a desarrollos que duran mucho más tiempo cuando puede mejorarlos utilizando lenguajes de quinta generación que aceleran el proceso de desarrollo. Este problema en parte es culpa del programador que se cierra a lo que conoce o teme conocer algo nuevo y también es culpa de la empresa, ya que esta última no obliga a su personal a capacitarse pagándoles cursos y certificaciones.
  4. En el cuarto y último punto menciono algo importante y es el hecho de las empresas por no tener un modelo de mejora y evaluación de procesos, por ejemplo CMMI, MoProSoft. Esto es una gran parte de todo el espiral de problemas que hay, ya que no solo se necesita saber programar, se necesita saber organizar el proceso de un software, no solo es que llegue Pepe y te diga quiero esto y en tiempo real vas al código de producción (si directo de producción, no es broma), y se modifica el cambio, después Pepe se enoja por que fallaron cosas que ya funcionaban, pues claro no se sigue una organización para realizar el cambio, es lógico que fallen cosas, y todo esto hace que el sistema valla tomando forma de Frankenstein.

Para concluir yo recomendaría que las empresas le den más importancia al área de sistemas, ya que son el núcleo de su logística, casi todos los departamentos dependen de un software creado en esta área, y siempre el personal de sistemas termina llevándose todas las culpas en la mayoría de ocasiones. Se necesita mejorar los departamentos de sistemas ya que es un beneficio para la empresa, si se mejora los procesos como se realiza un software, con procesos como toma de requerimientos, análisis, desarrollo, pruebas e implementación se puede mejorar en calidad, y la calidad reduce los errores en el software ya que hacer un software cuando Pepe viene a joder pedir un cambio, es un 99% que va a fallar algo, y Pepe tendrá que seguir chingando dando vuelta al departamento hasta que se esté listo el cambio. También las empresas invirtiendo dinero en capacitación a su personal tendrán gente más preparada y no se cerraran en utilizar herramientas de los años 80, a lo cual harán los desarrollos de forma más rápida. Y como ultima sugerencia, optar por tener un modelo de mejora y evaluación de procesos no está demás, ya que esto les daría un estatus de calidad superior y lo cual se vería sin duda reflejado en los ingresos monetarios que obtiene la empresa.

Existen muchos más puntos pero trate de englobar los que creo son los principales.