Dos mesitas de noche:

• Parte 1: Preparar las piezas
• Parte 2: Marcar las patas
• Parte 3: Los cajones

Hace unos años hice una mesita de noche para mi esposa. Siempre tuve la intención de hacer una para mí y otra para mi hija... y bueno, ocho años después empiezo a hacerlas.

La mesita original no tiene cajones, pero estas dos nuevas sí van a tener, uno cada una.

A lo largo de los días pasados he estado preparando la madera para todas las piezas principales; los cajones irán al final, pues las medidas del cajón salen del espacio que quede ya que el resto esté armado.

Tengo unos tablones de cedro aromático que quiero usar para las patas y para las piezas del cajón, para que al abrirlo siempre huela bonito. Los travesaños van a ser del mismo cedro; las superficies de unas tablas muy lindas de caoba que tengo por ahí.

Los tablones ya estaban cuadrados. Mi intención original era usarlos para una ventana, pero cambiaron los planes. En fin, así me ahorro el trabajo inicial de cuadrarlos.

Las patas

Primero puse el gramil a 1.25" para las patas. Las mesitas son cuadradas, y también quiero patas cuadradas. Se marca a lo largo del tablón.

Serruché lo más cerca posible de la línea, a 1 ó 1.5mm, para luego tener poco qué cepillar. Se alínea el serrucho con respecto a las dos líneas en una esquina; como dos líneas que se cruzan en el espacio determinan un plano, ese es el plano que seguirá el serrucho. Volteo el tablón regularmente, digamos después de serrucharle cada 10cm, y lo serrucho desde el otro lado para que se mantenga parejo.

Por cierto, este serrucho para corte longitudinal es una delicia. Lo afilé hace poco y le suavicé las curvas del mango, entonces es muy cómodo de agarrar. Tengo que hacerle lo mismo al mango de mi serrucho grande de corte transversal. Aquí están ambos, el de corte longitudinal arriba y ya suavizado, el de corte transversal abajo. Nótense las esquinas que llegan a lastimar.

La tira de madera que corté, la guardo, y prosigo a enderezar el canto del tablón con la garlopa. Como el corte estaba bien alineado, sólo con unas pasadas del cepillo queda derecho. De todas formas lo checo con escuadra.

Esto se repite para cada una de las 8 patas. A la mitad del proceso tengo que afilar la cuchilla de la garlopa... entre que pierde su filo y que uno se cansa, la afilada es una buena pausa. Se afila y se pule sobre cuero...

... hasta que el bisel queda lindo y brilloso.

Ahora bien, el grosor del tablón no es igual al ancho que quiero para las patas. En cada pieza, cepillo la cara recién cortada y luego marco todo alrededor con el gramil para el grosor final.

Así quedan las 8 patas, a las que nada más les falta cepillar la última cara.

De las tiras sobrantes, puedo usar las más gruesas para sacar los travesaños.

Ahora falta cepillar la última cara de las patas. La forma más rápida que encontré es primero un corte grueso con el cepillo, y luego un corte fino con la garlopa. Como las patas ya están marcadas todo alrededor con el gramil, sólo hay que cepillar hasta la línea; ni siquiera hay que revisar con la escuadra.

Por fin, 8 patas listas para trabajarse. Imagínenme bañado en sudor y con brazos como de Dragon Ball.

Travesaños

Las mesitas tienen dos tipos de travesaños: unos estrechos para la parte inferior, y unos anchos para alrededor del cajón.

Los estrechos no tienen problema; ya están cortados, pues salieron de las tiras sobrantes de las patas. Nada más se alisan con el cepillo de acabados.

Los travesaños anchos funcionan como faldones de la mesita. Las tablas que tengo son más gruesas de lo que quiero, entonces marco el grosor con el gramil y primero les cepillo un bisel hasta la línea. Así no se astilla la madera al cepillarlas de forma transversal — lo que es la forma más rápida de adelgazar las tablas.

Frentes de cajones

Abajo de cada frente de cajón, queda otro travesaño. Quiero que la veta de la madera se conserve entre cajón y travesaño, entonces corto ambas partes de la misma pieza. Les dibujo triángulos con lápiz para mantenerlas siempre bien orientadas.

