Данная статья является шестой частью серии статей, предназначенных, по словам автора, для тех, кто не может разобраться с внедрением зависимостей и фреймворком Dagger 2, либо только собирается это сделать. Оригинал написан 23 декабря 2017 года. Перевод вольный.


Читать дальше ->

https://habrahabr.ru/post/345372/

Недавно мы выпустили новое приложение КОМПАС-Эксперт для поиска ошибок в чертежах и моделях, разработанных в КОМПАС-3D. Идеей для него послужил анализатор кода PVS-Studio. Что общего в продуктах для программистов и инженеров и как классифицируются ошибки проектирования, рассказывает Олег Волков.

В свое время меня вдохновил Viva64 для проверки кода C++ (сейчас этот прекрасный продукт называется PVS-Studio). Он выполняет анализ кода на различные правила: логические/нелогические, конструктор/деструктор, сравнение переменных и другие. Возникла мысль применить похожую идеологию в КОМПАС-3D: на выходе проверять результат — чертеж или 3D-модель — некими правилами. Тем более, что в других САПР подобные проверки реализованы.
Читать дальше ->

https://habrahabr.ru/post/345152/

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.
Читать дальше ->

https://habrahabr.ru/post/345242/

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.
Читать дальше ->

https://habrahabr.ru/post/345242/

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

Экономисты называют это ошибкой невозвратных затрат или ошибкой «Конкорда» (в память о разработке сверхзвукового пассажирского самолёта «Конкорд»). Это иррациональное усиление, при котором человеку кажется, что он вложил очень много денег/времени/энергии в работу и её прекращение окажется пустой тратой ресурсов. Однако в реальности решение продолжать не должно быть никак связано с предыдущими тратами; самое важное — это понять, оправдают ли себя дополнительные усилия.
Читать дальше ->

https://habrahabr.ru/post/345242/

Проблематика вопроса сформулирована в предыдущей статье.

А именно: как оценить влияние определенного допущения модели Блэка-Шоулза на расчетную величину премии по европейскому опциону? Допущения о том, что цена торгуемого актива имеет логнормальное распределение. Как альтернативу расчета по формуле Блэка-Шоулза я использовал подход — прогнозирование выплат покупателю опциона методом Монте-Карло. На вход программе я подавал:

• “эталонные данные” (моделирование логнормального распределения”),
• случайный ряд, характеризующийся распределением с “толстыми хвостами”,
• и, наконец, цены нескольких биржевых активов — валютных пар и криптовалют.

В каждом случае я рассчитал премию опциона по формуле Б-Ш и методом Монте-Карло. Сравнил результаты и сделал(?) выводы:


Читать дальше ->

https://habrahabr.ru/post/345362/

Проблематика вопроса сформулирована в предыдущей статье.

А именно: как оценить влияние определенного допущения модели Блэка-Шоулза на расчетную величину премии по европейскому опциону? Допущения о том, что цена торгуемого актива имеет логнормальное распределение. Как альтернативу расчета по формуле Блэка-Шоулза я использовал подход — прогнозирование выплат покупателю опциона методом Монте-Карло. На вход программе я подавал:

• “эталонные данные” (моделирование логнормального распределения”),
• случайный ряд, характеризующийся распределением с “толстыми хвостами”,
• и, наконец, цены нескольких биржевых активов — валютных пар и криптовалют.

В каждом случае я рассчитал премию опциона по формуле Б-Ш и методом Монте-Карло. Сравнил результаты и сделал(?) выводы:


Читать дальше ->

https://habrahabr.ru/post/345362/

Приветствую!
Не так давно я увлекся исследованием игр под android. Как оказалось, весьма немалое количество разработчиков используют Unity3D(наверное, процентов 50-60 игр, которые мне были интересны, базируются на этом движке). Сразу оговорюсь — я не специалист по взлому и даже практически не знаю C++/asm(не смотря на небольшое знакомство с этой темой), так что просьба не швыряться унитазами при помощи гравипушек. Также небольшое уточнение — я исследовал практически только ММО/полу-онлайновые игры в стиле «крабишь сюжетный данж до посинения, а потом сражаешься на арене с другими игроками, причем полу-оффлайн). Оффлайновые игры на Unity3D исследовать просто-напросто скучно.
Собственно, насколько мне известно игрушки под Unity3D используют 2 технологии: Mono и Il2cpp.
В пределах данного материала я хочу рассмотреть процесс подмены .NET dll'ок и дампа даже шифрованных версий этих самых dll'ок напрямую из игры.

