Skip to content

Monday, 19 September 2022

Last month, I was in Saumur (France) to attempt a KDE Promo sprint. This was my first sprint since the pandemic, actually this might even be my first ever official KDE sprint as before the pandemic I primarely attended conferences (Akademy, Fosdem, Libre Graphics Meeting, Linux App Summit, …) but no official sprint.

The sprint took place during the weekend and was a great occassion to meet Allon, Aron and Neophytos for the first time. Aside from them I also meet Claudio, Paul, Joseph and Aniqua would I had already had the chance to meet before.

While the sprint was only 2 days long, I think we had some really productive discussions about the general strategie we should take and also how to move forward with some stuck tasks.

Personally I was quite happy to unblock one of my previous idea of creating “KDE for”-webpages. I already created a KDE for Kids page a long time ago but never managed to find the time and motivation to create more of them. So during the sprint, we started to brainstorm a bit for a “KDE for Creators” page, you can already take a look at the wip prototype here and if you have suggestions and want to help we have a phab task.

Aside from all the productive discussions, Allon made us discover Saumur. It’s a really nice city near the Loire. But I need to say that I was quite depressed at the level of water in the Loire, it looked almost empty. Good reminder that climate change is real and human made.

Aside from the sad state of the Loire, we also tasted a lot of good food. We had some gallete bretones on Sunday evening and it was delicious. Allon also invited us Saturday night at his place and he made fouée for us.

bread oven with fouée
bread oven with fouée

It’s a local speciallity and it was really good and I was so full at the end of the day. Thank you Allon and your family for being such wonderful hosts!

Sprint photo
Sprint photo

Saturday, 17 September 2022

Tuesday night, I managed to break the screen of my laptop. This is particular annoying when you don’t have any external screen at home and need to work. Fortunately the scren wasn’t completely broken, and I managed to survice Wednesday, with half of the screen working.

From half of the screen working on Wednesday, the situation got worse on Tursday and I was forced to find another solution. My only other Linux powered devices at home were a PinePhone and my SteamDeck. Performance wise, the choice was easy and I choose to try to use my SteamDeck. And so my workstation on Tursday and Friday ended up like this:

Steam deck workstation
Steam deck workstation

I connected the dev environment of my laptop with SSH and it kinda worked. I did some commit. I even managed to do call and share my screen for a demo/presentation at work. But still the experience on the small screen wasn’t that great.

Fortunately, I ordered a new laptop (Thinkpad E14 gen 4) and it arrived on Friday afternoon. The new laptop has a working screen but no mainline wifi drivers. So took me a bit more time than expected to build and sign the out-of-tree drivers with secure boot enabled.

I love hardware.

Friday, 16 September 2022

Let’s go for my web review for the week 2022-37.


W4 Games raises $8.5 million to support Godot Engine growth – W4 Games

Tags: tech, 3d, godot, business

This could be good news, let’s hope this really pushes Godot forward.

https://w4games.com/2022/09/13/w4-games-raises-8-5-million-to-support-godot-engine-growth/


Privacy vs “I have nothing to hide” - Kev Quirk

Tags: tech, privacy, surveillance

As if we still need people to be convinced… apparently we do. So just in case we need a well built argument about it, this post does it.

https://kevquirk.com/privacy-vs-i-have-nothing-to-hide/


Microsoft Teams stores auth tokens as cleartext in Windows, Linux, Macs

Tags: tech, microsoft, security

So they’re seriously not using the system credential management to store these… I mean OK if your machine is compromised there’s not much you can do. But for a laptop being stolen for instance it’d make sense for such tokens to be protected by default and require a passphrase to be read by a local application, otherwise you could just easily recover it from the disk if it’s not encrypted.

https://www.bleepingcomputer.com/news/security/microsoft-teams-stores-auth-tokens-as-cleartext-in-windows-linux-macs/


A taxonomy of hosting options, for personal data security

Tags: tech, self-hosting

This is a welcome list of options to clarify what we’re talking about when we talk about “self-hosting”. It’s not a single concept but a range of approaches.

https://thomask.sdf.org/blog/2022/09/15/a-taxonomy-of-hosting-options.html


QR codes | Dan Hollick 🇿🇦

Tags: tech, barcode, qrcode

