A la hora de ponerse a hacer un script para Counter Strike, uno de los principales problemas que tenemos es el de conocer los nombres que reciben las teclas. Las letras, los números y las Fs, están claros, todos son exactamente igual en el teclado que en el script (a es a, 1 es 1, F1 es F1), pero el problema es cuando queremos usar el tabulador, mayúsculas, Supr, Fin, las flechas del ratón, etc… o el teclado numérico (el grupo de numeros de la derecha del teclado).

Teclado:

<tabulador>              "TAB"
ESC                      "ESCAPE"
Espacio                  "SPACE"
<arriba>                 "UPARROW"
<abajo>                  "DOWNARROW"
<izquierda>              "LEFTARROW"
<derecha>                "RIGHTARROW"
Ctrl                     "CTRL"
Alt                      "ALT"
Mayusculas               "SHIFT"
Pausa                    "PAUSE"
Insert                   "INS"
Inicio                   "HOME"
Supr                     "DEL"
Fin                      "END"
AvPag                    "PGDN"
RePag                    "PGUP"

Ratón:

<rueda adelante>         "MWHEELDOWN"
<rueda atras>            "MWHEELUP"
<boton izq raton>        "MOUSE1"
<boton der raton>        "MOUSE2"
<boton central raton>    "MOUSE3"

Teclado Numerico:

0       "KP_INS"
1       "KP_END"
2       "KP_DOWNARROW"
3       "KP_PGDN"
4       "KP_LEFTARROW"
5       "KP_5"
6       "KP_RIGHTARROW"
7       "KP_HOME"
8       "KP_UPARROW"
9       "KP_PGUP"
-       "KP_MINUS"
+       "KP_PLUS"
Intro   "KP_ENTER"
.       "KP_DEL"
/       "KP_SLASH"

De esta forma si queremos, por ejemplo, comprar  una granada HE usando la tecla Supr podemos hacer el siguiente bind

bind DEL "hegren"

El mapeo de los estados dentro del diagrama de evoluciones puede ser representado en Un diagrama.

Plantea la necesidad de un marco de referencia, que permita establecer las mediciones, así como las valoraciones, del desempeño y desarrollo organizacional. 

Consiste en una plataforma de herramientas para analizar el perfil de composición y articulación de la estructura y los procesos internos de entidades organizacionales, con base en un marco de referencia de parámetros descriptivos, su representación y valoración a través de formatos de tipo tabular y matricial.

Mapeando imágenes como evidencia y explicación de un contentido.

La represencación de una forma ficionada a través de palablas, la proyección de una idea puede generar una forma ideal que puede ser reconocible por un grupo. El contenido de las palabras, tanto físicas como abstracctas pueden mostrar en una forma verval, virtual o visual la proyección de los deseos y ilusiones de quien las usa.

El poder de mapear resulta del análisis, la representación y la comprensión/explicación de la información. Esta puede tener diferentes usos y objetivos, condicionados por quien los genera y maneja/mapea.

La mirada generadora de un mapa pretende ser objetiva, pero los criterios de estructuración, gerarquía y visualización son también una evidencia de los intereses de quien los crea y pueden condicionar sus usos.

Su uso puede ser muy diferente si el mapeo se realiza partiendo de criterios y objetivos personales, didácticos o publicitarios, o si la misma información es usada por el gobierno, la industria, el mercado o la investigación.

El Mapeo es una tecnica utilizada por los Vj’s (preguntale a Wiki) para realizar sesiones de proyeccion sobre una pared o sobre casi cualquier cosa, y consiste en calcular y establecer cuales son las dimenciones de los objetos sobre los cuales se van a proyectar para asi poder realizar una buena presentacion visual.

Lo interesante de este asunto es las cosas que se pueden hacen con esta tecnica en la cual se combinan arte, musica y tecnologia, para crear asi una buena presentacion visual, grafica y artistica, aqui les dejo unos videos.

