В среду в Госдуму внесен законопроект, который вводит особый правовой режим для «новостных агрегаторов» — интернет-ресурсов с посещаемостью более 1 миллиона в сутки, которые собирают, обрабатывают и распространяют информацию.

Реестр таких ресурсов будет вести Роскомнадзор. Проект обязывает новостные агрегаторы «проверять достоверность распространяемой общественно значимой информации». За публикацию недостоверной информации предусмотрено внесудебное «принятие мер по пресечению распространения недостоверной информации» по жалобе уполномоченных органов.

Новостной агрегатор должен быть российским юридическим лицом. Доля иностранного капитала в нем не должна превышать 20%. На приведение структуры компании в соответствие с новыми требованиями дается 6 месяцев.

Компания должна будет хранить опубликованную информацию в течение полугода.

За отказ удалить недостоверную информацию по требованию Роскомнадзора новостной агрегатор будет обязан выплатить штраф – от 400 тысяч рублей для физических лиц и до 5 миллионов рублей для юридических лиц.

По словам одного из авторов проекта Алексея Казакова (фракция «Справедливая Россия»), «новостные агрегаторы» должны «ответственно» подходить к информации: либо перепечатывать авторитетные СМИ, которые проверяют информацию, либо нести ответственность за перепечатку. «Агрегаторы по влиятельности превосходят СМИ. Но мы не хотим создать им условия для некомфортной работы, поэтому право обратиться в Роскомнадзор даем только профильным ведомствам, а не гражданам», рассказал он «Коммерсанту».

Член фракции КПРФ Александр Ющенко подтвердил изданию, что вносит законопроект в Госдуму совместно с господином Казаковым. Он сослался на социологические исследования, по которым около 60% пользователей черпают новости не через традиционные СМИ, а в поисковых программах и агрегаторах. «Такие ресурсы определяют новостную повестку, ранжируя новости. Эта функция требует той же ответственности, как у СМИ», полагает он. Ведь недостоверность информации может быть связана и с «ангажированным размещением новостей» в топах. Кроме того, по его словам, иностранные социальные сети Twitter, Facebook в других странах уже тестируют собственные новостные сервисы, поэтому такая деятельность требует регулирования российскими законами.

По словам источника в Госдуме, под действие проекта подпадут до 30 крупных компаний: «Яндекс», Mail.ru, Google, Rambler, «ВКонтакте», «Спутник», Facebook, Twitter и другие.

49,8% акций Mail.ru приходится на держателей глобальных депозитарных расписок, которые торгуются на LSE; 27,6% — у MIH Mail Investment Company BV (принадлежит южноафриканскому медиахолдингу Naspers); 15,2% — у New Media and Technology Investment L.P. и аффилированных с ней структур; 7,4% — у китайской инвесткомпании Tencent.

В пресс-службе «Яндекса» «Коммерсанту» сообщили, что сервис «Яндекс.Новости» просто не сможет существовать, если возложить на ресурс работу по проверке новостей. «Каждый день «Яндекс.Новости» индексирует более 100 тысяч новостных сообщений от почти 7 тысяч источников. У «Яндекс.Новостей» нет редакции, сервис автоматически собирает сообщения от партнеров и в том же виде показывает их заголовки и фрагменты. Полные тексты новостей новостной агрегатор «Яндекса» не публикует — читатели переходят по ссылкам на сайты партнеров.

Основным акционером является руководитель группы компаний «Яндекс» Аркадий Волож, его голосующая доля — 39,81%, экономическая — 10,84%, еще 7% голосов и 4% капитала у сотрудника «Яндекса» Владимира Иванова. У инвестора компании, группы фондов Baring Vostok, которые управляют в том числе пенсионными и университетскими деньгами США, стран Западной Европы и Азии,— 15,55% голосов и 4,69% капитала.

Получается, что для интернет-агрегаторов предлагается установить те же самые правила, что и для СМИ с иностранным капиталом. В октябре 2014 года президент Владимир Путин подписал постановление о поправках к закону «О СМИ».

