Писать свою либу для этого - это сложная затея. В примерах вы генерируете файлы, а потом читаете их же. Но в рельной жизни, вы генерируете файлы, а читает их кто-то другой (это ещё не страшно), а вот когда генерирует файлы кто-то другой, а вашей либе надо их прочитать - вот тут начинается веселье.
Календари крупных компаний вообще ушли от этих стандартов, и у них для синхронизаций есть собственные нативные API. Да, они поддерживают импорт и экспорт, но и у них не всё так гладко. При переносе ивентов с айфона на андройд или обратно, могут появляться артефакты.
А данные, врутри этих файлов далеко уходят за спецификацию календарей. Чего только стоит одно только переименование Kiev в Kyiv. Ещё не факт что вам нормально удастся читать все часовые поеса всех операционных систем.
Чем субъективная оценка отличается от очень субъективной?
Разница субъективна :D
Но, я вложил в это понятие какую-то нотку нетерпимости к чужому мнению.
Что-то типа: эта статься ужастна, потому что автор - араб, ведёт заметки справа налево, хотя все остальные авторитетные авторы, ведут заметки правильно - слева направо.
Раньше было легче найти материал на основе которого ты мог что-то сделать, попробовать. Сейчас же приходится продираться через материалы, которые в лучшем случае ничего не дают и в худшем вводят в заблуждение.
Так тут проблема не в качестве материалов, а в вашей копетентности. Раньше, нормальные видео про obsidian длились по 3 часа, где автор разжовывал каждый плагин, систему и метод работы со всем этим делом. По сути было длинно и примитивно. Это создавало какой-то порог входа, и в обсидиане небыло "криэйтеров". Если вы уже прошли через это, конечно вам будет не интересно смотреть то же самое, но укомплектованное в 15-минутку, где автор вскольз говорит нажимать ctrl+n, опуская "важные детали".
А вы попробуйте найти какой-то старый материал, настолько крутой, как ваша предыдущая статься про GTD в обсидиане. Раньше такого и близко небыло. Это уже сравнимо с тем, как в своё время в майнкрафте делали эмуляторы процессоров :D
Вот и получается, что среди нового материала всё сложнее отрыть что-то интересное, потому что вы уже и так всё знаете, и сами стали локомотивом интересного материала.
Кстати, из относительно недавнего мне ещё понравился этот парень. По сути, пользы там мало, но оч красиво получается :D
Очень субъективная оценка. Автор оценивает не "качество" материала, а полезность этого материала по отношению к самому себе.
Подборка сильно уходит за рамки Obsidian, и больше относится к ведению заметок в целом.
Автор считает, что раньше материал был лучше, но признаёт, что это может звучать как "гундёж" старого человека. Думаю, материал стал лучше, просто материала стало много, и от изобилия можно вертеть носом.
Безумие :) Я даже в заключении сравниваю это дело с шапкой из фольги.
Вдохновлением на эти размышления мене послужил Путин, у которого нет девайсов.
Мне стало интересно, а может ли обычный человек не иметь девайсов, при этом иметь онлайн приватность, получая к ней доступ через публичные устройства.
Будто хиппи, живущий в лесу и питающийся солнцем и улыбками, который в любой момент может в халате придти в библиотеку, сесть за публичный компьютер и оплатить налог за собственную землю.
Ну да, суть кейса именно в том, чтобы авторизоваться через взломанное устройство в неизвестной для нас сети. Кейс такой, что хакеры видят и трафик, и нажатия, и клипборд, и вообще всё, что только можно (включая видео с вебки, и видео с камер видеонаблюдения в помещении, где вы используете устройство.
При этом, после авторизации нам надо либо прочитать какие-то данные, которые нам нужны в данную минуту, либо отправить куда-то какие-то данные. Да, хакеры смогут прочетать тот кусок, который мы будем читать, но не смогут прочитать остальные данные. Да, хакеры смогут увидеть данные, которые мы отправляем, но они не смогут сами отправлять данные от нашего лица без нашего ведома.
Пример из реальной жизни - поход на вершину горы, где вы не берёте с собой ничего лишнего, что бы выжить, но пользуетесь общественными девайсами в точках лагерей. Другой пример, - путешествие на коробле, через море, где выход в интернет строго контролируется. Хотя, по сули, в обоих случаях можно иметь при себе физический TOTP токен, который весит всего пару грам.
В схеме с одноразовым словарём из какого-нибудь текста, меня смущает 2 вещи:
надо помнить какие слова уже использовались, а какие ещё нет
после 5-ой авторизации, слов может быть достаточно, что бы найти исходный текст
На случай, если Хабр недоступен глобально, сервер тоже это увидет, и может переключиться на другой резервный портал. Если же, серверу Хабр доступен, а вам - нет, то тут сложнее.
Тоже об этом думал. Предположил, что можно внедрить что-то вроде временного кэша. Т.е. авторизоваться можно по любой статье за последние 5 минут. Но вообще, это проблема, если использовать блокировку при 2-3 неправильных вводах.
Да, токен MFA - это саое безопастное и удобное решение.
Зачем тогда придумывать всё это? - что бы избавиться от зависимостей. Токен надо тоскать с собой. Токен не везде можно подключить (например в публичных компах, где в целях безопасности отключен USB). Токен можно забыть или потерять. Токен можно украсть, после того, как кейлоггер запишет ваш пин :D В общем, шапка из фальги нужна...
Я слукавил, сказав, что "удалил приложение". Это предустановленное приложение. Телефон не рутованный и удалить его нельзя, можно только "отключить". Спрос к заводским настройкам, наоборот, включит и установит это приложение. И вероятно, эта несанкционированная установка - какая-то ошибка какого-нибудь менеджера приложений, которое, не знаю... включила приложение? :D
Просто, чем больше я копаюсь в интернет-безопасности, чем больше читаю о приватности, тем больше осознаю, что "безопасных" устройств нет.
Тем более, продвинутый шпионский софт, явно не будет заниматься такой ерундой, как установкой приложения социальной сети.
Постулат: отсутствие информации об алгоритме шифрования не повышает его критостойкость
Если речь идёт о шифровании, то да. Но в данном случае в конечном варианте идеи - хэширование. А в центре внимания - не шифровка данных, а авторизация. Если авторизироваться не так часто, то у второй стороны не соберётся достаточно данных для реверс инженеринга. А попытки брутфорса приведут к блокировки.
Но вообще, я с вами согласен, потому и опубликовал статью (раскрыл алгоритм) :)
Ну... в реальной жизни TOTP на отдельном девайсе встречается крайне редко. Аппаратные ключи почаще. Но массовый кейс использования - это TOTP на телефоне. И при этом люди носят с собой только 1 телефон, и при этом на телефоне авторизируются, нарушая многофакторность.
Статья - просто мысли в слух, о том, какая могла бы быть альтернатива.
Полистал вашу ленту, пооткрывал случайные стати. Во всех статьях есть ссылки. Где-то на ваши же статьи, где-то на фильмы, где-то на википедию и т.д.
Возник ли вопросы:
Чем больше пишешь, тем больше начинаешь ссылаться на себя же?
Насколько быстро появляются новые источники? Т.е. невозможно же ежедневно впитывать в себя кучу новой информации (или можно?) И наверняка, отсылки на фильмы - это фильмы, которые были просмотрены до того, как вы начали писать. Ведь выденяя по 2 с половиной часа ежедневно на одно только написание статей, в вашем графике врятли есть время на свежие фильмы?
Возможно я употребил неправильную терминологию. В доках на русском это называется пространства имён.
Ну и суть в изоляции имён функций, что бы небыло конфликтов, наприер с импортируемыми библиотеками.
Например a.php:
<?php
namespace my\functions;
function hello() {
echo "world";
}
b.php:
<?php
use function \my\functions\hello as privet;
include("a.php");
\my\functions\hello(); //world
privet(); //world
hello(); //PHP Fatal error: Uncaught Error: Call to undefined function hello() in b.php:11
Я бы ещё добавил сюда пару абзацов про области видимости (namespace), и что с ними тоже можно играться при построении грамотного процедурного кода.
Вспомнился небольшой забавный проектик, когда я пробовал переписать Symfony на процедурный стиль с целью более глубокого изучения symfony и попыткой доказать, что без ООП тоже можно жить: git
Сухая теория. Если б не примеры, я бы вообще не понял в чём сути.
А ещё я не понял в чём разница OKR от обычной работы любой компании, но глянув статью на википедии, вроде понял.
А можете немного рассказать о личном опыте? Когда внедряли? Как внедрилось? Какие результаты? Где подводные камни? Какой софт используете и как его настроили для OKR?
А можно, возможно глупый, вопрос: как маштабируют эти модели? т.е. если всё так упирается в железо, то как ChatGPT так быстро работает? Эти модели как-то можно запускать на кластерах из серверов?
Недавно тоже делал замеры программы на Go. Написал простенький алгоритм, который преобразует числа в слова (например "15" в "пятнадцать" с поддержкой двух языков). Консольное приложение.
Замерял через баш скрипт. Сразу получил какие-то дикие числа в 200 мс в среднем за один прогон. Потом выяснилось, что баш скрипт даёт оверхед на виндовсе. Переписал скрипт за мера да Go. Число упало до 60 мс в среднем за прогон.
Но и это было дикостью для такого простого алгоритма. Тогда начал анализировать не среднее число, а каждый прогон по отдельности. Выяснилось, что первый прогон из-за инициализации чуть ли ни в 10 раз дольше всех остальных и сильно сдвигает среднее.
Убрал учёт первого прогона. Получил уже более приемлемые 5-6 мс за прогон в среднем.
Но и тут я был очень не доволен. "быстрый язык, говорили они". Какой же он быстрый, если на таких простых операциях расходиет 5 мс? - подумал я.
Скоприрол код на Ubuntu сервер, скомпилировал и запустил. Средний прогон выполнялся за 1 мс, даже с учётом инициализации, которая заняла 5 мс. Вероятно даже алгоритм работал быстрее, но у меня заканчивалось свободное время и я не стал адаптировать замерочный скрипт под микросекунды.
Загуглил, и да, на форумах пишут, что Go больше заточен под *nix системы.
Отсюда, возникает вопрос к автору: если все говорят, что Go быстрее PHP, но у вас по вашим замерам выходит наоборот, что вы сделали, что бы понять почему ваш результат отличается от общего мнения?
Статья огонь, советы огонь, но, как и в предыдущех статье, хочется придраться с этой "эффективности" на микро-операциях.
1) нельзя при подсчёте годового сэкономленного времени перемножать на 52 недели, т.к. есть отпуска, праздники, а иногда и больничные.
2) предположим, вы экономите на алиасах 1 минуту в день. Это 4 часа в год. За 4 часа, например, можно написать онлайн конвертер валют, который будет считывать актуальные курсы с публичного xml. Такой, небольшой пет-проектик. Вопрос, сможете ли вы его написать, имея только 1 минуту в сутки? Вот, каждый день, в 16:59 начинаете работу и в 17:00 заканчиваете. Получится ли через год результат?
Что бы закончить на позитивной ноте, вот ещё один пункт по улучшению производительности:
Вы уже используете github copilot - круто. Но он помогает именно в задаче написания кода. А для поиска решений можно использовать ChatGPT. Т.е. приходит вам задача. Вы её читаете и сразу понимаете, как её выполнить. Но вместо того, что бы её выполнять, вы описываете её своими словами в ChatGPT и спрашиваете, как решить эту задачу. Звучит, как уменьшение эффективности, но при переписании задачи вы её лучше поймёте и сможете задать нужные вопросы ПМу. А решение от GPT может расширить ваше личное решение, т.к. 2 головы всегда лучше чем одна. В итоге мы как бы получаем краткосрочные затраты времнени, но долгосрочную экономию, т.к. задача будет выполнена значительно качественнее. По сути это относится в Lean Development (https://ru.wikipedia.org/wiki/Бережливая_разработка_программного_обеспечения)
А вы читали ответ о циклах в этой статье? Ни слова про ООП, ядро, мидлвэр, шаблонизацию, orm. Зато целый абзац про композер. Серьер бы точно так не отвечал.
Писать свою либу для этого - это сложная затея. В примерах вы генерируете файлы, а потом читаете их же. Но в рельной жизни, вы генерируете файлы, а читает их кто-то другой (это ещё не страшно), а вот когда генерирует файлы кто-то другой, а вашей либе надо их прочитать - вот тут начинается веселье.
Календари крупных компаний вообще ушли от этих стандартов, и у них для синхронизаций есть собственные нативные API. Да, они поддерживают импорт и экспорт, но и у них не всё так гладко. При переносе ивентов с айфона на андройд или обратно, могут появляться артефакты.
А данные, врутри этих файлов далеко уходят за спецификацию календарей. Чего только стоит одно только переименование Kiev в Kyiv. Ещё не факт что вам нормально удастся читать все часовые поеса всех операционных систем.
Разница субъективна :D
Но, я вложил в это понятие какую-то нотку нетерпимости к чужому мнению.
Что-то типа: эта статься ужастна, потому что автор - араб, ведёт заметки справа налево, хотя все остальные авторитетные авторы, ведут заметки правильно - слева направо.
Так тут проблема не в качестве материалов, а в вашей копетентности. Раньше, нормальные видео про obsidian длились по 3 часа, где автор разжовывал каждый плагин, систему и метод работы со всем этим делом. По сути было длинно и примитивно. Это создавало какой-то порог входа, и в обсидиане небыло "криэйтеров". Если вы уже прошли через это, конечно вам будет не интересно смотреть то же самое, но укомплектованное в 15-минутку, где автор вскольз говорит нажимать ctrl+n, опуская "важные детали".
А вы попробуйте найти какой-то старый материал, настолько крутой, как ваша предыдущая статься про GTD в обсидиане. Раньше такого и близко небыло. Это уже сравнимо с тем, как в своё время в майнкрафте делали эмуляторы процессоров :D
Вот и получается, что среди нового материала всё сложнее отрыть что-то интересное, потому что вы уже и так всё знаете, и сами стали локомотивом интересного материала.
Кстати, из относительно недавнего мне ещё понравился этот парень. По сути, пользы там мало, но оч красиво получается :D
Очень субъективная оценка. Автор оценивает не "качество" материала, а полезность этого материала по отношению к самому себе.
Подборка сильно уходит за рамки Obsidian, и больше относится к ведению заметок в целом.
Автор считает, что раньше материал был лучше, но признаёт, что это может звучать как "гундёж" старого человека. Думаю, материал стал лучше, просто материала стало много, и от изобилия можно вертеть носом.
Безумие :) Я даже в заключении сравниваю это дело с шапкой из фольги.
Вдохновлением на эти размышления мене послужил Путин, у которого нет девайсов.
Мне стало интересно, а может ли обычный человек не иметь девайсов, при этом иметь онлайн приватность, получая к ней доступ через публичные устройства.
Будто хиппи, живущий в лесу и питающийся солнцем и улыбками, который в любой момент может в халате придти в библиотеку, сесть за публичный компьютер и оплатить налог за собственную землю.
Хм... да... смогут. Причём, в теории, в момент получения куки или токена, они могут отключить меня от интернета, и я даже не смогу сделать logout...
Пожалуй да, тут всё зависит от модели угроз. От чего-то может это и поможет, но вероятно затраты усилий не окупятся
Ну да, суть кейса именно в том, чтобы авторизоваться через взломанное устройство в неизвестной для нас сети. Кейс такой, что хакеры видят и трафик, и нажатия, и клипборд, и вообще всё, что только можно (включая видео с вебки, и видео с камер видеонаблюдения в помещении, где вы используете устройство.
При этом, после авторизации нам надо либо прочитать какие-то данные, которые нам нужны в данную минуту, либо отправить куда-то какие-то данные. Да, хакеры смогут прочетать тот кусок, который мы будем читать, но не смогут прочитать остальные данные. Да, хакеры смогут увидеть данные, которые мы отправляем, но они не смогут сами отправлять данные от нашего лица без нашего ведома.
Пример из реальной жизни - поход на вершину горы, где вы не берёте с собой ничего лишнего, что бы выжить, но пользуетесь общественными девайсами в точках лагерей. Другой пример, - путешествие на коробле, через море, где выход в интернет строго контролируется. Хотя, по сули, в обоих случаях можно иметь при себе физический TOTP токен, который весит всего пару грам.
В схеме с одноразовым словарём из какого-нибудь текста, меня смущает 2 вещи:
надо помнить какие слова уже использовались, а какие ещё нет
после 5-ой авторизации, слов может быть достаточно, что бы найти исходный текст
На случай, если Хабр недоступен глобально, сервер тоже это увидет, и может переключиться на другой резервный портал. Если же, серверу Хабр доступен, а вам - нет, то тут сложнее.
Тоже об этом думал. Предположил, что можно внедрить что-то вроде временного кэша. Т.е. авторизоваться можно по любой статье за последние 5 минут. Но вообще, это проблема, если использовать блокировку при 2-3 неправильных вводах.
Да, токен MFA - это саое безопастное и удобное решение.
Зачем тогда придумывать всё это? - что бы избавиться от зависимостей. Токен надо тоскать с собой. Токен не везде можно подключить (например в публичных компах, где в целях безопасности отключен USB). Токен можно забыть или потерять. Токен можно украсть, после того, как кейлоггер запишет ваш пин :D В общем, шапка из фальги нужна...
Я слукавил, сказав, что "удалил приложение". Это предустановленное приложение. Телефон не рутованный и удалить его нельзя, можно только "отключить". Спрос к заводским настройкам, наоборот, включит и установит это приложение. И вероятно, эта несанкционированная установка - какая-то ошибка какого-нибудь менеджера приложений, которое, не знаю... включила приложение? :D
Просто, чем больше я копаюсь в интернет-безопасности, чем больше читаю о приватности, тем больше осознаю, что "безопасных" устройств нет.
Тем более, продвинутый шпионский софт, явно не будет заниматься такой ерундой, как установкой приложения социальной сети.
Попытался найти, в итоге нашёл это. Всё скомпрометировано! :D
Google
Если речь идёт о шифровании, то да. Но в данном случае в конечном варианте идеи - хэширование. А в центре внимания - не шифровка данных, а авторизация. Если авторизироваться не так часто, то у второй стороны не соберётся достаточно данных для реверс инженеринга. А попытки брутфорса приведут к блокировки.
Но вообще, я с вами согласен, потому и опубликовал статью (раскрыл алгоритм) :)
Ну... в реальной жизни TOTP на отдельном девайсе встречается крайне редко. Аппаратные ключи почаще. Но массовый кейс использования - это TOTP на телефоне. И при этом люди носят с собой только 1 телефон, и при этом на телефоне авторизируются, нарушая многофакторность.
Статья - просто мысли в слух, о том, какая могла бы быть альтернатива.
Полистал вашу ленту, пооткрывал случайные стати. Во всех статьях есть ссылки. Где-то на ваши же статьи, где-то на фильмы, где-то на википедию и т.д.
Возник ли вопросы:
Чем больше пишешь, тем больше начинаешь ссылаться на себя же?
Насколько быстро появляются новые источники? Т.е. невозможно же ежедневно впитывать в себя кучу новой информации (или можно?) И наверняка, отсылки на фильмы - это фильмы, которые были просмотрены до того, как вы начали писать. Ведь выденяя по 2 с половиной часа ежедневно на одно только написание статей, в вашем графике врятли есть время на свежие фильмы?
Возможно я употребил неправильную терминологию. В доках на русском это называется пространства имён.
Ну и суть в изоляции имён функций, что бы небыло конфликтов, наприер с импортируемыми библиотеками.
Например a.php:
b.php:
Очень крутая статья.
Правда много объектных нюансов.
Я бы ещё добавил сюда пару абзацов про области видимости (namespace), и что с ними тоже можно играться при построении грамотного процедурного кода.
Вспомнился небольшой забавный проектик, когда я пробовал переписать Symfony на процедурный стиль с целью более глубокого изучения symfony и попыткой доказать, что без ООП тоже можно жить: git
Сухая теория. Если б не примеры, я бы вообще не понял в чём сути.
А ещё я не понял в чём разница OKR от обычной работы любой компании, но глянув статью на википедии, вроде понял.
А можете немного рассказать о личном опыте? Когда внедряли? Как внедрилось? Какие результаты? Где подводные камни? Какой софт используете и как его настроили для OKR?
А можно, возможно глупый, вопрос: как маштабируют эти модели? т.е. если всё так упирается в железо, то как ChatGPT так быстро работает? Эти модели как-то можно запускать на кластерах из серверов?
Недавно тоже делал замеры программы на Go. Написал простенький алгоритм, который преобразует числа в слова (например "15" в "пятнадцать" с поддержкой двух языков). Консольное приложение.
Замерял через баш скрипт. Сразу получил какие-то дикие числа в 200 мс в среднем за один прогон. Потом выяснилось, что баш скрипт даёт оверхед на виндовсе. Переписал скрипт за мера да Go. Число упало до 60 мс в среднем за прогон.
Но и это было дикостью для такого простого алгоритма. Тогда начал анализировать не среднее число, а каждый прогон по отдельности. Выяснилось, что первый прогон из-за инициализации чуть ли ни в 10 раз дольше всех остальных и сильно сдвигает среднее.
Убрал учёт первого прогона. Получил уже более приемлемые 5-6 мс за прогон в среднем.
Но и тут я был очень не доволен. "быстрый язык, говорили они". Какой же он быстрый, если на таких простых операциях расходиет 5 мс? - подумал я.
Скоприрол код на Ubuntu сервер, скомпилировал и запустил. Средний прогон выполнялся за 1 мс, даже с учётом инициализации, которая заняла 5 мс. Вероятно даже алгоритм работал быстрее, но у меня заканчивалось свободное время и я не стал адаптировать замерочный скрипт под микросекунды.
Загуглил, и да, на форумах пишут, что Go больше заточен под *nix системы.
Отсюда, возникает вопрос к автору: если все говорят, что Go быстрее PHP, но у вас по вашим замерам выходит наоборот, что вы сделали, что бы понять почему ваш результат отличается от общего мнения?
Статья огонь, советы огонь, но, как и в предыдущех статье, хочется придраться с этой "эффективности" на микро-операциях.
1) нельзя при подсчёте годового сэкономленного времени перемножать на 52 недели, т.к. есть отпуска, праздники, а иногда и больничные.
2) предположим, вы экономите на алиасах 1 минуту в день. Это 4 часа в год. За 4 часа, например, можно написать онлайн конвертер валют, который будет считывать актуальные курсы с публичного xml. Такой, небольшой пет-проектик. Вопрос, сможете ли вы его написать, имея только 1 минуту в сутки? Вот, каждый день, в 16:59 начинаете работу и в 17:00 заканчиваете. Получится ли через год результат?
Что бы закончить на позитивной ноте, вот ещё один пункт по улучшению производительности:
Вы уже используете github copilot - круто. Но он помогает именно в задаче написания кода. А для поиска решений можно использовать ChatGPT. Т.е. приходит вам задача. Вы её читаете и сразу понимаете, как её выполнить. Но вместо того, что бы её выполнять, вы описываете её своими словами в ChatGPT и спрашиваете, как решить эту задачу. Звучит, как уменьшение эффективности, но при переписании задачи вы её лучше поймёте и сможете задать нужные вопросы ПМу. А решение от GPT может расширить ваше личное решение, т.к. 2 головы всегда лучше чем одна. В итоге мы как бы получаем краткосрочные затраты времнени, но долгосрочную экономию, т.к. задача будет выполнена значительно качественнее. По сути это относится в Lean Development (https://ru.wikipedia.org/wiki/Бережливая_разработка_программного_обеспечения)
А вы читали ответ о циклах в этой статье? Ни слова про ООП, ядро, мидлвэр, шаблонизацию, orm. Зато целый абзац про композер. Серьер бы точно так не отвечал.
https://laravel-docs.com/ru/docs/10.x/lifecycle - есть схожесть с нормальным обьяснением, но на уровне ChatGPT.
И вопрос в целом тоже не хороший. Лучше спрашивать жизненный цикл MVC фреймворка, а не конкретно Laravel.
Laravel оправдан только, если нужен именно человек на Laravel.