Aunque no lo paresca todos se hicieron con un solo proyector y mucho trabajo e ingenio.

Me gustaria que Dj’s mexicanos pudieran hacer presentaciones asi como estas que cada ves son mas comunes en Europa

Hay mas…

ORM

El mapeo entre el modelo de objetos y el modelo relacional es una solución para conseguir la persistencia de datos en nuestros programas orientados a objetos, permitiendo que se puedan almacenar las instancias de los objetos en una base de datos normal y que luego puedan ser recuperados a su forma usual programática.

Ahora bien, un acercamiento quizás más clásico para esto es el trasladar los datos de los objetos a estructuras de datos simples que puedan ser almacenadas en la base de datos tras un proceso de conversiones, pero esto implica que los datos no son limpiamente almacenados, sino que deben guardarse de otras maneras con algún procedimiento intermedio. Los paquetes ORM automatizan este proceso haciendo las operaciones de conversión transparentes para el programador.

Con un paquete de ORM el programador simplemente indica que quiere guardar un objeto y este se almacena automáticamente en la base de datos relacional, luego el programador puede lanzar un procedimiento que recupere instancias del objeto mediante el paquete de mapeo y obtendría estas instancias limpiamente sin enterarse de las conversiones que tuvieron lugar detrás de bastidores.

Uno de estos paquetes es Hibernate para Java, un nombre bastante apropiado ya que nos refiere a la hibernación, como una analogía a lo que le ocurre a los objetos cuando estos pasan por el mapeo y se convierten en objetos persistentes que luego pueden ser “despertados” para regresar a la actividad en el programa. Esto implica determinados cambios en nuestro enfoque de programación pero serán mínimos y en realidad muy económicamente bajos si hablamos de mantener el modelo de objetos limpio.

Algunos de estos cambios son por ejemplo el contar con una idea básica de características únicas de nuestras instancias que podrían servir por ejemplo como llaves primarias al momento de mapear, además de esto sería necesario el esquematizar varios archivos de configuración que especifiquen como realizar este mapeo, luego el paquete tomará los archivos de configuración y convertirá en cadena nuestras instancias a las tablas.

Ventajas y usos

Esto es claramente útil ya que cada objeto puede guardarse fácilmente, por ejemplo si tuviésemos un juego de computadora donde se trabaja con una gran cantidad de personajes, digamos cada uno un objeto del tipo personaje y cada uno con sus respectivas propiedades como stamina, energía vital, experiencia, etc. Todo iría bien mientras estuviéramos corriendo el juego, cada personaje tendría sus características en tiempo de corrida, pero… ¿Qué pasa si queremos guardar el juego? Sería algo normal pensar en hacer una tabla con las propiedades de los personajes y guardarlos con un ciclo que recorra todos nuestros personajes actuales, pero sería ideal si se pudieran guardar de alguna manera estos objetos, tal como son actualmente en la memoria ram en la ejecución, para que rápida y limpiamente pudieran ser restaurados al reiniciar el juego con un simple “recuperar_personaje()” y esto es precisamente lo que se consigue con ORM.

El tiempo de ejecución por una de estas operaciones podría ser similar al tiempo que se haría con un while una apertura de conexión y el query de almacenamiento, pues es relativamente lo que hace el ORM pero si es una ventaja en eficiencia a la larga ya que estos paquetes están optimizados para esto, pero quizás más importante todavía, proveen un estándar para cada una de las operaciones de mapeo que realizaremos, es decir, no haremos las cosas de un modo y de otro para distintos objetos, evitando confusiones y posibles ciclos de más.

Al estar las funcionalidades de ORM convenientemente encapsuladas en las clases de los diversos frameworks, se facilita además mucho el aplicarles otras técnicas, como un singleton para crear un generador de conversiones orm único que ahorrará la inversión en tiempo procesador y en accesos.

