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

Мол, какой-то девайс, фреймворк или способ работы резко поднимает успешность предприятия. Например, «мы все используем MacBook, и у нас уже третий раунд инвестиций». Или «мы решили открыть travel-агентство, и нанимаем только тех программистов, которые не вылезают из путешествий; мы хотим, чтобы все сотрудники разделяли наши ценности, и у нас уже оборот 100 млн долларов». Или «как только мы внедрили React + Vue + Angular, наши дела пошли в гору, и нас купил Google». И так далее.

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

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

Сегодня мы хотим поделиться с вами переводом их рассказа о сильных и слабых сторонах платформ Node и Crystal, и о том, почему в Duo всё больше серверных проектов переводится на Crystal.

Это перевод обзора статьи «MemC3: Compact and Concurrent MemCache with Dumber Caching and Smarter Hashing» Fan et al. в Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI’13), pdf тут

Чуваки (бывший гугловец, чувак из университета Карнеги Меллон и еще один из Интел лабс) сделали улучшенный Memcached-совместимый кеш (по факту просто допилили мемкеш), и у них классные результаты производительности. Мне очень понравился обзор этой статьи в блоге "The morning paper" — описание алгоритмов и прочее.

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

Ниже — забавный проект, в котором собраны примеры неожиданного поведения в Python с обсуждением того, что происходит под капотом. Часть примеров не относятся к категории настоящих WTF?!, но зато они демонстрируют интересные особенности языка, которых вы можете захотеть избегать. Я думаю, это хороший способ изучить внутреннюю работу Python, и надеюсь, вам будет интересно.

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

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

PyTorch — современная библиотека глубокого обучения, развивающаяся под крылом Facebook. Она не похожа на другие популярные библиотеки, такие как Caffe, Theano и TensorFlow. Она позволяет исследователям воплощать в жизнь свои самые смелые фантазии, а инженерам с лёгкостью эти фантазии имплементировать.

Данная статья представляет собой лаконичное введение в PyTorch и предназначена для быстрого ознакомления с библиотекой и формирования понимания её основных особенностей и её местоположения среди остальных библиотек глубокого обучения.

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

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

Одна из главных проблем при написании крупных (относительно) программ на Python — минимизация потребления памяти. Однако управлять памятью здесь легко — если вас вообще это волнует. Память в Python выделяется прозрачно, управление объектами происходит с помощью системы счётчиков ссылок (reference count), и память высвобождается, когда счётчик падает до нуля. В теории всё прекрасно. А на практике вам нужно знать несколько вещей об управлении памятью в Python, чтобы ваши программы эффективно её использовали. Первая вещь, надо хорошо в ней разбираться: размеры основных объектов в Python. И вторая вещь: как устроено управление «под капотом» языка.

Начнём с размеров объектов. В Python есть много примитивных типов данных: целые числа (int), long (версия int с неограниченной точностью), числа с плавающей запятой (они же числа с двойной точностью, double), кортежи (tuple), строковые значения, списки, словари и классы.

Это принципы разработки ПО, взятые из книги Clean Code Роберта Мартина и адаптированные для PHP. Это руководство не по стилям программирования, а по созданию читабельного, многократно используемого и пригодного для рефакторинга кода на PHP.

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

Статья вдохновлена clean-code-javascript.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

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

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

Купили ли вы уже себе новый MacBook или MacBook Pro? А может, Google Pixel? Вы находитесь на пороге путаницы, благодаря этим новым портам «USB-C». Этот простецкий на вид порт таит в себе вселенскую путаницу, и благословенная обратная совместимость использует различные кабели для различных задач. Покупателям придётся очень аккуратно выбирать себе кабель!

USB Type-C: порты и протоколы

Порты USB Type-C распространились достаточно широко, Google начал использовать их на своих компьютерах и телефонах Pixel и Nexus, Apple применяет их на 12" MacBook, а теперь ещё и на новых MacBook Pro. Это физическая спецификация для 24-контактного двустороннего штекера и соответствующих кабелей. В этой статье я буду называть этот физический кабель и порт «USB-C», как наиболее часто используемый термин. Google сообщает, что этот порт называют «USB-C» 21 миллион раз, «USB C» 12 миллионов раз, а правильно, «USB Type-C», всего 8,5 миллионов раз.

Внезапно ваш диск под завязку забит фотографиями и видео, а впереди новые поездки. Что делать, покупать новый, арендовать дисковое пространство на облаке, или может лучше сжать видео файлы через ffmpeg?

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

Всё началось, как это часто бывает, когда моя машина стала подтормаживать. На рабочем компьютере Windows 10 c 24-ядерным процессором (48 потоков), который на 50% простаивал. Из 64 ГБ памяти использовалось меньше половины. Быстрый SSD тоже не особо использовался. И всё же, когда я двигал мышкой, курсор реагировал не сразу — иногда с задержкой в несколько секунд.

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

Трассировка ETW показала, что UI зависает во многих программах. Я решил исследовать 1,125-секундное зависание в Диспетчере задач:

Старые методы по-прежнему работают

[Обновление] Теперь я в каком-то списке спецслужб, потому что написал статью про некий вид «бомбы», так?

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

Когда я в возрасте 13 лет впервые захостил свою маленькую Linux-коробочку с доступом по SSH, я смотрел логи и каждый день видел IP-адреса (в основном, из Китая и России), которые пытались подключиться к моей сладенькой маленькой коробочке (которая на самом деле была старым ноутом ThinkPad T21 со сломанным дисплеем, жужжавшим под кроватью). Я сообщал эти IP их провайдерам.

На самом деле если у вас Linux-сервер с открытым SSH, то можете сами посмотреть, сколько попыток подключений происходит ежедневно:

grep 'authentication failures' /var/log/auth.log

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

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

Несмотря на то, что динамическая адаптация видеопотока уже сравнительно «старая» технология, существует множество мелких подробностей о том, как добиться лучшего результата. Чтобы и на серверной стороне попроще и подешевле, и чтобы такое видео было совместимо с как можно большим количеством клиентов (Web, iOS, Android, ну и не забываем про Smart TV).

Как известно, в основной реализации Питона CPython (python.org) используется Global Interpreter Lock (GIL). Эта штука позволяет одновременно запускать только один питоновский поток — остальные обязаны ждать переключения GIL на них.

Коллега Qualab недавно опубликовал на Хабре бойкую статью, предлагая новаторский подход: создавть по субинтерпретатору Питона на поток операционной системы, получая возможность запускать все наши субинтерпретаторы параллельно. Т.е. GIL как бы уже и не мешает совсем.

Идея свежая, но имеет один существенный недостаток — она не работает…

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

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


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