Sociedad > México > Playa de Acapulco

Les comentare un poco sobre la playa de Acapulco, una de las más famosas de México,  que tuve la oportunidad de visitar recientemente. Fue una gran experiencia pues no solo me permitió conocerla y compararla con las de Cuba a nivel de playas sino conocer su autopista, las ciudades y pueblos intermedios, etc.

Fue mi primer viaje largo en carretera y comenzare por el inicio.

La autopista México-Cuernavaca-Chilpancingo-Acapulco

Esta autopista o carretera atraviesa estas importantes ciudades atravesando 2 estados: Morelos (Cuernavaca es su capital) y Guerrero (Chilpancingo es su capital y Acapulco su puerto principal).  

Casi todo el tiempo la carretera atraviesa zonas de montaña con vistas increíbles. Se nota que a fuerza han abierto las vías a través de las lomas, por lo que existen tramos cuyo lado es una pared natural enorme (la montaña claro). En muchas de esas zonas existe peligro de deslizamientos de piedras y las están fundiendo con mezcla para una mayor seguridad. En otros tramos se optó por abrir túneles que atraviesan la base de la montaña. En otros, puentes inmensos que unen 2 laderas, a una altura considerable. Es todo un espectáculo.

Llama la atención el excelente estado de la carretera. Partamos del hecho que es una autopista con cobro de Peaje, y bien caro por cierto, pero que se nota que dichos fondos se revierten en ella constantemente.

El pavimento con una calidad y terminación excelente, completamente pintado en sus líneas horizontales indicadoras. En el lateral derecho en ambos sentidos de la vía siempre cuenta con espacio suficiente llamado Acotamiento para que los vehículos puedan detenerse si lo necesitan. A determinados intervalos existen recipientes de agua. Es una carretera con separadores de concreto entre ambos sentidos durante sus más de 350 Km., diseñados para proteger bastante de un choque. Posee una Rampa de Frenado, que es una construcción especial diseñada para que si un vehículo se queda sin frenos pueda hacerlo de forma natural: no es más que un pedazo de vía, saliendo de la principal con una pendiente grande y piedras como base que posibiliten una mayor resistencia al movimiento y el frenado final. A intervalos existen dispositivos electrónicos que te dicen a qué velocidad vas circulando y de forma bien visible: algo que si bien no aporta algo muy diferente del velocímetro de tu auto al menos si te hace notar que vas a exceso de velocidad.

En varios tramos la vía estaba recibiendo mantenimiento y es llamativa la cantidad de medidas de seguridad que se aplican durante esas labores para los conductores de vehículos: personas con banderolas a cada extremos avisando con suficiente distancia y señales y separadores plásticos que crean las vías temporales de acceso para no dejar lugar a la improvisación o al despiste de un conductor. Posee servicio médico de urgencia sobre la misma carretera, servicio de mecánicos de autos y otros.

Para una persona nacida y criada en esta parte del mundo nada de lo que he comentado le llamara la atención pero para mi país de origen casi todas estas cosas son dignas de mencionar. Creo que si el Peaje se reinvierte completamente en la vía, como debería ser, pudiéramos comenzar a aplicarlo con más frecuencia en nuestro país, pero aclaro, solo si se reinvierte en su mismo mantenimiento, sino carece de sentido.

Sus ciudades y pueblos intermedios.

Salvo Guadalajara no había estado en otra ciudad fuera del DF. Guadalajara viene siendo la segunda o tercera urbe de México junto a Monterrey por lo que no había tenido la oportunidad de visitar ciudades más humildes. Solo había podido contemplar la imponente riqueza y recursos de sus grandes ciudades que por mucho superan a las nuestras en Cuba, con sus grandes mercados, sus grades plazas, etc.

Pero aquí tuve la oportunidad de contemplar también la humildad de ciudades más pequeñas y de menos recursos. Por momentos me parecía que estaba en nuestro país, acompañado de un clima mucho más similar al nuestro también.

