Нормальное распределение (распределение Гаусса) всегда играло центральную роль в теории вероятностей, так как возникает очень часто как результат воздействия множества факторов, вклад любого одного из которых ничтожен. Центральная предельная теорема (ЦПТ), находит применение фактически во всех прикладных науках, делая аппарат статистики универсальным. Однако, весьма часты случаи, когда ее применение невозможно, а исследователи пытаются всячески организовать подгонку результатов под гауссиану. Вот про альтернативный подход в случае влияния на распределение множества факторов я сейчас и расскажу.

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

Всем добрый день!

В рамках моего проекта:
Создаем робота в домашних условиях
был сделан модуль управления роботом по ИК каналу. Вот о нём я бы и хотел написать поподробнее. Так как применений этому можно найти очень много.

Собственно, что такое ИК-управление — объяснять, думаю, не нужно. Сейчас более распространено управление по Wi-Fi, Bluetooth, ZigBee. Но если вам требуется простое устройство, которое можно собрать «на коленке» при минимальных затратах, то эта статья для вас. =)

Около года назад я опубликовал свою статью Как спастись от «зайцев». Инструкция по борьбе с ультрафиолетом в которой достаточно подробно рассказал про ультрафиолет, его воздействие на ткани человека и способы лучевой защиты. Однажды на досуге я задумался над тем, в какой форме чаще всего приходится сталкиваться с «рукотворным» (т.е. не из спектра Солнца) ультрафиолетом. Вышло, что наиболее популярный УФ — это мягкий УФ и флуоресценция, которую он способен вызывать. Наиболее популярный вариант у моих дружков — это просвечивать друг друга и потом спрашивать у меня, что значит тот или иной цвет пятна на коже, и не грибок ли это. Чтобы раз и навсегда этот вопрос закрыть представляю очередной туториал. На этот раз, по диагностике кожных заболеваний ультрафиолетом лампы Вуда. Так что если интересно, как с помощью «дискотечного ультрафиолета» можно определить наличие чесотки/грибка на ногах/лишая (в том числе у любимого котика), а также про то, как лампа с aliexpress за 5$ может помочь диагностировать рак кожи и бороться с борщевиком — читаем под катом. Только наукоёмкое самоделие, с пожеланием крепкого здоровья в Наступающем 2020 году!
Закинь в закладки, %username% :)

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.

В этой статье мы рассмотрим критерии хорошего кода и плохого кода, как и чем измерять. Увидим обзор типовых задач и подходов, разберем плюсы и минусы. В конце будут рекомендации и best practices по проектированию web-приложений.

Эта статья является расшифровкой моего доклада с конференции DotNext 2018 Moscow. Кроме текста, под катом есть видеозапись и ссылка на слайды.

Эта статья родилась из поста на внутреннем форуме нашей конторы, немножко пообсуждалась, слегка дополнилась, а потом я решил выложить её в итоговом виде тут, чтобы ссылаться было удобнее.
Да, пост капитанский, это ожидаемое поведение :) я просто хочу это иметь собранным, упорядоченным и общедоступным.

Введение: найди кота

В продуктах, которые мы разрабатываем, есть баги.
Мы их иногда находим. Иногда даже записываем.
Для того, чтобы помочь нашим коллегам, сделать их продукт лучше.
И очень обижаемся, когда коллеги нам пишут – "я нихрена не понял", "у меня не воспроизводится", "приди покажи".
Иногда так говорю я.
Потому что достаточно часто баги выглядят как картинка "найди кота".

Тот, кто записал баг, точно знает, где кот. Он его уже нашёл. Он уже не может его развидеть.
А я должен сидеть, пыриться в монитор и искать грёбаного кота.

Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

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

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

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

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

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

Собеседование — это экзамен

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

Начинается с простых вопросов на раскачку, примерно таких:

Порой диву даёшься, чего только люди не сделают «на блокчейне». С середины 2017 я занимаюсь аудитами безопасности смарт-контрактов и повидал всякого. В отдельную категорию я бы выделил «применения блокчейна», которые выглядят логичными и полезными, но в основе содержат проблему. И кочуют из стартапа в стартап вместе с ней. Здесь я рассмотрю ряд таких примеров, опишу проблемы и неработающие способы решения. После прочтения этого текста вы будете знать, с каких вопросов стоит начать, если вам как разработчику/клиенту/инвестору предложат такое «применение блокчейна».

Дисклеймеры

• Я описываю юзкейсы и проблемы, которые возникают на первом шаге. Я не утверждаю, что эти проблемы нельзя решить. Но при рассмотрении подобной системы стоит понимать, как создатели предлагают решать соответствующую проблему.
• Словосочетание «применение блокчейна» режет глаз. Тем не менее, здесь и далее я буду писать его без кавычек, хотя до сих пор до конца не уверен, что возможны другие применения блокчейна помимо денег, то есть кроме Bitcoin.

1. Supply Chain Management

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.

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

Итак, что на обещают производители?

