Сегодня мы подготовили для вас дайджест, в котором постарались собрать самые интересные литературные источники, статьи, видеокурсы и лекции (в том числе подготовленные силами преподавателей, студентов и сотрудников Университета ИТМО), которые позволят познакомиться с Data Science.

Эти материалы затрагивают как теоретические аспекты работы с данными, так и практические — направленные на создание алгоритмов и написание программ.

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

Как выглядят типичные трудовые будни системного администратора, который сидит на Linux? Если абстрагироваться от всего, кроме набираемых на клавиатуре команд, то окажется, что команды эти постоянно повторяются. Всё выходит на уровень автоматизма. И, если даже в работе есть что улучшать, привычка противится новому. Как результат, немало времени уходит на то, чтобы делать так, как привычнее, а не так, как быстрее, и, после небольшого периода привыкания – удобнее. Помнить об этом, сознательно вводить в собственную практику новые полезные мелочи – значит профессионально расти и развиваться, значит – экономить время, которое можно много на что потратить.

Перед вами – небольшой список полезных приёмов работы с командной строкой Linux. С некоторыми из них вы, возможно, уже знакомы, но успели их позабыть. А кое-что вполне может оказаться приятной находкой даже для знатоков. Хочется надеяться, что некоторые из них будут вам полезны и превратятся из «списка» в живые команды, которыми вы будете пользоваться каждый день.

Алгоритмы — это всего лишь пошаговые алгоритмы решения задач, и большинство таких задач уже были кем-то решены, протестированы и проверены. Можно, конечно, погрузиться в глубокую философию гениального Кнута, изучить многостраничные фолианты с доказательствами и обоснованиями, но хотите ли вы тратить на это свое время?

Откройте великолепно иллюстрированную книгу, и вы сразу поймете, что алгоритмы — это просто. А грокать алгоритмы — это веселое и увлекательное занятие.

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

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

Статья публикуется от имени Перфильева Алексея, akaaxel

Gatling – это framework для проведения нагрузочного тестирования. Он основан на трех технологиях: Scala, Akka и Netty.
В этой статье мы:

1. Посмотрим, как установить и начать использовать Gatling.
2. Разберем синтаксис скриптов Gatling на языке Scala.
3. Напишем небольшой тест, где используем основные функции Gatling. Запустим тестовый скрипт при помощи sbt и сохраним отчет.

Функциональный язык программирования Elixir набирает популярность, а один из последних фреймворков для создания одностраничных приложений — Angular 2 — недавно вышел в релиз. Давайте познакомимся с ними в паре статей, создав с нуля полноценный back-end на Elixir и Phoenix Framework, снабжающий данными клиентское приложение-frontend на базе Angular 2.

Hello, world — не наш вариант, поэтому сделанное при необходимости можно будет применить в реальных проектах: весь представленный код выложен под лицензией MIT.

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

В первой статье будет несколько вступительных слов и работа над back-end. Поехали!

Вступление

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

Мы добрались до самой интересной и увлекательной темы — это скрипты на bash. Когда вы запускаете терминал, внутри него работает специальная программа-оболочка — shell (англ) — интерпретатор команд. Shell понимает все команды, которые вы вводите с клавиатуры, и обрабатывает их. Также выводит сообщения об ошибках, следит за корректностью команд и их синтаксисом. Примером таких команд могут быть: сменить директорию, создать новую директорию, добавить текстовый файл, отредактировать текстовый файл, сохранить изменения и другие.

Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.

Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.

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

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

Discord

Discord испытал небывалый рост. Чтобы справиться с ним, нашему отделу разработки досталась приятная проблема — искать способ масштабирования сервисов бэкенда.

В этом деле мы добились большого успеха с помощью одной технологии, которая называется Elixir GenStage.

Идеальный шторм: Overwatch и Pokémon GO

Этим летом наша система мобильных push-уведомлений стала скрипеть от нагрузки. Чат /r/Overwatch перевалил за 25 000 одновременных пользователей, а чат-группы Pokémon GO возникали повсеместно, так что внезапные всплески потока уведомлений стали серьёзной проблемой.

PostgreSQL это современная, динамично развивающаяся СУБД с очень большим набором возможностей которые позволяют решать самый широкий спектр задач. Использование PostgreSQL как правило относится к очень критичному сегменту ИТ инфраструктуры который связан с обработкой и хранением данных. Учитывая особое место СУБД в инфраструктуре и степень критичности возложенных на нее задач, возникает вопрос мониторинга и надлежащего контроля за работой СУБД. В этом плане PostgreSQL обладает широкими внутренними средствами сбора и хранения статистики. Собираемая статистика позволяет получить довольно подробную картину о том что происходит под капотом в процессе функционирования СУБД. Эта статистика хранится в специальных системных таблицах-представлениях и постоянно обновляется. Выполняя обычные SQL запросы в эти таблицы можно получать разнообразные данные о базах, таблицах, индексах и других подсистемах СУБД.
Ниже я описываю способ и средства для мониторинга PostgreSQL в системе мониторинга Zabbix. Мне нравится эта система мониторинга поскольку предоставляет широкие возможности для реализации самого кастомного мониторинга самых разных систем и процессов.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

6 лет я создавал приложения на языке Ruby и фреймворке Rails. Я щупал всякие новые языки программирования по мере их выхода, но Elixir – первый из них, который меня действительно увлёк.

В своё время Ruby уделал всех

Язык Ruby и фреймворк Rails полностью поменяли способ создания веб-приложений. Они дали начало религии ценностей для сообщества программистов. Они первые предложили идею, согласно которой инструменты программиста должны быть оптимизированы для продуктивной и радостной разработки.

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



