Переезд с Ubuntu на Windows 10, Hyper-V и избавление от железного маршрутизатора

А кто судил о никсах по убунте? В статье про это вообще ни слова — просто пост со впечатлениями и простеньким маном по настройке виртуального маршрутизатора для Hyper-V…

Kotlin + React vs Javasript + React

Как-то все забывают, что основная задача стрелочных функций — все таки использование родительского контекста (отсутствие собственного this, arguments, super и new.target).

Kotlin + React vs Javasript + React

Получение машин на JS можно было короче (в котлине почему-то используете темплейт-стринг а в ЖС — нет):

async loadCars() {
    const uri = `/api/cars?brand=${this.state.brand || ''}&color=${this.state.color || ''}`;
    this.setState({
                      cars:   await (await fetch(uri)).json(),
                      loaded: true,
                  });
}

Квест, который никто не может пройти

— Запустить (не приносит результатов)
— Скопировать (чет совсем бредовый вариант кмк)
— Забить %) (там права только на чтение/запуск)

Квест, который никто не может пройти

Та же борода, запуск ничего не дает, внутри ничего полезного нет, а кроме этого тоже ничего нет. Работать не могу нормально — интересно что ж там за шляпа такая %)

15 малоизвестных свойств и методов объектов DOM

Именно, чтобы выбрать все надо делать myElement.querySelectorAll('.my-class');
Который уже вернёт злополучный NodeList

PHP может стать еще лучше

Оверхед по написанному не находите? =)
Все что я описал — банальная экономия на символах, с сохранением функциональности.

Правда, по поводу автодополнения на инициализации массива — не понял… PHPStorm вроде не позволяет такого.

PHP может стать еще лучше

Меня в PHP до состояния «аштрисёт» доводят только три вещи (по убыванию бесячести):

1. Доступ к элементам объектов через ->, которое ну очень часто получается как _> ну или -. (рукопопы как я, которые имеют рассинхрон между руками, поймут). Вот что угодно лучше служебного оператора из двух символов, один из которых по шифту вводится..
2. Инициализация значений именованного массива через => (ну какого черта не : ?)
3. Ну и как уже сказал автор — нельзя использовать выражения везде. Да даже если бы можно было хотя бы в строках делать было бы уже хорошо:
   

   $a = "Hello ${$b?:'hell'}";

   вместо

   $a = "Hello " . ($b?:'hell') . "!";

Golang, PHP, Кинопоиск и Telegraph — Что их объединяет?

Сенсей, расскажите мне, неумелому, как вы пишете бэкенд минуя работу с массивами на каждом чихе?
Ибо ну серьезно, чаще чем с массивы встречаются разве что строки (и даже это утверждение я бы подверг сомнению).

Golang, PHP, Кинопоиск и Telegraph — Что их объединяет?

Меня сейчас гоферы заминусят, но, если честно, пытался сделать заход в сторону GO — не вышло, обливаясь слезами я побежал обнимать свой PHP 7.1…
В GO все вроде бы круто, статическая типизация, рутины и прочее, но этот язык упорно превращает работу с массивами в кромешный ад. Да, я понимаю что это, в общем-то, плата за статичность, но, ведь, задумываясь, в большинстве случаев веб — это про массивы.

В России запретили Tor и VPN. Что теперь делать

Дык им же наплевать, насколько показывает опыт "пакета яровой". Закон приняли, а как его соблюдать будут — да пофиг, закон то приняли, их работа закончилась на моменте подписания закона…

Дихотомия UI и UX: UI-дизайнер ≠ UX-дизайнер

И все равно к обивке дивана.

Юзер сидит на диване обитом наждаком — плохой UX, попа потеет и это неприятно.
Юзер сидит на диване обитом кожей — хороший UX, приятно но попа все-таки потеет.
Юзер сидит на диване обитом микрофиброй — отличный UX, приятно и попа не потеет.

Тоже ведь UX, если мебель будет не лучшая — UX будет хуже нежели с лучшей мебелью. Как раз таки в контексте дома, материалы интерьера, его цвет и звуки это тоже UX.