• Заряд аккумуляторов Li-ion, Li-pol, LiFe, NiCd, NiMH, PbAcid(свинцовые всех типов)
• Полностью автоматический процесс заряда, управляемый микроконтроллером. Отсечка по току и напряжению для литиевых аккумуляторов, по температуре и ΔV для никелевых. Для всех типов — выключение по максимальному времени и емкости.
• Тренировка NiCd и NiMH. Балансировочный заряд Li-pol аккумуляторов(для батарей с несколькими банками)
• Ток заряда до 5А, разряда — до 1А.
• Экран с показаниями текущего напряжения, тока, емкости. Выгрузка всех этих параметров на компьютер и построение графиков.

У многих неюристов при виде очередного договора страниц на 20-30 появляется некий взгляд беспомощности. Немудрено, люди много лет учатся во всём этом разбираться, а потом ещё и практикой оттачивают. Поэтому нередко договоры подписывают не читая, просто посмотрев условия оплаты. Авось пронесёт.

Но эта проблема рукотворная. Приведу аналогию. Если вам нужно быстро сделать корпоративный сайтик, то берёте Wordpress и скачиваете любую из тем. На кой вам нужен Битрикс или уж тем более собственный движок? Или, к примеру, ту же тему надо подправить, хотелок у вас появилось. Но, не хватает знаний. Эту работу сделает большинство фрилансеров из самого низкого ценового диапазона. Зачем вам спец по 50 долларов в час?

Мораль сих аналогий: большой договор — это специфический инструмент для специфических задач. В 95 % случаях он не нужен вообще никому. Чтобы понимать как работать с договором без юриста, нужно понимать почему так происходит, что почти всегда договор — это большой и ненужный документ.

Почему договоры большие

Суть разработки программного обеспечения
— Нужно проделать 500 отверстий в стене, так что я сконструировал автоматическую дрель. В ней используются элегантные точные шестерни для непрерывной регулировки скорости и крутящего момента по мере необходимости.
— Отлично, у неё идеальный вес. Загрузим 500 таких дрелей в пушку, которые мы сделали, и выстрелим в стену.

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

Это громкая и страшная аббревиатура из трёх неприличных букв. Хотите поучаствовать в тендере, устраиваетесь на работу, нужно получить данные — вам подсовывают эту бумажку, мол, подпиши сначала, а то нашли дураков без NDA тебе что-нибудь рассказывать. При этом в большинстве случаев вы ничего сверхсекретного или коммерчески важного не узнаете, но процедура подписания NDA стала неким таинством посвящения, которое стороны выполняют не особо задумываясь над смыслом.

Это так же как вы неизбежно получите требование вместе с учредительными документами предоставить выписку из ЕГРЮЛ не старше 30 дней. Хотя всё доступно в онлайне, все распечатывают эту выписку из интернета, заверяют её и передают контрагенту, который даже не смотрит её, потому что всё есть в интернете. Ну, вы поняли, короче, отечественную любовь к таинствам.

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Введение

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

Я буду предполагать, что вы знакомы с видеоиграми, немного разбираетесь в таких математических концепциях, как геометрия, тригонометрия и т.д. Большинство примеров кода будет записано псевдокодом, поэтому вам не потребуется знание какого-то конкретного языка.

Что же такое «игровой ИИ»?

Игровой ИИ в основном занимается выбором действий сущности в зависимости от текущих условий. В традиционной литературе по ИИ называет это управлением "интеллектуальными агентами". Агентом обычно является персонаж игры, но это может быть и машина, робот или даже нечто более абстрактное — целая группа сущностей, страна или цивилизация. В любом случае это объект, следящий за своим окружением, принимающий на основании него решения и действующий в соответствии с этими решениями. Иногда это называют циклом «восприятие-мышление-действие» (Sense/Think/Act):

• Восприятие: агент распознаёт — или ему сообщают — информацию об окружении, которая может влиять на его поведение (например, находящиеся поблизости опасности, собираемые предметы, важные точки и так далее)
• Мышление: агент принимает решение о том, как поступить в ответ (например, решает, достаточно ли безопасно собрать предметы, стоит ли ему сражаться или лучше сначала спрятаться)
• Действие: агент выполняет действия для реализации своих решений (например, начинает двигаться по маршруту к врагу или к предмету, и так далее)
• … затем из-за действий персонажей ситуация изменяется, поэтому цикл должен повториться с новыми данными.

Несколько лет назад меня пригласили консультантом по одному проекту ПО для крупной французской технологической компании. Увиденное выходит за рамки всего, что я мог представить в разработке. Простое отсутствие профессиональной компетентности оказалось не самым худшим. Гораздо хуже было крайнее презрение к человеческому достоинству, что показалось мне сравнимо с тюрьмой в том виде, как я её представляю. Вот список, проверьте сами.

Масштаб

• Разработка программного обеспечения для государственного агентства.
• Сложность низкая, с несколькими вывертами.

Правительство платит авансом несколько миллионов евро. План разработки на два-три года. Для начала компания нанимает несколько разработчиков и продолжает удваивать размер команды каждые три месяца или около того, осваивая бюджет по мере поступления средств.

7 лет спустя проект ещё не оформился. Набегают штрафы по несколько тысяч евро в сутки. Руководство решает сократить расходы и производит увольнения опытных сотрудников, нанимая людей с небольшим или нулевым опытом работы.

10 лет спустя, учитывая катастрофическое состояние проекта, менеджмент среднего звена решает нанять некоторых людей с опытом разработки, чтобы вернуться в график. Средняя текучка среди новичков: три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.