Feeds

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1151 other packages on CRAN, downloaded 34.6 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 584 times according to Google Scholar.

Conrad released a new upstream bugfix yesterday (to improve views of sparse matrices). We uploaded it yesterday too but it once agfain took a day for the hard-working CRAN maintainers to concur that the two NOTEs from reverse-dependency checking over 1100 packages were in a fact false positves. And so it appeared on CRAN earlier today. We also increased the versioned dependency on Rcpp to match the use of optional entry-point headers Rcpp/Light, Rcpp/Lighter and Rcpp/Lightest. No other changes were made.

The set of changes since the last CRAN release follows.

Changes in RcppArmadillo version 0.12.8.4.0 (2024-05-30)

• Upgraded to Armadillo release 12.8.4 (Cortisol Injector)

  • Faster handling of sparse submatrix views

• Update versioned Depends on Rcpp to 1.0.8 or later to match use of Light/Lighter/Lightest headers.

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

We’ll be back next week!

The following contributors got their Debian Developer accounts in the last two months:

• Patrick Winnertz (winnie)
• Fabian Gruenbichler (fabiang)

The following contributors were added as Debian Maintainers in the last two months:

• Juri Grabowski
• Tobias Heider
• Jean Charles Delépine
• Guilherme Puida Moreira
• Antoine Le Gonidec
• Arthur Barbosa Diniz

Congratulations!

Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.

A bit like Nate’s “5 minutes bugs” initiative, I’m announcing a new initiative to improve our applications ecosystem. The goal is to improve the quality and quantity of KDE applications and the number of application contributors. For anybody who knows me, it is not that surprising. Inside KDE, I have been mainly involved in apps for many years. I worked on all areas, from development (maintaining or co-maintaining many apps like NeoChat, Kontrast, MarkNote, Tokodon, and Arianna, and contributing to numerous other apps, but also design, promotion, websites (e.g., apps.kde.org) and even a bit of packaging (Flatpak and to a lesser extent Windows). Hopefully, making this a bit more public and making this an initiative with a bit more coordination will encourage more people to help :)

The good thing is that we don’t start from zero. In almost 30 years, KDE developers have developed over 200 applications, covering many use cases, from high-quality applications for artists (Krita, Kdenlive, Glaxnimate) to educational and office apps. We also have:

• tons of shared libraries that make developing new apps more straightforward and consistent
• an increasing amount of technical documentation on develop.kde.org/docs (Thanks to Thiago, Claudio, and everyone else who contributed to it)
• a nice auto-generated website that lists all of these apps (apps.kde.org)
• a whole CI/CD system that makes it easy to test and deploy our apps to Flatpak, Windows, macOS, Android and FreeBSD
• tooling for the user documentation and the translations of apps
• an opt-in service to ensure that apps are regularly released (KDE Gear)
• tools like Clazy and Heaptrack to improve the code quality and performance of KDE apps
• and a lot more

However there are prominent areas where we should improve our story; otherwise, we would already have a desktop and mobile market share of 90% and archived world domination.

More concrete here is a non-exclusive list of high-level tasks to achieve this goal.

Closing the Feature Gap

We need to identify missing apps compared to other app ecosystems (Windows, macOS, Android, iOS, and GNOME) and see where we could, with little effort, improve our app offering. While creating a KDE 3D editor like Blender is unrealistic, we could already go quite far by creating small apps that wrap up existing CLI tools or KDE libraries. To give some examples, I saw a few days ago that GNOME has a new document converter app called Morphosis. It’s a simple wrapper around Pandoc, and we could either do the same and wrap Pandoc or use Calligra’s rich collection of filters. Another example is a translation application; we already have a library in KTextAddons that does translations with many backends (offline and online), and the library even provides a ready-to-use widget. We could create a simple wrapper around KTextAddons, and boom; we get a new high-quality application with minimal maintenance effort.

Improving our Existing Applications

Aside from creating new applications, improving and reviving some of our applications is also highly valued. A lot of work has already been put into these applications, and by cleaning up their UI and bringing them up to our latest standard, we could go quite far. Some examples: Calligra (a complete office suite including presentation tool, spreadsheet, presentation, and vector editor), KTechLab (an IDE for microcontrollers and electronics), KWave (a sound editor), Parley (a vocabulary trainer).

Usually for every release, I try to have one or two apps, where I focus some time on it. In the past, I worked for example on KWordQuiz, KAlgebra, Koko. I recently ported Calligra to Qt6, so now one of my side quests is to figure out a way to have a modern QtQuick UI while using the current QPainter-based renderer using the new Window embedding in Qt 6.7

Better Marketting for our Applications

