Cosas del día 3 de javascript30:

Hoy es el día 7, pero me salté trabajar el día 4 😦 que era domingo, y el día 5 y 6 estuve programando una landing page

  • El día 3 aprendí:
  • Document.documentElement es todo el HTML
    document.documentelement.style es todo el css. Pero todo, desgranado. (loguealo para que veas)
  • desde JS puedes cambiar cualquier propiedad del css con document.documentelement.style.setproperty xD
  • en document.documentelement.style.setproperty no se van a ver las variables de CSS porque ah� ya est� todo procesado.
  • cuando voy a inicializar algo que puede tener valor undefined, puedo hacer or a la inicializaci�n const subfix = this.dataset.sizing || ” ;
  • data-sizing puede ser utilizado para poner unidades a variables de los inputs (como px o deg)
  • Poner name a un input que va a controlar una variable de CSS puede ayudar al vincularlos en JS

Todo eso estuvo metido en un v�deo de 13 minutos.

Anuncios

JS30 día 2

Voy por el día 5 y no he publicado los otros días así que…
Cosas que aprendí con el proyecto del reloj:

  • no está mal utilizar clases que no necesariamente estén definidas en los estilos. Es para poder acceder a ese elemento desde JS30
  • se pueden temporizar eventos setInterval(setAngles, 1000);
  • las comillas “ son súper importantes (`rotate(${degSeconds}deg)`)
  • Se puede apagar una propiedad de estilo de un elemento hand.style.transition = ‘none’;
  • Se puede volver a encender la propiedad asignandole ” secundero.style.transition=”;

#javascript30 día 1

Quiero hacer uno de esos #100DaysOfCode y pensé comenzar con algo más pequeño como el #javascript30.

Las cosas que he aprendido nuevas en el día uno son:

  • HTML5 tiene un tipo de dato custom data- que se utiliza para guardar datos que pueden requerirse por javascript. En los vídeos de wes bos utiliza el tipo de dato custom data-key.
  • document.querySelector te deja selecciona un elemento del DOM. Se trae todo el elemento como está escrito en el DOM ej. <audiodata-key=”76″src=”sounds/tink.wav”></audio>
  • addEventListener Puedo escuchar a cosas que haga el usuario, pero también puedo escuchar otros eventos como cuando una transición termina.
  • Puedo escribir código en la consola del navegador xD
  • Cuando no entiendo qué significa this, puedo hacer console.log(this)

Cosas que no entendí:

  • en `audio[data-key=”${e.keyCode}”]` porqué usa los “?

Eso de los “ resulta que es un tipo de string que permite dos cosas:

  1. hacer string multi líneas
  2. hacer strings que permiten evaluar funciones, o poner nombres de variables adentro.

Día 1 listo. Estoy bajando el vídeo del Día 2 por si acaso.

Git: “already up to date” pero no…

Aprender rompiendo puede resultar en que pasas mucho tiempo reparando las partes rotas.

El problema: mi compañero y yo creamos ramas diferentes de un repositorio, (jugamos a hacer commits, push y a cambiarnos de ramas y seguimos desarrollando cada quién por su cuenta) y cuando necesitamos integrar de nuevo nuestras ramas al repo principal nos encontramos con este mensajito: “already up to date”.

Pero no, los archivos de los tres repositorios son diferentes y de alguna manera los repositorios están al día.

Una búsqueda en google arroja muchos resultados, y en particular este de stackoverflow parece prometedor la cuestión es que después de leerlo, todavía no entiendo ni el problema, ni la solución.

Luego de dos día de flagelarme acudí a los hechiceros de FccCaracas, donde me recomendaron el siguiente procedimiento:

git checkout master && git reset HEAD --hard && git clean -dfx && git pull origin master

Esta primera línea te ubica en la rama máster, y hace ese reset. De todo lo que leí, aprendí que reset –hard y rebase no son comandos tan comunes, así que hay que estar bastante seguros de si es necesario utilizarlos.

Git Clean -dfx limpia los archivos que no son necesarios del repositorio (acá me volé las DLL y la base de datos de la aplicación que luego tuve que buscar otra vez). Y el último git pull origin master es para sincronizar el master local con los cambios del master en origin.

Acá me queda la duda de sí luego de ese último pull debí sincronizar mi master con el de origin 😦

git checkout Feature1 && git pull origin master

git checkout feature1 hace que se active mi repositorio, y al hacer el pull de master me traigo los posibles cambios que estén allá. Acá hay que ir a la herramienta de merge (en mi caso es Visual Studio) y solucionar los conflictos a mano. Luego los cambios se fijan con un commit

git add . && git commit -m "arreglar diferencias entre Feature1 y master" && git push -u origin Feature1

El último push lleva la rama Feature1 al origen. Hasta acá todo bien. Luego con la herramienta de VSTS realicé un pull request de Feature1 y master et voila.

Tuve que repetir el mismo proceso con la rama Feature2 de mi amigo.

Post-mortem

Me hubiera gustado pedir ayuda a un amigo que me explicara lo básico para no estar inventando. Aprendí más dañando, pero también invertí muchísimo tiempo.

