Продолжаем обзор нововведений в PostgreSQL 9.5.
Часть 1. INSERT… ON CONFLICT DO NOTHING/UPDATE и ROW LEVEL SECURITY.
Часть 3. GROUPING SETS, CUBE, ROLLUP

После открытия своей платформы Internet.org для разработчиков в мае, компания Facebook потребовала, чтобы любой сервис, использующий его, передавал данные без шифрования. Спустя пять месяцев ситуация изменилась — теперь шифрование можно использовать без всяких проблем, и миллионы пользователей из развивающихся стран смогут работать с сервисами наподобие Twitter, с использованием шифрования.

Часть миссии Internet.org — создание бесплатной платформы для веб-сервисов развивающихся стран. Благодаря сотрудничеству с различными операторами связи, платформа обеспечивает пользователям бесплатный доступ к некоторым сетевым сервисам. Никакой оплаты Internet.org не взимает. При этом подобное положение вещей уже критиковали некоторые поклонники концепции сетевой нейтральности, утверждая, что у подобных приложений — огромное преимущество по сравнению с обычными программами-конкурентами.

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

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

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

Wired пишет, что скрыть повышенный уровень выброса вредных веществ было просто. Как происходит лабораторное тестирование? Машину ставят на ролики, нажимают на газ, колеса крутятся, двигатель работает, выхлоп анализируется. Какое единственное отличие между таким режимом и обычной ездой по трассе? Правильно, руль не двигается. То есть достаточно ввести единственное условие: никто не крутит руль, а машина едет — значит мы на станции техосмотра. Такой «хак» можно было обнаружить только случайно — что, собственно, и произошло.

Опять же, пока историю не рассказали до конца, разницу в выхлопе можно считать как намеренным действием автоконцерна (а точнее узкой группы людей, ответственной за управляющий код), так и простой ошибкой. Может это быть ошибкой? Да вполне. В сегодняшнем дайджесте самых важных новостей с сайте Threatpost.ru за неделю — истории о том, как ошибки происходят, как ими пользуются, и как на них делают деньги. Все предыдущие выпуски тут.

Runkit 1.0.4 для PHP выпущен!

Поздравляю всех пользователей Runkit с новым долгожданным мега-релизом! Если вы постоянно используете Runkit и хорошо знакомы с его возможностями, историей и развитием, то можете сразу переходить к описанию изменений релиза 1.0.4. В любом случае предлагаю прочесть статью целиком.

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Предисловие от автора оригинала:

В марте 2011 я написал черновик статьи про то, как команда, отвечающая за Google Chrome, разрабатывает и выпускает свой продукт — после чего я благополучно о нем забыл. Лишь несколько дней назад я случайно наткнулся на него. Пусть местами он уже устарел (Chrome форкнул WebKit в Blink в 2013 году, да и я сам больше не работаю в Google), я склонен считать, что изложенные в нем идеи все еще в силе.

Сегодня я собираюсь рассказать вам о том, как работает Chromium. Нет, речь пойдет не совсем о браузере Chrome, а скорее о Chromium — группе людей, занимающихся созданием браузера.

Над проектом Chromium работают сотни инженеров. Вместе мы коммитим в кодовую базу примерно 800 изменений каждую неделю. Мы также зависим от многих других больших и активно развивающихся проектов вроде V8, Skia и WebKit.

Мы отправляем новый стабильный релиз сотням миллионов пользователей каждые шесть недель, четко по расписанию. И мы поддерживаем несколько других каналов раннего доступа, которые обновляются еще быстрее — самый быстрый канал, canary, «тихо» авто-обновляется почти каждый будний день.

Каким образом все это продолжает работать? Почему «колеса» у этого «автобуса» еще не «отвалились»? Почему еще не все разработчики сошли с ума?

Незамеченным на Хабре остался инцидент с выпуском сертификата для доменов google.com и www.google.com удостоверяющим центром компании Symantec. Об этом сообщается в блоге «корпорации добра».

Сертификат был выпущен 14 сентября примерно в 19:20 (GMT) удостоверяющим центром Thawte (принадлежит компании Symantec) без разрешения или запроса со стороны Google. Причем не простой сертификат, а Extended Validation (EV). Таким образом, это первый зафиксированный случай нелегального выпуска EV сертификата.

Всем привет.

Какое-то время назад я видел в небезызвестном блоге пост о том, как реализовать на Go простую программу, работающую с БД, а затем сделать на её базе целый REST-сервис. Я решил проверить, насколько сложно сделать аналогичную программу на Rust и поделиться результатами.



Мы начнём с работы с БД и создадим обычное консольное приложение, а затем добавим, так сказать, REST-фронтенд.

Здравствуйте, меня зовут Дмитрий Карловский и я… антиконформист, то есть человек, который не держится за свои привычки и всегда готов их поменять, если в том есть необходимость. Например, как и многие разработчики, я начинал изучение баз данных с реляционных. Хотя реляционная алгебра и довольно красива в своей простоте, я постоянно ловил себя на мысли, что пытаюсь впихнуть круглую фигуру в квадратное отверстие и получалось как-то не герметично.



Нет, я не буду рассказывать вам про MongoDB или ещё какую неполноценную «убийцу SQL». Статей на тему «SQL vs NoSQL» сравнивающих на самом деле реляционные субд с документными и так полно:

