• Как мы заставили npm-пакеты работать в браузере
    0
    Автор хотел запускать JS код as-is. А as-is он — на 99% состоящий из npm зависимостей. Начиная от реакта и заканчивая leadpadом.
    Далее — по тексту.
  • 7 выводов программиста самоучки за 1 год
    0
    А можно тоже самое, только с ссылкам на почитать?
    И это же сколько лет это потребуется узучать?
    (сколько лет потребуется чтобы написать учебный материал)
  • Весь веб на 60+ FPS: как новый рендерер в Firefox избавился от рывков и подтормаживаний
    0
    Эх, все зло и тормоза от Альфы. Каких только технологий не придумали чтобы сделать жизнь чуть чуть лучше, но до победы далеко.
    А самое главное, что любая полупрозрачность (текст) требует активного режима смешивания который просто сразу в два раза все просаживает.

    В свое время пытался рендерить различные сущьности в отдельные текстуры, чтобы потом в шейдере сразу все склеить. TMU сейчас ой как много.

    От сюда и вопрос — а как ФФ склеивает слои? glBlend не предлагать.
  • React, встроенные функции и производительность
    0
    «Хороший» способ оптимизации — ограничивать область распространения изменений. Не надо вешать на каждый чих shouldUpdate, достаточно в узловых местах добавить connect, которые будет ташить данные из стора, а не родителя, создавать как бы «автономную» область.
    Ну и не стоит забывать что connect создает PureComponent, который только на изменение стора и реагирует.
    Но вообще, по моему опыту, большая часть зла исходит от самого реакта и его экосистемы, чем он кривых рук конечного програмиста.
  • Секции в футере
    0
    www.propellermediaworks.com/blog/2017/7/6/websites-ada-places-of-public-accommodation
    Суд США приравнял сайты к публичным местам. В общем приехали.
  • Как собеседовать инженеров-программистов
    0

    Испытательный срок 6 месяцев, который в Австралии прям на законодательном уровне, никто не отменял.

  • Как собеседовать инженеров-программистов
    +2

    Испытательный срок — крайне плохая идея, если в начале надо уволиться из текущей компании, продать дом, и переехать на другой континент.
    Я, например, стараюсь заворачивать кандидата при малейшем намеке на то, что он может не пройти.

  • Webpack и моканье зависимостей
    +2

    У вас метод индукции сбоит. В данный момент безаппеляционные утверждения исходят только с вашей стороны.
    Вроде как приверженность только одного взгляда — и есть проявление радикального.
    У меня каждый день есть возможности видеть плюсы и минусы разных подходов на разных языках… и в большинстве случаев использование «классического» DI — это или Java, или объектно ориентированный говнокод 5-то летней давности.

  • Webpack и моканье зависимостей
    +1
    Но «нормальный» DI(уровня SpringBoot/ng-di) на самом деле редкий зверь в мире JavaScript. Есть взять пяток самых популярный библиотек, убрать то что для ng, и посмотреть на статистику скачек — будет не очень. Плюс многие путают DI с более широким IoT.

    DI хорош, когда в одну и туже розетку можно засунуть разные вилки. Если пара вилка/розетка всегда одна, и DI — исключительно для тестов — может его и не надо?

    И, самое главное, многие вещи просто принято использовать «как есть». Именно поэтому 90% примеров моканья чего либо, мокают: fs, сеть, session storage, селекторы в редаксе и другой environment.
  • Webpack и моканье зависимостей
    0
    У меня и самого есть проект на inject-loader, и я им в принципе доволен. Но иногда по пути попадаются грабли, на которые редко, да наступаю.

    Давайте придумаем немного синтетический пример:
    import function1 from 'module1';
    export default () => function1()+1;
    

    После чего мы просто мокаем module1 и expect(function1).to.be.called();
    Проходит время, и Вася добавляет еще одну строчку:
    import function1 from 'module1';
    import function2 from 'module2';
    export default () => function1()+function2()+1;
    

    Но он не меняет тесты, а тесты как работали, так и работают.

    Бывает и обратная ситуация — вы убираете строчку, а тесты как работали, так и работают.

    Беда в том, что тесты должны не только «тестировать» поведение функции, те проверять результат — они должны служить вторым контуром проверки, обеспечивать еще один «момент подумать».
    И, по хорошему, должны падать при _любом_ изменении логики програмы. Просто потому что они должны его детектить и подносить вам на блюдечке.

    Да — совсем не круто править 10 тестов после того как изменил одну запятую. Но еще более не круто – не догадываться, что вы изменили чуть больше логики, чем думаете, этой одной запятой.

    В свое время я пытался пропихнуть API для этого в proxyquire, но не срослось.
    В rewiremock для мока можно определить то как он может быть вызван — toBeUsed, directChildOnly, calledFromMock, плюс режим isolation который будет ругаться на каждый неожиданный import.

    Раз уж units tests are production code — относитесь к ним соотвествующе. Хотя конечно можно добавить тесты для тестов, но нельзя добавить тесты для моков, те заставить моки соотвествовать интерфейсам того, кого они собой замещают – тут нужен DI. Но он тоже не сахар.
  • It's a (focus) Trap
    0
    Чувствуется опыт, друг ошибок трудных.
    С aria-hidden/busy, насколько я понимаю, история уровня zoom:1 – в общем мы методом тыка проверили как лучше, и лучше вот так. За стандарт немного обидно, но в вебе так везде и всегда.
  • It's a (focus) Trap
    0
    Ну насчет aria-hidden – лично меня спецификация не очень убедила. Точнее он все еще более правильный чем aria-busy, тем более достаточно часто контент за пределами модала и не виден пользователю (или не читабелен).
    Пока самое хорошее решение — или inert или blockingElements. Но ни того, ни другого в браузеры не завезли.

    С фокусом проблем нет — банально проверено на читалках. Но вообще тест очень простой — после ловушки на очень большом растоянии располагалается еще один фокусируемый элемент. Если фокус перескочет на него — произойдет скрол страницы. Но если вызвать preventDefault — то скрола не будет.
    Другая проблема что порядок таббания отличается от перехода по элементам стрелками(VioceOver), что (конечно же) может все сломать и с этим уже бороться бесполезно.

    А вот проблема с tabIndex раскиданным по странице с точки зрения порядка обхода — и не проблема вовсе — github.com/theKashey/focus-lock/blob/master/src/focusMerge.js
  • It's a (focus) Trap
    0
    Вы немного не последовательны:
    1. Во первых aria-busy придуман не для этого. Основной контент надо именно «прятать», для чего нужен aria-hidden. И это относится исключительно к пункту 3.
    2. А вот пункты 2 и 3 различать не надо. Есть два события — focusIn, когда фокус куда-то пришел, и focusOut, когда он откуда-то ушел.
    Большинство библиотек агрятся на попытку фокуса покинуть ловушку, те focusOut, где новый элемент будет записан в relatedTarget. При этом ловушку в любом случае можно покинуть уйдя в адресную строку браузера, и на этом все сломается. Выбрался — значит свободен.
    Плюс focusOut — его можно(и нужно) вешать на свою ноду.
    К сожалению, так как это не очень работает, требуется вешать хэндлер на focusIn глобально на документе. Теперь, когда что-то за пределами ловушки получает фокус — можно будет этот фокус взять и положить обратно.
    Ну а в итоге требуется вешать события и туда и туда.

    И самое главное — НИЧЕГО кроме операций с фокусом делать не надо. Никакие keyboard/mouse/touch events.

    Тоже самое относиться к предложеным фокусным ловушкам по краям основной. Главный поинт в том, что эти ловушки должны быть за пределами, а не внутри. И исключительно чтобы между началом/конца документа и модалом был что-то таббательное.
    И в таком случае их вообще можно не включать в состав библиотеки — focus-lock/dom-focus-lock не могут менять верстку.

    В общем KISS в полной красе.
  • It's a (focus) Trap
    0
    Спасибо. Совсем забыл про эту «фичу», когда внутри focus-lock находяться первый элемент с tabIndex=1, который оказывается самым-самым первым на странице.
    В общем случае с самого первого или самого последнего можно выйти во внешний мир и/или просто начать не правильно работать.
    Пофиксил react версию focus-lock просто добавим элемент с tabIndex=1 за пределами ловушки, и обновил ссылки на примеры в статье — теперь работают секси.
    PS: Я вообще не совсем уверен откуда я взял старую ссылку — она использует старую версию библиотек. В общем спасибо за комментарий.
  • Наш путь к грин картe
    0
    >наличие публикаций, наличие ссылок на публикации, участие в оценке работы других, важный вклад в область профессиональной деятельности… была пара патентов, и мы решили опираться на это.
    Честно говоря достаточно не типичный набор для современного программиста, ведь хабратопик за публикацию не считается, как и комменты к нему не относятся к рецензиям, но вопрос в другом:
    Насколько все это формально, и может ли переходить колличество в качество.
    Австралии, где я сейчас нахожусь, требуется только образование и опыт работы. На колличество патентов, звезд на гитхабе и профессиональный уровень вообще — глубоко фиолетово.
  • Переходим на сторону сервера с bem-express
    0
    Я уже год как не Яндексоид, и мне как-то и то и другое не очень.
  • Переходим на сторону сервера с bem-express
    0
    Но это же лучше чем там -> в статье наверху?
  • Переходим на сторону сервера с bem-express
    0
    import BlockElem from 'b:block e:elem m:modName';

    github.com/bem/webpack-bem-loader
  • Переходим на сторону сервера с bem-express
    0
    А в bem-react так вообще импорты вычисляемые…
  • Переходим на сторону сервера с bem-express
    0
    Но функции, классы и переменные вы по БЕМу(и венгерской нотации) не называете?
    Декомпозиция и изоляция — вечные друзья и спутники программиста.
  • Переходим на сторону сервера с bem-express
    +1
    Есть HTML driven by CSS — это BEM, где у вас нет проблемы с CSS, но все остальное пляшет под его дудку
    Есть CSS driven by CSS — это Tachyons/Turrent и другой atom/functional CSS. Где CSS-а практически нет, зато в html.
    <button class="bg-purple f6 br3 ph3 pv2 white hover-bg-light-purple">

    И есть CSS-in-JS/ShadowDOM который разными путями немного исправляет генетику CSS+HTML и к нему следует применять немного другие подходы, потому что НЕ нужно именовать что либо по BEM-методолигии так как нет _необходимости_.

    >Тем кто хочет идти работать в Y, думаю, точно стоит вчитаться и попробовать
    В Яндексе есть много мест где никакого БЕМа нет.
  • Хороший плохой манкипатчинг
    +3
    Можно: использовать полифилы на своем сайте
    Нельзя: использовать полифилы в библиотеке.
    Никогда Нельзя: использовать манкипатчинг. Те добавление чего угодно «нестандартного» в прототипы стандартных обьектов.

    PS: С полифилами тоже надо быть аккуратнее. Далеко не все полифилы, что лежат на гитхабе, полифилы.
  • How-to: адаптивные письма в Gmail
    0
    Вчера откопал информацию о том что под конец 2016 года Gmail прекратил вырезать style.
    Проверил — а ничего и не работает.

    А вот где, оказывается, собака зарыта!
  • А был ли взлом «Госуслуг»? Гипотеза Яндекса
    0
    Тогда скажите честно — все плохо?
    Я как открываю свои логи — так сразу закрываю.
    Есть ли возможность трекать поведение пользователя и «намекать» ему, что гадость какая-то в системе есть?
  • А был ли взлом «Госуслуг»? Гипотеза Яндекса
    0
    XSS не так опасен, если он не может:
    1. Подгрузить другие скрипты с третих сайтов, чтобы мозгов добавить
    2. Отправить секретные данные пользователя «куда надо».
    Те максимум, что эта чтука сможет сделать — показывать Alertы.
  • А был ли взлом «Госуслуг»? Гипотеза Яндекса
    0
    На любом нормальном сайте с нормальной посещаемостью этот лог — куча говна, которое нереально разобрать в поисках крупиц настоящих опасностей.
    Лично у меня он на 99.9% состоит из блокировки разной малвари, и на 0.1(и это очень много), из Яндекса, который вечно новые хосты с разными ролями ничинает использовать и не публикует об этом никаких пресрелизов :(
    А вообще добавили бы анализ логов CSP в метрику — вот было бы аудитории приятно. Да и Яндексу пришло бы много полезных данных про творимые страсти.
    Ах мечты мечты.
  • А был ли взлом «Госуслуг»? Гипотеза Яндекса
    0
    Ну блокировка стилей, скриптов и фреймов по while list — это плевое дело, и 99% сайтов, которые никого внешнего не подключают с этим легко справятся.
    Блокировка инлайн стилей — немного сложнее, но совсем немного.
    Другое дело блокировка инлайн скриптов и евалов — тут у «старого» кода могут быть проблемы с поддержкой, но, опять же, все решается серверными плагинами. Был бы смысл.
    Для 99% сайтов этого смысла нет.
  • А был ли взлом «Госуслуг»? Гипотеза Яндекса
    +2
    Мда, CSP, который настраивается за пару минут защитил бы не только миллионы пользователей портала, но и бедного админа.
    Не стоит забывать, что без него все ваши «данные» технически открыты для всего того множества вредоностных плагинов, что на свете бывают.
    Ну а то что такие вредоносные плагины активно устанавливаются пользователями — факт.
  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    0
    Я еще и на скрипке могу. Здесь как раз в кустах случайно стоит рояль, я могу сыграть.
  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    0
    Сегодня вот получил письмо о том, что меня не смогут пригласить 1 июля в офис.
    Жаль конечно, но календарь назад не отмотать :)
  • Mockанье зависимостей в node.js приложениях
    0
    PS: Проблемы с общими моками, подключенными через третий файл — нет. У каждой инстанс сам за себя, так как rewiremock сам себя из кеша вырезает. Общий только кеш nodejs.
  • Mockанье зависимостей в node.js приложениях
    0
    Жил в России — все фигели от моего русского. Переехал зарубеж — теперь все фигеют от моего английского.

    Насчет параллельных тестов — сразу честно — не тестировал, но должно работать. Потому что:
    1. База моков — общая (надо будет сделать простой интерфейс по клонированию и ресету моков перед началом теста).
    2. По enable/disable из кеша вырезаются все мокнутые файлы и все файлы что как либо от них зависят.
    Итого можно быть увереным, что после enable получите ровно то, что и нужно, а после disable — все вернется на круги своя.

    Единственная проблема — ресет.
    Возможно вот такой код сработает:
    //mocks.js
     rewireMock('file1'); // do nothing, just indicate mock, to wipe it from a cache
     rewireMock('file2');
    


    //test.js
     rewireMock('file1').with(something); // override mock.
    
  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +2
    Но на самом деле — скучно. Я то уж боялся, что там будут страшные вопросы про хитрые моменты PHP, классы, архитектуру, greedy алгоритмы и жадные регулярки.
    А то я уже лет 7 не являюсь php разработчиком, и _НЕ_ должен пройти этот тест.
    (ну один пунктик одного вопроса я зафейлил)
    По факту вопросы были стартового для хакерранка уровня. Школа/Первый курс. Базовые алгоритмы (которые в принципе ЦА как раз может уже немного и забыть, кстати)

    Имхо тест должен быть такой, чтобы мог показать уровень кандидата, и отсеять как можно больше не ЦА.
    Тут же — половина задач не может быть автоматически обработано, и требует ревью живым человеком. Сложно.

    Я бы добавил бы пару примеров посложнее, и пару примеров которые можно решить сильно по разному. Например поиск подстроки в строке с ограничением по времени/большими строками.
    И/или задачу реализовать наследование обьектов под некую задачу. Хоть под многоугольники. Опять же первый курс, но можно подойти творчески.

    Идеал — когда основная часть народу не может решить половину задач, что позволяет отсеять самый сок. И даже с таким отбором 90% прошедших на самом деле люди не подходящие. К сожалению.
  • Mockанье зависимостей в node.js приложениях
    0
    Все верно —
    От каждого по способностям, каждому по потребностям.

    Если нет способностей, но есть потребности — rewiremock и аналоги помогут.
  • Mockанье зависимостей в node.js приложениях
    0
    У вас не совсем корректный пример. Точнее вы не правильно используете proxyquire.
    Ваш пример работает на основе паразитного сайд эффекта работы библиотеки, а точнее на основе странного поведения, когда после работы proxyquire в кеше модульной системы остается мокнутая версия process.
    Буквально в следущем тесте, когда вы уже будете ожидать «нормальное» поведение — вам прилетит сюрприз.
    Не делайте так. Очень много людей ночами не спали, все думали почему по одиночке их тесты работают, а все вместе — падают.
    Правильный код:
    const app = proxyquire.noPreserveCache().load('./app', { process: { uptime } }); // app с мокнутым process
    const app = require('./app'); // "настоящий" app, как и должно быть
    

    PS: В любом случае «нужный» app надо забирать из метода load, а не require. Даже если noPreserveCache вам не нужен.

    В то же время такой код нормален для rewiremock
    rewiremock('process').with({uptime});
    
    rewiremock.enable();
    const app = require('./app'); // app с мокнутым process
    rewiremock.disable(); // вычистит все затронутые модули
    
    const app = require('./app'); // "настоящий" app, как и должно быть
    
  • Mockанье зависимостей в node.js приложениях
    0
    И jest `мокает` так же как sinon. Это не перехват внутренней зависимости модуля, а внешней.
    Представим что вас есть код на реакте
     const someComponent = ()....
    
     const mapStateToProps = (state) => ({
       awesomeData: coolSelectorFromReduxStore
     });
    
     const ConnectedComponent = connect(connect(
      mapStateToProps
    )(someComponent);
    

    И вы тестируете именно ConnectedComponent. Ну бывает.
    Стандартные средства заставят вас собрать правильный store, обернуть все в Provider и все будет плохо. Там нечего мокать «напрямую». Все спрятано в файле и в тесты не светит.

    Rewiremock и компания же могут «по живому» перегрузить connect или coolSelectorFromReduxStore внутри файла, а не снаружи, и итоговый тест будет прост как три копейки.
  • Mockанье зависимостей в node.js приложениях
    0
    Я подразумевал живых людей из дельта окрестности. Библиотек то – на любой вкус.
  • Районы… Кварталы…
    0
    За прошедшие два года я успел: допилить геокодер, переписать регионы на es6, обзавестись третим сыном и переехать в Австралию.
    Чего не успел — добиться стабильной сборки геометрии одной командой с консоли.
    А osme некоторое время назад пришлось скрыть из-за некоторых моментов, которые не очень дружат с опенсорсом.
    В данный момент переписываю. В моих интересах выложить его куда либо, чтобы получить помощь других разработчиков и снять это ярмо(tech debt) с шеи.
  • Правила использования ARIA в HTML
    +2
    Вместо
    <button aria-hidden="true" style="display: none;">Don't Click Me</button> 
    

    Надо писать просто
    <button hidden>Don't Click Me</button>
    

    В том числе для любых скрытых через css элементов никаких aria-hidden писать не надо, так как элементы которые не присутствуют в render-tree так же не присутствуют в accessibility-tree.
    Вообще по «разделению» role=«presentation» и aria-hidden были долгие споры в интернете, так как оба этих подхода в итоге делают одно и тоже.
    Да и вообще 80% «правил» применений ARIA имеет под собой более философскую проблему, чем техническую.
  • Z-order vs R-tree, продолжение
    +1
    16 метров же?
    А обычный 32-ти битный Z код описывает квадрат по стороной 300 метров если его применять «world-wide». Достаточно для фильтрации большинства данных.