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

Познакомьтесь с радикальными изменениями в языке JavaScript, которые произошли благодаря новому стандарту ECMAScript 6. Николас Закас — автор бестселлеров и эксперт-разработчик — создал самое полное руководство по новым типам объектов, синтаксису и интересным функциям. Каждая глава содержит примеры программ, которые будут работать в любой среде JavaScript и познакомят вас с новыми возможностями языка. Прочитав эту книгу, вы узнаете о том, чем полезны итераторы и генераторы, чем ссылочные функции отличаются от обычных, какие дополнительные опции позволяют работать с данными, о наследовании типов, об асинхронном программировании, о том, как модули меняют способ организации кода, и многом другом.

Более того, Николас Закас заглядывает в изменения, которые появились в ECMAScript 7. Неважно, являетесь вы веб-разработчиком или работаете с node.js, в этой книге вы найдете самую необходимую информацию, позволяющую эффективно использовать все возможности ECMAScript 6.

Команда Rust рада представить выпуск Rust 1.17.0. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Если у вас установлена предыдущая версия Rust, то для обновления достаточно выполнить:

$ rustup update stable

Если у вас ещё не установлен Rust, то вы можете установить rustup c соответствующей страницы нашего веб-сайта и ознакомиться с подробным примечанием к выпуску 1.17.0 на GitHub.

Что вошло в стабильную версию 1.17.0

Выпуск Rust 1.17.0 в основном вносит небольшие улучшения, преимущественно касающиеся удобства использования. Например, время жизни 'static теперь автоматически подразумевается для констант или статических переменных. При создании константы или статической переменной:

Наверняка каждый программист, работающий с OAuth 2.0, задумывался – зачем же нужны Refresh токены, неужели Access токенов недостаточно? 64 KB — Их должно хватать каждому!

Эта тема довольно активно дискутируется – вот и на Stackoverflow вопрос есть и на Хабре тоже обсуждается. Собственно, именно обсуждение на Хабре и заставило меня высказаться.

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

«Refresh токен можно хранить более защищенно!» — можно и нужно, хотя почти никто так не делает.
«Access token передается по сети чаще – и вероятность его утечки больше» — полноте, мы ведь всегда используем TLS, правда?
«Утечка Ассеss токена на так страшна как утечка Refresh токена» — да, и это тоже правда, именно поэтому в браузер Refresh токен и не выдается…

Есть много нюансов, есть много сценариев использования, при которых использование разных токенов становится полезным, просто видно их не сразу!

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

Производительность.

В предыдущем уроке обсуждалась матрица вида, и то, как её можно использовать для перемещения по сцене (мы немного отодвинули назад точку зрения наблюдателя). В OpenGL отсутствует концепция камеры, но можно попытаться её сымитировать, перемещая все объекты сцены в направлении противоположном движению наблюдателя, и тем самым создать иллюзию, что движемся мы сами.

В этом уроке мы рассмотрим, как можно создать камеру в OpenGL. Мы обсудим камеру типа FPS (First Person Shooter), которая позволит вам свободно перемещаться в трехмерной сцене. Кроме того, мы поговорим о вводе с клавиатуры и мыши, а закончим созданием собственного C++ класса камеры.

Спустя полгода сообщество Go-разработчиков снова воссоединилось в нашем московском офисе 14 апреля. И теперь у нас есть возможность ознакомиться с тем, как проходила эта встреча. Пять докладов и прочие подробности ищите под катом.

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

Хочу подчеркнуть: в статье сделан упор на том, ЗАЧЕМ нужна фича Х, а не на том, ЧТО такое фича Х.

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

Я расскажу про инструменты разработки, сам ЯП, процесс добавления UI и еще много интересного. В конечном итоге мы получим обычный сайт-визитку, но "под капотом" он будет работать на умных контрактах Ethereum. Кого заинтересовало — прошу под кат.

Наверняка вы знаете, кто такой Джон Скит: №1 на Stack Overflow, автор C# in Depth (одной из лучших книг по .NET), разработчик в Google и 14-кратный MVP. Разработчиков такого масштаба не так много, хватит двух порядков, чтобы их всех перечислить. 19-20 мая Джон приедет в Петербург и выступит на DotNext 2017 Piter.

Мне удалось пообщаться с Джоном и взять у него большое интервью по поводу судьбы .NET, .NET Core, нововведений в C# 7 и общем уровне развития среднего разработчика в 2017 году.



Если говорить конкретно, то обсудили следующие вопросы:

• Общее направление развития .NET и ошибки Microsoft;
• Чего ждать от .NET Core в ближайшем будущем;
• Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
• Проблемы и победы .NET на поприще кроссплатформенности;
• Java vs .NET на рынке enterprise решений;
• Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
• Небольшие, но приятные фичи C# 7;
• Деградация сообщества разработчиков (и есть ли она);
• Правильный подход к диагностике багов и постановке правильных вопросов на SO;
• Гайд по изучению новых языков и платформ;
• Проблемы с базовыми типами: числа, текст, дата и время;

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

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

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

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

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

В Voximplant мы в основном занимаемся автоматикой звонков: автоматически ответить и рассказать что с заказом, автоматически позвонить перед доставкой, автоматически соединить с нужным клиентом — вся вот эта история и JavaScript в облаке. Но кроме этого мы любим делать к нашей платформе SDK: Web SDK, чтобы звонить из браузера и в браузер, нативные Android и iOS SDK, чтобы в роуминге звонить через интернет, React Native SDK, чтобы звонить из кросс-платформенных приложений. А несколько дней назад мы сделали SDK для Unity. Который позволяет звонить из виртуальной реальности.