We need not only more apps but also better promotion. The apps.kde.org website has already helped a lot by listing all KDE apps, and more recently, we also created a lot of kde.org/for websites that list some KDE apps for some niches that might be interested in some of our apps. Further ideas on improving the marketing effort would be to promote new and lesser-known applications on social media regularly. But also publish a “This week in KDE apps” blog post that would cover all the news relating to first and third-party apps (e.g., new apps, updates, new app relevant APIs), and this would be community maintained with a process similar to this week in Matrix/GNOME/… where people write in a Matrix channel and a bot compile the relevant posts togethers. We need to make the progress on our apps more visible.

In addition to promoting first-party apps, we must figure out how to better promote third-party apps and extensions that use KDE Frameworks and integrate well with Plasma. Here, we could get some inspiration from the GNOME Circle initiative.

Make it More Accessible to Start a New Project

Documentation is essential in making it easy for newcomers to start projects. In the past few years, we have invested a lot of effort into that. I started develop.kde.org/docs, moved and updated a lot of old documentation from techbase.kde.org, and mentored a Season of KDE project to write a Kirigami tutorial. Nowadays, Thiago is fabulously leading the documentation effort. It is going in the right direction.

Aside from pure documentation, I’m impressed by the quality of the GNOME Workbench app and the number of examples it contains. I started a simple prototype of the same idea with Kirigami a while ago, which I need to finish (help is welcome 🤗). In the same vein, KAppTemplate and our default templates need some love.

Aside from documentation, we should create a support channel where people can ask for help with their applications. We could also make it more evident that developers are encouraged to ask on kde-devel and the VDG channel for help with their apps, even if their apps are not first-party KDE applications.

Making it More Attractive to Write KDE Applications

Writing applications using KDE Frameworks is already quite attractive, but we should communicate more on the advantage of starting an application using the KDE Frameworks more.

Firstly, by leveraging an almost 30-year-old ecosystem, app developers can reuse many libraries for their apps and find examples of how to implement the most common workflow in existing code. KDE Frameworks are also extremely cross-platform, and creating a KDE application doesn’t restrict you to only Plasma. Krita and Kleopatra have famously had millions of Windows installations. We also have Craft, which helps develop and deploy Qt applications on Windows, macOS and Android.

For first-party applications, our self-hosted Gitlab allows app developers to have full CI/CD pipelines for many platforms and even automatically publish them to the Windows Store. We also have infrastructure for translations, user documentation, wikis, code search, file sharing (Nextcloud), chat (Matrix), OSM hosting, and more. There is also a human factor; by making an app a first-party KDE app, the app received a lot of help from experimented KDE developers as part of the KDE review process and also during the entire life of the app. And we have a promo team that helps promote your app as much as possible.

For third-party applications, by being LGPL, we give users of KDE Frameworks a lot of freedom in licensing and monetizing their applications as long as they contribute their changes back to the library they use.

Not Limiting Us to C++

In terms of cross-language support, there are also two independent efforts to make KDE Frameworks accessible to more programming languages: one for Python by alcarazzam, which is part of a GSoC project I am mentoring, and another one for Rust by mystchonky. These efforts should make it easier for app developers to write KDE applications even if they are unfamiliar with C++ or prefer not to use it.

Streamline the Publishing of our Apps for Other Platforms

We now reached a state where most of our applications are automatically published on Flathub. This is not the case yet for Windows, Apple and Android. Recently we gained the ability to publish directly from the gitlab CI to the Microsoft Store, but we don’t make use of that yet in most of our apps. So let’s change that!

Getting Involved

I started creating a board of issues on gitlab and filled it with various applications ideas from a discourse thread. Feel free to take one of the open task or suggests a new app.

Additionally I also created a Matrix room to have a room for conversation.

I am happy to announce a new release of GNU poke, version 4.1.

This is a bugfix release in the 4.x series.

See the file NEWS in the distribution tarball for a list of issues
fixed in this release.

The tarball poke-4.1.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-4.1.tar.gz.

> GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
> editor for binary data.  Not limited to editing basic entities such
> as bits and bytes, it provides a full-fledged procedural,
> interactive programming language designed to describe data
> structures and to operate on them.

Thanks to the people who contributed with code and/or documentation to
this release.

Happy poking!

Mohammad-Reza Nabipoor

Prepare for DrupalJam 2024! Set to take place on June 12th at the Fabrique in Utrecht, this event marks its 20th edition, promising a day of exploration and learning. Attendees will have the opportunity to gain valuable insights from keynote speaker Dries Buytaert, the program lead of Drupal. Organized by a dedicated team of volunteers, including Bart Vreugdenhil, Carole Grootenboer, Mario Gerssen, Rolf van de Krol, and Jean-Paul Vosmeer, DrupalJam embodies the collaborative spirit of the Drupal community. Kazima Abbas, sub-editor at The Drop Times, brings you exclusive insights from the organizers into the event's schedule, speakers, and engagement opportunities.

