One of the most difficult choices to make when starting any new software project is that of the programming language and framework your team will use to create it. Should you stick with Qt because it’s the best tool for the job? Should you switch to something that uses web-based technology or is designed explicitly for mobile? Is Python a better choice to integrate in machine-learning capabilities?

Determining the right framework can be very difficult. Web resources often provide conflicting guidance or are subjectively based on a single developer’s perspective. Rarely does anyone create a substantial program in multiple frameworks that would allow a true comparison; creating a completely duplicate program of any complexity is very difficult and time consuming. It’s not surprising then that developers often follow the course of least resistance. Without a clear reason to switch, they default to language and framework of their previous project, reusing software that is already familiar.

Since the choice of a software stack is so important to guiding the project’s future course, it’s worth treating initial software selection as a strategic decision rather than the unconscious assumption that it can sometimes be. We have certainly done a good deal of Qt development and believe it’s a great tool. However, it’s not the only tool in the toolbox. In fact, there are occasions where it’s not a great fit.

When selecting a software stack for your project, there are 8 factors we recommend that you take into consideration:

1. Existing Codebase
2. Skills and Availability
3. The Target Platform
4. User Interface Requirements
5. Remote Access Requirements
6. Vertical Markets
7. Tool Interest and Longevity
8. Business Strategy

1. Existing Codebase

How much code do you already have? Is it cleanly factored, well documented, and can it be easily reused? Existing development is a consideration that can often overwhelm other decisions. Just remember that if you have a lot of spaghetti code that can’t easily be reused, it shouldn’t carry the same weight as solid, reliable, and modular code. Qt and C++ is not exempt from this consideration; you can inherit terrible code written in any language. Don’t let an existing legacy hinder you from making a clean break to a newer, better approach.

On the other hand, existing codebases carry a lot of knowledge and experience with them. This is often not encoded in documentation or comments but is the result of maturation over a long period of time and the accumulation of many decisions, workarounds, and fixes. Starting from scratch with a new framework or programming language carries the risk of repeating mistakes from the past. As ever, weighing these aspects is not a black or white decision and requires nuanced and careful consideration.

2. Skills and Availability

The talent pool for expert programmers in a particular framework, language, or domain can be a significant factor when deciding on tools. This is especially true for a language as powerful and nuanced as C++. We’ve found, throughout our years of training developers from diverse backgrounds, that Qt tends to tame the complexity of C++ and enables programmers of many levels to be productive. The ability to make developers of different skill levels effective contributors comes from Qt’s cleanly-structured design and complete library, along with QML. Due to its similarities to JavaScript, QML makes user interface development dramatically simpler and closer to web-based development. Even with this acknowledgement, it still remains hard to recruit high-quality talent that is able to tackle the challenging areas of Qt and C++: optimizing, modifying plumbing, or extending and customizing. Outside of Qt, it is easier to fill jobs for web-based technologies. If your project primarily sticks to the basics, going outside of Qt could be of benefit. However, if you need to dig under the hood of your web-based framework, you may be in the same situation. Excellent people are rare, regardless of the language. The importance of talent pool and language choice will vary, depending on your industry, locality, and ability to compete on salaries and other benefits.

3. The Target Platform

Since most tools shine in some environments but not in others, the platform that your application targets is a major consideration. One of Qt’s strengths is building cross-platform applications. However, while it provides an acceptable UI for all platforms, it won’t be fine-tuned for each platform. If you are only building mobile apps, for example, you may want to consider a framework that specializes in cross-platform mobile development, like React Native or Flutter. Similarly, if you’re only targeting one of the two mobile environments, Apple iOS or Google Android, you may want to investigate the best tool for each environment – Swift or Kotlin, for example. Moreover, if your app has a desktop and web-based interface, it may make sense to use an HTML5-based tool like Electron that can more easily cross the gap between the two environments. Finally, the size of the processor can introduce serious constraints. While an ARM microprocessor can run nearly any modern toolchain, microcontrollers have a number of constraints and can be more limiting in your language and framework choices. While Qt does offer a trimmed down version to target microcontrollers, it will require a big focus on performance to shoehorn your application into a small micro. You’re probably better off picking a smaller lighter-weight framework that’s designed to go into small applications like Crank Storyboard, if your main focus is on the low end of the hardware performance spectrum.