Согласно новым поправкам, с января 2016 года иностранцам запрещено напрямую или косвенно владеть более 20% любого российского СМИ. Поэтому теперь иностранные инвесторы могут либо покинуть российский рынок, либо реорганизовать бизнес так, чтобы он соответствовал новым требованиям.

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

ссылка на оригинал статьи https://megamozg.ru/post/24330/

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

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

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

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

Но у Эллен это не получается. Возможно, у вас тоже (и это нормально).

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

(1) Обеспечьте возможность легко с вами связаться

Гораздо легче ответить согласием на просьбу при личной встрече, чем публично на каком-либо случайном мероприятии. Требуется только пара минут, чтобы просмотреть /coffee page на сайте.

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

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

(2) Поставьте цель: Провести один нужный разговор

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

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

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

(3) Знайте свои ограничения и устанавливайте правила

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

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

Чтобы избежать такого поворота, Эллен попыталась выработать определённые правила и следовать им. Самое лучшее, что она придумала – всегда оставаться дома в пятницу вечером. Это даёт достаточно времени, которое можно провести в одиночестве. Если в пятницу она остается дома, то в субботу будет в состоянии хорошо и продуктивно поработать, вечером посетить светские мероприятия, в воскресенье расслабиться, а в понедельник вернуться в офис с новыми силами.

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

P.S. Рекомендуем ещё одну полезную статью по теме работы над собой — 9 коммуникативных навыков, которыми должен обладать любой успешный лидер.

Автор перевода — Давиденко Вячеслав, основатель компании TESTutor.

ссылка на оригинал статьи https://megamozg.ru/post/24320/

Регистрация на конференцию PG Day’16 в разгаре, а мы продолжаем публиковать перевод статей Hubert Lubaczewski об explain и его основных компонентах.

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

Самая базовая операция – это последовательное сканирование (Seq Scan).

Она выглядит вот так:

explain analyze select * from pg_class;                                                QUERY PLAN                                                 ---------------------------------------------------------------------------------------------------------  Seq Scan on pg_class  (cost=0.00..10.92 rows=292 width=202) (actual time=0.009..0.049 rows=295 loops=1)  Total runtime: 0.249 ms (2 rows) 

Это самая простая операция из всех возможных – PostgreSQL открывает файл с таблицей, читает строки одну за другой и возвращает их пользователю или расположенному выше узлу дерева explain, например, LIMIT, как здесь:

explain analyze select * from pg_class limit 2;                                                  QUERY PLAN                                                   -------------------------------------------------------------------------------------------------------------  Limit  (cost=0.00..0.07 rows=2 width=202) (actual time=0.014..0.014 rows=2 loops=1)    ->  Seq Scan on pg_class  (cost=0.00..10.92 rows=292 width=202) (actual time=0.009..0.009 rows=2 loops=1)  Total runtime: 0.132 ms (3 rows) 

Важно понимать, что порядок возврата строк не является каким-то определенным. Они возвращаются не «в порядке вставки» или «последняя обновленная строка – первой», или ещё что-то в том же духе. Параллельные выборки, обновления, удаления, чистки (vacuums) могут менять порядок следования строк в любое время.

Seq Scan может фильтровать строки – то есть отбрасывать некоторые при возврате. Это происходит, например, когда вы добавляете условие “WHERE":

explain analyze select * from pg_class where relname ~ 'a';                                                QUERY PLAN                                                 ---------------------------------------------------------------------------------------------------------  Seq Scan on pg_class  (cost=0.00..11.65 rows=227 width=202) (actual time=0.030..0.294 rows=229 loops=1)    Filter: (relname ~ 'a'::text)    Rows Removed by Filter: 66  Total runtime: 0.379 ms (4 rows) 