Nice explanation on how QR codes are made. The most gritty details are left out so it’s easy to follow.

https://typefully.com/DanHollick/qr-codes-T7tLlNi


Transcending POSIX: The End of an Era? | USENIX

Tags: tech, system, unix, posix

Very interesting piece. Goes in length about the UNIX history and the evolution of POSIX. It also highlight its limitations and where the design needs to evolve.

https://www.usenix.org/publications/loginonline/transcending-posix-end-era


The Little Things: My “radical” opinions about unit tests

Tags: tech, tests, tdd

Some good points in this list although I’m not in full agreement with everything (especially the one about the lack of usefulness for TDD). The importance and the impacts of the tooling is often underestimated indeed. The last two random opinions about mocking and overtesting are very much true as well.

https://codingnest.com/the-little-things-my-radical-opinions-about-unit-tests/


9 Practices that Haunt Developers Working with Scrum | by Willem-Jan Ageling | Serious Scrum | Sep, 2022 | Medium

Tags: tech, project-management, scrum, agile

Lots of truth in there. Indeed the proposed “practices” when they get in just kill the promises of things like Scrum.

https://medium.com/serious-scrum/9-practices-that-haunt-developers-working-with-scrum-e5903b8500f0


⭐️ How management by metrics leads us astray

Tags: management, metrics

A good reminder about the impacts of Goodhart’s law, or even simply of measuring the wrong thing. I like the conclusion overall: it’s fine to measure things but that shouldn’t be the center of the decision taking and conversations need to take a larger role into it.

https://jakobgreenfeld.com/metrics


First rule of the team: size

Tags: management, team

Good points to keep in mind regarding team size. It’s a delicate balance to strike in an organization.

https://medium.com/@kolyaskink/first-rule-of-the-team-size-94cdad8bc79e


ZeroBanana – Senior Engineers are Living in the Future

Tags: tech, organization, information

Interesting point of view. Indeed what might look like magic skills can simply be about having gathered more information. That thus depends on the organization.

https://www.zerobanana.com/essays/living-in-the-future/


Etsy Engineering | Blameless PostMortems and a Just Culture

Tags: management, failure, postmortem, safety, psychology

If you want to get to the bottom of a problem and of why an accident happen, people need psychological safety. This is indeed necessary if you want them to share truthfully why the accident happened in the first place. Otherwise fear will drive the conversation and hide important facts.

https://www.etsy.com/codeascraft/blameless-postmortems


Quality Is Systemic - Jacob Kaplan-Moss (jacobian.org)

Tags: tech, quality, team

In our industry, we obsess too much over individual performance. In turn it means that the systems we put in place within or around our teams get neglected… this is a problem because it is what has the biggest impact on quality and performance.

https://jacobian.org/2022/sep/9/quality-is-systemic/


Bikes, Not Self Driving Cars, Are The Technological Gateway To Urban Progress

Tags: tech, urbanization, bike

Please this, I’d love to see more bikes everywhere.

https://nextcity.org/urbanist-news/bikes-not-self-driving-cars-are-the-technological-gateway-to-progress


The world’s 30 most beautiful bookshops

Tags: book, library, travel

Definitely a good list of places I’d love to visit and get lost into.

https://nitter.42l.fr/AlexAndBooks_/status/1550145062260117506



Bye for now!

Thursday, 15 September 2022

KDE PIM is the set of applications that helps you manage your email, contacts, appointments, tasks and more. Since our last report covering KDE PIM in May and June, the PIM applications and libraries have seen over 1200 changes from almost 30 contributors. Let’s go over some of the biggest updates. New features Kalendar I … Continue reading "KDE PIM in July and August"

Tuesday, 13 September 2022

How some evening supermarket shopping is triggering some API work…

Human Mind vs. Machine Mind

Some time ago I ran into a variant of a self-service checkout system in a supermarket which, when asking for applying the data collection identity card, used a dialog with the button options “Yes” & “No”. Being privacy-positive, my thoughts were, yes, I want to keep my data private, and was about to press the “Yes” button. Only to check once more and find that the question actually was “Do you want to use our card?”. Which made me wonder why in the year 2022 new systems are developed that apply that old pattern of “Yes” & “No” replies. And reminded me that also in newer software made in the KDE community I had seen new appearances of that scheme. Had it not been found to be inferior, from what I had seen by-passing in the HMI field?