En Acapulco pude contemplar ya un poco de pobreza, negocios bastante sucios y despintados. Personas que tienen que lucharla bien duro para poder vivir también. Sus construcciones a medio terminar, en el ladrillo o el bloque crudo, optimizando los recursos también.

Cuernavaca y Chilpancingo pudiéramos decir que son ciudades similares a cualquiera de las capitales provinciales de Cuba. Tanto en tamaño como en apariencia. Ya el tipo de instalaciones no son como en el DF sino plantas bajas (2 o 3 a lo más), sin demasiada ostentación. Claro que allí el espacio sobra también.

El Clima y la playa de Acapulco

El clima es bien parecido al de Cuba aunque un poco más fresco. El promedio de máximas es de 29 a 30 grados Celsius y al estar en la costa pues es húmedo y con un sol estupendo todo el día. Incluso las noches son calientes, con una media de 23 grados para esta época de año. Por primera vez en 8 meses sentí un clima como el nuestro y es una sensación bien agradable: Un buen sol rompiéndote o quemándote la piel, jeje.

El mar es bien bravo, como es una especie de semi-bahía natural las olas rompen bien fuertes y bien altas sobre la orilla. En Cuba no vi nada parecido en ninguna de las tantas playas que visité. Si te paras a apenas uno o dos metros de la orilla la fuerza de las olas te tira sin contemplaciones contra la arena, arrollándote vulgarmente.

Ahora, lo más decepcionante es la arena de su playa. Es una arena que quizás podamos encontrar en un rio en Cuba o en cualquier arenera. No exagero, la arena es como la vulgar arena que usamos en Cuba para la construcción e incluso llega a ser mucho más gruesa o de granos gordos del tamaño de una moneda de un centavo.

Si solo fuera la diferencia del color pues bien, pero no, es todo. Por ende disfruten de nuestras playas.

Esto también se debe a que Acapulco esta sobre la costa del Pacífico. Siempre había escuchado que las playas del pacífico no son de buena calidad, ahora lo he comprobado.

Los hoteles, normales, tenemos hoteles mejores que varios que vi, otros similares y otros peores. También todo depende de la calidad del hotel pero les aseguro que al disfrutar de cualquier hotel de Santa Lucia, por ejemplo, estaríamos disfrutando de los mismos beneficios.

Nueva sección: Sociedad > México

A partir de hoy voy a escribir sobre algunos temas de sociedad asociados a mi estancia hasta el día de hoy en México.

Aunque parezca que estos temas sociales se salen del contenido central del Blog, no lo es tan, pues forma parte de la experiencia que he vivido y que quisiera compartir con los de adentro: familia, amigos, conocidos y desconocidos, para que, como dice la descripción principal del Blog: “la experiencia no quede sin compartir”.

Todos sabemos que uno de los grandes sueños de todo Cubano es viajar:  más allá de cualquier discusión absurda sobre política tan ligada a nuestra vida, pues también impera la propia naturaleza exploradora del ser humana de conocer todo aquello que está más allá de nuestro horizonte visible. Este sentimiento, o deseo, se multiplica debido a las historias de “los que regresan”, la dificultad para lograr un simple viaje, aunque sea de turismo, más la ausencia de los recursos financieros que se necesitan para ello.

Entonces, una de las grandes preguntas que nos pasamos toda la vida haciéndonos es:

¿Cómo será la vida fuera de Cuba?

Bien, intentare trasmitirle mi perspectiva de la vida en la Ciudad de México, en el Distrito Federal (DF).

Aclaremos que esto es una perspectiva bien personal condicionada por el nivel o clase social en la que encajo en esta sociedad asociada a la que tenía en Cuba. En ambos caso, tanto en Cuba como aquí, mi nivel de ingresos es bastante aceptable, como para ubicarme en clase media. No soy ni era rico, pero tampoco pobre, o de bajos ingresos, por lo que mi salario me da para no tener que preocuparme por las necesidades básicas elementales.

También cuento con una profesión muy solicitada como para tampoco preocuparme por quedarme sin empleo, amén de que me preocupé en su momento (y lo hago cada día) por ser más competitivo, sacrificado y eficiente. Vivo prácticamente en el Centro de la Ciudad y por ende en el centro de su vida social. A muy poca distancia a mi alrededor me quedan las principales zonas históricas, sociales y de farándula.

