Горюче-сказочные материалы
1.44K subscribers
1.85K photos
77 videos
18 files
2.07K links
Download Telegram
При изучении любого сложного подхода по книгам возникает одна и та же проблема: А как проверить, что действительно понял написанное? Хорошо, если есть проверочные упражнения, но и они не дают полной гарантии. И что вообще означает правильное понимание? Полное совпадение по мыслям с автором? Но автор мог ошибиться.

В итоге получается, что какое-то количество прочитавших понимает неправильно, но вполне успешно (по их собственным критериям) подход применяет.
Проект может быть либо завершён, либо нет. «Функционирующий прототип» не означает вообще ничего, его реализация может занять две недели, а потом два года потребуется на «завершение работы». Исключение тут только одно есть: изготовитель чётко следуют отлаженным процессам и у него в «предметном словаре» (domain vocabulary) есть понятие «функционирующий прототип». При этом наблюдатель должен быть знаком с этим словарём и процессами, чтобы верно всё оценивать.

К сожалению, почти всегда понятие «прототип» относится к области маркетинга, чем к предметной части проекта.
Когда учился в аспирантуре, изучал модный в то время Semantic Web, кандидаты фанбойных наук всерьёз считали, что за этим будущее. Но уже было понятно, что в таком виде и в такой предметной области (то есть в вебе) это не выживет.

Сначала коротко, что вообще такое — этот semantic web. Если коротко, то финальная цель — машиночитаемые максимально подробные метаданные у всех документов в интернете, включая картинки, фотографии, веб-сайты, просто файлы, вообще всё, короче, слово документ тут нужно понимать в широком смысле. Машиночитаемые метаданные — это данные о документе: автор, дата создания, история редактирования, контекст. В общем, максимально подробно записанные в стандартном виде данные о содержимом. Примеры: EXIF для фотографий, ID3TAG для mp3, описания word/pdf/xls документов (title, author, description итп).

Ключевых проблем было две.

Во-первых, пользователи не будут никогда заполнять метаданные так, чтобы им можно было автоматически доверять. Можете вспомнить, какой хаос творится в ID3-тегах в мптришечках из интернета, или что записано в поле author почти любого pdf/doc файла.

А во-вторых, уже тогда стало понятно, что главными распространителями документов постепенно становятся корпорации, а не люди, а корпорации очень не любят машиночитаемые метаданные в отдаваемых ими документах (картинках, веб-страницах итп). Ведь машиночитаемые метаданные, по которым можно проводить категоризацию, являются отличным подарком конкурентам, которые могут перетащить документы себе. Или являются подарком другим компаниям, которые организуют свою инфраструктуру для обработки документов, минуя предоставляемую корпорацией.

При этом в теории лежащие в основе semantic web идеи очень толковые и полезные, кандидаты фанбойных наук в творческом угаре насоздавали очень много очень толковых концепций, технологий и программ: RDF, OWL, RIF. И позднее применение этим вещам нашлось в корпорациях и системной инженерии, где на их основе стали городить умные онтологические штуки, но, к великому сожалению, закрытые от широкой публики.
И ещё прекрасная история:

I used to work for a mapping & navigation company that offered a traffic API service. It worked by using anonymized cell phone data to predict traffic patterns. I once heard a story that during peak hour, every five minutes or so the jams on a highway would magically disappear then reappear. After some head scratching, turns out there is a train track inbetween the lanes of the highway full of high speed commuters that would cancel out the stationary car commuters.

Перевод: Я работал в картографической компании, которая предлагала API для просмотра дорожного трафика. Сервис анализировал анонимизированные данные сотовых операторов, чтобы предсказать паттерны трафика. И однажды услышал историю, как в час пик каждые пять минут или около того заторы на магистрали волшебным образом исчезали, а затем снова появлялись. Разгадка этой головоломки оказалась в рельсах между полосами магистрали, по которым на высокой скорости ехала электричка со смартфонами, а вокруг стояли в пробке другие смартфоны.
Суда по графикам - эпидемии не допустили. Рост новых подозрений на вирус остановился. Значит через несколько дней развернётся число заболевших, еще через одну-две недели пойдёт вниз смертность. Будем надеятся.

Первоначальная паника среди простого народа понемногу утихает, и скоро их пропаганда начнёт качать "великий подвиг китайского народа, спасшего мир от смертельного вируса". И под это дело протащат ещё большую диктатуру. Потому что только диктатура может так эффективно закрывать мегаполисы, так быстро строить госпитали и так хорошо мобилизовывать ресурсы.

