The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,854 other subscribers

Symptomen van overprikkeling en hoe je dit kunt voorkomen

Posted by jpluimers on 2021/11/29

Via [Archive.is] Anne van de Beek💭 on Twitter: “Dit zijn een aantal mogelijke symptomen van #overprikkeling. Je leest er meer over in dit artikel van @PraktischAutism: https://t.co/viZAfz2GdE Welke klachten krijg jij als je overprikkeld bent? #autisme… https://t.co/D4SUGOsWDj”

[WayBack] Overprikkeling bij volwassenen met autisme – gastblog door Barbara de Leeuw – A-typist

  • Signaleren > welke signalen gaan bij jou vooraf aan overprikkeling?
  • Herkennen > het tijdig herkennen van die signalen, zodat preventief ingegrepen kan worden.
  • Doen! > wat kun je op zo’n moment doen en hoe pas je je dagelijks leven zo aan, dat je in mindere mate last van overprikkeling krijgt.

  1. Bijtijds rust nemen.
    Even uit de situatie stappen. Ga bijvoorbeeld een korte wandeling maken of verstop jezelf een tijdje op het toilet. Het gebruik van oordoppen kan in rumoerige situaties goed werken. Ook meditatie kan effectief zijn. In dat geval is het boek van Annelies Spek – “Mindfulness bij volwassenen met autisme” absoluut een aanrader.
  2. Pas je dagelijkse planning aan.
    Het hebben van een dagelijkse, doch niet rigide structuur brengt rust, duidelijkheid en regelmaat. Houd dus een dag- en weekplanning bij op een manier die jou het meest bevalt. Een agenda, een planbord en/of een bullet journal. Wissel elke activiteit af met “bijkomtijd”. Even rust alvorens de volgende activiteit te starten.
  3. Pas je woonomgeving aan.
    Teveel prikkels in huis werken averechts. Zorg dus dat alles een vaste plaats heeft, ruim alles direct op, zorg voor dozen en ordners om de losse spullen in op te ruimen en durf overtollige spullen weg te gooien. Neem hierin ook de eventuele kinderkamers mee. Ook zij zijn gebaat bij een opgeruimd huis. Zorg ervoor dat je huis je comfortzone wordt.
  4. Durf “NEE” te zeggen.
    “Nee” zeggen tegen je omgeving is vaak doodeng. Hoe zullen ze reageren? Natuurlijk, er zijn altijd mensen bij die het niet alleen niet kunnen, maar ook niet willen begrijpen. En als diezelfde mensen dan ook nog geen begrip op kunnen brengen, is dat beslist heel lastig en pijnlijk. Toch zijn die mensen vaak veruit in de minderheid. De meesten zullen begripvol reageren als je aangeeft waar je last van hebt en dat je daardoor bijvoorbeeld niet te lang op een verjaardagsfeest kunt blijven. Waar het hier vooral om gaat, is dat je een keuze durft te maken tussen die dingen die MOETEN en die dingen die je WILT. Sociale uitzonderingen daargelaten, zul je zien dat er heel veel situaties zijn die geen verplichting zijn. Ook niet als ze zo voelen. Jij wordt daar echt geen minder vriendelijk mens van.
  5. Leer assertief te zijn.
    Assertiviteit leert je om op een vriendelijke, doch daadkrachtige manier “nee” te zeggen. Op die manier kwets je niemand en zullen mensen eerder geneigd zijn begrip te tonen.
  6. Biedt een sociaal alternatief.
    Kun je niet naar die verjaardag? Biedt dan aan de jarige een keer te trakteren op een lunch. Hij/zij voelt zich niet vergeten, jullie hebben alle tijd om even bij te kletsen en jij kunt kiezen welke locatie jou de minste prikkels oplevert.

  1. Durf om duidelijkheid en voorspelbaarheid te vragen.
    Een mooie methodiek hiervoor is “Geef me de 5” van Colette de Bruin, waarmee je praktisch elke onduidelijkheid kunt wegnemen door ervoor te zorgen dat er invulling is op de punten Wie, Wat, Waar, Wanneer en Hoe.
  2. Zorgen om de ander.
    Het is mooi als je je inleeft in iemand anders zijn situatie of emoties, maar als dat betekent dat het jou daardoor belemmert, wordt het tijd om er iets aan te doen.
  3. Niet-helpende gedachten.
    Ook zo’n heikel punt waar veel mensen met autisme last van hebben. “Het kan niet, want….”. Nadeel hiervan is niet alleen het risico op overprikkeling, maar je kunt je dan ook ontzettend onbegrepen gaan voelen.

Her stuk bevat verder ook een aantal “Tips voor familie/vrienden, hulpverleners en werkgevers”.

Aanrader!

–jeroen

Read the rest of this entry »

Posted in About, Awareness, Personal | Leave a Comment »

Apple retrocomputing link clearance

Posted by jpluimers on 2021/11/29

For my archive:

–jeroen

Posted in 68k, Apple, Classic Macintosh, History, Macintosh SE/30, Power User | Leave a Comment »

Twitter: view tweets by people you enabled the “notification bell” for

Posted by jpluimers on 2021/11/26

This URL will usually bring you the list of “important” tweets (by people you have flagged to get notifications about):

https://twitter.com/i/timeline

Via: [Archive.isJeroen Pluimers on Twitter: “Ik kijk steeds vaker via twitter.com/i/timeline “

–jeroen

Read the rest of this entry »

Posted in Uncategorized | Leave a Comment »

Score-checklist klachten/eigenschappen/symptomen voor kwaliteit van leven

Posted by jpluimers on 2021/11/26

[WayBack] stomaatjelidy on Twitter: “@caseofdees @jpluimers Wmo dordrecht heeft zoiets” / Twitter

–jeroen

Posted in About, LifeHacker, Personal, Power User | Leave a Comment »

75 Funny Wifi Names (besides Disconnected and Access Denied)

Posted by jpluimers on 2021/11/26

[WayBack] 75 Funny Wifi Names (as I already run “Disconnected” and “Access Denied”).

Related blog posts:

–jeroen

Posted in Fun, Network-and-equipment, Power User, WiFi | Leave a Comment »

Some links on data bias

Posted by jpluimers on 2021/11/25

[Archive.is] NL_Wetenschap on Twitter: “Er zijn inderdaad veel manier waarop data gebiased kan zijn, zeker in dit soort contexten. Heel veel van dit soort oplossingen staan of vallen met hoe goed mensen zich er van bewust zijn dat data nooit een ‘gegeven’ is maar gemaakt wordt.” / Twitter

[Wayback/ThreadreaderApp]

Er zijn inderdaad veel manier waarop data gebiased kan zijn, zeker in dit soort contexten. Heel veel van dit soort oplossingen staan of vallen met hoe goed mensen zich er van bewust zijn dat data nooit een ‘gegeven’ is maar gemaakt wordt.https://twitter.com/jpluimers/status/1348550923958804480

Data is nooit een doorgeefluik van de werkelijkheid, we máken data. We kiezen ervoor om iets te tellen bijvoorbeeld, en maken keuzes in wat wel en niet meegenomen wordt. Tot op zekere hoogte is dat arbitrair (goede nieuws: daar kunnen we wel verantwoording over afleggen!). 
Met dat in het achterhoofd is een eerste stap om je sterk afvragen wat zegt deze data wel en vooral ook niet. En vervolgens: wat kunnen/mogen/willen we hier dan wel of niet mee? Wat betekenen deze keuzes voor gebruikers of burgers? 
Welke normen en waarden zitten er ‘verstopt’ in of achter de data? Op wie heeft de inzet van die data effect en in welke mate? 

Background reading:

–jeroen

Read the rest of this entry »

Posted in Development, Software Development, Systems Architecture | Leave a Comment »

What is “deleted” in an information system?

Posted by jpluimers on 2021/11/25

I have had quite a few discussions about data being “deleted” in information systems.

Often, data – despite GDPR – isn’t, or can’t be deleted for many reasons, especially when data is retained on backups, cloud storage is involved or data has been copied in other ways.

Many times, marking with a flag that data is deleted, is enough, but often it isn’t and then you need processes to track down all occurrences of the data and delete it permanently, which can be a tedious job.

Some more interesting thoughts are in this thread that triggered me:

Comment
byu/BlueMountainDace from discussion
inParlerWatch

Posted in Development, Software Development, Systems Architecture | Leave a Comment »

GitHub – TimeToogo/tunshell: Remote shell into ephemeral environments 🐚 🦀

Posted by jpluimers on 2021/11/25

Cool: [Wayback/Archive.is] GitHub – TimeToogo/tunshell: Remote shell into ephemeral environments 🐚 🦀

Via: [Archive.is] Jan Schaumann on Twitter: “This looks neat: on-demand remote shell into ephemeral environments, e.g. CI/CD pipeline container. Both sides fetch a client, use rendezvous server to negotiate session info, then establish connection or fall back to proxy through rendezvous. “

Read the rest of this entry »

Posted in Communications Development, Development, DevOps, HTTP, Infrastructure, Internet protocol suite, Power User, Software Development, TCP, WebSockets | Leave a Comment »

Writing desktop apps: use native tools, not web-tools

Posted by jpluimers on 2021/11/24

Despite the Electron framework, you might really want to consider writing desktop applications using native tools as it is extremely hard to write performant desktop applications otherwise.

It isn’t by coincidence that last year, Firefox by default makes the backspace key not go back to the previous web-page: it is still a problem in a truckload of interactive web applications, often even in web-based desktop applications:

I am not alone on this opinion:

In practice, “native” applications based on web-tools are notoriously hard to navigate by keyboard, which essential for swift operation.

I have filed a few bugs, and others many more on this, for example:

Also web-developers tend to love to introduce their own custom UX, like for a 6-digit numeric field, use 6 separate digit fields making it extremely hard to copy/paste numbers.

–jeroen
Read the rest of this entry »

Posted in Development, Software Development, Web Development, Windows Development | Leave a Comment »

OWASP top rated security “feature” A01:2021 – Broken Access Control

Posted by jpluimers on 2021/11/24

An important [Wayback/Archive] A01:2021 – Broken Access Control, in German, is a pre-amble for a future post about getting a feel how to counter the vulnerabilities that OWASP tracks and documents.

Basically remember that Broken Access Control is by far the most vulnerable feature in applications:

Broken Access Control war 2017 auf Platz 5 und ist jetzt Problem #1. 94 % der getesteten Anwendungen hatten irgendeine Form von defekter Zugangskontrolle. Der ehemalige #1 Dauerbrenner Injection ist nur noch auf Platz 3.

Basically the top 3 changed dramatically between 2017 and 2021. The new top-3 is below. Please get acquainted with it.

  1. [Wayback/Archive] A01 Broken Access Control – OWASP Top 10:2021

    Moving up from the fifth position, 94% of applications were tested for some form of broken access control with the average incidence rate of 3.81%, and has the most occurrences in the contributed dataset with over 318k. Notable Common Weakness Enumerations (CWEs) included are CWE-200: Exposure of Sensitive Information to an Unauthorized ActorCWE-201: Exposure of Sensitive Information Through Sent Data, and CWE-352: Cross-Site Request Forgery.

  2. [Wayback/Archive] A02 Cryptographic Failures – OWASP Top 10:2021
    Shifting up one position to #2, previously known as Sensitive Data Exposure, which is more of a broad symptom rather than a root cause, the focus is on failures related to cryptography (or lack thereof). Which often lead to exposure of sensitive data. Notable Common Weakness Enumerations (CWEs) included are CWE-259: Use of Hard-coded PasswordCWE-327: Broken or Risky Crypto Algorithm, and CWE-331 Insufficient Entropy .
  3. [Wayback/Archive] A03 Injection – OWASP Top 10:2021

    Injection slides down to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and 274k occurances. Notable Common Weakness Enumerations (CWEs) included are CWE-79: Cross-site ScriptingCWE-89: SQL Injection, and CWE-73: External Control of File Name or Path.

Via; [Archive] Kristian Köhntopp on Twitter: “Vieles aus diesem Thread ist nun geordneter in … zu finden.… “

Very much related as A01 was the basic cause of GitHub’s commitment to npm ecosystem security | The GitHub Blog – no npm package can historically ben tracked to be authentic.

We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.

–jeroen

Posted in Development, Power User, Security, Software Development | Leave a Comment »