A recent twitter discussion reminded me of an interesting XTC discussion last year. The discussion topic was refactoring code to make it worse. We discussed why this happens, and what we can do about it.

I found the most interesting discussion arose from the question “when might this be a good thing?”—when is it beneficial to make code worse?

Refactorings are small, safe, behaviour-preserving transformations to code. Refactoring is a technique to improve the design of existing code without changing the behaviour. The refactoring transformations are merely a tool. The result may be either better or worse. 

Make it worse for you; make it better for someone else

Refactoring ruthlessly can keep code habitable, inline with our best understanding of the domain, even aesthetically pleasing. 

They can also make the code worse. Whether the result is better or worse is in the eye of the beholder. What’s better to one person may be worse to another. What’s better for one team may be worse for another team. 

For example, some teams may be more comfortable with abstraction than others. Some teams prefer code that more explicitly states how it is working at a glance. Some people may be comfortable with OO design patterns and find functional programming idioms unfamiliar, and vice versa.

You may refactor the code to a state you’re less happy with but the team as a whole prefers. 

Refactoring the code through different forms also allows for conversations to align on a preferred style in a team. After a while you can often start to predict what others on the team are going to think of a given refactoring even without asking them. 

Making refactoring a habit, e.g. as part of the TDD cycle accelerates this, as do mechanisms for fast feedback between each person in the team—such as pairing with rotation or collective group code review.

Learning through Exploration

Changing the structure of code without changing its behaviour can help to understand what the code’s doing, why it’s written in that way, how it fits into the rest of the system. 

In his book “Working effectively with legacy code” Michael feathers calls this “Scratch Refactoring”. Refactor the code without worrying about whether your changes are safe, or even better.

Then throw those refactorings away. 

Exploratory refactoring can be done even when there’s no tests, even when you don’t have enough understanding of the system to know if your change is better or worse, even when you don’t know the acceptance criteria for the system.

Moulding the code into different forms that have the same behaviour can increase your understanding of what that core behaviour is.

A sign it’s safe to take risks

Picard management tip: If you never fail, you aren't going boldly enough.

— Picard Tips (@PicardTips) March 3, 2018

If every refactoring you perform makes the code better, it seems likely that we could be more courageous in our refactoring attempts. 

If we only tackle the changes where we know what better looks like and leave scary code alone the system won’t stay simple.

If we’re attempting to improve code we don’t fully understand and don’t intuitively know the right design for we’ll get it wrong some of the time. 

It’s easy to try so hard to avoid the risk of bad things happening that we also get in the way of good things happening.

Many teams use gating code review before code may make its way to production. Establishing a gate to stop bad code making it into production, that also slows down good code getting to production.

Refactorings are often small steps towards a deeper insight into the domain of the code we’re working on. Sometimes those steps will be in a useful direction, sometimes wrong. All of them will build up understanding in the team. Not all of them will be unquestionably better at each integration point, and could easily be filtered out by a risk-averse code review gate. Avoiding the risk that a refactoring might be taking us in the wrong path may rob us of the chance of a breakthrough in the next refactoring, or the one after. 

A team that’s not afraid to make improvements to the system will also get it wrong some of the time. That has to be ok. We learn as much or more from the failures.

Making it safe to make code worse

Extreme programming practices really help create an environment where it’s safe experiment with code in this manner.

Pair programming means you’ve got a second person to catch some of the riskiest things that could happen and give immediate feedback in the moment. It gives two perspectives on the shape the code should be in. Tom Johnson calls this optician-style “Do you prefer this… or this”. Refactorings are small changes so it’s feasible to switch back and forth between each structure to compare and consider together.

Group code review. (Reviewing code together as a team, after it’s already in production) can build a shared understanding of what the team considers good code. Help you foresee the preferences of the rest of your team. Between you build a better understanding of the code than you could even in a pair. Spot the refactoring paths we’ve embarked on that have made code worse rather than better. Highlight changes to make the next time we’re in the area.