А экономические потери компенсируют ударным трудом и сокращением праздников в мае и октябре. И ослаблением юаня.

-конец блока диванной экспертизы-
“Friends don't let friends use cloud hosting”
Напомнили про эпичный баг в твиторе, который один в один повторяет телеграмный. И это по идее должно побудить корпорации что-то сделать с 2FA авторизацией и как минимум сделать емейлы опциональными. Но нет, этого не будет. И даже после новых рекомендаций NIST, в которых, по слухам, MFA via SMS будет явным образом запрещена.
У разработки коробочного продукта есть «приятный» нюанс — постоянно меняющиеся требования. Это неотъемлемая часть процесса, от которой избавиться невозможно в принципе. У вас неизбежно появится однажды покупатель, у которого ваша умная и красивая архитектура даст фатальный сбой.

Например, для продуктов enterprise-рынка почти обязательной фичей является поддержка ActiveDirectory. Но некоторые клиенты не используют AD, поэтому нужна поддержка других конкретных LDAP-серверов. Сразу можете забыть про абстрактный LDAP, это не работает в реальности. И вот вы такой умный сделали всё, а тут приходит клиент, у которого пятьсот тысяч LDAP-групп и тысяча пользователей… Или у которого вся иерархия построена не на группах, а на OU… И всё разваливается полностью. Люди в дизайне LDAP проявляют дивную фантазию.
Рекламная компания Гугол опубликовала отчёт за 2019 год, доход от Google Cloud составил 8,9 млрд долларов, а доход от рекламы — 134,811 млрд. (Для сравнения, амазон на облачных сервисах заработал 35 млрд.)

Всего гугол заработал 161,857 млрд., что на 25 млрд. больше результатов 2018 года.
Товарищ выдвинул теорию, что случится, если все крупные американские компании (google, amazon, facebook, apple, microsoft) одномоментно перестанут нанимать людей: зарплаты обрушатся до среднего уровня, поскольку уровень зарплат держится на таком высоком уровне исключительно из-за конкуренции, которую создают перечисленные компании, нанимая постоянно огромное количество людей. Ну и ещё выдвигает несколько теорий, как эти компании могут пользоваться своим монопольным положением на рынке труда.
Вот иллюстрация из стандарта ISO 15926, на которой показана упрощённая схема жизненного цикла завода. Рамкой я обвёл фазы, которые обычно находятся в фокусе обывателя, а всё остально обычно остаётся за кадром.
Русский язык плохо подходит для изучения современных систем, подходов и парадигм, он всегда будет языком второго сорта, на который разными авторами переводятся тексты с английского. Поэтому литературу на русском лучше всего использовать параллельно с англоязычной, а систему понятий (словарный запаса) сразу строить в мозгу на английском языке.
Системная инженерия, которую мы заслужили.
Изучение новой области часто очень сильно меняет способ мышления. Начинают появляться новые мысли, причём они появляются не обособлено, а бесшовно и логично встраиваются в обычную цепочку размышлений. Многие из таких вещей происходят из философии и философских рассуждений: разница между конкретным и абстрактным, разница между объектом и его описанием, разница между объектом как таковым и его «представлением» (то есть как он ощущается органами чувств).

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

Системная инженерия занимается только рукотворными и материальными системами. Под словом материальный понимается система, занимающая некоторый объём в пространстве и времени. Например, клавиатура, на которой я набираю текст; монитор, на котором я вижу этот текст; новогодний корпоратив, на котором я был в конце декабря 2019 года. Первые два примера обычно воспринимаются адекватно, а насчёт третьего возникает сразу вопрос: а как может быть событие материально? А вот так, оно удовлетворяет всем требованиям: занимает место в пространстве (пансионат «Весёлая белочка») и времени (27 декабря, с 18:00 до 24:00), мероприятие однозначно рукотворное — некие конкретные люди его подготовили, провели и потом ликвидировали.

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

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

И ещё момент, очень важно не удариться в глубокую философию, так как в это болото можно погружаться всю жизнь и вместо реальной деятельности заниматься безрезультатной схоластикой.
Да, нужно отличать системное мышление от системной инженерии. Предметом интереса системного мышления являются вообще любые системы, не только рукотворные.
Формальное определение архитектуры в системной инженерии очень сложное. Понятно, что все сразу путают архитектуру (architecture) и описание архитектуры (architecture description). Описание архитектуры — это записанные на материальном носителе данные, после чтения и обдумывания которых становится понятна архитектура. Описание архитектуры конкретно — это артефакт, при этом архитектура сама по себе абстрактна. Архитектура у системы есть всегда, но описания может не быть.

