API design

Qwen 3.8 is out since Friday, 17 of August. I am running it on my own server since Saturday. I am running Q4 quants from unsloth .

So far it feels like a step up from Qwen 3.6 27B, which sometimes had problems figuring stuff in my project that I am developing almost entirely using models - just as a test of how far I can push LLMs in agentic coding - mostly local models, I must add. Qwen 3.8 seems like having no problem at all.

I am using pyLoad download manager for quite some time now. Previously when I was running windows server I was using JDownloader. I think it was better in few things, for example it was able to automatically name a package based on the name of the file from the link. So if I would be trying to download https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.4.0-amd64-netinst.iso, it would automatically name a package ‘debian-13.4.0-amd64-netinst.iso’. Folder with downloaded file would be named the same too. Much more convenient. If I would drop multiple links for the same file it would be downloading them in parallel, downloading them much quicker. Though with current speeds in average home maybe this is not necessary anymore. It had better UI, in my opinion, but maybe I was more accustomed to windows desktop then; certainly it was better to have single view instead of 3 views like in pyLoad:

Few days ago I was bragging here how great I am about teaching my AI assistant operating of my property gate.

Today I noticed that it no longer works. I asked it again to:

Open the gate

while wondering why am I actually doing it since I can just press the button on my phone… but well people are sometimes radicoulous like that.

Anyway I wrote message as above and I got answer like below:

What is query language? SQL is Structured Query Language and you use it to query your database for data you are interested in. It does not have to do anything with your API. If you ever were working with big XML files you probably used XQuery or XPath, query languages designed to XML for data. There are specialized languages that are designed to work with APIs to query them for data. For example, you probably heard about GraphQL or even used it when you were working with some API.

Ninject is very simple and in the same time powerful IoC container. I used it in few project and had very little or none problems. Most of the time getting instances from Ninject kernel requires simple line with binding expression, or even this is sometime unnecessary if type is self bind able (i.e. if it is concrete class with parameterless constructor). Little harder is getting Ninject to work with WCF. You cannot just bind interfaces types because proxies which implements them are created through .NET mechanism. Luckily WCF system is very flexible and mostly can be changed/extended with custom functionality.