This blog has become a bit quiet since I joined the Lean FRO. One reasons is of course that I can now improve things about Lean, rather than blog about what I think should be done (which, by contraposition, means I shouldn’t blog about what can be improved…). A better reason is that some of the things I’d otherwise write here are now published on the official Lean blog, in particular two lengthy technical posts explaining aspects of Lean that I worked on:

• Recursive definitions in Lean
• Functional Induction theorems

It would not be useful to re-publish them here because the technology verso behind the Lean blog, created by my colleage David Thrane Christansen, enables such fancy features like type-checked code snippets, including output and lots of information on hover. So I’ll be content with just cross-linking my posts from here.

We are glad to announce the publication of a new research paper entitled Source Code Archiving to the Rescue of Reproducible Deployment for the ACM Conference on Reproducibility and Replicability. The paper presents work that has been done since we started connecting Guix with the Software Heritage (SWH) archive five years ago:

The ability to verify research results and to experiment with methodologies are core tenets of science. As research results are increasingly the outcome of computational processes, software plays a central role. GNU Guix is a software deployment tool that supports reproducible software deployment, making it a foundation for computational research workflows. To achieve reproducibility, we must first ensure the source code of software packages Guix deploys remains available.

We describe our work connecting Guix with Software Heritage, the universal source code archive, making Guix the first free software distribution and tool backed by a stable archive. Our contribution is twofold: we explain the rationale and present the design and implementation we came up with; second, we report on the archival coverage for package source code with data collected over five years and discuss remaining challenges.

The ability to retrieve package source code is important for researchers who need to be able to replay scientific workflows, but it’s just as important for engineers and developers alike, who may also have good reasons to redeploy or to audit past package sets.

Support for source code archiving and recovery in Guix has improved a lot over the past five years, in particular with:

• Support for recovering source code tarballs (tar.gz and similar files): this is made possible by Disarchive, written by Timothy Sample.

• The ability to look up data by nar hash in the SWH archive (“nar” is the normalized archive format used by Nix and Guix), thanks to fellow SWH hackers. This, in turn, allows Guix to look up any version control checkout by content hash—Git, Subversion, Mercurial, you name it!
• The monitoring of archival coverage with Timothy’s Preservation of Guix reports has allowed us to identify discrepancies in Guix, Disarchive, and/or SWH and to increase archival coverage.

94% of the packages in a January 2024 snapshot of Guix are known to have their source code archived!

Check out the paper to learn more about the machinery at play and the current status.

How do you start adding unit tests to your Python code? Can the built-in unittest framework cover most or all of your needs? Christopher Trudeau is back on the show this week, bringing another batch of PyCoder's Weekly articles and projects.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

We know that Drupal 7 reaching the end of life on January 5, 2023. It means it will no longer receive security updates or support from the Drupal community. So organizations or individuals that use Drupal 7 should upgrade to the latest version of Drupal 10.

What are Drupal migrations?

In Drupal migrations content, data, and configurations are transferred from one Drupal site to another. Migrations are commonly used when we upgrade from Older versions of Drupal to newer versions of Drupal.

Steps Taken Before Starting The Migration

Here's a concise list of steps to take before starting a migration

Step 1: Drupal 7 Database

First, back up the database of the Drupal 7 site. This ensures that if any issues are encountered during the migration, you can restore the site and re-run the process.

Using below command

Export: mysqldump -u root -p database name > filename.sql

Let’s go for my web review for the week 2024-22.

The next decade of the web | James’ Coffee Blog

Tags: tech, web, social-media, democracy

Very nice piece. Hopefully it’ll push people to remember that the big social media enclosures are not really the Web. We can have more democracy on the Web again if we collectively want to.

https://jamesg.blog/2024/05/19/next-web-decade/

How does AI impact my job as a programmer? – Chelsea Troy

Tags: tech, programming, debugging, teaching, gpt, copilot

Definitely this. In a world where LLM would actually be accurate and would never spit outright crappy code, programmers would still be needed. It’d mean spending less time writing but more time investigating and debugging the produced code.

https://chelseatroy.com/2024/05/26/how-does-ai-impact-my-job-as-a-programmer/

When privacy expires: how I got access to tons of sensitive citizen data after buying cheap domains

Tags: tech, dns, privacy, security

Or why you should let domain simply expire, there’s plenty of work to do before that.

https://inti.io/p/when-privacy-expires-how-i-got-access

Instead of “auth”, we should say “permissions” and “login” | nicole@web

Tags: tech, security, communication

The words we use indeed matter. This is definitely a domain where we should avoid ambiguities…

https://ntietz.com/blog/lets-say-instead-of-auth/

arighi’s blog: Extend your battery life with scx_rustland

Tags: tech, linux, system, processes

Interesting results. It’s especially nice to see how sched-ext allows to easily iterate and experiment with process scheduling strategies.

https://arighi.blogspot.com/2024/05/extend-your-battery-life-with.html?m=1

