Вот только догадываются об этом лишь самые упёртые завсегдатаи. В представлении большинства программистов SO - это сервис, где можно задать вопрос и получить на него ответ. Не всем, прямо скажем, приходит в голову эта "прекрасная" идея о том, что задающий вопрос программист - это не равноправный участник процесса, а всего лишь безгласный кирпичик для Великой Базы Знаний (который, причём, скорее всего будет с презрением отвергнут).
Не говоря уже о том, что практически вся технология Stack Overflow направлена против достижения этой цели. Начиная с пресловутой "геймификации", которая поощряет как раз-таки только написание новых ответов, и вообще никак не поощряет улучшение старых; и заканчивая дурацким соревновательным принципом, который опять же, стимулирует написание возможно большего количества ответов на один и тот же вопрос, а не кооперативное улучшение существующего, как это на самом деле делается в Википедии. То есть никаким "аналогом Википедии" SO заведомо не мог стать, даже до появления LLM.
Да, действительно, я сначала не заметил, поскольку это заведомая бессмыслица. Никакого увеличения репутации ни от редактирования, ни от комментирования чужих ответов вы не получаете. Я снова теряюсь в догадках, что именно вы нафантазировали на этот раз. Что такое это "непостоянное" увеличение репутации, которое вы, очевидно, тут подразумеваете?
Виновата исходно негодная концепция: попытка усидеть на двух стульях, одновременно отвечая тем, кто задаёт вопросы, и составляя сборник канонических ответов.
На словах заявляем, что наша цель - "a library of detailed, high-quality answers to every question about programming", а на деле через геймификацию поощряем только написание новых ответов, а поддержка существующих ответов не организована вообще никак, и такое случается только в качестве исключения. То есть задача стабильного получения high-quality answers заведомо нерешаема - только ответы на совсем топовые вопросы можно считать приемлемыми. Это меньше процента.
На словах гордо заявляем, что "SO - не форум" (там же), но если открыть наугад почти любой популярный вопрос, то он совершенно неотличим от типичной страницы форума с десятками и сотнями ответов и микрообсуждений! То есть вместо одного качественного ответа у нас в библиотеке какие-то обрывки и огрызки, в которых надо копаться самому.
На словах заявляем, что у нас "дружественная атмосфера", а по факту люди рисуют мемасики, поскольку, как мне объяснили знающие люди, "задача составления качественного вопроса, достойного библиотеки, ложится на спрашивающего". То есть человека, который заведомо плавает в теме, заставляют написать вопрос так, как его бы задал эксперт. И разумеется, гонят драными тряпками 90% спрашивающих. То есть ни о какой "дружественности" речь даже близко не идёт, и в итоге задача ответов на поступающие вопросы тоже провалена.
Так забавно, что вы прочли "не вознаграждает" как "не даёт возможности" :)
Меня всегда интересовали такие случаи - о чем таком своём человек думал, что прочёл совсем не то, что было написано.
Но вопрос всё равно интересный. Сначала закончим про вознаграждает. На SO есть такая штука - "геймификация". Если ты активно отвечаешь на вопросы, то на тебя сыпется просто дождь из пластмассовых медалек, не говоря уже о баллах "репутации". Вот это я называю словом "вознаграждает". А за редактирование там вроде бы дают одну, если отредактируешь 100, что ли, ответов. И это вполне объяснимо, поскольку под редактированием подразумевается исправление опечаток и стилистических ляпов, а не внесение принципиальных изменений.
И здесь мы плавно переходим к вопросу принципиальной возможности правок. На серьезные правки там смотрят косо. "Как же так, человек старался, а ты весь ответ изгадил!". "А это ничего, что в ответе говнокод, а сайт, в общем-то изначально задумывался не для удовлетворения эго отдельных отвечателей, а для предоставления качественных ответов сразу для множества программистов?" - спрашиваешь ты. "Фу таким быть, низззззя!" - отвечают тебе. Если в самом популярном ответе написана чушь, то исправлять его нельзя. Надо написать свой. Который в популярном вопросе с десятками ответов увидит примерно никто (пример я приводил выше).
А по мне наоборот, море воды, а выводов с гулькин нос. Не показана самая главная проблема геймификации Stack Overflow - она поощряет только написание новых ответов, но вообще никак не вознаграждает за улучшение старых. Если первые пару лет это было оправдано, то дальше надо было сообразить, и повернуть руль в другую сторону. Но этого не случилось. И в итоге популярные ответы всё больше устаревали (например, в вопросе про то, как сделать из браузера асинхронный запрос к серверу, в 2024 году царил ответ для JQuery, а ответ про fetch API прозябал на второй странице, за год заработав один (один) балл репутации). Плюс SO начал стремительно захламляться ответами на одинаковые вопросы, что в итоге значительно затруднило поиск.
Также не показан совершенно карательный список причин закрытия:
Duplicate
Needs details or clarity
Needs more focus
Opinion-based
Needs debugging details
Seeking recommendations for books, tools, software libraries, and more
Not reproducible or was caused by a typo
Под который легко попадает больше 90% новых вопросов!
Вообще же, главным бичом SO является непоследовательность и взаимоисключающие параграфы буквально во всём:
Главной из которых является попытка усидеть на двух стульях: отвечать людям, пришедшим задать вопрос, и создать каталог качественных референсных ответов. В итоге:
людей, которые приходят задать вопрос, гоняют драными тряпками, потому что вопрос "или не идеально сформулирован, или уже был похожий, или кому-то показалось что он не по теме". Всё ради того, чтобы построить "великую библиотеку подробных ответов на любые вопросы по программированию"
люди же, которые приходят эту самую библиотеку из поиска, видят вместо неё кучу мусора, поскольку пресловутая геймификация поощряет к написанию возможно большего количества ответов за единицу времени, что, очевидно сказывается на качестве, и в результате ни о какой "подробности" речь уже не идёт. Не говоря уже о том, что со временем любой ответ устаревает, а "геймификация" не предлагает вообще ни одной пластмассовой медальки за поддержание ответов в актуальном состоянии
плюс отдельно надо отметить, что ответ на вопрос конкретного человека и написание качественного обобщённого ответа - это зачастую диаметрально противоположные задачи. И второе получить из первого получается очень редко
при этом заявляется, что SO - "это не форум", но соревновательная модель неизбежно делает любой популярный вопрос совершенно неотличимым от ветки форума, с кучей постов - ответов и обсуждения - комментариев под ними!
Вот это всё являлось основными причинами падения SO, задолго до появления LLM.
Всё это верно. Для сферического коня в вакууме. И совершенно очевидно.
Но если говорить про конкретную компанию, которая называет посадочные баржи диковинными именами космических кораблей из фантастического романа, и в целом известна постоянными отсылками к мемам и гик культуре, то тут очевидно, что это первую очередь шутка, и только во вторую - от "тренингов".
Я всё-таки верю в то, что в данном случае это всё-таки такая игра слов :)
Хотя, если подумать, то вполне возможно двойное назначение. Для своих это такой tongue-in-cheek, а для обывателя за утренним кофем "какие-то символы из высшей математики".
Ну кстати, по крайней мере если судить по вопросам на на qna сайтах, из проблем экранирования я бы на первое место поставил наивную веру в то, что оно экранирует некие "опасные символы SQL" и поэтому защищает любой помещаемый в запрос элемент, на второе - сознательный отказ от защиты "эти данные и так безопасны!" (впрочем, это является проблемой и для подставновок), и только на третье - "забыл".
А насчет подстановки типов я совершенно согласен, это самый удобный и наглядный вариант. По умолчанию, ({username}), делается стандартная подстановка, а если указывается ещё и тип, ({sort_column:ident}), то обработка в соответствии с этим типом.
И кстати, если говорить о самой фразе, то стилстически лучше бы подошёл "скоростной незапланированный демонтаж". Но увы, "разборка" уже прижилась в языке.
Ну Денис! "Быстрая незапланированная разборка" же. Это эвфемизм именно для слова "разрушение". Получается мало масляное. Если запускают космический корабль, то разрушение у него всегда быстрое и незапланированное. А если уж и писать "быстрое незапланированное разрушение" то в качестве рекурсивного троллинга (ср., например, "мужской половой ..й"), но тогда его надо брать не в кавычки, а выделять курсивом, чтобы все поняли, что это нарочно. И в этом варианте оно тогда должно присутствовать в тексте ровно один раз, а в остальных случаях будет просто разрушение.
Об этом и речь. Я-то комментировал не библиотеки, а статью. И писал про пример, приведённый в статье. Где используется совсем другой запрос, вида SELECT * FROM users WHERE username = '{username}' и в качестве защиты предлагается пресловутое "экранирование".
С одной стороны, радует, что комментаторы дружно не видят других вариантов, кроме подстановок. Но с другой - огорчает, что авторы статей всё ещё считают, что защитой от инъекций служит какое-то волшебное экранирование. У статьи влияние больше :(
Мда, с одной стороны, конечно отрадно, что выросло поколение, для которого существует только один способ поместить переменную в запрос :). Но почему вы называете параметризацию таким странным словом - "экранирование"? Что и зачем там экранируется?
Вопрос, разумеется, риторический. Всё-таки, исходно речь был про пример, приведённый в статье, и там очевидно речь идет именно об экранировании, а не подстановках. Хотя бы по той причине, что в запросе вокруг переменной стоят кавычки.
Мне кажется, тут никто либо статью не читал, либо вкладывает в слово "экранирование" какой-то свой особый смысл.
В статье приведён пример запроса
SELECT * FROM users WHERE username = '{username}'
В котором при вызове функции sanitize_sql() значение переменной username будет автоматически экранировано. Вы можете объяснить, с какой стати это экранирование сделает нерабочим запрос SELECT * FROM users ORDER BY {sort_column}?
Ага, и так для каждого значения в таблице. Прекрасная идея.
Вы, случайно, не забыли, о чём исходно шла речь? Она шла об универсальной функции экранирования любого литерала SQL. А не о переписывании имени поля для сортировки на многоэтажный код.
Не совсем ясно, насколько такой подход лучше уже существующего
В таком виде это вообще не вариант.
Этот пример слишком упрощён, и в таком виде представляет опасность. Не существует такой волшебной функции, которая абсолютно любое передаваемое в запрос значение каким-то волшебным образом сделает безопасным от инъекций. Это миф, популярность которого может соперничать только с его вредоносностью. Берём элементарный запрос
t"SELECT * FROM users ORDER BY {sort_column}"
"экранируем" его с помощью воображаемой функции "sanitize" и получаем идеальную инъекцию, из палаты мер и весов. Но при этом остаёмся в убеждении, что у нас всё безопасно.
Чтобы использовать t-строки для защиты от инъекций, надо вместе с переменной передавать контекст - тип SQL литерала, на место которого передаётся переменная. И тогда парсер сможет корректно этот литерал отформатировать. И очень важно, чтобы вокруг литерала не было кавычек. Потому что строковый литерал включает и обрамляющие его кавычки тоже. И тогда форматтер либо сделает строковое экранирование и заключит значение в кавычки, либо тупо заменит его целиком на плейсхолдер, а значение в несёт в список переменных на execute().
И в таком виде потенциал у подхода есть. Но реализовывать его надо очень аккуратно, не с кондачка.
Вот только догадываются об этом лишь самые упёртые завсегдатаи. В представлении большинства программистов SO - это сервис, где можно задать вопрос и получить на него ответ. Не всем, прямо скажем, приходит в голову эта "прекрасная" идея о том, что задающий вопрос программист - это не равноправный участник процесса, а всего лишь безгласный кирпичик для Великой Базы Знаний (который, причём, скорее всего будет с презрением отвергнут).
Не говоря уже о том, что практически вся технология Stack Overflow направлена против достижения этой цели. Начиная с пресловутой "геймификации", которая поощряет как раз-таки только написание новых ответов, и вообще никак не поощряет улучшение старых; и заканчивая дурацким соревновательным принципом, который опять же, стимулирует написание возможно большего количества ответов на один и тот же вопрос, а не кооперативное улучшение существующего, как это на самом деле делается в Википедии. То есть никаким "аналогом Википедии" SO заведомо не мог стать, даже до появления LLM.
После 2000
Да, действительно, я сначала не заметил, поскольку это заведомая бессмыслица. Никакого увеличения репутации ни от редактирования, ни от комментирования чужих ответов вы не получаете. Я снова теряюсь в догадках, что именно вы нафантазировали на этот раз. Что такое это "непостоянное" увеличение репутации, которое вы, очевидно, тут подразумеваете?
Виновата исходно негодная концепция: попытка усидеть на двух стульях, одновременно отвечая тем, кто задаёт вопросы, и составляя сборник канонических ответов.
На словах заявляем, что наша цель - "a library of detailed, high-quality answers to every question about programming", а на деле через геймификацию поощряем только написание новых ответов, а поддержка существующих ответов не организована вообще никак, и такое случается только в качестве исключения. То есть задача стабильного получения high-quality answers заведомо нерешаема - только ответы на совсем топовые вопросы можно считать приемлемыми. Это меньше процента.
На словах гордо заявляем, что "SO - не форум" (там же), но если открыть наугад почти любой популярный вопрос, то он совершенно неотличим от типичной страницы форума с десятками и сотнями ответов и микрообсуждений! То есть вместо одного качественного ответа у нас в библиотеке какие-то обрывки и огрызки, в которых надо копаться самому.
На словах заявляем, что у нас "дружественная атмосфера", а по факту люди рисуют мемасики, поскольку, как мне объяснили знающие люди, "задача составления качественного вопроса, достойного библиотеки, ложится на спрашивающего". То есть человека, который заведомо плавает в теме, заставляют написать вопрос так, как его бы задал эксперт. И разумеется, гонят драными тряпками 90% спрашивающих. То есть ни о какой "дружественности" речь даже близко не идёт, и в итоге задача ответов на поступающие вопросы тоже провалена.
Так забавно, что вы прочли "не вознаграждает" как "не даёт возможности" :)
Меня всегда интересовали такие случаи - о чем таком своём человек думал, что прочёл совсем не то, что было написано.
Но вопрос всё равно интересный. Сначала закончим про вознаграждает. На SO есть такая штука - "геймификация". Если ты активно отвечаешь на вопросы, то на тебя сыпется просто дождь из пластмассовых медалек, не говоря уже о баллах "репутации". Вот это я называю словом "вознаграждает". А за редактирование там вроде бы дают одну, если отредактируешь 100, что ли, ответов. И это вполне объяснимо, поскольку под редактированием подразумевается исправление опечаток и стилистических ляпов, а не внесение принципиальных изменений.
И здесь мы плавно переходим к вопросу принципиальной возможности правок. На серьезные правки там смотрят косо. "Как же так, человек старался, а ты весь ответ изгадил!". "А это ничего, что в ответе говнокод, а сайт, в общем-то изначально задумывался не для удовлетворения эго отдельных отвечателей, а для предоставления качественных ответов сразу для множества программистов?" - спрашиваешь ты. "Фу таким быть, низззззя!" - отвечают тебе. Если в самом популярном ответе написана чушь, то исправлять его нельзя. Надо написать свой. Который в популярном вопросе с десятками ответов увидит примерно никто (пример я приводил выше).
А по мне наоборот, море воды, а выводов с гулькин нос. Не показана самая главная проблема геймификации Stack Overflow - она поощряет только написание новых ответов, но вообще никак не вознаграждает за улучшение старых. Если первые пару лет это было оправдано, то дальше надо было сообразить, и повернуть руль в другую сторону. Но этого не случилось. И в итоге популярные ответы всё больше устаревали (например, в вопросе про то, как сделать из браузера асинхронный запрос к серверу, в 2024 году царил ответ для JQuery, а ответ про fetch API прозябал на второй странице, за год заработав один (один) балл репутации). Плюс SO начал стремительно захламляться ответами на одинаковые вопросы, что в итоге значительно затруднило поиск.
Также не показан совершенно карательный список причин закрытия:
Duplicate
Needs details or clarity
Needs more focus
Opinion-based
Needs debugging details
Seeking recommendations for books, tools, software libraries, and more
Not reproducible or was caused by a typo
Под который легко попадает больше 90% новых вопросов!
Вообще же, главным бичом SO является непоследовательность и взаимоисключающие параграфы буквально во всём:
Главной из которых является попытка усидеть на двух стульях: отвечать людям, пришедшим задать вопрос, и создать каталог качественных референсных ответов. В итоге:
людей, которые приходят задать вопрос, гоняют драными тряпками, потому что вопрос "или не идеально сформулирован, или уже был похожий, или кому-то показалось что он не по теме". Всё ради того, чтобы построить "великую библиотеку подробных ответов на любые вопросы по программированию"
люди же, которые приходят эту самую библиотеку из поиска, видят вместо неё кучу мусора, поскольку пресловутая геймификация поощряет к написанию возможно большего количества ответов за единицу времени, что, очевидно сказывается на качестве, и в результате ни о какой "подробности" речь уже не идёт. Не говоря уже о том, что со временем любой ответ устаревает, а "геймификация" не предлагает вообще ни одной пластмассовой медальки за поддержание ответов в актуальном состоянии
плюс отдельно надо отметить, что ответ на вопрос конкретного человека и написание качественного обобщённого ответа - это зачастую диаметрально противоположные задачи. И второе получить из первого получается очень редко
при этом заявляется, что SO - "это не форум", но соревновательная модель неизбежно делает любой популярный вопрос совершенно неотличимым от ветки форума, с кучей постов - ответов и обсуждения - комментариев под ними!
Вот это всё являлось основными причинами падения SO, задолго до появления LLM.
Напишите, пожалуйста, как это выглядит в оригинале, и я вам скажу, как это будет по-русски.
Всё это верно. Для сферического коня в вакууме. И совершенно очевидно.
Но если говорить про конкретную компанию, которая называет посадочные баржи диковинными именами космических кораблей из фантастического романа, и в целом известна постоянными отсылками к мемам и гик культуре, то тут очевидно, что это первую очередь шутка, и только во вторую - от "тренингов".
Я всё-таки верю в то, что в данном случае это всё-таки такая игра слов :)
Хотя, если подумать, то вполне возможно двойное назначение. Для своих это такой tongue-in-cheek, а для обывателя за утренним кофем "какие-то символы из высшей математики".
Ну кстати, по крайней мере если судить по вопросам на на qna сайтах, из проблем экранирования я бы на первое место поставил наивную веру в то, что оно экранирует некие "опасные символы SQL" и поэтому защищает любой помещаемый в запрос элемент, на второе - сознательный отказ от защиты "эти данные и так безопасны!" (впрочем, это является проблемой и для подставновок), и только на третье - "забыл".
А насчет подстановки типов я совершенно согласен, это самый удобный и наглядный вариант. По умолчанию, (
{username}), делается стандартная подстановка, а если указывается ещё и тип,({sort_column:ident}), то обработка в соответствии с этим типом.И кстати, если говорить о самой фразе, то стилстически лучше бы подошёл "скоростной незапланированный демонтаж". Но увы, "разборка" уже прижилась в языке.
Ну Денис! "Быстрая незапланированная разборка" же. Это эвфемизм именно для слова "разрушение". Получается мало масляное. Если запускают космический корабль, то разрушение у него всегда быстрое и незапланированное. А если уж и писать "быстрое незапланированное разрушение" то в качестве рекурсивного троллинга (ср., например, "мужской половой ..й"), но тогда его надо брать не в кавычки, а выделять курсивом, чтобы все поняли, что это нарочно. И в этом варианте оно тогда должно присутствовать в тексте ровно один раз, а в остальных случаях будет просто разрушение.
Об этом и речь. Я-то комментировал не библиотеки, а статью. И писал про пример, приведённый в статье. Где используется совсем другой запрос, вида
SELECT * FROM users WHERE username = '{username}'и в качестве защиты предлагается пресловутое "экранирование".С одной стороны, радует, что комментаторы дружно не видят других вариантов, кроме подстановок. Но с другой - огорчает, что авторы статей всё ещё считают, что защитой от инъекций служит какое-то волшебное экранирование. У статьи влияние больше :(
Мда, с одной стороны, конечно отрадно, что выросло поколение, для которого существует только один способ поместить переменную в запрос :). Но почему вы называете параметризацию таким странным словом - "экранирование"? Что и зачем там экранируется?
Вопрос, разумеется, риторический. Всё-таки, исходно речь был про пример, приведённый в статье, и там очевидно речь идет именно об экранировании, а не подстановках. Хотя бы по той причине, что в запросе вокруг переменной стоят кавычки.
С какой это стати он будет нерабочим?
Мне кажется, тут никто либо статью не читал, либо вкладывает в слово "экранирование" какой-то свой особый смысл.
В статье приведён пример запроса
SELECT * FROM users WHERE username = '{username}'В котором при вызове функции
sanitize_sql()значение переменнойusernameбудет автоматически экранировано. Вы можете объяснить, с какой стати это экранирование сделает нерабочим запросSELECT * FROM users ORDER BY {sort_column}?Ага, и так для каждого значения в таблице. Прекрасная идея.
Вы, случайно, не забыли, о чём исходно шла речь? Она шла об универсальной функции экранирования любого литерала SQL. А не о переписывании имени поля для сортировки на многоэтажный код.
Видимо, проблема в том, что о параметризации речь вообще не шла, а в статье говорится про экранирование?
Если экранировать, то всё плохо. Очень плохо. Само по себе "экранирование" не защищает вообще ни от чего.
С каких пор запись обычного строкового значения перестала быть элементарной операцией, не говоря уже о каком-то "не так просто"?
И она нормально отработает запрос из моего комментария? Можно попросить привести полный пример?
В таком виде это вообще не вариант.
Этот пример слишком упрощён, и в таком виде представляет опасность. Не существует такой волшебной функции, которая абсолютно любое передаваемое в запрос значение каким-то волшебным образом сделает безопасным от инъекций. Это миф, популярность которого может соперничать только с его вредоносностью. Берём элементарный запрос
t"SELECT * FROM users ORDER BY {sort_column}""экранируем" его с помощью воображаемой функции "sanitize" и получаем идеальную инъекцию, из палаты мер и весов. Но при этом остаёмся в убеждении, что у нас всё безопасно.
Чтобы использовать t-строки для защиты от инъекций, надо вместе с переменной передавать контекст - тип SQL литерала, на место которого передаётся переменная. И тогда парсер сможет корректно этот литерал отформатировать. И очень важно, чтобы вокруг литерала не было кавычек. Потому что строковый литерал включает и обрамляющие его кавычки тоже. И тогда форматтер либо сделает строковое экранирование и заключит значение в кавычки, либо тупо заменит его целиком на плейсхолдер, а значение в несёт в список переменных на execute().
И в таком виде потенциал у подхода есть. Но реализовывать его надо очень аккуратно, не с кондачка.