Почему некоторым нельзя помочь

Я регулярно провожу «сессии» на популярных технических форумах, где отвечаю на вопросы по программированию, юниксам и проектированию ПО вообще. За время такой практики, определил несколько признаков задаваемых вопросов, которые скорее всего так и останутся без четкого ответа.

Проблема

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

Поэтому вполне нормально как просить помощи так и помогать с решением, в этом нет и не может быть ничего необычного, предосудительного или «странного».

Аргументы из серии «тебе что больше всех надо» или «зачем тратить на это время» я если честно никогда не понимал и не принимал, потому что от такого до очередной вариации идеи о «смердах и высшей расе господ» — один шаг.

И надо сказать что такие радикальные идеи в ИТ очень популярны до сих пор.

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

Например не стоит пытаться переубедить фанатика или тратить время на общение с шизофреником, пусть и временным (под воздействием чего-нибудь).

Еще я стараюсь не помогать студентам и школьникам, так как они чаще всего просят решить за них какой-то элемент домашнего задания.

Не стоит также пытаться отвечать на вопросы в теме которых вы не разбираетесь совсем, а если опыта недостаточно — стоит честно об этом сообщить.

В нашем современном обществе, отравленным инстаграмом, желающих пустить пыль в глаза, рассказать «о том чего не было» и всячески преувеличить — тьма.

Естественно что это отрицательно влияет на доверие к вашим словам, а цена любой ошибки в вашем ответе (даже если это грамматика с пунктуацией) — взлетает до небес.

Насчет пунктуации это не шутка, например мои ответы на StackOverflow постоянно правили модераторы и именно орфографию и пунктуацию.

Что поделать, английский для меня не родной.

Причем это еще достаточно толерантный к иностранцам форум, в более «западных» вас с вашими ответами будут просто игнорировать.

Для вопрошающей стороны же, все описанное предсказуемо превращается в «тиндер из самых лучших типовых ответов на типовой же стандартный вопрос».

А любой шаг в сторону от мейнстрима — примерно как прогулка в кожаной короткой юбке посреди Ирана, как минимум не поймут.

Итак, признаки что ваш вопрос так и останется без ответа.

Пропустим все банальности про мат и оскорбления, про вопросы не по теме или заданные слишком расплывчато.

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

Признак первый: невоспроизводимая среда

Привожу цитату:

Есть язык программирования Tcl. Есть у него такая конструкция:

eltclsh > set t [clock scan {2004-10-30 05:00:00} \
-format {%Y-%m-%d %H:%M:%S} \
-timezone :America/New_York]

По идее должна выдавать секунды с начала эпохи для указанной даты во времени Нью-Йорка. Установлен Tcl в NixOS. Версия:

eltclsh > nixos-version 
23.11pre497256.86a9533155e (Tapir)

И вот в нём эта штука не работает.

Оочень редкий и старый язык и еще более редкая но при этом новая и экспериментальная ОС.

Шансы на то что появится другой пользователь с таким сочетанием и такой же проблемой приближается к нулю.

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

Это кстати причина №1 отсутствия поддержки редких ОС даже у кроссплатформенного ПО, даже если это технически возможно и не составляет особых проблем.

Признак второй: глобальное непонимание

В индустрии разработки ПО стало слишком много универсальности, слишком много способов сделать что-то нестандартными способами и/или инструментами. Из-за такого разнообразия тяжело выдавать ответы уровня «да/нет», «есть/нет» — т.е давать конкретику.

Цитата:

pragma optimize: почему рекомендуют вызывать в конце а не в начале? а если из отдельного коннекта?

Имеем сайт, т.е. приложение с очень большим аптаймом. База – SQLite. Нужно чтобы всё работало быстро, и стартовало / завершалось тоже.

Если вызывать pragma optimize при закрытии каждого соединения, как рекомендуют по ссылке выше, то есть шанс, что рано или поздно – и как положено, в самый неподходящий момент – оно задумается. А вместе с ним и админ: с чего это вдруг nginx не хочет завершаться? kill -9 его.

Понятно, что перед pragma optimize я ещё выдам pragma analysis_limit = 1000, чтобы оно совсем уж неприлично не задумывалось. Но внутренний перфекционист всё равно недоволен.

Проблема в том что SQLite это файловая база данных, рассчитанная на применение в качестве встраиваемой библиотеки.

Это не полноценный сервер баз данных, зараннее спроектированный, оттестированный и поддерживаемый для обработки паралльных запросов от разных пользователей.

Подключение к SQLite не подразумевает использования пула — набора из нескольких постоянно открытых подключений к базе, как раз и позволяющих параллельную обработку.

Т.е использовать SQLite для сайта конечно технически возможно, но на сайте не не должно быть какой-либо нагрузки и пользователей, что видимо и было.