También me hubiera gustado comenzar con un proyecto de una persona: mi repo y el de mi amigo estaban configurados diferente (el mío no hacía tracking del repo origin/feature) por lo que solucionar los dos problemas tomó dos soluciones diferentes.

Y bueno, ya vi que si tengo un par de horas trancado, mejor llamar a un amigo.

¿Cómo salir adelante?

O debería decir “Cómo salir” y ya.

En general, la decisión de emprender es complicada para muchos y ese camino está sembrado de sueños y desesperanzas. En lo particular, creo que el principal obstaculo es la inseguridad que tiene cada quién.

Para mi, esta inseguridad es un mostro de 3 cabezas:

gigante

La limitante personal que uno se repite es que no tiene las habilidades suficientes para continuar. A veces esto se esconde detrás de la mentira blanca de “voy a hacer un curso que me permita agarrar un mejor trabajo” pero la verdad es que muchas veces se aprende más metido en la candela que sentadito en la biblioteca.

La limitante temporal es que a veces el tiempo no alcanza para hacer lo que quieres. La verdad es que al día dedico mucho tiempo a cosas como preparar la comida, jugar con el cel, o simplemente no sé en qué se va el día.

La limitante de la experiencia va de que teniendo el tiempo y las habilidades, nos congelamos cuando vemos a la competencia, e imaginamos el tamaño de sus problemas, y el tamaño de sus soluciones, y nos achicamos al tamaño de no hacer nada.

Matando mostros.

starshiptroopers.jpg

Las limitantes personales son tan dificiles de superar como las limitantes externas. Y acá voy a dejar mi granito de arena:

Dedicar una hora al día a un proyecto luego de un año, equivale a 15 días trabajando sin parar, sin dormir. O siendo más realistas, a dos meses de trabajo de 8 horas, de lunes a viernes.

La constancia en el tiempo da frutos pero no está garantizado. No todo el mundo que trabaja arduamente es exitoso. Pero la suerte sí le sonrie al que la enamora.

Prueba una idea a la vez, y dale tiempo para madurar. Si le dedicas a cada idea 2 años, en los próximos 40 años vas a poder desarrollar 20 ideas completamente. Y habrás crecido con ellas. Que cada oportunidad te permita aprender y te deje dinero para ayudar a la idea siguiente.

Aprende en el camino y come las verdes. Una hora al día los próximos 2 años, o hasta que termines. Lo que pase primero.

t vs z.jpg

Aprendiendo Sass: Mixins

Sigo peleando. No he terminado el primer set de vídeos y eso me trae un poco cabezon. El curso de sass dice que es de tres horas, y ya llevo tres días y todavía no termino.

Mixins

Problema que resuelven: reutilización de código de CSS. Paul Graham en su libro Hackers Vs. Painters defiende que si tienes que copiar y pegar código dentro de tu aplicación, entonces estás programando mal. Kevlin Henney también respalda esta idea.

Al comienzo los mixins recuerdan un poco a las macros de C; pedazos de código que se agrupan con un identificador. Luego, cada vez que vas a usar ese segmento de código, en vez llamas a la macro.

La principal diferencia entre las macros y las funciones es que las primeras son preprocesadas, y las segundas son compiladas. Entonces un mixin es más parecido a una macro que a una función.

Uso de un mixin

En la página oficial de Sass hacen un comentario interesante de los mixins, y es que en CSS3 hay que definir propiedades con prefijos de cada navegador (vendor prefixes)

@mixin border-radius($radius : 15px) {
  -webkit-border-radius: $radius;
     -moz-border-radius: $radius;
      -ms-border-radius: $radius;
          border-radius: $radius;
}

Y para estos casos es útil la herramienta. El llamado se realiza mediante la directiva @include:

.box { @include border-radius(10px); }

Nota que la definición original tiene un argumento $radius, y que en el llamado al mixin se pasa un valor de 10px. Si no se pasa ningun argumento en el llamado de border-radius, entonces el valor por defecto de radius es de 15px.

Y básicamente esto es todo amigos.

Aprendiendo Sass: @, $, ; o nada?

Comencé un curso de SMACSS en teamtreehouse.com con @guilh y hasta ahora la cosa pinta muy bien.

El primer ejercicio con el que me encuentro (y sin saber nada de Sass) es este:

$font-url :"https://fonts.googleapis.com/css?family=Roboto";
@if variable-exists(font-url){
 @import url($font-url)
}

y veo que para $ hay una estructura, pero no entiendo muy bien de qué va

  • $ se usa para decir acá hay una variable
  • Pero en la línea 3 también se usa para llamar a la variable
  • Aunque en la línea 2 no se usa,  porque se quiere saber si el nombre existe.

Ok, acá entiendo. Valor ($) Vs. Referencia (sin el $)

Peeero… el @:

  • hay funciones como el if, y el import que lo requieren,
  • Pero otras funciones como el url y el variable-exists no lo requieren

Bono: ¿Porqué si se supone que es sass, tuve que poner el punto y coma luego de la definición de la línea 1? Será algo del teamtreehouse?

Despues preguntan que porqué prefiero CSS y JS vanilla… #devrant