Flashphoner.createSession(...).createCall({callee:'+74957718000'}).call();

В этой статье мы расскажем как сделать кнопку для звонка со страницы сайта на мобильный или городской номер телефона.

При переходе к распределённым системам с большим количеством инстансов сервисов в полный рост встают проблемы их обнаружения (service discovery) и балансировки запросов (load balancing) между ними. Как правило, для их решения используются такие специализированные инструменты как Consul, Eureka или старый добрый Zookeeper, в сочетании с Nginx, HAProxy и некоторым мостом между ними (см. registrator).

Основная проблема в подобном подходе это большое количество интеграций, и, как следствие, точек где что-то может пойти не так. Ведь помимо вышеупомянутых решений наверняка будет использоваться локальный маленький PaaS (например Mesosphere Marathon или Kubernetes). Последние, к слову, уже хранят необходимую конфигурацию об окружении (ведь через них идёт весь деплоймент). И встаёт вопрос, а можем ли мы отказаться от специализированных инструментов для service discovery и переиспользовать тот же Marathon для этой задачи?

Краткий ответ — можем. Если интересно как — читайте дальше.

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

Люди часто спрашивают меня:
Зачем мне вообще использовать RxJava или Reactor, если то же самое можно сделать с помощью Streams, CompletableFutures и Optionals?

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

Давайте определим 8 критериев, которые помогут нам понять разницу между этими библиотеками и стандартными возможностями Java:

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

Русскоязычные видео

Статический анализ кода

Обновлено: доступна видеозапись вебинара.





Мы продолжаем серию вебинаров по SAP Cloud Platform и сегодня в 11:00 приглашаем всех желающих познакомиться с некоторыми сервисами для платформы. Эксперты SAP расскажут о следующих темах:

• как связать воедино разные программные приложения на уровне процессов и данных — создать единый бизнес-процесс, состоящий из бизнес-сервисов, с помощью Integration Service
• как «принести» и использовать свой собственный готовый программный код для запуска на платформе SCP (с помощью Cloud Foundry)
• как превратить свой программный сервис в продаваемый продукт с помощью API Management
• сервис геймификации, позволяющий превратить скучное бизнес-приложение в захватывающее приключение
• WebIDE

Для участия в вебинаре необходимо зарегистрироваться.

Напоминаем, что серия вебинаров приурочена к проведению онлайн-конкурса по разработке приложений SAP Кодер.

Прим. Переводчика. Статья может быть интересна архитекторам и разработчикам, планирующим построение решения на основе микросервисов, либо ищущим способы оптимизации текущего решения, особенно если работа идет с большими объемами данных. Перевод сделан на основе части 1 и части 2 цикла статей о микросервисах на Apache Ignite. Предполагается общее знакомство с экосистемой Java (Apache Ignite работает также с .NET, C++, а через REST и с другими языками, но примеры в статье будут апеллировать к Java), рекомендуется наличие базового знания Spring.

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

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

Перевод поста Джона Макги (John McGee) "Mersenne Primes and the Lucas–Lehmer Test".
Код, приведенный в статье, можно скачать здесь.

Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации.

---

Содержание

— Введение.
— Теорема множителей Эйлера и Мерсенна
— Люка и Лемер
— От $$ до $$
— Совершенные числа
— 21-е, 22-е и 23-е числа Мерсенна
— 24-е, 25-е и 26-е числа Мерсенна.
— 27-е и 28-е числа Мерсенна
— 29-е число Мерсенна
— 30-е и 31-е числа Мерсенна
— Великий интернет-поиск чисел Мерсенна
— Факторизация чисел Мерсенна

---

Введение

Простое число Мерсенна — простое число вида $$ (значение степени р также должно быть простым). Эти простые числа получили свое название от имени французского математика и религиозного ученого Мерсенна, который и составил данный список простых чисел этой формы в первой половине семнадцатого века. Первые четыре из них были известны уже давно: $$, $$, $$ и $$.

Мерсенн утверждал, что значение $$ будет простым для простых чисел $$, принадлежащих множеству $$. Во всем ли он был прав, можно проверить с помощью функции Wolfram Language — PrimeQ, в которой используются современные методы тестирования чисел на простоту, для которых не требуется поиска конкретного множителя, чтобы доказать, что число составное.

Что ж, всё плохо. Немного забавно так говорить: на конференции (Web à Québec) было много разговоров об удивительном будущем и вещах, возможных благодаря новым технологиям. О новых средствах и устройствах, которые должны сделать нашу жизнь проще. Мои знакомые знают, что у меня обычно очень циничный взгляд на технологии; лично я боюсь всех этих умных устройств, которые реагируют на мои слова, чем восхищались другие спикеры.

В основном потому, что чем больше времени я трачу на программирование и провожу в этой отрасли, тем больше узнаю, как всё работает изнутри, и тем меньше доверия всё это мне внушает. Я подобрал изображение для слайда. Это картина «Триумф смерти» Питера Брейгеля. В некоторой степени она раскрывает моё отношение к «умному дому».

Текст этой статьи также доступен на английском.

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

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

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

Забегая вперед сразу скажу, что в конце статьи будет ссылка на github, куда я выложил готовое решение, позволяющее тестировать параллельные консольные процессы легко и просто.