О хранении данных в Parquet-файлах не так много информации на Хабре, поэтому надеемся, рассказ об опыте Wrike по его внедрению в связке со Spark вам пригодится.
В частности, в этой статье вы узнаете:

— зачем нужен “паркет”;
— как он устроен;
— когда стоит его использовать;
— в каких случаях он не очень удобен.

(у учебника по Основам React вышло второе издание, Redux-учебник в процессе обновления)

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

Курс про Redux попал в официальную документацию.

Оба руководства бесплатны и выложены на gitbook (можно скачать PDF, ePub, mobi).

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

В один прекрасный момент для одного из проектов появилась необходимость в хранении, обработке и визуализации большого количества логов. Необходимо было индексировать около 10-20 тысяч запросов в секунду с пиками до сотни тысяч, что, как оказалось, является нетривиальной задачей. Для решения этой проблемы мы решили использовать уже знакомый многим ELK- стек. Единственным вопросом было — «а потянет ли он». Как оказалось, потянет, но не сразу.

Phar — это аналог jar из мира Java, но только применительно к PHP. Phar упаковывает файлы проекта в специальный архив и позволяет легко переносить и устанавливать приложение без манипуляций с самим проектом в виде исполняемой программы.



Для создания phar файлов в PHP существует довольно развесистый API, но есть способ проще и удобнее — использовать проект Box.

Формат JSON файла

Проект Box позволяет описать процесс создания phar файла в удобном JSON формате.

Самый простой файл выглядит так:

{
    "files": ["src/Put.php"],
    "main": "bin/main",
    "output": "example.phar",
    "stub": true
}

Знакомьтесь: Pagekit — это новая модульная CMS от немецкой студии-производителя шаблонов YOOtheme, основанная на Symfony компонентах, а также Vue.js, Webpack, Doctrine и других современных технологий. Pagekit задумывался как сочетание простоты в управлении с гибкими возможностями для разработки — того, чего не хватает известным CMS на базе PHP, и имеющим множество анахронизмов.

«Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее»
Льюис Кэрролл, «Алиса в Зазеркалье»

Недавно мы в Таргете Mail.Ru реализовали систему push-уведомлений. Грамотное использование очередей задач позволяет реализовать быструю систему доставки уведомлений. В этом посте я расскажу о применении и реализации этой модели в нашем сервисе.

С приближением Web 3.0 все активнее начинают использоваться подходы API first и Linked Data (или что-то вроде Sematic Web). В связи с этим читателям предлагается познакомиться с фреймворком для удобного создания API на базе схем собранных на schema.org с генерацией ответов в виде JSON-LD,

Это укороченная версия туториала Api-platform

Недавно вышла новая версия стандарта HTTP. В мае 2015 года был утвержден HTTP/2, который получил распространение среди браузеров и веб-серверов (включая NGINX и NGINX Plus). На данный момент более 60% используемых браузеров поддерживают HTTP/2, причем эта цифра продолжает увеличиваться с каждым месяцем.

Стандарт HTTP/2 основан на протоколе SPDY, разработанном компанией Google. В Google Chrome поддержка SPDY будет осуществляться до начала 2016 года. NGINX одним из первых реализовал протокол SPDY и сейчас играет ведущую роль в продвижении HTTP/2. Была опубликована статья, в которой дано подробное описание HTTP/2, приводится сравнение со SPDY и подробно описывается процесс внедрения нового протокола.

3 ноября в нашем московском офисе прошла встреча сообщества #PostgreSQLRussia. В этот раз участники обсуждали нюансы перехода на PostgreSQL с других СУБД. В России вот уже несколько лет наблюдается тенденция к отказу от проприетарных СУБД. Некоторые крупные компании уже мигрировали или находятся в процессе миграции на PostgreSQL. Их опыт интересен не только с точки зрения самого процесса миграции. Крупные проекты, которые перешли на Postgres, могут поделиться новым уникальным опытом, что, безусловно, полезно и тем, кто использует Postgres давно. Смотрите наш отчет с конференции под катом.

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

– у меня полетели диски/кто-то удалил мою базу… как мне восстановить мои данные?
– у вас есть свежий бекап?
– нет

Чтобы не стать героем такой ситуации, нужно потратить минимум усилий. Во-первых, выделить дисковый массив, на который складывать резервные копии. Поскольку, хранить бекапы вместе с файлами БД – явно не наш выбор. Второе… это создать план обслуживания по резервному копированию баз данных.

