l sistema de control de versión que más se ha extendido en los últimos años posiblemente sea Git. Algo que no ha pasado desapercibido para los desarrolladores de Microsoft. Así que han decidido integrarlo en todas sus herramientas. Y este hecho… Me ha destrozado la vida. ...
El Proyecto Matriz #113 TERESA FORCADES UNA REFLEXION Y UNA PROPUESTA EN...Proyecto Matriz
A diferencia de la vacuna de la gripe de cada año, la vacuna de la gripe A contiene sustancias coadyuvantes tan potentes que pueden llegar a multiplicar por 10 la respuesta inmunitaria normal. Además, se recomienda en dos dosis, a recibir tras la inyección de la gripe estacional, que también contiene coadyuvantes, aunque de potencia menor. Nunca antes se han inyectado estas sustancias tres veces seguidas en la población general, empezando por niños, enfermos crónicos y embarazadas. TERESA FORCADES (El Periódico, 7 de octubre 2009) http://elproyectomatriz.wordpress.com/2009/10/09/teresa-forcades-una-reflexion-y-una-propuesta-en-relacion-a-la-nueva-gripe/
Team have to work with a client to help re-develope a marketing plan analysis strategy with social media platforms.
This course is an introduction to the promotion element in the marketing mix, focusing on the integration of all elements, including advertising, personal selling, public relations, sales promotion, sponsorship, interactive marketing, and other marketing channels. You will master new web-based technologies, such as Twitter, LinkedIn, WordPress and other social media. As a writing intensive course, you will write - individually and as a team - a wide variety of marketing communication pieces using standard technology (i.e., desktop word processing) and web tools, such as Google Docs and online blogging.
El Proyecto Matriz #113 TERESA FORCADES UNA REFLEXION Y UNA PROPUESTA EN...Proyecto Matriz
A diferencia de la vacuna de la gripe de cada año, la vacuna de la gripe A contiene sustancias coadyuvantes tan potentes que pueden llegar a multiplicar por 10 la respuesta inmunitaria normal. Además, se recomienda en dos dosis, a recibir tras la inyección de la gripe estacional, que también contiene coadyuvantes, aunque de potencia menor. Nunca antes se han inyectado estas sustancias tres veces seguidas en la población general, empezando por niños, enfermos crónicos y embarazadas. TERESA FORCADES (El Periódico, 7 de octubre 2009) http://elproyectomatriz.wordpress.com/2009/10/09/teresa-forcades-una-reflexion-y-una-propuesta-en-relacion-a-la-nueva-gripe/
Team have to work with a client to help re-develope a marketing plan analysis strategy with social media platforms.
This course is an introduction to the promotion element in the marketing mix, focusing on the integration of all elements, including advertising, personal selling, public relations, sales promotion, sponsorship, interactive marketing, and other marketing channels. You will master new web-based technologies, such as Twitter, LinkedIn, WordPress and other social media. As a writing intensive course, you will write - individually and as a team - a wide variety of marketing communication pieces using standard technology (i.e., desktop word processing) and web tools, such as Google Docs and online blogging.
Desarrollar los modelos lógicos conceptuales según los requerimientos del negocio. Diagrame y defina la multiplicidad para la relación (identificando los verbos idóneos)
En la actualidad todas las instituciones, ya sean públicas o privadas, pequeñas, medianas y grandes, requieren información relevante acerca del mercado y sus competidores para poder tomar decisiones más acertadas.
La investigación de mercado es una herramienta valiosa que nos aclara el panorama del tamaño, valor, características de nuestros clientes y competidores.
Desarrollar los modelos lógicos conceptuales según los requerimientos del negocio. Diagrame y defina la multiplicidad para la relación (identificando los verbos idóneos)
En la actualidad todas las instituciones, ya sean públicas o privadas, pequeñas, medianas y grandes, requieren información relevante acerca del mercado y sus competidores para poder tomar decisiones más acertadas.
La investigación de mercado es una herramienta valiosa que nos aclara el panorama del tamaño, valor, características de nuestros clientes y competidores.
Esta es una charla que di estando en Mercado Libre como una introducción a Git y a cómo poder configurar un repositorio desde 0, sus comandos básicos y poder también publicarlo en Github.
Administrar las versiones del código fuente de tus programas puede facilitarles la vida no sólo a ti, sino a tu equipo, y a toda la gente que se involucre con él a lo largo del tiempo. Los versionadores son herramientas muy útiles hoy en día para proyectos de software de todos los tipos, en particular los proyectos de software libre se ven muy beneficiados con estas herramientas. Git es una de ellas, y el sitio Github una forma muy popular de usarla.
Recomendable descargarla por las animaciones de las diapositivas, que se aprecian mejor a verlas estáticas.
Codigo fuente del ejemplo: https://github.com/jstitch/helloworld
Taller Git que impartimos Francisco Gortázar (@fgortazar) y Micael Gallego (@micael_gallego) en la Escuela Técnica Superior de Ingeniería Informática de la URJC.
Charla sobre las capacidades de extensión de Roslyn para c#.net. Queremos profundizar como añadir adaptaciones para la sintaxis y semántica en los lenguajes .net, nuevas expresiones, generación de código , y como utilizar las extensiones en el IDE de Visual Studio. En la sesión se mostrará cómo realizar adaptaciones sobre Roslyn para extender el comportamiento del análisis sintáctico y semántico del código, y generación de código y añadir estas extensiones sobre Visual Studio, disponiendo de esta forma de nuevas capacidades sobre .net. Será una sesión más práctica que teórica, mostrando código y realizando la explicación sobre este.
Como desarrolladores tenemos que crear el mejor código posible, que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad.
Una buena forma de conseguir esta buena calidad es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código, si las pruebas que realizan no aportan valor.
A lo largo de esta charla estudiaremos la mejor forma de probar código: Diferenciaremos entre los diferentes tipos de pruebas, sentaremos las bases de un buen unit test, nos ayudaremos de herramientas de diagnóstico y métricas de código, y refactorizaremos para conseguir código "testeable".
Como desarrolladores tenemos que crear el mejor código posible; que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad.
Una buena forma de conseguir esta buena calidad en nuestras apps de UWP es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código; si las pruebas que realizan no aportan valor.
A lo largo de esta charla estudiaremos la mejor forma de probar el código de las apps Windows 10: Diferenciaremos entre los diferentes tipos de pruebas; sentaremos las bases de un buen unit test; aprenderemos a probar métodos asíncronos; usaremos visual studio; crearemos test doubles; y refactorizaremos para conseguir código "testeable", usando los patrones que más favorecen los tests, como es MVVM.
Comúnmente conocemos redis como un sistema de caché distribuido que podemos usar en modo PaaS gracias a la plataforma de azure. Pero redis se define como un sistema de base de datos NoSql de tipo clave valor, que funciona perfectamente como memoria caché, pero que además tiene muchas características adcionales. A lo largo de esta charla comentaremos las posibilidades de este servicio y cómo podemos explotarlas.
Los olores del código (Code Smells en inglés) son la forma que utilizamos para referirnos a signos en el código fuente que podrían indicar un problema más profundo.
Un code smell no tiene por qué implicar que una aplicación no funcione correctamente. Indica un problema de diseño que puede enlentecer el desarrollo, generar más errores en el futuro y hacer aparecer una mayor cantidad de bugs en nuestra aplicación. Dentro de las buenas prácticas de programación, con el objetivo de escribir cada vez mejor código, necesitamos ir aprendiendo todos estos signos.
La caché es una memoria más pequeña y rápida que la de nuestro almacén de información, por lo que su uso se ha extendido desde el hardware hasta el software. Con la evolución de las tecnologías hacia internet y la utilización de diferentes servidores en entornos cloud, se ha creado la necesidad de desarrollar sistemas de caché distribuidos. Microsoft Azure nos provee de diferentes servicios de caché distribuida, pero debemos aprender a utilizarlos de la forma más eficiente. A lo largo de esta charla revisaremos los sistemas de caché disponibles y cómo podemos explotarlos en nuestras aplicaciones.
Descubriendo las caches por Quique Martínez y Fernando Escolar.
Hoy en día en la nube puedes hospedarlo todo, incluso la memoria caché que usan tus aplicaciones. Pero no todas las cachés que encontramos son iguales, ni se usan para los mismos fines, ni siquiera tienen el mismo comportamiento.
A lo largo de esta charla realizaremos un viaje a través de los tipos de datos, cuales es mejor almacenarlos en caché y qué caché es más recomendabe para cada uno. Y terminaremos con los resultados de un estudio acerca de la performance de diferentes sistemas de cachés hospedados en la nube.
Como desarrolladores tenemos que crear el mejor código posible, que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad. Una buena forma de conseguir esta buena calidad es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código, si las pruebas que realizan no aportan valor.
A lo largo de esta charla estudiaremos la mejor forma de probar código: Diferenciaremos entre los diferentes tipos de pruebas, sentaremos las bases de un buen unit test, nos ayudaremos de herramientas de diagnóstico y métricas de código, y refactorizaremos para conseguir código "testeable".
Estamos demasiado acostumbrados a que como javascript tiene el nombre script, podemos programar como y donde nos parezca. Pero eso ha cambiado. Hoy en día js es una compleja plataforma de programación de clientes ricos, válida para móviles, tablets y todos los ordenadores de escritorio. Así que ha llegado la hora de empezar a programar javascript con calidad.
Vamos a explorar el mundo de las Social Networks en busca de las tecnologías y las arquitecturas ideales.
Desarrollaremos la red Social más cool del momento, beer to beer.
Donde nos veremos envueltos en el complejo mundo de REST, WEP API, ASP.NET y las últimas tecnologías que nos podemos encontrar en la nube de Microsoft, Windows Azure.
basándonos en las prácticas de los coding dojo, intentaremos mostrar cómo aplicar en vivo, conceptos de la programación orientados a la calidad.
-----
El código zombi es aquel que está infectado del virus de la mala calidad. Este virus provoca que el código se degrade poco a poco hasta corromper el sistema, se ejecute lentamente y consuma todos los recursos disponibles. Todo programador que entre en contacto con código zombi y no esté preparado puede infectarse y empezar a hacer código de mala calidad.
Programar es difícil, y hacer buen código todavía más. Por suerte para nosotros, gente como Robert C. Martin, Bertrand Meyer,
Barbara Liskov o los miembros de GoF nos han dado las herramientas como los patrones de diseño y los principios SOLID que hacen nuestra tarea más sencilla.
Con su ayuda podremos pasar de hacer código que simplemente funciona, a aplicaciones robustas y mantenibles que serán fáciles de modificar y en las que será más difícil que haya bugs gracias a los tests unitarios. Subiremos un nivel (o dos) la calidad de nuestro código y veremos cómo dejamos atrás la frustración que provoca hacer código que no se entiende.
Catalogo general Ariston Amado Salvador distribuidor oficial ValenciaAMADO SALVADOR
Distribuidor Oficial Ariston en Valencia: Amado Salvador distribuidor autorizado de Ariston, una marca líder en soluciones de calefacción y agua caliente sanitaria. Amado Salvador pone a tu disposición el catálogo completo de Ariston, encontrarás una amplia gama de productos diseñados para satisfacer las necesidades de hogares y empresas.
Calderas de condensación: Ofrecemos calderas de alta eficiencia energética que aprovechan al máximo el calor residual. Estas calderas Ariston son ideales para reducir el consumo de gas y minimizar las emisiones de CO2.
Bombas de calor: Las bombas de calor Ariston son una opción sostenible para la producción de agua caliente. Utilizan energía renovable del aire o el suelo para calentar el agua, lo que las convierte en una alternativa ecológica.
Termos eléctricos: Los termos eléctricos, como el modelo VELIS TECH DRY (sustito de los modelos Duo de Fleck), ofrecen diseño moderno y conectividad WIFI. Son ideales para hogares donde se necesita agua caliente de forma rápida y eficiente.
Aerotermia: Si buscas una solución aún más sostenible, considera la aerotermia. Esta tecnología extrae energía del aire exterior para calentar tu hogar y agua. Además, puede ser elegible para subvenciones locales.
Amado Salvador es el distribuidor oficial de Ariston en Valencia. Explora el catálogo y descubre cómo mejorar la comodidad y la eficiencia en tu hogar o negocio.
Inteligencia Artificial y Ciberseguridad.pdfEmilio Casbas
Recopilación de los puntos más interesantes de diversas presentaciones, desde los visionarios conceptos de Alan Turing, pasando por la paradoja de Hans Moravec y la descripcion de Singularidad de Max Tegmark, hasta los innovadores avances de ChatGPT, y de cómo la IA está transformando la seguridad digital y protegiendo nuestras vidas.
33. remote
# con esto añadimos otro repositorio servidor con alias "tokiota" a
nuestro repositorio local
$ git remote add tokiota https://tokiota.com/gits/repo.git
# así listamos todos los servidores que tenemos asociados
$ git remote -v
43. commit local
# creamos un conjunto de cambios con el comentario entrecomillado
$ git commit -m "#Tarea - Red"
# otro commit para cuando pasan los tests
$ git commit -m "#Tarea - Green"
# creamos el último conjunto de cambios
$ git commit -m "#Tarea - Refactor"
# enviamos todos los commits locales al servidor
$ git push my-remote
46. logs
# así sacamos los commits de la branch actual
$ git log
commit a8a7bfff366350be2e7c21b8de9cc6504678a61b`
Author: Me <me@me.com> Date: ...
commit e5e3e4c1ef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me <me@me.com> Date: ...
...
54. # Desatachamos el HEAD, que es lo mismo que no tener ninguna rama
desprotegida:
$ git checkout dd1d7ab32
# si quieres hacer cambios mientras estás en este estado extraño:
$ git checkout -b old-state dd1d7ab32
temporalmente
55. # Primero no tendrás que tener nada modificado. Todo en commits.
# Después borramos el cambio:
$ git reset --hard dd1d7ab32
# Si quieres guardar el código modificado, porque no quieres hacer un
commit:
$ git stash git reset --hard dd1d7ab32 git stash pop
si no hemos publicado
56. # Esto crea 3 commits separados que desacen los commits indicados:
$ git revert a867a4ad 25eff4ca a766c053
# También lo podemos hacer por rango. Borrando los dos últimos
commits:
$ git revert HEAD~2..HEAD
# O podemos tirar para atrás un commit de tipo MERGE:
$ git revert -m 1 <merge_commit_sha>
si ya está publicado
57. Comando base Resultado inutil Comando útil Resultado esperado
git branch foo Creates a branch but does nothing with it git checkout -b foo Creates branch and switches to it
git remote Shows names of remotes git remote -v Shows names and URLs of remotes
git stash Stores modifications to tracked files, then
rolls them back
git stash -u Also does the same to untracked files
git branch Lists names of local branches git branch -rv Lists local and remote tracking branches;
shows latest commit message
git rebase Destroy history blindfolded git rebase -i Lets you rewrite the upstream history of a
branch, choosing which commits to keep,
squash, or ditch.
git reset foo Unstages files git reset –hard
git reset –soft
Discards local modifications
Returns to another commit, but doesn’t
touch working directory.
git add Nothing – prints warning git add .
git add -A
Stages all local modifications/additions
Stages all local
modifications/additions/deletions
Hall of shame
58. No voy a usar herramientas de 3os
Atlasian SourceTree gitkraken
Visual Studio
Según comenta el propio señor Torvalds, lo diseñó pensando en sus necesidades. Esas que no le aportaban otros SCM. Su idea era que fuera distribuido, fácil, rápido y poco pesado... Y la lunaaaa!!!
Cuentan las leyendas que lo hizo en un fin de semana y ahora ya no trabaja en ello.
Quizá esto le debería hacer perder credibilidad a la herramienta. Pero por lo visto causa el efecto contrario.
Pero no lo sabíamos entonces…
Antiguamente usábamos un sistema centralizado en el un servidor. Cuando no funcionaba internet, no podías trabajar. Visual Studio te daba problemas. Lo único que podías hacer era trabajar offline. Y las vueltas a online solían ser bastante dolorosas. La única solución razonable era irte a casa o tomar unas cervezas.
Pero Git es distribuido. Esto se traduce a que cuando te “clonas” un repositorio en tu ordenador, automáticamente estás creando un repositorio como el del servidor. Pero de forma local. Así trabajas en tu máquina hasta que decides sincronizar con el servidor todas las modificaciones que has realizado. Las consecuencias de esto son nefastas: ya no te puedes ir a casa. Aunque no tengas conexión, puedes seguir trabajando. Ya sincronizarás más tarde.
En este punto, supongo que más de uno se estará preguntando: ¿Qué es eso de que los cambios los guardas en local? ¿Cómo que subes cuando quieres? ¿Un desarrollador puede tener un cambio y no subirlo hasta final de mes? ¿No tiene por qué guardar directamente los cambios en el servidor?. Es evidente que quien desarrolló Git no tiene claro el concepto de Continuous Integration…
Dentro de estas funcionalidades absurdas, encontramos que un repo Git puede tener varios “remote”. Un “remote” es un servidor con el que sincronizar el repositorio local. Y un mismo repositorio que tienes en local puede estar vinculado con varios servidores diferentes.
Ahora me imagino a un proveedor diciendo que guardan en sus servidores el código que están escribiendo para nosotros. Y que nos digan que ya sincronizarán con nuestros servidores de vez en cuando… De eso nada. Les estamos pagando. Por lo que ese código es nuestro. No queremos que lo tengan en sus servidores.
Mi rutina diaria siempre ha sido muy normal. Me gusta llegar a trabajar por la mañana, encender el ordenador y le darle a descargar la última versión del código. Mientras, me acerco a la cafetera y me tomo un ristretto. Para cuando vuelvo a mi puesto, terminan de descargarse los últimos datos.
Git me ha robado el momento zen del café matutino. Internamente maneja un tamaño de paquetes diferenciales (snapshots) que imagino que serán bastante pequeños. Espero que no pierda cambios por ello. El resultado es que las descargas no dan tiempo a ese café. Y me dejan sin excusa para tomarlo.
Otro café que ya no me puedo tomar es el de cuando te descargas una branch. Mientras se descargaba podías tener una conversación interesante con los compañeros. Eso también lo hemos perdido. Git maneja un sistema de branches totalmente diferente. Para este sistema una rama es solo un punto en el camino. Marca una posición en la que se aplican solo una serie de cambios. No todos. Así que cuando sincronizas el código ya te descargas todas las ramas.
Parece que a los programadores de Git no les gusta el café. No me fío de las personas a las que no les gusta el café.
Hace tiempo que dentro del Definition Of Done figura tener pruebas unitarias para todo el código que subamos. Unas cómodas pruebas. Una vez has terminado la funcionalidad, copias el código y cambias un par de detalles. Así consigues una prueba válida rápidamente. Sin esfuerzo. Y eso sin contar con el apoyo de grandes herramientas como Pex.
Pues resulta que ahora como tenemos Git, no hace falta que un “commit” vaya directo al servidor. Ese cambio puede residir en nuestro repositorio local. Ahora resulta que tenemos sincronizar el código con al menos tres cambios bien diferenciados: “red”, “green” y “refactor”.
Todos los desarrolladores tenemos que pensar primero en una prueba, escribirla y que no pase. Luego hacer el código necesario para que pase ese test. Para finalizar poner todo el código anterior bonito y que las pruebas sigan pasando. Lo que se conoce vulgarmente como Test Driven Development. Que te obliga a pensar más. Y en cualquier momento alguien puede revisar si lo has estado aplicando correctamente. Una verdadera caza de brujas.
Los commit se pueden aplicar sueltos. Hay bifurcaciones. Puedes montar un puzzle de cambios sin problemas. Una branch puede tener unos commits totalmente diferentes a los de otra. Además la forma de identificarlos son GUID’s. Que no sé si alguno os dice algo un GUID, pero a mi no me aporta ningún valor.
Un ejemplo gráfico, gracias a una herramienta que nos muestra un mapa de cambios.
Otro ejemplo es uno de twitter: El GIT-ar Hero. Si alguien entiende algo de esto, que venga y me lo explique por favor.
La parte buena de tener semejante conjunto de cambios son los merges grandes. Creo que todos hemos vivido ese momento en el que se junta la rama de hotfix con la principal. La persona encargada suele perder algún código importante en la operación. Es la forma ideal de ocultar otros problemas y ganar tiempo en los desarrollos. Además, nadie te va a echar nada en cara porque la culpa ha sido de quien hizo el merge.
En Git esta operación de merge se realiza en el momento que descargas el código del servidor. Lo hace cada uno en local.
De esta forma, los administradores de VSTS tiran balones fuera. Que los merge los haga cada desarrollador. Que nos comamos nosotros el marrón. Y lo que es peor, al haber muchos commits, es muy fácil encontrar quien ha metido la pata en el código. Sigue la caza de brujas…
No sé si os habéis percatado de que voy poniendo code-snippets a lo largo de todo este escrito. Está hecho a posta. Si hay una forma de manejar bien Git y sacarle todo el jugo es usar comandos de consola. Como si estuvieramos en el medievo.
Alguno me dirá que Visual Studio tiene soporte para Git. Pero realmente no tiene todos los comandos implementados. Sí la mayoría. Pero no todos. Para hacer ciertas operaciones al final tienes que abrir la consola. También hay gente que usa Source Tree. Una aplicación de Atlassian. Me niego en rotundo a instalarme más aplicaciones… Aunque la recomiende Martin Fowler.
Dentro del mundo de todos los comandos que tiene Git, encontramos que podemos resolver un mismo problema de muchas formas diferentes. Un ejemplo sería echar para atrás un commit. Tendríamos las siguientes alternativas: