Category: it

Category was added automatically. Read all entries about "it".

Роскомнадзор "отключил" горячую воду владельцу "умного" бойлера

Роскомнадзор "отключил" горячую воду владельцу "умного" бойлера

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

Posted by Алексей Орлов on 17 янв 2019, 14:15

from Facebook

Орки, победившие технарей: Как силовики внедрились в «Лабораторию Касперского» — и к чему это…

Орки, победившие технарей: Как силовики внедрились в «Лабораторию Касперского» — и к чему это…

У «Лаборатории Касперского», крупнейшей российской компании, занимающейся кибербезопасностью, в последнее время большие проблемы на американском рынке. С осени 20...

Posted by Алексей Орлов on 22 янв 2018, 17:14

from Facebook

Как пишут ПО для космических аппаратов

Космос, как и любой большой проект, требует определенных навыков работы. Россия (СССР)  и раньше не очень то славился культурой проектов, сейчас их стремительно теряет. Нам кажется что раз мы Космическая Держава, то это и есть высокие технологии. А сейчас в любом смартфоне технологии намного круче. И не в смысле того, что Россия разучилась делать элементную базу (и вряд ли научится, если не поменяет методы). А то, что любое такое устройство - сложный проект, который соединяет в себе усилия многих, и многих людей.

Несомненно такая культура была. Именно такое объедение сил и отличает уровень развития цивилизации. Умеем объединять усилия и проектировать будущее, получаем Космос. Не умеем - уличный сортир. Это я не в смысле примитивности, а в смысле того,  что для канализации нужен определенный уровень проектирования, материалов и прочего.

Так вот, провальные решения  сегодня - это позавчерашние прорывные решения. Стоять на месте нельзя. Вот хорошее эссе как сейчас происходит программирование в  космической отрасли России.

Как у нас пишут ПО для космических аппаратов

Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов “у нас”, в отличие о того, что мы наблюдаем “у них“.

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

В общем, мой код уже летает в составе 2 модулей МКС, ещё один готовится улететь, а так же в составе нескольких спутников. Я не являюсь профессиональным инженером космических систем, но являюсь профессиональным программистом, поэтому и оценивать могу только часть касающуюся разработки ПО.

Все мои наблюдения оформлю в виде небольших тезисов.

  1. Большая часть ПО написана не профессиональными программистами.
    В основном функциональные системы написаны либо людьми имеющими инженерное образование связанное с летательными и космическими аппаратами, либо физиками и математиками, которым в силу необходимости пришлось научиться перекладывать свои знания на абстракции низкоуровневых языков программирования (типа C).
    Соответственно и на результаты такого написания кода без слёз взглянуть сложно.
  2. При написании бортовой части ПО используются технологии 20-30 летней давности.
    Это и устаревшие морально операционные системы, подходы к проектированию, реализации и тестированию программных продуктов. До сих пор можно найти документацию в виде страниц напечатанных на матричном принтере, которая в цифровом виде хранится у какого-нибудь дядечки на персональном компьютере под управлением MS-DOS, в одному ему известном месте.
  3. Для управления версионностью ПО не используются соответствующие программные продукты (Subversion, Git и т.п.).
    Даже если они и используются, то находится один (а чаще несколько) уникумов, которые не в состоянии их освоить, но в то же время являющиеся незаменимыми людьми, поэтому половина проекта находится под контролем системы управления версиями, а половина нет, что в итоге приводит к тому, что система начинает больше мешать, чем помогать в разработке.
  4. “Незаменимые” люди существуют.
    Существуют люди без которых разработка встает на месте. Чаще всего это связано с тем, что такой “незаменимый” держит в голове некие тайные знания на протяжении десятков лет и активно сопротивляется их формализации и оформлению в виде документации.
    Это может доходить до такого состояния, что с уходом “незаменимого” человека пропадают исходные тексты программ и целые пласты знаний, из-за чего приходится переписывать объемные системы с нуля.
  5. Отсутствие систем документооборота.
    Иногда таких систем просто нет, но чаще их просто не используют или использовать их крайне проблематично.
    В некоторых случаях система документооборота используется только для внешних по отношению к организации документов, для внутренней же документации используется переписка по e-mail, совещания и т.п.
  6. Бесконечные как по времени, так и по количеству совещания.
    Любое, даже самое мелкое действие для своей реализации может потребовать сбора совещания из 10-20 человек на срок 1,5-2 часа. Таких совещаний проводится 1-2 в день.
    На каждом таком совещании обсуждается сразу все вопросы, причем обсуждаются они по группам, т.к. эти вопросы редко касаются всех присутствующих, а в это время все остальные разговаривают между собой, играют или даже спят.
  7. Отсутствуют методология и системы модульного тестирования.
    Чаще всего, разработчик должен сам подумать и реализовать собственную систему модульного тестирования своего компонента, т.к. кроме него этим просто некому заняться.
  8. Слабо развиты методология и системы интеграционного тестирования.
    Чаще всего процесс слабо формализован и не поддается изменению. То есть, существуют формальные методики и люди занимающиеся тестированием, но получить что-то вменяемое от них практически невозможно.
    Все ошибки, в отсутствие системы учета багов, могут заноситься в бумажные журналы, которые сам разработчик должен отслеживать и после этого бежать к тестировщику для выяснения обстоятельств возникновения ошибки.
  9. Единственное, что спасает (далеко не всегда) ПО от багов это длительная многостадийная отработка.
    Зачастую при поступлении ПО на заключительную стадию тестирования в первые же несколько дней находят сотни ошибок.
    Иными словами, удивительно не то, что некоторые космические аппараты у нас не летают, удивительно то, что другие летают.
  10. Бессбойность работы не является приоритетом при проектировании и реализации.
    Многие предложения по повышению надежности ПО требующие лишь некоторого времени на реализацию отклоняются на том основании, что менеджер не видит или не понимает проблемы.
    Даже простейшие системы контроля параметров попадающих на борт внедрялись с большим трудом под предлогами “оптимизации” или недопустимости изменения интерфейса существующих функций используемых десятком разработчиков.
  11. Преждевременные псевдооптимизации при явной пессимизации.
    В программах почти всех инженеров ставших программистами по необходимости можно увидеть псевдомикрооптимизации, которые делают код нечитаемым (например: использование операций сдвига вместо умножения, использование битовых операций для ускорения исполнения программы, отказ от выделения функций для экономии на вызовах и т.д. и т.п.). Программы приобретают поистине кошмарный вид с десятком уровней вложенности и переиспользованием одной переменной для разных задач в пределах одной функции, с затейливой битовой арифметикой и шаманскими макросами имеющими глобальную область видимости.
    Вместе с тем при компилировании релизной бортовой версии могут быть сознательно выключены все оптимизации компилятора и линковщика для обеспечения какой-нибудь редкоиспользуемой низкоуровневой функции (например: реализации бинарных патчей). Что в конечном счете приводит к тому, что бортовой код становится медленным как черепаха и выходит за такт жесткого реалтайма, и в свою очередь вызывает новую волну дебильных микрооптимизаций по включению тела функций в места их вызова и замены нормальных вычислений сдвигами и т.п.
  12. Системная текучка кадров. Текучка кадров встроена в систему — такого слоя специалистов как грамотные опытные разработчики не пред пенсионного возраста практически нет. Есть два лагеря: профессионалы старой школы сопротивляющиеся всему новому и держащиеся за свои рабочие места (про них говорят: “Эти люди не читают книг — они их пишут”), и бывшие студенты ещё ничему не научившиеся и зачастую просто “отсиживающиеся” от призыва в армию. Большинство адекватных людей через 2-3 года работы понимают, что никаких перспектив и возможностей не предвидится и уходят на большие зарплаты. Но на их место уже готов новый набор из студентов.



Чему и как учат в ПТУ

Юрий Панчул [info]panchul написал пространную статью о том, как учат в МФТИ (Физтехе), одном из лучшем техническом ВУЗе страны.  Он приходит к выводу что раньше, что сейчас там не готовили специалистов в компьютерных науках. Готовили физиков, со знанием программирования, а остальное изучали сами. Как, впрочем, и в остальных вузах  студенты необъятной родины изучали одно, а работали над другим.   Может пора уже в консерватории поправить?

