Илья Космодемьянский ( hydrobiont )

Для начала сразу пару слов о том, о чем пойдет речь. Во-первых, что такое оптимизация запросов? Люди редко формулируют и, бывает так, что часто недооценивают понимание того, что они делают. Можно пытаться ускорить какой-то конкретный запрос, но это не обязательно будет оптимизацией. Мы немного на эту тему потеоретизируем, потом поговорим о том, с какого конца к этому вопросу подходить, когда начинать оптимизировать, как это делать, и как понять, что какой-то запрос или набор запросов никак нельзя оптимизировать – такие случаи тоже бывают, и тогда нужно просто переделывать. Как ни странно, я почти не буду приводить примеров того, как запросы оптимизировать, потому что даже 100 примеров не приблизят нас к разгадке.

В этой статье я расскажу о проблеме безопасности в технологии блокчейн в свете роста производительности квантовых компьютеров, разберу некоторые методы защиты от атак с применением квантового компьютера и о недавно появившемся проекте: Quantum-Resistant Ledger. Как заявляют разработчики, это будет первая в мире платформа, построенная на принципах постквантового шифрования и предназначенная для обеспечения защиты от «квантового удара» на случай быстрого развития этих технологий. Такому удару могут быть подвергнуты платформы, построенные с использованием классических принципов шифрования. Без фундаментальных изменений Bitcoin, Ethereum, Ardor и большинство подобных платформ в недалеком будущем могут оказаться в уязвимости.

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



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

(Начальное название статьи «Алгоритм работы протокола SSH» было изменено по рекомендациям Vindicar, Karroplan и других участников хабросообщества)

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Please Stop Using Local Storage" автора Randall Degges.

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

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

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

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


Автор материала, перевод которого мы публикуем сегодня, собирается обсудить распространённые ошибки, которые совершают программисты при работе с Git, и поговорить о том, как с этими ошибками бороться.

Друзья, с позиции главы программного комитета Frontend Conf поместил под катом краткий обзор шести самых полезных докладов с РИТ++ 2018 по фронтенду.

В подборке нашлось место рассказу про то, как настраивать PWA-приложения и делать их более нативными. Отдельно затронуты вопросы транспиляции, где на примере API Яндекс.Карт показано, как можно писать на ES2015, получая на выходе ES3, и обеспечить поддержку IDE и линтеров. Еще одна история — про популярные форматы хранения изображений, их сжатие и варианты загрузки на мобильные устройства. Не менее хардкорный доклад про то, как перенести нагрузку, связанную с расчетом анимации, с CPU на видеокарту. Плюс два отдельных доклада про секреты и лайфхаки CSS.

Все доклады — сугубо практические, а некоторые — вполне холиварные. Одним словом, именно такие, как мы любим, и отбираем для Frontend Conf Moscow.

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

Думаю, эта статья будет полезна тем, кто уже знаком с основами фреймворка Ruby on Rails и хочет начать разрабатывать плагины для Redmine.

Прежде всего, стоит разделить все плагины Redmine на две категории:

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

Все немного сложнее, когда плагин должен изменять встроенную функциональность!

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Приветствую всех и особенно тех кто интересуется задачами дискретной математики и теорией графов.

Предыстория

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

В конце июня компания VMware опубликовала программы конференций VMworld 2018 US и VMworld 2018 EU, которые пройдут в августе и ноябре соответственно. Одной из ключевых тем конференций является создание корпоративных блокчейнов на платформе VMware.

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

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

Tренду NoSQL уже почти 10 лет, и можно смело делать какие-то выводы и обобщения. Этим и займемся, поговорим про развитие NoSQL.

Вспомним, как родился NoSQL. Посмотрим, что в нем хорошо, а что плохо, и что выдержало испытание временем. Разберем возможности, которые уже есть в SQL, и которые теперь появляются в NoSQL СУБД. Выделим уникальные ценности NoSQL, и заглянем чуть-чуть вперед в то, что на рынке будет завтра.

А поможет нам в этом Константин Осипов (@kostja) — разработчик и архитектор СУБД Tarantool, который в своем докладе на РИТ++ 2017 говорил про тренды NewSQL, ведь архитектору полагается понимать, что происходит в мире баз данных, чтобы, как минимум, не изобретать велосипед.


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

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

Почему bash?

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

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

Предисловие

Данное руководство сопровождает ShellHarden, но автор также рекомендует ShellCheck, чтобы правила ShellHarden не расходились с ShellCheck.

Bash — не тот язык, где самый правильный способ решить проблему одновременно является самым простым. Если принимать экзамен по безопасному программированию в bash, то первое правило BashPitfalls звучало бы так: всегда используй кавычки.

Главное, что нужно знать о программировании в bash

Маниакально ставить кавычки! Незакавыченная переменная должна расцениваться как взведённая бомба: она взрывается при контакте с пробелом. Да, «взрывается» в смысле разделения строки на массив. В частности, расширения переменных вроде $var и подстановки команд вроде $(cmd) подвергаются расщеплению слов, когда внутренняя строка расширяется в массив из-за расщепления в специальной переменной $IFS с пробелом по умолчанию. Это обычно незаметно, потому что чаще всего результатом становится массив из 1 элемента, неотличимый от ожидаемой строки.

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

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

Далее, я часто занимаюсь анализом трудоемкости алгоритмов. Размеры наборов данных, подвергаемые обработке в наши дни, просто колоссальны. В 2010 году на конференции Techonomy Эрик Шмидт сказал, что объем данных, создаваемых сегодня человечеством всего за два дня, равен объему всех существовавших в мире данных по состоянию на 2003 год. Мне важно уметь обрабатывать большие сегменты этих объемов и извлекать из них пользу. И в этом смысле понимание пространственно-временной сложности операций, применяемых нами к данным есть ключ к определению того, возможны ли те или иные вычисления в принципе. В отличие от более традиционных видов O-анализа или тета-анализа постоянные множители в таких масштабах оказывают существенное влияние: множитель 2 не меняет асимптотическую временную сложность алгоритма, но потребует увеличения количества процессоров с 10 тыс. до 20 тыс., и такая разница в потреблении ресурсов будет ощутима. В результате вычисления становятся более изощренными. Примеры: могу ли я взять некое линейное вычисление и снизить его в силе до логарифмического? Можно ли снизить потребление памяти в три раза? И так далее.

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

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

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

Пристегни ремни.

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

Это программа – компьютерный червь. Червь был написан, судя по всему, между 2005 и 2010 годами. Поскольку этот червь является таким сложным, я могу дать лишь общее описание того, что он делает.

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

Я расскажу про инструменты разработки, сам ЯП, процесс добавления UI и еще много интересного. В конечном итоге мы получим обычный сайт-визитку, но "под капотом" он будет работать на умных контрактах Ethereum. Кого заинтересовало — прошу под кат.

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

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