Вход Регистрация
Написать

Программирование

Сортировать по: последним ответам дате количеству комментариев просмотрам рейтингу

Чему программисты могут научиться у экономистов: теоретическим принципам и моделированию

  • 09 декабря 2015 в 13:05
  • 0
  • 564
  • Kirill
или: О стереотипности современных программистов, отсутствии у них системного мышления и о том, почему это удручает

Между экономикой и компьютерной наукой есть некоторые сходства. Обе они сильно стремятся предположить, что открывалка есть [1, в конце документа]. Обе очень ограничены в плане воспроизводимости полученных результатов. Обе науки кажутся простыми для изучения с точки зрения простого обывателя. И обе они легко привлекают общественное внимание и обсуждаются в обществе.


Источник: DnE Blog

10 заповедей программирования без эго

«Программирование без эго» — перевод понятия egliess programming. Смысл в том, что разработчик осознанно отодвигает эго на второй план ради эффективности в работе. При разработке Web-payment.ru мы стараемся руководствоваться этими принципами. Если кто-то благодаря этому посту тоже начнет применять их в своем проекте, мы будем очень рады, ведь они помогают избежать конфликтов и несут в себе добро.

О программировании Стивен начал говорить с отцом за 2 недели до его смерти. Стивену было 22, он изучал графдизайн в колледже и почти получил степень бакалавра. Его отцу было 62 — больше, чем большинству отцов. Когда он только начинал програмировать в Теннессийском техническом университете в 60-е, то писал код на Фортране на перфокартах. Знал он очень много.

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

Когда Стивен приехал домой на каникулы, отец рассказал ему про 10 заповедей программирования без эго. Он распечатал их, и вдвоем со Стивеном они обсудили каждый пункт. Из-за внезапной смерти отца Заповеди стали одной из немногих программистских тем, которые Стивен успел обсудить вместе с ним. Возможно, именно поэтому они ему так запомнились.

Жизнь разработчика в картинках

  • 03 мая 2014 в 12:17
  • 2
  • 794
  • cigulev
Есть очень смешной сайт, который в gif картинках иллюстрирует жизнь разработчиков, вашему вниманию предлагаются несколько шедевров оттуда.

Сбой в системе:



Когда заставляют отказаться от привычного фреймворка:



Когда тим-лид показывает новичку, как решить проблему:



еще внутри...

Как 45 минут терять по $172 222 в секунду

  • 24 октября 2013 в 11:35
  • 0
  • 698
  • cigulev
Публикую интересный перевод поста David Wilson "How to lose $172,222 a second for 45 minutes":

Это, пожалуй, самый болезненный отчет об ошибке, который я когда-либо читал. Он красочно описывает шаги, которые привели к потере 465 миллионов долларов компанией Knight Capital в связи с ошибкой программного обеспечения, проявившейся в прошлом году и обанкротившей компанию.

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

Основные моменты:

Для обеспечения участия своих клиентов в Программе ликвидности (ПЛ) на Нью-Йоркской фондовой бирже, запуск которой планировался 1 августа 2012 года, Knight внес ряд изменений в свои системы и программный код, связанный с процессом обработки заказов. Эти изменения включали в себя разработку и развертывание нового программного кода в SMARS. SMARS представляет собой автоматизированный, высокоскоростной, алгоритмический маршрутизатор, который отправляет заказы на рынок. Одна из основных функций SMARS — это получение заказов от других компонентов торговой платформы Knight («родительских» заказов), и, по мере необходимости на основе имеющейся ликвидности, отправка одного или нескольких представительских (или «дочерних») заказов внешним службам на исполнение.

13. При развертывании новый ПЛ код в SMARS должен был заменить неиспользуемый код в соответствующей части маршрутизатора. Этот неиспользуемый код ранее был нужен для функции Power Peg, которую компания не применяла уже долгие годы. Несмотря на это, она оставалась рабочей и вызываемой во время развертывания ПЛ. Новый ПЛ код использовал флаг, который ранее был привязан к Power Peg. Knight хотела удалить код Power Peg, чтобы при активации этого флага использовалась новая функциональность ПЛ, а не Power Peg.

