В 2015-м я написал об инструментарии, который Ruby предоставляет для обнаружения управляемых утечек памяти. В основном статья рассказывала о легко управляемых утечках. На этот раз я расскажу об инструментах и хитростях, которые вы можете применять для ликвидации утечек, которые в Ruby не так легко проанализировать. В частности, я расскажу о mwrap, heaptrack, iseq_collector и chap.
Читать полностью »
Привет! Я руковожу разработкой платформы Vision — это наша публичная платформа, которая предоставляет доступ к моделям компьютерного зрения и позволяет вам решать такие задачи, как распознавание лиц, номеров, объектов и целых сцен. И сегодня хочу на примере Vision рассказать, как реализовать быстрый высоконагруженный сервис, использующий видеокарты, как его разворачивать и эксплуатировать.
Читать полностью »
В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть
Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?
Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Что делать, когда возможностей тестов недостаточно?
Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндекс.Почте, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.
Это вторая статья из цикла (первая статья тут), призванного привлечь внимание разработчиков и менеджеров к инженерному подходу к разработке ПО. В последнее время он незаслуженно обойдён вниманием, несмотря на революционные изменения в подходе и инструментах поддержки.
Было-стало после кластеризации и оптимизации культур
Колхозы и агрохолдинги в России почти не автоматизированы. А там на почти ровном месте с минимальными затратами можно получить до 10 % прироста доходности за счёт выбора оптимального портфеля выращиваемых культур, точного распределения техники по работам и вообще нормального планирования. Мы пришли на несколько объектов и провели расчёты для них, о чём сейчас я и расскажу.
Сформулировали три фундаментальных вопроса:
Мы решали все эти задачи, и там море интересных особенностей. Обсуждать мы будем абстрактный колхоз «Путь коммунизма», расположенный в случайном месте (нам просто понравились поля на спутниковой карте), потому что настоящих заказчиков я называть пока не могу.
В таких местах, конечно, действуют рациональные агенты. Но иногда встречается пьющий агроном, иногда попадается косячник-механизатор и другие узнаваемые персонажи из реальной жизни. Нас ждут град, сломанный комбайн и другие приключения. И вот мы пойдём в это всё со своей автоматизацией. Читать полностью »
Аполлон 11 на Луне
Через пять месяцев Аполло 12 выжил после удара молнии при разгоне и сел на Луну. Благодаря новому «существительному 69», которое мы добавили в программу для того, чтобы позволить команде изменять положение, основываясь на данных наземного слежения, астронавты Пит Конрад (Pete Conrad) и Алан Бин (Alan Bean) смогли посадить лунный модуль в шаговой доступности от беспилотного корабля Surveyor, который сел на Луну в апреле 1967. Точная посадка Аполлона 12 проложила дорогу для посадок на более сложный рельеф местности.
Читать полностью »
Часть фотографий была взята с сайта Hack The Moon.
Статья была представлена на 27-й ежегодной конференции по навигации и управлению Американского Общества Астронавтики (AAS) в Брекенридже, штат Колорадо, 6 февраля 2004. Предлагаемая вам версия содержит дополнительные иллюстрации, комментарии и небольшие исправления.
ABSTRACT: Миссия Аполлон 11 совершила успешную посадку на Луну, несмотря на две проблемы с компьютером, повлиявшие на лунный модуль в период управляемой посадки. Неустранённая проблема в интерфейсе радара сближения отняла около 13% времени цикла бортового компьютера, приведя к пяти сбоям программы и перезагрузкам. Менее известная проблема была вызвана ошибочными данными, что привело к флуктуациям тяги двигателя посадки лунного модуля, так как алгоритм управления тягой находился на границе устойчивости. Объяснение этих проблем даёт возможность описать операционную систему бортового компьютера Аполлона и программу управления посадкой на Луну.
Читать полностью »
В данной статье мы осуществим попытку проникновения в самое сердце "кровавого энтерпрайза" — в бухгалтерию. Вначале мы проведем исследование главной книги, счетов и баланса, выявим присущие им свойства и алгоритмы. Используем Python и технологию Test Driven Development. Здесь мы займемся прототипированием, поэтому вместо базы данных будем использовать базовые контейнеры: списки, словари и кортежи. Проект разрабатывается в соответствии с требованиями к проекту Empire ERP: https://github.com/nomhoi/empire-erp/blob/master/requirements.md.
Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками.
Питеркин Сергей, Меркулов Михаил, «Райтстеп»
За последние годы, количество производственных предприятий, заявляющих о внедренных ERPсистемах, значительно возросло. И составляет уже не десятки, а сотни. Говорим мы прежде всего о дискретном производстве, а под «производственной ERP» подразумеваем любую систему, претендующую на это гордое название. По частоте наших «столкновений», наиболее распространенными «работающими в производстве» ERP являются — BaaN/InforLN, InforERPSyteLine, постоянно-растущая «армия» заводов с 1С, и в небольшом количестве SAPERP и прочая экзотика.
Данная статься будет интересна прежде всего «продвинутым» пользователям ERP, в большей степени с позаказным типом производства («вытягивание» под заказ или на склад, в т.ч. и «вытягивание» под прогноз спроса), тем, кто автоматизировал (возможно – «как есть») процессы учета хода производства, т.е. формирования производственных заданий (далее по тексту – ПЗ. В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.
