Почему "увы", это ваш опыт и это здорово. Отлично если все получилось и удовлетворяет потребностям. А мой пример, ну, он практический, но из моего опыта и сильно маргинальный )
Перегруженный синтаксис - это просто невозможно использовать. Такое ощущение, что другого способа парсить синтаксические конструкции языка при реализации компилятора/интерпретатора - просто не нашлось. Или, что автор печатает не на обычной клавиатуре, а на очень специфической, в которой дотянуться до всего этого многообразия довольно проблематично. Таким вероятно язык и задумывался - под специфичную клавиатуру, восприятие, сложный набор и ментальность. KISS. P.S. Я уж молчу что напоминает какую-то адскую смесь всех языков в мире. Говорят откровенно, глаза текут. Не хватает чистоты. Но наверное это только мне и только кажется. Простите меня за это.
Спасибо ), я тоже с вами согласен, что сразу увольнять не выход. Более того, во-первых, это не так то легко сделать, во-вторых видимо автор статьи поэтому и написал статью.
Для меня просто странно выглядит ситуация, в которой перевоспитывать человека будут люди, которого в статье описывают эпитетом "проблемник", и за глаза весь коллектив недолюбливает. Поэтому я думаю, что спасать то возможно надо не компанию и руководителя, что в "увольнении"(разрыве ТО) "проблемника", возможно кроется его спасение. То есть потенциально это сохранит, как его здоровье, так и коллектива. Пойдет на пользу обеим сторонам.
Но мы рассуждаем, и не знаем всей ситуации, мнения обеих сторон, знает ли об этом "проблемник", "проблемник" ли он на самом деле или нет, и даже если да, то для "кого" он проблемник? Я упоминал в предыдущем ответе что не исключена ситуация в которой какой-то "Альфа" сотрудник просто настраивает коллектив, умышленно или нет.
Мне понравился выход еще из ситуации довольно простой. Что если он работает медленно, то премировать остальных коллег, а его нет. Рано или поздно "проблемник" либо сам задаст вопрос, почему остальным премия а ему нет, либо руководителю самому придется это объяснить.
Но важен и момент, чтобы сохранив этого человека, он не стал "спусковым крючком" для других, потому что если степень недовольства "других" этим "проблемником" высока, то они могут пожелать рано или поздно разорвать трудовые отношения.
P.S. получается руководитель IBM вложил в него 1 миллион? ). Ну то есть компания потеряла 500к + он вложил в его обучение еще 500к ).
Попробую объяснить мою личную точку зрения и ответить: на мой личный взгляд, софт-скиллс зависят в разной степени от характера, воспитания, жизненных сложившихся обстоятельств (семья, дети, тяжелые ситуации, психологические проблемы или отклонения(аутизм например) и тп).
При всем уважении, я не уверен, что вы как сторонний человек (коллега или руководитель как автор статьи), сможете изменить характер и воспитание, хотя бы в силу времени и социального статуса по отношения к субъекту. У взрослого сформировавшегося человека, мне кажется поздновато менять характер, а базовые ценности, воспитание закладывают все-таки родители/опекуны.
Сложившиеся жизненные обстоятельства (отношения с женой, количество детей и их возраст(грудные дети, недосып и тд), семейные проблемы, и тп) мне тоже видится странным вмешиваться или менять.
Может и сможете, я не знаю ваших способностей, но лично мне это показалось бы странным, и думаю выглядело бы это тоже странным. Условно и теоретически увеличить количество детей в чужой семье вы можете, но боюсь это неизбежно повлияет на другие аспекты софт-скиллс субъекта.
Ну и если отбросить все вышесказанное, с чем вы можете не согласиться, по причине того, что это каким-либо образом связано или влияет на софт-скиллс например, то мне кажется странным менять человека и его софт-скиллс, людям (руководителю и коллегам), которые в представленной статье/ситуации, изначально называют его "проблемником", относятся к нему, не говоря ему все в лицо(?) и прямо(?) (за его спиной?), и относятся к нему с недоверием(?) и непониманием/неприятием/антипатией(?) — вопросы означают что я подвергаю это сомнению и возможно это не так по всем пунктам.
Проще говоря если человек вам не нравится, и если вы уже настроены к нему в неком негативном свете, то выглядит довольно странным пытаться его изменить именно вам. А в данной статье вроде бы отсутствует описание хотя бы одного лица, которое его открыто поддерживает и симпатизирует.
Я бы для помощи в принятии решения принял дополнительное допущение: допустил бы что он выполняет работу в те же сроки, что и все остальные, или даже быстрее или продуктивнее. Снова опросил остальных инженеров, как бы они в этом случае к нему относились, и было бы ли им комфортно с ним работать. Рискну предположить что они все равно бы отказались бы с ним работать.
Тут возможны два вывода: первый — софт-скиллс проблемника, мешают работать команде и его надо увольнять. Изменить его софт-скиллс вы вряд ли сможете.
Второй неочевидный вывод: проверить гипотезу о том, что коллективное большинство — тайно "подтравливает" или "съедает" по какой-то причине проблемника (внутренний конфликт, с одним(альфа) или несколькими инженерами большинства), и инициатива направленная на его итоговое "увольнение" исходит от них. Попытаться выяснить причину если таковая есть. Если её нет, то, вероятнее всего, это все-таки софт-скиллс проблемника и он действительно отравляет коллектив. Потому что я бы например не отказался от коллеги, который делает работу так же быстро как я, так же качественно как я, и при этом мне с ним работать комфортно.
Вывод: кроме потенциального случая, что это большинство его "подтравливает", нужно просто опеределить насколько соответствуют софт-скиллс проблемника, компании. Если он отравляет работу коллектива и потенциально угрожает стать спусовым крючком для других инженеров, я бы уволил без колебаний.
При этом, при принятии решения, я бы держал в голове, достаточно вероятную и часто встречающуюся, обратную ситуацию: вы нанимаете вместо проблемника "рубаху-парня — душу коллектива и звезду компании", который выполняет таски за двоих, и в сжатые сроки, отвечает на любые звонки, но при этом быть готовым переделывать его веселый код, или тратить объемы времени, соизмеримые с временем, на которое отставал тот самый проблемник.
Я не понимаю порой, как можно тащить в язык дженерики, и думать о них, когда в языке нет нормального Set (множества), который сделан на Map. Как по мне, это тоже пример непоследовательного подхода и попытки угодить страждущим.
И вот ниже resetme подсказывает, что в таком виде, не стоят дженерики того. Лично я скорее согласен. Они нужны, но в таком виде, субъективно, нет.
1) Ехал на собеседование на 50cc скутере, одной рукой держа телефон (дорогу смотрел), какой-то доставщик на легковушке дал по тормозам передо мной, я конкретно приложился об асфальт. На собеседование пришел в полувменяемом состоянии, не прошел
Устраивался как то на таможню, госслужбу, в специальное техническое подразделение. За два дня до собеседования, на нервной почве ли, или по еще какой причине, в глазу лопнул сосуд. Зрелище стремное, глаз красный, "залит" кровью. А через пару дней выглядит как "подбитый" глаз. Гематома расползается на нижнее веко, в общем приобретает натуральнейший вид после хорошей драки, прям как в детстве.
А собеседование назначено, динамить нельзя, тянуть бессмысленно, только второй день "фингалу", еще даже "зеленеть" не начал. Пришлось явиться.
Начальник отдела вышел встречать на проходную. Еще до его прихода чувствовал себя уголовником. Знаешь что полиграфа не будет, фингал — не настоящий, лопнул сосуд, а выглядит как после славной битвы за средиземье, и что тебе никто не поверит.
Собеседование все таки провели, и вероятно, я даже их удивил (не только фингалом, хотя фингалом конечно больше, уж слишком сильный диссонанс вызывало несоответствие вида моего лица, с общей технической осведомленностью). Мудрый начальник отдела, даже "почти" поверил в историю про лопнувший сосуд, после моих почти буквальных "мамой клянусь".
Провожая меня обратно через запретные коридоры до проходной, пожалел и меня, и видимо себя, что не может меня взять из-за подбитого глаза, вежливо попрощался, и пожелал чтобы сосуды сами больше не лопались, хитро подмигнув, мол, "да понял я что ты подрался, сынок, но не могу тебя взять такого на службу".
В тот момент, конечно, я расстроился, было досадно, но понимал что поверить мне невозможно, достаточно было просто на меня посмотреть.
Примерно так, испытав проблемы с трудоустройством, благодаря целой череде "неудач", в том числе последующих, я переквалифицировался из инженеров в программисты. О чем не жалею.
Спасибо, статья прям очень хорошо зашла. Прочитал про себя. Понял, что я отношусь к подобной категории (тугодум), на завод правда не захотелось все равно.
Единственное, возможно разница в том, что я могу довольно словоохотливо общаться на любом из этих совещаний (общителен), но правда будет в том, что я не выдам ни одного решения нормального, или вообще никакого, и в этот момент над ним не буду думать точно.
И еще такой момент (может быть есть такие поделитесь, и кмк его тоже можно учитывать), что я не очень хорошо воспринимаю на слух какие-то вещи, мне надо по-старинке воспроизвести это на бумаге или посмотреть как выглядит код, или работает, или в каком месте что-то расположено и тп.
Сиюсекундных решений принимать не люблю, одумываю, порой очень долго. Может быть не все это время, конечно, прям думаю над решением. Скорее погружаюсь в работу, я называю это состоянием "рабочего транса". То есть чтобы въехать в задачу, сфокусироваться, обдумать, отключить посторонние мысли и порой даже слух (перестаешь воспринимать разборчиво окружающие звуки/разговоры, начинают звучать как приглушенный фон) — надо войти в "рабочий транс".
Время которое необходимо, примерно соизмеримо с названными 23 минутами, в моем случае я "погружаюсь" в среднем от 30 до 50 минут. По прошествии этого времени, если меня не отрывать — я наиболее продутивен и работоспособен.
По-моему именно таким образом был сбит F-117 в небе над Югославией во время операции НАТО против Югославии. Стелс выдали открытые бомболюки, и самоуверенность в собственной "невидимости".
они действительно были странными, для всех людей хоть какое-то отношение имеющих к авиации. Особенно для пилотов и КВС. Есть стандартные процедуры, четко описанные в регламентах и чек-листах. В т.ч. процедуры выполняемые наземными службами и КВС на земле, относительно технического состояния самолета. Они(процедуры), отчасти, и созданы, чтобы отличать стандартные ситуации, от нестандартных, как в действиях пилотов, так и в происходящих вообще с бортом.
Конкретно в данном случае, совокупность фактов, исходящих от КВС, траектории полета, говорят не в пользу гипотезы экстренной ситуации(потенциально приводящей к падению) на начальной стадии полета.
Больше похоже на вполне осознанные действия или самого КВС, или внешних источников. Траектория разворота ВС на границе входа в зону ответственности Вьетнамских наземных служб, нереальна для выполнения автопилотом. Только в ручном режиме. Да и далее больно ловко избегались зоны радиолокации, и маяки контрольных точек воздушных трасс.
Для выполнения всех совокупных факторов, приведших к тому, что самолет был "потерян", надо быть не просто достаточно подкованным человеком. Надо было знать конкретно особенности данного ВС, знать не только технические зоны самолета, но и конкретно где отключать все транспондеры, как именно выводить их из строя, таким образом, чтобы дублирующие системы не "выдали" самолет. Помимо этого совершенно определенно надо было знать и понимать схему управления воздушным движением в данном регионе. Это возможно по контрольным картам, PFD. Ну и, разумеется, управлять воздушным судном. Понимать сможет ли самолет данного типа, при расчетных исходных данным, выполнить тот или иной маневр, хватит ли топлива и на сколько.
Так что даже если на секунду поверить в гипотезу захвата самолета посторонними, то совершенно точно они должны были обладать знаниями, не меньшими, чем сам командир воздушного судна.
Ну и странными выглядят не только действия командира, но и то что на земле, за несколько минут до вылета, ему поступал звонок с номера, сим-карта которого была приобретена неизвестным лицом по поддельным документам.
Слишком много "совпадений" или "случайностей", которые как известно "не случайны".
Но до доказательств всех теорий и гипотез, или подтверждения фактами, до сих пор нет, поэтому выводы каждый делает сам, и может только догадываться.
Для любителей конспирологических теорий будет интересен тот факт,
что на этом видео, в районе 6:37-7:05 указывается примерный район-дуга, который вычислили на основе спутниковых данных SATCOM. По довольно странному стечению обстоятельств, примерно в этом районе Индийского океана, находится атолл Диего-Гарсия, с расположенной на нем с 1973 года, одноименной американской военной базой Диего-Гарсия. Её еще называют иногда "Черной точкой ЦРУ", которая помимо авиабазы, по слухам, выполняет схожие функции с базой Гуантанамо на Кубе.
Странно что никто Clojure не вспомнил/упомянул в качестве современного диалекта Лиспа, где иммутабельность из коробки, впрочем элемент «мутабельности» там тоже присутствует там где это необходимо. И Clojure вполне себе функциональный язык.
Позволю себе не согласиться. Местами российский Калининград выглядит не только не хуже, но и лучше Гданьска. И справедливости ради, обращаю ваше внимание, что вы привели только фотографии Гданьска, приводили бы фотографии и Калининграда. Регулярно пребываю и в том и в другом городе, и не вижу упомянутой вами ужасающей разницы. Так же ее не увидели сами поляки приезжающие в Калининград, а также жители остальной Европы. Те же хорваты, приехавшие на ЧМ по футболу, в массе своей проживавшие в Польше на постоянной основе, не видят такой разницы. Поэтому если вам не нравится Калининград, или Гданьск нравится больше, не заставляйте верить в это остальных огульными сравнениями.
Почему "увы", это ваш опыт и это здорово. Отлично если все получилось и удовлетворяет потребностям. А мой пример, ну, он практический, но из моего опыта и сильно маргинальный )
Clojure + ClojureScript + Reagent. Настаиваю что это самая идеальная связка backend + frontend
Возможно есть более элегентные способы, которые я не учел, это просто сразу в голове было.
у заголовка не было контекста, и поэтому google translate не справился. Не льстите автору, если он человек, он GPT не использовал.
Перегруженный синтаксис - это просто невозможно использовать.
Такое ощущение, что другого способа парсить синтаксические конструкции языка при реализации компилятора/интерпретатора - просто не нашлось.
Или, что автор печатает не на обычной клавиатуре, а на очень специфической, в которой дотянуться до всего этого многообразия довольно проблематично. Таким вероятно язык и задумывался - под специфичную клавиатуру, восприятие, сложный набор и ментальность.
KISS.
P.S. Я уж молчу что напоминает какую-то адскую смесь всех языков в мире. Говорят откровенно, глаза текут. Не хватает чистоты. Но наверное это только мне и только кажется. Простите меня за это.
Проголосовал за экзотическое Phoenix LiveView. Оговорюсь это не мой выбор, а предположение. Сам бы выбрал Clojure/Script+Reagent
Спасибо ), я тоже с вами согласен, что сразу увольнять не выход. Более того, во-первых, это не так то легко сделать, во-вторых видимо автор статьи поэтому и написал статью.
Для меня просто странно выглядит ситуация, в которой перевоспитывать человека будут люди, которого в статье описывают эпитетом "проблемник", и за глаза весь коллектив недолюбливает. Поэтому я думаю, что спасать то возможно надо не компанию и руководителя, что в "увольнении"(разрыве ТО) "проблемника", возможно кроется его спасение. То есть потенциально это сохранит, как его здоровье, так и коллектива. Пойдет на пользу обеим сторонам.
Но мы рассуждаем, и не знаем всей ситуации, мнения обеих сторон, знает ли об этом "проблемник", "проблемник" ли он на самом деле или нет, и даже если да, то для "кого" он проблемник? Я упоминал в предыдущем ответе что не исключена ситуация в которой какой-то "Альфа" сотрудник просто настраивает коллектив, умышленно или нет.
Мне понравился выход еще из ситуации довольно простой. Что если он работает медленно, то премировать остальных коллег, а его нет. Рано или поздно "проблемник" либо сам задаст вопрос, почему остальным премия а ему нет, либо руководителю самому придется это объяснить.
Но важен и момент, чтобы сохранив этого человека, он не стал "спусковым крючком" для других, потому что если степень недовольства "других" этим "проблемником" высока, то они могут пожелать рано или поздно разорвать трудовые отношения.
P.S. получается руководитель IBM вложил в него 1 миллион? ). Ну то есть компания потеряла 500к + он вложил в его обучение еще 500к ).
Попробую объяснить мою личную точку зрения и ответить: на мой личный взгляд, софт-скиллс зависят в разной степени от характера, воспитания, жизненных сложившихся обстоятельств (семья, дети, тяжелые ситуации, психологические проблемы или отклонения(аутизм например) и тп).
При всем уважении, я не уверен, что вы как сторонний человек (коллега или руководитель как автор статьи), сможете изменить характер и воспитание, хотя бы в силу времени и социального статуса по отношения к субъекту. У взрослого сформировавшегося человека, мне кажется поздновато менять характер, а базовые ценности, воспитание закладывают все-таки родители/опекуны.
Сложившиеся жизненные обстоятельства (отношения с женой, количество детей и их возраст(грудные дети, недосып и тд), семейные проблемы, и тп) мне тоже видится странным вмешиваться или менять.
Может и сможете, я не знаю ваших способностей, но лично мне это показалось бы странным, и думаю выглядело бы это тоже странным. Условно и теоретически увеличить количество детей в чужой семье вы можете, но боюсь это неизбежно повлияет на другие аспекты софт-скиллс субъекта.
Ну и если отбросить все вышесказанное, с чем вы можете не согласиться, по причине того, что это каким-либо образом связано или влияет на софт-скиллс например, то мне кажется странным менять человека и его софт-скиллс, людям (руководителю и коллегам), которые в представленной статье/ситуации, изначально называют его "проблемником", относятся к нему, не говоря ему все в лицо(?) и прямо(?) (за его спиной?), и относятся к нему с недоверием(?) и непониманием/неприятием/антипатией(?) — вопросы означают что я подвергаю это сомнению и возможно это не так по всем пунктам.
Проще говоря если человек вам не нравится, и если вы уже настроены к нему в неком негативном свете, то выглядит довольно странным пытаться его изменить именно вам. А в данной статье вроде бы отсутствует описание хотя бы одного лица, которое его открыто поддерживает и симпатизирует.
Где в этом высказывании уверенность? В любом случае вы можете быть несогласны с этим высказыванием. Ваше право.
https://ru.wiktionary.org/wiki/вряд_ли
Я бы для помощи в принятии решения принял дополнительное допущение: допустил бы что он выполняет работу в те же сроки, что и все остальные, или даже быстрее или продуктивнее. Снова опросил остальных инженеров, как бы они в этом случае к нему относились, и было бы ли им комфортно с ним работать. Рискну предположить что они все равно бы отказались бы с ним работать.
Тут возможны два вывода: первый — софт-скиллс проблемника, мешают работать команде и его надо увольнять. Изменить его софт-скиллс вы вряд ли сможете.
Второй неочевидный вывод: проверить гипотезу о том, что коллективное большинство — тайно "подтравливает" или "съедает" по какой-то причине проблемника (внутренний конфликт, с одним(альфа) или несколькими инженерами большинства), и инициатива направленная на его итоговое "увольнение" исходит от них. Попытаться выяснить причину если таковая есть. Если её нет, то, вероятнее всего, это все-таки софт-скиллс проблемника и он действительно отравляет коллектив. Потому что я бы например не отказался от коллеги, который делает работу так же быстро как я, так же качественно как я, и при этом мне с ним работать комфортно.
Вывод: кроме потенциального случая, что это большинство его "подтравливает", нужно просто опеределить насколько соответствуют софт-скиллс проблемника, компании. Если он отравляет работу коллектива и потенциально угрожает стать спусовым крючком для других инженеров, я бы уволил без колебаний.
При этом, при принятии решения, я бы держал в голове, достаточно вероятную и часто встречающуюся, обратную ситуацию: вы нанимаете вместо проблемника "рубаху-парня — душу коллектива и звезду компании", который выполняет таски за двоих, и в сжатые сроки, отвечает на любые звонки, но при этом быть готовым переделывать его веселый код, или тратить объемы времени, соизмеримые с временем, на которое отставал тот самый проблемник.
Я не понимаю порой, как можно тащить в язык дженерики, и думать о них, когда в языке нет нормального Set (множества), который сделан на Map. Как по мне, это тоже пример непоследовательного подхода и попытки угодить страждущим.
И вот ниже resetme подсказывает, что в таком виде, не стоят дженерики того. Лично я скорее согласен. Они нужны, но в таком виде, субъективно, нет.
Устраивался как то на таможню, госслужбу, в специальное техническое подразделение. За два дня до собеседования, на нервной почве ли, или по еще какой причине, в глазу лопнул сосуд. Зрелище стремное, глаз красный, "залит" кровью. А через пару дней выглядит как "подбитый" глаз. Гематома расползается на нижнее веко, в общем приобретает натуральнейший вид после хорошей драки, прям как в детстве.
А собеседование назначено, динамить нельзя, тянуть бессмысленно, только второй день "фингалу", еще даже "зеленеть" не начал. Пришлось явиться.
Начальник отдела вышел встречать на проходную. Еще до его прихода чувствовал себя уголовником. Знаешь что полиграфа не будет, фингал — не настоящий, лопнул сосуд, а выглядит как после славной битвы за средиземье, и что тебе никто не поверит.
Собеседование все таки провели, и вероятно, я даже их удивил (не только фингалом, хотя фингалом конечно больше, уж слишком сильный диссонанс вызывало несоответствие вида моего лица, с общей технической осведомленностью). Мудрый начальник отдела, даже "почти" поверил в историю про лопнувший сосуд, после моих почти буквальных "мамой клянусь".
Провожая меня обратно через запретные коридоры до проходной, пожалел и меня, и видимо себя, что не может меня взять из-за подбитого глаза, вежливо попрощался, и пожелал чтобы сосуды сами больше не лопались, хитро подмигнув, мол, "да понял я что ты подрался, сынок, но не могу тебя взять такого на службу".
В тот момент, конечно, я расстроился, было досадно, но понимал что поверить мне невозможно, достаточно было просто на меня посмотреть.
Примерно так, испытав проблемы с трудоустройством, благодаря целой череде "неудач", в том числе последующих, я переквалифицировался из инженеров в программисты. О чем не жалею.
Спасибо, статья прям очень хорошо зашла. Прочитал про себя. Понял, что я отношусь к подобной категории (тугодум), на завод правда не захотелось все равно.
Единственное, возможно разница в том, что я могу довольно словоохотливо общаться на любом из этих совещаний (общителен), но правда будет в том, что я не выдам ни одного решения нормального, или вообще никакого, и в этот момент над ним не буду думать точно.
И еще такой момент (может быть есть такие поделитесь, и кмк его тоже можно учитывать), что я не очень хорошо воспринимаю на слух какие-то вещи, мне надо по-старинке воспроизвести это на бумаге или посмотреть как выглядит код, или работает, или в каком месте что-то расположено и тп.
Сиюсекундных решений принимать не люблю, одумываю, порой очень долго. Может быть не все это время, конечно, прям думаю над решением. Скорее погружаюсь в работу, я называю это состоянием "рабочего транса". То есть чтобы въехать в задачу, сфокусироваться, обдумать, отключить посторонние мысли и порой даже слух (перестаешь воспринимать разборчиво окружающие звуки/разговоры, начинают звучать как приглушенный фон) — надо войти в "рабочий транс".
Время которое необходимо, примерно соизмеримо с названными 23 минутами, в моем случае я "погружаюсь" в среднем от 30 до 50 минут. По прошествии этого времени, если меня не отрывать — я наиболее продутивен и работоспособен.
Спасибо за статью, было интересно.
Wallmart, Сбербанк, Apple, Deutche Bank, Datomic и тд.
Коротко
https://clojure.org/community/success_stories
Список компаний пополняемый:
https://clojure.org/community/companies
По-моему именно таким образом был сбит F-117 в небе над Югославией во время операции НАТО против Югославии. Стелс выдали открытые бомболюки, и самоуверенность в собственной "невидимости".
они действительно были странными, для всех людей хоть какое-то отношение имеющих к авиации. Особенно для пилотов и КВС. Есть стандартные процедуры, четко описанные в регламентах и чек-листах. В т.ч. процедуры выполняемые наземными службами и КВС на земле, относительно технического состояния самолета. Они(процедуры), отчасти, и созданы, чтобы отличать стандартные ситуации, от нестандартных, как в действиях пилотов, так и в происходящих вообще с бортом.
Конкретно в данном случае, совокупность фактов, исходящих от КВС, траектории полета, говорят не в пользу гипотезы экстренной ситуации(потенциально приводящей к падению) на начальной стадии полета.
Больше похоже на вполне осознанные действия или самого КВС, или внешних источников. Траектория разворота ВС на границе входа в зону ответственности Вьетнамских наземных служб, нереальна для выполнения автопилотом. Только в ручном режиме. Да и далее больно ловко избегались зоны радиолокации, и маяки контрольных точек воздушных трасс.
Для выполнения всех совокупных факторов, приведших к тому, что самолет был "потерян", надо быть не просто достаточно подкованным человеком. Надо было знать конкретно особенности данного ВС, знать не только технические зоны самолета, но и конкретно где отключать все транспондеры, как именно выводить их из строя, таким образом, чтобы дублирующие системы не "выдали" самолет. Помимо этого совершенно определенно надо было знать и понимать схему управления воздушным движением в данном регионе. Это возможно по контрольным картам, PFD. Ну и, разумеется, управлять воздушным судном. Понимать сможет ли самолет данного типа, при расчетных исходных данным, выполнить тот или иной маневр, хватит ли топлива и на сколько.
Так что даже если на секунду поверить в гипотезу захвата самолета посторонними, то совершенно точно они должны были обладать знаниями, не меньшими, чем сам командир воздушного судна.
Ну и странными выглядят не только действия командира, но и то что на земле, за несколько минут до вылета, ему поступал звонок с номера, сим-карта которого была приобретена неизвестным лицом по поддельным документам.
Слишком много "совпадений" или "случайностей", которые как известно "не случайны".
Но до доказательств всех теорий и гипотез, или подтверждения фактами, до сих пор нет, поэтому выводы каждый делает сам, и может только догадываться.
Для любителей конспирологических теорий будет интересен тот факт,
что на этом видео, в районе 6:37-7:05 указывается примерный район-дуга, который вычислили на основе спутниковых данных SATCOM. По довольно странному стечению обстоятельств, примерно в этом районе Индийского океана, находится атолл Диего-Гарсия, с расположенной на нем с 1973 года, одноименной американской военной базой Диего-Гарсия. Её еще называют иногда "Черной точкой ЦРУ", которая помимо авиабазы, по слухам, выполняет схожие функции с базой Гуантанамо на Кубе.
https://goo.gl/maps/yFXrjkrTt57n64JQ6
Еще на карте есть два странных, рядом расположенных объекта, с говорящими названиями.
https://goo.gl/maps/1XAxUpXWHY2DZA5M6
И еще по странному стечению обстоятельств, это одна из 5 авиабаз, которая загружена в упомянутый и любимый КВС-ом симулятор.
Но то, для любителей конспирологических теорий.