Evolution of the ELF object file format | MaskRay

Tags: tech, system, unix, elf, history

Definitely a complicated history… this doesn’t make the evolution or documentation of it easy.

https://maskray.me/blog/2024-05-26-evolution-of-elf-object-file-format

Never reason from the results of a sampling profiler – Daniel Lemire’s blog

Tags: tech, performance, optimization, profiling

Definitely to keep in mind when using sampling profilers indeed. They’re useful, they help to get a starting point in the analysis but they’re far from enough to find the root cause of a performance issue.

https://lemire.me/blog/2024/05/30/never-reason-from-the-results-of-a-sampling-profiler/

PyPy has been quietly working for me for several years now

Tags: tech, python

This definitely shows PyPy as a successful runtime.

https://utcc.utoronto.ca/~cks/space/blog/python/PyPyQuietlyWorking

Let’s optimize! Running 15× faster with a situation-specific algorithm

Tags: tech, python, performance, optimization

Another good example of how to speed up some Python code with nice gains.

https://pythonspeed.com/articles/lets-optimize-median-local-threshold/

What is a collision? — On Error Resume Next

Tags: tech, 2d, collision, physics, simulation

Good introduction to collision resolution inside of physics engines.

https://www.sassnow.ski/rigid-body-collisions/1

matcha.css | Drop-in semantic styling library in pure CSS

Tags: tech, web, frontend, css

Looks like a nice CSS library for the semantic styling of web content.

https://matcha.mizu.sh/

Why, after 6 years, I’m over GraphQL

Tags: tech, graphql, complexity

Shows well why you likely don’t want to use GraphQL. The chances you need the extra complexity and caveats are very slim.

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/

Don’t Microservice, Do Module

Tags: tech, architecture, microservices, complexity

Since this particular fad apparently doesn’t want to die… this is a good reminder about why you want to do something simpler.

https://yekta.dev/posts/dont-microservice-do-module/

My BDFL guiding principles | daniel.haxx.se

Tags: tech, foss, governance

Not necessarily my favorite governance model, but if you’re on that scheme… those are good guiding principles.

https://daniel.haxx.se/blog/2024/05/27/my-bdfl-guiding-principles/

To the brain, reading computer code is not the same as reading language | MIT News

Tags: tech, programming, cognition, neuroscience

Interesting research! Is reading code a math and logic task? Is it a language task? Well… it might be its own thing.

https://news.mit.edu/2020/brain-reading-computer-code-1215

Bye for now!

54th issue of Andrei Neagoie's must-read monthly Python Newsletter: Python Security Best Practices, State of Python 2024, Prompt Engineering, and much more. Read the full newsletter to get up-to-date with everything you need to know from last month.

Introduction Whatever takes time takes for good. Yeah, so, about on March I created a PR on snapcraft by canonical. It was about adopting more metadata from the parsed appstrean metadata file. The new fields that were made to parse were License Contact Issues Source Code (VCS Browser) Website Donation Link What does this change means? For publishers/snapcrafters Publishers and snapcrafters who also maintains an appstrean metadata for their app, you don’t need to maintain the metadata in your snap package separately.

The leading SEO principles for Drupal in 2024: Tips for Marketers Editor Fri, 05/31/2024 - 12:08

Drupal SEO tips come in whenever you need to build a firm foundation amidst the never-ending digital marketing and search engine optimization tricks. The overall industrial volatility can't help but demand more well-thought-out and user-engaging domains.
Take a closer look at modern SEO principles for Drupal 2024 — from content sustainability to the overall website architecture's adaptability and scalability. They demonstrate the international craving for turning solutions for customers' pain points, AI-based technologies, and human authorship into the best buddies. What Drupal modules will align with your business's vertical and horizontal success channels? Check it out!

Experience Builder (XB) must be able to render single directory components (SDC) … but really any component. Furthermore, to achieve the compromiseless UX we want, we’ll need both client-side and server-side rendering (to avoid network latency): isomorphic rendering. So on Monday May 20, Ben “bnjmnm”, Mateu “e0ipso”, Lee “larowlan”, Théodore “nod_”, Pierre “pdureau” and Tim met in a truly global meeting (from Lee’s Australia to Kris’ U.S. West Coast), with very interesting conclusions.
These are not current concerns for XB, but they will eventually be — this was early alignment to avoid wasting time.

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