Donde quizás se perciben mejor sus bondades es al lidiar con problemas complejos, como las relaciones entre objetos, como de herencia y otras, que precisamente son planificadas y mapeadas gracias al framework ORM que hayamos escogido.

NHIbernate

En el caso particular de .Net podemos emplear Nhibernate, que es un port del framework Hibernate con las clases transformadas para ejecutarse en este framework superior, la mecánica para emplear NHibernate lleva estos pasos básicos:

1. Copiar los archivos esquemáticos nhibernate-configuration.xsd y nhibernate-mapping.xsd a la carpeta de esquemas de .Net
   
2. Incluir las librerías de Nhibernate en nuestro proyecto.
   
3. Planificar nuestros objetos de tal manera que puedan ser mapeados al modelo relacional.
   
4. Escribir un archivo xml para cada clase donde planteamos como se mapeará el objeto al modelo relacional, incluyendo por ejemplo que campos del objeto formarán la llave primaria en la tabla.
   
5. Programar funciones que faciliten el trabajo con los objetos como procedimientos de igualdad o almacenadores y recuperadores de objetos en masa.
   

Ejemplo

Un ejemplo empleado bastante práctico es el de la creación de objetos de tipo producto y luego facturas que pueden tener muchos objetos, con un modelo de objetos como este:

Esto quedaría mapeado a las siguientes tablas, programables en SQL y generadas por el paquete ORM

Luego, cada una de estas clases tiene que contar con su respectivo archivo de configuración xml donde se indicará como será el mapeo, por ejemplo, para la clase factura el archivo de configuración sería este:

<?xml version=”1.0″ encoding=”utf-8″ ?>

<hibernate-mapping xmlns=”urn:nhibernate-mapping-2.2″ assembly=”Proy.NH01″ namespace=”Proy.NH01.Entidades”>

<class name=”LineaFactura”>

<id name=”Id” column =”IdLineaFactura” type=”int” unsaved-value=”0″>

<generator class=”identity”/>

</id>

<property name=”Cantidad” type=”int” />

<property name=”Precio” type =”Decimal”/>

<many-to-one name=”Factura” column=”IdFactura” />

<many-to-one name=”Producto” column=”IdProducto” />

</class>

</hibernate-mapping>

Aquí notamos como se indica que partes de la clase serán identificadores, que tipos tendrán los campos y las relaciones que se darán en las diversas columnas.

Finalmente se tiene que configurar un archivo de preferencias generales de Nhibernate, el isession factory donde se definen parámetros generales como la base de datos relacional a usar, la cadena de conexión y otros.

<?xml version="1.0" encoding="utf-8" ?>

    <hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >

      <session-factory name="NH01">

        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>

        <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>

        <property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>

        <property name="connection.connection_string">Data Source=localhost\SQLEXPRESS;Initial Catalog=NH01;Integrated Security=True</property>

        <property name="show_sql">true</property>

        <mapping assembly="Proy.NH01" />

      </session-factory>

    </hibernate-configuration>

En el programa definiremos un objeto sesión que usará estas características y donde ya usaremos operaciones simples para persistir los objetos, tales como:

sesion.Save(Objeto1);

Para este ejemplo me base en el excelente blog de uno de los colaboradores de NHIbernate, http://darioquintana.com.ar/articles/tutorial-de-nhibernate-primeros-pasos si les interesa NHibernate ese blog les vendrá como anillo al dedo.

En varias ocasiones hemos dicho que Hibernate utiliza unos ficheros de mapeo para relacionar tablas con objetos Java, hemos dicho también que estos ficheros están en formato XML y que tienen extensión .hbm.xml. Vamos a ver entonces uno de estos ficheros para entrar en detalle y tener al menos una idea de cómo funcionan.

En cyberHotel tenemos una clase que representa una dirección, por lo tanto podemos crear objetos dirección a partir de ella, esta clase dado que es un POJO tiene unos atributos y unos métodos get y set para acceder a los mismos.

