Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

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



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

Данная публикация не является полным разбором или анализом (не покрывает пакет java.util.concurrent). Это, скорее, справочник, который поможет начинающим разработчикам понять ключевые отличия одних коллекций от других, а более опытным разработчикам просто освежить материал в памяти.

Что такое Java Collections Framework?

Java Collection Framework — иерархия интерфейсов и их реализаций, которая является частью JDK и позволяет разработчику пользоваться большим количесвом структур данных из «коробки».

Базовые понятия

На вершине иерархии в Java Collection Framework располагаются 2 интерфейса: Collection и Map. Эти интерфейсы разделяют все коллекции, входящие во фреймворк на две части по типу хранения данных: простые последовательные наборы элементов и наборы пар «ключ — значение» (словари).

Прочитал еще одну статью про «психологические типажи разработчиков». И с меня хватит. Как всегда, в этой статье предлагают узнать себя в одном из антипаттернов «плохих парней», понять, что я врежу бизнесу и начать наконец «исправляться». Я вот узнал себя в каждом типе. Я и рок-звезда, и солдат, и некомпетентный, и мечу в менеджеры… Короче, все выглядит так, что каким бы разработчиком и человеком я ни мечтал быть, бизнес увидит здесь проблему.

Знаете что? Пусть катятся к черту.

Мы начали изучать Control Groups (Cgroups) в Red Hat Enterprise Linux 7 – механизм уровня ядра, позволяющий управлять использованием системных ресурсов, кратко рассмотрели теоретические основы и теперь переходим к практике управления ресурсами CPU, памяти и ввода-вывода.


Однако, прежде чем что-то менять, всегда полезно узнать, как все устроено сейчас.

Компьютеры – это «железо». И сегодня мы вернулись в исходную точку, в том смысле, что сейчас редко найдешь физический хост, на котором выполняется одна единственная задача. Даже если на сервере крутится только одно приложение, оно, скорее всего, состоит из нескольких процессов, контейнеров или даже виртуальных машин (ВМ), и все они работают на одном сервере. Red Hat Enterprise Linux 7 неплохо справляется с распределением системных ресурсов в таких ситуациях, но по умолчанию ведет себя как добрая бабушка, угощающая внуков домашним пирогом и приговаривающая: «Всем поровну, всем поровну».



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

Привет! Ниже — расшифровка видеозаписи выступления на митапе Apache Ignite сообщества в Петербурге 20 июня. Загрузить слайды можно по ссылке.

Есть целый класс проблем, с которыми сталкиваются начинающие пользователи. Они только что скачали себе Apache Ignite, запускают первые два-три-десять раз, и приходят к нам с вопросами, которые решаются схожим образом. Поэтому предлагаю создать чек-лист, который сэкономит вам много времени и нервов, когда вы делаете свои первые приложения на Apache Ignite. Мы поговорим о подготовке к запуску; как сделать так, чтобы кластер собрался; как запустить какие-нибудь вычисления в Compute Grid; как подготовить модель данных и код, чтобы можно было записать в Ignite свои данные и потом их успешно прочитать. И главное: как ничего не сломать с самого начала.

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

С точки зрения разработки, продолжение — это доведение до идеала и совершенства всего того, что ты думал про игру последние пару лет. И ещё новые механики. И ещё куча крутого контента.

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

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

Мне сообщили, что на новых компьютерах некоторые регрессиионные тесты стали медленнее. Обычное дело, такое бывает. Неправильная конфигурация где-то в Windows или не самые оптимальные значения в BIOS. Но в этот раз нам никак не удавалось найти ту самую «сбитую» настройку. Поскольку изменение значительное: 9 против 19 секунд (на графике синий — это старое железо, а оранжевый — новое), то пришлось копать глубже.

Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

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

То, о чём я хочу рассказать, было на самом деле. Или, может быть, моя история лишь основана на реальных событиях. А возможно всё это — выдумка.

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

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

Кого можно назвать «пиксельных шейдеров начальник и пикселов командир»? Дениса Радина, работающего в Evolution Gaming над фотореалистичными веб-играми с использованием React и WebGL: он известен многим как раз под именем Pixels Commander.

В декабре на нашей конференции HolyJS он выступил с докладом о том, как использование GLSL может улучшить работу с UI-компонентами по сравнению с «обычным джаваскриптом». А теперь для Хабра мы подготовили текстовую версию этого доклада — добро пожаловать под кат! Заодно прикладываем видеозапись выступления:

Что такое Open Compute Project (OCP)?
В России об этом известно довольно мало, в основном рекламные заявления о миллиардах экономии Facebook с помощью OCP.

Официально Open Compute Project — это сообщество, основанное Facebook, с целью создать наиболее оптимальную инфраструктуру для ЦоД с минимальной оглядкой на существующие варианты.

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

Стоит отметить, что результат получился очень неплох.

На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.

Часть I
Часть II
Часть III
Часть IV

Одна из глав книги "Код" Чарльза Петцольда посвящена проектированию блоков CPU и в начале главы описывается устройство, позволяющие суммировать наборы чисел, хранящихся в памяти. Спроектируем похожую схему в Logisim. Возьмем набор восьмиразрядных чисел и подключим его к мультиплексору, переход от одного числа к другому будем осуществлять с помощью счетчика, подключенного к выбирающему входу мультиплексора, а к выходу мультиплексора подключим сумматор и аккумулятор. В качестве тактового генератора будем использовать кнопку. Данные будут загружаться в аккумулятор при отпускании кнопки. Это осуществляется с помощью элемента НЕ, подключенного к кнопке. Про реализацию этих функциональных блоков в виде отдельных микросхем далее в статье.

Bitcoin-майнер от ASICMINER, производительностью ~2TH/s ^{(источник)}

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

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

У вас есть старенький (или не очень) компьютер с двумя сетевыми картами? Вам надоела реклама и лишние телодвижения для обхода блокировок? Вы не хотите с этим мириться? Тогда добро пожаловать под кат.

В декабре 2016 мой коллега kevteev сказал, что было бы неплохо замутить митап по постгресу в следующем году на площадке Avito. А незадолго до этого безопасники пригласили меня поучаствовать в нескольких CTF, в том числе одном Attack-Defence. И я ответил ему: “А почему бы не замутить постгресовый хакатон?”. И вот мы подготовили первое в России очное соревнование для специалистов по PostgreSQL, и сегодня я хочу пригласить на него вас.

Update 17.02.2019 — эта статья устарела. Пользоваться ей в 2019 году не стоит.

Зачем нужна автоматическая сборка проекта никому объяснять не надо.
В случае со сборкой проектов под Unity это особенно актуально, так как средненький проект, например, под WebGL собирается на рабочей машине 5-7 минут, полностью её завешивая.

Не так давно вышла версия Unity под Linux, что дало принципиальную возможность настроить автоматическую сборку при помощи Gitlab CI (которая основана на docker образах).

Я хочу поделиться своим опытом такой настройки.

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.