В течение полугода я программировал преимущественно на Go. И я разочарован. По двум причинам:

• В Go особенно трудно придерживаться функциональной парадигмы. По сути, язык препятствует функциональному программированию. Меня это разочаровало, потому что в императивном коде, который я пишу, большое количество шаблонных кусков. К тому же, как мне кажется, в этом случае выше риск ошибок, в отличие от использования функциональных абстракций.
• Я считаю, что Go упускает свои шансы. В программных языках появились замечательные нововведения (особенно в сфере проверки и вывода типов — type inference), делающие код безопаснее, быстрее и чище. Мне хотелось бы, чтобы Google использовала своё влияние, чтобы поддержать некоторые из этих идей.

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

• Why Go Is Not Good
• Everyday hassles in Go
• Three Months of Go (from a Haskeller’s perspective)
• The Language I Wish Go Was

Ниже я добавлю свои соображения. Чтобы показать, как именно можно улучшить Go, я буду сравнивать его с Rust.

Много где написано о том, как получить 100% и A+ по тесту от Qualys. При всём при том практически везде директивы ssl_ciphers и подобные даются как эдакие магические строки, которые нужно просто вставить, и надеяться, что автор не подводит вас под монастырь. Эта статья призвана исправить это недоразумение. По прочтению этой статьи директива ssl_ciphers потеряет для вас всякую магию, а ECDHE и AES будут как друзья да братья.

Также вы узнаете почему 100% по тестам — не всегда хорошо в реальности.

Недавно вышла новость про то, что webassembly теперь включен в firefox 52 из коробки. А потом еще и chrome 57 подтянулся (правда, там вроде бы были какие-то баги с запуском). Я решил, что обязательно надо попробовать.

Для тех, кто не знает, что такое webassembly краткая информация: webassembly (или wasm) — это низкоуровневый язык, который понимают браузеры, и в который можно будет скомпилировать программы, написанные на популярных языках. Это гораздо более выгодно по скорости парсинга и выполнения, чем компилировать эти языки в чистый javascript или какой-нибудь asm.js.

Wasm задумывался в основном для c/c++, но, на удивление, уже все готово, чтобы скомпилировать программу на rust. Давайте сделаем небольшое приложение и посмотрим, что получится. Все это будем компилировать на Ubuntu. Без теоретических деталей, просто "пощупаем".

Третья и заключительная часть перевода статьи из блога сервиса Auth0 A Brief History of JavaScript. Ключевые моменты: транспайлеры и ECMAScript 2015, немного о новом процессе подготовки обновлений, чего ждать в будущем и как на него повлияют Asm.js и WebAssembly. Перевод подготовлен отделом фронтенд-разработки компании Лайв Тайпинг.

Краткая история JavaScript. Часть 1
Краткая история JavaScript. Часть 2

Продолжение перевода статьи A Brief History of JavaScript, подготовленный отделом фронтенд-разработки компании Лайв Тайпинг. Первая часть закончилась на том, что в ноябре 1996 года язык JavaScript начали приводить к стандартам ECMA. С этих пор язык проходит по бумагам как ECMAScript, но в обыденной жизни все называют его по-прежнему. Читайте во второй части: версии ECMAScript, появление технологии AJAX, ActionScript и его влияние на Flash и путь к Гармонии.

Краткая история JavaScript. Часть 1

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

В далекие времена, до фейсбука и гугла, когда 32 мегабайта RAM было дофига как много, security была тоже… немножко наивной. Вирусы выдвигали лоток CD-ROM-а и играли Янки Дудль. Статья «Smashing the stack for fun and profit» уже была задумана, но еще не написана. Все пользовались telnet и ftp, и только особо продвинутые параноики знали про ssh.

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

Michael Widenius (или просто Monty) явно был знаком с параноидальными безопасниками не понаслышке, чего стоит один такой момент (из исходников, global.h):

/* Paranoid settings. Define I_AM_PARANOID if you are paranoid */
#ifdef I_AM_PARANOID
#define DONT_ALLOW_USER_CHANGE 1
#define DONT_USE_MYSQL_PWD 1
#endif

Так что неудивительно, что пароли в MySQL открытым текстом не передавались никогда. Передавались случайные строки на основе хешей. А конкретно, первый протокол аутентификации (цитируется по mysql-3.20, 1996) работал так:

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

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Несколько дней назад сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый алгоритм генерации коллизий для SHA-1. За десять лет существования SHA-1 не было известно ни об одном практическом способе генерировать документы с таким же хешем SHA-1 и цифровой подписью, как в другом документе, но теперь такая возможность появилась.

Хеш-функция SHA-1 используется повсеместно, поэтому известие о генерации документов с идентичным хешей вызвало естественную обеспокоенность у пользователей. В том числе у пользователей системы управления версиями Git, в которой тоже используются хеши SHA-1. Развёрнутый ответ на эти опасения дал Линус Торвальс. Если вкратце, то бояться нечего.

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

