Anurag Hazra anuraghazra

How to estimate effort

By Golo Roden, translated from German with the help of DeepL

Every developer knows the challenge of estimating effort for development code. Very few like to do it. Why is estimating so unpopular, why is it even necessary, and what should you look for?

Why estimate effort?

The question of why it's necessary to estimate effort at all is easy to answer. Knowing how long a task is expected to take is essential for planning who in a team can do what and when. Even across team boundaries, a certain amount of time planning is essential; after all, teams have to be coordinated and resources have to be procured. In addition, other departments such as marketing also have an interest in being involved in planning at an early stage.

Generics Deep merge

source code was moved into github repository: https://github.com/Svehla/TS_DeepMerge

"Art prior" to React:

Martin Fowler: InversionOfControl (2005-Jun-26)

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

The litmus test:

If your code calls it, it's a library.

Advanced memoization and effects in React

Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.

Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:

Memoization means caching the output based on the input; in the case of functions, it means caching the return value based on the arguments.
Values and references are unfortunately overloaded terms that can refer to the low-level implementation details of assignments in a language like C++, for example, or to memory

Why using the `children` prop makes `React.memo()` not work

I've recently ran into a pitfall of [React.memo()][memo] that seems generally overlooked; skimming over the top results in Google just finds it mentioned in passing in a [React issue][regit], but not in the [FAQ] or API [overview][react-api], and not in the articles that set out to explain React.memo() (at least the ones I looked at). The issue is specifically that nesting children defeats memoization, unless the children are just plain text. To give a simplified code example:

const Memoized = React.memo(({ children }) => (<div>{children}</div>));
// Won't ever re-render
<Memoized>bar</Memoized>
// Will re-render every time; the memoization does nothing

	export const CACHE_STALE_AT_HEADER = 'x-edge-cache-stale-at';
	export const CACHE_STATUS_HEADER = 'x-edge-cache-status';
	export const CACHE_CONTROL_HEADER = 'Cache-Control';
	export const CLIENT_CACHE_CONTROL_HEADER = 'x-client-cache-control';
	export const ORIGIN_CACHE_CONTROL_HEADER = 'x-edge-origin-cache-control';

	enum CacheStatus {
	HIT = 'HIT',
	MISS = 'MISS',
	REVALIDATING = 'REVALIDATING',

	// a typescript implement of hindley-milner type inference
	// reference http://smallshire.org.uk/sufficientlysmall/2010/04/11/a-hindley-milner-type-inference-implementation-in-python/

	/// <reference path="./lib.es6.d.ts" />

	// ...
	interface AstNode {
	}

	class Id implements AstNode {

	const https = require("https");

	exports.handler = (req, ctx, callback) => {
	const event = JSON.parse(req.body);
	console.log("Event:", event);
	let response = {
	statusCode: 200,
	body: "ok"
	};

	/* eslint-disable no-unused-vars */
	/* eslint-disable no-else-return */

	// JSX constructor, similar to createElement()
	export const h = (type, props, ...children) => {
	return {
	type,
	// Props will be an object for components and DOM nodes, but a string for
	// text nodes
	props,