On the code front, Alex Pott (who initially proposed a different repository structure in #3446374, see last week’s post) nudged XB in a better direction: over the weekend, he provided an MR to reuse core’s PHPCS rules and +1’d the structure we settled on. I finished & merged what he started and am grateful for the result :)

On Tuesday, front-end lead Jesse’s MR to carve rough outlines of the UI (no premature detail while awaiting more detailed wireframes and interaction design) was merged, and introduced the Radix UI component library that Lauri recommended.

Try it yourself locally if you like, but there’s not much you can do yet. See Jesse’s Slack message with more nuance.
Install the 0.x branch — the “Experience Builder PoC” toolbar item takes you there!

SDC is a foundation of XB, and while SDC recently left the experimental phase in Drupal core, it is itself still evolving. An example is #3390712, where work is happening to introduce the concept of component variants. On Wednesday, e0ipso, Christian “penyaskito” and pdureau started pushing that forward.

That same day, I pushed the commit that introduced a new FieldType plugin that actually implements Alex “effulgentsia” Bronstein’s proposed data model in #3440578.
An interesting suggestion on the proposal came from Matt “mglaman” Glaman: to implement this as a single field with 2 properties plus 1 computed property for the combined result … which matched my thinking exactly! I implemented it on Friday. More work to be done next week to get it to a mergeable state, and much more beyond that (nested component trees, (a)symmetric translations, easy querying and hence easy updates …)

From the flurry of activity above, a few outlines start to merge:

• with squinting eyes: the silhouette of a UI
• similarly: the data model as envisioned months ago by effulgentsia
• things happening outside XB that are relevant to it, with people not just from Acquia, Lullabot and PreviousNext, but the beginning of far wider involvement 1 — globe-spanning even!

Which seamlessly brings us to the next highlight of the week: the very first asynchronous XB meeting in Drupal Slack, organized by Griffyn “griffynh” Heels on Thursday. After 24 hours 2, the discussion gets archived in a d.o issue (#3449517).
This first meeting had 24 participants (with <150 people in the #experience-builder channel: 1 in 6!), I’d say this was a success :)
One pattern stood out: people are eager to contribute, but don’t know how yet. The honest answer is: we’re figuring that out — there is a list of product requirements, a codebase of <1 week old targeting those requirements and Lauri’s concept wireframes from September 2023. Contributors are welcome already, and can have a huge influence on the direction and shape of XB, but at this time need to be comfortable with helping to make things more concrete.

At the end of the week, I met with pdureau 3, talking about the UI Suite Initiative he’s been pushing for years now. Deeply integrated design system support in XB is crucial per Lauri’s research, and that’s exactly where the people behind the UI Suite initiative have gained a lot of expertise — and a working codebase that has ~20 frequent contributors and ~80 contributors over the past year! UI Suite explicitly supports for the various artifact types that design systems consists of, and XB will need to support these too. As the tech lead for XB but somebody who has never used design systems, it’s important for me to listen & learn. So I mostly listened.
The UI Suite ecosystem is currently transitioning to build on top of SDC. e0ipso and pdureau have been enthusiastically collaborating on this, and their enthusiasm is now positively visible in the XB Slack channel too! How exactly UI Suite will influence XB is not yet clear, but it likely will.

Goal for next week: connect conceptual dots that today exist only in the heads of people who’ve been in sufficient meetings with Lauri.

1. Hence why I stopped stating the employer of each individual — I’m still linking each individual so it’s easy to find out the organization name. And actually, quite a few of the names in this week’s update are independent/freelancers! In the end, any collaboration is between individuals, not organizations, so going forward I will only mention individuals’ names. When a new organization gets involved, I’ll state that too, but individuals deserve their own recognition. Each first mention of an individual in a post will always be linked to their drupal.org profile. ↩︎

2. To enable equal participation from any timezone. Which will be crucial, since Dries invited the entire community to help build XB and Starshot! ↩︎

3. He lives ~1000 km from me, but he happened to be in Brussels that week, so we made the best of that opportunity :) ↩︎

• Drupal
• Acquia
• Experience Builder

• The very rough initial XB UI— with a left and right sidebar, a canvas to drag components onto, and a few more basic pieces.

The LinuxCNC project is still going strong. And I believe this great software system for numerical control of machines such as milling machines, lathes, plasma cutters, routers, cutting machines, robots and hexapods, would do even better with more in-person developer gatherings, so we plan to organise such gathering this summer too.

The Norwegian LinuxCNC developer gathering take place the weekend Friday July 5th to 7th this year, and is open for everyone interested in contributing to LinuxCNC and free software manufacturing. Up to date information about the gathering can be found in the developer mailing list thread where the gathering was announced. Thanks to the good people at Debian as well as leftover money from last years gathering from Redpill-Linpro and NUUG Foundation, we have enough sponsor funds to pay for food, and probably also shelter for the people traveling from afar to join us. If you would like to join the gathering, get in touch and add your details on the pad.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

When I started this series on writing for developers and consultants, I thought of this piece first, but I couldn’t get the ideas to come together. Sometimes it takes a few tries.

Anytime you write something, you should be aware of what kind of document you’re writing and who is it for. The definition of “document” in this context is very broad it could be: an email, letter, solution design, chat messages, blog post, test script, work of fiction, book, poem, presentation, marketing slide deck, scope of work, and so on: anything that involves writing words.

For example, this is a blog post, about writing, meant for people who are developers or technology consultants who may have been told good writing isn’t important.

Common Work Documents

I’m going to put aside poems, novels, and other personal writing forms to focus here on work related writing. Developers need to be able to describe their work to other people. We also need to communicate about what is happening on a project, support one another, and ask for help. We do all these things with words, and often in writing.

In my career I’ve written a wide variety of documents as part of my work. A partial list (because I doubt I can think of everything to create a complete list) includes:

• Emails
  • to my boss
  • to colleagues or friends
  • to direct reports
  • to clients
  • to large mailing lists
• Solution Design Documents
• Scopes of Work
• Contracts
• Invoices
• Test Scripts
• Conference Talks
• Research Reports
• Chat Messages

Some require more detail and longer prose than others. Some are expected to be polished where others can tolerate typos and mistakes. But each has its own style, structure, audience, and expectations that the writer must meet.

A Document’s Purpose

When you start to wring something, know your purpose in writing.

Not all documents are created equal and so understanding your purpose is critical. Are you writing an Solution Design that needs to outline how you plan to solve all the hard problems in a project? Or are your writing an email to your boss asking for a few days off? Is this a research report meant to support an advocacy project or a cover letter for a resume? All of those are important things, but none should be written in the same tone or with the same style.

A Scope of Work (SOW) is a lasting artifact during a projects that sets the bounds of the work you’re going to complete. A sloppy SOW can cost you, or your employer, vast sums of money. A SOW writing purely to defended against those concerns may not express the client’s needs and interests, and result in them refusing to sign.

An email to a client might be a friendly reminder about pending deadlines, or a carefully crafted notes from a contentious meeting. Written well, both could leave you in a better place with your client. Written poor, both may cause your client to become frustrated with your sloppiness.

If you don’t know why you’re writing something, you are likely to write the wrong thing. At work, if you aren’t sure, ask for guidance.

A Document’s Audience

There is no such thing as a “general audience” you should always have a mental image of who you are writing to, and why.

We all know that it’s important to think about your audience, but we don’t always do this well. In part because determining the audience is sometimes a little complicated.

When your audience is the person or people you are writing to, you need to leverage your understanding of their knowledge, skill set, and project engagement. You want your text to meet them where they are.

Sometimes the audience you care about most, isn’t the direct subject of the message, but a 3rd party we know, or suspect, will read the document later. I find this is true particularly in contentious situations.

FOIA Warning

If you work in, for, or with government agencies in the US (and for similar reasons elsewhere as well) – including as a subcontractor – you should understand if your content is subject to a Freedom of Information Act requests. Sometimes your audience isn’t the person you are writing to at all, but the reporter who could read the message 2 years from now after they get copies of everything related to your project. In those settings, don’t put anything in writing you don’t want on the front page of a major newspaper.

But FOIA can also be a blessing for a developer who knows a bad decision is being made. Carefully worded expressions of concern, and requests for written confirmation of next steps, can trigger FIOA-cautious readers to recognize they need to follow your advice.

Finding the Right Level of Technical Detail

One of the hardest things for developers, and other people with lots of technical knowledge, to do well is communicate clearly about technical minutia. There is a balance to be struck between providing transparency and overwhelming readers with details. Developers have to think about details in our work. We also use field specific jargon that can be confusing to people whose work is in other areas.

Too often we confuse that specialized knowledge of our field, with intelligence. I have watched developers lose their audience in the nuances of small details, and come away announcing their audience was a bunch of idiots. Early in my career I was guilty of this as well. Assume you’re audience is as smart as you; they just know different stuff.

When you make that assumption you can avoid talking down to people, and start to work on finding their level.

The right level of technical detail will also vary by document type. When I’m exchanging emails with a client’s in-house developer we go deep into the weeds often. When I’m writing a SOW, the technical detail is nearly absent as we are defining functionality and purpose, not the exacting detail of how that functionality will be delivered.

The more you can be in conversation with the people you’re working with about their background, the easier it will be to find the right level of detail to explain yourself clearly.

Summation

Hopefully by now it’s clear, this is an overview of approach, not detailed guidance. In a future post I plan to write about some of these specific documents types, and how to write them. Hopefully this overview gives you ideas and things to think about as you work on your next document.

As I said in my first post on this topic, communications skills for developers and consultants is an enormous topic. The plan for this series is evolving as I go. If you have suggestions or requests feel free to leave me a message.

The post Writing for Developers and Consultants: Know your Documents Types appeared first on Spinning Code.

• Halla Rempt

Twenty-five years. A quarter century. That's how long we've been working on Krita. Well, what would become Krita. It started out as KImageShop, but that name was nuked by a now long-dead German lawyer. Then it was renamed to Krayon, and that name was also nuked. Then it was renamed to Krita, and that name stuck.

I only became part of Krita in 2003, when Krita was still part of KDE's suite of productivity applications, KOffice, later renamed to Calligra... And I became maintainer of Krita in 2004, when Patrick Julien handed over the baton. That means that I've been around Krita for about twenty of those twenty-five years, so I'll hope you, dear reader, will forgive me for making this a really personal post; a very large part of my life has been tied up with Krita, and it's going to show.

But let’s first go back to before when I needed a digital painting application; the first seeds for Krita were laid in 1998, even earlier than the first bits of code. There was this excitement around Linux back then, and there were lots of projects that attempted to create great applications for Linux. One of those projects was GIMP, and another project was Qt. The first was a digital image manipulation application, the other was a toolkit to create user-friendly applications in C++. But GIMP didn't use Qt, it used its home-grown user interface toolkit (although it originally used Motif, which wasn't open source). A Qt fan, Matthias Ettrich, did an experimental port of GIMP to Qt, and gave a presentation about it at the 1998 Linux Kongress. That wasn't received well, and resulted in the kind of spat that is typical of the open source community. People were young and tempers were hot.

Well, in cases like this, the only solution is to go at it yourself, and that's what happened. It took several false starts, but on the last day of May 1999, Matthias Elter and Michael Koch started KImageShop: read the mail, because it's quite funny how we did and didn't follow the original vision (KOM was a Corba-like thing, and if you have never heard of Corba, that's probably because Corba was a terrible idea.).

