<font color=“color”> и стили внутри — вот за подобное я бы сразу заканчивал собеседование.
В то же время ничего не спрашивается о viewport, flex/float/table-cell; встречаются перлы типа
Да, существуют другие способы разделения текста. Можно использовать тег p или тег blockquote.
но при этом ни одного вопроса о display: inline/block, что является более важным для понимания, чем тэг br и <p>, поведение которого можно изменять стилями.
Я сначала даже не поверил, что подобные вопросы могут быть в 2020 году, подумал, может статья за 2008-2009, но даже тогда уже были распространены рекомендации «в HTML не должно быть никаких правил форматирования, делайте все в CSS».
Часто встречаю «Встраивайте критически важные стили в страницу». А что понимать под «критически важными» и как их отделить от менее важных в том же фреймворке Twitter Bootstrap, к примеру?
Возможно, кто-то посоветует статью на эту тему?
Для тех, кто решит использовать Clickhouse, небольшой момент. Да, одним местом прочитал документацию, но…
Clickhouse не любит множественные одиночные записи — это сильно поднимает нагрузку на сервер. Поэтому лучше записывать все в отдельный log (используя даже оперативную память, если не страшно потерять данные или отдельную таблицу в базе данных или более специализированных решениях), а затем с этого лога вынимать первые 5-10 тысяч записей, группировать их самостоятельно (если возможно), и только затем делать multiple insert. Это будет намного быстрее и эффективнее.
Со всей техники, которая у меня была, больше всего удивляет Amazon Kindle Paperwhite.
Я купил его в 2014 году, читаю в среднем 1-3 часа в день. Батарея жива (заряжаю раз в месяц, читаю почти всегда с подсветкой), что удивительно — устройство до сих пор поддерживается производителем и на него выходят прошивки с новым функционалом.
С того времени я успел сменить 3 телефона (устаревали морально, батарея сильно деградировала и т.д.), поэтому поддержка продукта за каких-то 150$ приятно удивляет.
Могу посоветовать писать с использованием ООП (который проще поддерживать команде и тестировать при грамотном подходе), но затем проверять «тяжелый код» с помощью xhprof.
Как-то я оптимизировал запросы к базе данных (так как считал, что это замедляет работу тяжелого скрипта), но не получал значительного ускорения работы скрипта. Оказалось, что самое большое замедление давало именно создание объекта ActiveRecord и затем миллионы вызовов __get к виртуальным полям. Да, пришлось переписать конкретно код с объектов на массивы (с потерей возможности работы с сущностями как объектами со своими свойствами), т.е., грубо говоря, вместо $obj->getParentName() писать Something::getParentName($obj), но за счет этого получил троекратное ускорение работы алгоритма.
Итого, все эти предположения — хороши, но всегда нужно смотреть фактическое употребление памяти и процессорного времени с помощью отладчиков в конкретных алгоритмах и получать приемлемую скорость.
Для многих задач — да, я его активно использую для автозапуска многих задач.
Но для наблюдателя над ходом исполнения программы — возможно, это не самое эффективное решение, хотя и довольно простое. Конечно, все зависит от программы, которая запускается кроном, но supervisord или systemctl в этом плане более заточенные.
А еще проще использовать тот же supervisord или systemctl, которые:
1) включаются вместе с ОС и имеют возможность запуска скрипта после запуска зависимостей (т.е., когда включилась база данных или обработчик очередей)
2) функция контроля (перезагружать ли после ошибки или штатного завершения работы, сколько попыток сделать, с каким диапазоном сделать перезапуск)
3) все это логгируется и вытаскивается через тот же journalctl
А сам скрипт исполняет работу и спит от 5 до 30 секунд. Чтобы не текла память, можно также завершать скрипт после получаса-часа работы, тогда systemctl автоматически включит задачу повторно.
Поэтому cron в этом смысле выглядит довольно странным и не универсальным решением.
К сожалению, эта картинка часто ходит в группах направленности: «От нас скрывают» с текстом: «а вы знали, что вот так на самом деле выглядит форма Земли?».
Поэтому решил уточнить, вдруг Вы тоже неправильно поняли это изображение.
Замечу, что это схематическое изображение карты гравитации земли. Реальная форма — это почти идеальный шар почти без видимых искривлений (да, немного приплюснутый, но незаметно). В космосе вы подобной формы как на картинке не увидите, посмотрите на любую спутниковую фотографию Земли.
Еще немного подтверждений: www.sciencealert.com/don-t-be-fooled-by-a-viral-gif-that-claims-earth-is-actually-lumpy-not-round
Там все регламентировано — и цвет, и размер.
Но деньги решают все. Оператор заинтересован в прибыли не меньше сайтов, так как обычно забирает до 60%, поэтому правила постоянно меняются в сторону «либерализации».
Раньше нужно было вводить номер и подтверждать подписку по смс, но это приносило меньше прибыли, поэтому и разрешили подписку в один клик.
Кстати, этим страдают не только российские операторы, но и по всему миру.
Когда в MySQL нужно накатить дополнительный индекс или добавить колонку в таблицу с 50 миллионами записей — в своем большинстве эти инструменты никак не подходят.
Впервые об этом я узнал, когда по неопытности локнул таблицу на 4 часа…
После чего приходится использовать percona-toolkit, которая создает временную таблицу с новой структурой, а на старую цепляет триггеры. Это позволяет делать редактирование таблиц без простоев.
Как я понимаю, эта проблема актуальна не для всех баз, но подобная ошибка может быстро отучить от использования миграций на больших таблицах.
Знаю, но вот один производитель, который здесь активно пиарится, имеет свой тип экрана, у которого мало того, что подсветка какого-то странно-синеватого цвета, так еще и неравномерная. Поэтому все же приходится сравнивать экраны, хотя понятно, что у большинства они почти те же.
Для меня всегда был и есть главный критерий электронной книжки — это качество экрана (сюда же включаю качество подсветки и скорость прорисовки).
Все остальное — приятные бонусы, но не более.
Своего времени на рынке мне больше всего понравился экран Kindle Paperwhite, и все недостатки памяти, форматов и функционала отошли на второй план.
Конечно, нужно более внимательно изучить, как там с экранами сейчас, но почему-то есть уверенность, что Amazon до сих пор в этом плане держат высочайшую планку качества.
Что и требовалось доказать. Публикация подобной статьи на популярном ресурсе обычному приводит к быстрому закрытию дыры.
Не знаю, чего вы хотели добиться этой публикацией — если подтолкнуть разработчиков к ее закрытию — тогда молодец.
Если же хотели поделиться рабочим способом получить список аудио — ну, сами сделали хуже.
В то же время ничего не спрашивается о viewport, flex/float/table-cell; встречаются перлы типа
но при этом ни одного вопроса о display: inline/block, что является более важным для понимания, чем тэг br и <p>, поведение которого можно изменять стилями.
Я сначала даже не поверил, что подобные вопросы могут быть в 2020 году, подумал, может статья за 2008-2009, но даже тогда уже были распространены рекомендации «в HTML не должно быть никаких правил форматирования, делайте все в CSS».
Возможно, кто-то посоветует статью на эту тему?
Clickhouse не любит множественные одиночные записи — это сильно поднимает нагрузку на сервер. Поэтому лучше записывать все в отдельный log (используя даже оперативную память, если не страшно потерять данные или отдельную таблицу в базе данных или более специализированных решениях), а затем с этого лога вынимать первые 5-10 тысяч записей, группировать их самостоятельно (если возможно), и только затем делать multiple insert. Это будет намного быстрее и эффективнее.
Я купил его в 2014 году, читаю в среднем 1-3 часа в день. Батарея жива (заряжаю раз в месяц, читаю почти всегда с подсветкой), что удивительно — устройство до сих пор поддерживается производителем и на него выходят прошивки с новым функционалом.
С того времени я успел сменить 3 телефона (устаревали морально, батарея сильно деградировала и т.д.), поэтому поддержка продукта за каких-то 150$ приятно удивляет.
Как-то я оптимизировал запросы к базе данных (так как считал, что это замедляет работу тяжелого скрипта), но не получал значительного ускорения работы скрипта. Оказалось, что самое большое замедление давало именно создание объекта ActiveRecord и затем миллионы вызовов __get к виртуальным полям. Да, пришлось переписать конкретно код с объектов на массивы (с потерей возможности работы с сущностями как объектами со своими свойствами), т.е., грубо говоря, вместо $obj->getParentName() писать Something::getParentName($obj), но за счет этого получил троекратное ускорение работы алгоритма.
Итого, все эти предположения — хороши, но всегда нужно смотреть фактическое употребление памяти и процессорного времени с помощью отладчиков в конкретных алгоритмах и получать приемлемую скорость.
Но для наблюдателя над ходом исполнения программы — возможно, это не самое эффективное решение, хотя и довольно простое. Конечно, все зависит от программы, которая запускается кроном, но supervisord или systemctl в этом плане более заточенные.
1) включаются вместе с ОС и имеют возможность запуска скрипта после запуска зависимостей (т.е., когда включилась база данных или обработчик очередей)
2) функция контроля (перезагружать ли после ошибки или штатного завершения работы, сколько попыток сделать, с каким диапазоном сделать перезапуск)
3) все это логгируется и вытаскивается через тот же journalctl
А сам скрипт исполняет работу и спит от 5 до 30 секунд. Чтобы не текла память, можно также завершать скрипт после получаса-часа работы, тогда systemctl автоматически включит задачу повторно.
Поэтому cron в этом смысле выглядит довольно странным и не универсальным решением.
Самая меметичная сова Рунета — Yoll (само видео)
Поэтому решил уточнить, вдруг Вы тоже неправильно поняли это изображение.
Еще немного подтверждений: www.sciencealert.com/don-t-be-fooled-by-a-viral-gif-that-claims-earth-is-actually-lumpy-not-round
Но деньги решают все. Оператор заинтересован в прибыли не меньше сайтов, так как обычно забирает до 60%, поэтому правила постоянно меняются в сторону «либерализации».
Раньше нужно было вводить номер и подтверждать подписку по смс, но это приносило меньше прибыли, поэтому и разрешили подписку в один клик.
Кстати, этим страдают не только российские операторы, но и по всему миру.
Впервые об этом я узнал, когда по неопытности локнул таблицу на 4 часа…
После чего приходится использовать percona-toolkit, которая создает временную таблицу с новой структурой, а на старую цепляет триггеры. Это позволяет делать редактирование таблиц без простоев.
Как я понимаю, эта проблема актуальна не для всех баз, но подобная ошибка может быстро отучить от использования миграций на больших таблицах.
Придумали ли какое-то решение для этого сценария?
Все остальное — приятные бонусы, но не более.
Своего времени на рынке мне больше всего понравился экран Kindle Paperwhite, и все недостатки памяти, форматов и функционала отошли на второй план.
Конечно, нужно более внимательно изучить, как там с экранами сейчас, но почему-то есть уверенность, что Amazon до сих пор в этом плане держат высочайшую планку качества.
Не знаю, чего вы хотели добиться этой публикацией — если подтолкнуть разработчиков к ее закрытию — тогда молодец.
Если же хотели поделиться рабочим способом получить список аудио — ну, сами сделали хуже.