/ фото reynermedia CC

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

В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.

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

Рик Рид в его предстоящем мартовском докладе, озаглавленном "Миллиард с большой 'М': Следующий уровень масштабирования в WhatsApp" раскрывает сногсшибательную статистику WhatsApp:

Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).

Хочу внести небольшую лепту в дискуссию о том, что такое SaaS и какими положениями ГК оно регулируется. Ну или продолжить этот спор. На мой взгляд SaaS это лицензия. Аргументы у меня такие.

Есть мнение, что отличает SaaS от лицензии один факт: устанавливается ли программа на жесткий диск или же доступ к ней удаленный. В случае с удаленным доступом есть аргументы, что он не относится к “использованию” Программы. Возможные варианты использования объектов авторских прав, к которым относятся и программы, перечислены в части 2 статьи 1270 ГК. А лицензионное соглашение – это договор именно о праве использования программы (статья 1235 ГК). То есть получается, что если нет “использования” программы, то договор, на основании которого ею пользуются, не является лицензионным соглашением. А отсюда налоговые последствия ввиде необходимости платить НДС, потому что от НДС освобождаются выплаты по лицензионному соглашению (пп.26 п. 2 ст. 149 Налогового кодекса).

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Этот год оказался неплохим для компании Blizzard Entertainment. Многое сделано, сейчас у компании — большое количество планов по развитию своих продуктов. Некоторые действия Blizzard Entertainment выглядели не слишком хорошо. Речь идет о закрытии фан-сервера Nostalrius Begins, компания добилась его отключения не смотря ни на что. Конечно, многим поклонникам игр от Blizzard это не понравилось. Команда Nostalrius собиралась выложить исходный код и базу игроков в сеть, чтобы дать возможность поклонникам WoW продолжить работу над проектом. Но потом это решение было отменено.

Но теперь появилась еще одна игра — StarCraft Universe. Создавали ее поклонники StarCraft II, и сейчас StarCraft Universe доступна в бета-версии. По словам разработчиков это «экшн от третьего лица с RPG элементами World of Warcraft, механизмом боев Diablo и физикой звездолетов от FTL с рядом элементов из StarCraft». Самое интересное то, что Blizzard не имеет ничего против этой игры. По крайней мере, пока.

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

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

Сегодня я перечислил несколько лучших инструментов, существующих в индустрии.

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

Помните книгу «Вредные советы» Григория Остера, где в стихотворной форме давались забавные советы по выходу из разнообразных ситуаций для детей? Тормозить на велосипеде в папу или вытирать после обеда руки об скатерть и штаны соседа. Причём книга рассчитана исключительно на непослушных читателей. И тут – ловушка! Они привыкли делать наоборот.

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

На счету «Евростудио» уже более 2000 проектов, и наши менеджеры успели пообщаться с самыми разными заказчиками. Ориентируясь на свой опыт, опыт коллег по «цеху» и их комментарии, мы составили «Вредные советы» для «сложных» заказчиков веб-студий и digital-агентств. Если это не вы, то ни в коем случае не читайте дальше (хотя нет, читайте).

Вы хотите продвигаться
В Яндекс, в Google, чтоб в ТОП-10?
Всё заказывайте сразу
Не давайте разъяснений
И все письма без ответов
Смело можете оставить
А потом просите грозно
У веб-студии отчёт

Будьте загадочными

Ставьте задачи без конкретики, обсуждайте в общих словах. Из 20 вопросов в письме менеджера отвечайте только на один. Чтобы что-то конкретизировать, предложите исполнителям самостоятельно подумать и решить. Однако требуйте конкретных цифр по прибыли ещё на этапе обсуждения задачи.