Continuous integration means we’re only making small steps before getting feedback from integrating the code. The size of our mistakes is limited.

Test Driven Development gives us a safety net that tells us when our refactoring may have not just changed the structure of the code but also inadvertently the behaviour. i.e. it wasn’t a refactoring. Test suites going red during a refactoring is a “surprise” we can learn from. We predict the suite will stay green. If it goes red then there’s something we didn’t fully understand about the code. Surprises are where learning happens.

Test Driven Development also makes refactoring habitual. Every micro-iteration of behaviour we perform to the system includes refactoring. Tidying the implementation, trying out another approach, simplifying the test, improving its diagnostic power (maybe not strictly a refactoring). If you never move onto writing the next test without doing at least some refactoring you’ll build up the habit and skill at refactoring fast. If you do lots of refactorings some of them will make things worse, and that’s ok. 

The post The benefits of making code worse appeared first on Benji's Blog.

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• http://dominique.leuenberger.net/blog/2020/09/opensuse-tumbleweed-review-of-the-week-2020-37/

Esta semana ha sido tranquila y no han ocurrido incidencias que retrasen o dificulten la publicación de nuevas “snapshots”. Pero eso no significa que no haya habido un buen número de actualizaciones y algunas de ellas muy importantes

En total se han publicado 6 nuevas snapshots: (0904, 0905, 0906, 0907, 0908 y 0909)

Que entre otros, se pueden destacar estos cambios como los más notables:

• KDE Plasma 5.19.5
• KDE Applications 20.08.1
• LibreOffice 7.0.1.2 (aka 7.0.1rc2)
• Mesa 20.1.7
• Libvirt 6.7.0

Y entre lo que podremos encontrar en próximas actualizaciones, podemos destacar:

• systemd 246
• glibc 2.32
• binutils 2.35
• gettext 0.21
• bison 3.7.1
• SELinux 3.1

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

Based on my gut feeling, I’d claim week 37 was a bit quieter than other weeks. But that might be due to the fact that I had some day off in the middle of the week, where I only did a check-in round, but not actually pushing on the Stagings. Some of you might have seen that Richard Brown has been helping out on this front, which can just be another reason for things to look more relaxed for me. But let’s look at the 6 snapshots (0904, 0905, 0906, 0907, 0908, and 0909) we released during this week.

The changes included were:

• KDE Plasma 5.19.5
• KDE Applications 20.08.1
• LibreOffice 7.0.1.2 (aka 7.0.1rc2)
• Mesa 20.1.7
• Libvirt 6.7.0

That leaves the list of things being worked out in stagings almost the same:

• systemd 246
• glibc 2.32
• binutils 2.35
• gettext 0.21
• bison 3.7.1
• SELinux 3.1

Ninja Cookie est une extension de navigateur gratuite qui refuse l’utilisation des cookies et fait disparaître les bandeaux cookies automatiquement.   Depuis l’entrée en vigueur du RGPD (Règlement Général sur la Protection des Données) en mai 2017, les sites internet sont dans l’obligation d’informer et de recueillir l’accord de l’internaute pour utiliser des cookies sur les […]

En un par de días finaliza el evento más importante de la Comunidad KDE Internacional pero en el blog seguimos repasando cómo fueron las ponencias. Bienvenidos a la mañana del tercer día de Akademy 2020 en línea, donde se habló desde Plasma BigScreen a robots animales animados con tecnología KDE pasando por un repaso a GCompris.

Mañana del tercer día de Akademy 2020 en línea

Sigo empezando los artículos dedicados a Akademy 2020 con este vídeo de bienvenida… me ha encantado la diversidad cultural que nos muestra.

Al igual que la tarde del sábado, tenemos dos salas simultáneas donde los miembros de la Comunidad siguen compartiendo conocimientos. De esta forma hablaremos de la Room 1 y la Room 2.

De esta forma nos encontramos en la Room 1 ponencias como:

