Программирование *

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

Каждый успешный проект софтверной компании начинается с идеи, но перед тем, как она станет реальным продуктом, необходимо пройти большой путь проб и ошибок. Сегодня мы хотим рассказать о некоторых проектах Virtuozzo, которые смогли (или не смогли) стать востребованными на рынке продуктами

Светлана Шаповалова, редактор «Нетологии» адаптировала заметку Quincy Larson, в которой он представил три возможных пути становления веб-разработчика: для фронтенда, бекэнда и DevOps.

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

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

Наш сегодняшний собеседник Дилан Битти (Dylan Beattie) имеет высокую репутацию на StackOverflow, а значит умеет хорошо, интересно и, что немаловажно, правильно отвечать на вопросы. Большой опыт позволяет ему на собственных примерах рассказать что-то из прошлого, а профессия архитектора держит в тонусе и приносит новые знания о трендах и передовых технологиях.

Примеры использования и тестирование потоко-безопасного указателя и contention-free shared-mutex

В этой статье мы покажем: дополнительные оптимизации, примеры использования и тестирование разработанного нами потоко-безопасного указателя с оптимизированным разделяемым мьютексом contfree_safe_ptr<T> – это эквивалентно safe_ptr<T, contention_free_shared_mutex<>>
В конце покажем сравнительные графики тестов нашего thread-safe указателя и одних из лучших lock-free алгоритмов из libCDS на процессорах Intel Core i5/i7, Xeon, 2 x Xeon.

В этой статье мы детально разберем атомарные операции и барьеры памяти C++11 и генерируемые ими ассемблерные инструкции на процессорах x86_64.

Далее мы покажем как ускорить работу contfree_safe_ptr<std::map> до уровня сложных и оптимизированных lock-free структур данных аналогичных по функциональности std::map<>, например: SkipListMap и BronsonAVLTreeMap из библиотеки libCDS (Concurrent Data Structures library): github.com/khizmax/libcds

И такую многопоточную производительность мы сможем получить для любого вашего изначально потоко-небезопасного класса T используемого как contfree_safe_ptr<T>. Нас интересуют оптимизации повышающие производительность на ~1000%, поэтому мы не будем уделять внимание слабым и сомнительным оптимизациям.

В этих 3-ех статьях я детально расскажу об атомарных операциях, барьерах памяти и о быстром обмене данными между потоками, а так же о «sequence-points» на примере «execute-around-idiom», а заодно постараемся вместе сделать что-нибудь полезное — умный указатель, который делает любой объект потоко-безопасным для любых операций с его членами переменными или функциями. А затем покажем как используя его достичь производительности высоко-оптимизированных lock-free алгоритмов на 8 — 64 ядрах.

Введение

В доисторические времена высокопроизводительные Web-приложения можно было писать, в основном, на C или C++. Поддерживать такие приложения было не просто дорого, а очень дорого.

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

В первую очередь термины "производительность" и "надежность" относятся к Erlang. В своей нише он великолепен, но синтаксис заставляет желать лучшего. Собственно, именно поэтому появился Elixir, но речь сейчас не об этой экосистеме.

Если же немного снизить планку надежности, то здесь перед нами широкий выбор, включая Node, Go, Nim и Crystal. Можно взглянуть на типичные сравнительные данные по производительности, включая более обширные.

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

При это Node предлагает всем понятный язык программирования (и вариации на тему), но динамическая типизация снижает производительность в несколько раз относительно других претендентов.

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

Так почему же Crystal?

В предыдущей статье Жирные программы-факторы скорости были набросаны наметки по теме — почему программы "тормозят".

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

Была написана утилита, которая позволяет измерить время загрузки программы и связанные с этим расходы — дисковый ввод/вывод и потребляемую память. Ссылка в конце статьи.

Некоторые тесты под катом.

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

Список лекций:

• Лекция 1. Введение
• Лекция 2. Функции, структуры, интерфейсы. Объектная модель
• Лекция 3. Асинхронная модель
• Лекция 4. Web. Работа с сетью
• Лекция 5. Работа с СУБД
• Лекция 6. Система тестирования
• Лекция 7. Reflect or generate?
• Лекция 8. Производительность
• Лекция 9. Context, unsafe, cgo

