Mostrando entradas con la etiqueta Ofimática. Mostrar todas las entradas
Mostrando entradas con la etiqueta Ofimática. Mostrar todas las entradas

miércoles, 24 de abril de 2024

OOo Basic

Características del lenguaje OOo Basic

Aunque todos los lenguajes de programación tienen, en lo básico, mucho en común (y oportunidades tendremos de comprobarlo en las entradas de esta sección), OOo Basic (y también VBA) tiene características específicas que interesa conocer desde el inicio de su aprendizaje.



Este lenguaje procede del desarrollado para OpenOffice y se define como lenguaje de macros. Es fundamental entender lo que implica esta categorización, ya que, aunque la considero poco precisa y hasta cierto punto confusa, resumen lo que OOo Basic tiene de específico (insisto: también VBA): es un lenguaje para trabajar desde dentro de las suites OpenOffice y LibreOffice, desde cada uno de sus servicios (Writer, Calc...), como recurso para automatizar procedimientos.

Dentro de eso que se ha venido en llamar competencia digital docente, más específicamente en lo que se refiere a la lógica de programación competencia (un tanto olvidado, como ya tuve ocasión de [comentar]) y más en concreto aun en lo referido a la competencia ofimática ([ver al respecto]), el conocimiento orientado a la práctica de un lenguaje como OOo Basic nos permite hacer un uso mucho más potente y eficiente de unos recursos que (para los SEO) son fundamentales.

Fundamentales por la propia naturaleza de nuestras funciones y del trabajo cotidiano. Y fundamentales también por el ahorro de tiempo que supone lo que deriva de ese conocimiento: la posibilidad de automatizar los procedimientos de trabajo y la creación documental que conllevan. Esto viene a ser equivalente a decir incremento de la competencia ofimática.

El lenguaje OOo Basic aporta, por tanto, ciertas ventajas, aunque también presenta limitaciones que no tienen otros lenguajes de propósito general, no "encerrados" en la suite ofimática (1). Pero ahora me interesa destacar algunas de las innegables ventajas que, en mi opinión, hacen que merezca la pena trabajar con él:
  • Usar OOo Basic (2) implica incrementar exponencialmente el aprovechamiento del conocimiento de los servicios de las suites ofimáticas. Dicho de otra forma, no partimos de cero, y estos conocimientos previos suponen tener andado un buen trecho del camino.
  • En relación con lo anterior, los resultados que podemos obtener con OOo Basic son directamente aprovechables desde los propios servicios, con independencia de cuáles sean éstos y de la frecuencia y familiaridad de uso que tengamos de ellos (3)
  • Las habilidades que se adquieren en el uso de funcionalidades de cierta complejidad se ven potenciadas con el conocimiento y uso de OOo Basic. La relación entre ambos (funcionalidades avanzadas y creación de script) es bidireccional: ambas se potencian, aunque puedan considerarse alternativas.
Podemos resumir todo lo anterior diciendo que OOo Basic como parte que es de la suite LibreOffice complementa y potencia sus funcionalidades, transformando lo que son simples documentos en una especie de aplicación o programa que, además de automatizar la generación de contenidos, incorpora procesos de análisis de datos de cierto nivel de complejidad, tanto como necesitemos o seamos capaces de desarrollar.

La ventaja para el profesional son evidentes: es él mismo el que, desde su conocimiento profesional y de sus específicas necesidades, desarrolla un recurso orientado a proporcionarle ayuda. Es por eso que, aunque podemos enmarcar el uso de OOo Basic dentro del desarrollo de la competencia ofimática, en realidad se supera ampliamente esta delimitación, ya que se adentra en el conocimiento y uso funcional de las habilidades de programación.

Cierto es que nada es gratis, y en este caso se requiere conocimiento del lenguaje. A ello está dedicado este apartado.

NOTAS

(1) Me refiero, por ejemplo, a Python. No es éste un tema que me interesa desarrollar ahora, ya que tiempo y espacio habrá para navegar por esos mares.

(2) O VBA para los que opten por MSO, que en esto del lenguaje no hay mucha diferencia de funcionalidad, aunque si de código, como también de servicios. La apuesta de la Administración educativa asturiana por los servicios de Microsoft no es un secreto. Sus razones tendrá, pero ni el precio ni la utilidad, ni siquiera la versatilidad pueden ser argumentos a favor de esta opción.

(3) Constato reiteradamente que la frecuencia de uso, por si misma, no permite incrementar el nivel de conocimiento que se tiene de ellos. Y lo que es igualmente limitante: los servicios realmente utilizados se limitan al procesador de texto y, muy en segundo lugar, de los servicios de creación de presentaciones. Las hojas de cálculo y no digamos las bases de datos son, en la práctica, auténticos desconocidos. Considero que esto evidencia la insuficiencia de considerar que el uso genera por si mismo un incremento conocimiento de las funcionalidades de las herramientas y consecuentemente un mayor aprovechamiento. Siendo esto así (y lo es), se hace aun más necesaria una formación específica sobre duchas funcionalidades, incluyendo la propia y específica sobre los mal llamados "lenguajes de macros". 

miércoles, 13 de marzo de 2024

Opinión

 Asturias 2024. Nuevo modelo de informe psicopedagógico.

El Servicio de Inclusión Educativa y Formación del Profesorado ha publicado recientemente un nuevo modelo de informe psicopedagógico, siguiendo la ya costumbre de realizar los cambios anuales que ya vienen siendo tradición por parte del Servicio. Tengo la impresión que ganamos (un poquito) en estética (el modelo anterior parecía un tanto avejentado), pero poco más... ¿o puede que un poco menos?.


Para gustos se hicieron colores, así que dejo el tema de la estética a la opinión de cada cual y me centro en lo que interesa desde la perspectiva de este blog.

Desde esa misma perspectiva, y aunque en este caso sea una limitación que impone su temática, me abstengo aquí de comentar cuestiones (fundamentales) relativas a la estructura de contenidos. Son éstas cuestiones mayores que dejamos para otros medios, aunque opinión (basada en el análisis del documento) tenemos.

Pero como todo no se puede, a riesgo de parcializar las cosas (lo cual tiene, como todo, ventajas e inconvenientes), me centraré exclusivamente en lo que toca a parte importante (que no única) de nuestra temática: la competencia ofimática de los SEO.

Muy cierto es que este documento, uno de los que determinan y mucho el trabajo de los SEO, evidencian precisamente la necesidad de desarrollar esa (sub)competencia como específica de estos servicios. Toca también a eso que ya hemos tratado como responsabilidad (no asumida, ahora tampoco) de la Administración: proporcionar herramientas de utilidad para los profesionales y predicar con el ejemplo en eso de ser digitalmente competentes. 

Está claro que la competencia ofimática del Servicio de Inclusión no es mayor que la de los profesionales de los SEO. También que se preocupan bien poco por facilitarnos el trabajo. ¿Será que no es esta una de sus prioridades?.

Dejando las ironías a un lado (que lo mucho enfada) me voy a centrar en explicar ahora por qué considero que este bonito documento no supone ningún avance en términos de competencia digital ni ofimática, sí acaso algún retroceso, empezando por éste.

Precisamente la novedad parcial en la apariencia (encabezado con escudo a parte), se concreta en las tablas 2, 3 y 4 de la carátula (en la 4 sólo parcialmente), considerando como primera tabla (que lo es, aunque no lo parezca a simple vista) la que sigue al título y precede al apartado 1 (Datos personales...).

