Augustin C. 0gust1

Ces dernières années on entendait constamment que devenir dev (et plus globalement aller dans les métiers de l'informatique) c'était se garantir un poste bien payé où il y aura toujours du taf.

De ma fenêtre (totalement subjective et donc peut-être mal orientée) cela n'a pas changé, il y a toujours autant de boulot et de demande. Les salaires fluctuent, les avantages aussi, les conditions d'embauche également, mais rien de dramatique. Mais SEULEMENT pour les gens ayant quelques années d'expérience.

La difficulté donc, c'est d'obtenir sa première expérience. C'était déjà difficile il y a 2 ou 3 ans, mais ça semble s'être aggravé en 2023, comme si en six mois tout avait changé. Ci-dessous une liste non-exhaustive et désordonnée, 100% subjective, des raisons pour lesquelles je pense que s'orienter dans le dev en ce moment n'est peut-être pas/plus une bonne idée.

Plein de régions et villes ont voulu devenir des pôles numériques afin d'attirer investisseurs et réduire le chomage. Elles ont créé des lieux déd

FIP Radio

Main URL: fip.fr
Wikipedia: en.wikipedia.org/wiki/FIP_(radio_station)
Mobile apps: Android / iOS

Streams

Direct streams for your listening pleasure

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

~~Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.~~

Small script for development + builds with browserify.

Uses loose-envify for faster inlining and cross-env to handle windows/unix shells.

Dev features:

fast rebuilds w/ watchify, LiveReload, syntax errors in DOM, etc.

Build features:

uglify, simple dead code elimination, optimized bundle.

(TLDR; This is a super naive list, just a few quick thoughts)

I was thinking that perhaps having some kind of % coverage for things that people will need in practice in order to use Elm for rapidly creating nice GUIs. However, I also think there needs to be some kind of (mental, at a minimum) framework for people to work inside so that new controls are easily extensible, styling agnostic, work uniformly with other form controls + validation etc before it can really become mainstream. I'll start adding some thoughts here over time (not much time now) - however, this doesn't cover the second point and I think people still need to get into that before things can really progress very far.

Form handling

Submit handling, some notes from @rtfeldman : evancz/virtual-dom#5 (comment)

Inputs fields

display masking (e.g. static slashes and colons for __/__/__, __:__:__ formatting)
simple inline dropdowns (e.g. dropdown/typeahead for `10 [days/months/year

A short list of hurdles to get Electron working more like Node, and how I'm tackling them.

using renderer process.stdin with Buffer seems difficult/impossible
- alternative: send buffered stdin as a string to the renderer
renderer process.argv needs to be require('remote').process.argv
- should be patched in preload script to ensure your Node dependencies work correctly
syntax errors in <script src="index.js"> do not print to terminal
- window.onerror in a preload script can be used to detect these problems
- only provides file, line number and a minimal error message
stderr gets cluttered with Chromium logs

	import argparse
	import json
	import logging
	import os
	import re
	import shutil
	from concurrent.futures import ProcessPoolExecutor, as_completed
	from dataclasses import dataclass
	from datetime import datetime
	from typing import Any, Callable, Dict, List, Literal, Optional, Tuple

	#!/bin/sh
	# Based on Loren finding https://chromeisbad.com/

	# From https://apple.stackexchange.com/questions/92640/how-do-i-prevent-the-permissions-denied-message-from-being-displayed-when-i-do-a
	find() {
	{ LC_ALL=C command find -x "$@" 3>&2 2>&1 1>&3 \| \
	grep -v -e 'Permission denied' -e 'Operation not permitted' >&3; \
	[ $? = 1 ]; \
	} 3>&2 2>&1
	}

	const test = require('tape')
	const util = require('util')
	const puppeteer = require('puppeteer')
	const component = 'my-component'

	let browser, page, focus
	const componentId = 'my-component-instance'
	const interactionId = 'my-component-trigger'

	test(component, async t => {

	'use strict';

	var pkg = require('./package.json');
	var gulp = require('gulp');
	var utils = require('gulp-util');
	var source = require('vinyl-source-stream');

	var isWatching = false;
	var isProduction = process.env.NODE_ENV === 'production';