Microblog

How to Process Pictures in Bulk?

When working with large batches of photos, efficiency is key. My workflow is streamlined by taking time to crop photos directly on my camera (Fujifilm X-T5). This camera's ability to save images in both RAW and JPG formats, with a predefined color profile, significantly reduces the need for extensive post-processing.

While this approach saves me dozens—if not hundreds—of hours in color grading, some tasks still need attention before publishing. In the Drupal community, we follow specific guidelines for publishing photos to platforms like Flickr, ensuring proper attribution and copyright compliance.

Fortunately, tools like exiftool make this process straightforward. For example, here’s the command I used to prepare photos from DrupalCon Singapore 2024:

```
exiftool -artist="Jakub Piasecki" -copyright="© 2024 Jakub Piasecki" -sep ", " -keywords="DrupalCon, Drupal, Singapore, Open Source, Community, IT" /home/zaporylie/Pictures/DrupalCon\ Singapore\ 2024/Day\ 3/Contribution\ Day
```

This single command allowed me to:
- Add keywords for better
- Embed copyright
- Process all photos in a specific folder in one go.

By investing a little effort upfront, you can save time and maintain professional standards for your published work.

Hello from Singapore.

As mentioned in the previous post, I didn't come here only as a delegate but also decided to volunteer during the conference. I helped in two areas: as a Drupal Splash Awards Judge and as a DrupalCon photographer.

All Splash Awards-related work was done way ahead of the event - coordinated by Julia Topliss Splash Awards was gathering projects from across APAC region. I was impressed not only by the number but also the quality of submissions. It never stops to amaze me all the applications where Drupal proves itself not only useful but way ahead of its competition in terms of features, quality, and scalability.

Being a conference official photographer was demanding, I can't lie about that. Taking thousands of photos, selecting hundreds of unique shots, and processing and publishing them during the conference took a lot of effort. The stress of missing out on the shot is real and I have a new level of appreciation for everyone doing this on a daily basis.

Below you'll find a group photo I took this year. For more photos go to https://www.flickr.com/groups/drupalconsingapore2024/

Last year I had the pleasure of participating in Websummit in Lisbon. You can read more about my experience in this blog entry: https://piasecki.no/microblog/17

However this year I decided to skip Websummit as it conflicts with my plans to visit Singapore for DrupalCon Asia 2024! Happy to report that these plans worked out and I will see you in Singapore from Dec 9 to 11. More about my role in the upcoming post.

It's been a while since my last update but I intend to post more in the following weeks.

Today a short bash snippet I use to sync files from my local machine to my NAS. Adding it here as a reference for myself but feel free to adapt it in your workflows.

`rsync --remove-source-files --recursive --archive --compress --human-readable --partial --progress --info=progress2 ~/Pictures/ myNAS:Photos/`

Let me go through the option flags I am using:
`--remove-source-files` probably needs no explanation - files are removed once uploaded
`--recursive` rsync will go over files AND directories inside `~/Pictures/` dir.
`--archive` keeps ownership, permissions, symlinks, timestamps
`--compress` compresses files (some files that are compressed already may be excluded automatically)
`--human-readable` file sizes are in a human-readable format
`--partial` keeps partially transferred files if interrupted
`--progress` displays file progress on screen - appends file that is currently being transferred
`--info=progress2` displays the total percentage of files transferred and ETA

Whether you are an active member of the Drupal community, a hobbyist, or a power user, please use a couple of minutes today to answer this (very quick) survey. Thanks 🙌

Direct link: https://forms.cambrico.net/forms/drupal-bookmarking-survey?tca=JoDWgMmm…

Deadline: end of April 2024

I've been quiet lately as I am now at the end of my (well... very first... yeah, I know ) Asia trip. As this trip has covered the week of Easter and I've been postponing taking some longer time off from work I was able to do some sightseeing in Singapore, and other SEA countries. During other weeks I managed to work remotely for my clients back in Europe. I am happy that my work allows me to travel with my better half, and provide services to my clients even from another continent. That level of freedom (quite literally) means the world to me.