4. User Interface Requirements

What does your application need to display? Simple text? Responsive mobile pages? 3D graphics? Complex visualizations? The sophistication of your graphical needs can be a big driver in selecting an appropriate programming environment. If you can live with console input and text output, nearly anything will do. If, however, you’re building a lot of sophisticated graphs, you may want to consider a language with extensive data visualization libraries like R, Julia, or Python. Then again, if you’re looking to do 3D manipulation or integrating 3D graphics into 2D UIs, that’s an area where Qt really shines; web-based technologies will likely struggle in these types of applications. Because of its ability to create software closer to the metal, Qt also does very well in areas where data management is paramount, such as scientific applications, high-throughput measurement systems, or real-time data collection.

5. Remote Access Requirements

If remote access is required, web-based solutions can often be a natural choice. The upside is that development will naturally use a browser interface, making remote browser access identical to local access. However, this benefit is also a downside since web technologies are constrained to the browser, making it difficult to create an optimal desktop experience. It’s possible to create a tailored desktop and remote UI with Qt, as it has become very versatile in being able to support remote and browser-based UIs through WebAssembly or WebGL. The requirements of remote access should be considered. Will it be used for control more frequently than local access? Is it for maintenance support? Is it for training, oversight, or administration? Based on the frequency of use, UI needs, and flexibility, you can make a more detailed assessment on whether Qt or web-based tools are better for your remote access requirements.

6. Vertical Markets

The market for your product may impact the toolkit you want to use. Sometimes a particular tool chain has a strong foothold in a particular area like automotive or point-of-sale applications. Having access to open source libraries, third-party expert consultants, pre-existing software stacks, and third-party offerings can help shortcut the development process. Development using uncommon tools in one of those areas can mean that your team will need to reinvent the wheel for common protocols or hardware devices.

In some vertical markets, the application will need to directly access hardware. If all hardware components are off-the-shelf and have properly encapsulated drivers, then this won’t be a problem, regardless of language. However, custom hardware is often found in industrial or robotics designs, making them challenging to use in programming environments that use a virtual machine such as Java or web-based technologies.

The final constraint that vertical markets may impose are software lifecycle, development, and quality standards that must be met for regulation and safety reasons. You’ll want to pick a language and toolset that is familiar to certifying agencies and doesn’t introduce any problematic concepts like unprompted garbage collection. While the specifics of each standard differ, similar characteristics will apply to medical devices that need IEC 62304 certification, automotive systems that comply to ISO 26262, and industrial systems that require IEC 61508 compliance.

7. Tool Interest and Longevity

Is the language you want to use “hot” in the development community? A tool’s popularity may tell you how easy it will be to have programmers join your team. “New and exciting” needs to be balanced with stability; don’t pick something that’s so new it is undergoing continual refinement and requires changes throughout the code base on each subsequent tool release.

Another measure of developer interest is the community size. If your tool of choice has a large and active forum on Stack Overflow or Reddit, and ongoing projects on GitHub, you’ll know there are plenty of programmers interested and contributing in that space. Newer tools may have a lot of interest but fewer practitioners and smaller online communities.

Another measure of desirability is lifespan. Languages and tools that have been around a long time have proven their worth and have lived beyond obsolescence. Finally, is the software easy to maintain? The more maintainable the code base, the longer the productive lifespan – you’ll be able to keep the code fresh and reusable across multiple projects.

