Apple WWDC 2018: текстовая трансляция

Нам говорят о деликатной теме — новостях. В связи с последними событиями её можно раскрутить на негатив. Поэтому модерация вполне логична.

А можно немного рассказать об этих последних событиях? Не обязательно подробности. Можно просто сказать, что погуглить.

Telegram попросит паспорт

не пробовали пользоваться нормальным телефоном наверное

На вкус и цвет фломастеры разные. Я, вообще, считаю, что нормальный телефон — Nokia 3310, потому что там нет ни Android, ни iOS. :)

Telegram попросит паспорт

Также Телеграм отлично работает с закрытым доступом к телефонной книге, смс итд. И даже без Gapps работает. Попробуйте провернуть это с каким-нибудь вайбер, ваццап или вичат — будете сильно удивлены.

Если у телеграмма убрать доступ к контактам на ios, список контактов в телеграмме сразу становится пустым (остаётся только история чатов). Для сравнения, в ватсапе можно один раз дать доступ, а потом его закрыть, и контакты ватсапа остаются на месте.

Вы просто не тестировали это, наверное.

Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm

Если не ошибаюсь, ситуации с такими названиями это ужесточение не покрывает: react-natiue, react-natiive, react-natjve и т.п.

Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm

Есть такое явление, как «typo-squatting». Можно добавить зависимость на пакет, чьё имя похоже на «оригинальный и полезный пакет». Это вполне может прокатить. Вот реальный пример: habrahabr.ru/company/ruvds/blog/335144

Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов

А как происходит отслеживание открытия средств разработчика?

Например, так:

var devtools = /./;
devtools.toString = function() {
  this.opened = true;
}

console.log(devtools);

if (devtools.opened === true) {
    alert('Панель разработчика открыта');
} else {
    alert('Панель разработчика закрыта');
}

Управление зависимостями в PHP

Ясно. Я, в основном всё-таки про отнаследование и переопределение метода говорил и про то, что одним переопределением метода это может не ограничиться, и поддержка этого кода в соответствие с кодом оригинальной библиотеки может требовать больше времени и внимания, чем кажется на первый взгляд.

Управление зависимостями в PHP

Я вас же процитирую:

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

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

Вы ничего про фиксированную версию не говорили в тот момент. Вы говорили про то, что подразумевается возможность обновления. То есть, вы советовали унаследоваться и переопределить метод, а потом спокойно дожидаться, пока придёт обновление. Я просто показываю минусы такого подхода.

Управление зависимостями в PHP

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

Пример кода

class ComposerLibDependency {
    public static function usefulMethod($a, $b) {
        return floor($a * $b);
    }
}

class ComposerLib extends ComposerLibDependency {
    public static function useMoreA($a, $b) {
        return self::usefulMethod($a * 3, $b);
    }

    public static function useMoreB($a, $b) {
        return self::usefulMethod($a, $b * 3);
    }
}

class MyLibPatch extends ComposerLib {
    public static function usefulMethod($a, $b) {
        if (!is_numeric($a) || !is_numeric($b)) {
            throw new Exception('Incorrect input');
        }

        return intval(parent::usefulMethod($a, $b));
    }
}

var_dump(MyLibPatch::useMoreA(2, 3.5));
var_dump(MyLibPatch::useMoreB(2, 3.5));

Метод MyLibPatch::usefulMethod() здесь в итоге не используется. Чтобы этот мой фикс использовать, нужно заодно переопределить методы useMoreA и useMoreB, по сути, заменяя в них только self на static. Если потом в них придут изменения из ComposerLib, они не отразятся, потому что я эти методы переопределил. Получается, мне нужно будет мониторить внешние зависимости, чтобы в эти переопределённые методы своевременно вносить изменения. Или, даже, если не вносить, то просто удостоверяться, что такое переопределение ничего не ломает в новых версиях билиотеки из композера.

Это просто к вопросу об отнаследовании.

Управление зависимостями в PHP

Критикал — ни разу в этом году. Из просто ошибок, которыми могу поделиться: этот и этот (плюс пулл-реквест, который приняли) репорты в Yii Framework.

Из того, всеми деталями чего не могу поделиться: фиксы в cordova-plugin-file-transfer, cordova-plugin-statusbar, react-dom.js (планирую попробовать отправить репорт и фикс, когда появится время, про ReactDOM.render, который возвращает не то, что должен, если вызывается внутри коллбека setState — нужно писать синтетический код для демонстрации — тот, который в проекте используется, показывать не могу), react-select.js (вообще выкинул после пары правок — проще и быстрее оказалось свою обёртку для <select> написать, чем натыкаться на постоянные грабли), sprintf.js (понимает %e, но не понимает %E + ещё несколько моментов, когда она работает не так, как в PHP).

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

Управление зависимостями в PHP

Я в моём подходе бремя тестирования беру на себя. Некоторое время назад меня впечатлила книга Г.Майерса «Надёжность программного обеспечения», особенно идея, что тесты нужны для поиска ошибок, а не для того, чтобы просто покрывать ими код или использовать их в качестве двигателя функционала (когда используется TDD). Так что, мне удобнее брать минимально возможное количества кода со стороны, чтобы потом приходилось меньше писать тестов, которые его пытаются сломать.

Ну и при подходе с композером никто не заставляет ждать цепочку «issue — fix — tag», всегда можете форкнуть и использовать форк до исправления ошибки.

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

Управление зависимостями в PHP

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

Я, в общем-то, особенно тоже не убеждаю. Просто я вижу минусы и их озвучиваю. Кто-то видит минусы в моём подходе и тоже их озвучивает. Лично меня такие диалоги хорошо развивают и дают возможность переосмысливать собственные подходы к разработке.

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

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

Конечно, можно отнаследоваться, но может получиться так, что, например, в классе, от которого я наследуюсь, статичный метод, который я хочу заменить, вызывается как self::method(), а не как static::method(), и в результате вызовы пойдут мимо метода, который я пропатчил в дочернем классе. Придётся тогда и те куски кода тоже в дочернем классе переопределять. А это приведёт к тому, что я больше не буду вызывать часть оригинального кода. Если в эти части придут какие-то изменения, я ими не буду пользоваться, а они могут быть полезными, либо могут как-то значительно влиять на полезность других методов, которые я использую. Мне в таком случае придётся дополнительно следить за кодом, который приходит при обновлениях, чтобы соответственно реагировать в моём дочернем классе. Это снижает ценность подключения и обновления библиотеки в автоматическом режиме — тратится больше времени.

Управление зависимостями в PHP

В том, что я не слежу за развитием библиотеки и вытаскиваю из неё, скажем, 5% кода, который мне реально потребуется, а остальное выкидываю из кодовой базы. А то, что осталось, я дополнительно тестирую самостоятельно. И если вижу ошибки, то я их могу мгновенно исправить, а не отправлять в цепочку: «создать issue на github» → «дождаться фикса» → «загрузить себе через композер», сидя на некорректно работающей библиотеке всё время, пока эта цепочка не завершится.

Управление зависимостями в PHP

При таком подходе, ИМХО, придётся следить за развитием билиотеки в обход композера, потому что иначе можно будет пропустить какое-то обновление безопасности (или просто фикс какой-то ошибки). Это кучу времени будет отнимать.

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

Лично для меня моя концепция лучше работает. Я её никому не навязываю. Она мне даёт больше плюсов, чем минусов.

Зачем я купил Mac Mini (Late 2012) накануне 2018 года?

Про смысл я не спорил — только хотел поправить по поводу цен на подписку. :)

Тем более, может быть это пояснение кому-нибудь ещё поможет. Я, когда покупал лицензию, сначала тоже видел корпоративные цены, потому что именно они по-умолчанию открыты, а не цены на персональные лицензии. Из-за этого чуть не начал пользоваться расширенным триалом, потому что 200 долларов в год за IDE — это дороговато всё-таки.

Управление зависимостями в PHP

У меня иногда бывали моменты, когда в начале проекта корневые неймспейсы часто появляются/удаляются, пока не устаканится какая-то определённая структура. Они, в общем-то, в composer.json прописываются, и чтобы autoload.php и прочие сопутствующие загрузчики перегенерировались, нужно запускать composer update

Управление зависимостями в PHP

если же вы хотите обновляемый пакет

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

К слову, мой подход приводит к тому, что я иногда в оригинал этого же пакета пулл-реквесты отправляю — из-за того, что внимательно смотрю, что именно принимаю в кодовую базу и как оно работает. По-моему, всем от этого польза. :)

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

Это вопрос надёжности ПО. У каждого свои критерии надёжности и того, сколько внимания он готов этому уделять. Есть примеры того, как откровенно вредный код может без вашего ведома подтянуться вместе с зависимостями. В общем-то, чем больше экономишь время, полагаясь на чужой код, который полагается на библиотеку, которая зависит от четвёртой библиотеки, тем выше риск получить нерабочий или уязвимый код.

Это всё не аксиома, и я не призываю фанатично чему-то следовать. Просто я вижу, что использование зависимостей может помогать тактически, но вредить стратегически.

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

Ну это пока пакет не обновляется а коллеги берут код с FTP

Я не совсем понимаю, причём тут FTP, если подключаемый код будет лежать в том же самом репозитории VCS. Я всегда считал, что FTP вместе с мамонтами вымер.

Управление зависимостями в PHP

Лично мне кажется, что copy-paste кода библиотеки лучше работает, чем включение этой библиотеки через Composer. Может быть, я неправильно что-то считаю, но у меня (пример ситуации) выходит так, что использовать код StringHelper из Yii Framework напрямую (удалив из него код, зависимый от HTMLPurifier) выходит выгоднее по времени, чем использование композера. На удаление лишних методов и зависимостей из кода я потрачу один раз несколько минут, и код раз за разом будет нормально работать. Но если я буду что-то включать через Composer, то через какое-то время получится, что на операции обновления зависимостей через него у меня затрачивается больше времени — оно [время] просто накапливается. Сегодня ушло 20 секунд на то, чтобы Composer прочекал все зависимости, завтра ушло ещё 20 секунд. Послезавтра ещё 30 (в новой версии билиотеки, в методе, который я никогда не буду использовать, появилась зависимость от другой библиотеки, которая, конечно же, загрузится и потянет за собой ещё какие-нибудь зависимости). В какой-то момент получится, что я мог потратить с самого начала 2 минуты на copy-paste и удаление ненужного кода, но, в итоге, я потратил за 2 месяца 30 минут только на ожидание, пока композер всё прочекает и обновит. (В итоге, за всю карьеру накапливается куча бесполезно проведённого времени, которое можно было бы потратить гораздо веселее — например, сметнуться в Новую Зеландию за презиками.)

(Теги, конечно же, не читал, потому что их никто не читает)

Ускорение сборки C и C++ проектов

Вам нужно было просто продать Macbook Pro и купить Macbook Mini 2012-го года для сборки (памяти на него накатить ещё, и SSD поставить)… Опыт хабрапользователей показывает, что скорость сборки вырастает.

Как расправиться с читерами и не переписать весь код

Я уточню: имитационный движок — это такая штука, которая работает и на сервере и на клиенте. Клиент отправляет событие и в свой имитационный движок и в имитационный движок на сервере. Имитационный движок на клиенте позволяет видеть прыжок ещё до того, как сервер пришлёт ответ о том, что он изменил какие-то состояния и кому-то разрешил прыгнуть.

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

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