While in Singapore I participated in my first ever Drupal event in Asia - Drupal Singapore Meetup. I met a great bunch of Drupal enthusiasts with different backgrounds - from developers to managers - and I felt welcome from the moment I arrived at the venue. I was amazed by the organizational efforts put into organizing this event, especially by Solihin Jinata (SJ) and Joseph Chin from the local community. The meetup was organized in the lean coffee format so that everyone could add some subjects to the agenda and participate in the discussion later. We had a bunch of topics ranging from headless frameworks, through AI, caching strategies, and penetration testing, to Gander, the automated performance testing framework (brought to you by Tag1 Consulting, Inc.). The discussion was lively with all the participants sharing their thoughts on all the subjects we covered. Unfortunately, due to time constraints, we didn't cover all of them this time but this local group meets every month, and next month's meeting was already announced. Sadly my time here in Singapore is ending very soon, and I won't be able to participate in next month's meeting. But if you are in Singapore, please follow their Facebook Group page (https://lnkd.in/dvBjn5Cs) and Meetup group (https://lnkd.in/dx-MTJMs), and join their next events. I will keep monitoring Drupal events happening in Singapore, and I'll join again whenever I can, hopefully very soon.

Thank you, Drupal Singapore, for the warm welcome, and until next time!"

Pączki

Yesterday was the first day of a Great Lent. In Polish culture, this means that we traditionally start fasting until Easter. Times change and not everyone follows that tradition anymore (I am also guilty of that) but, for some reason, there are parts of the end of Carnival season and the beginning of Great Lent that survived until now. One of the major events in Poland is Fat Thursday (this year it happened a week ago) when everyone is eating an enormous amount of the nation's beloved Pączki (aka Donuts).

What makes Polish Pączki special? First and foremost they are fresh. And I mean fresh - still warm from the oil bath. Then they are stuffed, traditionally with a Rose Petal Jam—so no hole in the middle but a sugary substance for added sweetness. Finally Pączek is topped with icing sugar or royal icing. Which means sugar, inside of sugar, covered with sugar. This is the day when people eat as many of them as they can, in the ultimate-cheat-day style.

Pączki are made out of yeasty dough but, if you know me a little you know I could not resist substituting baker yeast with sourdough (wild yeast) which is what I've been doing for several years now. Here is my recipe for Pączki (12 pieces) which I adapted from Maks @ https://upieczsobiechleb.pl/paczki-na-zakwasie/ These are the best Pączki I ever had.

Ingredients:
- Bread flour 330g (in my case Caputo Manitoba)
- Oat Milk 150g
- Yolks 85g (between 4-6 depending on the size)
- Butter 85g
- Sugar 85g
- Levain 130g (I used my freshly fed and size-doubled wheat stiff starter)
- Salt 7g
- Rum 10g (this year I substituted it with Maple Whiskey with great result)

I mixed everything (except Salt and Rum) with a stand mixer until smooth, well-developed dough, rested for 15 minutes, and added salt and alcohol for another 4-5 minutes to mix until well incorporated and the dough had a silky-smooth texture.

Then coil-folded 4 times, 45 minutes apart, and finally, after a few hours of fermentation, shaped into 70-75g balls (12 balls). The entire procedure, including feeding the starter, took the entire day - first thing in the morning - feeding the starter, in the afternoon (around 3 pm) - mixing the dough, in the late evening (probably around 10 pm) - shaping it into balls and let it rise covered with plastic film so it won't dry,

Next day in the morning fry on a deep oil (I used sunflower oil) heated to 170C - 3-4 minutes on each side. Let it rest on a kitchen towel for a few minutes and add a feeling to your tasting. For me, it was rose petal jam or pistachio cream.

I hope you'll give it a try if you're a keen sourdough care-taker like myself 😉

I have been working in the software industry for almost two decades. Software products are never perfect - some mistakes, or maybe just minor annoyances, are and always will be part of software products. Nothing will change that, not even AI. 😉

It doesn't mean we, the people responsible for software products, do nothing to prevent issues from happening. Certain development processes, such as Test Driven Development, can limit the number of bugs in the software by adding test coverage or establishing common criteria for how the software must behave, like in Behavior Driven Development. However, none of these methods are perfect to the point where problems cannot be detected or reported.

There are three main personas when it comes to issue reporting:

1. Those who accept things the way they are.
You can meet them everywhere - maybe they are part of the product team, maybe they are potential clients evaluating your software product, or maybe they are already your clients - either voluntarily or involuntarily (e.g., through their affiliation with a certain company that uses your product). Often, these people suffer in silence and just accept things the way they are ("Well, it is what it is", "Could be worse", "Oh... it never worked. I just do this and that", "Let's take a coffee break and wait until it works again").

2. Those who report their frustration.
The second group of people are those who give feedback not on the product itself but on what it makes them feel. This group focuses on their experience with using the software product and compares it with their (often undisclosed) expectations. With these reporters, you will hear phrases like "Your product is a piece of garbage", "Nothing works", "Everything is broken", "I can't do anything", "It drives me nuts", etc. This group will usually be very vocal, but the information they provide doesn't help much in making the product better. This attitude is often boosted by the fact that no product on the market is unique; i.e., each product has a multitude of competitors, and it's often easier to replace the vendor than to help the current vendor fix known issues. Often, they can't verbalize what it is that annoys them.

3. Those who report their issues.
The final group consists of those who report specific issues they encounter with their software product, adhering to your reporting guidelines and providing necessary debug information. They may be frustrated and occasionally express frustration, but they focus on the particular problem and often provide the necessary debug info.

Let's now think about the interaction between your product team and each user group. With the first group, there is none - as simple as that. That makes it potentially the worst group of users as, while they don't complain, they also don't push you to make your product any better. The second group, the complainers, pose a nightmare for support teams. They can break team spirit and increase team turnover. However, they leave a footprint of their time with the product, and, with some curiosity and the right attitude, one can often pull some more information from them, which, in my humble opinion, makes them better for the product than the first group. The third group is your external QA team - they leave you all the information needed so you can make informed improvements to your software product. Be kind to them and reward them. You probably want to keep these users with you as long as possible, or at least I know I do.

As a product company, which group would you prefer as your user base?
As a software user, which group do you identify with?

Right to repair.

A little bit over a year ago I had an issue with electrical wiring in our place which almost led to a major incident. Thankfully a technician responsible for maintaining the grid network caught it in time and, with the help of my friend, he made a fix while I was away (I am blessed to be living in a place where I have friends and can occasionally trust strangers). During the repair, one of the picture frames we had on the wall fell and broke. Nothing big, just a simple frame from Ikea that costs less than 7 EUR. I took all of it apart and kept stored safe for the undefined future.

The future came yesterday as my wife and I purchased a poster from an exhibition we attended last weekend. I felt a rush to hang it on a wall and the only frame I had was the one I mentioned earlier. Thankfully we are both good with our hands so when the time finally came I used some wood glue, tape, and a hammer and with the help of my wife, we put it back to its original shape. I had plenty of occasions to replace the broken frame with a new one as neither the cost nor the availability was an issue, yet I decided to keep the 7 EUR frame in parts for over a year. Why?

The most obvious reason is - I was taught to do so. The older generation of Poles, people directly responsible for my education like my parents or teachers, had severe issues in getting what they wanted back in the 70s and 80s. That's due to a shortage of food and goods related to the economic crisis and increasing foreign debt of the People's Republic of Poland (RIP). Since they couldn't simply buy things they had to be creative and resourceful. So instead of replacing broken items, they would fix them. As a person born in the 80s, I did experience some of it on my skin, however, that's nothing compared to what the older generation has experienced and developed into a skill. And, either consciously or not, passed over to the next generation.

Now, two generations later, this mindset faded away. I am glad for the reasons why it did as we're blessed to live in prosperity with lots of goods and services available at our fingertips. On the other hand, we are living unsustainable lives, generating tons of waste, polluting the world around us, and jumping head-first into the climate crisis.

Fixing a 7 EUR frame rather than replacing it with a new one is just one small step. The frame is just 4 pieces of wood. But the same should be possible with more complex items we own. iFixit is a company that monitors the consumer electronics market and provides spare parts kits together with instructions on how to perform required maintenance on the items we own. They also rate devices such as laptops and phones, to indicate how fixable and upgradeable they are. Read more about the company's mission in its Right-to-repair manifesto https://www.ifixit.com/Manifesto

Of course, not everyone is manually capable of fixing everything. Just last week I felt too intimidated to replace a battery in my phone on my own so I delegated this task to someone much better at doing so. I wish I could do it myself but most of the manufacturers make it very hard. Suddenly you need specialty tools and parts you'll use only once if you do it by yourself. This is why companies such as iFixit are needed to open our eyes to the problems we are (potentially) facing and influence the change among manufacturers. Luckily we have now more options than ever to buy more sustainable phones (Fairphone - https://fairphone.com) or laptops (Framework - https://frame.work) that will last 2 or 3 times as long as the devices we currently own.

This is just the tip of the iceberg - we still have TVs, washing machines, cars, etc. As long as we want to buy new rather than fix what we already own, we are maintaining the status quo. Let's join those who speak loudly about this problem, companies like iFixit, and start fixing rather than replacing. If I can do it, most of you can as well.