Нам, как дизайнерам уровней, часто приходится снабжать игроков большими объемами информации. Это необходимо по многим причинам. Иногда нам просто хочется блеснуть красивым гейм-артом, а иногда – направить игрока к выполнению цели, проработать историю или сюжет игры, создать или сбавить напряжение. Но прежде чем делать всё это, необходимо понять, как направлять внимание игроков туда, куда нам нужно. Подробнее об этом — в нашем переводе статьи Майка Стаута.

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

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

Очевидно, что если у сайта есть уязвимости, то его можно взломать с помощью веб-атак. Но даже если сайт защищен техническими средствами, работает на надежной CMS, его все равно могут скомпрометировать. Каким образом это происходит и как защищать сайт от различных вариантов взлома не через веб-уязвимости — oб этом рассказал на партнёрской конференции «1С-Битрикс» Григорий Земсков, руководитель компании «Ревизиум».

Единый интерфейс для всех мессенджеров, самый удобный способ скачивать видео с YouTube, пакетный менеджер для Windows в стиле линуксового apt-get, встроенный калькулятор Google

Существует ли универсальный фонтенд, чтобы обмениваться сообщениями в WhatsApp, Messenger, Skype, Slack, Telegram, не устанавливая каждую программу?
Конечно, ведь работать с 20-30 мессенджерами по отдельности не очень комфортно. Гораздо удобнее собрать их в едином интерфейсе. Есть несколько универсальных решений для этого.

Во первых, свободная и бесплатная программа Rambox с открытым исходным кодом (репозиторий на Github) под Windows, Linux и Mac OS.

Я предпочитаю работать в маленьких командах: до 10 человек. Всех участников команды ты знаешь лично, чаще всего не нужно специально «бронировать время», чтобы обсудить что-то и принять решения.

Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:

1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
2. Билд и выкладка длятся более 5 минут
3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
4. Существует четкое разделение труда и область ответственности каждой команды
5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

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

Друзья, будем краткими: в честь нашего шестого дня рождения мы выпустили в open source новейшую версию ONLYOFFICE. С этого дня вы сможете найти на GitHub всё, о чем нас просили: новую версию редакторов с быстрым совместным редактирование как в Google Docs и последнюю версию сервера для совместной работы (Community server).

Подробности релиза, что, где и под какой лицензией читайте далее.

Если вы зачитывались историями про Шерлока Холмса или смотрели многочисленные экранизации, то наверняка помните название метода, который использует герой для раскрытия запутанных дел. На всякий случай напомним: он пользуется индукцией — переходом от частного к общему в противовес дедукции, когда из общих данных делают вывод о частных. Как же использовать метод индукции для изучения поведения пользователей в нашем приложении?.. «Элементарно!»- сказал бы герой сэра Арутра Конан Дойля. «Именно так», – вторит ему ведущий аналитик devtodev Василий Сабиров.

Здравствуйте. Сегодня я расскажу как можно создать единый установочный носитель с множеством разных версий Windows не прибегая к использованию стороннего ПО. Таким образом вы будете полностью понимать какие манипуляции мы выполняем.

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

Кому интересно — прошу под кат.

Перевод поста Майкла Тротта (Michael Trott) "Aspect Ratios in Art: What Is Better Than Being Golden? Being Plastic, Rooted, or Just Rational? Investigating Aspect Ratios of Old vs. Modern Paintings".
Код, приведенный в статье, можно скачать здесь.
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации

---

Содержание