Что мы и сделаем далее, а после обсудим некоторые тонкости связанные с бекапами.

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

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

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

Преамбула от переводчика: Это достаточно вольный перевод пусть и не самой свежей (июнь 2013 года), но доходчивой публикации о новом планировщике параллельных ветвей исполнения в Go. Достоинством этой заметки есть то, что в ней совершенно просто, «на пальцах» описывается новый механизм планирования для ознакомления. Тем же, кого не устраивает объяснение «на пальцах» и кто хотел бы обстоятельного изложения, рекомендую Scheduling Multithreaded Computations by Work Stealing — 29 страниц изложения со строгим и сложным математическим аппаратом для анализа производительности, 48 позиций библиографии.

Введение

Одной из наибольших новинок в Go 1.1 стал новый диспетчер, спроектированный Дмитрием Вьюковым (Dmitry Vyukov). Новый планировщик дал настолько разительное увеличение производительности для параллельных программ без изменений кода, что я решил написать что-нибудь об этом.

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

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

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

По долгу работы я примерно 3 года занимаюсь разработкой и поддержкой нескольких проектов, которые используют MongoDB в качестве основной БД, и в этой статье хочу рассказать, почему на мой взгляд с MongoDB далеко не все так просто, как написано в мануалах, и к чему вы должны быть готовы, если вдруг решите взять MongoDB в качестве основной БД в ваш новый модный стартап :-)

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

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

Для начала, вспомним, что такое MVP. MVP — это паттерн, который позволяет «разбивать» приложение на три основных слоя (компонента):

1. Модель (Model) — где сосредоточены данные;
2. Представление (View) — интерфейс приложения (UI — элементы);
3. Presenter — промежуточный компонент, который реализует связь между Моделью и Представлением.

MVP паттерн — это наследник более известного шаблона — MVC. Применение такого подхода позволяет отделить в приложении логику от интерфейса.

Предлагаю читателям «Хабрахабра» перевод статьи главного архитектора компании Malwarebytes о том, как они достигли обработки 1 миллиона запросов в минуту всего на 4 серверах.

У нас в Malwarebytes мы переживаем бешеный рост и с тех пор, как я присоединился к компании около года назад в Кремниевой Долине, одной из моих основных обязанностей было проектирование и разработка архитектур нескольких систем для развития быстрорастущей компании и всей необходимой инфраструктуры для поддержки продукта, который используют миллионы людей каждый день. Я работал в индустрии антивирусов более 12 лет в нескольких разных компаниях, и знаю, насколько сложными получаются в итоге эти системы, из-за колоссальных объемов данных, с которыми приходится иметь дело ежедневно.

Предлагаю вашему вниманию перевод гостевого поста из блога Go от лица Yang Zhou, в данный момент занимающего позицию инженера в Qihoo 360.

Qihoo 360 является лидирующим поставщиком антивирусных продуктов для интернета и мобильных устройств в Китае, контролирует крупную платформу дистрибьюции мобильных приложений для Android (магазин приложений). На конец июня 2014 года Qihoo пользовались 500 миллионов активных пользователей ПК в месяц и свыше 640 миллионов пользователей мобильных устройств. У Qihoo также имеется свой браузер и поисковый движок, оба не менее популярны среди китайцев.

В последнее время все чаще и чаще поднимается тема хакерской угрозы в автомобильном мире. Причем тема эта волнует всех — производителей авто, OEM, консультантов по ИБ, и, конечно, власти ЕвроСоюза и США интересуются этой темой (даже выделяют гранты на исследования и тд). Так как в индустрии ИБ очень часто все движухи это попытка «напугать», то хотелось бы разобраться в ситуации «сейчас» и потенциальной ситуации в «будущем» без лишнего пафоса и паранойи, хотя в нашем деле лучше «перебдеть», чем «недобдеть». В ходе своей работы я занимаюсь безопасностью систем ConnectedCar, в том числе и Embedded продуктов для Автомобильных систем. И в свете всего вышесказанного я бы хотел поговорить про недалекое будущее и новые риски связанные с IoT, автомобилями и хакерами. Конкретно в этой части я поговорю про потенциальные вектора атак на Head Unit авто и его окружение.