• C++17 and 20 Goodies de Ivan Čukić donde habló de las nuevas características que C++17 y 20 traen y cómo podrían combinarse entre sí.
• Rust from a KDE Perspective de Méven Car en la que explicó lo que Rust podía ofrecer a la comunidad de desarrolladores de KDE y las características que lo convertían en un lenguaje de programación único.
• Test It! en la que Andreas Cord-Landwehr propuso a los desarrolladores dar vuelta las cosas y preparar pruebas para el código antes de escribirlo.
• KIO: A Story of Young and Old Jobs por David Faure donde nos habló del trabajo del mecanismo KIO y como se utiliza. Además, expuso los trabajos añadidos en los últimos dos meses y explicó el concepto de «delegados» que se utilizan para resolver el problema de la dependencia inversa.
• Static Code Analysis with Gitlab CI de Daniel Vrátil donde mostró los beneficios de usar herramientas de análisis estático y linters para comprobar automáticamente la calidad del código generado en GitLab, y explicó cómo configurar Gitlab CI para que ejecute esas herramientas automáticamente en cada solicitud de extracción o como parte de construcciones regulares.

Mientras que para la Room 2 nos encontramos con:

• Showcasing Plasma Bigscreen por Marco Martin y Aditya Mehra, locs cuales mostraron Plasma Bigscreen, la interfaz de KDE para los grandes televisores inteligentes. Marco y Aditya llevaron a los asistentes a través de las diversas características y la tecnología que impulsa a Bigscreen, como Plasma, Kirigami, y los marcos de KDE con un toque de la plataforma de asistencia de voz de código abierto de Mycroft
• Free Software, Press Freedom & KDE por Ambady Anand S. donde nos contó el caso de éxito de migración de un diario local de Kerala con 100.000 lectores al Software libre.
• Celebrating 20 Years of GCompris por Timothée Glee, el cual nos mostró algunas de las nuevas actividades que están llegando a GCompris, como nuevos juegos de conteo y aritmética, y un simulador de circuitos eléctricos de aspecto divertido.
• A Year in KDE from Outside por Marta Rybczynska que nos contó sobre su visión de KDE tras un año «fuera» de la Comunidad analizando los reportajes de los medios de comunicación sobre KDE y rastreó en qué sitios de noticias, blogs y podcasts eligieron enfocarse cuando hablaban de KDE.
• KDE Wags Your Tail por Leinir y Andrew Shoben que explicaron cómo controlar las colas y orejas de los animales animatrónicos usando un software basado en software libre y el framework Kirigami de KDE.

Las charlas relámpago

No quiero olvidar las charlas relámpago que se realizaron en la Room 1:

• Bhushan Shah habló de su experiencia con los sprints en línea y dio consejos al respecto
• Adriaan de Groot explicó el Acuerdo de Licencia Fiduciaria, una herramienta que la comunidad de KDE utiliza para gestionar las licencias a largo plazo
• Kai Uwe Broulik reveló algunos de los consejos y trucos menos obvios para sacar el máximo provecho del escritorio Plasma de KDE.

Material audiovisual Akademy 2020 en línea

Una de las cosas positivas de esta Akademy es que todo el material debe ser emitido digitalmente, lo cual hace que ya puede estar listo para ser compartido en diferido, aunque sea sin editar.

De esta forma, en caso de que te lo hayas perdido, las charlas de hoy ya están disponibles en línea en tres bloques – uno para la mañana y dos para cada una de las habitaciones utilizadas por la tarde. También se ha grabado grabado todas las charlas por separado y pronto podrás verlas en las plataformas de vídeo disponibles de KDE.

Six openSUSE Tumbleweed snapshots have arrived in the rolling release since the last Tumblweed update.

KDE’s Plasma 5.19.5, php and Ceph were among more of the known updates.

The display-oriented email client Alpine updated to version 2.23 in the 20200908 snapshot and provided support for the Simple Authentication and Security Layer-IR IMAP extension. The open-source disk encryption package cryptsetup 2.3.4 added support options for the 5.9 kernel and fixed a Common Vulnerabilities and Exposure affecting the memory write. A couple of RubyGem packages were updated in the snapshot and the 2.43 libcap package added some more release time checks for non-git tracked files. The snapshot is trending stable at a rating of 99, according to the Tumbleweed snapshot reviewer.