While maintainability is often as much about programming style and documentation standards, tool characteristics can help or hurt maintainability too. Development environments that contain a hodgepodge of techniques and paradigms make it very difficult for a developer to know where and how to fix a bug or extend functionality without breaking existing code. Tools built on web standards can be difficult to modify with a combination of HTML5, JS, CSS, and custom JavaScript frameworks. However, Qt applications can also suffer from this problem due to the mix of C++, QML, and Qt libraries. Finding tools that can easily integrate unit testing into the development process can help maintainability and should be a priority for modern development.

8. Business Strategy

Often, development tool choices are not considered by anyone outside of the engineering department. However, with the additional impacts that software tool choice imposes on hiring talent, available consultants, the cost and availability of third-party libraries, codebase longevity, and product stability, it is wise to make these strategic decisions with input from the whole team. Certainly, you want your programmers to feel the choice of development tool is a good technical fit, however, engineers may not be as aware of all the other downstream considerations – just as management, HR, leadership, or other corporate areas may not fully understand the technical aspects of software selection. Bringing all parties to the table to create an open dialog for selecting critical software tooling will ensure that such decisions not only help the immediate product development but also support the company’s longer-term considerations.

Summary

As you can see, there’s a lot to consider when making your initial software selection. While Qt makes a lot of sense for a good number of projects, it’s not the only kid on the block. We have lots of experience helping customers evaluate whether Qt is the right choice for a project. We know all about the framework, its license options, its strengths and weaknesses, and much about other possible choices. We have seen people pick Qt and succeed but we’ve also seen people have problems. We can help you structure your decision-making process around the software options that might be the best fit for you and give you the necessary guidance to head in that direction.

The post Is Qt Right for Your Project? appeared first on KDAB.

I’ve started to worry that mentioning really small weird bugfixes week after week gives the impression that KDE software is buggier than it really is. The truth is that all responsibly maintained projects are constantly landing these kinds of maintenance bugfixes, so it’s probably a bit misleading to be talking about them all the time.

Instead, I’m going to try only mentioning the big, consequential bugfixes: the ones for bugs marked HI or VHI priority, that have with multiple duplicates, that are really significant in effect, etc. Hopefully this should improve the signal-to-noise ratio in the blog posts.

I’ll still mention new features and significant user interface improvements, of course.

Let me know what you think!

Purpose

The major purpose of the mid-term evaluation during the Google Summer of Code program is to ensure the contributor’s progress for their committed timeline for both coding and communication.

My progress till mid-term

During the coding period, I started with “ten’s complement,” and after a thorough discussion among the mentors, we decided to divide the activity into three sub-activities. The details for all the sub-activities can be found here.
At the time of mid-term evaluation, all these three sub-activities were half-functional, the improvements were left, but the basic functioning and the dataset for level 1 of all the activities were present. Although, I was one week late to my timeline, which I proposed. I planned to complete “ten’s complement” by mid-term. I’ve added the to-do for this activity under the task. (here)
But one thing I realized, and my mentors told me too, is that the small things require more time. One of the reasons why I was unable to complete the activity before mid-term was the incorrect estimation of time and work. And initially, the college was going to open a month later, but it started in the month of July itself. Due to this, I couldn’t provide much time for a few days.

Improving myself

After the mid-term evaluation, I prepared another timeline consisting of the remaining tasks and time left, as advised by the mentors. An updated timeline would help both of us, mentors and me. Through this, my progress during the remaining weeks can be measured. I try to have daily interaction with the mentors, and I’ll be publishing more blogs to increase communication with the whole community as well.
Also, I am allocating more time to the remaining task and increasing the contributing pace to catch up to the timeline and complete all the tasks before the final evaluation.

Krita 5.1 is nearing its release, and working on that has claimed a lot of our attention. Not that there haven’t been other things happening!

And not just bug reports, though with on average a hundred new bug reports a month, that’s taking a lot of work as well. Even if the bug report is more a cry for user support than a real bug report, it will take time to evaluate and close. Say, on average, half an hour of engagement with the report and reporter before the real work starts, just triaging these bugs takes 50 hours a month!

