Все тут пишут, на сколько полезны стали ИИ как инструмент для разработчиков. Но другую сторону разработки - обучению этой же самой разработке в век ИИ - как-то обходят стороной. Однако, в одном из рабочих чатов, недавно обсуждали, как же круто учиться с помощью ИИ, потому что его можно заебывать тупыми вопросами до бесконечности. И это имеет место. Но, на мой взгляд, заебывать ИИ вопросами != обучение. Хоть это и может быть его частью.

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

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

Поэтому я думаю, что обучение на книжках - это иллюзия. Ну только если эта книжка не учебник с упражнениями.

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

Поэтому, только практика. Только руками поработать, если вы понимаете, о чем я😉

И причем здесь ИИ? а при том, что ИИ очень-очень усложняет вот это "руками поработать". Слишком велик соблазн просто попросить решить задачу ИИ. А затем, ты попросишь эту ИИ полностью объяснить тебе решение. И он объяснит. А самое страшное, что после этого у тебя возникнет ощущение, что ты все понял и чему-то научился. А ты нихера не научился на самом деле.

Эта иллюзия сравнима с тем, что ты воспользовался решебником в школе. Я не знаю, есть ли щас решебники у школьников, но в моем дестве они были. И если раньше найти решебник - это та еще задачка, то теперь этот решебник просто у тебя в кармане. Для практически любой задачи.

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

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

В итоге, выходит, что даже в обучении ИИ - это отнюдь не серебряная пуля😔

Единственный свет в конце туннеля — это если нас всех заменит ИИ и нам не придется ничему учиться🤡 правда непонятно, а за что тогда будут платить зп, но это я потом подумаю

Давно у меня не горело сзади, но седня я просто кричал криком в монитор! 😡

Все дело в doctrine orm и в ебучих таймзонах.

Я самый несчастный человек на земле, когда дело касается базы данных. Потому что у нас на проекте до сих пор mysql - основная бд 😔 Фан факт про mysql - долгое время эта СУБД не позволяла хранить таймзоны в полях с датами. Ситуация изменилась только в 2020м с версией 8.0.19. Там добавили возможность хранить смещение в поле с датой.

Но суть даже не в этом. Открываем доку доктрины по типам. Там мы можем увидеть следующие типы, касательно времени: datetime, datetime_immutable, datetimetz, datetimetz_immutable. Впринципи любой более менее программистский человек по названию может догадаться, о чем каждый из этих типов.

У меня пользователи в разных таймзонах, и важно точное время события. Поэтому таймзоны я не могу отбросить, и я должен использовать datetimetz. Ведь в описании написано

> Maps and converts date with time and timezone information data. If you know that the data to be stored always contains date, time and timezone information, you should consider using this type.

О боже, это же мой сценарий!

Ну и поскольку я как минимум миддл пхп девелопер, окончательный выбор падает на datetimetz_immutable.

Также под типом datetimetz можно увидеть предупреждение о том, что не все СУБД поддерживают хранения таймзон, поэтому результат чтения может не совпадать с записью. Типа вставили 1986-22-03 19:45:30-03:00, а прочитали 1986-22-03 22:45:30-00:00. В целом это понятно, и мне ок!

Каково же было мое удивление, когда я обнаружил, что доктрина просто на похуй отбрасывает таймзону и сохраняет значение как есть! То есть, сохраняю я например текущую дату 2026-05-18 10:40:50 в таймзоне America/Toronto. В бд я вижу значение 2026-05-18 10:40:50. Без таймзоны. Загружаю сущность после

date_default_timezone_set('Europe/Moscow');

получаю ту же самую дату в москве. Просто херак и проебал 7 часов на ровном месте.

По факту datetimetz не хэндлит таймзоны! Меняю тип на datetime - поведение не отличается! И в коде все одинаково для обоих типов. Ну пиздейшн конечно!

И я сижу такой обосравшийся и не понимаю, почему мои ожидания, что тип datetimetz конвертнет дату в utc перед сохранением и из utc при загрузке, оказались на столько завышенными. И нахуя этот тип тогда нужен! И почему в mysql уже 6 лет как поддерживаются таймзоны, а доктрина их не сохраняет!

Не ну это не самое прикольное. Самое прикольное, как раз то, что есть страница в доке Working with DateTime Instances, где и описывается подход с конвертацией в/из utc при сохранении/загрузке. И говорится, что это тру вей (с чем трудно спорить). В качестве решения предлагается мне самому написать кастомный тип, который это бы делал🤡 и даже код этого типа предоставили, чтоб я скопипастил.

Но почему не включить этот тип по умолчанию в доктрину!!! Почему написать о подходе в доке, предоставить код для копипасты - это тру вей! 😡

Эх, столько "почему" сегодня. Я устал😔

удар в псину 🐶 от вардампа!

вардамп был выбран для hell2shape, потому что он
* есть у всех
* провайдит типы

И, казалось бы, все хорошо.

Но я не знаю, как так получилось, но мы с клодом пропустили капец важный корнер кейс. аж стыдно!😢

дело в том, что вардамп не экранирует двойные кавычки. и получается как-то так.

$v = ['k' => 'v"v'];
var_dump($v);

array(1) {
  ["k"]=>
  string(3) "v"v"
}

ну и как бы все! лексер сломан! идея о том, что мы одной регуляркой распарсим все на токены сразу идет в очко.

И если щас кто-то скажет "да ты просто не умеешь готовить регулярки" (что в целом правда), то как вам такое

$a = [
    'govno' => 'жопа"
  ["лох"]=>
  string(8) "тигр',
];
$b = ['govno' => 'жопа', 'лох' => 'тигр'];
var_dump($a, $b);

array(1) {
  ["govno"]=>
  string(46) "жопа"
  ["лох"]=>
  string(8) "тигр"
}
array(2) {
  ["govno"]=>
  string(8) "жопа"
  ["лох"]=>
  string(8) "тигр"
}

разница только в цифрах в скобочках. и получается, что надо по-хорошему добавлять препроцессор, и только потом уже в лексер все это пихать😔

и удивительно, что сколько я не пользовался сам hell2shape, я ни разу с этой багой не столкнулся. но мне открыли issue, и я такой "блять как это можно было пропустить" и буквально на следующий день я уже сам это словил. сук.

пока закинул фикс с positive lookahead на пустую строку после кавычки. ну теперь лексер ломается только если кавычка с переносом строки.

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

С другой стороны, может быть, если бы я об этом кейсе знал, я бы до сих пор ничо не выпустил😂