Как вы видите, теперь у нас появилась информация “Filter:”. И, поскольку у меня версия СУБД 9.2 или новее, я также получил комментарий «Строки удалены фильтром» (“Rows removed by filter").

Следующий тип узла — “Index Scan".

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

explain analyze select * from pg_class where oid = 1247;                                                           QUERY PLAN                                                            -------------------------------------------------------------------------------------------------------------------------------  Index Scan using pg_class_oid_index on pg_class  (cost=0.15..8.17 rows=1 width=202) (actual time=0.007..0.007 rows=1 loops=1)    Index Cond: (oid = 1247::oid)  Total runtime: 0.077 ms (3 rows) 

Всё просто – у нас есть индекс, соответствующий условию, так что PostgreSQL:

• открывает индекс;
• в индексе, если находит, где (в данных таблицы) могут быть строки, соответствующие данному условию:
  
  • открывает таблицу;
  • получает строку(-и), указанную(-ые) индексом;
• если строки могут быть возвращены – то есть, если они видимы в текущей сессии – они возвращаются.

Конечно, вы можете спросить: как строка может быть невидимой? Это может случиться с удаленными строками, которые всё ещё находятся в таблице (не были вычищены vacuum). Или со строками, которые были обновлены. Или были вставлены, но после текущей транзакции.

Index Scan также используется, когда вы хотите отсортировать какие-то данные, используя порядок сортировки в индексе, например:

explain analyze select * from pg_class order by oid limit 10;                                                                QUERY PLAN                                                                 -----------------------------------------------------------------------------------------------------------------------------------------  Limit  (cost=0.15..1.67 rows=10 width=206) (actual time=0.017..0.029 rows=10 loops=1)    ->  Index Scan using pg_class_oid_index on pg_class  (cost=0.15..44.53 rows=292 width=206) (actual time=0.014..0.026 rows=10 loops=1)  Total runtime: 0.145 ms (3 rows) 

Здесь нет условия, но мы легко можем его добавить вот таким образом:

explain analyze select * from pg_class where oid > 1247 order by oid limit 10;                                                                QUERY PLAN                                                                ----------------------------------------------------------------------------------------------------------------------------------------  Limit  (cost=0.15..4.03 rows=10 width=206) (actual time=0.021..0.035 rows=10 loops=1)    ->  Index Scan using pg_class_oid_index on pg_class  (cost=0.15..37.84 rows=97 width=206) (actual time=0.017..0.031 rows=10 loops=1)          Index Cond: (oid > 1247::oid)  Total runtime: 0.132 ms (4 rows) 

В этих случаях PG находит начальную точку отсчета в индексе (либо первую строку, которая старше 1247, либо просто самую маленькую величину в индексе), а потом просто возвращает следующие строки/значения, пока условие Limit не будет удовлетворено.

Есть версия Index Scan под названием “Index Scan Backward", которая делает то же самое, но используется для сканирования в порядке по убыванию:

explain analyze select * from pg_class where oid < 1247 order by oid desc limit 10;                                                                    QUERY PLAN                                                                     -------------------------------------------------------------------------------------------------------------------------------------------------  Limit  (cost=0.15..4.03 rows=10 width=206) (actual time=0.012..0.026 rows=10 loops=1)    ->  Index Scan Backward using pg_class_oid_index on pg_class  (cost=0.15..37.84 rows=97 width=206) (actual time=0.009..0.022 rows=10 loops=1)          Index Cond: (oid < 1247::oid)  Total runtime: 0.119 ms (4 rows) 

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

Ещё одна схожая операция — “Index Only Scan".

Давайте создадим простую таблицу:

create table test (id serial primary key, i int4); CREATE TABLE   insert into test (i) select random() * 1000000000 from generate_series(1,100000); INSERT 0 100000   vacuum analyze test; VACUUM 

Это даёт нам таблицу вроде этой:

select * from test limit 10;  id |     i      ----+-----------   1 | 546119592   2 | 253476978   3 | 235791031   4 | 654694043   5 | 187647296   6 | 709050245   7 | 210316749   8 | 348927354   9 | 120463097  10 |   5611946 (10 rows) 

Здесь у меня есть индекс по id:

\d test                          Table "public.test"  Column |  Type   |                     Modifiers                      --------+---------+---------------------------------------------------  id     | integer | not null default nextval('test_id_seq'::regclass)  i      | integer |  Indexes:     "test_pkey" PRIMARY KEY, btree (id) 

Так что, если определенные условия выполняются (чуть позже расскажу об этом подробнее), я могу получить вот такой план:

explain analyze select id from test order by id asc limit 10;                                                              QUERY PLAN                                                              ------------------------------------------------------------------------------------------------------------------------------------  Limit  (cost=0.29..0.55 rows=10 width=4) (actual time=0.039..0.042 rows=10 loops=1)    ->  Index Only Scan using test_pkey on test  (cost=0.29..2604.29 rows=100000 width=4) (actual time=0.036..0.038 rows=10 loops=1)          Heap Fetches: 0  Total runtime: 0.092 ms (4 rows) 

Обратите внимание на слово “Only" в “Index Only Scan".

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

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

Сложность в том, что для корректной работы, Index должен содержать информацию о том, что данные строки находятся на страницах, не подвергавшихся изменениям «в последнее время». То есть, для использования Index Only Scans ваша таблица должна быть хорошо вычищена с помощью vacuum. Но, с запущенным autovacuum это не должно стать проблемой.

Последний тип сканирования таблицы – так называемый Bitmap Index Scan. Он выглядит вот так:

explain analyze select * from test where i < 100000;                                                  QUERY PLAN                                                   -------------------------------------------------------------------------------------------------------------  Bitmap Heap Scan on test  (cost=4.37..39.99 rows=10 width=8) (actual time=0.025..0.110 rows=13 loops=1)    Recheck Cond: (i < 100000)    ->  Bitmap Index Scan on i1  (cost=0.00..4.37 rows=10 width=0) (actual time=0.013..0.013 rows=13 loops=1)          Index Cond: (i < 100000)  Total runtime: 0.154 ms (5 rows) 

(если вы читаете внимательно, то заметили, что он использует индекс, о создании которого я ранее не говорил. Это легко сделать: create index i1 on test (i);).

Bitmap Scans всегда состоят, минимум, из двух узлов. Сначала (на нижнем уровне) идет Bitmap Index Scan, а затем – Bitmap Heap Scan.

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

Допустим, в вашей таблице 100000 страниц (это около 780MB). Bitmap Index Scan создаст битовую карту, где каждой странице вашей таблицы будет соответствовать один бит. Так что, в этом случае мы получим блок памяти на 100,000 бит ~ 12.5 кБ. Все эти биты будут установлены в 0. Затем, Bitmap Index Scan установит некоторые биты в 1, в зависимости от того, на какой странице таблицы может находиться строка, которую нужно вернуть.

Эта часть вообще не затрагивает данные в таблице. После того как это будет сделано – то есть когда все страницы, на которых находятся строки, которые нужно вернуть, будут «помечены» – эта битовая карта перейдет на уровень выше, к узлу Bitmap Heap Scan, который читает их в более последовательной манере.

В чем смысл такой операции? Обычные Index Scans вызывают случайные операции ввода/вывода – страницы с диска загружаются в случайном порядке. А это медленно. По крайней мере, на вращающихся дисках.

Последовательное сканирование быстрее, когда нужно получить одну страницу, но, с другой стороны, вам не всегда нужны все страницы.

Bitmap Index Scans объединяет оба случая: когда вам нужно много строк из таблицы, но не все, и когда строки, которые вы будете возвращать, находятся не в одном блоке (что было бы оправдано, если бы я производил операцию “… where id < …"). У сканирований битовых карт есть ещё одно интересное свойство – они могут объединять две операции или два индекса, как в этом примере:

explain analyze select * from test where i < 5000000 or i > 950000000;                                                        QUERY PLAN                                                        ------------------------------------------------------------------------------------------------------------------------  Bitmap Heap Scan on test  (cost=107.36..630.60 rows=5323 width=8) (actual time=1.023..4.353 rows=5386 loops=1)    Recheck Cond: ((i < 5000000) OR (i > 950000000))    ->  BitmapOr  (cost=107.36..107.36 rows=5349 width=0) (actual time=0.922..0.922 rows=0 loops=1)          ->  Bitmap Index Scan on i1  (cost=0.00..12.25 rows=527 width=0) (actual time=0.120..0.120 rows=491 loops=1)                Index Cond: (i < 5000000)          ->  Bitmap Index Scan on i1  (cost=0.00..92.46 rows=4822 width=0) (actual time=0.799..0.799 rows=4895 loops=1)                Index Cond: (i > 950000000)  Total runtime: 4.765 ms (8 rows) 

Здесь мы видим два сканирования Bitmap Index (их может быть больше), которые потом объединяются (но не так, как при операции “JOIN" в SQL!) с помощью BitmapOr.

Как вы помните, вывод Bitmap Index Scan – это битовая карта (блок памяти с единицами и нулями). Имея несколько таких битовых карт, вы можете легко производить на них логические операции: Or, And или Not.

Здесь мы видим, что две таких битовых карты были объединены с помощью оператора Or, и получившаяся битовая карта была передана в Bitmap Heap Scan, который загрузил подходящие строки из таблицы.

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

alter table test add column j int4 default random() * 1000000000; ALTER TABLE alter table test add column h int4 default random() * 1000000000; ALTER TABLE create index i2 on test (j); CREATE INDEX create index i3 on test (h); CREATE INDEX 

А вот что получается:

explain analyze select * from test where j < 50000000 and i < 50000000 and h > 950000000;                                                        QUERY PLAN                                                        ------------------------------------------------------------------------------------------------------------------------  Bitmap Heap Scan on test  (cost=280.76..323.61 rows=12 width=16) (actual time=2.295..2.352 rows=11 loops=1)    Recheck Cond: ((h > 950000000) AND (j < 50000000) AND (i < 50000000))    ->  BitmapAnd  (cost=280.76..280.76 rows=12 width=0) (actual time=2.278..2.278 rows=0 loops=1)          ->  Bitmap Index Scan on i3  (cost=0.00..92.53 rows=4832 width=0) (actual time=0.546..0.546 rows=4938 loops=1)                Index Cond: (h > 950000000)          ->  Bitmap Index Scan on i2  (cost=0.00..93.76 rows=4996 width=0) (actual time=0.783..0.783 rows=5021 loops=1)                Index Cond: (j < 50000000)          ->  Bitmap Index Scan on i1  (cost=0.00..93.96 rows=5022 width=0) (actual time=0.798..0.798 rows=4998 loops=1)                Index Cond: (i < 50000000)  Total runtime: 2.428 ms (10 rows) 

Три сканирования Bitmap Index Scan, каждое из которых использует свой индекс, битовые карты объединены с помощью битовой операции “and", и результат скармливается Bitmap Heap Scan.

Если вы интересуетесь, почему BitmapAnd показывает “Actual rows = 0", ответ прост: этот узел вообще не имеет дела со строками (только битовая карта страниц диска). Так что он не может вернуть строки.

На этом пока всё. Это все возможные сканирования таблицы – способы, которыми вы получаете данные с диска. В следующий раз я расскажу об объединении разных источников данных и других видах планов.

Ещё больше полезной информации о PostgreSQL вы сможете получить, зарегистрировавшись на конференцию PG Day’16. Чем ближе конференция, тем дороже билеты, поэтому спешите приобрести их по выгодной цене!

ссылка на оригинал статьи https://habrahabr.ru/post/276973/

Всем привет!

Мы задержались с очередной сборкой — всплыли довольно неприятные регрессии, побороть которые получилось не сразу. Но мы не зря собирались всем дружным коллективом в Исландии в начале февраля. Получив заряд бодрости от суровой исландской природы, мы не только справились с регрессиями, но и приготовили для вас много новинок. Об этом — чуть подробнее ниже.

Управление сессиями

По многочисленным настойчивым просьбам пользователей мы добавили в браузер менеджер сессий. Найти соответствующие пункты меню можно в меню Файл:

Работает функция вполне привычно. Указав в открывшемся диалоге название сохраняемой сессии:

В дальнейшем вы сможете через то же меню и открыть сохранённый ранее набор вкладок:

Как вариант, вы можете открывать сохранённую ранее сессию и через диалоговое окно быстрых команд, вызываемое клавишей F2, введя в поле поиска слово «сессия». Кстати, это пока единственный способ открыть сохранённую сессию для пользователей Mac OSX — в вашей версии браузера в меню Файл данный пункт появится в следующих сборках.

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

Оптимизация процесса запуска браузера

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

Масштаб для отдельных вкладок

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

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

Контроль за использованием памяти

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

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

Пока данная функция будет радовать только пользователей Windows и Mac OSX, но вскоре мы добавим аналогичную возможность и в Linux (она там на самом деле уже есть, но почему-то не хочет работать — выясняем причину).

Индикатор загрузки фоновых страниц

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

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

CSS отладчик

А эта новинка придётся по вкусу веб-разработчикам. Мы внедрили в код браузера расширение Pesticide CSS layout debugger, и вы можете использовать его, включив соответствующую опцию в Эффектах страницы:

А теперь немного о новой бете

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

На этом всё. Загрузить новую сборку можно по ссылкам ниже:

• Windows 32-bit
• Windows 64-bit (экспериментальная)
• Mac 10.7+
• Linux RPM 32-bit
• Linux RPM 64-bit
• Linux DEB 32-bit
• Linux DEB 64-bit

Полный список изменений:

• VB-77 Session save/load/import missing
• VB-8706 Noisy and slow startup: more work to be done
• VB-2876 Make option for per tab zoom behaviour: see settings
• VB-12290 Add «Hibernate background tabs» option: not available on Linux yet
• VB-9429 Background tab progress indicator does not work
• CSS Debugger added to page actions: pesticide.io
• VB-12824 [Windows] Random crash when closing context menus
• VB-9327 [Linux] [Mac] Impossible to initiate mouse gestures on speed dial page
• VB-2663 [Mac] Missing Swipe Back/Forward Gestures
• VB-8583 [Mac] Change keyboard shortcuts using «Option» key: not normally used as a modifier in this way on Mac
• VB-12825 [Mac] Remove icons from main menu: native OSX apps never have this
• VB-12840 [Mac] Youtube fullscreen seems broken
• VB-12566 [Mac] Lack of rounded corners
• VB-12823 [Mac] Main menu is not always updated after all windows are closed
• VB-11620 [Regression] Up/Down arrow keys do not move cursor in text of Notes and Bookmarks
• VB-12850 [Regression] Cannot rename bookmark folders in side tab
• VB-12970 [Regression] Bookmarks bar resets to root
• VB-12902 [Regression] Navigation button menus do not always show up
• VB-12822 [Regression] Write Your First Note message not shown
• VB-12624 Modifiers + the scroll wheel doesn’t work
• VB-12767 Bookmark is slow with many bookmarks (delete and edit halts the browser)
• VB-12906 Extension popup does not work correctly with ui-zoom
• VB-13176 Bookmark bar drag’n’drop fix: further work needed
• VB-2328 There should be no references to Vivaldi Cloud Print
• VB-12675 Nickname on bookmarks doesn’t work when it matches autocompletion
• VB-3177 Ctrl+Shift+V double-pastes
• VB-12014 Auto complete typed search missing
• VB-11294 Permission settings (notifications, geolocation and media) not retained after browser restart
• VB-13076 Tweak tab stack design slightly
• VB-12547 Find in Page cannot be closed
• VB-12675 Nickname on bookmarks doesn’t work when it matches autocompletion
• VB-13051 Close tab sometimes fails
• VB-12828 Restore button shows «maximize» icon
• VB-12860 Gap in tabbar when addressbar is not at top
• VB-12657 Speed Dial should be relative for tab opening
• VB-12739 Add «Right of current tab» in tab settings for a Close tab
• VB-10608 Lazy tabs doesn’t work after minimize/restore
• VB-12932 Tab stacks barely visible with «Color Behind Tabs»
• VB-12927 All Tab Stacks are shown as Unread
• VB-11548 Pocket extension doesn’t work
• VB-12382 In addressfield the ending ‘/’ is stripped from URL
• VB-5303 Note attached picture not displayed
• VB-9704 After renderer crash refreshed page is not active
• VB-12283 No stack indicator when tab bar at the bottom
• Fast forward not checking all locales
• Prevent Quick Commands position changes on vertical resize
• Improved history autocomplete test

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

ссылка на оригинал статьи https://habrahabr.ru/post/277893/

У зарубежных компаний история с ИТ-инфраструктурой очень простая: они как росли себе на Западе, так там всё и осталось. В России, как правило, нет даже инженеров, а все сервисы предоставляются откуда-нибудь из Ирландии, Франкфурта, Бостона или других городов, где находится головная организация и её дата-центры.

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

Сложностей море, например, такие:

• Полное отсутствие ИТ-персонала в российском офисе, занимающегося миграцией систем и управлением всего проекта в целом — нужно общаться с сетевиками из Европы или США и разработчиками, например, из Шанхая.
• Мало поднять прокси-структуру — нужно реально по факту обрабатывать данные в России. А, значит, в Москве (или в другом городе, но, как правило, действие происходит в столице) должен быть развёрнут инстанс CMS, почты, прикладного ПО для работы с продажами, бухгалтерия и так далее.
• Нужно перевезти всё это быстро и без существенных простоев, а потом ещё и поддерживать в плане инфраструктуры (приклад в данном случае поддерживают «родные» ИТ-команды).

Постановка задачи

Во-первых, было довольно сложно сформировать точное техзадание. Да и вообще понять, что и как нужно сделать. Специфика очень простая — в России находится офис, который занимается коммерцией, а не ИТ. И если для нас CMS, ERP, документооборот и почтовый сервер — разные вещи, то с точки зрения менеджера — это одна и та же система. Поэтому российский представитель компании выступал исключительно в качестве юр.лица, с которым подписывался контракт. Абсолютно все переговоры происходили с зарубежными коллегами. Даже договор был на двух языках. Их спецы в начале приезжали на экскурсию в наши дата-центры: их вице по ИТ в качестве гостей, наши топы — в роли экскурсоводов.

Во-вторых, география. Площадка и администраторы в одном часовом поясе, разработчики в другом, мы — в третьем. Языкового барьера не было, к счастью, весь ИТ-мир говорит на английском, и даже с китайской стороной никаких непониманий не возникало.

В-третьих, надо было понять, что такое ПД внутри их инфоообмена, то есть подключить юристов. В итоге юристы сделали заключение, что ПД для этой компании — любые данные, по которым можно идентифицировать человека. Туда попало хранение и обработка ФИО, фотографий, разные косвенные признаки типа места работы с указанием должности, адреса аккаунтов в соцсетях. При этом адреса твиттера с никнеймами — не ПД. Кстати, небольшой ликбез мы не так давно сами проводили.

Очень хорошо, что у нас было много исходных данных. История про переезд такая: чем меньше входных данных у тебя есть — тем дороже решение. Закладываешь самый дорогой продукт, который все умеет, самые дорогие лицензии — но можно не выиграть конкурс, потому что заказчику цена не понравится. Мы потратили свое время — показали, что можем разобраться. И получилось куда дешевле для заказчика.
В итоге были сформированы первичные задачи переноса и вторичные по сертификации-аттестации. История в том, что регулятор сначала будет смотреть компании с иностранным происхождением — где у них данные. Если за границей – блокировку сделать можно гораздо быстрее, чем перенести системы. И уже второй вопрос, требующий более глубокого вдумчивого копания — аттестация элементов системы. В нашей практике никто эти вопросы разом не решает. Сначала переезд, потом проверка всего на местах, уже потом остальное. Это два разных проекта.

Часть А — переезд — заняла полгода от первого контакта.

Этапы

Сначала мы предоставили тестовую зону из нескольких виртуальных машин, на которые заказчик выполнял так называемый proof of concept. КРОК выполнял задачу провайдера инфраструктуры — серверы, системы хранения, сеть.

Представители заказчика делали тестовые переносы, проверяя, как устанавливается соединение, с какой скоростью передаются данные, как разворачивать системы внутри того, что мы предоставляем. Грубо говоря, изучали инструментарий.

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

Инфраструктура

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

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

Самый простой случай — схема бекапа

Полезный урок по сбору данных

На первый взгляд проект кажется достаточно простым — мол делов-то собрать тут то же, что есть у заказчика в Европе. У заказчика эти сервисы ещё и в разных дата-центрах, плюс они сразу же захотели оценить последующую модернизацию — и все эти требования не всегда хорошо ложатся на «просто перенос», надо объяснять и выяснять.

Выявление требования к инфраструктуре и согласование техзадания заняло половину времени заказа, то есть почти три месяца. Удалось очень хорошо сэкономить время за счёт того, что мы смогли составить специальные опросники в виде списка закрытых вопросов («да»/«нет» или 3-5 вариантов) — чтобы четко получать информацию от заказчика. До этого был на похожем переезде опыт с открытыми вопросами — и ответы были такие, что пришлось заходить ещё на две итерации. Здесь же мы получили довольно много информации изначально и могли предлагать свои варианты.

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

Плюс местные особенности, конечно. Например, сроки мы согласовывали с боями — зарубежные коллеги не всегда представляют актуальные сроки доставки оборудования. Не понимают, что не всегда можно привезти что-то конкретное в РФ. Цены не как у них — у нас они вообще другие, и то, что в Европе дороже, может оказаться у нас дешевле. Или наоборот.

Чем мы были удивлены, так это их идеальной скрупулезностью во всём, что касается существующих стандартов и правил, написанных часто лет 10 назад. У них всё это работает на честные 100 процентов, а не на 20-80, как мы это часто видим внутри России. У нас любое правило стандарта рассматривается как некая полезная рекомендация. У них — как железный барьер.

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

Ещё мы не всегда видели их структуру: на этапе общения ты даже не всегда знаешь, с кем конкретно общаешься. И думаешь — ок, договорились, завтра дадут требования. А этот человек в Ирландии, железо в Америке, там своя ИТ-команда, с которой он ещё должен всё согласовать, а они должны показать проект тимлиду команды в Китае. Пока письмо с ответом пройдет — минимум двое суток из-за часовых поясов. Много отдельных бизнес-подразделений, и у каждого техподразделения свои хотелки, особенно на будущее. Согласование с 10 людьми в копии — совершенно нормально.

Или вот вообще чумовой пример: обновить прошивку роутера — у нас решает ИТ-главный, а у них все эти 10 человек сразу, причём туда входят и разработчики приклада.

Внедряли собственными силами, позже заказчик обратился к нам и за сопровождением не только на уровне инфраструктуры, но и на уровне операционок.

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

Итог

Договорились про даунтайм на переключение, перенесли за 32 часа (большая часть даунтайма — окончательная синхронизация данных и тесты продакшна), согласовав работы всех команд. Сейчас система уже несколько месяцев работает без нареканий. Кратко история прошла так: монтаж железа, сборка, проверки, накатывание инфраструктурного софта, поднятие виртуализации, первоначальная настройка, сопровождение и внедрение их систем, ещё тесты — дальше включалась команда заказчика. Иногда они просили нас помогать по своим задачам, например, на тестах производительности приклада мы ковыряли вместе с ними, искали узкие места в инфраструктуре. У нас много всяких услуг, всё же по ИТ-инфраструктурам мы по России первые. Вот они всем этим смело и пользовались к общему счастью. Их сетевики заглядывали в проект всего лишь пару раз, и то, когда были просадки на международных каналах, всё остальное время никто, кроме прикладников, в эксплуатации не участвует. После внедрения 2 недели мы были в режиме усиленной поддержки, то есть каждый день обсуждали с их спецами статусы и мелкие доработки. Сейчас предоставляем инфраструктуру: серверы, системы хранения, сети, балансировщики, устройства ИБ, виртуализация, систему резервного копирования. Плюс все это в режиме отказоустойчивости резервируется во второй дата-центр, за счет чего SLA составляет 99,9% для всех уровней инфраструктуры.

Ссылки

• Экскурсия по нашему дата-центру T-III «Компрессор» (T3 проект, T3 объект, Т3 эксплуатация)
• Миграция данных одного банка
• Распределённые системы хранения данных (часть программно-определяемого дата-центра)
• Моя почта — RSayfutdinov@croc.ru

ссылка на оригинал статьи https://habrahabr.ru/post/277891/