At the same time, every artist who starts using Krita will have ideas that must be implemented, so there is a never ending stream of feature requests, often of the form “Photoshop has X, it’s incredible that Krita still hasn’t X, too!”. That is not only discouraging, it is also a big timesink. And since there’s so much of it, it’s not possible for the Krita developers to meaningfully engage with all the ideas artists bring to the table.

Working in response to bugs and feature requests is also reactive: it prevents the Krita team from developing a vision, and then using that vision to develop and improve Krita.

And that’s just frustrating. Some of us have been working on Krita for more than a decade. Some for nearly two decades, in fact, and we know what we want Krita to be.

So earlier this year, we sat down together, every developer who could make the virtual meeting to discuss what fun stuff we wanted to work on after all the pandemic depression, resource system rewrite and bug fixing. First, Wolthera and Halla sat down together to investigate our closest competitor. Which application is that?

If you guessed Photoshop, you guessed wrong. Honestly, we think Krita’s painting tools are better than Photoshop’s. Some people might disagree, will disagree — just like there are always people who want better performance, always.

It’s also not Affinity Photo. Or Corel Painter.

We think that Clip Studio is much more of a real competitor: that is also an application created for working artists who need to be productive to earn money. Corel Painter’s niche nowadays is tracing wedding photographs in a painterly style, Affinity doesn’t have a strong brush enging at all, and Photoshop is copying our features, instead of the other way around.

Here is the first document we created where we talk about what we think is lacking in Krita compared to Clip Studio: let’s call it a “competitor analysis”.

Then we met up, virtually, of course, and discussed what we wanted to do. That also resulted in a document you can browse at your leisure. This actually has names with the topics!

But let’s pick out some things. Let’s start with text. People complain a lot about Krita’s text tool, though in reality, apart from doing the editing in a popup instead of on the canvas, it was already more powerful than Clip Studio’s. Now there are two parts to text: the actual text object that renders text on the canvas, and the tool, that allows you to enter text and change text properties like the font.

Wolthera has completely rewritten the rendering engine for the text object. It no longer uses Qt’s text layout classes, since those were too limited. (Apparently, they were written for rendering Qt’s help files, though that might be a retcon, since I remember that they were presented as a full-blown layout engine.) That part is done! It will be merged right after the Krita 5.1 release, because it needs new dependencies, like libraqm.

Note: changing the text tool to work on text on-canvas is something we want to work on, but out of scope for this project!

Emmet and Eoin have completely rewritten the audio part of Krita’s animation support. We used to use QMultiMedia, but that library has a very strange API and never worked all that well; apparently its intention was simply for playing sounds in mobile games. Or something. This has taken months of work, of course! But right now, the first test build, Linux only, is ready! Here is their vision for Animation in Krita.

Back in 2007, it seemed a good idea to build the brush preset editor around the user interface objects that change the preset settings. Yes, we were young and foolish. Dmitry is working on refactoring that extremely complicated and error prone architecture using a library called Lager. Dmitry is, of course, also always working on improving Krita’s performance and memory handling, and chunks of that are already in Krita 5.1!

Since there are many other places in Krita where we did the same thing — keep the state of something in the user interface, like in the tools, this opens up some exciting possibilities, like tool presets, or even multiple tool instances. That’s something Halla has wanted to work on for some time. But she’s also doing the admin work of maintaining a big free software project, so whether she’ll get down to it… That’s an open question.

Sharaf, our Android maintainer, is looking into bringing back the mobile-friendly UX we used to have for Krita 4. Or rather, rewrite it from scratch with modern QML and Kirigami. He has started with the welcome page. Right now, Krita’s welcome page is intentionally a bit drab and understated, but we want to do much more with it: show off featured artwork from Krita Artists (and just remember how new that website is, and how central a part of the Krita community it has become), links to tutorials and videos, news from this website, recent projects — or maybe a proper project organizer for all projects.