Ruby прошёл путь от скромного положения невразумительного языка до одного из самых популярных языков, в основном из-за фреймворка Rails и огромного лидерского потенциала таких людей, как DHH, Wycats, Aaron Patterson, Jose Valim и множества других. Но периодически, и тут и там начинают вылезать артефакты, оставшиеся из-за такого скромного старта языка.

Убегающая память

Зед Шо [Zed Shaw] в посте "Rails – это гетто" разглагольствует на тему проблем со сборкой мусора, из-за которых первые приложения на Rails перезапускались каждые 4 минуты.

Один из самых популярных серверов для Rails сегодня – это unicorn. Моё веб-приложение – это приложение для Rails, оно довольно простое, по сравнению с другими приложениями, которые я разрабатывал. Я перенёс его на сервер с 512 Мб памяти, и после нескольких дней работы мой unicorn съел всю доступную память и приложение начало тормозить.

Решение? unicorn-worker-killer. Не слишком отличается от более ранних решений.

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Вступление

FreeNAS 9.1.1 — дистрибутив для быстрого развёртывания сетевого хранилища, основан на базе FreeBSD, отличается интегрированной поддержкой ZFS и полностью настраивается через веб-интерфейс. Для организации доступа к хранилищу поддерживается FTP, NFS, Samba, AFP, rsync и iSCSI, для повышения надежности хранения может применяться программный RAID (0,1,5), для авторизации клиентов реализована поддержка LDAP/Active Directory.

Версия FreeNAS 9.1.1 примечательна переходом на кодовую базу FreeBSD 9, (прошлый выпуск был основана на FreeBSD 8.3), а также проведением огромной работы по улучшению удобства использования, стабильности и производительности. Улучшения затронули практически все подсистемы дистрибутива, от web-интерфейса до системы подключения плагинов. Инфраструктура разработки проекта переведена на использование Git.

FreeNAS можно установить на жесткий диск или USB-флешку. При этом система занимает весь объем носителя на который устанавливается, не зависимо от емкости, а все сетевые ресурсы для хранения информации размещаются на других жестких дисках.
т.е. сама система freenas занимает 1 жёсткий диск на котором нельзя ничего хранить, а на втором уже может хранится вся наша инфа!

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

Установка.

Вставляем CD-диск с FreeNAS в привод, и загружается с него. Видим такую картину

В первой части мы установили и частично настроили наш FreeNAS надо двигаться дальше. Почему бы не поставить на него какой то BitTorrent-клиент? например Transmission. Мы не будем использовать встроенные плагины FreeNAS, а немного потренируемся используя консоль, и текстовый редактор vi :)

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

Всем привет! Я работаю в AT Consulting и представляю команду разработчиков портала Beeline.kz, который мы пишем на Ruby on Rails. Поскольку информация в нашей сфере быстро устаревает, приходится постоянно следить за новостями и обучаться новым технологиям. По мере накопления новостей и полезных материалов, связанных с Ruby, я буду публиковать Ruby-дайджест.
Большинство материалов, которые я собрал в дайджесте, написаны на английском, но я надеюсь, что это не проблема, ведь первый шаг к Ruby – это изучение языка.

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

Dokku это средство простого трансформирования Ubuntu сервера, в мини-Heroku. После установки dokku, вы получаете возможность делать:

$ git push production master

для могих популярных платформ (Node.js, Java, PHP, Python etc). Результатом процесса развертования, есть запущенное приложение, к которому сразу можно получить доступ по http/https.

Как это работает?

Если открыть репозиторий проекта, то в описании можно увидеть строчку - «Docker powered mini-Heroku in around 100 lines of Bash» — около 100 строчек баш кода, который иммитирует работу Heroku. Это довольно «легкая» реализация, как для такой большой проблемы, которую он решает.

Все объясняется тем, что Dokku стоит на плечах таких технологий как: Docker, Heroku Buildpacks, Nginx, Git.

Dokku — это мини-Heroku, сделанный на базе Docker и состоящий из менее чем 100 строк на Bash.

После установки Вы сможете публиковать свои приложения простым git push. Каждое приложение будет запущено в изолированном контейнере. В конечном итоге у Вас будет своя Heroku-подобная платформа.

Цель данной статьи — показать возможный подход для построения микросервисов с использованием Scala, RESTful JSON, Spray и Akka. В качестве базы данных мы будем использовать MongoDB. В результате нашей работы мы упакуем наш проект в Docker-контейнер, а Vagrant и Ansible позволит нам управлять конфигурацией приложения.

В этой статье вы не найдете подробностей о языке Scala и других технологиях, которые будут использоваться в проекте. В ней вы не найдете руководства, которое ответит на все ваши вопросы. Цель статьи — показать технику, которую можно использовать при разработке микросервисов. На самом деле, большая часть этой статьи не завязана на конкретной технологии. Docker имеет более широкую сферу использования, нежели только микросервисы. Ansible позволяют быстро развернуть любое требуемое окружение, а Vagrant — отличный инструмент для создания виртуальных машин.

Эта статья предназначена для тех, кто уже знает про Docker, знает для чего он. А вот что делать с этим дальше не знает. Статья носит рекомендательный характер и не посягает на звание «лучшая практика».

Итак, возможно вы прошли docker tutorial, докер кажется простым и полезным, но вы пока не знаете, как он может вам помочь с вашими проектами.

Обычно с деплоем возникает три проблемы:

1. Как мне доставить код на сервера?
2. Как мне запустить код на серверах?
3. Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?

Как с этим поможет Docker под катом.