Возможно я употребил неправильную терминологию. В доках на русском это называется пространства имён.
Ну и суть в изоляции имён функций, что бы небыло конфликтов, наприер с импортируемыми библиотеками.
Например 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. Зато целый абзац про композер. Серьер бы точно так не отвечал.
я просто не понимаю в чём ценность этой статьи. Автор не делится опытом. Сет вопросов ничем не обоснован. А ответы такие, что если бы я их получил от кандидата на собеседовании, то уж точно не определил бы его как сеньёра. А вообще, я бы даже и не стал бы такие вопросы задавать... они не показательны
Это первая статья подобного рода, которую я решил глянуть...
И... даже не знаю стоит ли это комментировать...
Во-первых, ответы выглядят, как GPT.
Во-вторых, нет связанности. Вторым вопросом идёт Laravel, а 7-ым примеры на symfony.
В-третьих, странные вопросы, не о PHP, а о конкретном стэке: kafka, redis. Т.е. не вопросы типа какие бывают мэсэдж брокеры и кэши, и как они работают, а разбор конкретных технологий.
В-четвёртых, в микросервисах вопросы про PHP, а ответы, не про PHP. "В чём плюсы микросервиса на PHP?" - "В технологической независимовти". Т.е. микросервис на PHP можно написать на GO что ли? :D :D
В-пятых, какой-то странный сет из видов тестирования. Например, есть Security Testing, но нет penetration testing.
Создание библиотеки на PHP - это вопрос? Описание вообще смешное.
Если мы уже сделали 3 оценки, то зачем нам зводить всё в одно число?
Почему бы не продолжить оперирывать 3-мя числами?
Тем самым закладывая в план те задачи, которые можно сделать дополнительно если большая часть задач будет реализована по оптимистичной оценке, а помечая задачи, от которых можно отказаться, если реализация будет проходить пессиместично.
Более того, подсчёт среднего может сильно сбивать с толку, когда оптимистичная оценка слишком далека от пессимистичной.
Например:
Надо нам интегрировать новое железо.
Оптиместическая оценка - 2 часа, в случае, если все драйвера подойдут и либы будут работать, как описано в доках.
Пессиместичная оценка - 40 часов, в случае, если драйвера придётся писать самостоятельно.
Ну и возникает вопрос, откуда, в этом случае взять наиболее вероятнаю оценку.
Рассмотрим 2 варианта:
Наиболее вероятная оценка - 2.
Наиболее вероятная оценка - 40.
В первом случае средняя выйдет 8. Во втрором - 27.
И что нам это даст? Только то, что мы с огромной вероятносью получили неверную оценку.
Т.е. часть софта стоит на домашнем железе, а часть в vps.
Причём в vps стоят более критические штуки типа Authentik и vaultvarden.
А есть ли какая-то реплика этого vps?
Как-то очень не хотелось бы остаться без авторизации и менеджера паролей, если vps отвалится. Особенно, если в этот момент находиться в отпуске далеко от дома.
Я не эксперт, но... мне кажется, если вы используете excel для управления проектов, то вам лучше заняться самообразованием, т.к. существуют десятки крутих полноценных систем по утправлению проектами, которые работают по чётко продуманным методологиям и существуют уже не менее 10 лет (т.е. это не системы однодневки)
Это сработало бы для сферического разработчика в вакууме. Но на практике, работа разработчика имеет задержки. То ждёшь что-то от админов, то тестировщик возвращает тикет, то вопросы к бизнесу появляются. В итоге из 8 часов и без всяких совещаний разработчик в лучшем случае сосредоточенно работает всего часа 2.
Наверное те же сервисы, которые слили эти 193 млн. паролей.
А если серьёзно, то при подборах, запросы идут с разных IP с различными задержками. Это хорошо видно, по логам на vps или домашних nas. Причём, бывает когда пытаются подобрать пароль конкретного пользователя, а бывает просто перебором идут по слитой базе, подставляя разных пользователей.
А вообще, скорее всего рассчёт про "не более часа" подразумевается на локальном взломе. Например, если хакеры получили базу хэшей паролей, а дальше перебором пытаются найти пароль, хэш которого совпадёт с похищеным. А дальше, имея этот пароль, можно пробовать логиниться им во все сервисы подряд, в ожидании, что где-то пользователь использовал одинаковые пароли.
Кофе на голодный желудок противопоказано при проблемах с жкх.
Меня больше смутила та часть, в которой человек живёт без еды 15 часов подряд, которая особо выделяется на фоне остальных 9, когда питание каждые 2 часа.
Согласен.
Расписание автора выглядит как буд-то он двигается только во время тренировки, а остальное время сидит. Прогулка до магазина 1 раз в день даст больше буста для самочувствия и здоровья, чем сама утренняя тренировка. Важно двигаться, и делать это часто.
Тут я не эксперт, но разве посещение психолога входит в рацион здорового человека с идеальным расписанием, социальными связями и отсутствием выгораний? Т.е. писхологом мы чиним то, что поломано чем-то другим. И если мы посещаем психолога, значит наша формула не идеальна. Ею можно делиться в статье ради фидбека, но не стоит утверждать что она вам идеально подходит в данный момент (хотя автор может психолога и не посещает, но от последнего выгорания у него прошло не так много времени)
Тут я хотел проакцентировать, что на короткой дистанции есть выходные, где другой график, а на более длинной есть сезонность - лето, когда больше времени проводишь на улице, и зима, когда большую часть суток темно. А ещё есть праздники и отпуска. Я бы провёл аналогию с бюджетом на месяц, где запланированы все расходы на месяц, но никак не задумано, что раз в 2-3 года надо покупать новый телефон. Т.е. расписание одного дня достаточно бесполезно, без контекста пары лет.
1) Зачем первая чашка кофе? Во-первых это вредно на пустой желудок, во-вторых, у вас же утренний спорт, который пробудит вас лучше кофеина
2) Завтрак только через 5 часов после пробуждения? Это нормально вообще? Особенно, если обратить внимание, что после завтрака через 2 часа обед, а потмо через 2 часа полдник и потом через 2 часа ужин. Какой-то фастинг что ли?
3) А не лучше ли дневной сон после обеда сделать? После обеда многих часто клонит в сон.
4) Если есть дневной сон, тогда неужели на ночной сон надо 8 часов? Или туда включено чтение перед сном?
5) А когда вы за продуктами ходите? После 20:30, перед закрытием магазинов?
6) Мне кажется, или тут отсутствует какая-либо социальность? Вы хоть кого-то в живую видите с таким расписанием? 7) У вас все дни одинаковые? А что на выходных?
Возможно я употребил неправильную терминологию. В доках на русском это называется пространства имён.
Ну и суть в изоляции имён функций, что бы небыло конфликтов, наприер с импортируемыми библиотеками.
Например 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.
я просто не понимаю в чём ценность этой статьи. Автор не делится опытом. Сет вопросов ничем не обоснован. А ответы такие, что если бы я их получил от кандидата на собеседовании, то уж точно не определил бы его как сеньёра. А вообще, я бы даже и не стал бы такие вопросы задавать... они не показательны
Это первая статья подобного рода, которую я решил глянуть...
И... даже не знаю стоит ли это комментировать...
Во-первых, ответы выглядят, как GPT.
Во-вторых, нет связанности. Вторым вопросом идёт Laravel, а 7-ым примеры на symfony.
В-третьих, странные вопросы, не о PHP, а о конкретном стэке: kafka, redis. Т.е. не вопросы типа какие бывают мэсэдж брокеры и кэши, и как они работают, а разбор конкретных технологий.
В-четвёртых, в микросервисах вопросы про PHP, а ответы, не про PHP. "В чём плюсы микросервиса на PHP?" - "В технологической независимовти". Т.е. микросервис на PHP можно написать на GO что ли? :D :D
В-пятых, какой-то странный сет из видов тестирования. Например, есть Security Testing, но нет penetration testing.
Создание библиотеки на PHP - это вопрос? Описание вообще смешное.
Паттерны даже читать не стал.
Three-point estimate звучит, как какая-то фигня.
Если мы уже сделали 3 оценки, то зачем нам зводить всё в одно число?
Почему бы не продолжить оперирывать 3-мя числами?
Тем самым закладывая в план те задачи, которые можно сделать дополнительно если большая часть задач будет реализована по оптимистичной оценке, а помечая задачи, от которых можно отказаться, если реализация будет проходить пессиместично.
Более того, подсчёт среднего может сильно сбивать с толку, когда оптимистичная оценка слишком далека от пессимистичной.
Например:
Надо нам интегрировать новое железо.
Оптиместическая оценка - 2 часа, в случае, если все драйвера подойдут и либы будут работать, как описано в доках.
Пессиместичная оценка - 40 часов, в случае, если драйвера придётся писать самостоятельно.
Ну и возникает вопрос, откуда, в этом случае взять наиболее вероятнаю оценку.
Рассмотрим 2 варианта:
Наиболее вероятная оценка - 2.
Наиболее вероятная оценка - 40.
В первом случае средняя выйдет 8.
Во втрором - 27.
И что нам это даст? Только то, что мы с огромной вероятносью получили неверную оценку.
А можно чуть чуть подробнее про инфраструктуру?
Т.е. часть софта стоит на домашнем железе, а часть в vps.
Причём в vps стоят более критические штуки типа Authentik и vaultvarden.
А есть ли какая-то реплика этого vps?
Как-то очень не хотелось бы остаться без авторизации и менеджера паролей, если vps отвалится. Особенно, если в этот момент находиться в отпуске далеко от дома.
Изучил проект подробнее и возникли вопросы по децентрализации…
Как это в идеале должно работать?
На моём клиенте будут храниться мои письма и чьи-то чужие? А что будет на IPFS?
А куда будет ссылаться DNS?
И куда будет коннектиться клиент при первом холодном старте?
Как эта сеть будет противостоять спаму? Что бы спамеры не создавали миллионы децентрализованных ящиков и не рассылали миллиарды спам-писем?
1) Скачал свежий бинарник
2) Проинициализировал, добавил Proton-аккаунт, получил нотификацию от протона о новом входе
А вот дальше...
3) show-all-messages - возвращает пустую строку
4) при отправки почты пишет The private key could not be found
Меня больше смущает, что теперь папку Документов находится в папке OneDrive.
Мемная картинка вдруг стала реальностью:
Ну, как я сказал, я не эксперт, но из популярных систем - это jira, asana, clickup, monday.com.
Ну или что-то что пришло им на смену: https://habr.com/ru/companies/evateam/articles/714114/
Я не эксперт, но... мне кажется, если вы используете excel для управления проектов, то вам лучше заняться самообразованием, т.к. существуют десятки крутих полноценных систем по утправлению проектами, которые работают по чётко продуманным методологиям и существуют уже не менее 10 лет (т.е. это не системы однодневки)
Но за то, что делетись рабочим опытом плюсик
Это сработало бы для сферического разработчика в вакууме. Но на практике, работа разработчика имеет задержки. То ждёшь что-то от админов, то тестировщик возвращает тикет, то вопросы к бизнесу появляются. В итоге из 8 часов и без всяких совещаний разработчик в лучшем случае сосредоточенно работает всего часа 2.
Наверное те же сервисы, которые слили эти 193 млн. паролей.
А если серьёзно, то при подборах, запросы идут с разных IP с различными задержками. Это хорошо видно, по логам на vps или домашних nas. Причём, бывает когда пытаются подобрать пароль конкретного пользователя, а бывает просто перебором идут по слитой базе, подставляя разных пользователей.
А вообще, скорее всего рассчёт про "не более часа" подразумевается на локальном взломе. Например, если хакеры получили базу хэшей паролей, а дальше перебором пытаются найти пароль, хэш которого совпадёт с похищеным. А дальше, имея этот пароль, можно пробовать логиниться им во все сервисы подряд, в ожидании, что где-то пользователь использовал одинаковые пароли.
Нет контекста. Сколько вам лет?
Кофе на голодный желудок противопоказано при проблемах с жкх.
Меня больше смутила та часть, в которой человек живёт без еды 15 часов подряд, которая особо выделяется на фоне остальных 9, когда питание каждые 2 часа.
Согласен.
Расписание автора выглядит как буд-то он двигается только во время тренировки, а остальное время сидит. Прогулка до магазина 1 раз в день даст больше буста для самочувствия и здоровья, чем сама утренняя тренировка. Важно двигаться, и делать это часто.
Тут я не эксперт, но разве посещение психолога входит в рацион здорового человека с идеальным расписанием, социальными связями и отсутствием выгораний? Т.е. писхологом мы чиним то, что поломано чем-то другим. И если мы посещаем психолога, значит наша формула не идеальна. Ею можно делиться в статье ради фидбека, но не стоит утверждать что она вам идеально подходит в данный момент (хотя автор может психолога и не посещает, но от последнего выгорания у него прошло не так много времени)
Тут я хотел проакцентировать, что на короткой дистанции есть выходные, где другой график, а на более длинной есть сезонность - лето, когда больше времени проводишь на улице, и зима, когда большую часть суток темно. А ещё есть праздники и отпуска. Я бы провёл аналогию с бюджетом на месяц, где запланированы все расходы на месяц, но никак не задумано, что раз в 2-3 года надо покупать новый телефон. Т.е. расписание одного дня достаточно бесполезно, без контекста пары лет.
Интересный опыт, но есть вопросы:
1) Зачем первая чашка кофе? Во-первых это вредно на пустой желудок, во-вторых, у вас же утренний спорт, который пробудит вас лучше кофеина
2) Завтрак только через 5 часов после пробуждения? Это нормально вообще? Особенно, если обратить внимание, что после завтрака через 2 часа обед, а потмо через 2 часа полдник и потом через 2 часа ужин. Какой-то фастинг что ли?
3) А не лучше ли дневной сон после обеда сделать? После обеда многих часто клонит в сон.
4) Если есть дневной сон, тогда неужели на ночной сон надо 8 часов? Или туда включено чтение перед сном?
5) А когда вы за продуктами ходите? После 20:30, перед закрытием магазинов?
6) Мне кажется, или тут отсутствует какая-либо социальность? Вы хоть кого-то в живую видите с таким расписанием?
7) У вас все дни одинаковые? А что на выходных?