What Does The Human Interface Guideline Say

Let’s see what in 2022 the guidelines for some prominent UI systems recommend for buttons in dialogs.

Apple’s Human Interface Guidelines for Alerts (dialogs) about text to use on buttons:

Aim for a one- or two-word title that describes the result of selecting the button. Prefer verbs and verb phrases that relate directly to the alert text — for example, “View All,” “Reply,” or “Ignore.” In informational alerts only, you can use “OK” for acceptance, avoiding “Yes” and “No.” Always use “Cancel” to title a button that cancels the alert’s action.

Google’s Material guidelines on behavior of Alert dialogs:

Don’t use action text that fails to indicate what the selection will do. “Cancel” and “Delete” better indicate what will occur in this dialog.
[ed.: comment on a “Don’t” example using “NO”/”YES” buttons]

Microsoft’s Fluent Design System guidelines on buttons of Dialog controls:

Use specific responses to the main instruction or content as button text. An example is, “Do you want to allow AppName to access your location?”, followed by “Allow” and “Block” buttons. Specific responses can be understood more quickly, resulting in efficient decision making.

And respective recommendations can be also found in guidelines of FLOSS projects:

Haiku’s Human Interface Guidelines hold for Alert Windows this:

Avoid Yes / No button labels. It is much better to use the name of the action in the label, such as Save Changes / Discard Changes. Only in very rare cases are Yes / No labels the best choice.

Also KDE’s Human Interface Guidelines state on Modal Message Dialog:

Buttons should clearly indicate the available options using action verbs (“Delete”, “Rename”, “Close”, “Accept”, etc.) and allow the user to make an informed decision even if they have not read the message text. Never use “Yes” and “No” as button titles.

And the GNOME Human Interface Guidelines recommend on Action dialogs:

Label the affirmative button with a specific imperative verb, for example: Save or Print. This is clearer than a generic label like OK or Done.

When looking at older guidelines, e.g. in the NeXTSTEP User Interface Guidelines from November 1993 in the section “Naming Buttons in an Attention Panel” can be read:

When naming buttons in an attention panel, you should label each one clearly with a verb or verb phrase describing the action it performs. The user shouldn’t have to read the text of the attention panel to be able to choose the right button. Thus, generic labels (like Yes and No) aren’t appropriate, as they tend to cause user errors.

And similar, to little surprise, the variant in the OpenStep User Interface Guidelines from September 1996 in its section “Naming the Buttons in an Attention Panel”:

Label each button clearly with a verb or verb phrase that describes its action. Users should be able to read the names of the buttons and choose the right one. They should not need to read other text on the panel. Avoid “generic” labels like Yes and No, because they are not clear and lead to user errors. Avoid using OK unless it is the only button in the attention panel.

So seems the authors of all the HIGs checked agree on avoiding Yes & No. But is that actually founded on data from science & research, or did they just copy from each other?

Backed by Research?

On a quick look I could not find related scientific research reports that could back up the guideline recommendations. But instead I came across research about the related field of designing questionnaires, on the topic of preventing errors in the given answers e.g. due to misunderstandings or lack of concentration. And that seemed to confirm that people gave more correct answers and also felt it simpler to do when the items representing the choice (e.g. a text next to a checkbox) themselves had clear unique references to the choice instead of being abstract items whose meaning only could be known by the assignment to a choice in the question itself. Abstract items being things like colors, shapes, positions, numbers or the very Yes & No.

Not seen discussed or even researched, but my theory would be that things are worse even when there is a memory effect and something could mean the opposite in other similar choices.

Own experience with soda machines or coffee machines would confirm that, less mistakes remembered when pushing a button with the image of the wanted drink on it over entering a number on a dial to express the selection. Even more when the motivation for a drink was temporary brain insufficiency 😉

(If a reader has some pointer to related public papers, happy to add here).

API-Driven UI

By personal experience a lot of software is produced patch-by-patch, feature-by-feature, idea-by-idea. Often by people who at most learned how to write syntax-conforming code. And to be efficient, typically things are developed using resources which are available, e.g. deploying existing standard libraries. Thus instead of UX engineers designing HIG conforming UI stories directing the implementation, as theory would suggest, it is the API and any documentation around it of existing UI components libraries.