Читать дальше ->

https://habrahabr.ru/post/345356/

Приветствую!
Не так давно я увлекся исследованием игр под android. Как оказалось, весьма немалое количество разработчиков используют Unity3D(наверное, процентов 50-60 игр, которые мне были интересны, базируются на этом движке). Сразу оговорюсь — я не специалист по взлому и даже практически не знаю C++/asm(не смотря на небольшое знакомство с этой темой), так что просьба не швыряться унитазами при помощи гравипушек. Также небольшое уточнение — я исследовал практически только ММО/полу-онлайновые игры в стиле «крабишь сюжетный данж до посинения, а потом сражаешься на арене с другими игроками, причем полу-оффлайн). Оффлайновые игры на Unity3D исследовать просто-напросто скучно.
Собственно, насколько мне известно игрушки под Unity3D используют 2 технологии: Mono и Il2cpp.
В пределах данного материала я хочу рассмотреть процесс подмены .NET dll'ок и дампа даже шифрованных версий этих самых dll'ок напрямую из игры.

Читать дальше ->

https://habrahabr.ru/post/345356/

Прошло полтора года как Microsoft закрыл случайно оказавшийся в корзине с Xamarin-ом RoboVM. Уже и официальный robovm.com канул в лету. Последняя opensource версия 1.8 была форкнута группой MobiVM и поддерживается на искусственном дыхании в рабочем состоянии и сейчас.

Сам RoboVM (тут и далее MobiVM форк я буду называть так) тесно переплетен с MacOSX и в оригинальном виде, будучи запущенным в Windows/Linux встречает сообщением, что код писать можно, компилировать нельзя. Встречая в cmake файлах/сети упоминании о Windows, принял вызов и решил довести дело к какому-либо результату.

Понадобится:

Читать дальше →

https://habrahabr.ru/post/345348/

Написать эту статью меня побудила заметка уважаемого jobgemws "Отправка запроса на все базы данных всех указанных серверов на примере MS SQL Server и C#.NET"

Я расскажу, как схожую задачу можно решить штатными инструментами MSSQLSERVER, а именно – SSMS (или, для экстремалов от администрирования — sqlcmd), быстро, без программирования, с помощью крошечного лайфхака.

Итак, у нас в организации имеется несколько десятков разнотипных MSSQLSERVER, разных редакций. Express превалирует, но это – не важно. Инфраструктура – старая, целиком унаследованная, и — «кусочно-непрерывная».

Задача: «запустить один и тот же запрос/пакет на нескольких серверах в нескольких базах данных», у нас, что называется, «редко бывает, но часто случается».

И то, что это «редко бывает» — не позволяет изобрести достойного обоснования для закупки или написания полноценного софта для централизованного администрирования всего зоопарка, а то, что «часто случается» — бывает, требует мгновенного решения в стиле «5 секунд до взрыва».

Но всё это – лирическое отступление, дисклаймер и всё такое.
Читать дальше ->

https://habrahabr.ru/post/345344/

Redux — это интересный шаблон, и, по своей сути, он очень прост. Но почему его сложно понять? В этом материале мы рассмотрим базовые концепции Redux и разберёмся с внутренними механизмами хранилищ. Поняв эти механизмы, вы сможете освоиться со всем тем, что происходит, что называется, «под капотом» Redux, а именно — с тем, как работают хранилища, редьюсеры и действия. Это поможет вам вывести на новый уровень отладку приложений, поможет писать более качественный код. Вы будете точно знать, какие именно функции выполняет та или иная строка вашей программы. Мы будем идти к пониманию Redux через практический пример, который заключается в создании собственного хранилища с использованием TypeScript.



