Thomasorus

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

harperreed

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

penso

#!/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
}

AutoSponge

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 => {

mattdesl

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.

thom4parisot

'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';

rehno-lindeque

(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

mattdesl

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

domderen

const fun = ({param1 = 'some default value', param2 = 'other default value'} = {}) => {
  console.log(param1);
  console.log(param2);
  console.log(options); // Can I somehow get access to the object that has param1 and param2 inside?
  console.log(arguments[0]); // Is this the only way?
};

tdd

Angular: Just say no

A collection of articles by AngularJS veterans, sometimes even core committers, that explain in detail what's wrong with Angular 1.x, how Angular 2 isn't the future, and why you should avoid the entire thing at all costs unless you want to spend the next few years in hell.

Reason for this: I'm getting tired of having to explain to everyone, chief of which all the indiscriminate Google Kool-Aid™ drinkers, why I have never believed in Angular, why I think it'll publicly fail pretty soon now (a couple years), and why it's a dead end IMO. This gist serves as a quick target I can point people to in order not to have to parrot / compile the core of the articles below everytime. Their compounded reading pretty much captures 99% of my view on the topic.

This page is accessible through http://bit.ly/angular-just-say-no and http://bit.ly/angularjustsayno, btw.

• I won't be using Angular for my next project...and neither should you. • Robe