• MongoDB или как разлюбить SQL
• Реляционные базы данных обречены?
• NoSQL базы данных: понимаем суть
• Почему нужно 1000 раз подумать, прежде чем использовать noSQL
• SQL — гибок или почему я боюсь NoSQL
• NoSQL и Big Data – обман трудящихся?
• Чем поможет архитектору «NoSQL» и… поможет ли?
• Сравнение производительности MongoDB vs PostgreSQL. Часть I: No index
• Сравнение производительности MongoDB vs PostgreSQL. Часть II: Index
• Разбираем ACID по буквам в NoSQL
• Почему вы никогда не должны использовать MongoDB
• Почему мы выбрали MongoDB
• Недостатки RDBMS или RDBMS vs NoSQL
• Почему вы никогда не должны говорить «никогда»
• Еж с ужом в одной корзине, а также немного об отсутствии схемы
• Почему реляционные СУБД отлично подходят для стартапов: Пример из истории разработки мессенджера Kato
• Прощай, MongoDB, здравствуй, PostgreSQL

Но у большинства из них есть фатальный недостаток — авторы просто не в курсе, что моделей данных в СУБД есть куда больше, чем два упомянутых: от узкоспециализированных «словарей», то универсальных «графов». А популярные «реляционные» и «документные» находятся лишь где-то по середине между универсальностью и специализированностью.

Давайте сравним типичных представителей упомянутых типов СУБД (от большего к меньшему).

• Популярность: Oracle, MongoDB, Redis, HBase, OrientDB.
• Функциональность: OrientDB, Oracle, MongoDB, HBase, Redis.
• Скорость: очень сильно зависит от задачи, данных и реализации приложения. Я пересмотрел кучу бенчмарков, везде всё по разному.

Всем привет! Меня зовут Андрей, я работаю в отделе разработки продуктов Veeam Software.

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



Сегодня я хочу рассказать свою историю.

Итак, начну с момента, когда мне исполнился 21 год, я уволился из рядов доблестной российской армии и оказался на серых и холодных улицах Санкт-Петербурга. Осень, отсутствие жилья и денег активировали все клетки головного мозга для ответа на вопрос: «Что делать?».

Ничто не предвещало беды, как оборвалось подключение к Skype. С подобной проблемой столкнулась и другие пользователи, многочисленные жалобы посыпались в Twitter.

По данным сервиса DownDetector, проблема возникла в 11:23 по Москве. Неполадки затронули пользователей не только из России, но и США, Великобритании, Канады, Индонезии, Румынии и другие страны.

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

UPD2:
Техподдержка Skype написала в своем Twitter-аккаунте:
«Мы работаем над решением этой проблемы и надеемся, что обновления будут доступны для вас в ближайшее время», – говорится в сообщении разработчиков.

We are aware of an issue affecting Skype status at the moment, and are working on a quick fix: http://t.co/ymSzmrgEX0 pic.twitter.com/8LoqqL0hh7

— Skype Support (@SkypeSupport) 21 сентября 2015

UPD3:
При этом веб-версия Skype работает: https://web.skype.com/en/

Привет!

Осталась неделя до конференции RailsClub. Мы уже планируем, как будем встречать и развлекать приглашенных спикеров, печатаем для всех участников классные наклейки, вместе с докладчиками репетируем их выступления. Самое время зарегистрироваться, если вы вдруг еще не успели. Сделать это можно тут.
Сегодня новое интервью, на вопросы ответил наш коллега Александр Кириллов, Ruby-разработчик из Evrone, со-организатор конференции Юкон в Саратове.

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

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

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

Привет, Хабр!

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

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

Для старта достаточно клонировать сборник себе и начать описывать реализацию, все оставльное уже есть. Есть готовые входящие данные для задач, есть FB класс, который позволяет уйти от var_dump() или print_r(). Все есть, поставил и сразу можно выполнять задачи — без лишней суеты. Надеюсь, кому-нибудь это окажется нужным.

После того, как у меня появился новый монитор на рабочем месте, я начал новую итерацию улучшения своего «безмышечного» (mouse-less, прим. пер.) опыта. Вы же знаете, что это значит, не так ли? Это значит, что каждый раз, когда вы беретесь за мышку, убирая руку с клавиатуры, вы тратите немного времени и энергии. Если вам нужно набирать много текста (а я много пишу кода), это становится существенным.

Так же существует следующий уровень «безмышечного» опыта, когда вы стараетесь избежать труднодоступных клавиш, например Delete, Backspace, Escape или даже Enter.

Если вы держите руки в стандартной позиции для 10-пальцевой слепой печати, более удобно нажать Ctrl-m вместо того, чтобы тянуться мизинцем к энтеру.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Добрый день, Хабрахабр.

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

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

Всем привет! Меня зовут Андрей Новиков и в последнее время я работаю над проектом по разработке приложения, которое используется в разных частях нашей страны и автоматизирует работу людей. В каждом конкретном часовом поясе нашему приложению необходимо правильно получать, сохранять и отображать время, причём как в прошлом, так и в будущем – например, рассчитать начало рабочей смены и так же правильно его отображать: отсчитать время до конца смены, показать, сколько люди ехали до точки назначения и определить, уложились ли они в норматив, в также многое-многое другое.



За те уже несколько лет, что я пишу на Ruby on Rails, мне не приходилось сталкиваться с подобными проблемами — до этого все мои приложения работали в одном часовом поясе. А тут неожиданно пришлось немало попотеть, отлавливая самые разные ошибки и пытаясь выяснить, как же работать с датой и временем так, чтобы их в дальнейшем избежать.

В результате, сегодня мне есть, чем с вами поделиться. Если вы регулярно встречаетесь с тем, что время сохраняется или отображается некорректно с характерным разбросом в несколько часов (3 часа для Москвы), какие-то ночные записи перекочёвывают на соседние дни, а время упорно отображается не так, как хотят пользователи, и вы не знаете, что со всем этим делать — добро пожаловать под кат.