Ранее описанный процесс изучения инстранных языков усовершенствовался, и досовершенствовался до того, что сейчас опубликована более продвинутая статья на сайте Gomel in English.
51 минуту назад
четверг, 14 августа 2014 г.
среда, 13 августа 2014 г.
вторник, 12 августа 2014 г.
Разработчики МПЦ «Ипуть»
Разбирая архивы нашел фото, на котором есть почти все разработчики процессорно-релейной централизации «Ипуть».
Слева направо:
- Бочков К. А.
- Руководитель проекта, решение всех политических, организационных и стратегических вопросов.
- Логвиненко А. В.
- Архитектура системы, разработка ядра ПРЦ, общая стратегия доказательства безопасности.
- Ермоленко А. В.
- Разработка алгоритмов работы станции, интеграция с устройствами и внешними системами ж.д. автоматики и телемеханики.
- Кузьмич М. C.
- Разработка безопасной системы сетевой передачи данных, разработка АРМа, разработка системы принятия решений.
- Сивко Б. В.
- Доказательство безопасности устройств связи с напольными объектами, разработка драйвера связи с напольными объектами.
- Харлап С. Н.
- Испытания системы на безопасность, разработка аппаратной части узлов интеграции с напольными объектами.
- Зобов С. М.
- Внедрение, испытания, дизайн и наладка системы, разработка алгоритмов работы станции, разработка подсистемы тестирования алгоритмов, электропитание.
Из ключевых не хватает только А. Ковриги, занимавшегося всеми вопросами с точки зрения ж. д. автоматики и телемеханики.
Кроме вышеописанного списка в разработке участвовало и неиллюзороно помогало более десятка других людей. Кроме того, значимые силы были задействованы специалистами КТЦ Белорусской железной дороги.
После ввода в эксплуатацию развитие проекта до версии 2.0 велось, но не такими темпами (это увязка с перегонами, повышение диверситета, разработка новых схем увязки с напольными объектами, повышение доли микро- по сравнению с реле, разработка систем автоматического тестирования, разработка безопасной виртуальной машины, разработка системы удаленного управления).
понедельник, 11 августа 2014 г.
Парижская школа
Где-то год назад у нас в городе была выставка художников Парижской школы. И сейчас пост о том, к чему может привести посещение такой выставки таким человеком как я (далеким от художественного искусства, только по понятиям).
Одно из того, что вынес из этой выставки было то, что Парижская школа в художестве сделала одну уникальную вещь, изменив вектор направления развития искусства и в некотором роде, вывела его из кризиса. Это изменение можно описать как смещение фокуса с реализма (попытки изобразить как можно ближе к реальности) на акцентирование определенных моментов, с помощью которых можно что-то сказать или показать. Например, на этой картине можно увидеть, что она изменена от реальности другими красками и цветами с определенным смыслом.
Если рассматривать глобально, то длительное время люди стремились изобразить на холсте реальность (мишки в лесу, натюрморты, портреты, …). Были конечно различия (на Западе как можно идеальнее и красивее, на Востоке изобразить как есть и найти там красоту и пр.), но в общем случае генеральный вектор к реальности был одинаков. Однако после какого-то момента ещё больше приближаться к реальности нет особого смысла. Если можно сделать фото, то зачем перерисовывать то же самое, только вручную? Соответственно, если мы фотографигруем мишек в лесу, то то же самое делать руками бессмысленно. Поэтому если хотим изобразить что-то, то лучше найти что-то более со смыслом (чего трудно в реальности), или сменить акцент. Что в свое время и сделала Парижская школа, выйдя из тупика (который был изображен в виде квадрата Малевича, он же символ конца искусства).
Сейчас пришел к такому выводу, что в ряде других областей наблюдается или наблюдалось такое же явление. Например, в научной фантастике, зародившейся где-то на Ж. Верне и Г. Уэллсе, а в дальнейшем был расцвет в виде т.н. классики (Беляев, Саймак, Бредбери, Хайнлайн). Однако, через некоторое время фантастика попала в кризис, рубеж которого находился где-то в районе Суммы Технологий Лема. Данное явление обсуловлено тем, что в фантастике нужно было успешно совмещать несколько вещей. Во-первых, быть достаточно подкаванным в науке, и разбираться в последних достижениях достаточно глубоко. Во-вторых, эту информацию преобразовывать читателю таким образом, чтобы он все это понял. И в-третьих, находить на этой научном гребне что-то новое, делая шаг вперед. Так как научный разрыв постоянно увеличивался от простых людей, то совмещать все это становилось сложнее и сложнее, и в конце концов фантастика свалилась в миры фэнтези. Таким образом, акцент с реальности сместился в фантазирование, оторванное от реальности.
Следующий яркий пример который можно наблюдать прямо сейчас это видеоигры. Длительное время все стремились сделать все реальнее, красивее, детальнее и проч.. Однако со временем из-за развития компьютеров во-первых, качество резальтата стало очень высоким, а во-вторых, для достижения этого качества уже не хватало команды в пару человек, нужна уже была большая студия с опытом работы. И таким образом, как мне кажется, где-то в районе 2007-2010 (в основном из-за уменьшения барьера инди) запустилось отдельным направлением из инди реализация таких видеоигр, которые особо не заморачиваются на качестве графики и прочего, а акцентируют свое внимание на совершенно других вещах, которые чем-то даже напоминают Парижскую Школу.
И последнее из замеченного — это демосцена. Сначала это было стремление сделать уникальные вещи на слабой технике (как аппаратных средствах, так и микропроцессорных), при этом делая это ближе к реальности. Например, сделать так, чтобы компьютер с одним бипером играл как оркестр, или заговорил человеческим голосом. Или сделать так, чтобы на мониторе с 256 цветами изображалось 16 млн цветов. Или изобразить множество полигонов с несколькими отражениями и всеми тенями и туманами, на что техника соответствующего времени неспособна. Однако после нарастания мощностей и совершенствования инструментов высокий реализм стал обыденностью, и поэтому демосцене пришлось перейти в искусство и утратить свою значимость.
воскресенье, 10 августа 2014 г.
Удобны ли ваши API?
Написанное здесь обусловлено тем, что в последние год-два приходилось сталкиваться наверное раз пять с различными проявлениями в отношении пользователей к API и документации в целом. В данном сообщении в основном все базируется на одноименной статье Стивена Кларка, имеющейся в книге «Идеальная разработка ПО», и в е-виде содержимое на находится. Стивен провел более 10 лет работая над совершенствованием API в Microsoft'е, с 1998-го года, с такими инструментами, как Visual Studio.
Удобство API
Сплошь и рядом попадается ситуация, когда проектирование библиотек, API и т.п. происходит как есть, для себя, по каким-то высшим или подсознательным катеогриям, но без какого-либо обращения внимания на пользователей, их разнообразие и решаемые ими задачи. Так получается, что потери reengineering'a с той стороны либо совершенно не волнуют, либо списываются на глупость или неусидчивость пользователей, и более того, идут аргументы вида «а вы используете неправильно, не ходите туда и не делайте так, делайте как мы».
Цитата С. Кларка:
Меня как разработчика, который пользовался Visual Studio до присоединения к группе Visual Studio, используемые инструменты часто раздражали. Параметры компилятора было трудно найти и задать. Настройка путей к библиотекам выглядела громоздкой и неудобной. У продукта было много недостатков из области удобства использования, которые я хотел исправить при поступлении на работу в Microsoft.
Я не хочу сказать, что у меня не было трудностей с API фирмы Microsoft. Напротив, чуть ли не самые серьезные проблемы, с которыми я когда-либо сталкивался, были связаны с пониманием API библиотек MFC. Но в отличие от ситуации с инструментами, в том, что мне не удается разобраться в правильном использовании VFC, я винил только себя. Ни разу я не подумал, что проблема крылась в проектировании API.
Такая реакция на плохо спроктированные API встречается очень часто. Многие разработчики объясняют возникающие трудности своей неопытностью в обращении с API. Будь у них побольше времени, то они бы во всем разобрались. Я много раз слышал, как разработчики говорят, что им просто не хватает ума для освоения API.
Таким образом, документация и API могут быть неудобными и плохо спроектированными. Если на это не обращать внимания, то именно так и произойдет, а при более внимательном рассмотрении можно даже понять почему.
Работа с API не представляет собой работу со всем API целиком
В повседневной работе лишь немногие работают сразу со всем API. Как правило, интересы ограничиваются только той задачей, которую пытаются решить. То есть, необходимо сосредотачиваться на том, для чего предназначены API, а не на том, что оно собой представляет.
Вторым моментом является то, что все API редко кто понимает или даже пытается понять, так как это большой объем информации. Используется какой-то участок фронта для какой-то задачи в течение какого-то времени. И все. Но с другой стороны баррикад почему-то считается правильным заставлять других учить авторские предрассудки и геометрию граблей архитектуры. Зато удобно и есть кого обвинить.
Аналогичную ситуацию наблюдаю с документацией. Вместо решения конкретных задач и ориентации на пользователя пишется большой талмуд обо всем, а на все вопросы идет ответ — идите читайте нашу прозу и медитируйте над тем, что мы тут натворили. Это как если бы вы пришли на почту с вопросом, когда приходит почтальон, а в ответ вам нужно было бы изучить архитектуру того, как работает организация, кто за что отвечает, откуда берет план и график обхода с точной траекторией.
Таким образом, в редких случаях идет работа пользователя целиком со всем, что есть. А для пользователя есть задачи, которые ему нужно решать. И в круг этих задач не входит постижение некого дао.
Разные пользователи
Одним из результатов исследований было то, что пользователи разные, в том плане что они по разному работают с API и её документацией. И вписаться сразу в каждый мир и угодить всем мягко говоря, сложно.
Три типа пользователей из статьи:
- Коньюктурщики (оппортунисты)
- Для этой категории характерна привычка к быстрому экспериментированию, задачно-ориентированный подход и широкое использование высокоуровневых конкретных компонентов.
- Прагматики
- Деятельность разработчиков этой категории ориентиирована на программный код. Они пользуются инструментами, которые способствуют улучшению правильности и надежности написаного кода.
- Педанты
- Для педантов характерен «безопасный подход» к разработке; они считают, что для использования любой технологии необходимо сначала глубоко разобраться в ней.
Первые работают на высоком уровне (абстракции), вторые и третьи на более низком. Педанты любят гибкость примитивов (например отображение файла в память и полный контроль). Прагматики склоняются к факторизированным компонентам, т.е. агрегатные компоненты для коньюктурщиков (чтение текстового файла и работа со строкой), но с выделенными типовыми режимами работы (бинарный файл, аналогичный тому, как на диске). Соответственно, для каждых из них имеется разное представление об удобстве API.
В данном случае одно из решений — сценарно-ориентированное проектирование. Так понял, что в данном случае это когда на сооветствющем уровне абстракции готовятся API и документация для соответствующего типа пользователя.
Таким образом, пользователи разные, и что хорошо одному, может быть плохо другому, и наобормот.
Архитектура API и интерфейс пользователю
Архитектура это одно, и она не обязана быть известной пользователю. Более того, чаще всего она не помогает в решении задачи. Для пользователя намного важным является интерфейс и предоставляемая функциональность, позволяющая решать его задачи. И если описывать архитектуру, то получится много, и не для пользователя.
суббота, 9 августа 2014 г.
Первая публикация с вариантом на английском
Где-то с месяц назад вышла первая моя научно-рецензированная статья, которую можно прочитать на английском. Это минский журнал «Надежность», от принятия до публикации прошло где-то немногим более полугода.
Статья посвящена проблемам валидации при разработке и верификации программного обеспечения для систем, критичных по безопасности (безопасность которая safety). В частности, про выбор функции безопасности, в котором необходимо как выполнять требования с минимальными потерями, так и соблюдать баланс.
Отпраздновать что ли…
пятница, 8 августа 2014 г.
О проблемах менеджмента в 1855-м году
Цитата из произведения North & South, для упрощения из версии Penguin Readers. Здесь Mr Thornton — собственник нескольких мануфактор, буржуй-предприниматель; Margaret — главная героиня. Диалог первый, относительно смысла в начале книги:
(Mr Thornton) 'Yes, the fools are going to strike. They think the cotton trade is as good as it was last year. They want better pay, but because we won't explain why we have refused their demand, and tell them we may have to lower wages, they think we are trying to cheat them.'
'But why can't you explain your reasons?' asked Margaret.
'Do you give your servants reasons for the way in which you spend your money? We manufacturers have a right to choose what we do with it.'
'What about the rights of the workers?' said Margaret quietly.
'I'm sorry, I did not hear what you said.'
'I would rather not repeat it,' she said. 'I don't think you will understand.'
'Please try and explain,' said Mr Thornton, who really wanted to know what she had said.
'I meant that the workers have rights too. Surely they deserve to know why you cannot pay them more.'
Mr Thornton paused for a moment and then said, 'In my opinion, the workers are like children. I do not think we mill owners try to keep them like that — it is just the way they are. They need to be told what to do and, like children, they do not need to be given reasons why.'
В моем переводе:
(Мистер Торнтон) 'Да, эти дураки собираются бастовать. Они думают, что торговля хлопком идет также хорошо, как и в прошлом году. Они хотят большей оплаты труда, но так как мы не будем объяснять почему мы отказываем на их требования, и почему зарплата будет меньше, они думают что нас хотят обмануть.'
'Но почему вы не объясните своих причин?' спросила Маргарет.
'А вы объясняете своим слугам почему и как вы тратите свои деньги? Мы промышленники имеем право делать то, что считаем нужным.'
'А что насчет прав рабочих?' сказала Маргарет тихо.
'Извините, но я не услышал что вы сказали.'
'Я бы и не повторяла,' сказала она. 'Не думаю, что вы поймете.'
'Пожалуйста, попробуйте объяснить,' сказал м-р Торнтон, который действительно хотел знать что она сказала.
'Имею ввиду, что рабочие имеют права тоже. И конечно, они заслужили того, чтобы знать почему вы не можете платить больше.'
М-р Торнтон сделал паузу и затем сказал: 'По моему мнению, рабочие как дети. Я не думаю что мы, владельцы, должны обращаться с ними таким образом. Это просто у них такая роль. Им нужно говорить, что делать, и, также как и с детьми, им не нужно объяснять почему.'
И вторая цитата, уже ближе к концу книги:
'My business has failed,' Mr Thornton said, 'and I am looking for a position in Milton where I can experiment with some ideas that I have.'
'What experiments are these?' asked Mr Colthurst respectfully.
'I now believe that an organisation can be much more successful if the employers and workers talk freely to one another and see each other as people. If an employer has a new plan, the workers may not realise how carefully he has thought about it. But if he discusses it with his workers, they will feel they are part of it and will want it to be successful.'
В моем переводе:
'Мой бизнес провалился,' сказал м-р Торнтон, 'и я ищу работу в Милтоне, где я смогу проэкспериментировать с некоторыми своими идеями.'
'А что за эксперименты?' списил мистер Колтурст с уважением.
'Сейчас я считаю, что организация может быть намного более успешна в случае, когда владельцы бизнеса и рабочие говорят свободно друг с другом, и видят в других людей. Если наниматель имеет новое намерение, то рабочие могут реализовать его так хорошо, как они это продумали. И если он обсуждает это с рабочими, то они будут чувствовать более свободно, а также считать себя частью предприятия, и захотят, чтобы все было успешно.'
И это при всем том, что не то что современных теорий управления, но даже Юнга и Фрейда ещё нет. А те, кто пуп земли, во многом и ныне там.
Подписаться на:
Сообщения (Atom)