Все началось примерно 6 лет назад, когда я познакомился с node.js. Около 3 лет назад я начал использовать node.js на проектах вместе с замечательной библиотекой express.js (на wiki она названа каркасом приложений, хотя некоторые могут называть express фреймворком или даже пакетом). Express сочетает в себе node.js http сервер и систему промежуточного ПО, созданную по образу каркаса Sinatra из Ruby.

Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

При создании веб-приложения мы в какой-то момент задаемся вопросом — как управлять его состоянием? Vue предоставляет нам способ управлять им в пределах одного компонента, подход очень простой, и при этом замечательно работает. Но что делать, если в приложении множество компонентов, которые должны иметь доступ к одним и тем же данным? Одно из решений этой задачи — Vuex, инструмент для централизованного управления состоянием. В данной статье мы рассмотрим из чего он состоит и как его использовать.

Последние несколько месяцев ситуация вокруг RethinkDB была весьма смутна, о будущем проекта было сложно что-то сказать. Но ситуация наконец-то разрешилась, в официальном блоге появилось долгожданное обновление с разъяснением о текущем положении вещей. Как стало известно, CNCF(Cloud Native Computing Foundation) выкупила права на исходники RethinkDB и передала проект под покровительство организации Linux Foundation. Перед передачей код был переведён с лицензии AGPLv3 на Apache 2.0. Передача осуществлена в рамках предпринятой бывшими разработчиками RethinkDB инициативы по передаче сообществу управления над проектом.

В процессе разработки современных JS приложений особое место уделяется тестированию. Test Coverage на сегодня является чуть ли не основной метрикой качества JS кода.

В последнее время появилось огромное количество фреймворков которые решают задачи тестирования: jest, mocha, sinon, chai, jasmine, список можно продолжать долго, но даже имея такую свободу выбора инструментов для написания тестов остаются кейсы которые сложно протестировать.

О том как протестировать то что в общем может быть untestable пойдет речь далее.

В нашем мире без JavaScript никуда! Куча фреймворков, библиотек и прочей радости! jQuery плотно вошел в нашу жизнь. React с Angular пробивают дорогу к светлому будущему. Да и не за горами поддержка браузерами ES6 без Babel.

Но если тема заходит об обычном сайте со стандартным функционалом, не редки случаи, когда JavaScript начинают “злоупотрелять”. И все, в принципе, нормально… Но порой задаешься вопросом: «А если без JavaScript?».

Это перевод поста в блоге Гая Бедфорда — основного разработчика таких замечательных инструментов, как JSPM — менеджера пакетов для браузеров и NodeJS, который работает на основе его же детища SystemJS — асинхронного загрузчика JS модулей любых известных форматов, способного расправляться в том числе с циклическими зависимостями, и который, в свою очередь, основан на его же детище под названием es-module-loader, полифиле для загрузки ES модулей. Как я понимаю, автор довольно сильно переписал SystemJS в данном релизе, и об этом будет интересно почитать хабраюзерам.

SystemJS 0.20 только что зарелизился — это полная его переработка, а также коррекция спецификации, в то время как ES модули уже находятся прямо здесь, в браузерах.

SystemJS изначально был разработан ещё в 2013-м году для проекта jspm, в то время когда RequireJS был лидирующим загрузчиком модулей. Параллельно развивался ES6, а модули ES6 всё ещё казались нематериальным сном. Идея SystemJS была простой и убедительной: модули приходят в браузеры, так что нам надо иметь возможность загружать любой модуль в любое время из браузера, что дало бы очень простой процесс разработки.

В конце 2015 года я услышал об этой паре ключевых слов, которые ворвались в мир JavaScript, чтобы спасти нас от promise chain hell, который, в свою очередь, должен был спасти нас от callback hell. Давайте посмотрим несколько примеров, чтобы понять, как мы дошли до async/await.

Перевод книги Райана Макдермота clean-code-javascript

Оглавление:

• Введение
• Переменные
• Функции
• Классы
• Объекты и структуры данных. Асинхронность. Обработка ошибок.
• Тестирование. Форматирование. Комментарии.

Предупреждение: проверьте, как установлена версия Webpack в package.json. Возможно скоро ваш continuous integration сломается.

Наконец-то Webpack 2 преодолел рубеж beta и release candidate. Это значит, что всё работает стабильно, и можно без опаски использовать его в production.

Список изменений/улучшений:

• Нативная поддержка ES6-модулей;
• Разбиение кода на чанки — Code Splitting with ES6;
• Поддержка динамических выражений при загрузке модулей — Dynamic expressions;
• Изменения при работе с Babel;
• ES6-специфичные оптимизации;
• Breaking Changes;
• Новый сайт с документацией.

Подробности под катом.

Перевод книги Райана Макдермота clean-code-javascript

Оглавление:

• Введение
• Переменные
• Функции
• Классы
• Объекты и структуры данных. Асинхронность. Обработка ошибок.
• Тестирование. Форматирование. Комментарии.