Предисловие: золотое сечение — красивая математическая концепция
Работа Фехнера 1876 года об эстетичности прямоугольников и соотношениях сторон в картинах
Легкий старт: анализ «Artwork» — области базы знаний Wolfram Knowledgebase
Первая часть: особенности вероятностного распределения соотношений сторон
Соотношения сторон для разных веков, жанров и художников
Анализируя пять старых немецких музейных каталогов
Коллекция Кресса: четыре больших PDF файла
У нас представлены коллекции следующих галерей: Метрополитен (Metropolitan), институт искусств Чикаго, Эрмитаж, Национальная Галерея (National Gallery), Рейксмюзеум (Rijks) и Тейт Британия
Исключение в соотношениях сторон: Национальная портретная галерея
Веб-галерея изящных искусств: удобная база данных, готовая к использованию
Примечание II: важность точности в измерениях
WikiArt: еще один крупный веб-ресурс
Коллекция Французского государственного музея
Картины в итальянских церквях: высота есть всё
Смитсоновская коллекция
Большая коллекция картин в Великобритании
Нынешний рынок изящных искусств: рациональней чем когда-либо
Проданные картины: большинство написаны недавно, а у распределения длинный хвост
Восток: все показатели отличаются
Пропорции пакетов, автомобилей, этикеток, логотипов, эмблем, бумаги, банкнот, почтовых марок и фильмов
— Продукты из супермаркета
— Винные этикетки
— Этикетки немецких сортов пива
— Логотипы продуктов питания
— Банкноты
— Размеры автомобилей
— Бумажные листы
— Марки
— Эмблемы команд NCAA (Национальной ассоциации студенческого спорта)
— Эмблемы немецких футбольных клубов
— Форматы фильмов
Заключение: так какое соотношение самое «лучшее»?

---

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

В 1876 году немецкий ученый Густав Теодор Фехнер изучал человеческое восприятие прямоугольных форм, а после заключил, что прямоугольники с золотой пропорцией (то же, что и золотое сечение) наиболее приятны для человеческого глаза. Чтобы проверить свои экспериментальные наблюдения, Фехнер также проанализировал соотношения более десяти тысяч картин.

Здравствуйте! Я занимаюсь разработкой игры на Rust и хочу рассказать об этом.

Моя первая статья будет полезна тем, кто хочет начать делать игру на Rust, но не уверен, какие из пакетов (крейтов) стоит использовать и что вообще происходит в экосистеме Rust для игрового разработчика.

Выступления и посты в блогах о производительности JavaScript часто обращают внимание на важность мономорфного кода, однако обычно не дается внятного никакого объяснения, что такое мономорфизм/полиморфизм и почему это имеет значение. Даже мои собственные выступления зачастую сводятся к дихотомии в стиле Невероятного Халка: «ОДИН ТИП ХОРОШО! ДВА ТИП ПЛОХО!». Неудивительно, что когда люди обращаются ко мне за советом по производительности, чаще всего они просят объяснить, что на самом деле такое мономорфизм, откуда берется полиморфизм и что в нем плохого.

Ситуацию осложняет еще и то, что само слово «полиморфизм» имеет множество значений. В классическом объектно-ориентированном программировании полиморфизм связан с созданием дочерних классов, в которых можно переопределить поведение базового класса. Программисты, работающие с Haskell, вместо этого подумают о параметрическом полиморфизме. Однако полиморфизм, о котором предупреждают в докладах о производительности JavaScript – это полиморфизм вызовов функции.

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

_{Я также попробовал новый способ объяснять вещи – изображая взаимодействие составных частей виртуальной машины в виде коротких комиксов. Кроме того, данная статья не покрывает некоторые детали, которые я посчитал незначительными, излишними или не связанными напрямую.}

Здравствуйте, уважаемые читатели.

Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.

Для лучшего понимания этого поста, прочитайте сначала предыдущий пост про прокрастинацию.

Если бы, когда я учился в школе, вы спросили меня прокрастинатор ли я, я бы конечно ответил “да”. Учеников школы учат “держать темп” с крупными проектами. И я гордо держал темп больше чем кто-либо кого я знаю. Я никогда не пропускал дедлайн, но делал все ночью перед сроком сдачи работы. Я был прокрастинатором.

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

Без всякого сомнения в моей голове была Обезьянка Немедленного Удовольствия, но она была милее всех на свете. С постоянно маячащими дедлайнами, Панический Монстр никогда не спал и Обезьянка знала об этом. Она конечно постоянно отвлекала, но не была за главного.

Мой мозг в школе: