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

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

В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.

Дизайнеры, с которыми я работаю, часто рассматривают сообщения об ошибках в iOS как что-то очевидное. А если конкретно – как UIAlertController.

Подстрахуй братуху, подстрахуй...

В ZFS 0.8 появилась возможность отправлять инкрементные снимки зашифрованных данных не расшифровывая. То есть имея зашифрованный массив, можно организовать его зеркальную копию на удалённой машине, не доверяя владельцу удалённого помещения. Ключ и расшифрованные данные не покидают доверенное помещение.

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

Любой сервис в виде виртуальной машины ставится на Proxmox, где данные размещены на ZFS, и у вас всегда будет возможность хранить удалённую копию виртуальной машины. Есть шанс, что в один прекрасный день вместо впадания в уныние вы съездите в удалённое помещение, заберёте железяку и запустите все службы в полном здравии. Я уже перевёл почти все свои сервисы на Proxmox около 2 лет назад и ни капли не жалею, всё отлично работает. На ZFS у меня работает терминальный сервер на 30 человек, на который завязаны тонкие клиенты (то есть 30 полноценных рабочих мест). Помимо актуальной копии у вас будут ещё и снапшоты за последние x дней и локально и удалённо.

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

Недавно поучаствовал в дискуссии на тему влияния на производительность указания длины в столбцах с типом nvarchar. Доводы были разумны у обеих сторон и поскольку у меня было свободное время, решил немного потестировать. Результатом стал этот пост.

Спойлер – не всё так однозначно.

Все тесты проводились на SQL Server 2014 Developer Edition, примерно такие же результаты были получены и на SQL Server 2016 (с небольшими отличиями). Описанное ниже должно быть актуально для SQL Server 2005-2016 (а в 2017/2019 требуется тестирование, поскольку там появились Adaptive Memory Grants, которые могут несколько исправить положение).

Нам понадобятся – хранимая процедура от Erik Darling sp_pressure_detector, которая позволяет получить множество информации о текущем состоянии системы и SQL Query Stress – очень крутая open-source утилита Adam Machanic/Erik Ejlskov Jensen для нагрузочного тестирования MS SQL Server.

О чём вообще речь

Вопрос, на который я стараюсь ответить – влияет ли на производительность выбор длины поля (n)varchar (далее везде просто varchar, хотя всё актуально и для nvarchar), или можно использовать varchar(max) и не париться, поскольку если длина строки < 8000 (4000 для nvarchar) символов, то varchar(max) и varchar(N) хранятся IN-ROW.

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



Иммутабельные структуры данных не меняют своих значений. Чтобы что-то с ними сделать, нужно создавать новые значения. Старые же значения остаются на прежнем месте, поэтому их можно без проблем и блокировок читать из разных потоков. В итоге ресурсы можно совместно использовать более рационально и упорядоченно, ведь старые и новые значения могут использовать общие данные. Благодаря этому их куда быстрей сравнить между собой и компактно хранить историю операций с возможностью отмены. Все это отлично ложится на многопоточные и интерактивные системы: такие структуры данных упрощают архитектуру десктопных приложений и позволяют сервисам лучше масштабироваться. Иммутабельные структуры — секрет успеха Clojure и Scala, и даже сообщество JavaScript теперь пользуется их преимуществами, ведь у них есть библиотека Immutable.js, написанная в недрах компании Facebook.

Под катом — видео и перевод доклада Juan Puente с конференции C++ Russia 2019 Moscow. Хуан рассказывает про Immer — библиотеку иммутабельных структур для C++. В посте:

• архитектурные преимущества иммутабельности;
• создание эффективного персистентного векторного типа на основе RRB-деревьев;
• разбор архитектуры на примере простого текстового редактора.

В этой статье я хочу поговорить о методах смешивания растеризуемой геометрии. Классические модели смешивания полупрозрачных объектов — Alpha, Additive, Multiplicative — объединяет один и тот же принцип отрисовки: последовательно рисуем один примитив за другим, смешивая получаемые на выходе фрагментного шейдера пиксели с тем, что находится в текущем буфере. Каждый новый примитив обновляет область буфера, в которую рисуется; в случае с альфа-смешиванием объекты, которые находятся выше, заслоняют ранее отрисованные. Но что если хочется что-то сделать с группой объектов, рисуемых поверх сцены, — например, обрезать их по маске или подсветить? Тут сразу в голову приходят два решения: или внести изменения в их материал (т.е. изменить шейдер, расширить набор текстур), к примеру, добавив проекцию еще одной текстуры, которая будет отвечать за маску прозрачности. Однако если у нас много разношерстных объектов, менять каждый уникальный материал неудобно и чревато ошибками. Второй вариант — нарисовать все интересующие нас объекты в отдельный полноэкранный таргет и рисовать уже его на финальную сцену. Тут мы можем сделать с его содержимым все, что захотим, но это требует выделения лишней памяти и, что самое неприятное, — переключения рендер таргетов. Это не самая «дешевая» операция на мобильных устройствах, которую будет необходимо выполнить дважды. А если захочется вот так работать с несколькими слоями?

В смысле, привет, Хабр! Если вы можете сказать про себя слово «интроверт» (как и я) то вас, скорее всего, можно заносить в эту категорию. Другое дело, что категория, мягко говоря, размыта. И в неё от души навалено сразу несколько синдромов.

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

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

