Code
-
WebExtension Manifest.json permissions options list
WebExtension Manifest.json permissions options list is quite long. Let us see what we can access with our plugin for FF. This hsould inspire You to write Your own for quality of life and ease of doing things… or avoid them all together. For avoidance i would highly recommend to look into prper ad block filter and creating / adding your own. Rule : Do not scare users Remember when Your app requires and asks for access. You either explain to user in every detail what for and go with bare minimum. Just as a rule of thumb of not beeing accused of getting and selling info. It is always scary…
-
Structure for instructions, agents and skills
This all is the provide a nice clean idea on how to store your files so You can make Your AI assistant / LLM network understand what and how to do. Acording to Your more or less strict rules. This should help You to achieve more repeatable results as expected. The problem : generic answer Do not confuse with generic functions, those rock ! Out-of-the-box, any LLM (here copilot) creates generic code. You could call it 'vanilla’ flavour. It doesn’t know your conventions, library preferences patterns / anti patterns. This results in something that might work but is hard to maintain, totally different then the rest of the lot and…
-
Productive struggle vs AI slop
Productive struggle vs AI slop is quite the topic these days. On one hand we have to do the hard, boring, frustrating work. Do it long enough to learn the whole lot, reshape skills, gain confidence. Opposition of escaping to quick fixes with or without AI. When used in conjuction with AI, we should still keep the struggle but without the pointless friction. That way more energy and cognitive power goes into craft and progress, long-term growth… instead of refactoring some legacy code and working over things that should not be that hard in the first place. What is productive struggle? Productive struggle is the time and space where a…
-
Typescript perfect sync – 3 tricks to keep it tight
Typescript perfect sync can be kept using couple of strategies. Most of us start with simple union types, like this: const ScenarioStatus = 'success' | 'fail' | 'error' | 'other'; So far so good. That works great… until you need to iterate over those values for rendering, validation, or other logic. And now You are stuck with two separate definitions: one array for logic, and one string union for the type. Sooner or later, they’ll fall out of sync and provide headaches to people. You could go for en enum…. Below behold the three TypeScript tricks to make your code tight, hard to break, cleaner, safer, DRYer and resistant to…
-
Statics VS AI code analysis ~13 tools
Statics VS AI code analysis works best using the pros from both words. Go hybrid ! Static tools understand the syntext, hardcoded parameters and are very strict. On the other hand AI understands context, can figure out business logic, adapt the codebase. Logic flaws or performance bottlenecks rule-based scanners might miss, AI will put more effort into that. Static analysis limits Static tools scan for syntax errors, style violations, and basic security patterns using fixed rules. Always consistenst, very fast but might generate false positives, ignore business logic, and require manual rule overrides. How often did You use @typescript-error 🙂 Do You code for the linter to pass, logic to…
-
Data contracts. Building universal data access proxy api
Data contracts usually requires us to build around them a universal data access proxy API for users to consume. API utilizing proper data contracts, negotiated with different teams, acts as a unified gateway providing the necesities. Allows access to data sources like databases, REST APIs, GraphQL endpoints or other file systems. One api to rule them all Steps to build data contracts for proxy api You could try and adopt a similar flow for creating such access points, even make a template in JIRa so You will know where to get proper data and how to acquire it… or maybe expose the library and just aprove properly looking merge requests……
-
Law of Demeter in programming
Law of Demeter in programming You could in short paraphrase as „Don’t talk to strangers!” or „Keep Your hands in your pockets”. A class needing data from a deep chain of objects like – user.getAddress().getStreet().getNumber().It is visible very often in OOP, less in functional approachess ! The Law of Demeter states that method only knows its closest dependencies: itself, passed parameters, created objects, and own fields. Should not be used with dot chains ( they were so fancy when we started Java 8 back in the day). What to Remember? Where Law of Demeter comes from ? Why Demeter ? The Law of Demeter in progamming takes its name from…
-
GIT token access issue – use special API url !
GIT token access issue will usually be that You are using a wrong url. When accessing files through the GitLab API using an access token you must use a special API URL, not the regular browser URL you see in firefox when navigating the repository. Using the standard browser URL will not work with API authentication tokens. Why Use the API URL? The regular repository URLs are designed for web browsers and do not support token-based authentication. (They could, but they just don`t :)) The GitLab API requires you to call its specific endpoints, which accept access tokens and return the raw file data or JSON metadata. URL Comparison Parameter…
-
Technical refinment – the power in agile sprint planning
Technical refinment In many Scrum teams, sprint planning sessions often suffer from the chronic problem of task underestimation. While teams aim for agility and velocity, frequently, the work selected for the sprint exceeds the actual capacity due to unclear or vague task definitions. This results in rushed implementation, increased bugs, and lengthy code reviews—ultimately slowing down delivery rather than speeding it up. This is where technical refinement comes in as a game changer. Technical refinement is a focused process during backlog refinement where the development team collaborates deeply to break down, clarify, and technically validate user stories and tasks before sprint planning begins. Technical refinment worth Key ways technical refinement…
-
Estimations in sprints are ludicrous ?
Estimations in sprints are ludicrous ? We switched from fibonacci complexity to just plain man day. Estimating work in sprints has become a cornerstone of Agile | Scrum methodologies More and more evidence suggests it often creates more problems than it solves. On the other hand it is a nice „form” You can wrap Your work into. It is a nice template. Teams routinely face mismatches between predicted complexity and actual time investment. Exacerbated by meetings that should be an email, administrative overhead and tasks like code reviews. The Fallacy of Sprint Estimation is why complexity metrics miss but do we have anything better ? The complexity is time disconnected…
