My former colleague Marco invited me to codecentric's SoftwerkerCast to talk about frontend development and how backend developers can get started here.
I can recommend the SoftwerkerCast. Marco is doing a great job as host here and there are many interesting topics the podcast covered. You should find it on the platform of your choice.
Link: Episode on Spotify
Now and then I want to create PDFs and optimize the file size. I'm not necessarily in the mood to add another PDF software to my computer, and, depending on the content of the document, I don't want to complete the task online. In this situation, you can do well with Ghostscript.
The first thing you have to do is install Ghostscript on your computer. On a Mac with Homebrew, you can accomplish this with the following command:
brew install ghostscriptTo optimize a PDF, I use the following command.
gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile="output.pdf" input.pdfFollowing "Digital Minimalism," "Deep Work" was the second book by Cal Newport that I immersed myself into. The former had an overemphasis on "success stories" which seemed disruptive to me, but in "Deep Work," Newport strikes the right balance, in my opinion.
In early 2020, I discovered Cal Newport's book "Digital Minimalism", a discovery inspired in part by Marcel's insightful blog post on the subject.
Sicherlich kein Insider-Tipp und doch möchte ich Euch "What if" von Randall Munroe wärmstens ans Herz legen.
Nach "What if" folgt also "How to", welches auf den ersten Blick die logische Fortsetzung des vorherigen Buchs von Randall Munroe ist. An vielen Stellen gelingt das gut, jetzt, wo ich das Buch abgeschlossen habe, frage ich mich, ob ich zwischen den Büchern mehr Zeit hätte lassen sollen.
A few weeks ago, I decided to reactivate my podcast, "Herr Zenzes wills wissen". For the last few years, I hosted it with Podigee, but it became too expensive for my use case. I don't produce enough content to take full advantage of the smallest package, so I can save some money by hosting the podcast myself again.
April has started with a few minor updates that I'd like to share here on the blog.
There are topics in the IT world that divide opinions: what needs to be tested, test-driven development, do we work alone, in pairs or even in a mob? Do we need estimates for tickets?
Today I want to discuss estimates and why I think they are essential in a dev team. I realize many developers see it differently because estimates have an awful reputation. Critics say that they don't bring much to the team, take a lot of time in meetings and at the end "management" gets a statement when which feature is (guaranteed) available. In the sprint, people are then also quick to talk about why a supposedly small task is taking a long time. So, we have something that costs us a lot of time as developers and makes life difficult afterward because someone converts story points into time. And sure, if that's how estimates are lived in team, then I would question them in that form as well. But estimates can also be useful, help the team and help to plan things.