Por cierto, esas piezas son más gruesas que los travesaños delgados. Para poder usar ambas manos en el mango del serrucho, se me hizo cómodo sostener la madera al banco de serruchado con unos sargentos.

Todas las piezas

Y bien, he aquí el resultado de tres días de serruchar y cepillar y serruchar y cepillar y serruchar y cepillar.

Mañana comienzo con los ensambles.

Me sirvió mucho lo que leí por ahí, de terminar todas las operaciones iguales antes de pasar a una diferente. Hacer todas las marcas iguales, luego serruchar todos los cortes iguales, luego cepillar todas las caras iguales, etc. Sí que se avanza más rápido que al hacer cada pieza de forma individual.

Al igual que hice con mi blog principal hace un par de años, acabo de mover La Viruta Rebelde al motor de Pelican.

Todos los articulos viejos se encuentran aquí.

2018 is over and 2019 starts. This is a great opportunity to look back, reflect and to try to look into the future. I predict that 2019 will be a very good year for privacy, open source and decentralized cloud software. Maybe even the mainstream breakthrough of federated and decentralized internet services!

Let me explain why:

The mainstream opinion about centralized services started to change in 2018 and I think this trend will continue in 2019. More and more people see the issue with large, centralized data silos that control more and more of our private lives, democratic processes and society as a whole. Some examples from 2018 where bad news hit the press include:

• The never ending list of Facebook scandals: Wired
• Twitter election meddling: BostonGlobe
• Amazon Alexa is listening to private conversations and is leaking the data: Heise and  BusinessInsider
• Dropbox is leaking private date: TechTarget
• Google Plus is insecure and will shut down: CNBC

This year, Europe introduced the GDPR to regulate the collection of private data. I believe it is a good start and think we ultimately we need rules as described in the User Data Manifesto
I expected that people in the US and Asia wouldn’t take the GDPR seriously and make fun of Europeans tendency to ‘over-regulate’. So I was surprised to see that the GDPR was widely praised as a step into the right direction. People in Asia and US are already asking for similar regulations in their markets, California has already announced its own variant of the GDPR with the California Consumer Privacy Act.

This clearly shows that the world is changing. People realize more and more that extensive centralized data collection is a problem. This is an opportunity for open source and decentralized and federated alternatives to enter the mainstream.

At Nextcloud we have become widely recognized as one of the major alternatives. And this year was big for us, with three big releases introducing new technologies the world needs going forward. Let me name just a few:

• End-to-end Encryption. In 2018 Nextcloud launched support for full end 2 end encrypted file sync and share.
• Nextcloud Talk. Beginning of 2018 we launched Nextcloud Talk as a fully integrated self hosted, open source and decentralized chat and audio/video call solution
• Just a few weeks ago we launched Social with ActivityPub support to integrated with Mastodon and other projects of the Fediverse.
• Simple Signup. In summer we launched the Simple Signup feature to make it possible for new users to sign up at one of the Nextcloud providers directly from the Mobile and Desktop apps.
• We launched our unique Video Verification feature to become the most secure file share platform.
• In summer we announced the initiative to ship Nextcloud preinstalled on millions of NEC routers, something that will take off in 2019, you might have seen the prototype devices on social media.
• This fall we launched the Nextcloud Include program with funding from the Reinhard von König Preis for innovation. I’m happy we run this project together with my old friends from KDE.

In 2018 I traveled to more events and countries than ever before. It’s great to see how the Nextcloud community is growing all over the globe. On the company and business side we also have good news. The Nextcloud company is growing nicely in all areas. There will be separate news about this soon.

Of course it’s the mission of Nextcloud to not do everything alone. This is why we launched a lot of integration projects in 2018. For example with Rocket.Chat, Moodle, StorJ, Mastodon and others. I’m really happy to see that other open source and decentralization projects do as well as Nextcloud.

I think 2019 could be the year where open source, federated and self-hosted technology hits mainstream, taking on the proprietary, centralized data silos keeping people’s personal information hostage. Society becoming more critical about data collection will fuel this development.