Legacy API Rooting for Yes & No

One might remember more “Yes” & “No” buttons in older software. One reason might be that those texts (and their localized variants) need less horizontal space on the screen, something to consider for sure in low-dpi times. But then also still in hi-dpi times, when there are other constraints requiring very short texts to have it fit on the display.

Another reason was that it saves resources in the own software, if one just has to pass a flag to denote a set of predefined standard buttons with their texts and possibly icons instead of having to maintain and carry around all the data in the own executable and then pass it over at runtime. And such flag idea is supported by the API of legacy libraries.

The classic Microsoft Windows Win32 API provides a MessageBox function, to show a modal dialog:

int MessageBox(
  [in, optional] HWND    hWnd,
  [in, optional] LPCTSTR lpText,
  [in, optional] LPCTSTR lpCaption,
  [in]           UINT    uType
);

The argument uType is used with flags to define the buttons to use in the dialog, like MB_YESNO or MB_YESNOCANCEL. Those buttons have hard-coded text . The function return value indicates which button was pressed, like IDYES or IDNO.

This function signature and related definitions have been also carried over to other MS APIs, see e.g. .NET’s System.Windows.Forms.MessageBox with MessageBoxButtons and DialogResult. So still continuing to have developers write “Yes” & “No” options dialogs, despite some HIG from the same company (see above) recommending not to do that.

Borland’s (now Embarcadero) Visual Component Library (VCL) has been following the same spirit offering the function Vcl.Dialogs.MessageDlg:

function MessageDlg(
    const Msg: string;
    DlgType:   TMsgDlgType;
    Buttons:   TMsgDlgButtons;
    HelpCtx:   Longint
): Integer;

The Buttons argument takes flag values like mbYes and mbNo, while the matching returned value are defined by constants like mrYes or mrNo. Latest version 10.4 Sydney at least has an overload with an additional argument CustomButtonCaptions: array of string. But the flags and constants keep the code centered around the concepts of Yes and No.

Another classic UI library is Java’s Swing. It provides a class javax.swing.JOptionPane to use for standard dialog boxes. While the developer can add any custom UI components to the button row, the class itself provides prominently documented convenience API to use predefined button sets by optionType argument values like YES_NO_OPTION or YES_NO_CANCEL_OPTION. Using those flags saves resources needed to come up with own texts and any needed localization, so a developer has motivation to use those.

Then there is Qt. It has had the class QMessageBox (now part of Qt Widgets) providing a modal dialog. That has an enum with values like QMessageBox::Yes and QMessageBox::No, which is used in the class methods to reference predefined button as well as to return the user choice. Static convenience methods like QMessageBox::question() use Yes & No as default arguments, with no option to use custom buttons.

QMessageBox::StandardButton QMessageBox::question(
    QWidget *parent,
    const QString &title,
    const QString &text,
    QMessageBox::StandardButtons buttons = StandardButtons(Yes | No),
    QMessageBox::StandardButton defaultButton = NoButton
);

Custom buttons can be used when manually creating a QMessageBox instance, but the involved flags and constants also here keep the code centered around the concepts of Yes and No.

Again the API was carried over to own newer products, here the QtQuick API. The QML type QtQuick.Dialogs.MessageDialog has a property standardButtons, which takes a flag set for predefined buttons, .like QtQuick.Dialogs.StandardButton.Yes and QtQuick.Dialogs.StandardButton.No.

The sibling type from the QtQuick Controls 2, QtQuick.Controls.Dialog, also has a property standardButtons, which takes a flag set for predefined buttons, here QtQuick.Controls.Dialog.Yes or QtQuick.Controls.Dialog.No. With this type one can customize the button properties in the Component.onCompleted method, but as with QMessageBox the involved flags and constants also here keep the code centered around the concepts of Yes and No.

Looking further, Gtk also has had methods around a Gtk.MessageDialog, with the main instance creation function being:

GtkWidget*
gtk_message_dialog_new (
  GtkWindow* parent,
  GtkDialogFlags flags,
  GtkMessageType type,
  GtkButtonsType buttons,
  const char* message_format,
  ...
);

