Hoy toca hablar de Javascript, hace un par de meses vengo trabajando intensivamente con este lenguaje y tengo algunas cosas que compartir, esta es una de ellas.
En JS siempre se trabaja pasando valores y no referencias excepto en el caso de arreglos, objetos o funciones. En general esto es útil y uno se acostumbra con el tiempo, pero cuando trabajas con objetos complejos que contienen arreglos de otros objetos te topas con unos cuantos problemas, sobre todo al momento de modificar o copiar un arreglo.
Si tenemos arreglos que contienen tipos primitivos hacer copias es simple, existen principalmente dos formas de hacer copias sin que los datos de ambos arreglos queden linkeados: usando el método slice() o el método concat(). Un pequeño ejemplo.
var arregloFuente = ['a','b','c','d','e'];
var arregloDestino = arregloFuente.slice();
o
var arregloDestino = arregloFuente.slice(0);
o
var arregloDestino = arregloFuente.concat();
Estos mismos métodos también se pueden aplicar a arreglos de objetos, con la diferencia que en este caso los dos arreglos contendrán referencias a los mismos objetos, por lo que si modificamos algún objeto en un arreglo este cambio se verá en ambos. Esto puede ser útil para sincronizaciones, pero molesto a la hora de aplicar filtros o duplicar data para modificarla. A nuestros rescate llega jQuery con su método extend() que permite hacer copias "superficiales"( shallow) o "profundas"(deep) de arreglos. Con "superficiales" me refiero a copias que se hacen usando referencias y con "profundas" me refiero a copias usando valores; esto es que, si modificamos un objeto dentro de uno de los arreglos no afectaremos al otro. La sintaxis es la siguiente.
var arregloFuente = [{color: 'rojo', peso: 10},{color: 'verde', peso: 10},{color: 'rojo', peso: 20}, {color: 'amarillo', peso: 5}];
// Copia superficial (Shallow copy)
var arregloDestino = jQuery.extend([], arregloFuente);
// Copia en profundidad (Deep copy)
var arregloDestino = jQuery.extend(true, [], arregloFuente);
Me pasó recientemente que incluso el método extend() no me hizo una copia en profundidad de un arreglo el cual contenía entre sus propiedades otro arreglo con objetos, para este caso lo único que me quedó fue hacer un método propio que haga el copiado del arreglo. Como dato, el arreglo anidado era un objeto observable de knockout, creo que esto tuvo algo que ver con que no me haga la copia en profundidad bien.
Saludos,
Giank.
miércoles, 19 de febrero de 2014
jueves, 13 de febrero de 2014
De regreso al blog!
Dejé de publicar mucho tiempo, pero ya estoy de regreso. Ya tengo más notas, tiempo libre y un proyecto persona interesante que me gustaría compartir. La temática del blog sigue siendo la misma, tecnología y mi vida diaria en internet. So.. I`m Back baby!
Saludos,
Giank
Saludos,
Giank
martes, 16 de octubre de 2012
TempData y ViewData en MVC2
Cuando uno lleva mucho tiempo trabajando con el clásico paradigma de N capas
planteado al estilo .NET y trata de ir al mundo del MVC (también de .NET) se
encuentra con que las clásicas variables de sesión son poco usadas y en su
lugar se usan TempData y ViewData. Aunque en un principio los nombres son algo
descriptivos, estos mismos también son confusos, por lo que me han dado más de
un dolo de cabeza al querer usarlo y más al tratar de entenderlos.
Antes de pasar a explicar el funcionamiento de cada uno de estos debo aclara que Session aún existe, ahora paso a la explicación.
TempData, ViewData y Session funcionan igual en lo que se refiere a la forma de guardar información, todo son pares key - value.
TempData guarda la información solo durante el Request actual y el siguiente, muy útil cuando necesitas pasar data en redirecciones a páginas de error.
ViewData guarda la información solo durante un Request, más específicamente durante el camino Vista - Controlador (y viceversa), muy útil para mostrar mensajes de confirmación.
Session sigue trabajando igual, guarda datos que están disponibles durante toda la sesión de cliente.
Saludos,
Giank
Antes de pasar a explicar el funcionamiento de cada uno de estos debo aclara que Session aún existe, ahora paso a la explicación.
TempData, ViewData y Session funcionan igual en lo que se refiere a la forma de guardar información, todo son pares key - value.
TempData guarda la información solo durante el Request actual y el siguiente, muy útil cuando necesitas pasar data en redirecciones a páginas de error.
ViewData guarda la información solo durante un Request, más específicamente durante el camino Vista - Controlador (y viceversa), muy útil para mostrar mensajes de confirmación.
Session sigue trabajando igual, guarda datos que están disponibles durante toda la sesión de cliente.
Saludos,
Giank
lunes, 15 de octubre de 2012
LinQ To SQL y los archivos dbml
Linq To Sql es un ORM ligero, con soporte para Linq (Tecnologia .NET) integrado. Un ORM es un componente de software que se encarga de hacer el mapeo de una BD relacional a clases/objetos.
Como en todo trabajo con .NET existe una herramienta visual para hacer este trabajo y es realmente útil, en unos minutos podemos tener toda nuestra BD, relaciones incluidas, mapeada en nuestro sistema sin mayor esfuerzo.
Los pasos para trabajar con LinQ to SQL son simples:
Saludos,
Giank
Como en todo trabajo con .NET existe una herramienta visual para hacer este trabajo y es realmente útil, en unos minutos podemos tener toda nuestra BD, relaciones incluidas, mapeada en nuestro sistema sin mayor esfuerzo.
Los pasos para trabajar con LinQ to SQL son simples:
- Se agrega al proyecto un archivo de clases de LinQ to SQL, extension dbml.
- En el explorador de servidores realizamos un conexión a la BD de nuestro sistema.
- Agregamos todas las tablas que necesitemos de nuestra al archivo dbml, esto se hace solo "jalando" las tablas al archivo.
- Nombramos nuestras tablas con los nombres que queramos que tengan las clases en nuestro sistema.
- y listo!
Saludos,
Giank
ActionLink a otro controlador
Siempre hay cosas nuevas que aprender y hoy he aprendido mucho de MVC2. Entre todo mi trajín del día, haciendo el proyecto de DSD, me topé con la necesidad de llamar a un controlador diferente al que manejaba una vista determinada. Busque un rato entre las sobrecargas del método ActionLink, pero no encontré nada que calzara al 100% con mi necesidad, al final me aventuré por un constructor con 5 parámetros y como no tenia idea de que pasarle al último le di un null.. y ¡ohh sorpresa!, funcionó; se hizo una llamada a un controlador diferente al asociado con la vista en la que trabajaba en ese momento. El constructor es este:
Html.ActionLink("TextoDelLink", "NombreDelAction", "NombreDelControlador", new { NombreParametro1 = Valor1, NombreParametro2 = Valor2, etc, etc }, null)
Como "bonus track" para este post, agrego que este método no reconoce entre sobrecargas de métodos en el controlador al que se llame.
Saludos,
Giank
Html.ActionLink("TextoDelLink", "NombreDelAction", "NombreDelControlador", new { NombreParametro1 = Valor1, NombreParametro2 = Valor2, etc, etc }, null)
Como "bonus track" para este post, agrego que este método no reconoce entre sobrecargas de métodos en el controlador al que se llame.
Saludos,
Giank
miércoles, 7 de marzo de 2012
Mi nuevo Razer Onza Tournament Edition
Debido a la mala experiencia con mi experimento iPod-joypad
me quedé con las ganas de jugar con un buen joypad, así que me puse en busca de
uno. Al principio pensé en solo comprar un conector para mandos de PS2 a PC,
pero conforme iba leyendo reseñas y opiniones me convencía de que no era buena
idea. Al final, por pura casualidad, recordé que, según los conocedores, el
mejor mando del mercado es el del Xbox 360 y ya que es un mando inalámbrico me
gusto mucho la idea.
Cuando ya tenía decidido en donde comparar mi futuro mando
Microsoft de Xbox 360 para PC, me encontré con el motivo de este post, mi actual
Razer Onza Tournament Edition. Fue pura casualidad aunque yo lo llamaría
destino. Estaba viendo los anuncios de venta nuevamente y vi que al final de la
lista alguien vendía un gamepad Razer; la marca me sonó al instante, sé que
Razer hace muy buen hardware y que se especializa en pro gaming lo que llamo mi
atención. Hice un par de preguntas al vendedor, leí reviews en internet y me
convencí que ese era el mando que quería.
Hecha la compra regresé a mi casa emocionadísimo, instalé
Gears Of War, conecté el mando y a jugar se ha dicho!.
No tengo nada malo que decir del joypad, su desempeño es
optimo, su peso, sus botones, sus
joysticks, su retro iluminación, su velocidad de respuesta y sus botones
configurables, todo es genial. Si algo malo tendría que decir, es que el cable
que lo conecta a la PC es demasiado rígido y por momentos hace incomodo moverlo
para conectarlo.
Saludos,
GNK.
martes, 6 de marzo de 2012
WifiPad + iPod + Pc = Retrogaming - Resultado
En mi cabeza la idea de utilizar mi iPod como joypad para mi PC y poder jugar viejojuegos de SNES o PSONE parecía buena, pero la verdad fue otra. Puede conectar el iPod a la PC, pude abrir los emuladores y correr los juegos, pero el look and feel es totalmente distinto; además que la funcionalidad de un iPod como joypad no es ni mínimamente parecida a uno de verdad. Es difícil mantener apretado 2 botones a la vez y más difícil aún saber si de verdad los estas apretando a la vez, la distribución de los mismos no es igual, no se tiene a la mano los famosos R y L, y principalmente el "feeling" de tener un joypad real en mano se extraña.
Todo este tema del iPod-joypad despertó mis ganas de jugar nuevamente y decidí buscar algunos de mis no tan antiguos juegos, he comprado un muy buen joypad, pero cual es y que tal me va es tema de otra entrada.
Saludos,
GNK.
Suscribirse a:
Entradas (Atom)