If you want to make a difference then join Nextcloud or one of the other project that develop open source decentralized and federated solutions. I think 2019 is the year were we can win the internet back!

Recently the German computer magazin C’t posted an article about file sync solutions (“Unter eigener Regie”, C’t 23, 2018) with native sync clients. The article was pretty positive about the FOSS solution of… Nextcloud! I was wondering why they had not choosen ownCloud’s client as my feeling is that ownCloud is way more busy and innovative developing the desktop client for file synchronization together with community.

[caption id=“attachment_943” align=“alignright” width=“338”] Code lines changed as of Nov. 10, 2018[/caption]

That motivated me to do some investigation what the Nextcloud client actually consists of (at due date Nov. 10, 2018). I was looking into the NC desktop client git repoository grouped the numbers of commits of people that can be associated clearly to either the ownCloud- or Nextcloud project, or to “other communities” or machine commits. Since the number of commits could be misleading (maybe some commits are huge?) I did the same exercise with numbers of changed lines of code.

When looking on the changed lines, the first top six contributors to the Nextcloud desktop client are only active in the ownCloud project. Number seven is an “other community” contributor whos project the client was based on in the beginning. Number eight to eleven go to Nextcloud, with a low percentage figure.

[caption id=“attachment_944” align=“alignnone” width=“666”] # of commits to the Nextcloud Desktop repository as of Nov. 10, 2018[/caption]

As a result, far more than 80% of the changed lines of the Nextcloud client is actually work that ownClouders did (not considering the machine commits). In the past, and also today. The number would be even higher if it considered all the commits that go into the NC repo with an NC author, but are actually ownCloud patches where the original author got lost on the way by merging them through a NC branch. It looks like the Nextcloud developers were actually adding less commits to their client than all “other community” developers so far.

No wonder, it is a fork, you might think, and that is of course true. However, to my taste these numbers are not reflecting a “constructive” fork driving things forward when we talk about sync technology.

That is all fine, and I am proud that the work we do in ownCloud is actually stimulating two projects, with different focus areas nowadays. On the other hand, I would appreciate if the users of the technology would take a closer look to understand who really innovates, drives things forward and also fixes the nasty bugs in the stack. As a matter of fairness, that should be acknowledged. That is the motivation that keeps free software contributors busy and communities proud.

Christmas is around the corner, but I couldn’t wait and I have already been trying the new Ruby release! :christmas_tree: :tada: Ruby 2.6, apart from efficiency improvements, which include the initial implementation of a just-in-time compiler, brings us many new cool features. Taking advance of the cold outside, let’s discover some of them! :snowflake:

Array#union & Array#difference

This Ruby version is particularly special to me because it includes my two new methods for the Array class, which I presented in my talks at EuRuKo and Brighton Ruby. Array#union and Array#difference are just readable alias for Array#| and Array#- respectively when only having two arrays:

[1, 3, 5, 7, 9].union([2, 3, 4, 5, 6]) #=> [1, 3, 5, 7, 9, 2, 4, 6]
[1, 1, 3, 3, 5, 7, 9].difference([3, 4, 7]) #=> [1, 1, 5, 9]

Array#union is also equivalent to combine Array#concat and Array#uniq (with the difference that concat modifies the array), but more readable. But what is really important about those new methods, are the gains in efficiency when having more than two arrays. We need some Benchmark now. :wink:

Using Array.new(num_elements) { Random.rand(20_100_000) } to create four arrays with 20,000,000, 30,000,000, 8,000,000 and 25,000,000 elements, those are the times for the different options:

• (array1 | array2 | array3 | array4) ~ 20.043 seconds
• array1.union(array2, array3, array4) ~ 13.390 seconds
• array1.concat(array2, array3, array4).uniq ~ 20.633 seconds

So please, stop using concat + uniq :pray: and let’s finally refactor some Ruby code! :tada:

Hash#merge with multiple parameters

Hash#merge and Hash#merge! were only able to merge two hashes at the same time. With Ruby 2.6, we can merge as many hashes as we want at once, which provides an performance improvement similar to Array#union and Array#difference when merging several big hashes.

{ a: 1, b: 2 }.merge({ b: 3, c: 4 }, { d: 5 }) #=> {:a=>1, :b=>3, :c=>4, :d=>5}

Enumerable#to_h

Enumerable#to_h accepts a block which allows to do things that used to require iterating manually or prepending map, being consequently more efficient. The following examples illustrate how it works:

(1..5).to_h { |x| [x, x % 3] } #=> {1=>1, 2=>2, 3=>0, 4=>1, 5=>2}
[1, 1, 2, 4].to_h { |x| [x, true] } #=> {1=>true, 2=>true, 4=>true}

Endless range

Ruby 2.6 introduces endless ranges like (1..), (74..) and (1..nil), whose size is infinite:

(1..).size => Infinity

It provides a nice alternative to [1..-1] to retrieve a slice up to the end of an Array or String:

[1, 2, 3, 4, 5][3..] => [4, 5]
'hello world'[6..] => "world"

It can also be combined with other methods to produce such elegant code:

# Selects from an array a range and from an element to the end
[0, 1, 2, 3, 4, 5, 6].values_at(1..3, 5..) #=> [1, 2, 3, 5, 6]

# Iterates over more than one array at the same time with index
[:a, :b, :c].zip([10, 37, 30], 1..) { |x1, x2, index| puts "#{index}: #{x1} #{x2}" }

# Multiples of π less than 100
(1..).lazy.map { |x| x * Math::PI }.take_while{ |x| x < 100 }.force

Last, it can be used to write infinit loops with index: (1..).each { |n| ... }, however we had already several alternatives to do this. I personally find the following ones more readable:

1.step { |n| ... }
n = 1; loop { ...; n += 1 }

Note: Be careful when trying infinite ranges, as if you iterate over a range (for example with map) and forget lazy (or to stop it for instance with break), it may consume all the memory of your computer, as it happened to me. :sweat: You can use ulimit to limit the memory available for the console where you execute irb when playing with it to avoid this (on Linux and macOS). :nerd_face:

Range#=== uses cover? instead of include?

Although Matz always aims to prioritize backwards compatibility, in this case performance has won. Range#=== uses now cover? instead of include? to check if an object is an element of the range. This is a reasonable but also breaking change, which modifies the behaviour of statements like:

(Date.today..(Date.today + 1)) === DateTime.now #=> true (false in Ruby 2.5)

Take into account that Range#=== is used in case, so the following example also change its behaviour:

case DateTime.now
when (Date.today..(Date.today + 1))
  'you are in Ruby 2.6!'
else
  'update to Ruby 2.6'
end

Proc#« & Proc#»

We can now compose procs both from left to right (>>) and from right to left (<<):

double = proc { |x| x * 2 }
increment = proc { |x| x + 1 }
(double >> increment).call(2) #=> 5
(double << increment).call(2) #=> 6

Procs with multiple arguments are also supported:

f = proc { |x, y| x + y }
g = proc { |x, y| [x * 2, -(y * 3)] }
(f << g).call(2, 1) #=> 1

Enumerator#+ and Enumerable#chain

Ruby 2.6 introduces Enumerator::Chain, a new class to represent a chain of enumerables that works as a single enumerator as well as methods to create chain of enumerables: Enumerable#chain and Enumerator#+:

chain = (1..3).chain([7, 8]) #=> #<Enumerator::Chain: [1..3, [7, 8]]>
chain.to_a #=> [1, 2, 3, 7, 8]

chain = (1..3).each + [7, 8] #=> #<Enumerator::Chain: [#<Enumerator: 1..3:each>, [7, 8]]>
chain.map { |x| x * 2 } #=> [2, 4, 6, 14, 16]

Dir#each_child & Dir#children

The Dir class had already the class methods children and each_child. Ruby 2.6 add the equivalent instance methods:

d = Dir.new("/home/ana") #=> #<Dir:/home/ana/>
d.children #=> [".config", "bin", ".gitignore", ".vimrc", "github", "cat_pictures", ".bashrc", "VirtualBox VMs"]

non-ASCII constant names

Constant names can now start with non-ASCII capital letters. I am not sure how useful this is, but you can do funny things like:

class Σ♥²; end

In few days, you can update to Ruby 2.6 and have fun too! :wink: