Давайте на время отвлечемся от очередного "языка-убийцы C++", ошеломляющих синтетических тестов производительности какой-нибудь NoSQL-ой СУБД, хайпа вокруг нового JS-фреймворка, и окунемся в мир "программирования ради программирования".

«Банда четырёх» была неправа, стандартная библиотека Ruby тоже ошибочна, и Rails – также. Но является ли нечто неправильным, если все так делают?

Да.

Книга «Банды четырёх» "Шаблоны проектирования" даёт нам общий словарь для понимания базовых шаблонов ООП. Она помогает нам использовать одинаковую терминологию при обсуждении софта. К сожалению, она же является причиной путаницы.

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

Делегирование – это приём, которому приписывают возможность внесения гибкости в программы. Обычно говорят, что делегирование – это способ достичь композиции. Но делегирование – это не то, что вы думаете, и «Банда четырёх» ввела вас в заблуждение. Хуже того, почти все упоминания о делегировании содержат лишь совместную работу объектов с пересылкой (forwarding) сообщений. Это примеры вызовов методов, а не делегирования.

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

Последние два года вся страна пристально следит за курсом доллара. Новостные выпуски пестрят громкими репортажами о долларе. Все говорят о долларе. А что, если мы на фоне горячего интереса, разберемся с тем, как формируется цена доллара, посмотрим кто и как торгует валютой?! Все результаты, представленные в данной статье, получены на основе официальных торговых данных full orders log (полный журнал заявок), купленные на Московской Бирже. Мы покажем реальные торги изнутри. Параллельно, познакомимся со стандартными методами анализа рынка. Такая аналитика стоит не малых денег и её могут позволить ограниченное число «компаний».

Инструментом для анализа данных будет Java. Анализируемый биржевой инструмент — USDRUB_TOM. Наша задача вытащить любопытные детали из имеющихся данных и попробовать сделать определенные выводы.

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Введение

Я математик-программист. Самый большой скачок в своей карьере я совершил, когда научился говорить:«Я ничего не понимаю!» Сейчас мне не стыдно сказать светилу науки, что мне читает лекцию, что я не понимаю, о чём оно, светило, мне говорит. И это очень сложно. Да, признаться в своём неведении сложно и стыдно. Кому понравится признаваться в том, что он не знает азов чего-то-там. В силу своей профессии я должен присутствовать на большом количестве презентаций и лекций, где, признаюсь, в подавляющем большинстве случаев мне хочется спать, потому что я ничего не понимаю. А не понимаю я потому, что огромная проблема текущей ситуации в науке кроется в математике. Она предполагает, что все слушатели знакомы с абсолютно всеми областями математики (что абсурдно). Признаться в том, что вы не знаете, что такое производная (о том, что это — чуть позже) — стыдно.

Но я научился говорить, что я не знаю, что такое умножение. Да, я не знаю, что такое подалгебра над алгеброй Ли. Да, я не знаю, зачем нужны в жизни квадратные уравнения. К слову, если вы уверены, что вы знаете, то нам есть над чем поговорить! Математика — это серия фокусов. Математики стараются запутать и запугать публику; там, где нет замешательства, нет репутации, нет авторитета. Да, это престижно говорить как можно более абстрактным языком, что есть по себе полная чушь.

В прошлом году я описывал свой путь в преобразовании дарового солнечного света в электрическую энергию. Перепробовав немало оборудования для автономной энергетики, я остановился на продукции российской компании «МикроАРТ». А в этом году отечественные разработчики порадовали выходом совершенно нового устройства, которое является сердцем любой автономной энергосистемы — инвертора МАП DOMINATOR. Заявлена масса новых функций: наращивание мощности путем добавления инверторов, организация трехфазной сети, встроенный микрокомпьютер. В конце концов, было обещано, что система позволяет генерировать более полумегаватта энергии, а это уже заявка!
Пользуясь акцией на сайте, которая повествует о возможности апгрейда инвертора с небольшой доплатой, я решил этой возможностью воспользоваться и сам оценить заявленные характеристики.

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

Про моментальный клей с содой разве что ещё анекдотов не насочиняли, но все молчат про одну интересную особенность. Итак, смесь цианоакрилата с содой моментально полимеризуется (твердеет), выделяя тепло и отлично схватываясь молекулярными связями с близлежащими слоями. Но не с любыми. С ABS-пластиком — хорошо, а с полипропиленом — плохо. Ну и что с того? При послойной заливке (точнее, «закапке») соблюдать точную форму детали непросто. Много излишков в конце приходится удалять механически (напильником). А как насчёт «опалубки» из таких же подручных материалов? Кустарная 3D-печать из кармана.

Одна и та же история повторяется снова и снова. Сначала команду людей озаряет идея.

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

Но что же здесь не так? Почему для многих стартапов это оборачивается проблемами?

^{Cчетчик со страницы Getting Started на момент публикации статьи}

С минуты на минуту случится то, чего ждали очень многие, и я в том числе. А именно: компания ObjectArts полностью открывает исходники и выпускает язык и среду разработки Dolphin Smalltalk под открытой лицензией MIT!

О проекте

DolphinSmalltalk — это среда разработки на собственном диалекте Smalltalk для Windows. Ключевыми особенностями является тесная интеграция с нативными виджетами и подсистемами операционной системы, включая COM и ActiveX, и приятный глазу дизайн.

Долгое время Dolphin Smalltalk был доступен в двух вариантах: условно-бесплатная ограниченная версия (community edition) и платный пакет для профессиональной разработки. Последний давал доступ ко всем функциям, включая продвинутые редакторы и публикацию приложений в standalone режиме, однако стоил около четырехсот долларов, что, по понятной причине, устраивало далеко не всех.

Похоже, что компания таки одумалась (или терять стало нечего) и решила выпустить ПО на волю. Под катом краткое описание среды разработки и размышления на тему open source будущего Dolphin Smalltalk.

В прошлый раз мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.

Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.

Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS на практике.

Итак, linkmeup — уже больше не аутсорсинг по поддержке хоть и крупной, но единственной компании, мы — провайдер. Можно даже сказать федеральный провайдер, потому что наша оптика ведёт во все концы страны. И наши многочисленные клиенты хотят уже не только высокоскоростной доступ в Интернет, они хотят VPN.
Сегодня разберёмся, что придётся сделать на нашей сети (на которой уже меж тем настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.

^{В ситуации полной и беспросветной задницы власть в AI сразу забирали военные, и это иногда спасало партию.}

Для нашего AI Шакала пришлось написать целых 4 разных AI, каждый из которых отвечал за свою задачу. А затем они собирались вместе и голосовали за то, что же делать пиратам на поле в этом ходу.

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

Давным-давно мой преподаватель профессор Сербин рассказывал байку с сыроваром из Европы. К этому обаятельному толстяку приезжали автоматизаторы и спрашивали, как он делает такой вкусный сыр. Им нужны были эвристики для температуры, густоты и так далее. Сыровар опускал палец в мягкий сыр, медленно и кайфно чертил там дугу, улыбался во всё хитрое лицо и говорил: «Ну как вы не чувствуете!».

Алгоритмизировать процесс гости так и не смогли. Так вот, разработка шла так: мы чертили дуги и хитро улыбались, а парни проигрывали нам в настольный Шакал. И мечтали, что за них отомстит AI.

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

Как бывший менеджер продукта Google Calendar я видел много человеческих реакций на встречи. Как партнёр в Google Ventures, я напрямую работал с более чем сотней стартапов. Я даже сделал курсы на тему того, как освободиться от тирании переговоров. И вот что я рекомендую:

Уберите статусные встречи

Самые вредные для работы – еженедельные статусные встречи, или встречи для учёта прогресса. Типа «давайте каждый расскажет, чего он достиг». Это трата времени, тянущаяся с тех дней, когда менеджеры таким образом удостоверялись в том, что люди делают свою работу.

Большинство обновлений относятся к 1-2 людям в комнате, а все остальные тупо ждут своей очереди. Замените их системами обмена сообщениями, встречами с меньшим количеством участников или списками рассылки.

Относитесь с уважением к встречам один на один

Занятно, как менеджеры тратят время на общие встречи, и всё время отменяют персональные встречи с их непосредственными подчинёнными. А это самые важные встречи в вашем расписании – только они нужны не для вас, они для работников.

Случалось ли вам, что нужно быстро нарисовать график функции, а под рукой нет любимой десктопной программы? Меня не раз спасал бесплатный онлайн графический калькулятор от компании Desmos. Мультиязычный интерфейс, в т.ч. с поддержкой русского языка.

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

Я проверил. В течение получаса после моего твита я получил документ по почте. Моё сообщение ретвитнул аккаунт Shecanhazpdf, в описании к которому сказано: «С 2014 года не делает ничего, кроме ретвитов #icanhazpdf целый день».

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

Will you help? #icanhazpdf https://t.co/X1R1trWtGQ sychev.i.p@gmail.com

— Иван Сычев (@ivan_sychev) 24 октября 2015

Андреа Кужевски — учёная, придумавшая распространять работы с помощью Twitter. Фото из Google+

Последнее время в материалах различных конференций по сетевым технологиям, обзорах, статьях стали всё чаще встречаться такие термины, как TRILL, FabricPath, VXLAN, OTV и LISP, особенно в разрезе построения ЦОДов. Ловишь себя на мысли, а что же это такое? Конечно, многие из них, как звёзды, достаточно далеки от нашей повседневной реальности. Но все-таки, наверное, было бы не плохо понять, хотя бы в общих чертах, а что же это всё значит. Более того, вроде как, все они меняют привычные принципы работы сети: коммутация по каким-то меткам, маршрутизация какая-то не такая, да и адресация хоста совсем уже не та. В общем, предлагаю попробовать со всем этим разобраться.

Статья будет разбита на три части. В первой части рассмотрим, что такое оверлейные технологии. Разберёмся с предпосылками появления новых оверлейных технологий для ЦОД, а также их общей классификацией. Остальные части будут посвящены уже непосредственно технологиям TRILL, FabricPath, VXLAN, OTV и LISP.

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

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

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

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



В посте много изображений.

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

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)