Entonces pues, espero que les sean de agrado y de interés los temas que trataré, entre los cuales deben estar la vivienda, el transporte, su gente, la diversidad sexual, la violencia, la seguridad, la salud, la educación, el deporte, la cultura, el empleo, la comida y el resto de las necesidades primarias.

Nuevas plantillas para Moviles aquí en BlogSpot

Acabo de ver que esta plataforma de Blog ha puesto a nuestra disposición plantillas para dispositivos móviles: Excelente, y además con un look bastante limpio y de mi agrado.

Bienvenidas todas estas mejoras. A mis colegas les recomiendo que les den un vistazo pues cada vez son mas los que acceden a través de estos dispositivos. Basta con habilitarlas en las opciones.

LINQ to SQL. Tratamiento de Transacciones con TransactionScope (parte 3 final))

Aunque no fue mencionado, la variante primera de lograr transacciones también tenía un problema: No se admitían transacciones anidadas.

La clase TransactionScope viene a solucionar todos los problemas con transacciones, diseñada incluso para el caso que queramos, en medio de una transacción, ejecutar un bloque de código fuera de ella.  Genial!.

Su uso seria en un bloque similar al siguiente:

using (TransactionScope trans = new TransactionScope())

{

    //Operaciones

    trans.Complete();

}

Aquí se extrañaran de no ver algo parecido a un Rollback y un bloque de try..catch en el cual se llame: NO ES NECESARIO. Al utilizar el TransactionScope en un bloque using, el mismo sistema se encarga de deshacer todas las operaciones si al concluirlo no se ha llamado al método Complete().

Claro que un bloque try..catch será necesario para capturar excepciones pero no para llamar a un Rollback específicamente.

Este mecanismo está preparado para hacer transacciones sobre múltiples servidores a la vez, caso en el cual usa el servicio MSDTC de Windows como soporte.

No obstante, no todo es felicidad. Esta clase utiliza un mecanismo propio (por llamarlo de una forma más amigable) en caso que dentro de su bloque se utilice solo una conexión de datos o DataContext. Si se llegan a utilizar dos entonces hace uso del servicio MSDTC para gestionarlo lo que nos obligaría a instalarlo en las PC donde se use el sistema.

En Windows7 de 64 bit existen varios reportes de personas en Internet que no les corre por la ausencia del servicio y en mi caso lo viví en carne propia. Aunque la solución sería la instalación del servicio y listo a mí no me resultaba factible agregar un pre-requisito más a mi sistema así que ajuste el código fuente a que usara siempre una sola instancia del DataContext al menos mientras se estuviera dentro del contexto de la transacción (bloque using).

Hasta aquí lo relacionado a los problemas más relevantes que hemos tenido. Los beneficios han sido muchos más con el uso de LINQ to SQL. Solamente tendría algo importante que criticarle y es que el modelo creado no incluye un par de métodos WriteToXml y ReadFromXml como los tiene la tecnología de Ado.Net con el uso de los DataSet. No es que Linq to SQL no tenga mecanismo de exportar a Xml sino que es, por mucho, más complejo, aunque también ofrece buena flexibilidad.

Todo problema con LINQ to Sql que puedan reportar en este blog será bienvenido.

LINQ to SQL. La Cache, ¿una ventaja o un problema? (parte 2)

Haciendo un buen resumen creo que me ha traído más problemas que ventajas aun cuando las ventajas sean medio invisibles por su propia naturaleza. A lo mejor una consulta es menos eficiente sin el uso del Cache pero no lo vemos.

La cuestión es que LINQ se encarga de manipular lo que ya tiene en memoria y lo que trae de la BD ante una consulta y no nos deja muchas opciones al respecto. Aun cuando existe una propiedad supuestamente bajo la cual le podemos decir al DataContext de LINQ que no utilice el Cache pues solo es funcional para datos de solo lectura.