The argument buttons is used to reference predefined sets of buttons, e.g. GTK_BUTTONS_YES_NO. The dialog will emit a signal when the user chose a button, using values like GTK_RESPONSE_YES or GTK_RESPONSE_NO. One can also only add custom buttons with own text and ids. A note in the documentation for Gtk.ButtonsType hints at least that GTK_BUTTONS_YES_NO is discouraged by GNOME’s HIG.

Oh Yes: KDE Frameworks with Oh-Nos

The KDE Frameworks, a set of extensions around Qt, have quite some APIs designed decades ago. Among them are in the KMessageBox namespace convenience methods around message dialogs, for more feature-rich variants of the static methods of QMessageBox and reflecting the accepted state of art at the time. By the time they have grown into a large set, all encoding their specifics in the method names. But never got adjusted to meet the newer state of the art when it comes to recommended texts on the buttons, including KDE’s own HIG.

Examples are:

ButtonCode
questionYesNo(
    QWidget *parent,
    const QString &text,
    const QString &title = QString(),
    const KGuiItem &buttonYes = KStandardGuiItem::yes(),
    const KGuiItem &buttonNo = KStandardGuiItem::no(),
    const QString &dontAskAgainName = QString(),
    Options options = Notify
);
ButtonCode
questionYesNoCancel(
    QWidget *parent,
    const QString &text,
    const QString &title = QString(),
    const KGuiItem &buttonYes = KStandardGuiItem::yes(),
    const KGuiItem &buttonNo = KStandardGuiItem::no(),
    const KGuiItem &buttonCancel = KStandardGuiItem::cancel(),
    const QString &dontAskAgainName = QString(),
    Options options = Notify
);
ButtonCode
warningYesNo(
    QWidget *parent,
    const QString &text,
    const QString &title = QString(),
    const KGuiItem &buttonYes = KStandardGuiItem::yes(),
    const KGuiItem &buttonNo = KStandardGuiItem::no(),
    const QString &dontAskAgainName = QString(),
    Options options = Options(Notify|Dangerous)
);
ButtonCode
warningYesNoCancel(
    QWidget *parent,
    const QString &text,
    const QString &title = QString(),
    const KGuiItem &buttonYes = KStandardGuiItem::yes(),
    const KGuiItem &buttonNo = KStandardGuiItem::no(),
    const KGuiItem &buttonCancel = KStandardGuiItem::cancel(),
    const QString &dontAskAgainName = QString(),
    Options options = Notify
);

The return type ButtonCode being an ernum with values like Yes and No.

Recent API additions for some more asynchronous variants, though without convenient one-method-call code, by the class KMessageDialog continue the pattern. An instance can be only created by defining its type in the constructor method:

KMessageDialog::KMessageDialog(
    KMessageDialog::Type type,
    const QString &text,
    QWidget *parent = nullptr 
);

Where the argument of enum type KMessageDialog::Type has values like QuestionYesNo, QuestionYesNoCancel, WarningYesNo, or WarningYesNoCancel. To signal the user choice, the class reuses the enum type StandardButton from QDialogButtonBox , with values like QDialogButtonBox::Yes or QDialogButtonBox::No.

Searching the current sources of all KDE software using QWidgets technology for the UI, one can see all that API is heavily used. While many places have seen follow-up work to use custom, action-oriented texts for the buttons, as recommended by the KDE HIG, yet the code itself has to keep using the Yes and No semantics, being part of the API.

The spirit of this API can be again found in the message API available to the KIO workers to request interaction with the user by the front-end:

int KIO::WorkerBase::messageBox(
    const QString &text,
    MessageBoxType type,
    const QString &title = QString(),
    const QString &buttonYes = QString(),
    const QString &buttonNo = QString(),
    const QString &dontAskAgainName = QString() 
);

The argument of enum type MessageBoxType has values like QuestionYesNo, WarningYesNo, or WarningYesNoCancel. Similar patterns in the front-end interface classes.

KDE Frameworks’ QtQuick-based UI library Kirigami with its Kirigami.Dialog and Kirigami.PromptDialog copies the problems of Qt’s QtQuick.Controls.Dialog, having a property standardButtons taking a flag set for predefined buttons by values like QtQuick.Controls.Dialog.Yes or QtQuick.Controls.Dialog.No.

With all this API, and also not a single comment in its documentation about what the KDE HIG has to tell here, and a community reaching out explicitly also to non-educated developers, it is little surprise that even new code written in the KDE community these days uses the discouraged Yes/No dialog pattern.