Этот материал основан на исходном коде хранилища Redux, написанном на чистом TypeScript. Автор предлагает всем желающим взглянуть на этот код и разобраться с ним. Однако, он указывает на то, что этот проект предназначен для учебных целей.
Читать дальше ->

https://habrahabr.ru/post/345340/

Redux — это интересный шаблон, и, по своей сути, он очень прост. Но почему его сложно понять? В этом материале мы рассмотрим базовые концепции Redux и разберёмся с внутренними механизмами хранилищ. Поняв эти механизмы, вы сможете освоиться со всем тем, что происходит, что называется, «под капотом» Redux, а именно — с тем, как работают хранилища, редьюсеры и действия. Это поможет вам вывести на новый уровень отладку приложений, поможет писать более качественный код. Вы будете точно знать, какие именно функции выполняет та или иная строка вашей программы. Мы будем идти к пониманию Redux через практический пример, который заключается в создании собственного хранилища с использованием TypeScript.



Этот материал основан на исходном коде хранилища Redux, написанном на чистом TypeScript. Автор предлагает всем желающим взглянуть на этот код и разобраться с ним. Однако, он указывает на то, что этот проект предназначен для учебных целей.
Читать дальше ->

https://habrahabr.ru/post/345340/

Пока мы после конференции Heisenbug собирали и анализировали зрительский фидбэк, на Хабре появился подробный пост IvanPonomarev с его впечатлениями зрителя. И чтобы не повторять его, а дополнить, мы решили построить свой текст о конференции иначе.

Не описывать последовательно все два дня с вечеринкой, а посмотреть по зрительским оценкам, какие из не упомянутых Иваном докладов сильнее всего понравились аудитории (у всех таких оценки оказались выше 4.2), и рассказать немного о них. В итоге получился список «шесть вещей, которые привлекли зрителей Heisenbug» — по нему можно оценить и конкретные темы, и их разброс.

Читать дальше ->

https://habrahabr.ru/post/345294/

Привет! Меня зовут Анна, я руководитель образовательных проектов в Avito. Нам кажется очень важным способствовать тому, чтобы начинающие (и не только) разработчики узнавали о самых крутых технологиях на рынке. Поэтому мы делаем целый пул образовательных онлайн-проектов в партнёрстве с лучшими площадками. Подробно о них рассказываю под катом, там же раскрываю наши планы на будущее.

Читать дальше ->

https://habrahabr.ru/post/345314/

Недавно мы рассказали пару поучительных историй о том, как всё может пойти наперекосяк, сколько ни стели соломы. Нам вспомнился ещё один случай, одновременно и забавный, и крайне драматический, особенно для непосредственных участников. Хотя по прошествии времени они уже вспоминают те кошмарные часы со смехом.
Читать дальше ->

https://habrahabr.ru/post/345322/

Визуальное и текстовое программирование

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

Исторически сложилось, что алгоритмы в программах записываются в виде исходных текстов. Почти никто не ставит под сомнение, что текст — это и есть лучшее средство представления алгоритмов. Алгоритм кодируется внутри функций на языке программирования, например, C или JavaScript. Для тех, кто хочет разобраться в алгоритме с высоты птичьего полёта, предусмотрен псевдокод. Однако с текстом есть серьезные проблемы. Дело в том, что человек не оптимизирован под сплошной текст. Человек оптимизирован на восприятие графики. Текст — это относительно новое изобретение, а вот графическую информацию организмы обрабатывают уже миллионы лет.

Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом — текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.

Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.

Как программировать на языке ДРАКОН

ДРАКОН не является самостоятельным языком программирования. Он работает в паре с

Читать дальше →

https://habrahabr.ru/post/345320/

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

Читать дальше ->

https://habrahabr.ru/post/345270/

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

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

Оглавление серии «Производительность как восприятие»:

• Производительность как восприятие: восприятие времени;
• Производительность как восприятие: управление восприятием;
• Производительность как восприятие: управление терпением. (эта статья)

Читать дальше ->

https://habrahabr.ru/post/343974/

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


Читать дальше ->

https://habrahabr.ru/post/345312/