Выход Java 9 — новой версии платформы — был отложен. Все это связано с недавними возражениями Red Hat и IBM касательно работы над системой модулей.

UPD: По итогам мероприятия мы сделали 8 предложений о работе: 5 – iOS-разработчикам, 3 – Android-разработчикам.

Привет, Хабр! Я Богдан, разработчик в iOS-команде Badoo в Лондоне. Прочитав заголовок, вы можете подумать, что в Badoo совсем с ума сошли публиковать посты на такие темы. Но пост вполне для Хабра. Мы сейчас очень активно расширяем iOS- и Android-команды и ищем разработчиков по всему миру. Естественно, Москву обойти стороной просто не можем (наш второй офис здесь). Мы хотим провести достаточно необычное мероприятие, чтобы после него обзавестись новыми коллегами.

Мы (мобильные команды Badoo) решили приехать на несколько дней в Москву и провести небольшую встречу, после которой несколько разработчиков (iOS и Android) получат предложения о работе у нас (в Лондоне). Чтобы не затягивать эту самую встречу, мы сделали онлайн-тест (он не суперсложный, а скорее чтобы понять ваш уровень и упростить и ускорить личные встречи).

Блогеры и авторы, пытающиеся быть на передовой, уже немало писали про проект Amber в Java 10. В этих статьях обязательно упоминается вывод типов локальных переменных, улучшения enum и лямбд, иногда пишут про pattern matching и data-классы. Но при этом незаслуженно обходится стороной JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions. Возможно, потому что мало кто понимает, к чему это вообще. Хотя любопытно, что именно об этой фиче ребята из NIX_Solutions фантазировали на Хабре год назад.

Широко известно, что в виртуальной машине Java, начиная с версии 7, есть интересная инструкция invokedynamic (она же indy). Про неё многие слышали, однако мало кто знает, что она делает на самом деле. Кто-то знает, что она используется при компиляции лямбда-выражений и ссылок на методы в Java 8. Некоторые слышали, что через неё реализована конкатенация строк в Java 9. Но хотя это полезные применения indy, изначальная цель всё же немного другая: делать динамический вызов, при котором вы можете вызывать разный код в одном и том же месте. Эта возможность не используется ни в лямбдах, ни в конкатенации строк: там поведение всегда генерируется при первом вызове и остаётся постоянным до конца работы программы (всегда используется ConstantCallSite). Давайте посмотрим, что можно сделать ещё.

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

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

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

В моей текущей компании никто не упоминает о правильном именовании переменных, это несерьезно. Мы обсуждаем с коллегами стили именования тестов, стоит ли использовать TestCase атрибут в nUnit, спорим о целесообразности #region в C#, пишем кастомные анализаторы для своих проектов и пьем смузи вообще всячески наслаждаемся жизнью.

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

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

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

А теперь к делу!

Привет, Хабр! Сегодня хочу поделиться своим небольшим опытом выбора инструментов для организации расчетов на будущем сервере. Отмечу сразу, что в этой публикации речь пойдет не о самом сервере, а скорее об оптимизации символьных вычислений на нем.

Задача

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

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

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

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

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?

Некоторое время назад в одном уютном камерном собрании я делал доклад о своей разработке — скриптовом лиспоподобном языке Liscript. Начал с азов — семантики вычисления списков, префиксной нотации… Дошел до произвольной арности стандартных операций:

+ 1 2 3
=> 6

все интуитивно понятно, вопросов не возникает. Рассказываю про булевские значения, привожу пример:

< 1 2
=> true

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

< 1 2 3
=> true
< 1 2 3 4 1 2
=> false

Все так же интуитивно понятно, вопросов не возникает и продолжаем дальше (благоразумно оставляя без рассмотрения вычисления примитивных операций на одном аргументе и вообще при отсутствии оных, а также вычитание/деление и прочие немоноидальные операции :)). Успешно миновав в докладе подобных камней, через некоторое время я подумал — а можно ли как-то изловчиться, и все-таки сделать операцию сравнения моноидом (в каком-либо смысле)? И мне кажется, мне это удалось. Заинтересовавшихся темой прошу под кат.