La historia de π (pi)

Una de las experiencias más satisfactorias para mi ha sido leer A history of PI de Petr Beckmann.

Aunque los logros específicos del saber humano se dan a través de individuos al ver la historia el contexto social parece ser determinante para el desarrollo tecnológico y el entendimiento científico. Como dijo alguien con respecto a la bomba atómica:

 El secreto es saber que se puede hacer.

Por otro lado, los genios son cosa rara. Consideramos el siglo veinte y lo que va del veintiuno como superiores al resto de la historia humana en términos de entendimiento científico y avance tecnológico pero tal vez todavía no terminamos de aprehender lo que Newton percibió y plasmo en su obra hace 300 años.

Pi es interesante porque el circulo es interesante. El circulo es una forma ideal abstracta que no existe en la realidad pero también es la forma de muchos objetos de la vida diaria.

Algunas personas pueden entender que un objeto redondo es aproximadamente circular pero que si medimos con suficiente precisión no hay círculos perfectos en el mundo. Para algunos lograr este salto de abstracción no es una posibilidad y logran demostrar que pi es igual 20612/6561, que en términos prácticos, en términos de medir una mesa, o rebanar un pastel esta más que bien, pero en términos de capacidad de desarrollar tecnología, por ponerlo de alguna manera, es un callejón sin salida. La practicidad es un duende travieso que nos permite salir adelante ante los retos de la vida pero que si nos descuidamos nos lleva por los senderos del estancamiento y de la corrupción. Empecemos por valorar a los que pueden, tratemos de entender. El primer paso, según alcohólicos anónimos es aceptar el problema. La educación es el camino, trabajemos para que nuestros niños sepan observar, pensar, discutir, y hacer, no para que sean científicos, sino para que todos vivamos mejor.

Un lector del libro de Beckmann comparte su frustración en Internet:

I think my main problem with the book is that I was looking for an interesting narrative that explores the impact of pi from a cultural and personal point of view. What I got was a mathematical primer on pi, heavy on formulas, charts and graphs, peppered with bland historical facts easily obtained from general knowledge history books and encyclopedias.

Es curioso el comentario porque el libro es ameno, atestiguado por sus ventas, y las matemáticas son un lenguaje para hablar de cosas como pi, es decir son parte de la narrativa. Parece que la comunicación entre el hemisferio izquierdo y el derecho del cerebro no es tan fácil. Para algunos, como Pitágoras, los números son mágicos y su manipulación un camino para controlar el destino.

Volviendo a pi, veamos como expresarlo como una fracción.

Empecemos con una aproximación
pi=3.141592653589793+.
=
3 + 0.14159…

Tomado el reciproco de la parte fraccionaria
1
3 + ————
7.06251…

Iterando el procedimiento
1
3 + —————-
7 + 0.06251…

1
3 + ——————-
1
7 + ————-
15.99658…

Si la parte decimal es mayor a .5 podemos acercarnos por arriba
1
3 + —————————
1
7 + ———————
1
16 – ————–
292.98696…

Simplificando

1
3 + ———-
1
7 + —-
16

1
3 + ——-
113
—–
16

16
3 + —–
113

335
—–
113

Las primeas cuatro aproximaciones a pi corresponden con valores históricos;

3/1 3.000000000000000
22/7 3.142857142857143
355/113 3.141592920353983
104348/33215 3.141592653921421

Referencias:

eXtreme Programming

Uno de los problemas fundamentales con las metodologías de desarrollo, de hecho, con cualquier esfuerzo de normalizar un proceso entre personas, es que el deber ser en un sentido moral idealista obscurece el es. eXtreme Programming es un enfoque contra intuitivo para aumentar la productividad de los programadores.

A pesar de los esfuerzos heroicos del equipo de mercadotecnia y de la necesidad de los usuarios de mantener los costos bajos, un programador es productivo alrededor de 2 a 4 horas diarias en promedio. Un monstro en el closet pero una realidad. Esto anuado al hecho de la programación es una arte en al que unos pocos virtuosos pueden realizarla con soltura, 5% de los programadores (o menos) hacen 95% del trabajo (o más). Por eso los beneficios de programación en pares en realidad no implican un costo en productividad. Antes al contrario, probablemente un equipo de 2 de programadores trabajando bajo el esquema de programación extrema sea 2 a 3 veces más productivo que los mismos programadores trabajando de manera aislada.

El énfasis en diseño y pruebas es simplemente una realidad del ciclo de desarrollo:

  • Un defecto en codificación es un defecto, aunque corregirlo puede generar más defectos.
  • Un error en la fase de diseño produce más de 10 defectos en código
  • Un error en la fase de levantamiento de requerimientos produce más de 100 defectos en código

Por eso el esfuerzo de desarrollo debe concentrarse en el análisis y realizar iteraciones cortas donde rápidamente la funcionalidad del sistema sea aparente al usuario final y este pueda dar la retroalimentación necesaria para mantener las cosas en la dirección correcta de manera eficaz.

El esfuerzo de desarrollo debe seguir aproximadamente la siguiente ponderación:

  • 40 % análisis y diseño
  • 5 % codificación
  • 30 % pruebas y soporte
  • 25 % más análisis, diseño, pruebas.

Referencias

diagrama xtrem programming

Technorati Tags: ,,,,,,,,,,,,,,,

Los operadores de copia e igualdad.

Una de las trampas de la orientación a objetos en lenguajes como C# son los operadores de copia e igualdad.

En C# al usar el operador = o ==, la igualdad entre objetos referenciados solo se da si en realidad es el mismo objeto y de manera similar al hacer una copia nos podemos llevar una sorpresa si no tenemos cuidado de estar copiando la referencia o el contenido. Por eso la interfaz ICloneable es controversial porque su significado es ambiguo

Referencias:

Implementar ICloneable mediante serialización

ICloneable Interface

Should we Obsolete ICloneable (The SLAR on System.ICloneable)

IClonable deep vs shallow, best practise

Creating and Using Attributes in your .NET application

IEquatable Generic Interface

Libreria empresarial del grupo de patrones y practicas de Microsoft

La última versión de la Enterprise Library del grupo de Patterns and Practices de Microsoft se libero en mayo del 2007 y es compatible con .Net 2.0 y 3.0.

Información actualizada y material didactico se puede localizar en el sitio comunitario de la libreria empresarial.

Enterprise Library: La evolución de los .NET Application Blocks de patterns & practices

Entlib – Enterprise Library es la evolución de los Bloques Aplicativos .NET que han sido desarrollados por el Grupo PAG (Microsoft Platform Architecture Guidance) dentro de Microsoft. Este grupo genera guías y arquitecturas de referencia, patrones de diseño, y código fuente desarrollado con la implementación de diversos escenarios tecnológicos.

Los desarrolladores en su momento puden usar la guía para comprender las mejores prácticas referenciadas y sugeridas por Microsoft para aplicaciones .NET; o incorporar el bloque aplicativo como tal dentro de sus desarrollos, en su formato original y/o extendido.

Los “Bloques Aplicativos .NET” que en su momento fueron liberados son los siguientes:

Por la forma gradual en que fueron desarrollados dichos bloques aplicativos, los mismos estaban desintegrados y la experiencia de utilización e extensibilidad eran diferentes entre si. Además que la utilización de cada uno de dichas piezas de software obligaba a la instalación de componentes de software independientes.

Con estas áreas de oportunidad la nueva versión de los “.NET Application Blocks” se integró con la nueva etiqueta de Enterprise Library. El grupo de PAG ha anunciado lo siguiente:

Entlib es una librería de activos de software reutilizable que atenderá los retos comunes en el desarrollo del software empresarial.

Entlib está focalizado en la consistencia, extensibilidad, fácil utilización e integración de los diversos bloques aplicativos existentes y futuros.

Es importante aclarar que Enterprise Libray no es un producto como tal, sino que es un componente de software que es proporcionado como está, pero del cual se puede contratar soporte directamente de Microsoft, tratado bajo un esquema parecido al código escrito por los usuarios.

Recursos relacionados:

  1. Web Service Software Factory

  2. Smart Client Software Factory

  3. Web Client Software Factory

  4. Guidance Automation Extensions and Guidance Automation Toolkit

Requerimientos:

  • Sistema oprativo: Windows Server 2003; Windows Vista; Windows XP

Note: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1. However, you can install the Enterprise Library 3.0 or the Enterprise Library 3.1 when 2.0 is already installed.

  • Microsoft .NET Framework 2.0 or 3.0. You need .NET Framework 3.0 for the
    Application Block Software Factory and the WCF adapters for the Validation
    Application Block and Exception Handling Application Block

  • Microsoft Visual Studio 2005 development system (any of the following
    editions):

    • Microsoft Visual Studio 2005 Standard Edition

    • Microsoft Visual Studio 2005 Professional Edition

    • Microsoft Visual Studio 2005 Team Edition for Software Developers

    • Microsoft Visual Studio 2005 Team Edition for Software Testers

    • Microsoft Visual Studio 2005 Team Edition for Software Architects

    • Microsoft Visual Studio 2005 Team Suite

  • To use the Application Block Software Factory and the Strong-Naming
    Guidance Package, you need the Guidance Automation Extensions (GAX). To
    modify these guidance packages, you also need the Guidance Automation
    Toolkit (GAT).

  • Some blocks and samples require the use of Microsoft SQL Server or other
    database products.

  • Visual Studio Team System or NUnit 2.2 is required if you want to
    execute unit tests.

Referencias:

Enterprise Library 3.1 – May 2007

Juan Carlos Lozada’s WebLog

Acropolis

More Information

 

  Enterprise Library
The patterns & practices Enterprise Library is a library of reusable and extensible application blocks designed to assist developers with common enterprise development challenges. Enterprise Library 3.0 contains application blocks for Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security and Validation.
  Caching Application Block
The Caching Application Block is a component of Enterprise Library which provides a flexible and extensible caching mechanism for use in client and server-side .NET development projects.
  Smart Client – Composite UI Application Block
Are you building applications with complex user interfaces? Do you want to take full advantage of the power of the Microsoft Windows desktop? Check out this recently released application block that provides guidance on building world-class, enterprise ready, client applications. Available both in C# and Visual Basic .NET.
  Cryptography Application Block
The Cryptography Application Block is a component of Enterprise Library which makes it easier to include cryptographic functionality in .NET applications. The block provides a simple interface to DPAPI, symmetric encryption and hashing, and uses the Enterprise Library configuration tool to simplify key management.
  Data Access Application Block
The Data Access Application Block is a component of Enterprise Library which reduces the amount of custom code that you need to create, test, and maintain when building data access layers in .NET applications.
  Exception Handling Application Block
The Exception Handling Application Block is a component of Enterprise Library that makes it easier to implement consistent exception handling policies at logical tiers in an application. Exception policies can be configured to perform tasks such as logging exceptions, wrapping or replacing exception types.
  Logging Application Block
The Logging Application Block is a component of Enterprise Library that allows developers to instrument their applications with logging and tracing calls. Log and trace messages can be filtered, formatted and routed to a choice of trace listeners, including the event log, text files, database or WMI.
  Policy Injection Application Block
The Policy Injection Application Block is a component of Enterprise Library which allows developers to specify the crosscutting behavior of objects in terms of a set of policies. Crosscutting concerns are the necessary tasks, features, or processes that are common across different objects. Examples are logging, authorization, validation, and instrumentation.
  Security Application Block
The Security Application Block is a component of Enterprise Library that builds on the capabilities of the Microsoft .NET Framework to help you perform authentication, authorization, check role membership and access profile information.
  Validation Application Block
The Validation Application Block is a component of Enterprise Library which provides a common approach to defining validation rules for your business objects that allows them to be reused across different layers of your application.
  Web Service Facade for Legacy Applications
This guide discusses best practices for interfacing with legacy applications by using Microsoft® ASP.NET Web services and the Microsoft .NET Framework. The .NET Framework provides the foundation for creating a Legacy Application Interface solution using Microsoft technologies. This guide provides a sample solution using a Microsoft FoxPro® database as the legacy application and connecting it to a .NET-based application using ASP.NET Web services and SOAP. The specific technologies involved are ASP.NET, C# or the Microsoft Visual Basic® .NET development system, the .NET Framework, XML, Visual Basic, COM, and ADO.

La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.

Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

http://www.go-mono.com/docs/
http://www.codeproject.com/cpnet/hellomono.asp

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

  • El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.

  • La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado

  • La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.

  • La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.

  • El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

Liberarí­a Tamaño (MB) Tamaño comprimido (MB)
Java 30+ 15
GTK+ 9+ 4
QT 4+ 2
wxWidgets <1 <.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento “Quasar Technologies”) en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

Lisp y Scheme

Una de las cosas que me llaman la atención es la convicción tan grande que los programadores de Lisp tienen en el poder de sus paréntesis.

Aún en el contexto de desarrollo Web Paul Graham ha llamado a Lisp su arma secreta, y en el manual de como convertirse en un Hacker de Eric Steven Raymond Lisp se presenta como un experiencia mística. Peter Norvig, en Teach Yourself Programming in Ten Years recomienda aprender lenguajes que soporten abstracción de clases (como Java), abstracción funcional (como Lisp), abstracción sintáctica (como Lisp), especificación declarativa (como Prolog), corutinas (como Scheme), y paralelismo (como Sisal).

El enfoque funcional parece ser fundamental y, por ejemplo, el equipo de desarrollo de C# ha hecho un esfuerzo por soportar este paradigma en la nueva versión a través del mecanismo de delegados.

Es claro que el río suena porque agua lleva. Para el interesado hay material introductorio abundante pero lograr la iluminación requerirá tiempo y esfuerzo.

Para Lisp, como lo indica su nombre, todo son listas y los comando básicos (constructors, selectors y recognizers) son para manipular las mismas:

quote para diferenciar una lista de una llamada a función.
first y rest para separar listas en sus partes.
cons para construir listas.
null y consp para ver si una lista esta vacía.
member para verificar si un elemento es miembro de una lista.
append para unir listas.

Lisp tiene varios dialectos: Common Lisp y Scheme son algunos de los más difundidos. CLisp es un implementación de Common Lisp y Visual CLisp es un puerto a Windows con un GUI. Otra alternativa es CMUCL.

Dorai Sitaram tiene un sitio con ligas a recursos sobre Scheme y Common Lisp, incluyendo un tutorial bastante bueno.

drscheme incluye varias implementaciones de Scheme bajo una interfaz común orientada a un ambiente académico.
Las funciones de Scheme para manipular listas son:

cons
toma dos argumentos y regresa un par o lista.


(cons '1 '2)              is   (1 . 2)

El primer ejemplo es un par y los otros son listas. Pares o listas se pueden utilizar para implementar registros.

car
regresa el primer miembro de una lista o par.