Нет, я совершенно не против того, чтобы 2% студентов МФТИ учили только физику, математическую физику и объем математики, необходимый и достаточный для поддержки физики, после чего уезжали в Великобританию и получали там Нобелевскую Премию за графен, после чего делали дурацкие заявления, что якобы изобретение графена моментально обнуляет все существующие силиконовые технологии.

Но а что делать остальным 98% физтехам, которых привлекли в юном возрасте в Долгопрудный рассказами о том, какое элитарное физико-ТЕХНИЧЕСКОЕ образование они смогут приобрести? Продолжать закрывать колоссальные дыры в физтеховском образовании - самообразованием, как это приходилось делать 25 лет назад? Например в то время ФУПМ популярно позиционировался как факультет для подготовки хмм, произнесем это постыдное слово, программистов. Ну и чему там учили? Физике, математической физике и объему математики, необходимого и достаточного для поддержки физики, плюс мааленький курсик по дискретному анализу и полстранички LR(k) алгоритма в курсе "Теория и реализация языков программирования", который не содержал и 5% материала, который учили по компиляторам студенты Стенфорда и Беркли (dataflow analysis, register coloring и т.д.). Кое-что учили на базах (теория графов, RTOS, базы данных), но не совсем в систематизированном виде.

В результате у студентов-компьютерщиков с ФУПМа образовывалось в мозгу два островка понимания мира - физика и выученное самостоятельно программирование на Си. Между этими островками находился абсолютный вакуум, в котором иногда пролетали астероиды самостоятельно выученного ассемблера, популярных статей про векторые суперкомпьютеры в русском переводе журнала "Electronics" и подобные случайные вещи. Небольшим архипелагом стояла Студенческая Лаборатория Компьютеризации под лидеством почившего Олега Бацукова в Лабораторном Корпусе, но это был скорее тоже развернутый вариант коллективного самообразования.

Только спустя 20 лет Сергей Вакуленко [info]ramlamyammambam дал мне разумное объяснение почему это было устроенно именно так. Согласно Вакуленко, на физтехе был крен в сторону матфизики, потому что стране были нужны программисты, которые были бы способны решать задачи типа расчета нагревания боеголовки при прохождении её через атмосферу. But seriously, folks. Прошло 25 лет, и к национальной задаче России бомбануть Америку прибавилась другая национальная задача - догнать и перегнать iPhone. И если россияне действительно хотят без дураков решить последнюю задачу, то им нужна другая программа физтеха - программа, в которой для компьютерщиков с самого первого курса была бы возможность пощупать весь спектр технологий между физикой и программированием на Си - logic design, FPGAs, logic synthesis, place and route, static timing analysis,computer architecture, pipelining, microcontrollers, embedded system design, RTOSes и другие.


Анализ речи Стива Джобса и сообщество риторики и ораторского мастерства

 Как то я давал ранее видео речь Стива Джобса "Оставайтесь голодными, оставайтесь безрассудными"  в Стенфорде. А теперь благодаря переводу nikita_avanti  (точнее его текста на habrhabr.ru)  приглашаю ознакомится с анализом речи Джобса сделаным Эндрю Длуган.

Пост размещен в новом сообществе Демосфен - ru_demosfen  посвященному искусству риторики и ораторского мастерства. 
Присоединяйтесь к сообществу!

Алан Купер о системном подходе к управлению бизнесом

Побег из психушки

Побег из психушки

Алан Купер, гуру проблем взаимодействия человек компьютер написал книгу-обоснование, как он её называет о философии этого взаимодействия «Психбольница в руках у пациентов»

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

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

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

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

Collapse )<\br>Этa cтатья была опубликована на сайте Искусство Организации Можно оставить комментарии здесь, а можно прокомментировать непосредственно на сайте.

Если бы программисты строили самолеты

Все мы знаем, что если бы программисты строили дома, то цивилизация была бы разрушена первым же дятлом.

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