HIG CPL KF API: TBD ASAP

With the upcoming KDE Frameworks 6 API series around the corner, it would be good to have some substitute API done before, so the HIG-conflicting API could be deprecated still for KF5. And KF6 would only hold API trapping developers into more HIG-conforming UIs.

Some, sadly non-exciting proposals to address this should appear in the next days, both as further blog posts as well as MR with actual code.

Sunday, 11 September 2022

My Google Summer of code is about to close! It’s been very educational time working on my project to implement exporting as svg. Now that it’s just about done its time I put my thoughts on how my GSoC project went.

Things that went well

I think I learned quite a lot working on this project. It was the first coding task with a fairly large scope that I’ve done. All of my past contributions have either been small bug fixes or extending currently existing code. This was the first time I had to make entirely new classes, files, and logic to get something working. That resulted in a lot of needed discovery and investigation to get all the pieces to fit together.

After an unexpected change in the plan in the project (using a nodeVisitor with a saveContext) I was able to pivot and figure out how that out and get that code working. I had a lot less starting context on how that part of the code worked since it wasn’t a part of my initial investigation for this project. But despite that I was able to fit the pieces together (with some help).

Things that could have gone better

Sadly I didn’t get to complete my goals for the project. I think this was mainly from my own inexperience in development. First there were a few times that something I thought would be fairly easy turned out to much harder to figure out than expected. Even though I had some padding in my project timeline I wasn’t able to meet the goals I had originally set. Although many of these were just first time struggles so things should go more smoothly next time.

The other thing I feel like I can do better is with asking questions. I don’t think I made as good a use of the mentorship as I could have. I never really feel truly “stuck” since I always have an idea of something else to investigate/research to better understand the problem. Eventually that gets a solution but sometimes it is just easier (and faster) to ask for some more help. Next time I’ll try to be more lenient and ask for help when I’ve been stuck a little sooner.

For the Future

GSoC is officially done but I still plan to work on my project. I think I’m actually just starting the fun part so I’m actually excited at whats coming next. I’ll still be updating this blog with my progress (although now not for GSoC) so stay tuned to watch my journey!

Saturday, 10 September 2022

I previously announced the end of new Qt5-based Grantlee releases. The Grantlee template system is to find new life as part of KDE Frameworks 6 in the form of KTextTemplate. The Grantlee textdocument library will probably become part of another KDE library with similar scope.

Meanwhile, some changes have accumulated since the last Grantlee release, so I’ve made a new release to make them available to users. Many of the changes are small, but with a few new features which were cherry-picked from the Cutelee repo.

The other significant change is that Grantlee 5.3.0 can be built with Qt 6. This is not a change of plan regarding migration to KDE Frameworks, but is intended to assist with porting existing code to Qt 6.

Speaking of new releases, we welcomed our baby into the world almost a year ago. Years ago it was a common refrain within the KDE community to new parents to remind them, tongue in cheek, to never shake the baby. I was amused to find that the advise given as a printed book to all new Irish parents reminds the same :).

Friday, 9 September 2022

Let’s go for my web review for the week 2022-36.


The New Numbers on Music Consumption Are Very Ugly

Tags: culture, art, business

There is indeed something concerning with the current trends in the arts and entertainment. This is clearly stagnating and looking back, barely creating novelty.

https://tedgioia.substack.com/p/the-new-numbers-on-music-consumption


After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won.

Tags: tech, email

The sad state of self-hosting emails. Even though it might not be as hopeless as it sounds.

https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html


Self-Hosted email is the hardest it’s ever been, but also the easiest.

Tags: tech, email

A good list of tricks to ease the pain with email hosting. I use some of it to deal with the delivery pain.

https://vadosware.io/post/its-never-been-easier-or-harder-to-self-host-email/


USB, Thunderbolt, Displayport & docks

Tags: tech, usb

Looks like a good cheatsheet to navigate the maze of the USB marketing terms…

https://stderr.nl/Blog/Hardware/Thunderbolt/TechnologyOverview.html


CO2.js: An Open Library for Digital Carbon Reporting

Tags: tech, climate

Sounds like a potentially interesting tool to estimate web applications CO2 impact. Looks far from perfect but this is better than nothing.