Development started, and believe it or not, there's still some actual code dating back to then in Krita's codebase, though most of the remaining code is opening and closing brackets.

And then development stopped, because, well, doing a proper image manipulation application isn't easy or quick work. And then it started again, and stopped again, and started again. There were several maintainers before I was looking for a nice, performant codebase for a painting application in 2003. I didn't know C++; but I had written the first book on using Python and Qt together.

Krita had been rewritten to the point where it didn't even have a paint tool, so that was the first thing I wanted to have. That was not easy!

But... Being open about it not being easy meant people got interested, and we started gaining contributors. And so, in 2004, we had a small team of enthusiastic people. A lot happened in that year; Camilla Boemann rewrote the core of Krita so we had autosizing layers, Adrian Page wrote an OpenGL based backend, Cyrille Berger added the first inklings of plugins and scripting. Our approach was still pretty technical, though, and we didn't manage to make a release.

It was only in 2005 that we released Krita as part of KOffice 1.4. Still very immature, but everyone agreed that it was promising, and we got nice reviews in some Linux magazines -- that was still a thing in 2005.

Then came 2006. And Krita 1.5 was released with support for color managed CMYK. Krita 1.5 also had the short-lived real color mixing watercolor layer feature, but that was too complex to maintain. And in the same year, we released Krita 1.6: Linux Journal called it State of the Art. We thought it was a pretty mature release, but artists who gave us feedback still found it lacking a lot.