Also trending at a 99 rating, snapshot 20200907 brought two package updates with fetchmail 6.4.12 and perl-Cpanel-JSON-XS 4.23. Fetchmail provided some regression fixes that were introduced in the versions between the 6.4.12 update and the previous 6.4.8 version in Tumbleweed.

Just four packages were updated in the 20200906 snapshot. The Heaptrack fast heap memory profiler updated to version 1.2.0; the package that allows you to track all heap memory allocations at run-time removed a fix-compile patch for 32bit. New features were added in the libvirt 6.7.0 version; added support for device model command-line passthrough for xen was one of the changes and there was also a change to the spec file that enables the same hypervisor drivers for openSUSE and SUSE Linux Enterprise. The update of php 7.4.10 fixed a memory leak and python-libvirt-python 6.7.0 add all new APIs and constants in libvirt 6.7.0.

Mesa 20.1.7 was updated in snapshot 20200905. GNU Privacy Guard 2.2.23 added regular expression support for Trust Signatures on all platforms and fixed a PIN verify failure on certain OpenPGP card implementations. The screen reader package orca 3.36.6 added some checks to prevent crashing due to a GStreamer failure. There was an improvement to the pulse layer and to GStreamer elements in the pipewire 0.3.10 update.

Plasma 5.19.5 arrived in snapshot 20200904. The desktop fixes several bugs and the Powerdevil package has restored the keyboard brightness. The Discover package of the K Desktop Environment project properly wraps text on the popup header. The Kwin window manager had a fix to properly clip a sliding popup window. LibreOffice received a small update to match up a configuration and the mail server postfix 3.5.7 fixed some random certificate verification failures. There were a handful of Python packages updated in the snapshot including python-Sphinx and python-Sphinx-test 3.2.1, python-dulwich 0.20.5, python-numpy 1.19.1 and python-sphinxcontrib-websupport 1.2.4.

The new major version of Mozilla Firefox 80.0 arrived just more than a week ago in snapshot 20200902. The major version update of Ceph 16 was also in the snapshot, which has shown the lowest score of the week thus far at a 97 rating.

When I say “Return” what I mean is, return to a fully functional state. I fancy myself a vintage computer enthusiast, although I haven’t done a whole lot with my Amigas as of late, a part of that has been my apprehension in being able to access the data on my old drives. I also … Continue reading Amiga Fast File System Return to the Linux Kernel →

Announcement

The Kubic Project is proud to announce that Snapshot 20200907 has been released containing Kubernetes 1.19.0.

Release Notes are avaialble HERE.

Upgrade Steps

All newly deployed Kubic clusters will automatically be Kubernetes 1.19.0 from this point.

For existing clusters, please follow our new documentation our wiki HERE

Thanks and have a lot of fun!

The Kubic Team

¿Otro libro o texto más para aprender a utilizar el editor de texto Vim? Pues sí, nunca es suficiente…

¿Estás buscando un libro o texto para aprender a utilizar el editor Vim y empezar a sacarle todo el partido que puede ofrecer esta potente herramienta de edición de textos? Quizás este libro que te traigo sea un buen punto de partida.

En este blog llevo ya un tiempo ofreciendo tutoriales y guías sobre el uso del editor Vim. Este es un recurso más que puedes utilizar en ese empeño en aprender a utilizar Vim.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Sobre el editor Vim  se ha escrito un montón de artículos, tutoriales, libros. Se han hecho vídeos, etc. Pero nunca está de más el poder dar otra visión, otro concepto y el poder llegar a más usuarios informando de la potencia que ofrece Vim a la hora de gestionar textos.