https://branch.climateaction.tech/issues/issue-4/co2js/


The self-fulfilling prophecy of React - Josh Collinsworth blog

Tags: tech, web, frontend, react

Indeed, React is a bit too much of the default choice right now while clearly it shouldn’t be that way. Let’s hope it’ll change and something else with more merit will take its place.

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react


You Can Build Portable Binaries of Python Applications

Tags: tech, python, portability, deployment

Python is making progress regarding portable binaries and it is welcome.

https://hynek.me/til/python-portable-binaries/


Accelerate Python code 100x by import taichi as ti | Taichi Docs

Tags: tech, python, performance

This has some interesting promises in terms of performance using Python. Looks a bit like a CUDA for Python… to be seen how it fares in practice.

https://docs.taichi-lang.org/blog/accelerate-python-code-100x


What Distinguishes Great Software Engineers? - by Abi Noda

Tags: tech, programming, craftsmanship

Indeed a good list of attributes. Not sure if that’s the only attributes you want in a team but that’s definitely must haves in at least one person.

https://abinoda.substack.com/p/great-engineers


The Forty-Year Programmer

Tags: tech, programming, culture, craftsmanship, career, life

Lots of good insight for a long career as a programmer. Definitely a few things I live by and a few… I tend to loose sight of. More progress to be made.

https://codefol.io/posts/the-forty-year-programmer/


Do we need an office?

Tags: management, remote-working

Very thorough breakdown on the things to keep in mind around remote work. We definitely still need offices and ways to meet. It “just” needs to be rethought how we use them and how we’re reachable.

https://zhuk.fi/do-we-need-an-office/


Good Interviewer/Bad Interviewer

Tags: hr, interviews

A very good list of criteria… Definitely questions we should ask ourselves regularly to know where we stand.

https://blog.metaview.ai/good-interviewer-bad-interviewer/



Bye for now!

Thursday, 8 September 2022

Current progress

The coding period is coming to an end in a few weeks, and this is the time for complete devotion towards making the activity ready to be merged. The visual representation of the activity is close to completion, and the working of a few parts is left. The implementation of the idea is improved significantly with the help of mentors. One thing I learned when implementing something in the code is that the activity should be “scalable” for the future. It should adapt to the requirements.

In sub-activity 2, the representation is now done using “repeater.” Initially, it was three separate blocks of the same component which wasn’t the most effective way. The dataset in sub-activity one is modified. Now the dataset is more adaptable to adding new levels, and the calculation of the number of levels is more efficient than in the previous implementation. The dataset has three options, options 1 and 2 have two levels each, and 3rd option has three levels. In the first option, the user would have to find the 10’s complement of a number greater than five and the 10’s complement of a number smaller than 5 for the second option. The third option is the combination of the first and second. When all the options are selected, sub-activity 1 consists of 7 levels.

Challenges Faced and learnings

One major challenge I faced, and it was one of the most fruitful learning too, was using a repeater for display. Although there was an “easy” implementation for it, too, mentors said I could do it using it anyway. I thought to attempt to do it the “best” way first, and if I’m unable to do it, I will do it the brute force way, which is not very ideal for scalability but fulfills the purpose. 

To understand the implementation of “repeater,” I read the official documentation, understood very little, and then watched 1-2 youtube videos and saw some current implementation of the “repeater.” in “analog electricity” and “categorization” activities. Then I started implementing initially, which was difficult, but eventually, I could implement repeater.

I made a few mistakes while implementing it, but my mentors helped me correct them.

And another very useful thing I learned is when we populate the array with values, we should always add only the required values in them. In the previous implementation, I was first adding decoy values and later modified them to suitable values, which is not the correct way.

What’s next?

  • Clean up the code for all three activities, and make it ready to merge.
  • Resolve all the open comments on the merge request.
  • Briefly test the activities and check the room for improvement.

Tuesday, 6 September 2022

Due to a problem with releaseme's tarme.rb script, the release tarball for KPhotoAlbum 5.9.0 didn't contain any translation data. Alas, I noticed this not before the tarball already spread the mirrors, so we had to withdraw it an create a new one, with a bumped version number.

So here we are, KPhotoAlbum 5.9.1 is out now – even with translations now ;-)

— Tobias