и менеджер и сеньер программист считают что можно избавиться от джунов и их задачки (тесты, документацию, мелкие правки) переложить на llm. и оно будет работать вот прям щас.настоящая проблема будет через лет так 10-20 когда нынешние сеньоры поуходят на пенсию а новых нет, так как хрен ты до синьора дорастешь просто так.
и лучшей аналогией будет - ситуация с cobol программистами когда в штатах искали пенсионеров чтоб те могли поснить - а как то что они писали работает.
подобная гибкость иногда приводит к замечательному результату, когда у вас файлик листов на 10 в одном 30к строк в остальных до 300 строк, колонок 20 -30 на каждом, и все это говно начинает жутко тормозить при любой операции с данными.
отдельно доставляло, что пользователи умудрялись добавлять невидимые обьекты на листы, отчего это реашьно нужный файл превращался в кучу г-на и начинал тормозить даже при скроллинге
это при том, что ответ то можно сделать вовсе без cte, в один запрос
там же не было резевного
на мой взгляд проблема совсем в другом:
и менеджер и сеньер программист считают что можно избавиться от джунов и их задачки (тесты, документацию, мелкие правки) переложить на llm. и оно будет работать вот прям щас.настоящая проблема будет через лет так 10-20 когда нынешние сеньоры поуходят на пенсию а новых нет, так как хрен ты до синьора дорастешь просто так.
и лучшей аналогией будет - ситуация с cobol программистами когда в штатах искали пенсионеров чтоб те могли поснить - а как то что они писали работает.
боевка там как бы есть, но нет.
заключается буквально в следующем - берем и выдвигаем пару отрядов наперерез к атакующим и забываем на время про них.
так что:
1) то что есть до боли примитивно, и казалось примитивным даже тогда. эпиком было когда стражей отбил вторжение, не имея проф военных
2) боги... Сет при расположении может взять и угробить вторженцев.
есть конешнг еще задания на отправку куда либо подкреплений, но тут тоже - отправил забыл.
так что боевка это как ни странно еще пара мастерских, и по большому счету от ее отсутствия игра ничего бы не потеряла.
епть, как же давно это было а еще чето всплминается
хех, помнится работал я с одним api, так там вполне норм было отдать ответ вида
[{"key_column": str, "value": str},{"key_column": str },{"key_column": str, "value": list[dict]},{"key_column": str, "value": dict}]дату рождения вполне могут спрашивать и так, если приложение реализует функционал условно 18+.
дык понятно же что очень упрощенно все.
а насчет 200к - вона ирл находятся умники за обещание 50к релейный шкаф на жд путях поджечь
или 8.1%
а самое забавное, что в самой статье несколько иной фактаж
т.е. ии поучаствовал в написании половины кода, причем не сказать чтоб качественно, ибо большая часть подсказок отвергается.
ну по крайней мере так можно воспринять написанное
а когда кликхаус перестал быть СУБД?
чей та менее удобным.
наоборот как раз. особенно если проект/сервис пишется не за один подход
но ведь это же так просто, переписать с python на java (сарказм)
года полтора назад заказываю такси, яндекс, детский тариф.
яндекс такой - ждите 1.5 часа, приедет.
отменяю, вызываю обычный, так же яндекс. приезжает мужик, достает кресло. едем.
так что таксистов с креслом то может и хватает, ток яндекс про то не знает.
москва если что
подобная гибкость иногда приводит к замечательному результату, когда у вас файлик листов на 10 в одном 30к строк в остальных до 300 строк, колонок 20 -30 на каждом, и все это говно начинает жутко тормозить при любой операции с данными.
отдельно доставляло, что пользователи умудрялись добавлять невидимые обьекты на листы, отчего это реашьно нужный файл превращался в кучу г-на и начинал тормозить даже при скроллинге
ходят еще как
вот только обычно еще куча уточнений потом:
по манагерам/складам/регионам, без/с возвратами, ндс
и чсх каждый раз эти уточнения сцук разные
42 - этож ответ на главный вопрос жищни вселенной и всего.
какие еще доказательства
pd.read_sql(), insert_dataframe() тоже с большой долей вероятности не нужны. большую часть трансформаций всеже можно внутри бд сделать.