14. Ранее при использовании Power Peg суммирующая функция вычисляла количество акций в выполняемых дочерних заказах и сигнализировала о необходимости прекращения размещения дочерних заказов после того, как родительский заказ был выполнен. В 2003 году Knight прекратили использовать Power Peg. В 2005 Knight изменили код Power Peg, переместив функцию отслеживания выполнения родительского заказа на более раннюю стадию последовательности кода SMARS. Повторного тестирования кода Power Peg после изменения Knight не выполнили и в том, что процедура по-прежнему работает корректно, не убедились.

15. Начиная с 27 июля 2012, компания Knight развернула новый ПЛ код в SMARS, разместив его на ограниченном числе серверов. Во время развертывания нового кода один из техников не скопировал новый код на один из восьми серверов SMARS. В Knight не было второго техника, который бы проводил проверку развертывания, и никто не понял, что код Power Peg не был удален с восьмого сервера и новый ПЛ код не был добавлен. В Knight не было никаких письменных процедур, которые требовали бы такой проверки.

16. 1 августа Knight получала заказы от брокеров-дилеров, чьи клиенты могли участвовать в ПЛ. Семь серверов обрабатывали заказы правильно. Но заказы, отправленные на 8 сервер с установленным флагом запуска, запустили дефектный код Power Peg, который всё ещё присутствовал на этом сервере. В результате сервер воспринял заказы как родительские и начал отправлять дочерние заказы в трейдинговые центры. Вследствие того, что функция проверки выполнения родительского заказа была перемещена на другую стадию процесса, сервер продолжал размещать дочерние заказы безостановочно — не обращая внимания на то, что родительский заказ уже выполнен. Хотя некоторая часть системы обработки заказов определяла, что родительский заказ выполнен, в SMARS эта информация не попадала.

19. 1 августа Knight также получала заказы, которые относились к ПЛ, но предназначались для торговли до открытия рынка. 6 серверов SMARS обрабатывали эти заказы и, начиная примерно с 8:01 утра, внутренние системы генерировали автоматические сообщения (под названием «отказ BNET»), которые ссылались на SMARS и описывали ошибку как «Power Peg отключен». Система Knight отправила 97 таких сообщений до 9:30 утра, когда открылся рынок. Сообщения подобного типа не расценивались системой, как опасные, а персонал вообще не читал их.


Дальше еще веселее:

27. 1 августа в Knight не было никаких процедур, касающихся реагирования на инциденты. Иными словами, в компании не было контрольных процедур для руководства персоналом, когда происходили серьезные проблемы. 1 августа Knight пользовался услугами своей команды техников, чтобы выявить и устранить проблемы в SMARS в живой торговой среде. Система Knight продолжала посылать миллионы «дочерних» заказов, пока персонал пытался выявить источник проблемы. Компания даже удалила новый ПЛ код с семи серверов, на которых он был установлен правильно. Это усугубило ситуацию, ведь новые «родительские» заказы активировали код Power Peg, который присутствовал на этих серверах, подобно тому, что уже произошло на восьмом сервере.


Безусловно, стоит прочитать весь документ, в нем большое внимание уделяется новым процедурам проверки, выполняемым людьми, чтобы избежать подобной трагедии. Ошибки разработчиков, безусловно, были связаны с человеческим фактором, но такие последствия стали результатом плохого сценария развертывания и отвратительного мониторинга. Что это за контора, в которой даже не проверяют версию программного обеспечения кластера? Не говоря уже о сценарии развертывания, при котором проверяются коды возврата.

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

И на сладкое: штраф составил еще 12 миллионов долларов, проведенный аудит показал, что система постоянно пыталась осуществить спекулятивные короткие продажи.