Agata is working on painting assistants. Krita’s painting assistants have always been a really powerful tool marred by by a relatively poor usability and a really confusing codebase. Already three different merge requests have been merged into what is going to become Krita 5.2, and more is to come! She was also really helped out by the community at Krita Artists.

Also already merged is AmySpark’s brand new jpeg-xl file format plugin. This is a format that supports both animation as well as still images with very good lossless compression.

And, of course, all this work doesn’t mean we’re neglecting stability, performance or even just keeping up with new compilers, updated dependencies or smaller features. We solved over 500 bugs in the past half year… And this is just what the sponsored developers are doing and planning to do: there are also many volunteer developers making awesome contributions to Krita.

Freya has improved the display of layers in the layer box so it optionally shows blending mode and opacity, added single direction wraparound mode and zoom fit with margins.

Deif Lou‘s contributions are maybe too many too enumerate… Ranging from improving the fill tool so it can use label colors, to improving the fill tool’s performance, to new filters — to entire new tools, like the Enclose and Fill tool.

Alvin has worked on updating Krita to use the latest version of the Angle wrapper that sits between our OpenGL code and the Windows Direct3D display driver layer — as well as a host of other things.

And there’s more… But this is enough for today. Please support the Krita Foundation so we can continue our work and make Krita a great application for every digital artist! We have over 80,000 downloads a month — and only about 4000 euros in donations, and that’s the sum of the Krita dev fund and one-off donations!

Krita is a free and open source project. Please consider supporting the project by joining the Krita Dev Fund, donations or by buying training videos! With your support, we can keep the core team working on Krita full-time.

The post What the Krita Developers Are Up To, Part II appeared first on Krita.

Are you the C++ experienced reader to solve the following challenge?

Given a class C (edit: covered by binary compatibility needs) with the overloaded methods foo() and foo(A a):

    class C
    {
    public:
        void foo();
        void foo(A a);
    };

Now you want to add an overload, to serve further use-cases as requested by API consumers, and going for another overload matches your API guidelines :

        void foo(B b);

But there is existing consumer code, making use of C++17, which calls

    C c;
    c.foo({});

So the new overload will not be source-compatible and break existing code, due to the ambiguity whether {} should be turned into an instance of A or B.

What could be done about this?

The goals here would be:

1. to enable API consumers to write code which works as if there are the two old and the one new overloads declared
2. any calls using the {} expression as argument are resolved to a method which emits a compiler warning to avoid that ambiguous argument and which on any next compatibility breaking occasion can be simply removed

While asking around, some approaches have been proposed, but so far none could satisfy the second goal, catching existing ambiguous argument expressions to hint API consumers to adapt them.

Would you have an idea?

Edit: Note that we cannot change A or B (might be types/classes from elsewhere), and only can add new API to C, due to binary compatibility needs.

Edit: On a second thought, similar problems also exist before C++17 already when an argument has a type which can be implicitly converted both to A and B, by implicit constructors or type operator methods.

We continue chewing through bugs this week, and now I’m mentioning the “very high priority” Plasma bugs in addition to the “15 minute bugs” which are slightly lower priority. Plasma developers reading along are encouraged to prioritize the very high priority bugs.

Very high priority Plasma Bugs Resolved

Current number of bugs: 26, down from 29. 3 resolved:

System Monitor widgets no longer reset various settings to their default values after the system is restarted (Alexander Lohnau, Plasma 5.25.5)

It’s once again possible to select windows on other screens using the Present Windows and Overview effects (Marco Martin, Plasma 5.26)

Application Launcher widgets that you activate by pressing the Meta key no longer require that the Alt+F1 shortcut to be set, which should dramatically reduce instances where you press the Meta key and nothing happens. Also, now when you have more than one launcher that wants to open with the Meta key, it will open on whatever screen is considered active by KWin (David Redondo, Plasma 5.26)

Current list of bugs

15-Minute Plasma Bugs Resolved

Current number of bugs: 50, down from 51. 1 added and 2 resolved:

Kickoff no longer strangely pre-selects search results list items that aren’t the first ones after previously having selected the item in that position using the cursor the last time you searched for something (me: Nate Graham, Plasma 5.25.5)

Hovering the cursor over an item in Kickoff no longer repeatedly re-selects it if you use the keyboard to select something else (me: Nate Graham, Plasma 5.25.5)

Current list of bugs

New Features

You can now configure a keyboard shortcut to activate Present Windows showing only the windows from the current app that are on the current desktop (Arjen Hiemstra, Plasma 5.26)

User Interface Improvements

It’s now much easier to initially set up a folder for sharing with Samba, because the wizard now gives you detailed and actionable error messages (me: Nate Graham, kdenetwork-filesharing 22.12):

Wallpapers in the slideshow wallpaper grid are no longer selectable, since this isn’t a state that makes sense for them (Jin Liu, Plasma 5.25.4)

The Timer Plasma widget has received a big overhaul that fixes most of the open bugs and improves the UI to add a clickable start/stop button (Fushan Wen, Plasma 5.26):

Searching for widgets in the Widget Explorer now also matches their keywords, providing another way to find what you’re looking for (Alexander Lohnau, Plasma 5.26)

Menu shortcuts are now displayed in a subdued gray color, visually de-emphasizing them compared to the menu items’ text (Jan Blackquill, Plasma 5.26):

The Breeze icon theme now includes icons for Windows DLLs (Alexander Wilms, Frameworks 5.97)

Other Bugfixes & Performance Improvements

In Okular, it’s no longer possible to drag pop-up notes off the screen (Nikola Nikolic, Okular 22.12)

The first time KRunner is opened, it no longer oddly slides up from nowhere; now it always slides down from whatever’s above it as expected (Kai Uwe Broulik, Plasma 5.24.7)

In the Plasma Wayland session, monitors no longer sometimes lose their names and become unable to be set as the primary one (Xaver Hugl, Plasma 5.24.7)

The Breeze style once again respects the “Small Icons” size you can set in System Settings (Alexander Kernozhitsky, Plasma 5.25.5)

The KScreen screen handling service is now more lenient about detecting screens as unique, which should fix various weird screen-and-desktop-layout-related problems caused by hotplugging screens and docks where both the screen ID and connector ID change during the hotplug (Harald Sitter, Plasma 5.26)

Setting the language in System Settings now updates the standard FreeDesktop org.freedesktop.Accounts.User.Language value which is used by Flatpak apps and lots of 3rd-party apps in general, so they should now use your preferred language as well (Han Young, Plasma 5.26)

…And everything else

This blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, check out our 15-Minute Bug Initiative. Working on these issues makes a big difference quickly!

Otherwise, have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

Hello and welcome to my second GSOC update! I think I these last few weeks have been really productive in fixing some issues with my code and getting some direction in the next steps for my project. If you remember last time we had just figured out how to get the SVG option to appear in Krita so we can start testing out saving a test SVG file. We were getting a few errors actually trying to use that option and save the file but those should be all fixed now.

Firstly we were getting a Permission denied: Krita is not allowed to read the file. error when actually trying to save with SVG. At first I thought this was due to how I was trying to use the svgWriter class. The svgWriter assumes that we are only getting to export one layer (the current one) so I thought by trying to save in the context of the whole file, that was tripping it up somehow. After doing some investigation and tracing all the steps in the code this didn’t seem to be the issue.

Hmmmm alright so since my intitial assumption was incorrect lets try starting from the beginning with whats actually producing this error? Well turns out it is from the fail of the check !io->isReadable(). Is this the correct way to check if a file is readable? Well comparing to the check used in an example commit (from amyspark) it seems to use a different method to check if the file is writeable KIS_SAFE_ASSERT_RECOVER_RETURN_VALUE(io->isWritable(), ImportExportCodes::NoAccessToWrite);. Thats interesting, lets try commenting our check and see if the file gets created or Krita crashes, either way we’ll get some valuable information. After trying that it the file gets created! An empty file but thats exactly what we expected. Now we’ll replace my incorrect check with the right one.

Next step is get the boilerplate SVG file context written to our empty file. After some investigation it seems like all of the SVG writer code does get executed properly and it does try to write to the file but something is missing. Even when passing the same layer contents to svgWriter it still doesn’t write to that file. Well to make a long story short it turns out you have to actually pass your IO device if you want to actually write to it/use it. After changing my code to pass the current QIODevice it was properly writing to the file!

After figuring out those issues I had a discussion with Wolthera around the next steps for my project. We talked about how I was going to traverse the layers of the Krita file as I was writing to my SVG file. At first I thinking about writing entirely new code, reading the document, and going through layer by layer but then Wolthera introduced me to the intended way to do this process. Namely, by making an implementation for the KisNodeVisitor class that would handle traversing the layers. Instead of trying to re-invent the wheel I can use the standard way Krita accesses file. I started working on that implementation late last week so I’m still figuring out all the details on how it works. Hopefully I’ll be able to talk about my making that next week.

Thanks for tuning in!

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

How far can you go by train in 5h?

Tags: tech, train, map

Very cool map. Definitely useful tool to push for more train use.

https://chronotrains-eu.vercel.app/

Remote attestation is coming back. How much freedom will it take? – Gabriel Sieben

Tags: tech, microsoft, vendor-lockin, surveillance, security

Palladium is coming back and it’s not good news in my opinion.

https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/

How Tor is fighting—and beating—Russian censorship | Ars Technica

Tags: tech, tor, security, censorship

It’s nice to see Tor is still winning even in difficult countries.

https://arstechnica.com/information-technology/2022/07/how-tor-is-fighting-and-beating-russian-censorship/

The OG Social Network: Other People’s Websites - Jim Nielsen’s Blog

Tags: tech, google, search, attention-economy, advertisement, open-access, web

The paradox of how walled gardens could kill search engines in the end. I’m not too concerned for Google in practice though, it’s been a long time since it’s an ad agency and not a search engine, and they’ll always have something to advertise…

https://blog.jim-nielsen.com/2022/other-peoples-websites/

Use One Big Server - Speculative Branches

Tags: tech, infrastructure, cloud, services

This is definitely a good musing on when not to go for “cloudy architectures”. Most often people don’t really need it, this needs to be properly thought out for each project. There are costs involved which you might not make sense to pay for in your context.

https://specbranch.com/posts/one-big-server/

The Slotted Counter Pattern

Tags: tech, design, databases

Nice little database pattern to avoid row contention with counters.

https://planetscale.com/blog/the-slotted-counter-pattern

Manifold

Tags: tech, java

This looks like an interesting set of extensions for Java projects. Unsure if it’s been properly battle tested yet. Likely need that before being really advisable.

http://manifold.systems/

Unlocking type-safety superpowers in Typescript with nominal and refinement types

Tags: tech, typescript, type-systems

That’s an intersecting Typescript pattern to get to nominal and refinement types despite the fact they lack from the language.

https://zackoverflow.dev/writing/nominal-and-refinement-types-typescript

Bye for now!

While testing my merge request, Tobias spotted that NeoChat was making multiple requests to the /hierarchy API endpoint. The requests were actually being spammed to the server.

So I was suggested to separate the Space hierarchy caching functionality to a separate class itself.

The work was mostly about refactoring. Code was already existing in a different class. I moved it to the new SpaceHierarchyCache class and edited it to glue in properly.

getRoomListForSpace() in SpaceHierarchyCache accepts a space id, and returns a list of rooms id that belong to the space. This function is exposed in QML and used to populate SortFilterRoomListModel:: m_activeSpaceRooms whenever user clicks a Space icon.

Rest of the implementation is mostly similar to what was earlier scattered through SortFilterRoomListModel.

The code is currently on a separate branch on my fork so that my mentors can check if it looks and works right. If they say its fine, I'll add the code to my open merge request.

PS. Its my birthday today :)