lunes, 12 de octubre de 2015

Trucos CSS Entendiendo las medidas relativas rem y em


Es común hoy en dia mirar un archivo css con definiciones para ancho y largo con rem o em, ya que en la actualidad se necesita que las páginas web tengan su diseño escalable y es debido a que la página debe visualizarse en cualquier pantalla.

En css (Hoja de estilos en cascada - Cascading Style Sheets) existen dos grupos generales de medidas para definir el espacio que va ocupar los elementos html y como va hacer el espacio entre los elementos y los elementos internos; el primer grupo se define como medidas absolutas que es si es una medida completa que representara siempre el valor que se especifique entre estas medidas tenemos los pixeles (px) que es si representa un pixel de la pantalla y las siguientes, in - pulgadas, cm - centímetros, mm - milímetros, pt - puntos, pc - picas.

El segundo grupo son las medidas relativas, y se nombran así porque son medidas que dependen de una referencia a un valor o una medida absoluta, y de cierta forma al usar estas medidas los elementos se adaptan a los diferentes dispositivos, para no hacerlo tan largo, las medidas rem y em son medidas que se basan en la anchura de la letra m mayúscula (M) del tipo de fuente que se utilice, la diferencia entre las dos es que em inciden la herencia de los elementos y rem siempre toma de referencia el elemento padre (la etiqueta ) del documento para definir el tamaño, veamos esto con el siguiente código.

link al código en github
Definimos dos etiquetas div y le asignamos unos estilos personales a cada uno, uno con medidas en em y el otro con medidas en rem; al visualizar la página los dos bloque son idénticos tanto en alto y ancho como en tamaño de letra.



Al visualizar con el inspector de elementos del navegador (en este caso estoy usando chrome) podemos ver cuánto en pixeles representan los valores otorgados a los div, y lo describo, tanto el height y width de ambos div son de 160px y los valores con sus medidas que se asignaron a estos div fueron de 10em y 10rem lo que no lleva a concluir que un rem o un em equivale a 16px (160px/10em), pero de donde podemos sacar el valor de referencia de 16px, con la ayuda del inspector de elementos lo podemos descifrar; segun la teoria tanto em y rem toman como referencia la letra M de la fuente que se esté usando, lo que nos lleva a pensar que en si lo que buscamos es el font-size definido, al dejar seleccionado uno de los elementos div y desplazar el scroll al final de la sección en donde esta el cuadro que muestra el tamaño, padding, border y margin del elemento logramos identificar lo siguiente.



El ancho y alto es de 160px, y lo que nos interesa es el font-size que está definido de 16px, con lo que concluimos que ese es el valor de referencia de las medidas em y rem, además tenemos otro dato importante, el cual es el tipo de fuente que se está usando y esta es la Time New Roman; lo que nos lleva a nuestro siguiente experimento, si, si exacto como lo piensas, cambiar el tamaño de la fuente. Comencemos por cambiar el tipo de fuente, para esto definimos la siguiente regla css.
body{
   font-size: 20px;
}
y con esto obtenemos lo siguiente



El tipo de tamaño de letra del título cambio y también lo hizo el tamaño del div que definimos con em pero el definido con rem sigue igual, el div definido con em tiene altura y anchura de 200px y el font-size es de 20px, si pensamos un poco en la teoría que mencione al inicio, llegamos a la conclusión de que rem toma su referencia del elemento root, y esta es la etiqueta html del documento, ahora cambiemos el tamaño de la fuente para esta etiqueta y le daremos el valor de 30px.
html{
  font-size: 30px; 
}
Con esto obtenemos lo siguiente



Con esta prueba ya tenemos más que claro que rem y em dependen del tamaño definido de la fuente y que rem siempre toma de referencia la etiqueta raiz (), para ver cual es el punto de referencia de donde toma el tamaño em, haremos lo siguiente, crearemos varias etiquetas div y dentro de ellas dejaremos las dos etiquetas div definidas con em y rem, esto sera asi, a la etiqueta html de definiremos el font-size en 10px, la etiqueta body con font-size 15px, el primer div con font-size 20px, el segundo con font-size con 25px, y finalmente un cuarto con un font-size de 30px y este será el código.

