Как я использую git

Почему народ так цепляется за консоль мне непонятно…

Помогает лучше понять механизмы работы, что все таки иногда полезно и вероятно некоторым просто любопытно знать детали. За одним кликом мыши в GUI часто скрывается десяток CLI команд.

Ну и статья с использование GUI клиента мотрелась бы глупо.

PS SmartGit получше TortoiseGit будет, хотя бы из-за кроссплатформенности (Java).

Как выбрать правильный лэптоп для программирования

Процессор уже не так и важен для большинства задач, а вот память и SSD очень.

Как выбрать правильный лэптоп для программирования

Ага, ссылки в студию на ноутбук с 7700HQ, но без дискретной видеокарты. Да, я знаю о workstation, у Dell линейка precission очень неплохая по характеристикам

HP Zbook (в том числе с приставкой Studio) опционально бывают с HQ процессором и без дискретки, тоже workstation.

Сравнение REST и GraphQL

Если смотреть на детали, то да, но REST просто получается более частная форма вызова конкретных ендпоинтов.

Сравнение REST и GraphQL

когда команда — некий идентификатор команды + список некоторых параметров для этой команды.

Так делаем сколько нужно ендпоинтов с соответствующей логикой и все, это REST API и есть. Называет ендпоинты командами или чем угодно, а не сущностями и все. Так делают уже десятки лет.

В случае гибкого GraphQL дело как раз в унификации, как раз в этом цель и есть чтобы выставить ДБ наружу образно говоря, но конечно не напрямую как некоторые могут подумать.

Сравнение REST и GraphQL

как об интерфейсе команда-результат

Ну вот GraphQL как раз ближе гораздо к этому чем REST API. Один ендплоинт куда отправляешь запросы на выборку только необходимых данных или на обновление данных. То есть оперируешь сущностями подобно таблицами в SQL (строя связи в запросах), а не ендпоинтами которые повешаны поверх сущностей в случае REST API.

PS вообще подобный OData стандарт существовал до GraphQL.

JavaScript без this

Пример того как писать неподдерживаемый/корявый код.

Что будет если скрестить React и Angular?

Верно, вот пример возможной реализации https://habrahabr.ru/company/ncloudtech/blog/321584/#comment_10243970

Что будет если скрестить React и Angular?

class MySecondComponent extends MyComponent  {
 constructor(...args) {
    super(...args);
    this.scope.example = 'Goodbye World';
  }
  myOwnMethod() {}
}

Как в этом случае добавляются/описываются дополнительные зависимости для MySecondComponent?

Во-вторых, области видимости разметки также наследуются.

Прототайпинг скоупа как раз ангуляровская фишка (точнее обычный JS прототайпинг), от которой лучше отказаться, так же лучше отказаться от любых вещей завязанных на специфику фреймворка, передавать все явном виде через атрибуты. Компоненты по-моему мнению компоненты должны быть независимыми/изолированными.

GitHub переходит на GraphQL

graphql вероятно более web/js/script-kiddies ориентирован

Angular 1.x: крадущийся webpack, затаившийся grunt

Теперь ипорт зависимостей выглядит так, что более удобно:

• зависимости описываются только один раз и это просто массив $inject без необходимости соблюдать порядок элементов в массиве
• использование сервисов в более явном/унифицированном виде — по импортированной зависисимости (this.$i[GroupsService.$name])

import './groups-favorite-page.component.scss';

import {Component, BaseClass2Scoped} from '_global_common_angular';
import {GroupsService} from './../groups/groups.service';

@Component({
    __filename,
    bindings: {
        _input: '< input'
    }
})
export class GroupsFavoritePageComponent extends BaseClass2Scoped {
    static $inject = [
        GroupsService.$name,
        ...BaseClass2Scoped.$inject
    ];

    constructor(...$injections) {
        super(...$injections);

        this.$s.groups = [];

        this.$i[GroupsService.$name]
            .requestFavoritePage({sort: {orders: [{property: 'group.title'}]}})

CSS в JavaScript: будущее компонентных стилей

это все называлось спагетти-кодом
jsx сам по себе гадость

Вот вот, ноги то ведь из Facebook растут, корни у которого с PHP связаны ...

CSS в JavaScript: будущее компонентных стилей

СSS внутри javascript — глупейший тренд последнего времени.

React фанбоям должно понравиться, JSX ведь им нравится.

Vue.js для сомневающихся. Все, что нужно знать

и каким-то уютными)

Потому что это так и есть, это очень developers friendly штука, забыл например описать поле в data — фреймворк тебе подскажет не тупи мол.

Vue.js для сомневающихся. Все, что нужно знать

Ничего не мешает .vue файл использовать просто для группировки, а сами файлы (шаблон, код, стили) внутри подключючить как внешние файлы.

Обзор систем учета рабочего времени

http://alternativeto.net/browse/search?q=time+tracking

Вот это может под linux работать нормально http://alternativeto.net/software/hubstaff/

Зачем использовать статические типы в JavaScript? (Преимущества и недостатки)

Все преимущества сводятся к одному — воможность четкого (гарантированно верного) автоматического анализа кода, по сути эмуляция компиляции (TypeScript). По сути это уже не скриптинг. И это очень большое подспорье как минимум в случае больших проектов и распределенных команд.

Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов

отсутствие jsx

JSX поддерживается, если нужно.

качество кода и его документирования

Может быть, но вот допустим документация отличная. И вообще сам фреймворк очень developers friendly, в консоли подсказывает на упущения и ошибки хорошо отображает.

Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов

Если нужна статическая проверка, можно использовать Flow

Костыли в виде Flow не нужны (уже не нужны), существует более полноценное решение в виде TypeScript. Если TypeScript не дружит с React, то это проблема React и сообщества его фанбоев.

Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов

Сравните лучше с VueJS, то что риакт не нужен люди и так уже начинают понимать.