А теперь давайте разбираться в деталях.

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

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

Под катом — видео и расшифровка моего доклада с конференции DotNext, где я разбираю несколько примеров, когда использование средств из стандартной библиотеки .NET (Task.Delay, SemaphoreSlim, ConcurrentDictionary) привело к просадкам производительности, и предлагаю решения, заточенные под конкретные задачи и лишённые этих недостатков.

Вчера хешрейт сети Биткоина мгновенно упал на 40 %, при этом по странному стечению обстоятельств произошло самое внушительное падение курса за последние недели. Мощность устройств сети обрушилась с 98 до 57.7 экзахеша за день, в стоимости криптовалюта потеряла более $1200 (около 13%). Интересно также, что всего несколько дней назад хэшрейт сети обновил исторический максимум и достиг значения 102 экзахешей в секунду. Достоверных сведений о причинах произошедшего пока нет. Неизвестно также связаны ли эти события. Под катом я изложил свои соображения, а также мнения экспертов и СМИ, освещающих тему криптовалют, о причинах явления, влиянии ситуации на майнинг биткоина и перспективы развития актива.
На момент написания статьи хэшрейт восстановлен до значений в 88,3 млн Тх/с.

Алан Кей — это магистр Йода для ИТишников. Он стоял у истоков создания первого персонального компьютера (Xerox Alto), языка SmallTalk и концепции «объектно-ориентированного программирования». Он уже много высказывался о своем взгляде на образование в сфере Computer Science и советовал книги тем, кто хочет углубить свои познания:

• Алан Кей: как бы я преподавал Computer Science 101
• Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
• Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
• Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»

Недавно на Quora опять подняли эту тему и обсуждение вышло на первое место на Hacker News. Предлагаю вашему вниманию «новый» список суперстарых и фундаментальных книг по программированию и мышлению программиста от Алана Кея.

Lisp 1.5 Programmers Manual

by John McCarthy, 1962



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

ещё восемь раритетов:

Материал этой статьи является следствием моих дизайн-экспериментов и выводов за последний год-полтора непрерывного дизайн гринда. Я неустанно собирал ui kit’ы, экспериментировал с контентом в плейсхолдерах, стилями, тенями текстами и состояниями, чтобы понять влияет ли это на конверсию. Иначе говоря, смогу ли я увеличить продажи дизайн-продуктов для Figma, если добавлю немного визуальной динамики в статичные дизайн-макеты, чтобы сделать темплейты интереснее и функциональнее.

Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

Генерация уровней в Unexplored 2

Мы очень гордимся генератором уровней игры Unexplored 2, это программа, отвечающая всем современным требованиям. В посте я расскажу о том, как создаются уровни игры.

Нам не пришлось заново изобретать велосипед. В Unexplored 1 мы уже создали техники, которые сильно повлияли на успех первой игры. Unexplored 2 просто продолжила начатое. Фундамент нашей технологии состоит из двух частей: мы применяем многоэтапную генерацию, которая почти имитирует процесс, очень похожий на работу живого дизайнера уровней. Поверх него мы используем технику под названием "циклическая генерация подземелий", которая гораздо лучше справляется с генерацией естественно выглядящих уровней, чем большинство стандартных приложений генеративного создания контента. В этом посте я расскажу о первом аспекте. Адаптация циклической генерации подземелий к Unexplored 2 будет темой будущего поста.

Имитация «человеческого» дизайна уровней

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

200 байт для управления состоянием React-компонентов

• React-хуки: это все, что нужно для управления состоянием.
• ~200 байт, min+gz.
• Знакомый API: просто пользуйтесь React, как обычно.
• Минимальный API: хватит пяти минут, чтобы разобраться.
• Написан на TypeScript, чтобы обеспечить автоматический вывод типов.

Главный вопрос: чем этот пакет лучше, чем Redux? Ну...

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

Любая борьба организма с инфекционным заболеванием — это попытки распознать сигнатуру угрозы и выработать контрмеры. В общем случае этот процесс ведётся до полного результата, то есть до выздоровления. Однако могут быть инфекции, которые:

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

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

Давайте сначала разберёмся с ликбезом, потом перейдём к путешествиям и списку действий.

Почему путешествия опасны?

Предположим, вы летите в Африку. Там есть повышенный риск жёлтой лихорадки. Простая вакцина обойдётся вам примерно в 1 500 рублей вместе с приёмом терапевта и услугами процедурного кабинета, вакцина более высокого уровня — в 3 000 рублей. Вылечиться от жёлтой лихорадки специализированными медикаментами нельзя (то есть можно только поддерживать ресурсы организма, пока он сам не справится), заболеть легко, летальность — около 10%, основной вектор — комары. Побочных эффектов у вакцины почти нет. Стоит вакцинация того? Наверное, да. Но решать вам.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

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

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

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

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

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

Как с этим жить — чтобы оставалось время на жизнь вне работы? И можно ли применить какие-то рабочие алгоритмы менеджмента в повседневной, бытовой жизни? 3 месяца назад я кардинальным образом поменял всю систему постановки задач и контроля за ними. Хочу рассказать, как я к этому пришёл и что в итоге получилось. Пьеса будет в 2 частях: в первой — немножко про, если так можно выразиться, идеологию. А вторая — целиком про практику.

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.