Realmente a mí me gustaría poder decirle: No uses el Cache, tráeme siempre datos frescos.

El problema es simple, veámoslo en una secuencia de acciones, en donde todas usan un mismo objeto DataContext: 

1. La instancia1 de la aplicación lee la existencia de un producto X = 0. LINQ lo mantiene en Cache.
2. La instancia2 también lo lee. X = 0. LINQ lo mantiene en Cache.
3. La instancia1 consulta de  nuevo la existencia de X y le suma 2. X = 2.
4. La instancia2 consulta de  nuevo la existencia de X y le suma 3. Aquí debería queda X = 3 pero no, resulta que es igual a 3.

 ¿Cuál es el problema?

Que en el paso 4 cuando la instamcia2 consulta el valor de la existencia del producto X el Cache le devuelve el valor 0, aun cuando ya la instancia1 lo ha modificado.

Cuando al DataContext le solicitan datos lo hace a través de su Cache. Si el registro (siguiendo como criterio la llave de la Entidad) ya existe en la Cache entonces no lo consulta desde la BD sino que lo retorna desde allí mismo. Si no existe (solo si no existe) en la Cache entonces lo trae de la BD.

Cuando trabajamos en ambiente web con ASP.Net, sumado a que casi siempre seguimos un patrón Singleton para el DataContext general de la aplicación, no trae problema alguno. Pero en aplicaciones concurrentes es un gran problema.

Una solución es utilizar un DataContext nuevo cada vez que necesitamos datos frescos pero eso desde el punto de vista de la misma lógica no es siempre posible pues necesitamos los datos que ya tenemos y que no estarían en el nuevo DataContext.

Otra solución que encontramos, que usamos un tiempo, y que ni siquiera publicaré porque no me gusta, es crear un mecanismo (un truco) de limpieza del Cache del DataContext que usaremos cuando lo necesitemos, por ejemplo, antes de efectuar el paso 4 de la secuencia de acciones. Con esto obligamos al DataContext a traer de la BD el valor actual.

Pero aquí es donde el desconocimiento nos juega una mala pasada pues existe en el DataContext un método para ello, aun cuando esté poco documentado: Refresh.

public void Refresh(

        RefreshMode mode,

        IEnumerable entities

)

Cuando necesitemos obtener una copia fresca de los datos, por ejemplo de la tabla de Inventarios, podemos usar una sentencia similar a la siguiente justo antes de hacer uso de ella:

dc.Refresh(RefreshMode.OverwriteCurrentValues, dc.Inventories);

var inv = dc.Inventories.Where(i => i.IdProduct == op.IdProduct && i.IdLocation == op.IdLocation).SingleOrDefault();

Ahora, aun cuando esto soluciona definitivamente el problema de obtener datos frescos de la BD nos produjo una seria de problemas, algunos “mágicos” y por ende se nos iban de control.

El primero de ellos es que con una tabla de Clientes de 800 mil registros, en la cual hacíamos una búsqueda elemental, el sistema se demoraba una eternidad. Increíblemente el proceso de Refrescado casi congelaba la aplicación y no me pregunten por qué? Porque no tengo respuestas. En este caso era más factible realizar la búsqueda sobre un DataContext nuevo que sobre el existente y la velocidad era la normal. 

El segundo problema más serio aun es que el Refresh nos generaba una excepción cuando lo usábamos en un entorno de Transacciones como el mencionado arriba (parte1 de este artículo). La excepción nos decía algo así como que la conexión o la transacción no coincidía, etc, etc. Nada, un bugs que busqué un par de veces y no encontré un motivo. 

En el proceso de búsqueda de soluciones encontré una biblioteca de .Net específica para el tratamiento de excepciones. Una clase destinada a tales efectos: TransactionScope, que trataremos en la tercera parte de este artículo.

LINQ to SQL. Problemas y errores comunes (parte 1)

Implementación de Transacciones