Hace unos días gracias a Ekaitz, conocí un trabajo de un usuario que estaba escribiendo un libro o tutorial en inglés y utilizando un repositorio de GitHub para llevar a cabo la tarea. El usuario es Igor Irianto y el libro es Learn Vim (the smart way)

En ese proyecto, a lo largo de los distitos capítulos, nos va explicando distintos conceptos y funcionalidades del editor Vim. Muchas de ellas ya las he tratado en mi blog, que puedes encontrar reunidas en este enlace:

• https://victorhckinthefreeworld.com/tag/vim/

Pero siempre es interesante ofrecer otros ejemplo, u otro método didáctico. El proyecto me resultó interesante, así que he decidido ponerme manos a la obra e ir traduciendo al español el libro y después ofrecerlo no solo en el repositorio de GitHub, si no también mediante Gitbook u otra alternativa…

Así que en GitHub está disponible mi repositorio para ir realizando la traducció de los diferentes capítulos publicados en el original. Te invito a clonar, abrir tu editor Vim y participar, traduciendo, corrigiendo o mejorando las traducciones mediante Pull Request.

Espero que el trabajo final resulte interesante y sirva para dar a conocer más esta gran herramienta, ¡incluso a lo mejor entre los usuarios de Emacs!

Enlaces de interés

• https://github.com/iggredible/Learn-Vim
• https://github.com/victorhck/learn-Vim-es
• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim

En esta ocasión se cumple el dicho de «no hay dos sin tres» y ésta será el tercer podcast consecutivo que comparto de los programas del podcast de Juan Febles. En esta ocasión os presento a José Jiménez en Podcast Linux #111 donde nos habla de su experiencia como comunicador en el mundo del Software Libre.

José Jiménez en Podcast Linux #111

En esta ocasión tengo el placer de presentaros a otro promotor de las bondades de los sistemas libres.

Se trata de José Jiménez, un experimentado usuario que lleva en el mundo de la informática desde los tiempos del Spectrum y que es linuxero desde mediados de los 90 con Slackware 3.4, posteriormente se pasó a Red Hat 4 y en la actualidad se encuentra con Fedora, eso si con KDE durante toda su vida ya que dice que ya utilizaba la versión 1.0.

De su charla destacaría el concepto de la «falsa gratuidad de GNU/Linux» ya que según él, y de forma muy acertada, todo el software se paga, bien sea con dinero (M$ o Apple) o con tiempo de aprendizaje, como son los libres. Esta idea me la quedo (gracias José).

Además en la entrevista con Juan descubrimos que es un experto en placas ARM como Raspeberry Pi pero que le encanta buscar alternativas (muchas de las cuales pueden ser incluso mejores que la Raspy) y que domina como pocos Telegram.

Y lo mejor de todo, no es erudito sino que un sabio ya que todo su conocimiento lo comparte con todo el mundo. Os recomiendo su blog: rooteando.com.

No obstante, para entender mejor quien es José y qué le hace merecedor de un capítulo de Linux Conexion lo mejor es leer las palabras del presentador y creador del podcast Juan Febles:

Como siempre, os dejo el audio para que los podáis escuchar y disfrutar de este programa de una hora de duración.

Y los enlaces de interés de José Jiménez:

• Blog: http://rooteando.com/
• Telegram: https://t.me/JoseAJimenez
• Twitter: https://twitter.com/RooteandoBlog

Canales de Telegram:

• Un día una aplicación: https://t.me/UnDiaUnaAplicacion
• Un Python al día: https://t.me/UnPythonAlDia
• Entrevista en Diferido: https://t.me/entrevistaendiferido
• Formadores en tiempos revueltos: https://t.me/Foentire
• Podcast Tomando un café: https://t.me/TomandoUnCafe
• Podcast ARM para todos: https://t.me/ARMparaTodos
• Podcast Aviones de papel: https://t.me/avionesdepapel
• Boletín de noticias: https://tinyletter.com/jajt

Más información: Podcast Linux

Y aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene, los cuales han cambiado debido a que Podcast Linux ha abandona e

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: podcastlinux@disroot.org
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed