Au delà de la pyramide des tests.
Des propriétés désirables de tests.
- make it wrong
- make it short
- make it again
npx difitTrancher dans n'importe quelle situation
Maximizer : comparer au max les choix, opimiser pour faire les meilleurs choix
Satificier : cherche juste un bon chois, décident vite, moins de regret post-décision, et sont plus heureux.
Si un choix peut être réversible, il doit être pris comme une expérience et être fait le vite possible
Si un choix est irréversible, prendre sont temps et réfléxhir à fond
- complexity is the default condition
- complexity will grow
- entropy will increase
- local decisions will get made will appear to make sense locally will not roll up will clash at the edges
- we we always have the choice to simplify if we can recognize where the complexity is and if we can arm ourselves with techniques that are going to help us do that
- consistency is the key
- consistency is the mechanism by which we can make we can reduce cognitive load we can or make cognitive load appropriate
- some problems are intrinsically hard, that's fine
- they don't need to be any harder than they are
it really shouldn't be this difficult
We have two options for defining types in TypeScript: types and interfaces. One of the most frequently asked questions about TypeScript is whether we should use interfaces or types.
The answer to this question, like many programming questions, is that it depends. In some cases, one has a clear advantage over the other, but in many cases, they are interchangeable.
In this article, I will discuss the key differences and similarities between types and interfaces and explore when it is appropriate to use each one.
Let’s start with the basics of types and interfaces.
When to use types vs. interfaces
Type aliases and interfaces are similar but have subtle differences, as shown in the previous section.
While almost all interface features are available in types or have equivalents, one exception is declaration merging. Interfaces should generally be used when declaration merging is necessary, such as extending an existing library or authoring a new one. Additionally, if you prefer the object-oriented inheritance style, using the extends keyword with an interface is often more readable than using the intersection with type aliases.
Interfaces with extends enables the compiler to be more performant, compared to type aliases with intersections.
However, many of the features in types are difficult or impossible to achieve with interfaces. For example, TypeScript provides rich features like conditional types, generic types, type guards, advanced types, and more. You can use them to build a well-constrained type system to make your app strongly typed. You can’t do this with interfaces.
In many cases, they can be used interchangeably depending on personal preference. But, we should use type aliases in the following use cases:
- To create a new name for a primitive type
- To define a union type, tuple type, function type, or another more complex type
- To overload functions
- To use mapped types, conditional types, type guards, or other advanced type features
Compared with interfaces, types are more expressive. Many advanced type features are unavailable in interfaces, and those features continue to grow as TypeScript evolves.
Below is an example of the advanced type feature that the interface can’t achieve.
type Client = {
name: string;
address: string;
}
type Getters<T> = {
[K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};
type clientType = Getters<Client>;
// type clientType = {
// getName: () => string;
// getAddress: () => string;
// }
Using mapped type, template literal types, and keyof operator, we created a type that automatically generates getter methods for any object type.
In addition, many developers prefer to use types because they match the functional programming paradigm well. The rich type expression makes it easier to achieve functional composition, immutability, and other functional programming capabilities in a type-safe manner.
Some of you may be able to guess what’s been on my mind lately. In April 2010, film critic Roger Ebert made an infamous claim. He said, “Video games can never be art.” His blog post set off a firestorm of discussion, centered around the idea that he was an out-of-touch, old man who didn’t understand games. While I disagree profoundly with Mr. Ebert, he was an intelligent, articulate scholar, and had a better point than his clickbaity quote might imply.
Sandro Mancuso, Co-founder and Group CEO
AI is Changing How We Code
AI coding tools are completely changing the software development landscape. Developers now rely on tools like GitHub Copilot, Amazon CodeWhisperer, and ChatGPT to generate code, fix bugs, scaffold tests, and accelerate routine tasks. Code that once took hours can now be produced in minutes; sometimes seconds. Prompting is quickly becoming a core developer skill.
AI is here to stay. The promise is undeniable: higher output, faster delivery, and fewer repetitive tasks. But with this leap in speed, a deeper question emerges:
Are we building well - or just fast?
This article explores that question through the lens of Software Craftsmanship, offering a pragmatic perspective on how to embrace AI without sacrificing the principles that make great software possible.
Project
EcoLogits is a suite of open source tools for estimating the environmental footprint of generative AI models at inference. Based on life-cycle assessment principles, the project raises awareness about the direct environmental impacts of AI while empowering developers and organizations to build more sustainable AI-powered applications.
- Open & transparent – Code, methodology, and data are openly accessible.
- Ease of use – Emphasizes on seamless integration and user experience.
- Community-driven – Continuously built and improved collaboratively.
✦ TECHNICAL BEAUTY ✦
Episode 22: mc – Midnight Commander
- A computer science student in Mexico City writes a file manager. Thirty-one years later, it's still running. One pkg install on FreeBSD. One apt install on Debian. Available on anything with a C compiler and a pulse.
Miguel de Icaza built mc as a Norton Commander clone for Unix. Then he co-founded GNOME. Then Mono. Then Xamarin. Then Microsoft acquired it. The man kept rather busy. The file manager quietly kept working.
220,000 lines of C. One binary. 12 MB of RAM. Here's what you get for that:
■ Dual-panel file management
■ Built-in editor (mcedit) with syntax highlighting
■ Built-in viewer (mcview) and diff (mcdiff)
■ FTP, SFTP, SMB: browse remote servers as local directories
■ FISH: file transfer over SSH without SCP on the remote
■ Archive browsing: .tar.gz, .zip, .rpm, .deb as directories
Hardik Pandya
I am generally curious about the concept of legibility of work. Look around in your workplace. You can find documents, messages, presentations, design files. Evidence of people’s work. While it may look like a lot, there is a whole other type of work that is very hard to see. The invisible work.
This decision tree describes how to use the alt attribute of the <img> element in various situations. For some types of images, there are alternative approaches, such as using CSS background images for decorative images or web fonts instead of images of text.
Jim Coplien believes that we have done OOP the wrong way for 40 years, and suggests an approach to reflection based on the DCI paradigm and influenced by the human society.
Heidi Waterhouse discusses seven issues to tackle during project development: Localization, Security, Extensibility, Documentation, Affordance, Acceptance, Accessibility.
Jeu video eco conçu en pixel art
Découvrez l'article de Cognitive Realms : https://www.brandonsanderson.com/blog...
L'essor de l'IA, des grands modèles de langage et de l'art généré soulève des questions fascinantes. Les progrès réalisés jusqu'à présent nous incitent à nous interroger sur la nature de l'art et sur les raisons qui nous poussent à en créer. Brandon Sanderson explore l'émergence de l'art généré par l'IA, l'importance du processus artistique et les raisons de sa rébellion contre cette nouvelle frontière technologique et artistique.
« Oui, le message est clair : “Le voyage prime sur la destination”. C'est toujours le voyage qui prime. »