• Изучение Go путём портирования небольшого Python веб-бекенда
    –2
    А почему вы это пишете мне? Это не я сказал, что паниковать необходимо при внезапно не сработавших вызовах к базе.

    И, очевидно, человек это придумал из-за крайне кривой и неудобной работы с ошибками в Гоу
  • Code review по-человечески (часть 2)
    0
    Я не суеверный. Наши отношения в наших руках)
    Просто я хотел сказать, что где два человека — конфликт вероятен, но не неизбежен)
  • Code review по-человечески (часть 2)
    +5
    Не захотел овертаймить в субботу и пошел на игру сына? Мужик!
  • Code review по-человечески (часть 2)
    +4
    Любой код ревью портит отношения между коллегами по разработке

    Знаете, а у нас код-ревью даже что-то сродни тим-билдинга и отношения наоборот укрепляются. Так что вы ошибаетесь.

    Проще взаимоотношения между разработчиком и тестером — они антагонисты по природе

    Тут вы, кстати, тоже ошибаетесь. Они как танк и хилер в играх. Когда я работал в Варгейминге мы с тестерами были одной командой и реально вместе работали над тем, чтобы сделать результат наиболее качественным. То есть я не воспринимал их как: «вот подлецы, баг нашли!», а как «класс, они нашли баг и игроки его уже не увидят».

    А из-за вашего категоричного заявления и невежества, которое вы проецируете на всех — вас и минусуют.
  • Code review по-человечески (часть 2)
    +2
    Где есть два человека, там конфликт неизбежен.

    У нас сейчас команда побольше и ревью просто прекрасные. Более того, мы притерлись к стилю друг друга, выработали хорошие практики и, в итоге, ревью значительно сократились. При этом с самого начала у нас не было ни одного конфликта на этой почве.
  • Code review по-человечески (часть 2)
    +3
    Можно было снизить планку по требованиям

    Объясните, пожалуйста, зачем снижать планку по требованиям? Если советы в код-ревью дельные, то их стоит учесть и исправить, но:
    — если это слишком сложно для новичка — он может попросить о помощи
    — если их аргументированость под сомнением — обсудить, аргументировать, пригласить других членов команды
    — если времени слишком много на исправление — обсудить с командой. Возможно, найти компромиссный вариант. Прям сейчас это время текущей задачи. И качественный код включен в это время. Если выбился за эстимации — это не означает, что необходимо жертвовать качеством, а означает, что необходимо улучшить эстимации. Потом, увы, времени на исправление не будет — будут в работе другие задачи. В крайнем случае серьезного дедлайна, конечно, качеством можно пожертвовать, но такие ситуации бывают редко.

    Пока это выглядит так: новенькой девочке было то ли лень, то ли просто обидки, а потому — она устроила саботаж на работе, убила 15-30 человеко-дней, испортила атмосферу в команде и… получила положительное подкрепление — работу по объемному фидбеку она так и не сделала.

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

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

    Короче решение из статьи — как писать в штаны на морозе. Сейчас тепло, конфликт вроде замяли. В средне-срочной перспективе — одни минусы.

    Должен заметить, что такое решение прекрасно подходит для низкосортных галер, где нанимают всех подряд, 3-6 месяцев из них выжимают все сроки с графиком 80 часов в неделю, а потом проект — толкают, команду — выбрасывают, поддержку отдают на аутсорс в Индию. Краткосрочный выигрыш от решения конфликта — крайне важен, а среднесрочные риски могут не успеть сработать.
  • Code review по-человечески (часть 2)
    0
    В армии это называется «дедовщина». Ну и что, что зубной щёткой драить сортир долго и мезко? Я «дед», ты — «салага», иди, драй.

    Нет, на дедовщину это совершенно непохоже. И мы не в армии.
  • Code review по-человечески (часть 2)
    +4
    Вотгда придёт пора менять что-то в этом коде — тогда и отрефакторите.

    Так вот — прям сейчас меняем. Вот пул-реквест открыт, еще даже до тестеров не дошло. Мы помним контекст, причину решений, у нас даже есть комментарии, что улучшить! В следующий раз всё это необходимо будет нарабатывать с нуля, то есть вы предлагаете просто выкинуть на ветер ресурсы, деньги на которые бизнес уже потратил. И все зачем? Потому что у кого-то корона мешает признать, что его код имеет недостатки?

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

    Плохое отношение к качеству сейчас — еще хуже отношение к качеству потом.

    константам не даны имена, копи-паста много или что-нибудь подобное.

    Ага, вот так сейчас: «а, хрен с ним, пока не печет». А через пол-года:
    — хнык-хнык, было 50 багов, закрыл 20, теперь 100 багов.
    — хнык-хнык, да, я фиксил этот баг, но оказывается, что мы его скопипастили 18 раз и каждый из участков немного менялся, потому надо пофиксить его 18 раз, а потом отдел тестирования должен будет внимательно проверить все 18 частей системы заново.
    — хнык-хнык, чтобы этот модуль заработал, надо переписать его с нуля
    — хнык-хнык, мы не сможем сделать это в срок, потому что программист, которому поручили работать с этим кодом сперва неделю плакал, а потом вышел в окно офиса на 7 этаже
    — давай, досвидания, пущай ваши джуны разгребают этот говнокодище, который оставил ни в коем случае не я, с наплевательским отношением к качеству, а папєрєдники.

    И всё это вы называете «я думаю про бизнес!»
  • Code review по-человечески (часть 2)
    +3
    Обычно в таких случаях необходима аргументация с каждой стороны и решение команды (иногда, в конфликтных ситуациях демократия — лучший выбор, ведь потом ВСЕЙ команде поддерживать этот).

    А детский сад из разряда «ты старая пердящая звезда, а я тут яркая молодая звездочка, потому нибуду делать, как ты сказал, сам так делай» — это крайне неконструктивно.

    Если команда не может договориться — это или саботаж, или детский сад.
  • Изучение Go путём портирования небольшого Python веб-бекенда
    –2
    В случае же с исключениями задача подобного «разделения обязанностей» возможена на программиста, который модулем пользуется — а он, зачастую, не знает толком: можно ли модуль как-то «спасти» или он безвозвратно испорчен.

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

    Ну вот к примеру, я формирую результаты боя в игре, для каждого юзера вызываю функцию `getStat(user)` из другого модуля, ее результат для меня не смертельно важен — если для каких-то юзеров она упала, я просто выведу знаки вопроса вместо циферок. И вот на Джаве — просто словил ексепшн и вывел вопросы. А программист на Го ведь самый умный, у него упал запрос к базе, который обычно не падает и он решает запаниковать. И вот весь расчет коту под хвост.

    А потому-что в Джаве хорошее, продуманное решение, а в Гоу — очередной мусор для хипстеров.
  • Как программисты-самоучки в реальности получают работу
    +1
    Маленькое качество разработчика. Называется «смелость». Смелость применить найденное решение. С моей стороны это недостающее звено о котором не говорится ни в каком учебнике по эволюции разработчиков.

    Я соглашусь с lair. Мне немного непонятен этот аргумент. Ты или понимаешь найденное решение, или не понимаешь. Если понимаешь, то зачем смелость? Если не понимаешь, то надо разобраться, понять и снова же — зачем уже смелость?
  • Как программисты-самоучки в реальности получают работу
    0
    Он сказал, что избегал его использования, потому что это фигня полная. Это не значит, что он не сможет поддерживать легаси — будет поддерживать и плеваться, а при возможности, перепишет по-нормальному

    Давайте формулировать правильно: «будет плеваться, потому что оно не соответствует его религии и вопреки мнению команды будет стараться написать так, как говорит пророк Абрамов из его секты».
  • Как программисты-самоучки в реальности получают работу
    +2
    А вы не думали, что возможно человек понимает о чем он говорит? Возможно человек адепт ФП парадигмы, а не ООП, и наследование в вашем понимании ему не интересно.

    Нет, не думал. Замыкания — не только ФП, Прототипы — не только ООП. И даже опытный человек, который в ЖС полностью отрицает ООП в пользу ФП — это человек, думающий модой, а не своей головой.

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

    Еще раз процитирую оригинал: «свойство prototype — знаю, но вообще никогда им не пользовался. код на прототипах убог есть же замыкания». То есть человек:
    1. Никогда этим не пользовался
    2. Верит, что знает
    3. Искренне уверен, что оно — убогое

    У нас почти во всех командах все были атеисты и я крайне сомневаюсь, что такой глубоко-религиозный человек бы прижился.
  • Как программисты-самоучки в реальности получают работу
    +13
    но код на прототипах убог есть же замыкания

    Сразу пока-пока такому человеку.
    Человек слишком мало знает как для мидла-синьйора
    И слишком высокого мнения о своих знаниях как для джуна — тяжело обучаться будет.
    Эффект Даннинга-Крюгера во всей красе.

    А если такая дыра в знаниях через 10 лет опыта, то он вообще необучаем.
  • 4 слова
    +1

    Можно пойти ва-банк:


    "У тебя клёвые сиськи"


    Менее эффективно, но более эффектно, если говорящий — девушка.

  • Полное руководство по написанию утилиты для Go
    +14
    есть ограничения, делающие эту возможность бесполезной для нас,

    Эти теги — один из примеров ущербности языка Go. Конечно, кое-какие проблемы вы исправили, но у них есть фундаментальные недостатки

    type Article struct {
    	Text string `json:"text,omitempty,string" xml:"foo"`
    }
    


    Во-первых, просто отвратный синтаксис, который заставляет писать все теги и их свойства в одну строку. WAT? Автор, ты это сделал специально, чтобы ими было неудобно пользоваться? Но, допустим, это вкусовщина.

    Значительно больнее — во-вторых: они динамичны. WAT? Это go или php? Та даже декораторы в JS и то адекватнее! Никакой проверки ошибок в компайл-тайме. Более того, ее даже толком в ide и рантайме нету (как в JS). Я могу написать «omit-empty» вместо «omitempty» и оно просто будет неправильно сериализовать JSON. WAT? Как результат — никакой документации в IDE. Хочешь узнать, какие теги можешь использовать — лезь в документацию. WAT? Какие опции? В документацию! WAT?

    В дополнение я просто процитирую статью:
    * структурный тег — это строковый литерал
    * Настройка опций не описана в определении

    То есть каждая либа придумывает такой формат, какой ей удобен.



    Автор может и исправил пару недостатков тегов, но не исправил их фундаментальный недостаток. Какой тег использует либа — указано где-то в середине ее функции на 1110 строке огромного файла посреди кучи говнокода.

    Автор языка, за что ты так ненавидишь программистов на Go?

    Неужели нельзя было сделать как-нибудь статически-типизированно?

    type Article struct {
    	@xml.Tag{ key:"foo" }
    	@json.Tag{ key:"text", omitempty: true, string: true }
    	Text string
    }
    


    Или, если хотелось бы уйти от ужасного C# и написать в стиле богоподобного Go в одну длинную строчечку:

    type Article struct {
    	Text string [2]struct{ xml.Tag{ key:"foo" }, json.Tag{ key:"text", omitempty: true, string: true } }
    }
    
  • Смена пола и расы на селфи с помощью нейросетей
    0
    Мне одному кажется что это похоже на западную пропаганду транссексуализма?

    Лол, я как раз хотел сказать наоборот — этот фильтр жуткий шовинист с кучей гендерных и расовых стереотипов! Особенно оскорбительно он видит «White» людей!
  • Простой плагин для локализации приложений на Unity3D
    +1
    В комментариях выше подсказывали вариант создавать enum с возможными значениями

    Это все-равно в Юнити неудобно, т.к. элементов локализации в игре сотни — выбирать один из списка занятие неблагодарное.
  • Как я научился напрямую перезагружаться в нужную ОС через UEFI
    0
    Тоже помню такое. Если не ошибаюсь — где-то в районе Кубунту 13.
  • Простой плагин для локализации приложений на Unity3D
    +3
    удобнее использовать целочисленный
    Чем удобнее?

    Кроме того — поиск чуточку быстрее за счет сравнения)
    Вы ведь так шутите, да?
  • Простой плагин для локализации приложений на Unity3D
    +2
    Цифровой айдишник ведь крайне неудобно. Почему бы не сделать что-то вроде «Units.HeavyTank.Title» в качестве айдишника?
  • Чем хорош (и чем плох) Typescript: опыт UI-разработчиков
    0
    Идеология TypeScript в корне противоречит функциональному подходу принятому в React и использовать их в такой связке неверно.

    Псевдо-функциональный подход принят исключительно в Редаксе. Реакт — вполне себе мультипарадигменный и даже больше ООПшный, чем ФПшный. Мы его использует с TS и MobX, и не знаем бед — у нас ВСЕ статически-типизированно, никакого сомнительного кода.
  • За что я люблю именно Mithril (он же MithrilJS)
    –1
    Опять же, бенчмарки подтверждают скорострельность инструмента, а в Chrome Development Tools видно, что страницы не грузят процессор

    Бенчмарк странный — он в цикле кликает на 50 элементов, соответственно нету смысла перерисовывать по одному элементу и перерисовка всей страницы выгоднее.
    В реальной жизни будет происходить клик по одному элементу 50 раз и в реальной жизни в Мифриле будет в 50 раз больше перерисовок, чем в Реакте
  • За что я люблю именно Mithril (он же MithrilJS)
    0
    То есть, пусть считает когда надо, на скорость UI не повлият.

    Почему не повлияет? Да, множество запросов стекаются в один и рендерятся только во время рендеринга кадра, но из-за большого дерева вполне может тормозить. То есть, скажем, у нас дерево рендерится 500 мс. Да, если вызвать forceUpdate трижды, то рендер будет длиться 500 мс, а не 1500. Но это не значит, что ЮИ не тормознет.

    В идеале — если поменялись пропсы/стейт компонента — этот компонент нужно перерендерить, при этом у его дочерних компонентов перерендеривать только те, у которых поменялись пропсы/стейт. Тогда будет минимум пересчетов.

    Также он не пересчитывает VDOM для компонентов, которые в данный момент не отображаются на уровне роутера

    Ну это само собою разумеется.
  • Список лучших инструментов для web-анимации
    0
    Нет, лично я имею ввиду создание нативных приложений. Та игра, которую я делаю — весит под два гига и требует технологий, которые WebGL не тянет. Хотя у меня товарищ делает игрушку, экспортит в ВебГЛ и не жалуется.
  • Список лучших инструментов для web-анимации
    0
    Мне лестно, конечно, но он, к сожалению, уже малоактуален.
    Лично я в последний раз, когда нужен был именно JS-фреймворк использовал Pixi. За счет WebGL он очень быстро работает.
    Но вцелом я предпочитаю Unity — там и язык получше (C#) и движок игровой значительно мощнее.
  • Реализация «Тетриса» в игре «Жизнь»
    0
    Чтобы запустить глайдер необходимо, допустим 23 клеток по высоте и 24 клеток по ширине.
    Каждая мета-мета-клетка состоит из 211*211 метаклеток, каждая из которых из 211*211.

    Следовательно, необходимо 23*24*211*211*211*211 = 251 бит = 248 байт = 256 терабайт памяти. Лет через 20 можно будет поиграться.

    Я нигде не ошибся?

    Кстати, а сколько поколений необходимо на смену одного мета-поколения?
  • Чем хорош (и чем плох) Typescript: опыт UI-разработчиков
    0
    3 не совсем корректно PropTypes проверка работает только в dev

    А если мы хотим один из этих пропсов передать во внешнюю функцию? Ну типа того же mapReplace, что повыше. Вы как будете пропТайпами типизировать?
    Зачем этот сломанный костыль, если есть адекватное решение, которое работает на всем коде, а не только там, где повезет?
  • Чем хорош (и чем плох) Typescript: опыт UI-разработчиков
    +1
    Когда в аргумент передается функция все становится тяжело

    Ну что вы хотите, писать на «фп» и чтобы у вас из ноги кровь не текла? Тут или одно или другое

    И как вам такое? Сходу понятное?

    Мне меньше всего понятен смысл этого: (A | U)[]. Зачем массив с двумя разными типами? Как с ними работать вообще? То есть вот у вас есть A[], с ним понятно как работать, а потом, после этой функции в этом массиве начинает попадаться то A, то U. А потом как? if (x instanceof U) ? Код, конечно, не самый изящный, но проблема скорее в архитектуре.

    Плюс еще названия. A и U — просто рандомные буквы? Вот так было бы значительно понятнее:
    export function mapReplace<TCurrent, TReplace>(
      array: TCurrent[],
      test: (item: TCurrent) => boolean,
      replacement: (item: TCurrent) => TReplace
    ): (TCurrent | TReplace)[] {
        return array.map(item => test(item) ? replacement(item) : item);
    }


    Никогда не понимал, почему некоторые к именованию дженериков относятся так наплевательски. Переменная у вас ведь названа не a, а item. Впечатление, что это специально, чтобы потом жаловаться, что дженерики такие непонятные.

    Проблемы с этим кодом две — неправильная архитектура и именование переменных. Как видите, TS в этом списке нету.
  • Реализация «Тетриса» в игре «Жизнь»
    0
    А реально запустить «Жизнь» на этой версии «Жизни», которая запущена на «Жизни»?
    Если да — насколько мощнее комп должен быть? Какие там порядки?
  • Премирование vs депремирование
    0
    Ну я же сказал, что пошутил про увольнение. От того, что уволишь виноватого база не восстановится.
  • UX-дизайн: 50 вещей, которые вы наверняка забыли сделать
    +1
    только корпоративный и на него зарегистрировано все, от ВК до аккаунта в научных журналах.

    Классическая ситуация. И тогда подобная «мера защиты» совершенно бессмысленна
  • Премирование vs депремирование
    0
    Ну потому что сделать так, чтобы таких факапов не было — задача менеджера. Разработчик — человек и ошибки само собою разумеются.
  • Премирование vs депремирование
    0
    Пошутил я про увольнение. Увольнять людей надо только в крайнем случае. Идея была в том, что вина тут исключительно на менеджере, а не на программисте, если разве что тот не устроил целенаправленный саботаж.
  • UX-дизайн: 50 вещей, которые вы наверняка забыли сделать
    +1
    Да, но если моя мама там не зарегистрирована вовсе — она заподозрит неладное.

    Вы говорите об атаке с анализом личности, а потом оказывается, что все, что знает злоумышленник — это емейл. Тут скорее вашей маме необходимо бояться нигерийских принцев. Моя мама до слез со мной ругалась, потому что говорила: «ну откуда ты знаешь, вдруг он и правда хочет нам подарить 10 миллионов, всякое бывает». Ваша «атака» — она имеет слишком много «если» и слишком мало «зато», чтобы рассматривать ее серьезно.

    А вы не находите что показывать сообщение «данный имейл у нас отсутствует» и есть это самое действие бабушки, которое вы повторяете? (:

    Не нахожу, потому что «емейл или пароль неизвестен» — это та псевдо-безопасность которую все повторяют словно попугаи. На всех сайтах, блин. И совершенно бессмысленно!
  • UX-дизайн: 50 вещей, которые вы наверняка забыли сделать
    0
    Желающие этого избежать используют более одного емейла.
  • Убираем радиальное искажение с фото и видео при помощи библиотеки openCV и языка python
    0
    Супер! Спасибо
  • UX-дизайн: 50 вещей, которые вы наверняка забыли сделать
    +1
    «На таком-то популярном сайте (ВК/Ютуб) разыгрываются призы. Отправьте СМС ХХ на номер ХХХ и вы...».

    А такая атака будет успешной даже если ваша мама зарегистрирована на ВК под другим емейлом (у моей мамы вот регистрация там еще на емейле от рамблера, но если ей придет такое сообщение на гмейл аккаунт — она ничего не заподозрит), так что совершенно не аргумент.

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

    Вы как в том анекдоте про швабру:

    Пожилая еврейская пара готовится ко сну.
    — Изя, ты закрыл калитку?
    — Закрыл, Соня, закрыл.
    — А дверь ты закрыл?
    — И дверь закрыл.
    — А на английский замок?
    — И на английский замок, Соня.
    — А на бельгийский?
    — И на бельгийский закрыл.
    — А на засов?
    — И на засов закрыл, Соня.
    — А на цепочку?
    — И на цепочку тоже.
    — Изя, а швабру ты подставил?
    — Ой! Швабру, кажется, забыл.
    — Ну вот! Заходи и бери, что хочешь!


    Вот все упорно продолжают ставить швабру с этой глупостью и плевать, что об нее чаще спотыкаются обычные жители вместо того, чтобы хоть как-то защищать от мошенников. Но швабру надо поставить, потому что бабушка так делала.
  • UX-дизайн: 50 вещей, которые вы наверняка забыли сделать
    +1
    Есть значительно более простые способы собирать базу имейлов.
    Тем более для того, чтобы какой-то емейл проверить — его необходимо иметь. Не проще ли просто послать письмо, чем использовать сомнительный способ проверки на одном из сайтов?
  • Убираем радиальное искажение с фото и видео при помощи библиотеки openCV и языка python
    –1

    Что значит "в следующий раз"?? У вас кнопка редактирования отвалилась? Сейчас исправьте, а не оставляйте халтуру навсегда.