(car '(123 245 564 898))             is   123

cdr
regresa la lista sin el primer elemento.


(cdr '(7 6 5))               is  (6 5)

null?
regresa #t si el objeto es la lista nula. En cualquier otro caso regresa la lista nula.
list
regresa un alista construida de los argumentos.


(list 'a)                          is  (a)

length
regresa la longitud de la lista.

     (length '(1 3 5 9 11)) is  5

reverse
regresa la lista invertida.

     (reverse '(1 3 5 9 11)) is  (11 9 5 3 1)

append
regresa la concatenación de dos listas.

     (append '(1 3 5)  '(9 11))  is  (1 3 5 9 11)

Expresiones condicionales son de la forma:

(if test-exp then-exp)

(if test-exp then-exp else-exp).

Definiciones son de la forma:

     (define id exp)

Expresiones Lambda son funciones anónimas de la forma:

         (lambda (id...) exp )

Definiciones locales se introducen con las funciones let, let* y letrec. let se aplica en paralelo, let* es secuencial, y letrec permite definiciones recursivas.

  • apply regresa el resultado de aplicar el primer argumento al segundo.

    • 1 ]=>  (apply + '(7 5)) 

    ;Value:   12 

    1 ]=>  (apply max '(3 7 2 9))
     

    ;Value:   9

  • map regresa una lista que es el resultado de aplicar el primer argumento a cada elemento del segundo.

    • 1 ]=>   (map odd? '(2 3 4 5 6)) 

    ;Value: (() #T () #T ())

    Referencias:

    The Allegro Common Lisp Open Source Center

    Allegro CL

    http://www.cs.berkeley.edu/~fateman/generic/

    Richard J. Fateman

    Algoritmos en Scheme

    Taller sobre Scheme

    Hobbit versión 5 compila R4RS Scheme a código C, que se puede usar con SCM Scheme Implementation

    El paquete SLIB es una librería portable del lenguaje Scheme que funciona en varias plataformas e implementaciones, incluyendo Guile.

    Generación automática de código

    Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

    Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

    Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

    En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

    El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

    UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

    MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

    MDA asume que están disponibles modelos para cualquier artefacto.

    MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

    MDA asume que 3 tipos de modelo son suficientes:

    computation-independent model,

    platform-independent model,

    platform-specific model.

    MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

    Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

    Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

    El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

    Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

    El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

    El uso de una fábrica de software incluye los siguientes pasos:

    • Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.

    • Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.

    • Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.

    • Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes

    • Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.

    • Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

    Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

    El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

    Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.

    Referencias:

    Bare-Naked Languages or What Not to Model

    CodeGen’ing a Data Access Layer with CodeSmith

    LLBLGen

    Microsoft DSL

    CodeSmith Community: .netTiers

    Sean Mccormack’s Codus

    Software Factories

    Wilson OR Mapper templates for CodeSmith

    Codegeneration.net

    Can you code gen everything?

    CodeSmith Community: Rocky CSLA Templates

    Deklarit Kathleen Dollard

    CodeSmith Community: Files

    Andres Aguiar’s Blog

    Eric Smith’s Blog

    .nettiers demo/tutorial DAL in 15 mins

    Global Bank Scenario

    Visual Studio 2005 SDK Version 4.0

    http://blogs.msdn.com/jackgr/

    Jack Greenfield’s Blog

    Code Generation Network

    TypeBuilderLib, a Library to Build Dynamic Types Easily

    Minimalist GNU for Windows

    MinGW o MinGW32 (Minimalist GNU for Windows) es una implementación de los compiladores GCC para la plataforma Win32, que permite migrar aplicaciones GNU a entornos Windows. Es un derivado de Cygwin en su versión 1.3.3.

    MinGW incluye un conjunto de la api de Win32, permitiendo un desarrollo de aplicaciones nativas para esa plataforma, pudiendo generar ejecutables y librerí­as usando la API de Windows.

    MinGW fue creado por Colin Peters, el 1 de julio de 1998, compilándolo con Gygwin. La primera versión nativa de MinGW fue realizada por Jan-Jaap van der Heijden, quien también tuvo participación en el proyecto GCC. Mumit Khan estuvo a cargo del mantenimiento del proyecto e incluyo al compilador algunas características propias de Windows. Los archivos de cabecera del API de Windows fueron provistos por Anders Norlander.

    Una de las desventajas de MinGW es que los ejecutables que genera son de tamaño más grande que los generados por otros compiladores. Esto ocurre cuando se incluyen los archivos de cabecera estándares de C++ (por ejemplo, #include ), y se debe a que el compilador vincula todas las librerí­as dentro del archivo ejecutable de manera estática.

    MinGW incluye MSYS (Minimal SYStem) un shell POSIX/Bourne para ejecutar scripts de configuración usados por make y ./configure

    Después de descargar MinGW y MSYS, incluyendo mingw-runtime, w32api, binutils y gcc, gdb y mingw32-make se pueden expandir los archivos de dos formas. Poner el directorio de MinGW dentro de MSYS o instalarlos en directorios distintos y modificar el archivo MSYS /etc/fstab para agregar un apuntador al directorio donde mingw esta instalado.

    Para probar la instalación se puede correr el shell de msys y probar el comando de línea

    gcc –v

    Para habilitar el soporte de IDEs agregar lib a la variable de entorno LIBRARY_PATH y los subdirectorios bin de y a la variable de entorno PATH
    Aplicación de consola:

    En un archivo con el nombre hello.c poner el siguiente código:

    #include

    int main(int argc, char **argv)
    {
    printf (“Hellon”);
    return (0);
    }

    y compilar con

    gcc -c hello.c

    y después

    gcc -o hello hello.o

    Alternativamente

    gcc -o hello hello.c

    En un archivo con el nombre hello.cpp poner el siguiente código:

    #include
    int main(int argc, char **argv)
    {
    std::cout return (0);
    }

    y compilar con

    g++ -c hello.cpp
    g++ -o hello hello.o
    Aplicación Windows

    En un archivo con el nombre hello.c poner el siguiente código:

    #include

    int WINAPI WinMain (HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    PSTR szCmdLine,
    int iCmdShow)
    {
    MessageBox (NULL, “Hello”, “Hello Demo”, MB_OK);
    return (0);
    }

    para crear el ejecutable usar los comandos de linea

    gcc -c hello.c

    y

    gcc -o hello hello.o -mwindows

    el parametro -mwindows es necesario para que se incluyan las librerias necesarias para un programa Windows.
    dll

    En un archivo con el nombre dllfct.h poner el siguiente código:

    #ifdef BUILD_DLL
    // the dll exports
    #define EXPORT __declspec(dllexport)
    #else
    // the exe imports
    #define EXPORT __declspec(dllimport)
    #endif

    // function to be imported/exported
    EXPORT void tstfunc (void);

    En un archivo con el nombre dllfct.c poner el siguiente código:

    #include
    #include “dllfct.h”

    EXPORT void tstfunc (void)
    {
    printf (“Hellon”);
    }

    En un archivo con el nombre Hello.c poner el siguiente código:

    #include “dllfct.h”

    int main ()
    {
    tstfunc ();
    return (0);
    }

    Para crear una dll y un ejecutable que lo use:

    gcc -c hello.c
    gcc -c -DBUILD_DLL dllfct.c
    gcc -shared -o tst.dll -Wl,–out-implib,libtstdll.a dllfct.o
    gcc -o hello.exe hello.o -L./ -ltstdll

    Se puede especificar el directorio a usar para los includes durante la compilación con

    -I/path/to/headers

    y las librerias para link:

    -L/usr/lib/library

    Usualmente no hay necesidad de andar moviendo las librerias.
    Archivo .def para un dll

    Si tiene un dll llamado file.dll y quiere crear un archivo .def con el nombre file.def,

    echo EXPORTS > file.def
    nm file.dll | grep ‘ T _’ | sed ‘s/.* T _//’ >> file.def

    Para crear una biblioteca con el nombre file.a :

    dlltool –def file.def –dllname file.dll –output-lib file.a

    Generación de código

    sisyphus

    Así­ como los objetos fí­sicos se mueven a través del tiempo y el espacio, las aplicaciones de software se mueven por diferentes ejes en su ciclo de vida. Concretamente, el mantenimiento de una aplicación requerirá de una serie de adecuaciones y cambios por distintos motivos: cambio de plataforma, cambios en el proceso de negocio, nuevos requerimientos, nueva base de datos. Etcétera. Además, desde el punto de vista del desarrollador, lo ideal es poder reutilizar lo más posible de esfuerzos anteriores. En el ciclo de vida de un sistema, más del 60% del costo es el mantenimiento

    La tendencia a requerimientos cada vez más complejos con tiempos de desarrollo cada vez más cortos vuelve el re-uso de código un imperativo.

    Teóricamente, la programación orientada a objetos facilita el re uso de código. Los atributos de los lenguajes orientados a objetos que promueven el re-uso de código son:

    Abstracción de datos que promueve sistemas modulares.

    Herencia que permite que las subclases re-usen código de las superclases.

    Poliformismo facilita el re-uso de comportamiento bajo diferentes contextos.

    Marcos (frameworks) que son conjuntos de clases abstractas que solucionan familias de problemas relacionados.

    Pero, para que se cumpla esta promesa divina de re-uso, el código, o más bien dicho, el diseño, debe ser bueno, muy bueno. ¿Qué es, entonces, un buen diseño? Cada cuál tendrá su idea. A manera de contrapunto empecemos por lo negativo, ¿Qué características tiene un mal diseño? Concediendo que la aplicación cumple con los requerimientos para los que fue diseñada, un diseño puede adolecer de lo siguiente:

    Rigidez. La aplicación es difí­cil de cambiar porque cualquier cambio afecta demasiadas cosas.

    Fragilidad. Cuando se hace un cambio, la aplicación deja de funcionar en lugares inesperados.

    Inmovilidad. Es difí­cil utilizar la aplicación como parte de otra aplicación porque las dependencias con el contexto están enmadejadas en el código.

    ¿Qué es lo que hace un diseño rí­gido, frágil, e inmóvil? Las interdependencias de sus módulos. Entonces, para que el proceso de mantenimiento no sea la imagen de un perro persiguiendo su cola, se debe tener cuidado de minimizar interdependencias.

    Desde el punto de vista de la programación estructurada, un diseño se puede ir construyendo bottom-up o top-down. Es decir, a partir de los componentes o módulos que tengo disponibles voy construyendo módulos más complejos, hasta cubrir los requerimientos, o conversamente, voy dividiendo mis requerimientos entre sub-módulos, hasta que llego a un punto suficientemente concreto para resolverlo de manera independiente. Al final, de manera iterativa, se llega a un diseño de capas jerárquico, donde en un sentido estricto, los únicos componentes que pueden ser completamente independientes del resto son los módulos de más bajo nivel en la jerárquia, es decir los más concretos y especí­ficos, los más ligados al problema particular que se esta resolviendo.

    La mecánica establecida para re-usar rutinas de bajo nivel es el uso de librerí­as. En la practica la productividad de un lenguaje o ambiente de desarrollo esta ligada con la calidad y disponibilidad de librerías. Esto esta bien, pero desde el punto de vista de re-uso de código las dependencias están al revés. Los módulos de alto nivel, que resuelven un proceso complejo de interacción entre la aplicación, sus módulos internos, y el contexto exterior son los que queremos re-usar. De acuerdo a este precepto, un buen diseño debe cumplir con el principio de inversión de dependencias.

    El principio de inversión de dependencias

    Módulos de alto nivel no deben depender en módulos de bajo nivel. Ambos deben depender de abstracciones.

    Abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

    Al concepto de inversión de control se le refiere como el principio de Hollywood:

    Do not call us, we call you

    Inversión de control es un aspecto clave que diferencia un marco orientado a objetos de una librería. Una librerí­a es un conjunto de funciones, tal vez organizadas dentro de clases, que una aplicación (cliente) llama dentro del código, la función hace lo que tiene que hacer, y regresa el control al cliente. En un marco orientado a objetos, es el marco el que llama al código del cliente. En .Net, por ejemplo, una manera de hacer esto es que el marco defina eventos a los cuales se subscribe el cliente y mediante el uso de delegados, el cliente asigna el compartimiento especifico que requiere.

    En términos más generales, Interfaces es la manera de abstraer la interacción entre el cliente y el marco (framework). Una técnica de inversión de control es dependency injection.

    La inversión de control es parte de lo que hace la programación de marcos orientados a objetos perturbadora para algunos. Al programar un procedimiento, la atención del programador esta en el flujo de control. Es difícil imaginar como se pudiera entender un programa sin saber la lógica de ejecución. Pero un buen marco abstrae el detalle del control de flujo. El foco de atención esta en los objetos, lo que puede ser al mismo tiempo más y menos tangible que el flujo de control.

    En el marco, lo importante son las responsabilidades de cada objeto y la interacción (colaboración) entre ellos. Es una visión más abstracta, más declarativa del mundo, potencialmente más flexible y amplia que el enfoque en procedimientos.

    Resumiendo, un buen diseño es aquel que nos permite hace cambios de manera no intrusiva, es decir, añadiendo código en vez de cambiando código. Un buen diseño se puede modificar sin tocar el código existente. O sea, en un desarrollo orientado a objetos el esfuerzo debe estar en el diseño. La programación orientada a objetos debe ser fácil, a costa de un proceso exhaustivo de diseño. He ahí la promesa y el reto fundamental de la orientación a objetos.

    Los buenos patrones de diseño no se inventan, se descubren. Desde una perspectiva macro de diseño el principio de inversión de control es fundamental. Desde la perspectiva de las clases en si, ¿Qué principios se deben seguir para facilitar un buen diseño?, o más importante, ¿Qué debemos evitar para no inhibir el potencial del diseño? ¿Cómo garantizar que no haremos daño?

    Algunos tips:

    Es más fácil reusar un comportamiento agregando un componente que a través de herencia.

    Eliminar análisis de casos. En el caso de .Net se pueden usar genéricos.

    Reducir el número de argumentos. Sin embargo, al crear un objeto, es preferible exponer todas las dependencias para facilitar pruebas de clases individuales.

    Reducir el tamaño de los métodos. El propósito del método debe ser obvio e idealmente el código debe ser auto documentado.

    Las jerarquías de clases deben ser profundas y espigadas. Una clase todopoderosa, rodeada de ratoncitos indica un área de oportunidad en el diseño. Cada clase debe tener una responsabilidad principal, de preferencia única, claramente definida.

    Minimizar acceso a variables. Una clase debe exponer solo aquello que sea estrictamente necesario para cumplir con su responsabilidad. En .Net se promueve el uso de propiedades en vez de variables públicas, para que la clase tenga mayor control en el uso de sus valores a través de métodos get y set.

    La raíz de la jerarquía de clases debe ser abstracta. Es decir, no debe tener ningún (minimizar) detalle de implementación y solo exponer la interfaz de la clase.

    Subclases deben ser especializaciones. Usualmente una subclase no debe redefinir métodos de la superclase, solo añadir nuevos.

    Dividir clases grandes. Factorizar diferencias de implementación en sub-componentes. Separar métodos que no se comunican entre si.

    Evitar el uso implícito de parámetros.

    La guí­a del buen objeto,

    • Mantengo un estado consistente todo el tiempo.

    • No tengo métodos o variables estáticos.

    • Nunca espero o regreso null.

    • Fallo pronto.

    • Soy fácil de probar, todos los objetos de los que dependo los recibo como parámetros, normalmente durante construcción.

    • Los objetos de los que dependo pueden ser substituidos por Mock Objects (no uso dependencias a clases concretas).

    • Encadeno constructores multiples a un lugar comun, usando this

    • Siempre defino hashCode() junto a equals().

    • Prefiero valores inmutables que puede tirar fácilmente.

    • Tengo un valor especial para nada, por ejemplo EMPTY_SET para colecciones.

    • Disparo una excepción cuando el cliente pide algo que no es razonable, por ejemplo, abrir un archivo que no existe.

    • Disparo una excepción cuando no puedo hacer algo que deberí­a poder hacer, por ejemplo error de disco al leer un archivo abierto.

    • Solo atrapo excepciones que puedo manejar completamente.

    • Solo registró en bitácora información que alguien necesita ver.

    Referencias

    Johnson and Foote’s paper Designing Reusable Classes, Journal of Object-Oriented Programming , 1988.

    El libro del Gang of Four

    Richard Sweet ,1983.

    John Vlissides column for C++ report

    http://www.betaversion.org/%7Estefano/

    http://www.laputan.org/drc/drc.html

    http://www.laputan.org/dfc/discussion.html#Rock

    http://www.digibarn.com/friends/curbow/star/XDEPaper.pdf

    http://researchweb.watson.ibm.com/designpatterns/

    http://www.flexwiki.com/default.aspx

    http://www.artima.com/lejava/articles/patterns_practice.html

    http://www.artima.com/index.jsp

    http://today.java.net/pub/a/today/2004/02/10/ioc.html

    http://www.objectmentor.com/resources/articles/dip.pdf

    http://www.objectmentor.com/

    One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user’s application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

    Ralph Johnson y Brian Foote

    Introducción a Perl

    Practical Extraction and Reporting Language.

    There is more than one way to do it

    Puntos a favor de perl:

    • perl es un lenguaje de alto nivel

    • perl es gratis

    • perl puede escribir y leer archivos binarios

    • perl puede tener múltiples archivos de entra y salida abiertos al mismo tiempo

    • Tiene un generador de reportes

    • Maneja expresiones regulares

    • Maneja arreglos lineales y asociativos

    • Es poderoso y simplifica la programación

    • Puede procesar archivos muy grandes sin limites en el tamaño de registro

    • perl incluye un conjunto amplio y poderoso de instrucciones para manejo de cadenas de caracteres y arreglos

    • Cualquier cosa se puede realizar de múltiples formas

    Ejemplo de programa en Perl:

    # Este sencillo programa copia registros de un archivo
    # y agrega un prefijo a cada línea con un numero en secuencia
    while (< >){
    # while () {} genera un lazo de control que continua mientras el
    # enunciado en paréntesis es verdadero.
    # la instrucciones en el lazo están dentro de los corchetes {}
    # < > es un símbolo especial
    # Le dice a Perl que busque en la línea de comando y vea si se
    # especificaron algunos archivos.
    # Si es el caso, entonces se lee cada uno en turno.
    # Si no se especifica ningún archivo entonces se lee de
    # la entrada normal (standard input)
    # Cualquiera que sea el caso los caracteres que se leen se guardan
    # en la variable especial $_
    # Cuando <> llega al fin de archivo (end-of-file), regresa un valor de falso,
    # lo cual termina el lazo.
    print STDOUT ++$i, $_;# print es un método simple sin formato de impresión
    # STDOUT es una referencia de archivo normal (standard filehandle)
    # para la salida normal (Standard Output).
    # Filehandles se especifican en MAYUSCULAS en perl.
    # ++$i indica incrementar el valor de $i y dejar el valor disponible
    # para la instrucción print
    # Todos los valores escalares ( es decir cualquier cosa menos una instrucción,
    # un arreglo lineal, un arreglo asociativo, filehandle, o nombre de procedimiento)
    # empieza con $ en perl # $_ es el operador de default de cualquier instrucción
    # en este caso, $_ contiene el último registro que leyó la instrucción<>
    # ; termina cada instrucción en perl
    }

    Breve revisión de la sintaxis de perl

    • En perl es significativo el caso de los caracteres y se diferencia entre mayúsculas y minúsculas

    • No utilice nombres que empiezen con un numero, ya que estos comúnmente son símbolos especiales para perl, por ejemplo $1, $2, etc.

    • Todas las instrucciones en perl terminan con punto y coma ;

    • Comentarios se pueden insertar en un programa con el símbolo #, y cualquier cosa después de # hasta el fin de línea será ignorado

    • perl identifica cada tipo de variable o nombre de dato con un prefijo. Estos caracteres son:

      Tipo Carácter Comentario
      Escalar $ Un numero o cadena de caracteres
      Vector lineal @ Un arreglo referenciado por un numero índice.
      Subí­ndices entre paréntesis cuadrados [].
      @cosa se refiere al arreglo completo.
      $cosa[1] se refiere al escalar que ocupa la segunda posición en el arreglo
      Vector asociativo % Un vector referenciado por una llave de texto, no necesariamente un número.
      Subí­ndices entre{}.
      %cosa se refiere al vector completo.
      $elemento{“x”} se refiere al escalar que corresponde a la llave “x”
      filehandle UC Los apuntadores se archivo se escriben en mayúsculas
      Subrutina & Una subrutina
      Etiqueta xx: Objeto de goto

    • Valores entre paréntesis () son listas. Las listas se usan frecuentemente como argumentos para una subrutina o llamada a función. No es necesario usar paréntesis si solo se usa un argumento o el programa conoce el limite de la lista.

    • Las variables $x, @x. %x, y &x, no necesitan estar relacionadas entres si, sin mencionar $X, @X, %X y &X.

    • Existen variables especiales, las más importantes son:
      $_
      Es el valor escalar de default. Si no se especifica un nombre de variable en una función donde se usa una variable escalar, se usa $_. Esto se usa bastante en perl
      @_
      Es la lista de argumentos a una subrutina
      @ARGV
      Es la lista de argumentos especificada en la línea de comando cuando el programa se ejecuta

    Instrucciones básicas y control

    Los corchetes {} se usan para contener un bloque de enunciados. Es posible tener variables locales dentro de un bloque. Bloques se usan como los objetos de la mayoría de los comandos de control

    Asignación simple:

    • Asignación escalar

    • Listas de escalares

    • Lista a vector

    • Vector a lista

    • Vectores asociativos necesitan un llave, pero aparte de eso, funcionan como se espera de un vector

    • Al asignar un vector a un escalar se obtiene el numero de elementos del vector

    Operaciones aritméticas

    if-then-else

    • if( condición ) {  rama verdadera  }  else  {  rama falsa  }

      		 

    • if (condición) {instrucciones}  elsif (condición) {instrucciones}

      elsif (condición) {instrucciones}

      		 

    • unless (condición)  {  rama verdadera  }

    • La condición tiene una gama amplia de operadores comparativos. Es importante observar la diferencia entre operadores numéricos y de cadenas de caracteres.

      Numérico Cadenas Significado
      = = eq igual
      != ne no igual
      > gt mayor que
      < lt menor que

    • Cadenas de caracteres. que no están compuestas por números tienen un valor de cero.

    • perl cuenta con un conjunto extenso de pruebas de archivo:

      • -T cierto si archivo es de texto

      • -B cierto si archivo es binario

      • -M regresa el número de días desde la última modificación

      • -A regresa el número de días desde el último acceso al archivo

      • -C regresa el número de días desde la creación del archivo

    Lazos de control
    Los lazos más comunes son for y while

    • for ($i = 0; $i < 10; $i++) { instrucciones }

    • foreach $i (@items) { instrucciones }

    • foreach $i ($first .. $last) { instrucciones }

    • while (condición) { instrucciones }

    • until (condición) { instrucciones }

    • Las instrucciones next, last, redo, y continue se usan para escapar de un lazo.

    Entrada/Salida
    Abrir
    Como en Unix, los tres primeros manejadores de archivos se abren automáticamente y son STDIN, STDOUT, y STDERR. Otros archivos se deben abrir explícitamente. La forma de la instrucción open es la siguiente:
    open (FILEHANDLE,XFY);
    donde X y Y son caracteres opcionales

    X = <
    Para abrir archivo F solo lectura
    X = >
    Para abrir archivo F solo escritura
    X = > >
    Para agregar datos al final de archivo F
    X = |
    Para escribir a un tubo (pipe) hacia programa F
    Y = |
    Para leer a un tubo (pipe) desde programa F

    Si solo se da el nombre F, el archivo se abre de lectura/escritura

    Lectura
    La forma más básica de lectura es poner el manejador de archivos dentro de <>. Si no se provee una variable escalar para el registro, este se guarda en $_.
    Escritura
    La mayor parte de la escritura se hace usando la instrucción print o printf. Estas instrucciones se utilizan aún si el resultado no se va a imprimir realmente.
    Cerrar
    perl cierra automáticamente cualquier archivo al salir. Cuando se necesita cerrar un archivo se puede hacer con un cierre explicito.
    Mensajes de error:

    • die se usa para imprimir un mensaje de error y terminar la ejecución

    • warn se usa para imprimir un mensaje de error pero continuar

    Manejo de cadenas de caracteres:

    • split se usa para extraer fichas (tokens) o campos de una cadena a un vector.

    • sort ordena una lista o vector.

    • study optimiza operaciones de cadenas.

    Codificación binaria:

    • pack empaca datos en una cadena usando un machote de formato

    • unpack recupera datos de una cadena usando un machote de formato

    • Existe una larga lista de formatos que se pueden usar

    • Se puede usar más de un formato a la vez

      • l long 32 bit signed integer

      • L long 32 bit unsigned integer

      • s short 16 bit signed integer

      • S short 16 bit unsigned integer

      • f float 32 bit floating point

      • d double 64 bit floating point

      • A ASCII string

      • c char a single byte (character)

    Expresiones regulares:

    perl añade un conjunto de caracteres al conjunto normal. Uno uso importante de expresiones regulares (RE) es el uso de () para seleccionar subconjuntos de la expresión regular. perl facilita el uso del operador (). Existen dos maneras de usar expresiones regulares en perl: Match y Substitute

    Una expresión regular esta contenida en slashes, y el operador =~ evalúa.

    Las expresiones regulares son sensitivas a mayúsculas y minúsculas

    El operador !~ se usa para detectar diferencias.

    Algunos caracteres especiales:

    .
    Cualquier Carácter menos newline
    ^
    El principio de lí­nea o de cadena
    $
    El fin de línea o cadena
    ?
    Cero o más del último Carácter
    +
    Uno o más del último Carácter
    []
    Cualquiera de los caracteres dentro de los corchetes []
    |
    o inclusivo
    ()
    Agrupar
    Los caracteres especiales $, |, [, ), , / deben ir precedidos por backslash para usarse en expresiones regulares
    $` $& $’
    $` , $& y $’ se pueden usar para ver cuales fueron los caracteres que se encontraron antes, durante, y después de un empate

    Referencias

    Active State

    Active Perl

    Live tutorials

    Distribuciones binarias

    Open Perl IDE

    Documentación.

    Introduction to Perl