link al código en github
y esto es lo que obtenemos




El div definido con rem (div inferior), tiene alto y ancho de 100px, con esto es más que claro que la referencia de rem siempre la va a tomar del tamaño de la fuente definida en la etiqueta html, ahora para el div definido con em, el alto y ancho es de 300px, con lo que tenemos que la referencia la tomo del div con clase .div3 el cual se definió con un font-size de 30px, con esto concluimos que em toma su referencia del tamaño de fuente definido de la etiqueta padre en este caso el tercer div.

Llegados a este punto, la pregunta que surge es ¿cuál de las dos medidas es mejor usar?, por el momento eso va en gustos, a mi me gusta usar mas rem debido a que siempre va a tener una referencia la cual la es fácil encontrar y se me hace mas claro ya que para definir el tamaño de cualquier elemento tengo a la mano el tamaño, em no lo uso mucho debido a que se debe tener en cuenta los elementos anidados y si hay una pagina con mucho código esto puede llegar a ser confuso; si no estoy mal creo que la w3c prepara un estándar con rem, pero esto es un rumor o sea que mejor esperemos a ver que publican.

Bueno como siempre, espero que les sea de utilidad, trate de hacer un laboratorio, experimentar las cosas es lo que me gusta y el mejor metodo que tengo es el ensayo y error, me divertí haciendo los códigos y esperaba hacer un post más corto, ir al punto en si, pero ya saben me gusta experimentar y a la final medeje llevar.

Los códigos estan en github, para la próxima lo subire a gitlab y para un próximo post hablaré de gitlab, tambien escribire sobre algo que quiero aprender sobre unas librerías de javascript para videojuegos.

hasta la próxima que espero sea pronto, y si te gusto el post, compartelo en tu canal, blog, o en tus redes sociales.

happy coding

lunes, 6 de julio de 2015

Visual Studio Code multiplataforma, prueba en Linux