Para los que trabajamos con Visual Studio.Net y hemos venido siguiendo su desarrollo desde sus inicios la llegada de “LINQ to SQL” supuso un paso de avance en el trabajo con bases de datos en Sql Server. Pero la migración a esta tecnología no está exenta de problemas y errores que muchas veces cometemos por no leer a fondo sus peculiaridades o por falta de tiempo para hacerlo.

Este artículo está destinado a usuarios que ya conocen y trabajan con esta tecnología. No pretende ser ni mínimamente una guía para principiantes.

LINQ (sin SQL) es un lenguaje de consulta muy potente y su gran ventaja es que puede ser aplicado a simples listas en memoria aun cuando su origen no sea desde bases de datos.

Este uso sobre simples listas en memoria (LINQ to Object) fue el primero que le di a esta tecnología en un proyecto que realizábamos hace ya algún tiempo. Aquí fue donde aprendí (junto con mi equipo) la sintaxis de cada sentencia y sus equivalentes en expresiones Lambda que casi siempre usamos.

Después lo comenzamos a usar en proyectos de ASP.Net con problemas menores que poco a poco fuimos solucionando y nos llevó a ganar en experiencia.

Pero la propia naturaleza de los proyectos Webs (todo corre centralizadamente en el servidor, por lo general se trabaja con una entidad a la vez en cada página) nos hizo muy fácil trabajar con una tecnología que no habíamos leído en sus aspectos más profundos referidos a acceso concurrente a datos y tratamiento de transacciones.

El verdadero dolor de cabezo vino recientemente en una aplicación Desktop que debía tener corriendo varias instancias a la vez modificando y compartiendo datos comunes a todas. En específico se trataba de una clásica aplicación de Venta y Control de Inventario con varios Puntos de Ventas en paralelo.

Cuando leemos sobre LINQ enseguida nos llevamos la idea que es un modelo de Objetos en memoria que mapea la estructura de la BD, de la cual permanece desconectada, que implementa operaciones de manipulación de datos y que mantiene una Cache de datos para evitar el tráfico innecesario y manipular de forma eficiente las operaciones. Dichas operaciones corren en un ambiente implícito de transacciones. Todo eso es bonito pero lo que no es bonito es la interpretación y el entendimiento que hacemos de ello con lo que comienzan a surgir los problemas más serios.

Transacciones implícitas, no tan implícitas.

Transacciones implícitas se traduce en la vida real en que las operaciones que hagamos sobre una misma tabla o entidad se ejecutarán en una transacción (todo o nada) pero no se refiere para nada a que si hacemos operaciones sobre más de una Entidad a la vez y una de ellas falla en el intermedio del conjunto pues se deshagan todos los cambios desde el inicio.

Aquí es donde comenzamos a implementar la primera versión de un modelo de transacciones, como el siguiente:

public static class DataHelper

{

public static IDbTransaction BeginTransaction(AdminDataContext dataContext)

        {

            if (dataContext.Connection.State == ConnectionState.Closed)

            {

                dataContext.Connection.Open();

            }

            dataContext.Transaction = dataContext.Connection.BeginTransaction();

            return dataContext.Transaction;

        }

        public static void CommitTransaction(AdminDataContext dataContext)

        {

            if (dataContext.Transaction != null)

            {

                dataContext.Transaction.Commit();

            }

        }

        public static void RollbackTransaction(AdminDataContext dataContext)

        {

            if (dataContext.Transaction != null)

            {

                dataContext.Transaction.Rollback();

            }

        }

}

Su utilización es trivial en un bloque de código similar al siguiente:

protected DataContext dc = DataHelper.GetDataContext();

try

{

    using (DataHelper.BeginTransaction(dc))

    {

        //Operaciones en varias Entidades

        dc.Inventories.InsertOnSubmit(...);

        dc.Kardexes.InsertOnSubmit(...);

        dc.SubmitChanges();

        DataHelper.CommitTransaction(dc);

    }

}

catch (Exception ex)

{

    DataHelper.RollbackTransaction(dc);

}

Esto nos soluciona el primer y más importante problema pero aún nos quedan otros que fuimos detectando en el camino y que incluso nos hicieron cambiar el modelo de Transacciones, aun cuando este funciona.