То, что тривиальные задачи llm решают с трудом — так это правда. Буквально вчера консультировался с Клавдием по отдельным аспектам написания пайплайнов для битбакета — он и посыпался. Предлагает заведомо невалидные решения, когда указываешь ему на это, одно невалидное решение меняет на другое.
А то, что сложные задачи llm решают успешно, так это я сомневаюсь. Как-то попросил чатгпт написать мне драйвер файловой системы — так он отказался. Ой, говорит, это очень сложно, я не умею. Прототип — хоть сейчас, а продакшн реди решение сам пиши.
Всё, что вы пишете, на самом деле уже было в тёплые LAMPовые времена.
Тогда все сидели на MySQL, а MySQL не умела во внешние ключи, и приходилось всё делать на бэкенде.
Даже когда MySQL научилась во внешние ключи, многие всё ещё игнорировали эти возможности ровно из-за описанных в статье соображений — ради скорости.
Но даже тогда люди понимали, что жертвуют консистентностью ради производительности.
Сейчас же, кмк, если скорость — главный приоритет, проще взять NoSQL-решение.
Простой пример того, когда проверки на бэкенде не работают:
if (user_exists(user_id)) { // тут пользователь ещё существует
// тут процесс останавливается и другой процесс удаляет пользователя
create_order(user_id) // здесь создаётся заказ для пользователя, которого уже не существует
}
Даже если вы используете soft delete, вы, скорее всего, всё равно не хотите, что бы заказы создавались для удалённых пользователей. Но, в случае с soft delete, вам только внешнего ключа уже не хватит, конечно.
Напомню, что стек — это очередь/массив, в которых операции подвергаются push, то есть добавлению значения в конец, и pop, при котором это значение возвращается в программу.
В одном из проектов, над которым я работал, автоматическое форматирование было сделано на уровне pre-commit-hook. Причем использовалась наивная реализация, когда из хука запускается программа форматирования, которая форматирует код всего проекта, но никак не обновляет данные для коммита. Это приводило к тому, что после коммита в рабочей копии появлялись изменения с правильным форматированием файлов, но они не попадали коммит.
Я бы использовал автоформатирование на двух уровнях: изменяющее, на уровне IDE, и проверяющее, на уровне CI. Конечно, это должна быть одна и та же программа с одинаковым набором правил.
Форум — это не саппорт. Форум — это комьюнити.
Там общаются пользователи плеска, обмениваются опытом и помогают друг другу по мере сил.
Если же говорить именно о саппорте, то он доступен 24/7, имеет строгие ограничения по времени ответа и никому не приходится ждать его «с февраля этого года».
Завтра выйдет новая версия браузера, которая будет интерпретировать корректный код по-другому и сайт перестанет отображаться правильно во всех браузерах.
Вообще, в моей практике, проблемы с кодировками решаются двумя строчками в конфигурационном файле:
;; Установка правильного шрифта.
(set-frame-font "-xos4-terminus-medium-r-normal--24-240-72-72-c-120-iso10646-1")
;; Установка кодировки вставляемых строк.
(setq x-select-request-type 'UTF8_STRING)
Конечно, для отдельных режимов могут понадобится дополнительные настройки.
Хорошая статья для начинающих, хотелось бы развития темы.
Ряд замечаний, относительно подготовки рабочего места.
Устанавливая переменную auto-mode-alist в .emacs мы теряем её общесистемное значение — как правило, в переменной уже содержаться соответствия для различных режимов, как поставляемых с emacs, так и установленных с пакетами дистрибутива. Если это значение терять не хочется, лучше использовать функцию add-to-list.
Так же в emacs'е существует специальный режим для редактирования elisp — emacs-lisp-mode, возможно имеет смысл использовать именно его. В итоге, вместо (setq auto-mode-alist ...) можно написать нечто вроде:
То, что тривиальные задачи llm решают с трудом — так это правда. Буквально вчера консультировался с Клавдием по отдельным аспектам написания пайплайнов для битбакета — он и посыпался. Предлагает заведомо невалидные решения, когда указываешь ему на это, одно невалидное решение меняет на другое.
А то, что сложные задачи llm решают успешно, так это я сомневаюсь. Как-то попросил чатгпт написать мне драйвер файловой системы — так он отказался. Ой, говорит, это очень сложно, я не умею. Прототип — хоть сейчас, а продакшн реди решение сам пиши.
Всё, что вы пишете, на самом деле уже было в тёплые LAMPовые времена.
Тогда все сидели на MySQL, а MySQL не умела во внешние ключи, и приходилось всё делать на бэкенде.
Даже когда MySQL научилась во внешние ключи, многие всё ещё игнорировали эти возможности ровно из-за описанных в статье соображений — ради скорости.
Но даже тогда люди понимали, что жертвуют консистентностью ради производительности.
Сейчас же, кмк, если скорость — главный приоритет, проще взять NoSQL-решение.
Простой пример того, когда проверки на бэкенде не работают:
Даже если вы используете soft delete, вы, скорее всего, всё равно не хотите, что бы заказы создавались для удалённых пользователей. Но, в случае с soft delete, вам только внешнего ключа уже не хватит, конечно.
TIOBE — это же глобальный рейтинг. А hh.ru и хабр карьера — это российские вакансии, в основном. Отсюда и различия.
Меня совсем не удивляет, что в России не ищут специалистов по ada или cobol, а в других странах — по 1с.
Я сломался вот на этой строке:
Нет, reset —hard убирает не только последний коммит, но и все его изменения. Если изменения нужно только немного подправить, это не очень удобно.
Вместо
git reset --soft HEAD~1я обычно использую
git commit --amendПомогает во всех случаях, кроме разбиения большого коммита на несколько маленьких.
Не все сайты позволяют использовать пароли длиной 65 символов, к сожалению.
В одном из проектов, над которым я работал, автоматическое форматирование было сделано на уровне pre-commit-hook. Причем использовалась наивная реализация, когда из хука запускается программа форматирования, которая форматирует код всего проекта, но никак не обновляет данные для коммита. Это приводило к тому, что после коммита в рабочей копии появлялись изменения с правильным форматированием файлов, но они не попадали коммит.
Я бы использовал автоформатирование на двух уровнях: изменяющее, на уровне IDE, и проверяющее, на уровне CI. Конечно, это должна быть одна и та же программа с одинаковым набором правил.
Тема, обозначенная в эпиграфе, разобрана в статье академика Ершова: «Программирование — вторая грамотность».
Статья написана в прошлом веке и сейчас представляет скорее исторический интерес. Но рисунки забавные.
Там общаются пользователи плеска, обмениваются опытом и помогают друг другу по мере сил.
Если же говорить именно о саппорте, то он доступен 24/7, имеет строгие ограничения по времени ответа и никому не приходится ждать его «с февраля этого года».
Японский стиль, я полагаю.
;; Установка правильного шрифта.
(set-frame-font "-xos4-terminus-medium-r-normal--24-240-72-72-c-120-iso10646-1")
;; Установка кодировки вставляемых строк.
(setq x-select-request-type 'UTF8_STRING)
Конечно, для отдельных режимов могут понадобится дополнительные настройки.
Ряд замечаний, относительно подготовки рабочего места.
Устанавливая переменную auto-mode-alist в .emacs мы теряем её общесистемное значение — как правило, в переменной уже содержаться соответствия для различных режимов, как поставляемых с emacs, так и установленных с пакетами дистрибутива. Если это значение терять не хочется, лучше использовать функцию add-to-list.
Так же в emacs'е существует специальный режим для редактирования elisp — emacs-lisp-mode, возможно имеет смысл использовать именно его. В итоге, вместо (setq auto-mode-alist ...) можно написать нечто вроде:
(add-to-list 'auto-mode-alist '("\\.el$". emacs-lisp-mode))
Наконец, весьма вероятно, что emacs и без дополнительной настройки открывает .el файлы в нужном режиме — в этом случае вообще ничего писать не нужно.
На счёт global-font-lock-mode — аналогично, не исключено, что она включена по умолчанию.