And then disaster struck. Qt3 reached end-of-life, and Qt4 was released. The porting effort was huge and took ages, also because we, foolishly, decided to rewrite a lot of the 1.x code to make it possible to share components between KOffice applications. The rewrite took all of 2007, 2008 and half of 2009.

In the meantime, when we were desperately trying to fix all the bugs the porting and rewrite were introducing, we held our first fundraiser: that was to get Wacom tablets for testing Krita with, complete with art pens. I am still using the Wacom Intuos 3 we got way back then!

In 2009, we then released Krita 2.0. It was not really usable, but it was important for us to have something out that we could get people to test. Krita 2.1 was also released in 2009. We also got our first sponsored developer, Lukáš Tvrdý, whose task specifically was to fix all bugs. Later on, he also improved the performance of Krita's brushes.

As Krita gained recognition, we got more and more feedback, and in 2010, we decided to have a big sprint in Deventer where we were going to determine what we wanted Krita to be for our users. A Photoshop clone? A GIMP clone? A Corel Painter Clone? Or something that was itself. Who were we making Krita for?

The answer is true to today: we are making Krita for digital artists who are making art, mostly from scratch. Painting with Krita should be fun for artists of all kinds, all over the world.

But it would be some time before we'd reach that goal. 2010 saw Krita 2.2 and Krita 2.3: we thought that Krita 2.3 was ready for artists, but it was only with Krita 2.4 and 2.5 in 2012 that Krita really became pretty good! In fact, we had a laser-precise focus: for some years our rallying call was “Make Krita usable for David Revoy!” – partly silly, but also partly serious. We spent time during dev sprints observing artists and allowing them to live comment on what they liked and didn’t like, without the observing developers being allowed to open their mouths, wether in rebuttal or to help the artist out.

In the meantime, I had created the Krita Foundation so we could do fund-raisers to sponsor full-time developers. The first developer we sponsored was Dmitry Kazakov, who is still the lead developer for Krita.