У дома будут тонкие стены — хреновый UX, плохая звухоизоляция, юзер слышит как храпит енот около дома, UX-дизайнер должен был предусмотреть.
У дома будут обои цвета #f00 — хреновый, опять же UX, ибо это перенапрягает глаза, они болят -> юзер не хочет входить в наш дом.

UX ведь расшифровывается как User Experience, то есть пользовательский опыт, то есть UX-дизайнер должен спроектировать именно «положительный опыт от пользования продуктом», на который влияет хренова туча разных для каждой предметной области (в смысле будь то шариковые ручки или космические шаттлы) аспектов.

Я это все к чему, с заголовком статьи согласен, UI-дизайнер≠UX-дизайнер, но UX-дизайнер = UI-дизайнер.

Важно то, что кроме взаимодействия через UI, клиент взаимодействует с компанией еще множеством способов и вот за все эти (оставшиеся) способы уже отвечает UX.

Как раз таки не за оставшиеся, а вообще за все, включая UI. Если UI дизайнер просто нарисует красивый сайт, то UX дизайнер сделает то же самое, с оглядкой на ЦА, технические-средства и т.п., а потом еще пользовательский тест устроит и сделает красивый сайт божественно-красивым (утрирую ясное дело).

Как-то так это лежит в моей голове и почему-то по-другому не укладывается, UI-дизайнер — демоверсия UX-дизайнера.

Дихотомия UI и UX: UI-дизайнер ≠ UX-дизайнер

В примере с домом, кстати, «материалы из которых сделана мебель» это и UI и UX, ибо от материала зависит и то, как будет диван выглядеть, и твои ощущения когда ты сядешь на него в одних трусах.
Именно поэтому, на мой взгляд, такой прям уж четкой и однозначной границы между UI и UX нет.

bala.js — убийца jQuery в менее чем 400 символах кода *

Вы, видимо, не так поняли смысл моего коммента, даже на сателлитном сайте ммо игры, доля ослика ощутимо велика.

bala.js — убийца jQuery в менее чем 400 символах кода *

Пример статистики с боевого сайта, проекта посвященного ММО игре:


Так что не надо пожалуйста про нераспространенной IE;)

БЭМ — методология развешивания костылей

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

БЭМ — методология развешивания костылей

ну и будет у визарда описан свой .wizard>.wrapper который ну никак не будет аффекститься .form>.wrapper

БЭМ — методология развешивания костылей

Да ну как же, появлияется визард, инпуты имеют все то же отображение что и имели просто слилистически и семантически появляется еще и визард, вокруг инпутов.

т.е. если описывать .form>.wrapper input{}, а именно так я в большинстве случаев и сделаю, то ничто мне не помешает вкорячить вокруг инпутов визард, раскидав так же копипастом нужные инпуты по разным страницам.

БЭМ — методология развешивания костылей

А зачем мне туда что-то вкладывать?
Я написал разметку, которая предполагает что внутри .menu лежат .item. А если вдруг, не пойми зачем, мне понадобится влепить что-либо между ними я просто добавлю один уровень в SCSS и будет не

.menu{
    & > .item{}
}

а

.menu{
    & > .some_shitty_block > .item{}
}

или если мне надо будет расписать стили того блока, то так:

.menu{
    & > .some_shitty_block {
        & > .item{}
    }
}

Все доводы БЭМщиков это какие-то членовредительские моменты, когда «где-то между» ВДРУГ! возникают левые блоки. У меня они не возникают вдруг, код пишу я и моя команда внутри котороой есть оговоренности, а чаще всего один глобальный блок — один разраб, а значит и разметка и стили пишет один мозг, а если у него элементы появляются «вдруг», то встает вопрос «какого он забыл в команде»

БЭМ — методология развешивания костылей

Т.е. вам непосредственный дочерний селектор религия запрещает использовать или что?

.menu > .item {}
.nevigation > .item {}

А дальше хоть 10 раз одно в другое вложит, оно не посыпется.