• Тест новой периферии Logitech в условиях домашнего офиса. Конкурс в комментариях
    0
    У меня MX Keys, прекрасная клава, не без недостатков (тут упоминались все), но по совкупности самая любимая. А MX мастера не зашли (было два разных) и остановился на M330, которую тут не упоминали. Случайно купил как-то в аэропорту, и очень понравилась. Маленькая, лёгкая, бесшумная, в руку легла идеально. Единственно из трёх экземпляров один был слегка проблемный — ощущение, что колёсико цепляется иногда за что-то внутри.
  • Украденное резюме, человек, который ушел в Кемерово, призыв кандидата и другие истории трэш-собеседований
    0
    Не, не сложилось.
  • Украденное резюме, человек, который ушел в Кемерово, призыв кандидата и другие истории трэш-собеседований
    +9
    Не совсем интервью… или интервью, как посмотреть.

    Лет десять назад дело было, нашу небольшую команду активно сманивала фирма-конкурент. Мы удачно заняли нишу, в котороую они хотели влезть, и наш продукт был готов, а у них ещё конь не валялся. Ну я этого не знал в тот момент, и когда меня как руководителя пригласили интересно поговорить, через знакомых, пришёл.

    Красивый офис, пафосная техника, много сладких рассказов. Бескрайние поля опенспейса. Владелец сразу ведёт себе в кабинет, прямо с порога наливает «Курвуазье» и рассказывает как им у них хорошо, а если я приду, то и мне будет так же, а уж если с командой, то ух и вообще. Обещает сразу трёшку в новом доме, между прочим. Ну как обещает — в счёт контракта, на 7 лет льготная рассрочка. Каждому. Тут я насторожился. Виду не подал, конечно, но коньяка себе подлил.

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

    Ля-ля, заходит разговор о технических подробностях, стеке, вот этом всём. Владелец, явно считая, что всё уже на мази, сбрасывает тему на «а вот наш техдир, очень умный парень. На всех конференциях его все знают. Наш лучший работник! Он и расскажет». Техдир говорит — а пойдём покурим на крыльце, потрындим? Ведёт меня на улицу, потом, как-то явно стрёмаясь — дальше на природу. Ну мало ли, вдруг на крыльце датчики дыма…

    Некоторое время мнётся, а потом спрашивает — слушай, а у вас нет вакансии для меня? Сил нет как заколебало всё, давай лучше вы меня к себе возьмёте, а…
  • В какую сторону течёт вода?
    +17
    Аналогично. «Жду божественного откровения», «жду божественного откровения до таймаута», «жду божественного откровения до таймаута, затем принимаю интуитивно-обоснованное решение», «если вероятность 50% устроит, то сразу бросаю монету и получаю ответ»…
  • В какую сторону течёт вода?
    +2
    Зато будет основание требовать мидла на эту позицию. Сеньора нельзя, сеньор сам послать может.
  • В какую сторону течёт вода?
    0
    Тогда остаются только неинвазивные методы, как-то:
    1) электромагнитное поле (вода — проводник), если адамантий не экранирует
    2) поднять техническую документацию по водопроводу и посмотреть, если документация есть в природе
    3) найти в отделе человека, который делал эту фичу или знает, кто её делал, и спросить автора
  • В какую сторону течёт вода?
    +1
    Применение джуна это тоже компенсирует. Заодно ещё один тест-сьют пройдёт (или нет).
  • В какую сторону течёт вода?
    +23
    Вода там по ТЗ, но за давление принимается. Тогда так: «поручим джуну разрезать трубу и отойдём».
  • В какую сторону течёт вода?
    +15
    А вариант «щаз разрежем и посмотрим» — не подходит?
  • Почему лезвия бритвы затупляются после бритья?
    0
    Добавлю — Barbasol, как бритвы, так и пена. Перешёл с жилета (в разных странах покупал, всё примерно один и тот же фастфуд) и шика (из Японии, весьма неплохо, но приходилось долго ждать доставки лезвий и прочих аксессуаров) и барбом доволен больше всего.

    Речь о многолезвийных системах, если что.
  • Осторожнее с редактированием bash-скриптов
    0
    Воспроизводится.
    bash --version
    GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu)
    
  • Реверс-инжиниринг антиблокировщика рекламы BlockAdBlock
    0
    На закладке «Hide Posts» в текстовом поле для ключевых слов пишем строку «Suggested for You» и отмечаем все галочки — работает.
  • Реверс-инжиниринг антиблокировщика рекламы BlockAdBlock
    0
    social fixer
  • Обзор Dell U4919DW: ультраширокий 49-дюймовый монитор с изогнутым экраном
    0
    Не знаю, не знаю. Монитор выглядит неплохо, но у меня уже второй 43" 4к — мне лично удобнее видеть 4 fullHD в раскладке 2х2, а не длинной изогнутой полосой. Гибкости больше.
  • Почему стоит использовать Svelte для своих веб-проектов
    +1
    Да даже и размер может быть терпимым — сам реакт в проде 12,5Кб. Ну, правда, ещё дом почти наверняка понадобится, это ещё 120.
  • Angular для Vue разработчиков
    0
    Там вряд ли чем-то можно помочь =) сложный сетап, большой проект с 12+ годами истории. Я когда с разработчиками ангуляра общался на конференциях, так реакция была «нифига себе, что людям бывает нужно! мы даже не думали, что такое бывает! ну вы и извращенцы (шутка)»

    Но спасибо.
  • Angular для Vue разработчиков
    0
    Я работаю над библиотекой UI компонентов и если добавить в веб компоненты DI и проверку изменений, то практически всё, что я делаю можно без особого труда в них перенести не сильно меняя код.


    Ага, понятно. Если заниматься задачами такого рода, то да, действительно здорово похоже. Я имел в виду обычную, «дженерик» разработку — мидлов, клепающих формы в рамках предустановленной архитектуры.

    Впрочем, заранее соглашусь, что если человеку не интересно, что там внутри и почему, то среда не важна (и ангуляр тут в плюс, потому что не даёт совсем уж наговнокодить).

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

    Да, не типовые случаи — ну я и сказал, что для типовых обычно есть типовое решение.
  • Angular для Vue разработчиков
    0
    Очень интересное утверждение. Не могли бы Вы его обосновать? Просто у меня есть некоторый практический опыт с ангуляром (1.2-9), реактом, вью и вебкомпонентами, и я бы так не стал утверждать.
  • Angular для Vue разработчиков
    +1
    С ангуляром есть одна особенность — вы будете программистом на ангуляре. В смысле как «вы будете программистом 1С» (никого не хочу обидеть): язык составляет малую долю от знаний необходимых соглашений, декораторов, структур и приёмов. Да, быстро. Да, эффективно. Если не нужно что-то такое, о чём разработчики ангуляра не подумали за вас. И да, если вы развиваетесь так, как они придумали и всегда можете объяснить бизнесу «вот эта штучка противоречит политике фреймворка, так что нет». Очень удобно для фулстека, кстати, где фронт всё же на вторых ролях.

    Усреднённый энтерпрайз с гарантированым средним уровнем.

    Это не хорошо и не плохо, это особенность.

    ЗЫ Ну и, мне кажется, не стоит всё же сравнивать фреймворк с библиотеками.
  • Главные причины медленной работы Angular-приложений
    +1
    Ну вот мы мигрируем. У нас большой и старый (12+ лет местами) проект, ангулярЖС. Мы попробовали уйти на Ангуляр (с беты второго до релиза 7 продержались). Сейчас в итоге переходим на Реакт по многим причинам, главные из которых (сорри, что местами туманно) —

    1) недостаточно разработчиков на нашем «суммарном» стеке — нам не только ангуляр нужен.

    2) начиная с версии 6 стало очень неудобно пользоваться сторонним сборщиком. Он у нас сильно большой и сильно хитрый, потому что легаси, и отказаться от него нельзя по разным важным причинам, но в итоге CLI мы использовать не можем никак. С определённого момента ангуляровцы выпилили некоторые возможности API вебпака (я упрощаю) и часть нашего важного функционала сборки стала вообще технически невозможной. Чтоб хоть немного конкретики — например, предобработка исходника скрипта.

    3) несколько технических и организационных нюансов, в которые я вдаваться не буду, но которые в сумме хорошо так склонили чашу в сторону «не ангуляр».

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

    По производительности решения в принципе равны, да и по возможности контроля качества кода я бы не сказал, что кто-то реально побеждает — везде есть нюансы. По личным же предпочтениям… после 7 или около того лет ангуляра я теперь предпочитаю реакт.
  • Деревянные игрушки — эпилог, что осталось прибитым к потолку
    0
    Упс, пропустил, извиняюсь. Специально просматривал же =)
  • Деревянные игрушки — эпилог, что осталось прибитым к потолку
    0
    worms же
  • Быстрое введение в Svelte с точки зрения разработчика на Angular
    0
    Понятно, спасибо.
  • Быстрое введение в Svelte с точки зрения разработчика на Angular
    0
    Svelte намного мощнее React


    вот этот тезис можно развернуть?
  • Выбор размера монитора: теория угловых размеров, обоснование и сравнение
    0
    +1 Тоже 4к 43". Что интересно, на работе четыре монитора, точнее, 19 (квадрат)-24-24-19(квадрат) в линейке стоят, а дома 43" — и не могу сказать, как удобнее. И так, и так нормально, но на работе у меня на каждом мониторе свой… э-э-э… скоуп? ну, пусть будет тип задач — там сборщик, там IDE, там контрольная панель, там всякая корпоративная ненужная фигня, а дома по центру основное окно — по всему остальному полю прочее. Тут я хабр читаю — сбоку ребёнок мультик смотрит.

    То есть лично для меня иногда удобнее сегментированное пространство, а иногда бесшовная стена.
  • Микрофронтенды: о чем это мы?
    0
    Занимаюсь последнее время как раз этой темой. Автор пишет очень по делу, но только краем затрагивает пару очень важных вопросов: базовую среду микроприложений и общую UI-библиотеку. Почему это важно — потому что собственно загрузчики/оркестраторы довольно абстрактны и делаются на чистом JS/TS, контракты и общая шина (шины) тоже в общем-то проблем не представляют, а вот динамическое монтирование/отмонтирование в случае SPA сразу же ограничивает полёт фантазии…

    Но я так понимаю, это связано со спецификой SSR-ориентированной архитектуры у автора. Пойду почитаю, что там внутри.
  • Как мы учились рисовать тексты на Canvas
    +2
    Делал как-то чем-то похожую систему. Но там было больше извращений, потому что оно было для полиграфии и итоговый макет должен был стать PDF. То есть, pixel perfect, причём во времена IE9/10, плюс специфика.

    Так вот, об извращениях — on-site редактор текста при правке именно текста отображал «ну как-то похоже» (стили CSS в основном), а при уходе фокуса текст с метаданными уходил на сервер, где генерировался этот кусочек PDF, потом Imagick'ом это счастье из PDF рендерилось в PNG, и уже этот PNG с прозрачностью отсылался обратно клиенту, где вставлялся в контейнер слоя. Ну и превью страницы (полный PDF) обновлялся в фоне, как и текст при изменении масштаба, поворотах и тому подобных преобразованиях. Статические картинки считались на клиенте.

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

    Интересно, что несмотря на монструозность конструкции — всё нормально себе работало и даже с хорошей производительностью в продакшене. Задачи суб-рендеринга прекрасно кластеризовались и масштабировались, но даже этого особо не требовалось, потому что основной сервер и так тянул.
  • Быть фулстеком и не быть им
    +1
    … а человек, разбирающийся (действительно разбирающийся) в фундаменталке, называется евангелистом и к практической работе его лучше не допускать. Хотя для всяких PoC он реально незаменим.

    Думаю, что такие люди, которые твёрдо знают теорию и при этом так же твёрдо _нюансы_ практики, существуют, но я лично с такими не сталкивался. В смысле — сразу в нескольких областях, в узких темах специалистов много. Это ж ещё надо иметь довольно разный склад характера.

    Сам я клонюсь то в теорию, то в практику в зависимости от того, что мне сейчас интереснее (повезло, могу себе позволить) и в результате не знаю ни того, ни другого, а мне за это платят =)
  • Быть фулстеком и не быть им
    +1
    Ну, например, VCL, наличие и качество компонентов и удобство RAD. А также разница в скорости билда сибилдера и дельфи — дело было в ранних 2000х, на всякий случай, тогда это было очень-очень заметно. В приципе dll и сервисы писались у нас тогда время от времени и на Delphi, но для кросс-платформенных модулей вариантов, прямо скажем, было немного.

    А про класть формочки в dll — лучше не напоминайте, это была одна из моих тем в то время, плагинные системы и динамически подгружаемые формы. Ох, сколько она крови выпила…

    И таки таки формошлёпство на дельфи требовало совсем одного тулчейна и набора умений, а разработка слоёв апп-логики и бизнес-логики сильно другого. Даже людей нанимали совсем разных, ровно как во фронте/бэке сейчас.

    А, да, пока вспомнил: по моему мнению в нормальном современном энтерпрайз-вебе настоящий фулл таки очень редкая зверюшка. Потому что ну очень накладно знать, например, ангуляр 7 в обвязке (не на уровне туториалов, а понимая, что там внутре за неонка в деталях) и, скажем, цэшарп с дотнетом так же глубоко — и поддерживать эти знания актуальными сколь-нибудь длительный период.
  • Быть фулстеком и не быть им
    0
    У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.


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

    Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?


    Скорее первое, чем второе. Дельфя для формочек, Ся для .dll и .so. Совсем разные задачи и подходы (не то, чтобы совсем-совсем нельзя было всё сделать на чём-то одном, но это был бы явный изврат ради изврата, а когда апп-сервер на другой ОС, то и вообще. Хотя — и такое я встречал).
  • Быть фулстеком и не быть им
    0
    1) Почему «или»? «и». Имеет бэк (пул апп-серверов и за ним субд-сервера) и сам является бэком для веб-клиентов (планшетов).

    2) Ну так он же бэк для десктоп-клиента, или нет? По роли он практически совпадает с бэком для веба, если на то пошло, только протоколы разные. У меня в практике были даже апп-сервера с подключаемыми логическими модулями на жабаскрипте (wss, самодельные расширения для vb и js) — прям ноджысы какой-то.

    И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
  • Быть фулстеком и не быть им
    +1
    Ну вот пара вариантов, реальных, с больших энтерпрайз-систем.

    1) Десктоп-клиент держит в себе встроенный веб-сервер, к которому подключаются браузером саб-клиенты для специальных задач.

    2) Да собственно апп-сервер и есть бэк декстопа в multitier, нормальная практика, хоть и устаревшая по нынешним временам.
  • Готовьтесь: Angular 8 уже близко
    –2
    Из-за великолепия и экосистемы, очевидно. На мелких/средних проектах весь ангуляровский явный и неявный бойлерплейт и магия декораторов многих отпугивают. Да, писать легко, но держать всю эту экосистему и принципы в голове (если не постоянно) — очень тяжко. На средних/крупных проектах ангуляр = вендор лок, что тоже не очень радует.
  • Представляем «CLI Builder»‎-ы
    0
    Спасибо, интересно.

    Но вот непонятен такой момент как пайпинг. Простая задача: мне нужно в процессе сборки взять определённый файл в сыром виде, до любой обработки, выполнить эту самую некую обработку и отдать его дальше, в watch-mode — то, что в вебпаке реализуется с помощью Rule.use chaining и его внутренней виртуальной файловой системы — кэша, и то, что как минимум до текущей версии CLI было сломано в CLI-плагине.

    Вот, например, похожее issue: github.com/angular/angular-cli/issues/9559 давненько висит.

    Проблема (как минимум со связкой webpack 4, typescript, AOT) в том, что AngularCompilerPlugin игнорирует результаты предыдщих лоадеров и берёт оригинальный исходный файл с диска. Я понимаю, что это больше связано с кэшированием проекта tsc, а не ng, но до определённого момента были стандартные хуки, потом можно было написать файл-трансформер, а теперь остались только совсем хакерские методы прямой работы с AST но они не всегда в принципе возможны. Кстати, с актуальностью плагина тоже печальная ситуация.

    Есть ощущение, что «обычный» «прямой» вебпак-сборщик теперь вышел из моды и поддерживается по остаточному принципу. Но, может быть, я чего-то не заметил и теперь такой сценарий может быть реализован прямо из CLI?
  • Ускоряем сборку веб-приложения с webpack
    0
    Да, это приложение из кучи разных бандлов, которые физически собираются и разворачиваются отдельно — то есть, вебпак не сможет сделать нормальный тришейкинг в любом случае — но при этом пользуются общим стеком технологий. Ядро, свои библиотеки, внешние библиотеки и прикладные пакеты.
  • Ускоряем сборку веб-приложения с webpack
    +2
    Спасибо за статью! Явно очень большая работа проделана и много граблей истоптано в процессе. Как человек, много работающий с вебпаком, не могу не оценить.

    Я хочу вставить пять копеек насчёт подхода с externals. У меня под рукой есть один проект, где применён такой приём, там сделано таким образом:

    1. Файл с конфигом, что-то вроде такого —
    export const Externals = [
       {
           alias: 'React', 
           dev: 'node_modules/react/dist/react.js', 
           prod: 'node_modules/react/dist/react.min.js'
       },
       ...
    ]
    


    2. В самом webpack.config.js до собственно конфига довольно тривиальный код, который из этой структуры

    — делает собственно объект для поля externals
    — готовит список файлов для HTML/Webpack DefinePlugin (используется свой загрузчик ассетов, с фолбэком и излишествами)
    — копирует каждый целевой файл для текущего окружения в output.
    — ну и ещё пара трюков, которые проверяют, нет ли уже такого файла в месте назначения чтобы не делать лишней работы и быстрая грубая проверка через lstat совпадают ли размеры файла с источником на предмет «а вдруг с прошлого билда поменялась версия или переключили прод на дев».

    Это позволяет не париться с отслеживанием консистентности. Хотя сам подход, конечно, достаточно специфичен и нужно чётко понимать, когда есть смысл им пользоваться…
  • Вы не сможете решить эту задачу на собеседовании
    0
    С этим я тоже согласен, практическая применимость такой функции сомнительна. Я больше на тему «хорошо бы знать, как создаются объекты и в чём может вылезти разница» — вот это сеньору неплохо бы понимать.

    По мне, если соискатель ответит на вопрос «нет ли подвоха в этой функции», даже без примера, то это прекрасно.
  • Вы не сможете решить эту задачу на собеседовании
    0
    как по мне, неплохой вопрос сеньору, большой пласт поднимает
  • Вы не сможете решить эту задачу на собеседовании
    +2
    var d = Object.create(null, {'d': {value: 42, writable: true}})


    typeof d === 'object'
    isObject(d) === false
  • Функциональные компоненты с React Hooks. Чем они лучше?
    +1
    В следующий раз не забуду поставить тэги «ирония», «сарказм» и «шутка».