решения о применении ИИ принимаются на основе хайпа в твиттере/телеграме или субъективных ощущений менеджмента
Так это всегда было. До ИИ увлекались ноу/лоу код платформами, скрамом, микросервисами, бигдатой, созданием соц. сетей, блокчейном, парным программированием и т.п.
Условно, если два будильника одновременно завести на "через год" ("квантово запутать") и со скоростью света переместить в противоположные стороны, то через год они прозвенят одновременно ("синхронно"), хотя между ними будет дистанция в 2 световых года.
Люди, не до конца понимающие современную физику, почему-то считают, что будильники "обмениваются информацией быстрее скорости света", раз звенят одновременно.
Более того, на той же странице гугл признаёт dynamic rendering костылём и сообщает что есть способы лучше.
В статье правильно сказано, что надо стараться сделать проще. Но как это соотносится с тем, чтобы перегружать сайт js и динамическими элементами, получить проблему индексации, и потом начать героически её решать? Когда весь основной html можно сразу формировать на сервере, и вообще не иметь этой проблемы...
для бизнеса отказ от жёсткого тайм-трекинга может быть даже полезен
Смотря какой бизнес и задачи. Если разработка относительно простая, предсказуемая - можно трекать как угодно, хоть на почасовке.
Если разработка более сложная, требует опыта, знаний, R&D - мерять её по принципам конвейера - крайне плохая идея. Эта идея обычно укореняется в умах руководителей, ни года не проработавших коммерческими разработчиками.
В сложных проектах надо беспокоится не о попадании в условные эстимейты, а об инженерной культуре. Как набирается и ротируется команда? Как именно ведётся работа с техдолгом, автотестами, документацией? Сколько времени уделяется на ресёрч, и как он проводится? Что вообще у нас за проект, его цели, польза, сильные и слабые стороны? И так далее.
Вместо этого я нередко наблюдаю как менеджеры с квадратно-гнездовым мышлением типа "час разработки = бабки" пытаются высчитать, как сократить расходы, вместо того, чтобы думать о том, как зарабатывать больше за счёт своих конкурентных преимуществ.
"Оверэмплоймент" - бредовая фантазия, закрепившаяся в умах некомпетентных менеджеров. Уверенных, что разработка - несложная работа, которую один человек может делать для многих разных компаний одновременно.
По поводу теории - (а)синхронность, параллелизм и многозадачность свалены в кучу. Правильнее разделять так:
(А)синхронность. PHP по дефолту синхронный, то есть код исполняется последовательно, в порядке вызова. Асинхронное выполнение означает, что каждая функцая (метод, со-программа) может вызываться и отрабатывать (завершать работу) не в том порядке, в каком была вызвана. Что касается цитаты
PHP и асинхронность. Такая комбинация долгие годы казалась невозможной, ведь PHP прочно ассоциировался с блокирующим подходом и синхронным выполнением скриптов «от запроса до ответа»
Такая комбинация всегда была возможной через написание менеджера вызовов и обработки по типу event loop как в javascript (js оказывается под капотом тоже синхронный!). Но до поры до времени мейнтейнерам пыхи хватало ума держаться подальше от такой асинхронности.
Многозадачность (конкурентность). Многозадачность это способ разделить ресурсы между со-программами так, чтобы всем досталось понемногу. Например, процессорное время по какому-то правилу распределяется между со-программами (или процессами), таким образом каждая со-программа за каждую секунду работы получает какое-то процессорное время. Вытесняющая многозадачность это когда правило распределения - условно, пропорция (каждой со-программе даем столько-то квантов, % процессорного времени), а кооперативная - когда со-программа отрабатывает и сама освобождает ресурс для следующей ожидающей со-программы.
Параллелизм. Это когда со-программы/процессы выполняются параллельно, то есть без прямой зависимости друг от друга. Например, на разных компьютерах или на разных ядрах одного компьютера. Обратите внимание, можно реализовать (а)синхронность или многозадачность и на одном ядре, но параллелзим возможен только при наличии более чем одного вычислительного узла (например ядра проца).
"Голубой океан" - это пока не занятая ниша, где можно преуспеть, заработать сверхприбыль. Я не понимаю, как указанная в посте японская it зарплата менее чем в 3 тысячи долларов в месяц соотносится с этим.
Да это просто извечный вопрос поиска "золотой середины". Сколько отдыхать, а сколько работать. Расти в знаниях вглубь или вширь. Насколько сильно изолированы должны быть транзакции в бд (надежность vs скорость). Компиляция vs интерпретация. Статическая vs динамическая типизация. Быстро-дешево-качественно - выбери два из трёх (CAP теорема Брюера туда же). Монолит vs микросервисы. И так далее.
И как правило это не выбор между одним либо другим, а выбор точки, которая насколько-то ближе к одному либо к другому.
Надо избавляться от раздражителей, ИМХО. Вот эти подстройки:
> лучше всего работаю ночью, когда никто не мешает
часто появляются от того, что вы не выстроили оптимальный режим работы для себя. Например, работаете в месте, где вас готовы "поставить раком" лишь бы удовлетворить хотелки очередного малокомпетентного начальника, спрашивающего "как дела?" каждый час.
И вы не один такой. В больших городах птицы, которые обычно бодрствуют днём, начали бодрствовать ночью, чтобы их трели и песнопения не загулашись гулом автомобилей.
Пример: "на новом релизе у 20% пользователей перестала работать аутентификация"
Это проблема низкой инженерной культуры, где положили болт на процессы, тесты, планирование релизов, бюджета, код-ревью и т.д. Проблема того, кто распределяет бюджет. В общем случае, это не разработчики.
Я же писал не конкретно про утро, а про начало рабочего дня. У кого-то режим вполне "совиный" (и другие варианты: плохо выспался, с похмелья и т.п.), тогда и эффективная работа начинаться будет отнюдь не с утра.
А так, наилучшая бодрость, активность ума достигается именно в первые часы после пробуждения.
И наоборот, чем ближе время ко сну, тем хуже соображаешь.
Так это всегда было. До ИИ увлекались ноу/лоу код платформами, скрамом, микросервисами, бигдатой, созданием соц. сетей, блокчейном, парным программированием и т.п.
Условно, если два будильника одновременно завести на "через год" ("квантово запутать") и со скоростью света переместить в противоположные стороны, то через год они прозвенят одновременно ("синхронно"), хотя между ними будет дистанция в 2 световых года.
Люди, не до конца понимающие современную физику, почему-то считают, что будильники "обмениваются информацией быстрее скорости света", раз звенят одновременно.
Без исходников или демо выглядит как-то неубедительно.
Не вижу ничего подобного https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering видимо написано для красного словца.
Более того, на той же странице гугл признаёт dynamic rendering костылём и сообщает что есть способы лучше.
В статье правильно сказано, что надо стараться сделать проще. Но как это соотносится с тем, чтобы перегружать сайт js и динамическими элементами, получить проблему индексации, и потом начать героически её решать? Когда весь основной html можно сразу формировать на сервере, и вообще не иметь этой проблемы...
Смотря какой бизнес и задачи. Если разработка относительно простая, предсказуемая - можно трекать как угодно, хоть на почасовке.
Если разработка более сложная, требует опыта, знаний, R&D - мерять её по принципам конвейера - крайне плохая идея. Эта идея обычно укореняется в умах руководителей, ни года не проработавших коммерческими разработчиками.
В сложных проектах надо беспокоится не о попадании в условные эстимейты, а об инженерной культуре. Как набирается и ротируется команда? Как именно ведётся работа с техдолгом, автотестами, документацией? Сколько времени уделяется на ресёрч, и как он проводится? Что вообще у нас за проект, его цели, польза, сильные и слабые стороны? И так далее.
Вместо этого я нередко наблюдаю как менеджеры с квадратно-гнездовым мышлением типа "час разработки = бабки" пытаются высчитать, как сократить расходы, вместо того, чтобы думать о том, как зарабатывать больше за счёт своих конкурентных преимуществ.
Какой-то бред.
"Оверэмплоймент" - бредовая фантазия, закрепившаяся в умах некомпетентных менеджеров. Уверенных, что разработка - несложная работа, которую один человек может делать для многих разных компаний одновременно.
По поводу теории - (а)синхронность, параллелизм и многозадачность свалены в кучу.
Правильнее разделять так:
(А)синхронность.
PHP по дефолту синхронный, то есть код исполняется последовательно, в порядке вызова.
Асинхронное выполнение означает, что каждая функцая (метод, со-программа) может вызываться и отрабатывать (завершать работу) не в том порядке, в каком была вызвана.
Что касается цитаты
Такая комбинация всегда была возможной через написание менеджера вызовов и обработки по типу event loop как в javascript (js оказывается под капотом тоже синхронный!). Но до поры до времени мейнтейнерам пыхи хватало ума держаться подальше от такой асинхронности.
Многозадачность (конкурентность).
Многозадачность это способ разделить ресурсы между со-программами так, чтобы всем досталось понемногу. Например, процессорное время по какому-то правилу распределяется между со-программами (или процессами), таким образом каждая со-программа за каждую секунду работы получает какое-то процессорное время. Вытесняющая многозадачность это когда правило распределения - условно, пропорция (каждой со-программе даем столько-то квантов, % процессорного времени), а кооперативная - когда со-программа отрабатывает и сама освобождает ресурс для следующей ожидающей со-программы.
Параллелизм.
Это когда со-программы/процессы выполняются параллельно, то есть без прямой зависимости друг от друга. Например, на разных компьютерах или на разных ядрах одного компьютера.
Обратите внимание, можно реализовать (а)синхронность или многозадачность и на одном ядре, но параллелзим возможен только при наличии более чем одного вычислительного узла (например ядра проца).
Супер инсайт: если в статье "вайб-код" переименовать в "говнокод", не изменится ничего.
Ох уж этот стиль изложения ChatGPT... Как же я устал от этого...
"Голубой океан" - это пока не занятая ниша, где можно преуспеть, заработать сверхприбыль. Я не понимаю, как указанная в посте японская it зарплата менее чем в 3 тысячи долларов в месяц соотносится с этим.
Да это просто извечный вопрос поиска "золотой середины". Сколько отдыхать, а сколько работать. Расти в знаниях вглубь или вширь. Насколько сильно изолированы должны быть транзакции в бд (надежность vs скорость). Компиляция vs интерпретация. Статическая vs динамическая типизация. Быстро-дешево-качественно - выбери два из трёх (CAP теорема Брюера туда же). Монолит vs микросервисы. И так далее.
И как правило это не выбор между одним либо другим, а выбор точки, которая насколько-то ближе к одному либо к другому.
Типы данных это ж базовая база...
Ссылку на упомянутую вакансию - в студию!
Надо избавляться от раздражителей, ИМХО. Вот эти подстройки:
> лучше всего работаю ночью, когда никто не мешает
часто появляются от того, что вы не выстроили оптимальный режим работы для себя. Например, работаете в месте, где вас готовы "поставить раком" лишь бы удовлетворить хотелки очередного малокомпетентного начальника, спрашивающего "как дела?" каждый час.
И вы не один такой. В больших городах птицы, которые обычно бодрствуют днём, начали бодрствовать ночью, чтобы их трели и песнопения не загулашись гулом автомобилей.
Это проблема низкой инженерной культуры, где положили болт на процессы, тесты, планирование релизов, бюджета, код-ревью и т.д. Проблема того, кто распределяет бюджет. В общем случае, это не разработчики.
Так это проблема ПМа или разработчиков?
Я же писал не конкретно про утро, а про начало рабочего дня. У кого-то режим вполне "совиный" (и другие варианты: плохо выспался, с похмелья и т.п.), тогда и эффективная работа начинаться будет отнюдь не с утра.
А так, наилучшая бодрость, активность ума достигается именно в первые часы после пробуждения.
И наоборот, чем ближе время ко сну, тем хуже соображаешь.
Ровно наоборот. Обычно первые 4 часа рабочего дня более продуктивны, по естественным причинам - меньше усталость, голова свежее и т.д.
Так что первую половину дня таки лучше посвятить непосредственно разработке, а длительное балабольство отложить на вторую.