А теперь, что такое архитектура. В ISO/IEC 42010 дано такое определение:

fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

Эта фраза очень компактная и её нужно разобрать отдельно буквально по словам.

fundamental означает, что там не абсолютно обо всём в системе, а только о самом важном и существенном.

concepts or properties of a system означает, что поддерживаются равноправно два подхода: концептуальный, то есть архитектура как ментальная/концептуальная модель в мозгу, и архитектура как воспринимаемые свойства системы.

in its environment означает, что система всегда рассматривается в окружении, то есть среди или внутри других систем.

embodied in its elements, relationships, and in the principles of its design and evolution означает, что концепты и свойства заключены в следующих вещах: элементы, отношения (как между элементами самой системы, так и элементами извне), принципы их (элементов и отношений!) создания и развития.

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

Да, разных определений архитектуры, наверное, сотни. Они все в какой-то степени пересекаются, но общее у них одно: архитектура — это самое важное о системе. Очень глубокий разбор этого понятия можно почитать в SEBoK wiki.
Программерское собеседование — это отдельный скилл, который слабо пересекается с обычной ежедневной работой программиста. К такому собеседованию надо готовиться. Если вы идёте на ублюдочные экзаменационные собеседования в стиле гугла/амазона/яндекса, то нужно готовиться по сайтам типа leetcode. Если идёте на нормальные собеседования, то всё равно нужно готовиться.

Во-первых, вы должны знать буквально наизусть базовые приёмы языка, на котором будете сдавать экзамен. У вас не будет времени их вспоминать или выводить из других приёмов. Например, нужно чётко знать, как разделить список пополам, знать и учитывать краевые случаи, чтобы не выйти за границы массива. Это, вроде, очевидно, но об этом не нужно думать во время решения, нужно это просто знать наизусть. Нужно знать все базовые арифметически операции, включая целочисленное деление, остаток от деления, битовые сдвиги, представление целых чисел.

Во-вторых, вы должны наизусть знать базовые алгоритмы типа quicksort. Особо подчеркну, наизусть. Времени их вспоминать не будет.

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

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

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

На экзамене-собеседовании не ждите глубоких вопросов, на них просто не хватит времени за выделенный час времени. Также на таком экзамене не ждите вопросов по вашим проектам на гитхабе из резюме, интервьюеру на них по большому счёту наплевать. Экзамен — это поток, примерно одинаковые вопросы для всех, по которым фильтруется куча людей, отдельно разбираться с каждым никто не будет.

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

И самое-самое главное — кодерское собеседование для лохов. Нормальные люди на нормальные должности проходят через совершенно другие фильтры и совершенно другие собеседования.
Forwarded from Noise in the wires
Современность требует современных решений.

- Во, так получаем примерно 3-4 тысячи ботов на IoT. Тренируем их на таргет, скармливаем им правильный вывод страницы покупки, варианты неправильных, делаем связи между неправильными выводами и причинами, делаем сценарии. Для управления и тренировки юзаем три джаббер канала - один для отдачи команд, другой для ответов типа "статус", третий для ответов по задаче. Нужное файло кладем на крупные порталы для художников, типа девиантарта, завернув в джипег - там обычно канал на отдачу окей и секьюрити хуи пинают.
В назначенный день боты группы А волнами заходят на сайт и чекают страничку, с разными юзерагентами, на предмет изменений. Если изменения есть - сразу пробуют бай, если бай не прошел - репортят об этом во второй чат, оттуда уже джаббер-бот кидает в первый чат команду группе ботов Б, они начинают сайт волнами ддосить сином и смурфом, причем делают из себя сеть для прохождения смурфов на 1000-2000 узлов, получается эффективно. В паузах между атаками четко заходит первая группа и пробует бай, под разными юзерагентами, если бай все же прошел - репортит во второй канал и в третий выдает результаты. Если на сайте вылезает что-то новое, чего не было во время обучения ботов - то тоже кидает в третий канал, чтобы оператор успел вовремя среагировать и поменять профиль атаки.
- Эээ, напомни, а зачем это все?
- Покупаем лимитки сникеров и всякие supreme box logo hoodie для перепродажи.
- ...