Hemos llamado AddressTo a esta clase y addressTo.hbm.xml al fichero de mapeo, que como comentamos en otras ocasiones, se guarda en el mismo directorio de la clase de forma que está en su mismo paquete Java.

Esta es la estructura de addressTo.hbm.xml:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE hibernate-mapping PUBLIC
“-//Hibernate/Hibernate Mapping DTD 3.0//EN”
“http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd”>

<hibernate-mapping package=”gz.cyberbrain.cyberhotel.model.address.to“>

<class name=”AddressTo“ table=”direccion“>

<id name=”addressId“ column=”idDireccion“ type=”java.lang.Long“ unsaved-value=”null“>
<generator class=”increment“/>
</id>

<property name=”country“ column=”pais“ type=”string“/>
<property name=”province“ column=”provincia“ type=”string“/>
<property name=”locality“ column=”localidade“ type=”string“/>

</class>

<query name=”allAddresses“>from AddressTo</query>
<query name=”findByCountry“>from AddressTo address where address.country = ?</query>
<query name=”findByProvince“>from AddressTo address where address.country = ? and address.province = ?</query>
<query name=”findByLocality“>from AddressTo address where address.country = ? and address.province = ? and address.locality = ?</query>

</hibernate-mapping>

hibernate-mapping: Todos los ficheros de mapeo comienzan y acaban con esta etiqueta. Al comienzo indicamos en el atributo package el paquete Java donde se encuentra la clase.

class: Esta etiqueta engloba a la clase con sus atributos, indicando siempre el mapeo a la tabla de la base de datos, así indicamos en name el nombre de la clase y en table el nombre de la tabla a la que representa este objeto. Dentro de class distinguimos la etiqueta id en la cual se indica en name el campo que representa al atributo clave en la clase y en column su nombre sobre la tabla, en type el tipo de datos Java, esto es común para el resto de atributos, pero en id además tenemos la propiedad generator que indica la naturaleza del campo clave que en este caso es increment con lo que estamos diciendo que es un identificador autogenerado por la base de datos, si fuese asignado por el usuario sería assigned. Para más detalle se puede consultar la documentación de Hibernate.

El resto de atributos se indican en las etiquetas property asociando igualmente nombre del campo de la clase con nombre de columna sobre la tabla y el tipo de datos Java.

query: Aquí se indican las consultas que se quieren hacer sobre este objeto, escritas en código HQL (el SQL de Hibernate).

Buenas noches; he estado echando un vistazo, indagando y viendo cómo funcionaba todo esto porque las fotos que tenía geoetiquetadas no aparecían en el mural del grupo.

Y evidentemente ya hemos dado con la solución. Resulta que hay que ir añadiéndolas al mural después de ubicarlas en nuestro mapa. No me había percatado de esto así que no aparecían de ninguna manera, claro. Si alguien cree que es necesario explicarlo con más detalle, a parte de consultar en el foro del grupo, puede decírmelo y edito un pequeño tutorial, aunque ahora que lo he hecho me parece verdaderamente sencillo.

Por supuesto, una consideración, la intención en este grupo es la de etiquetar imágenes, fotografías, de lugares, paisajes, etc. con lo que de algún modo evito, en medida de lo posible, fotos tipo ‘familiares’. Para eso podemos irnos a otro grupo, El Tren de los Rincones de España, que aunque también trata de lugares curiosos, podemos incluir algunas fotos más personales. Ya puestos podemos también pasar por este grupo,  ATravés de tu Mirada, con fotografías más profesionales y expuestas a concurso entre los miembros.

Aprovecho para enlazar el Mapeo Fotográfico de España del que hablo.

(Este enlace lleva al mapa; si buscas fotos de algún lugar concreto, centra dicho lugar en el mapa, ampliando y desplazándolo, y refresca la página pulsando el icono de refresco que hay en la parte inferior, bajo las imágenes deslizantes).