При этом команда pragma optimize осуществляет внутреннюю оптимизацию базы — анализ и запись в базу статистики.

Очевидно (ну ок, пусть будет «мне лично очевидно»), что она не предназначена для постоянного вызова и будет сильно тормозить работу.

Теперь самое интересное:

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

Признак третий: нереальная крутизна

Цитата:

I'm implementing a GC algorithm for HotSpot these days. My GC algorithm is concurrent. As we all know, CMF may be occurred when doing GC. I just know that concurrent GCs will cause a Serial Old GC to handle CMF. Is this operation should be implemented by myself or the HotSpot will handle it for me(if so, how to notify HotSpot to do it for me)? Looking forward to your answers.

Перевод:

Я пытаюсь реализовать свой собственный алгоритм сборки мусора для виртуальной машины Java. Мой алгоритм - многопоточный. Как мы все знаем CMF (ошибка модификации многопоточного режима) может появиться во время работы сборщика мусора. Я лишь знаю что несколько параллельно выполняющихся сборщиков мусора запустят "старый последовательный сборщик" для исправления этой ошибки. Подскажите, эта операция должна быть реализована мною или сама виртуальная машина сделает это за меня (Если это так то как вызвать эту обработку)? C нетерпением жду ваших ответов.

Ну, как бы это попроще сказать, если автор не выдумывает, а на самом деле этим занимается — он нереально крут.

Такими задачами занимаются люди с академическим образованием, а например порог входа в проект сборщика мусора для JVM во времена еще версии 1.8 занимал полтора года.

Даже пытаться отвечать на такие вопросы — потенициальный удар по репутации.

Для РФ это врядли актуально, но в западном мире такие ответы тщательно изучают и работодатели и инвесторы и коллеги.

И все делают выводы, а главный вывод будет в том что вы —  «беспредельщик», раз полезли давать советы академикам.

Признак четвертый: коммерция

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

Цитата:

In Websphere Commerce 7, how do I remove the language and store name from an SEO url the correct way?

Currently the client I'm working for is making use of the SEO Friendly urls outlined here:

https://www.ibm.com/support/knowledgecenter/en/SSZLC2_8.0.0/com.ibm.commerce.seositemap.doc/concepts/csdSEOURLconstruction.htm

However, they would like to have /en/clientstorename removed from all urls. For example, when a user navigates to www.clientwebsite.com, the url automatically switches over to www.clientwebsite.com/en/clientstorename. I would like to remove the /en/clientstorename from the url, and all other urls on the site.

The client has also informed me that IHS changes are not a possible solution to this problem.

Перевод:

Я использую IBM Websphere Commerce 7 (продукт такой), как правильно удалить язык и название магазина из SEO-ссылки ?

В данный момент, клиент на которого я работаю, генерирует SEO-ссылки способом описанным по ссылке ниже: (см. выше)

Тем не менее, они хотели-бы убрать /en/clientstorename из всех ссылок. Например, когда пользователь переходит по ссылке www.clientwebsite.com, ссылка автоматически переключается на www.clientwebsite.com/en/clientstorename. Я бы хотел избавиться от /en/clientstorename из этой ссылки и всех других на сайте клиента.

Клиент также сообщил мне что программная доработка (кодированием) не является приемлимой.

Думаю степень наглости вопрошающего вы уже оценили:

он был нанят клиентом за деньги для решения этой проблемы, нанят как "эксперт", с сертификатами как минимум о прохождении курса по данному конкретному продукту IBM. А затем взял и пришел на форум за бесплатным решением.

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

Чаще всего они и в жизни считают всех айтишников «компьютерными задротами», которых всегда можно прижать, напугать и заставить.

Вообщем этот вопрос висит без ответа на Stackoverflow уже пять лет и будет висеть дальше.

Потому что прямой и четкий ответ/решение на такого рода вопросы подразумевает выставленный счет и почасовую оплату.

Ну и наконец самое веселое.

Игнорирование правильного ответа

Думаете если вы потратили время, заморочились и составили корректный и технически грамотный ответ то на этом все?

Вас немедленно полюбят и окружающие умрут от восторгов?

Конечно же нет, потому что есть такой замечательный человеческий фактор как:

И... и все.

Дальше хоть усритесь, но ваш правильный, выверенный и технически грамотный ответ будет проигнорирован, а все лавры получит какой-нибудь Джон или Майк, просто потому что они «больше понравились».

Справедливости ради, в профессиональной среде тиндер-эффект еще не так сильно распространен и прокачанный профиль еще чего-то стоит.

Но целое поколение молодых людей, привыкшее с юных лет «делать выбор свайпом влево» вам изменить уже не удастся, при всем желании.

Имейте это ввиду если вдруг захотите просто так кому-то отвечать на профильные для вас темы.