Estas tablas reflejan un intento por simplificar la formulación de sus correspondientes en el modelo anterior de informe (en realidad en ya unos cuantos modelos anteriores) y aparentemente esa simplificación tiene un efecto visual de mayor claridad. Punto a favor del cambio. Pero en realidad suponen un retroceso (y un modo menos eficiente de usar tablas) para quien tiene que utilizar este documento-modelo: no es que en esto, el modelo previo fuera un dechado de virtudes, ya que las ventajas (que comento a continuación, para no hacerme más de rogar) eran parciales y se limitaban al manejo individual de cada tabla, pero ahora ni eso:

  • Eliminar las subdivisiones obliga a utilizar el ratón o las teclas de desplazamiento (flechas) para posicionarse en cada uno de los campos. Si se mantuvieran las subdivisiones sería posible resolver el problema utilizando directamente el tabulador.
  • La consecuencia de esa simplificación de estructura es convertir la tabla en una meja "caja de texto", que puede resultar visualmente atractiva, pero que no es más que mero adorno.
  • Dado que los campos implicados son unos cuantos campos (afortunadamente esa simplificación no se aplica también a la tabla 6 (Medidas...), nada menos que  15, aunque en la tabla 4 (8 campos) el problema se reduce (que no se anula), precisamente porque las modificaciones realizadas en ella son parciales (se mantienen, aunque ocultas).
  • Los cambios de apariencia (beneficiosos, a mi juicio) no tienen por qué implicar modificaciones en el funcionamiento de las tablas: es perfectamente posible mantener las subdivisiones de filas y celdas sin que tengan por qué verse las líneas que las delimitan, así que esta simplificación (total en las tablas 2 y 3, parcial en la 4) no están justificadas.
Realmente la cumplimentación de las carátulas no es, ni mucho menos, lo más trabajoso de un informe, así que el ahorro de tiempo que podemos conseguir es mínimo; pero no es depreciable si tenemos en cuenta que esta parte del trabajo se repite tantas veces como informes se elaboren. Dado que el mismo procedimiento de simplificación se ha aplicado al modelo de Dictamen, el trabajo se incrementa.

En fin, que en vez de mejorar (que falta hace), empeoramos. Casi duele más que no mejoremos que lo que empeoramos, es verdad, pero es significativo que se produzca este empeoramiento justo cuando tanto bombo se da al desarrollo de la competencia digital docente. Los olvidos y las deficiencias se pagan, también dar por sentado lo que no necesariamente está conseguido:
  • La ofimática se da por dominada, y no es cierto.
  • Los SEO necesitan una definición competencial específica que incluya ese dominio, que en realidad es limitado. Parece que también el de los asesores del servicio de Equidad.
  • La Administración debe preocuparse también de facilitar el trabajo de los profesionales, no sólo reglamentar y ajustar éste a las exigencias de la norma y/o a sus líneas de trabajo. Y mucho menos limitarse exclusivamente a resolver "sus" problemas de gestión.  
  • La Administración, por coherencia, debería impulsar también el desarrollo competencial que pretende para los demás, dando ejemplo de ello en la práctica, por ejemplo en los modelos documentales que prescribe.
Lo triste (porque lo es, aunque no vamos a llorar), es que la solución es bien sencilla, aunque de efecto limitado. Aplicando la que propongo, no sólo se evitaría este retroceso, además se conseguiría un modesto avance: en vez de eliminar las subdivisiones de las tablas, y en vez de mantener una estructura de tabla diferenciadas, para facilitar el posicionamiento y el desplazamiento por cada uno de los campos (y facilitar así la cumplimentación de la carátula), la alternativa es bien simple: crear una única tabla, aunque nos interese (y se mantenga) la apariencia multi-tabla y se elimine la visualización de las subdivisiones que no resulten "atractivas" visualmente. Así se mantendría la funcionalidad (se mejoraría, en realidad), ya que posicionamiento y desplazamiento se realizan a golpe de tabulador, con la ganancia de comodidad y tiempo, sin renunciar a una presentación más simplificada, funcional y atractiva.

Quedan, no obstante, muchos otros pasos que dar para llegar a un nivel satisfactorio de (semi)automatización del documento Informe (y del dictamen, que es, en esto, más sensible), siendo el siguiente (que no el último) emplear funcionalidades pensadas para dar respuesta a esta necesidad, e incorporadas en el propio servicio ofimático (Word), las cuales requieren, eso sí, ser conocidas y utilizadas expresamente: me estoy refiriendo, por ejemplo, al uso de campos dinámicos (por ejemplo).

Hay alternativas mejores, aunque también más complejas, como la creación de macros y/o script basados en la funcionalidad Grabar macro, y mejor aun en el conocimiento y uso del lenguaje de macros (en este caso VBA, por seguir en el mundo Word, que no es el único procesador de texto, ni necesariamente el mejor, pero esta es otra cuestión). Hay además otras alternativas, que suponen el conocimiento y la practica de la programación; pero hablar de ello es elevarse demasiado respecto a nuestro real suelo actual.

Por cierto, no puedo afirmar rotundamente que la IA no sea una ayuda en ese proceso de automatización de documentos como el Informe psicopedagógico, pero sí puedo asegurar que, a día de hoy (vale más ser cautos), no es una herramienta que nos resuelva los problemas reales que inciden ni en el logro de este objetivo (la automatización de la documentación), ni mucho menos nos evite el trabajo de tener que hacer un informe. Y en esto, además, yo sería muy cauto: los riesgos están ahí y las responsabilidades son muchas.

Creo que no nos queda otra que seguir trabajando mucho y bien, tanto para automatizar el informe como para redactarlo. Y en cuanto a lo primero, las herramientas más fiables siguen siendo las formas tradicionales de programación.


Documento
  • Asturias. Modelo de informe 2024
  • Versión reformada. Aunque era el objetivo y se acerca suficientemente a él, esta versión del modelo de informe no refleja totalmente lo que se pretende unificando tablas (se mantienen 2, una por para apartado) debido a que fue construido sobre la versión oficial, lo que conlleva dificultades de formato que afectan al uso del tabulador.

Presentación.

Competencia ofimática

Cuando hablé de cómo entendía la competencia digital de los SEO y de los motivos por los que consideraba inadecuando el enfoque de esta cuestión por parte de la Administración (si no la simple ausencia de atención a las necesidades específicas de estos servicios), insistí en la necesidad de desarrollar lo que llamé competencia ofimática creativa.

Ahora, tras concretar la base documental que tomo como referencia, entiendo que queda justificada la razón de esas valoraciones y de la propuestas que planteo, ya que en ella es abrumador el predominio de los servicios ofimáticos, destacando ampliamente a nivel cuantitativo el uso del procesador de texto.

Pero que el uso de este servicio ofimático sea tan frecuente, es evidente que no garantiza, por sí sólo, el aprovechamiento de sus funcionalidades, especialmente de aquellas que, de una u otra forma, permitirían reducir el coste de tiempo que supone su uso. Esta es una realidad incontestable, tanto en la documentación elaborada por los profesionales como en los modelos documentales que aporta (e impone) la propia Administración educativa.

Podemos pensar, con escaso margen de error en este caso, que si no se aprovechan las funcionalidades disponibles, es aun más difícil que se de el paso a crear procedimientos de (semi)automatización basados en el conocimiento de lenguajes de programación. De hecho no he encontrado ningún documento en que se emplee esta opción, aunque es posible que los haya. No estoy en condiciones de negar esta posibilidad, pero sí puedo afirmar (y creo no equivocarme) que en el mejor de los casos es minoritaria, extremadamente minoritaria.

Las razones de que esto sea así (que lo es), son varias y considero que razonables (valga la redundancia):

  • La primera deriva de la propia excepcionalidad (cuando no ausencia) del uso de funcionalidades de uso "minoritario": Combinar correspondencia, uso de formularios, recursos de automatización de documentos (como los campos dinámicos)...
  • La segunda, en estrecha relación con la anterior, es el desconocimiento de la funcionalidad Grabar macro, que se acompaña, como medida preventiva, del miedo a trabajar con macros, debido a la mala fama que (puede que justificadamente) tiene este código.
  • La tercera deriva de la anterior (de las macros) y su desarrollo se ve frenado, en primer lugar, por los dicho respecto a las macros, pero también por la presunción de dificultad que se atribuye a dar el paso que conlleva un cambio, en realidad, cualitativo importante, y no sencillo: adentrarse en el IDE para comprender el código que genera Grabar macro e interesarse por conocer el lenguaje de macros.
  • La cuarta y final (por no hacer más largo este listado) es la falta de tiempo (y de interés inmediato) por el aprendizaje de la lógica de programación que subyace en paso anterior y en otros que se podrían dar respecto al estudio de alternativas al uso de macros.
Todas estas razones, y otras que pudiera dar, se pueden resumir como sigue: 
  • Los profesionales de los SEO se ven impelidos por el ritmo del trabajo diario a usar lo conocido sin adentrarse en novedades que tienen un coste inicial de aprendizaje (y de tiempo y esfuerzo). Como suele suceder, lo urgente se impone a lo importante.
  • El desconocimiento genera suspicacia, cuando no rechazo: ya que lo que no sobra precisamente es tiempo, ¿para qué me voy a entretener aprendiendo cosas de dudosa utilidad, y más aun trabajar con lo que me puede crear problemas? (el primero, tener que aprender a programar y meterme a descifrar código que resulta ser (a primera vista) un galimatías).
  • Lo que yo necesito son herramientas funcionales. Que me las dé hechas la Consejería (el Servicio de Equidad, en este caso), que son los que tienen los medios (o podrían tenerlos); no tengo que ser yo el que haga el esfuerzo de crearlas, que ni ganas ni tiempo tengo.
Podrían matizarse estas expresiones, pero creo que ofrecen un panorama cercano, muy cercano, a la realidad; así que no nos queda más remedio que constatar que, realmente, "la cosa no está nada fácil".

También son expresión de la falta de consistencia de la idea de que saber programar es una competencia (digital) general e inespecífica que no es necesario (¿ni conveniente?) incluir dentro del catálogo de competencias digitales docentes. Y por ahí van (en primer lugar) los tiros: sin una apuesta decidida de la Administración por el aprendizaje de los principios básicos de la programación (dentro del llamado pensamiento computacional y su concreción como conocimiento de la lógica de programación), serán pocos los orientadores que se adentren en tan complejos como irrelevantes (cuando no "peligrosos") mares.

Falta también predicar con el ejemplo y proveer a los profesionales de los SEO de herramientas que hagan uso de este tipo de recursos y, de paso, sean expresión  de su utilidad.

La primera medida y sus consecuencias formativas derivadas no resultaría difícil de poner en marcha, si existiera convicción y voluntad (creo que faltan ambas) por parte de la Administración.

La segunda es más "difícil" de conseguir ya que hace falta que la Administración educativa piense un poco en facilitar el trabajo de los profesionales y consecuentemente invertir en la creación de recursos que lo hagan realidad. Los derroteros parecen ir por otro camino: la preocupación principal de la Administración educativa, cuando considera necesario "aportar" soportes para el trabajo de los SEO, es más bien controlar cómo se desarrolla éste y hacer se cumplan los criterios de legalidad y calidad que se considera necesario alcanzar. Decir que mira únicamente para su comodidad puede ser excesivo y no considero que esté justificada una aseveración semejante.

Y sin embargo es necesario. Hace falta incluir como competencia específica la competencia ofimática y es necesario también que esta competencia no se limite a convertir al orientador en mero usuario "avanzado" de los servicios ofimáticos; además debe ser capaz de ser un creador de soluciones, aunque sean puntuales, parciales y limitadas. Para ello es necesario también que los SEO sean conocedores, al menos, de cómo se trabaja con los lenguajes de macros.

Pero, ¿por qué estas necesidades?, ¿ cómo se justifica el coste económico y de tiempo y esfuerzo que todo esto conlleva?. He aquí algunos motivos:
  • Es cierto que la calidad de la intervención de los SEO no es una cuestión de uso-no uso de los medios informáticos, pero este uso mejora aspectos importantes de esa intervención. Entre otras cosas permite un ahorro de tiempo que se puede destinar a desarrollar las actuaciones que se consideren necesarias.
  • Comparto que lo que realmente se necesita, y donde hay que "echar tiempo" es en definir y concretar modos de intervención no centrados en "lo burocrático"; pero "lo burocráticos" es consustancial con la intervención de los SEO, por lo que resulta ineludible. Los recursos informáticos son herramientas imprescindibles para abordar estas tareas, cuanto más nos simplifiquen el trabajo, mejor. 
  • Es verdad que el conocimiento y uso de las funciones "avanzadas" de los servicios ofimáticos no resuelve lo importante del proceso de elaboración de estos documentos, pero no es cierto que el resultado de su empleo sea una mera cuestión de estética ya que contribuyen (unos más y otros menos) a facilitar el trabajo.
  • Emplear código para automatizar el uso de la documentación acentúa y mucho esa facilitación del trabajo, reduciendo en gran medida el tiempo empleado. Requiere conocer bien el contenido y modo de empleo de ese documento y utilizar, como mínimo y punto de partida, la funcionalidad Grabar macro. A partir de ahí se requiere conocer un lenguaje de programación (al menos un lenguaje de macros) y saber emplearlo para crear los elementos del código necesarios.
  • Este último paso supone aprendizaje y práctica. La propia práctica puede ser la guía del proceso de aprendizaje, pero en un momento determinado hay que estudiar el lenguaje de una forma más sistemática. Existen muchos recursos en la red (este blog mismamente) que te pueden ayudar en este proceso.
  • Los resultados que se obtienen gracias a la programación son en si mismos una recompensa, pero si además nos planteamos resolver problemas prácticos (que es el verdadero objetivo de todo esto), estarás en disposición de crear aplicaciones a la medida de tus necesidades. Puede que no sean las más eficientes del mundo, pero ninguna otra te habrá servido de tanto. Además nada impide que combines el uso de aplicaciones comerciales (o simplemente de otros) con el uso de las tuyas propias.
  • La competencia que alcances tú refuerza y/o complementa la que desarrollen otras personas. Comparte tus resultados (también tus dudas y fracasos) en contextos colaborativos. Esta colaboración incrementa la competencia del colectivo.

lunes, 27 de noviembre de 2023

Python. Aplicación.

Hojas de cálculo con Python

Ya vimos que una de las opciones disponibles para automatizar el trabajo con servicios ofimáticos mediante Python consiste en implementar librerías específicas para trabajar con MSO, concretamente con Word y con Excel. Dada la compatibilidad entre MSO y LibreOffice, aunque la suite no sea LO, esto no impide que finalmente podamos trabajar desde esta suite, utilizando incluso script OOoBasic para complementar la automatización del documento.


En una entrada anterior traté el trabajo con Word, así que en la presente me centraré en una de las opciones para trabajar con Excel: la librería OpenPyXL. Además del anterior (web oficial), al final de la entrada te dejo algunos enlaces de interés.

Aunque las posibilidades de uso son muchas, por el momento me voy a limitar a lo más básico: lo equivalente a lo hecho con Word/Writer, aunque sin entrar en comparaciones entre el uso de OOoBasic y Python, ya que ese discurso y sus implicaciones quedaron dichas en una entrada precedente respecto a un ejemplo práctico. Me parece más útil ahora centrarme en el uso básico de OpenPyXL con el objetivo inmediato de alcanzar el conocimiento necesario para desarrollar aplicaciones similares a los docap simples que podemos crear con OOoBasic; esto nos permitirá dar posteriormente algunos pasos en esa dirección.

Para ello expondré cómo crear un libro Excel, cómo acceder a un libro previamente creado, cómo acceder a una hoja concreta del libro y los rudimentos del trabajo con celdas: lectura y escritura de contenido. Estos conocimientos me permiten emular las acciones básicas que desarrollamos en OOoBasic (script y/o macros), por lo que, como dije antes, nos situamos en Python en niveles de competencia similares a los que nos han permitido crear docap sencillo en OOo Basic. Creo que el camino que debimos recorrer en OOoBasic para llegar a ese nivel y el que vamos a recorrer ahora en Python es un buen ejemplo del potencial de este lenguaje.

Lo primero que tenemos que hacer para trabajar con OpenPyXL es instalar este paquete para que está disponible en Python, ya que no es una de las librerías que trae Python en su instalación de base. Como ya vimos respecto a python-docx, la instrucción necesaria (pip install openpyxs) de escribe en el cmd, tras el prompt C:\Users\NombreUsiario> (sea NombreUsuario el que corresponda en tu ordenador).

Lo segundo que debes hacer, ahora ya en la creación de un script Python, es importar la librería instalada. La forma más simple, que no la única, pero sí la que vamos a utilizar por ahora, es la instrucción import opnepyxl escrita siempre y necesariamente al inicio del script (puedes, eso sí, escribir algún comentario explicativo de lo que se pretende con el script; es más, te lo recomiendo)

Pasemos ahora a crear nuestro primer archivo Excel, algo tan sencillo en Python como lo siguiente:

libro = openpyxl.Workbook()
libro.save("PrimerLibro.xlsx") 

La primera línea de instrucciones asigna a la variable libro la creación del libro excel mediante la función Workbook(). La segunda guarda el libro creado con la función save().(1) Sin esto, el libro no se guardará, por lo que perderemos todo el trabajo que hagamos en el script, así que es muy importante finalizar este con una instrucción save() y lo que corresponda escribir dentro del paréntesis, claro.

Existe un modo alternativo y simplificado de crear un libro excel:

  • Primero importamos OpenPyXL incluyendo en la solicitud la expresión Workbook del siguiente modo:

from openpyxl import Workbook

  • Después creamos la variable libro y asignamos la función Workbook()

libro = Workbook()

Como puedes ver, de este modo lo que hacemos es omitir openpyxl de la expresión openpyxl.Workbook(), pero el resto del procedimiento es igual, así que puedes optar por una forma o por otra, que el resultado será el mismo.

Entre paréntesis escribimos, como parámetro de la fución, el nombre del archivo y la extensión (.xlsx), ambos como cadena de texto. La forma empleada en el ejemplo, crea el archivo excel PrimerLibro.xlsx en el mismo directorio en el que esté ubicado el script python. Para indicar otra dirección deberemos señalarlo como parámetro. Un ejemplo podría ser...

libro.save("C:/Users/NombreUsuario/Desktop/PrimerLibro.xlsx")

Donde pone NombreUsuario deberás escribir el que corresponda. Observa además que he invertido la  barra separadora que genera windows por defecto.

C:\Users\NombreUsuario\Desktop\PrimerLibro.xlsx

Para ahorrarte experimentos condenados al fracaso: puedes utilizar la extensión Calc para nombrar el fichero (PrimerLibro.ods) y se creará el archivo sin ningún problema, pero cuando intentes abrirlo desde Calc te encontrarás con un menaje de error y no podrás acceder a él. Por el contrario, un archivo de extensión xlsx podrás abrirlo perfectamente desde Calc y trabajar con él sin mas problemas. Después ya decides tú si lo conviertes al formato .ods o lo dejas como .xlsx. Por cierto, Calc crea ficheros xlsx desde la opción guardar como... Excel 2007-365.

Resuelta la primera cuestión, vamos a plantear la segunda. Antes creamos un libro (de momento no hicimos nada en él), pero ahora nos planteamos que lo que necesitamos no es crear un nuevo libro, sino acceder a uno ya creado.

En este caso, después de importar el módulo openpyxl (2), podemos plantearnos también dos opciones: 

  • La primera consiste en crear una variable ruta (path, si prefieres) y después utilizarla para acceder al archivo. Esta opción es válida para cualquier ubicación del archivo al que deseamos acceder.

ruta = "C:\\Users\\NombreUsuario\\Desktop\\NombreArchivoExcel.xlsx" (3)
libro = openpy.load_workbook(ruta)

  • La segunda forma consiste en utilizar directamente el nombre del libro excel en la instrucción de apertura. Esta opción es útil (y yo diría que recomendable) cuando el libro excel se encuentra en el mismo directorio que el script Python.

libro = openpy.load_workbook("NombreArchivoExcel.xlsx")

Una vez que hemos accedido al libro deseado, o que lo hemos creado, (obviamente antes de guardarlo si queremos que surta efecto lo que hagamos en él) nos podemos plantear diferentes tareas, pero todas ellas pasan por acceder a una hoja, en primer lugar, y por acceder a una celda en particular. Resumiendo, que nos interesa saber cómo manejarnos con las hojas del libro y con las celdas de las hojas. A ello vamos a continuación, empezando por las hojas.

Cuando creamos un nuevo libro, inicialmente sólo tiene una hoja, pero cuando cargamos uno ya creado, nos puede interesar saber cuántas hojas tiene; para ello emplearemos la siguiente instrucción...

print(libro.sheetnames) 

... después de haber asignado a libro el acceso al archivo cargado, por ejemplo...

libro = openpy.load_workbook("NombreArchivoExcel.xlsx")

La instrucción anterior imprime en pantalla (cmd) una lista con los nombres de las hojas que contiene el libro, en mi caso ['Hoja0', 'Hoja1']. Esto nos permite trabajar con las hojas como podemos hacerlo con cualquier lista python, por ejemplo, conocer el número de hojas del libro con la función len()

lista_hojas = libro.sheetnames
num_hojas = len(lista_hojas)
print(num_hojas)                     
-> devuelve 2

Con frecuencia vas a necesitar añadir nuevas hojas a un libro. No en el caso de acceder a un libro creado previamente, pero sí seguramente en caso de crear un libro mediante Python, ya que lo que se crea es un libro básico de una única hoja. Vamos, entonces a aprender cómo crear nuevas hojas mediante OpenPyXL. 

Estas son las diferentes formas con que podemos crear una hoja (4). 

hoja1 = libro.create_sheet("Hoja_Creada") -> Crea la Hoja_Creada al final del libro
hoja2 = libro.create_sheet("Hoja_Ini",0) -> Crea la Hoja_Ini al inicio del libro
hoja3 = libro.create_sheet("Hoja_Fin",-1) -> Crea Hoja_Fin en la penúltima posición 

También nos puede interesar borrar una hoja creada, por ejemplo, la hoja Hoja_Creada que posicionamos al final del libro. Para ello utilizaremos la función remove() mediante la siguiente instrucción:

libro.remove(libro['Hoja_Creada']) -> Observa que estamos trabajando con una lista

Una vez creadas las hojas necesarias (y borradas las no deseada), necesitamos actuar sobre cada una de ellas, lo que supone acceder a la hoja activa

Debemos saber que, por defecto, la hoja activa es, por defecto, la hoja que ocupa la posición 0. Por ejemplo, según lo hecho mediante las anteriores instrucciones de creación de hojas, la que ocupa la posición 0 es la hoja llamada Hoja_Ini, así que...

hoja_activa = libro.active

print(hoja_activa.title) ... nos devolverá  Hoja_Ini

... y podemos aprovechar este procedimiento para modificar el nombre o título de la hoja mediante...

hoja_activa.title ="PrimeraHoja" (5)

Pero aun más interesante para el manejo básico del código es posicionarse en otra hoja, lo que es lo mismo que desplazar el foco (la condición de hoja activa) a esa nueva hoja. Para ello volvemos a trabajar sobre la lista de hojas del libro mediante las siguientes instrucciones:

hoja_activa = libro['Hoja_Fin']
libro.active = hoja_activa

... de modo que se ahora pedimos el nombre de la nueva hoja activa (print(hoja_activa.title), ahora nos devolverá Hoja_Fin, lo mismo que si lo pedimos de este modo: print(libro.active.title)

Para un uso básico de OpenPyXL, nos falta aprender a acceder a las celdas, cosa que ahora ya estamos en disposición de hacer, una vez que hemos sido capaces de acceder a una hoja y convertirla en hoja activa. Esto quiere decir que, al menos una de las formas de acceder a una celda pasa por las siguientes fases:

  1. Accedemos al libro
  2. Accedemos a la hoja (la hoja activa)
  3. Y finalmente accedemos a la celda que nos interesa, que, supongamos, es la celda A5.
El procedimiento ahora es sencillo (suponiendo resueltos los pasos 1 y 2):

celda_interes = hoja_activa['A5']

Otra forma consiste en utilizar las referencias de columna y fila:

celda_interes = hoja_activa.cell(row=5, column=1)

... y la mejor forma de saber a ciencia cierta que estamos trabajando sobre la celda A5 es pedir su contenido:

print(celda_interes.value) -> Nos devuelve None, ya que está vacía, pero...

Podemos atribuir valores (contenido) a cada celda de forma muy sencilla:

  • Asignando el valor directamente a la celda:

hoja_activa['A5'] = 10
celda_interes =hoja_activa['A5']

  •  Usando la notación fila-columna y el argumento value

celda_interes =hoja_activa.cell(row=5, column=1,value=10)

  • O actualizando la propiedad value de una celda

 celda_interes = hoja_activa.cell(row=5, column=1)
 celda_interes.value=10

Si ahora solicitamos el valor de la celda...

print(celda_interes.value)

... nos deberá devolver 10 en todos los casos. 

No está todo dicho, ni mucho menos, sobre lo que podemos hacer con OpenPyXL, pero esta entrada está siendo ya demasiado extensa, y como tenemos los fundamental para empezar a trabajar, mejor será dejarlo así de momento, pero con una propuesta de trabajo sencilla:

  1. Crea un libro excel nuevo en el mismo directorio que el script Python
  2. Cambia el nombre de la primera y única hoja disponible a "DATOS"
  3. Escribe en esa hoja un "a modo de formulario" de datos de identificación:
    • A1 -> "Datos de identificación"
    • A2 -> "Nombre" - C2 -> alum_nombre
    • A3 -> "Apellidos" - C3 -> alum_apellidos
    • A4 -> "Curso/Nivel - C4 -> centro_nivel
    • A5 -> "Centro" - C5 -> centro_nombre
Te dejo mi script para que lo compares con el tuyo. Corre de tu cuenta mejorarlo y/o crear otros ejemplos de código sencillo.

Enlaces:

NOTA 1. Fíjate que Workbook() se escribe con primera letra en mayúscula, pero que save() se escribe todo en minúscula. Esta diferencia es fundamental en Python y deberás escribir ambas funciones exactamente como te indico, así evitarás un mensaje de error innecesario.

NOTA 2. De una forma  - import openpyxl - o de otra - from openpyxl import Workwook - como vimos antes. Yo opto por la primera forma, de ahí que después acceda al archivo empleando la instrucción que incluye la llamada a openpyxl.

NOTA 3. Observa que he usado dos formas diferentes de separar las carpetas de la ruta: mediante dos barrar inclinadas hacia la izquierda (\\) y mediante una inclinada hacia la derecha (/). En Windows ambas surten el mismo efecto.

NOTA 4. Respecto a hoja2 y hoja3los valores de posición 0 y -1 (posición inicial y posición anterior a final, respectivamente) pueden ser sustituidos por otros valores, siempre que exista un número de hojas que lo permita.

NOTA 5. Si ahora pedimos saber la hoja activa mediante la función print() [print(hoja_activa.title], ahora nos devolverá PrimeraHoja en vez de Hoja_Ini.

jueves, 26 de octubre de 2023

Python. Aplicación.

Documentos específicos mediante Python

Python nos ofrece también la posibilidad de crear mediante script documentos genuinamente específicos de servicios ofimáticos. Esto es posible mediante el uso de bibliotecas de módulos o paquetes de funciones que previamente deben ser instalados e importados. Me refiero concretamente a la creación desde script Python de documentos Word, Excel o Acrobat. Los dos primeros son accesibles desde Libre Office gracias a la compatibilidad que esta suite mantiene con MSO, por lo que crear un documento Word o Excel es equivalente a crear un documento accesible desde LO-Writer y LO-Calc respectivamente. Y lo es en sentido pleno: LO puede trabajar con esos documentos como si fueran propios.


Así que mantengo como icono de esta entrada el mismo que en las anteriores referidas al uso de Python como herramienta para el trabajo con recursos ofimáticos, aunque en este caso una representación más adecuada del planteamiento de trabajo sería la siguiente:


Ésta no es una representación totalmente satisfactoria del modo 1A2, ya que no lo es al completo, al faltar formatos como .pdf, pero también otros que no explicité en el esquema inicial (como .cvs, por ejemplo), ni lo es en sentido estricto, ya que en esta entrada me voy a limitar a exponer cómo desarrollar la rama superior de esta representación (documento de texto), dejando para una posterior entrada el trabajo sobre  la rama inferior (hoja de cálculo) Esta división, que facilita la coherencia con otra documentación (1), está justificada por la complejidad de la temática que aborda, que exige realizar cuanto menos un primer acercamiento a temas como el uso de bibliotecas externar en Python, incluyendo su instalación y uso dentro de los script a crear. También parece una exigencia lógica que deriva de la complejidad de la propia biblioteca que facilita a Python  el trabajo con documentos Word.

En efecto, para desarrollar esta línea de trabajo (1A2) es necesario, en primer lugar, entender que Python, tal y como se instala en origen ofrece nada más que la punta de un iceberg de posibilidades, siendo posible (y necesario) implementar bibliotecas, paquetes de funciones o módulos, nuevas clases... (a gusto del consumidor) para desarrollar procesos específicos de trabajo, como es el caso de la creación de soportes ofimáticos (en este caso documentos MSO-Word).

Este proceso tiene cierta complejidad, aunque esta suficientemente simplificado gracias a los recursos disponibles en Python. A mí me ha servido parta entenderlo, además de la lectura de documentación, la explicación que proporciona Errodinger en este vídeo. Considero que es una buena síntesis de las opciones disponibles y de cómo proceder. No es el único recurso disponible, pero sirve para empezar.



En síntesis, la opción básica de instalación es el comando pip install NombreLibreria aplicado desde el cmd, tal y como te muestro en este vídeo que grabé mientras instalaba la librería para trabajar con documentos .docx. Para su visualización recomiendo la opción Pantalla completa


La instrucción completa es pip install python-docx, a escribir tras la cadena que genera Símbolo del sistema (consola o cmd) C:\Users\NombreUsiario>

Una vez instalada la librería python-docx, existen dos formas de saber si forma parte de las librerías instaladas, podemos utilizar indistintamente pip freeze o pip list (ambas desde Símbolo de sistema,cmd o consola) que listan todas las librerías, paquetes (de módulos) o clases instaladas y su versión (2)

Además, y ahora desde el IDE, podemos comprobar si un paquete está correctamente instalado (esto es, si funciona) utilizando la instrucción import NombreLibreria: si funciona correctamente no obtendremos ninguna respuesta (el intérprete queda a la espera), pero si no funciona obtendremos un mensaje de error. Por ejemplo, import doc devuelve...

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import doc
ModuleNotFoundError: No module named 'doc'

        Otra instrucción que nos interesa conocer, también a aplicar desde IDE, es dir(NombreLibreria), que nos devuelve el conjunto de funciones o métodos de que dispone la librería en cuestión. Por ejemplo, dir(docx) devuelve...

        ['Document', 'ImagePart', 'RT', 'TYPE_CHECKING', 'Type', '__all__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__', 'annotations', 'api', 'blkcntnr', 'dml', 'document', 'drawing', 'enum', 'exceptions', 'image', 'opc', 'oxml', 'package', 'parts', 'section', 'settings', 'shape', 'shared', 'styles', 'table', 'text', 'types']

        Saber cuáles son los componentes de la librería es útil como síntesis, pero no  es suficiente cuanto estamos iniciando el aprendizaje del funcionamiento de un paquete, así es conveniente disponer de información más detallada, sobre componentes, funcionamiento y ejemplos. Para ello es recomendable consultar los siguientes enlaces (3):

        Pasemos ahora a la crear un documento Word. Únicamente es una ejemplificación de esta opción para constatar su funcionalidad tal y como se representa en este esquema del modo externo (modo 1)


        El script ha sido creado desde el IDE estándar de Python y modificado desde bloc de notas. Con esto quiero significar que, al menos para elaborar recursos básicos no es necesario trabajar con IDE complejos ni especializados. Este es el script...

        from docx import Document #-> Acceso a la librería docx para importar el método Document

        document = Document() # -> Creamos un documento mediante la función Document()

         # Escritura del encabezado del documento mediante la función add_heading()

        document.add_heading('Escritura de texto en formato Word. Modo 1A2')

         # Siguen a continuación tres modos de escribir contenido (párrafos)

        paragraph = document.add_paragraph('Primer párrafo: Texto escrito directamente mediante asignación de contenido a variable.')

        p = document.add_paragraph('Segundo párrafo: Texto plano seguido de texto en ')
        p.add_run('negrita').bold = True
        p.add_run(' y texto en ')
        p.add_run('itálica.').italic = True

        texto_parrafo3=input("Escribe el tercer párrafo")
        paragraph = document.add_paragraph(texto_parrafo3)

         # Finalizamos  guardando el documento creado mediante la función save()

        document.save('textopruebaword.docx')

        ... y este el resultado (captura de pantalla del documento Word). Te recomiendo que descargues el script Python, analices y repliques el proceso. Aunque no es obligatorio, te sugiero que guardes el script en la unidad D:
         

        Con lo anterior he desarrollado el proceso representado en el esquema precedente hasta el punto en que se crea un documento Word. Aquí puede finalizar el proceso, pero también podemos continuarlo accediendo al documento desde LO-Writer.


        Efectivamentea diferencia de los modos 1A1 y 2B, en 1A2 el uso de LibreOffice no es necesario salvo como recurso para visualizar el contenido del documento y como alternativa a MSO-Word, dada la posibilidad que ofrece LO por su compatibilidad con las extensiones MSO. 

        También es posible implementar macros OOo Basic, pero a diferencia del modo 1A1, considero que esta opción sólo se debe contemplar de forma excepcional, ya que deberíamos ser capaces de generar un documento final mediante Python.

        NOTA 1. De este modo la estructura de contenidos de estas entradas se asimila a la que planteo en OBpO, blog en el que diferencio estrategias de trabajo OOo Basic para crear documentos de texto de las propias para el trabajo con fuentes de datos. Además facilita también que se mantenga cierta coherencia con los vídeos YouTu.be de la lista de reproducción Python para orientadores.

        NOTA 2. Eso en Windows; para Linux y Mac ver enlace

        NOTA 3. Conforme vayamos incorporando otras bibliotecas iré ampliando el listado de enlaces a la documentación de las mismas.

        sábado, 7 de octubre de 2023

        Documentos. Combinada.

        Comunicación con familias

        Sabemos que esta medida de escolarización combinada supone una carga de trabajo muy importante. La mayor no es la de tipo burocrático, aunque no es desdeñable y bueno será todo lo que la alivie, como este docap de comunicación de las decisiones de la Comisión de Seguimiento a las familias cuando se producen determinados cambios o se prevén determinadas actuaciones,

        Tanto por derecho como por conveniencia, la comunicación de la Comisión de Seguimiento de la Escolarización Combinada con las familias es fundamental para el correcto funcionamiento de esta medida de respuesta educativa. Siendo como es una medida controvertida y sumamente compleja, cumplir escrupulosamente los procedimientos que se establezcan para hacer efectiva esta comunicación es de vital importancia.

        Y contar con una ayuda que facilite el correcto desarrollo de este tipo de actuaciones siempre será de agradecer, especialmente si nos permite automatizar la generación de documentos, reduciendo la carga de trabajo que implica, sin pérdida de calidad y personalización de la intervención.

        Este docap sirve para crear documentos de comunicación de medidas a las familias. Aunque la firma es la del/de la responsable del Equipo educativo del centro de escolarización, se pretende que sea empleado por la persona que presida la Comisión de Seguimiento de la Escolarización Combinada (supuestamente el orientador u orientadora del centro de escolarización), quien lo presentará a la firma al responsable de la Dirección del centro, dentro del proceso de traslado de información y tramitación de las medidas que se plantearon en el seno de dicha Comisión.

        Aclaro que parto de que se cumple el principio de que el centro de escolarización (de matriculación, para entendernos), que define la modalidad de escolarización del alumno o alumna y la gestión de su expediente escolar, es el centro ordinario en E. Infantil y el específico en E. Primaria. Al menos, esto es lo que está establecido por norma administrativa en determinadas comunidades autónomas, y en este contexto planteo el funcionamiento del docap.

        En él, por delimitar su contenido, se consideran tres tipos de posibles medidas genéricas: la evaluación psicopedagógica prescriptiva según prescripción normativa, la modificación de apoyos especializados y la modificación de los periodos de asistencia a cada uno de los centros. Cualquier otra circunstancia o decisión de la Comisión no está considerada, lo que obliga, en su caso, a modificar tanto el control específico del formulario de entrada de datos como el código de tratamiento de los mismos.

        Formalmente este docap se configura como docap complejo; se basa en LO-Calc y genera un documento LO-Writer como salida. La gestión de este documento queda a decisión del usuario, tanto a nivel de configuración y formateo, como de cambio de formato; por ejemplo es posible convertirlo a .pdf después de darle el formato deseado.

        Se elegido esta formulación del docap por la simplicidad de gestión de los datos Calc desde OOo Basic y la fácil solución que proporciona ese servicio en el empleo de formularios, pero también por la versatilidad que supone trabajar con documentos de texto: que son editables y permiten realizar las modificaciones que se consideren pertinentes, haciendo que el docap resuelva la composición del documento-base, pero sin condicionar su formulación definitiva.

        Aunque la explicación del docap la traslado al [vídeo enlazado con esta entrada], parece pertinente analizar aquí la estructura de su código.


        En él podemos observar los diferentes componentes del docap y sus interacciones: partiendo del formulario y la asignación de sus controles a determinadas celdas, se accede mediante código a ellas y, posteriormente se complementa la información necesaria mediante el tratamiento condicional de los datos recogidos. Con estos datos se componen los textos (párrafos) que se escribirán en un documento Writer que se ha creado previamente mediante el procedimiento OOo Basic correspondiente.

        El uso del docap es, como siempre, muy simple:

        • Se cumplimenta el cuestionario en la hoja de cálculo (gestor)
        • Se hace clic en el botón de comando "crear documento", que da acceso al desarrollo del proceso.
        • En función de los datos que se aporten se deberán cumplimentar InputBox() complementarios. Se debe tener cuidado con la pulsación sobre el botón "Aceptar" de estos interfaces para evitar saltos indebidos que alteran el resultado final del docap.
        • Se genera un documento Writer con los datos que ha creado el script. Este documento puedes ser guardado directamente o dejarlo abierto y disponible para las manipulaciones que se desee, incluyendo formateo para presentación y exportación bien como archivo de texto editable (.odt o .doc/.docx) o como .pdf.
        • Una vez creado el documento (y si preferimos antes de ponernos a trabajar con él) borraremos el contenido de los campos del formulario Calc haciendo clic en el botón-comando correspondiente.
        Las posibilidades de mejora son varias, empezando por sustituir el uso de InputBox() por cuadros de diálogo para complementar el interface gráfico de entrada de datos y siguiendo por simplificar el código y mejorarlo ahí donde es posible (y hay unas cuantas mejoras potenciales). Como en otras ocasiones, dejo al usuario y su pericia la realización de estas mejoras y me reservo los mismos derechos.

        No obstante, te expongo ahora otra línea de mejora que no normalmente no se plantea, pero que es coherente y posible (y yo diría deseable) desde este enfoque que se defiende en este blog: ser capaz de crear herramientas personalizadas:
        • Dado que estamos hablando de logar un nivel competencial que nos permita crear herramientas personalizadas (por ahora desde las propias opciones que presentan las suites ofimáticas), ¿por qué no practica este mismo enfoque adaptando instrumentos como el presenta a las necesidades y realidades concretas de un centro?
        • Desde esta perspectiva te planteo que, al margen de que afrontes o no mejoras como las que insinúo antes, adaptes el docap a tus necesidades mediante la asignación de valores a determinadas variables para que no sea necesario solicitarlos mediante interface.
        • Si lo haces, debes tener en cuenta lo que esto implica para el funcionamiento conjunto del script, por lo que te lo planteo desde la seguridad de que tu actual nivel de conocimiento y capacidad así lo permite.