Buenas, hoy voy a comentar sobre un editor de código bajo la tutela de Microsoft, el cual lo han nombrado Visual Studio Code (https://code.visualstudio.com); y tu dirás “pero hay muchos editores de código”, si, si es la verdad y como ejemplo voy a nombrar unos que he usado como Sublime Text (http://www.sublimetext.com/) y atom (https://atom.io/), que realmente me parecen muy buenos; pero realmente me llamo la atención porque es multiplataforma, si, Microsoft le está apostando a que sus aplicaciones funciones en varios sistemas operativos y si vemos un poco la estrategia de Microsoft ahora, nos daremos cuenta que anda comprando aplicaciones que sean multiplataforma, como por ejemplo la app que compro hace aproximadamente un mes Wunderlist (https://www.wunderlist.com/es/), otro punto que me llamo la atención es que hasta el momento es free, si, si lo puedes descargar sin pagar un céntimo y bueno alguno dirán pero es que Microsoft te copia información y plin y plan, pues sí, pero te lo dicen antes de instalarlo ya es tu decisión, mientras escribo esto me he dado cuenta que lo han actualizado a su versión 0.5.0 y yo tengo instalado la 0.3.0, tal vez sea que para eso es que recopila la información, esperemos que siga siendo freeware; jeje, me acorde de algo que leí cuando estaba en la universidad lo dejare y para los entendidos le sacara una sonrisa.

“Si Microsoft alguna vez hace una aplicación para Linux eso significa que habré ganado“.

Bueno pues mano a la obra, llevo un tiempo usando el visual studio code en Windows, y me ha parecido muy bueno, tiene intellisense para varios lenguajes (php, javascript, asp, C#, y muchos más), te permite abrir carpetas como si fueran proyectos, abrir proyectos de Visual Studio, y te permite trabajar proyectos con Node.js, esta característica no la he probado aun, pero me lo creo, también se puede hacer debug y algo que me gusto es que lo puedes enlazar con Github (https://github.com/), es algo que también he visto y usado en Visual Studio 2013 en su versión express y es algo que te deja claro que Microsoft está cambiando un poco de mentalidad, bueno hasta el momento eso es lo que quiero creer, y me gusta.

De tanto probarlo y hablar bien de Visual Studio Code, se me antojo por instalarlo en Linux, y que creen funciono de maravilla, lo probé en una máquina virtual, use lo siguiente


La máquina virtual la configure de la siguiente forma: Memoria de 2048 MB, disco duro de 20 GB en un solo archivo y listo.

Cree la máquina virtual, instale el ubuntu que por cierto a cambio mucho desde la ultima vez que lo use, realmente de Linux me gusta más OpenSUSE(https://es.opensuse.org/Bienvenidos_a_openSUSE.org) lo tengo instalado en mi portátil y una versión viejita y ha funcionado tan bien que no lo he querido actualizar pero ya va siendo hora, creo que van en la versión 13 algo y yo tengo instalada la 11.2; me gusto el aspecto de Ubuntu pero no voy a cambiar a openSUSE, así quedo.

Luego entre a la página de Visual Studio Code para descargarlo

Como el sistema que descargue es de 32 bit, fui al lugar indicado para ello (seguí el link available on other platforms).


Descargue la versión para 32 bits, leí los requerimientos y solo decía que necesitaba de dos librerías y ya me estaba entrando la duda (¿necesita tampoco?), por suerte la versión de Ubuntu que descargue ya las tiene instaladas por defecto.



La descarga es un archivo en formato zip, lo descomprimí, a lo cual se creó una carpeta nombrada VScode-linux-ia32



Abrí la carpeta y ejecute el archivo Code.   


¿que como lo ejecute? pues doble clic, y…. tachan



Cacharree como por 40 minutos y le funciona todo, jeje estoy mintiendo, no probé lo de node.js y lo de github pero ya te toca a ti, realmente me dejo con buen síntoma la prueba fue muy fácil instalarlo, fue genial que funcionara tan rápido, en lo personal me gusta mucho la interfaz de usuario del editor, es sencilla, clara, te deja mucho espacio para echar código, en definitiva me gusto y espero que el editor siga mejorando y lo mejor que siga siendo free.

Gracias y hasta la próxima.
 

viernes, 26 de junio de 2015

Forman Equipo Microsoft, Google and Mozilla para agilizar el procesamiento de los navegadores

Buenas, hoy quiero escribir, mmmm, más que escribir comentar, sobre algo que está por pasar en la web y sobre los navegadores web, es algo que me sorprendió a pesar de que ya lleva un tiempo la noticia pero me entere apenas ayer.

Cuando lees “Microsoft, Google and Mozilla team”, pues hombre eso causa atención completa, ¿Microsoft haciendo equipo?, pues dirás desde hace rato están haciendo equipo, si, si, pero ahora lo hacen más seguido, y lo que esta pasado ahora ultimo con Microsoft, pues es sorpresivo como por ejemplo dejar libre el .Net Core eso es genial, depronto escribere algo sobre ello, te imaginas compilar y ejecutar codigo en .NET en plataformas Linux, MacOS, iOS y Android, puufff la pasada mano yo pense que eso nunca pasaria.

Bueno pero esta este grupo se ha formado para hacer que los navegadores interpreten más rápido el código y de esta forma se ejecuten de manera más eficiente las aplicaciones web, en si en lo que están trabajando es en desarrollar un WebAssenbly (como yo lo veo es como una especie de bytecode), que promete una forma de compilar el código fuente de las aplicaciones web de tal forma que el navegador lo procese más rápido; algo que me gusta segun dicen, es que al compilar código en C++ (seee c++, es uno de los lenguajes que más me gusta) se puede conseguir un 70% de la velocidad nativa de los navegadores; bueno, bueno y que tal si estas empresas se les da por estandarizar el motor de renderizado, pues hombre, eso sí que nos facilitaría la vida a nosotros y mas que todo a los diseñadores web o los frontend de la web, eso seria lago maravilloso; bueno pues dejo el link de la noticia y como vez es del 18 de junio del 2015 y un link donde explican un poco mas como funciona esto del WebAssenby, aaaah y dejo la misión del grupo.

“The mission of this group is to promote early-stage cross-browser collaboration on a new, portable, size- and load-time-efficient format suitable for compilation to the web.”



domingo, 31 de mayo de 2015

Postback en ASP.Net desde el cliente javascript

Cuando inicie en el desarrollo de aplicaciones web dinámicas, inicie con ASP.Net y me gusto realmente, creo que fue más por el entorno de desarrollo, ya que para ser franco el mejor debbuger que he usado ha sido el de Visual Studio, algún día escribiré sobre mis inicios en el desarrollo web jeje; cuando estaba aprendiendo ASP.Net en ese entonces lo primero que hay que tener claro es el concepto de postback, para decirlo de una manera simplista digamos que es el enlace entre el cliente y el servidor cuando se genera un evento en alguno de sus controles desde el lado del cliente y de esta forma enviar la página nuevamente al cliente con las modificaciones respectivas, claro que hay que agregarle más mecanismos como el de mantener la información entre los llamados y más (perdón desarrolladores de .Net por explicar así de simple, ja escribir es tedioso a veces).

Cuando ya se ha desarrollan algunas páginas, siempre entra la duda de cómo hacer un llamado a los métodos del code behind desde el lado del cliente o mejor desde javascript, es algo lógico cuando se inicia, el motivo al escribir este post fue eso, una pregunta, una pregunta que nos formular los nuevos desarrolladores y con esto no quiero decir que lo sé todo, es más siento que conozco muy poco de ASP.Net a pesar de llevar 6 años (fecha actual 2015) desarrollando en esta tecnología, pero como uno de mis objetivos es ayudar pues escribiré sobre la cuestión en marcha.

ASP.Net provee de un forma de realizar el postback desde el cliente, es algo que nació con ASP.Net debido a cómo funcionaba ASP, en si es una mejora que implementaron para su tecnología pero como todo, eso depende desde el punto de vista en el que se mire.

Esta forma de realizar un postback, se logra gracias a un método de javascript, este es el __dopostbak(), y su implementación es la siguiente:

       function __doPostBack(eventTarget, eventArgument) {
            if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
                theForm.__EVENTTARGET.value = eventTarget;
                theForm.__EVENTARGUMENT.value = eventArgument;
                theForm.submit();
            }
        }

Es una función sencilla pero poderosa, así deben ser las cosas; esta función tiene dos parámetros de entrada, eventTarget es el identificador del control que causa el postback y eventArgument es información adicional asociada al control y/o acción que se desea realizar, además de esto la implementación de esta técnica tiene dos controles HTML que son los siguientes.

<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />

Bueno ya te puedes imaginar para que se definen, correcto ya lo tienes, es para que el valor se pueda acceder desde el code behind de nuestra página osea para identificar qué control ha realizado el postback en simples palabras; esto se realiza automáticamente en ASP.Net para la gran mayoría de los controles. Para tener en cuenta, según la definición que se encuentra en MSDN, en ASP.Net hay dos controles que realizan el postback digamos que de forma nativa (Button y ImageButton), los demás controles usan el método __dopostback y los input ocultos para tal propósito al igual que vamos hacer nosotros para dar una solución posible a la cuestión en marcha, digo posible porque pueden existir otras soluciones.

Listo, centremonos en el caso, necesitamos llamar a un método creado en el code behind desde el cliente para ejecutar alguna tarea en específico  (bueno desde una función javascript desde el cliente, hay que especificar ahora, porque ya se usa javascript desde el lado del servidor), para que este truco funciones (si truco, debe existir una forma más elegante e ingenieril :/ ), se necesita que nuestra página tenga algún control de servidor y que no sea ni el Button o ImageButton, y ¿Por qué será?, si señor, correcto es por eso, que atentos están.

Para realizar esto crearemos un proyecto web en visual studio express (voy a usar el 2013), lo nombrare Demos para ejemplos futuros, que sea limpio (Empty) y seleccionare tecnologías Web From, MVC, Web API, osea todo lo que me puede ofrecer, como dicen por ahí “pensando en el futuro”.


Listo, ahora se agregara un formulario nombrado DoPostback, la idea es simple agregar un control de servidor (TextBox) y ponemos el atributo AutoPostBack en true, se creara un elemento div con su evento onclick que llamara a una función javascript en la cual realizaremos el llamado a la función en el code behind, un ejemplo sencillo pero es para mostrar la idea a la cuestión. Ahora sí, manos a la obra.

El Código HTML (resumido).

<head runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Demo dopostback</title>
    <script type="text/javascript">
        function LlamarMetodoCodeBehind() {
            var accion = document.getElementById('txtEventArgument').value;

            if (accion === 'servidor1') {               
                __doPostBack('divCliente', 'Evento1');
            }
            else {
                __doPostBack('divCliente', 'Evento2');
            }
        }
    </script>
</head>
<body>
    <form id="frmDopostback" runat="server">
        <header>
            <h1>Demo DoPostback</h1>
        </header>
        <div>
            <div>
                <asp:TextBox ID="txtEventArgument" runat="server" AutoPostBack="True"></asp:TextBox>
            </div>
            <br />
            <div id="divCliente" style="width:150px; height:20px; background-color:ButtonShadow" onclick="LlamarMetodoCodeBehind();">
                Llamar Servidor
            </div>
        </div>
    </form>
</body>
</html>

Aquí se puede observar tanto la función javascript como los elementos html que se definieron para el demo, valga aclarar que el control TextBox (txtEventArgument) tiene activo el AutoPostBack con el fin de que se agrega el método __doPostBack() en el cliente, si no, en la función javascript se generaría un error de método no implementado.

Code Behind (Resumido)

              protected void Page_Load(object sender, EventArgs e)
        {
            if (Page.IsPostBack)
            {
                string idControl = Request.Params.Get("__EVENTTARGET");
                string argumento = Request.Params.Get("__EVENTARGUMENT");

                string script = "";

                if (idControl.Equals("divCliente"))
                {
                    if (argumento.Equals("Evento1"))
                    {
                        script = string.Format("", txtEventArgument.Text, argumento);
                        mostrarMensaje(script);
                    }
                    else
                    {
                        script = string.Format("", argumento);
                        mostrarMensaje(script);
                    }
                }
            }
        }

        private void mostrarMensaje(string script){
            Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "postback", script);
        }


Aquí tenemos una especie de filtro en el evento de página Page_Load, capturamos el identificador del control que realizo el llamado a __doPostBack(), el cual definimos en su parámetro de entrada, y capturamos el argumento que también lo pasamos como parámetro, con esto ya podemos comparar según el retorno de estos valores que hacer, aquí simplemente verificamos que el control que llama es divCliente, si es así analiza el argumento, si el argumento es “servidor1” realiza el llamado al método mostrarMensaje para imprimir un alert con un mensaje en específico, aquí se puede ver que el control TextBox cuando se digita algo en él y pierde el foco, el argumento __EVENTTARGET tiene el id del control (usa el debbuger de .Net).

Teniendo en cuenta lo anterior podemos imaginar que esta forma de usar el método __doPostBack() que ofrece ASP.Net nos puede ayudar en muchas cosas como por ejemplo.
  • Crear controles de usuario con eventos programados por nosotros.
  • Realizar un llamado al code behind para que realice alguna tarea en específico.
  • Darle capacidad a controles simples html para que sean analizados en el code behind y se realize algo en específico.
  • Etc.

Por ejemplo, yo uso normalmente el __doPostBack cuando se abre una ventana modal y al cerrarla se retorna algún tipo de resulta, dependiendo del resultado realizo un llamado a algún método del code behind en específico, realmente me ha ayudado mucho.

Como siempre digo lo que se presenta aquí no es una solución elegante o regla a usar, tiene muchas falencias de una buena programación, pero para eso estamos todos, sería bueno que el que tenga el conocimiento comparta en qué casos se debe usar y más como es la forma correcta de usarla, hay desarrolladores que recomiendan que no se debe usar directamente el nombre de la función __doPostBack en el código, que se debería hacer una referencia a ella por si de pronto a Microsoft le da por cambiar el nombre o su definición de parámetros quede fácil realizar dicho cambio en la aplicación.

Dejo el link en GitHub del proyecto y por favor si lo usan no modifiquen la raíz creen una rama, para que el ejemplo inicial quede para todos.

No siendo más, me despido, espero que sea de utilidad y por favor comenten, ya sea malo o bueno pero siempre a nivel constructivo.

happy coding :).