Рубрика «оптимизация»

С появлением Java 8 Stream API позволило программистам писать существенно короче то, что раньше занимало много строк кода. Однако оказалось, что многие даже с использованием Stream API пишут длиннее, чем надо. Причём это не только делает код длиннее и усложняет его понимание, но иногда приводит к существенному провалу производительности. Не всегда понятно, почему люди так пишут. Возможно, они прочитали только небольшой кусок документации, а про другие возможности не слышали. Или вообще документацию не читали, просто видели где-то пример и решили сделать похоже. Иногда это напоминает анекдот про «задача сведена к предыдущей».

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

Читать полностью »

Вступление

  1. Моделирование транспортных потоков стало одной из лидирующих проблем в науке, чуть ли не с появления первых автомобилей. Считается, что родоначальником данной отрасли является учёный ещё из царской России Дубелир со своей книгой «Городские улицы и мостовые» (1912 год). За 100 лет непрерывных исследований выработалось много хороших моделей, которые помогают сегодня строить качественные и быстрые дороги. Но если Вы думаете, что не осталось нерешённых вопросов, Вы сильно ошибаетесь, ведь до сих пор светлые умы нашей планеты ломают головы над решениями задач, о которых иногда спрашивают даже дети. Например, как настроить светофор так, чтобы около него не образовывалась пробка?

Читать полностью »

Виталий vithar Харисов — один из ключевых разработчиков и руководителей Яндекса. На московском Я.Субботнике по фронтенду Виталий рассказал про лёгкую версию поиска для медленных соединений и способы оптимизации кода, позволяющие уложиться в 10 килобайт.

Читать полностью »

Добрый день!

Давно мечтал внести свою лепту в этот замечательный проект, который читаю уже несколько лет.

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

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

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

В основу данного материала легло выступление Николая Лихогруда, руководителя разработки мобильных Яндекс.Карт для iOS, на конференции Mobius 2017.

likhogrud уже написал пост на эту тему в блоге Яндекса, но мы не могли не выпустить один из лучших докладов конференции. Здесь есть и видео, и текст под катом, смотрите, как вам удобнее.
Читать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

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

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2 - 1

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

А посему давайте взглянем на качество требований глазами команды исполнителей: разработчиков, специалистов управления качеством, менеджеров проекта. Ведь именно эти люди и являются основными потребителями работы аналитика. И от того насколько точно созданные спецификации подходят конкретной команде для переработки их в готовый программный продукт, зависит качество и конечная себестоимость этого продукта.
Читать полностью »

Метод оптимизации Trust-Region DOGLEG. Пример реализации на Python - 1

Trust-region метод (TRM) является одним из самых важных численных методов оптимизации в решении проблем нелинейного программирования (nonlinear programming problems). Метод базируется на определении региона вокруг лучшего решения, в котором квадратичная модель аппроксимирует целевую функцию.

Методы линейного поиска (line search) и методы trust-region генерируют шаги с помощью аппроксимации целевой функции квадратичной моделью, но использую они эту модель по-разному. Линейный поиск использует её для получения направления поиска и дальнейшего нахождения оптимального шага вдоль направления. Trust-region метод определяет область (регион) вокруг текущей итерации, в котором модель достаточно аппроксимирует целевую функцию. В целях повышения эффективности направление и длина шага выбираются одновременно.

Trust-region методы надежны и устойчивы, могут быть применены к плохо обусловленным задачам и имеют очень хорошие свойства сходимости. Хорошая сходимость обусловлена тем, что размер области TR (обычно определяется модулем радиус-вектора) на каждой итерации зависит от улучшений сделанных на предыдущих итерациях.
Читать полностью »

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

Даже пустой проект в Unity весит очень много. Пустой проект под Android с настройками по умолчанию в Unity 2017.1 весит 21637 КБ. Однако его можно очень легко уменьшить до 1195212412 КБ, указав платформу для компиляции (ARMv7 и x86 соответственно).

По аналогии с этим, можно еще попробовать еще немного уменьшить вес, выбрав Graphic API. Если выбрать OpenGLES2 вместо Auto Graphics API, можно сэкономить еще 236 КБ (11716 вместо 11952). Выгода незначительна и возможна потеря в производительности, так что этого делать я не рекомендую.

Теперь поговорим о содержимом проекта. Рассмотрим 2D игру с большим количеством спрайтов.
Есть вероятность, что многие спрайты будут симметричными по одной или нескольким осям.
Читать полностью »