Back then, Krita was still part of KDE's office suite, but it was called Calligra now, because of an interminable conflict with just one KOffice developer, the KWord maintainer. All that energy spent on that conflict could have gone into development, it was a huge waste. From the Calligra days onwards, development went much smoother. Nokia was now involved with Calligra's development, and the resulting improvement in the central libraries all applications used also helped improve Krita, though, conversely, the complexity needed to support a very diverse set of applications is still burdening us today.

Years went by. 2013 was completely uneventful. We made our releases (2.6, 2.7), did our fund-raisers, added features (like animation support), created a version of Krita with a special user interface for touch/tablet users (sponsored by Intel: we still have a great relationship with Intel, our main development fund sponsor). It was great to see the art people were creating, great to get feedback from users and just plain fun to tackle development.

In 2014 we ported Krita to Windows, also because of the touch/tablet version of Krita. And we released eleven versions of Krita 2.9, which was really a very fine release.

Also in 2014, we had our first Kickstarter campaign. Kickstarter was new and fresh back then, and it was really exciting. We got nearly 700 people to sponsor Krita! And we ported Krita to MacOS. For some time we would do a Kickstarter campaign every year, and they were fun both for us and for our developers, we'd set stretch goals and let people vote on what they wanted us to work on.

I still had a day job back then, so it was all work done in the evenings and weekends, and on the train during my commute.

We also started porting Krita, again, this time to Qt5. That wasn't as hard as the port from Qt3 to Qt4, but we lost support for the tablet version of Krita because Qt5 made it impossible to properly integrate our OpenGL based canvas in the touch version of Qt5's libraries. We spent months and quite a bit of money on that, but it was no-go.

Then I broke my shoulder and lost my day job, with Blue Systems, and suddenly the Krita Foundation needed to pay me, too. Fortunately, we found a sponsor for the port to Qt5, and that was my first sponsored project.

In 2016, we released Krita 3.0 -- it wasn't as good as Krita 2.9, but thankfully we still remembered the pain we had when doing a rewrite combined with a port, so we simply did the port first, and didn't combine it with a huge rewrite. This had animation!

We also released our first and last paper artbook. A huge amount of work for me, which already started in 2015 and in the end, a huge money sink, too.

We worked on improved versions of Krita 3.0 all through 2016 and 2017. 2018 rolled by, and we released Krita 4.0, with the results of Kickstarter-sponsored work. Though not all of it, because in 2017, I was preoccupied with the Great Tax Disaster. The Dutch tax office wanted us to pay tens of thousands of euros in VAT for the work Dmitry had done; that's when we hired a proper accountant instead of a small business administration office in a local town.

When we went public with the problems, donations streamed in and PIA made a huge donation: they basically covered the bill.

To avoid having this happen again, I brought all commercial activities into a separate one-person company. That became even more important, because in 2017, we put Krita in the Windows Store. That was the second store, after we put Krita on the Steam Store in 2014. Since then, we have released Krita on Epic Store, the Google Play Store and now even on the Apple MacOS Store.

Time went on, and in 2018, we released Krita 4.1, in 2019 4.2, in 2020 Krita 4.3 and 4.4. Reasonably quiet years of active development, growing user base and popularity. More and more sponsored developers joined in, and Krita made a lot of progress.

Although the Krita YouTube channel already existed, in 2019, we asked Ramon Miranda to work on regular videos for our channel:

By now we've built up quite a list of impressive tutorials of all kinds, teaching everything from digital painting itself to creating brush presets!

And then development slowed down. In 2020, the effects of Covid19 became more and more clear. We couldn't have sprints anymore, so no hyper-productive in-person development sessions anymore. Team members got sick, for some, really sick. Long Covid has crashed my own productivity: there are many days when I can do nothing but lie down in a darkened room.

By 2021, even though we hadn't had to port Krita to a new version of Krita, we still decided to change vector layers from ODG to SVG, which made Krita files incompatible between versions 4 and 5. A major change in file format, in other words. We're still working on new versions of Krita 5: 5.1 in 2022, 5.2 in 2023.

The future promises a very nice Krita 5.3!

And also, groan, a Krita 6.0 because we have started porting Krita to Qt6. And that's no fun, because Qt6 is again a huge change in what Qt offers and allows.

And that was 25 years of working on something I started dabbling in because I wanted to draw a map for a fantasy novel on my laptop!

Join the Development Fund with a monthly donation. Or make a one-time donation here.

The diffoscope maintainers are pleased to announce the release of diffoscope version 269. This version includes the following changes:

[ Chris Lamb ] * Allow Debian testing continuous integration builds to fail right now. [ Sergei Trofimovich ] * Amend 7zip version test for older versions that include the "[64]" string. (Closes: reproducible-builds/diffoscope#376)

You find out more by visiting the project homepage.