Филипп Володин Fil

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

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

Предлагалось сделать следующее:

Можете ли вы поверить, что с момента моего последнего списка инструментов прошло 6 лет? Инструменты изменились, многие из них доступны онлайн, но, честно говоря, для составления нового списка инструментов требуется ОЧЕНЬ МНОГО РАБОТЫ. Но я смог, вот список на 2020-2021 годы. Это инструменты в моей папке Utils. Я создал папку d:\dropbox\utils и добавил ее в свой PATH. Таким образом, он будет на всех моих компьютерах, и я могу мгновенно добраться до любого из них.

Это обновленный до версии 2020-21 мой список 2003, 2005, 2006, 2007, 2009, 2011 и 2014 годов, который в настоящее время включает все остальные мои списки. Я занимаюсь этим более 17 лет. Вау. Думаю, стоит тратить на это больше времени.

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

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

Эту статью написал наш коллега Скотт. Вот версия на английском. Ну а сам список под катом.

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

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

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.

Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.

Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.

Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.

Ага.

Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.

Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.

Об авторе

Антон Подкопаев является постдоком в MPI-SWS, руководителем группы слабых моделей памяти в лаборатории языковых инструментов JetBrains Research и преподавателем Computer Science Center.

Еще в 1979 году Лесли Лампорт в статье «How to make a multiprocessor computer that correctly executes multiprocess programs» ввел, как следует из названия, идеализированную семантику многопоточности — модель последовательной консистентности (sequential consistency, SC). Согласно данной модели, любой результат исполнения многопоточной программы может быть получен как последовательное исполнение некоторого чередования инструкций потоков этой программы. (Предполагается, что чередование сохраняет порядок между инструкциями, относящимися к одному потоку.)

Рассмотрим следующую программу SB:



В этой программе два потока, в каждом из которых первая инструкция — инструкция записи в разделяемую локацию (x или y), а вторая — инструкция чтения из другой разделяемой локации. Для этой программы существует шесть чередований инструкций потоков:

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

Изображение предоставлено автором. Основано на фотографии Патрика Томаса с Ансплэша

Это перевод статьи Дэвида Клира о методе ведения заметок Zettelkasten, благодаря которому немецкий социолог Никлас Луман написал более 70 книг и 400 научных статей. Стоит читать, если вы хотите создать собственную базу знаний, систематизировать идеи и перестать забывать важные мысли.

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

Руководитель сервиса для регистрации бизнеса 1С-Старт Александр Раптовский о том, как отменить судебное решение о блокировке статьи на Хабре, инициированное Роскомнадзором.


Кадр из фильма «С меня хватит!» (Falling Down), 1992

---

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

---

Привет, Хабр.

У меня тут случайно код на хаскеле получился быстрее аналогичного кода на C++. Иногда — на 40%.

(время работы, меньше — лучше, C++ снизу)

Что самое смешное — я собирал хаскель-код через LLVM-бекенд, но при этом сравнивал с GCC. Если сравнивать с clang (что вроде как логичнее), то всё становится ещё хуже для плюсов: почему-то на этой задаче clang проигрывает GCC в пару раз, и разница становится не 40%, а этак раза три. Впрочем, одна маленькая модификация C++-кода это поменяет.

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

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

Посмотрим, как этого можно достичь?

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

• Nim медленнее компилятора C двадцатилетней давности.
• C# в пять раз медленнее Java, которая оказывается вполне на уровне Rust.
• Go вровень с C.
• PHP быстрее питона (что оправдывает вторую часть заголовка).

Я мирно сидел на семинаре, слушал доклад студента о статье с прошлого CVPR и параллельно гуглил тему.

— К достоинствам статьи можно отнести наличие исходного кода….
Пришлось вмешаться:
— Наличие чего, простите?
— Э-э-э… Исходного кода…
— Вы его смотрели? 
— Нет, но в статье указано… 
(мать-мать-мать… привычно отозвалось эхо)
ㅡ Вы ходили по ссылке?

В статье, действительно, предельно обнадеживающе написано: “The code and model are publicly available on the project page …/github.io/...”, — однако в коммите двухлетней давности по ссылке значится вдохновляющее «Код и модель скоро выложим»‎:


Ищите и обрящете, стучите и откроется… Может быть… А может быть и нет. Я бы, исходя из печального опыта, ставил на второе, поскольку ситуация в последнее время повторяется ну уж о-о-очень часто. Даже на CVPR. И это только часть проблемы! Исходники могут быть доступны, но, к примеру, только модель, без скриптов обучения. А могут быть и скрипты обучения, но за несколько месяцев с письмами к авторам не получается получить такой же результат. Или за год на другом датасете с регулярными скайп-звонками автору в США не удается воспроизвести его результат, полученный в наиболее известной лаборатории в отрасли по этой теме… Трындец какой-то.

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

Кому интересно, что стало со студентом куда катится научный мир, в том числе по «вине»‎ глубокого обучения, добро пожаловать под кат!

Привет, Хабр!

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

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

Поучить английский

AJ Hoge. На его канале есть всё: от базовых слов до размышлений о важности языка тела в общении. Чувак пилит видосы уже много лет, материальчик накопился.

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

Qt — чрезвычайно мощный и удобный фреймворк для C++. Но у этого удобства есть и обратная сторона: довольно много вещей в Qt происходят скрыто от пользователя. В большинстве случаев соответствующая функциональность в Qt «магически» работает и это приучает пользователя просто принимать эту магию как данность. Однако когда магия все же ломается то распознать и решить неожиданно возникшую на ровном казалось бы месте проблему оказывается чрезвычайно сложно.

Эта статья — попытка систематизации того как в Qt «под капотом» реализована работа с потоками и о некотором количестве неочевидных подводных камней связанных с ограничениями этой модели.

Основы
Thread affinity, инициализация и их ограничения
Главный поток, QCoreApplication и GUI
Rendering thread
Заключение

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

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

• Ни одну программу нельзя «закрыть» на 100%.
• Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

Когда-то я собеседовался на должность C++ разработчика в одну приличную и даже известную контору. Опыт у меня тогда уже кое-какой был, я даже назывался ведущим разработчиком у тогдашнего своего работодателя. Но на вопросы о том, знаком ли я такими вещами, как DRY, KISS, YAGNI, NIH, раз за разом мне приходилось отвечать «Нет».

Собеседование я с треском провалил, конечно. Но упомянутые аббревиатуры потом загуглил и запомнил. По мере чтения тематических статей и книг, подготовок к собеседованиям и просто общения с коллегами я узнавал больше новых вещей, забывал их, снова гуглил и разбирался. Пару месяцев назад кто-то из коллег небрежно упомянул в рабочем чате IIFE в контексте C++. Я, как тот дед в анекдоте, чуть с печки не свалился и опять полез в гугл.

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

Общеизвестно, что семантика инициализации — одна из наиболее сложных частей C++. Существует множество видов инициализации, описываемых разным синтаксисом, и все они взаимодействуют сложным и вызывающим вопросы способом. C++11 принес концепцию «универсальной инициализации». К сожалению, она привнесла еще более сложные правила, и в свою очередь, их перекрыли в C++14, C++17 и снова поменяют в C++20.

Под катом — видео и перевод доклада Тимура Домлера (Timur Doumler) с конференции C++ Russia. Тимур вначале подводит исторические итоги эволюции инициализации в С++, дает системный обзор текущего варианта правила инициализации, типичных проблем и сюрпризов, объясняет, как использовать все эти правила эффективно, и, наконец, рассказывает о свежих предложениях в стандарт, которые могут сделать семантику инициализации C++20 немного более удобной. Далее повествование — от его лица.

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

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

Сегодня я расскажу: почему if constexpr не является заменой макросов, каковы «внутренности» работы структурного связывания (structured binding) и его «подводные» камни и правда ли, что теперь всегда работает copy elision и можно не задумываясь писать любой return. 

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

Несколько месяцев назад я упомянул в одном посте, что это миф, будто бы const помогает включать оптимизации компилятора в C и C++. Я решил, что нужно объяснить это утверждение, особенно потому, что раньше я сам верил в этот миф. Начну с теории и искусственных примеров, а затем перейду к экспериментам и бенчмаркам на реальной кодовой базе — SQLite.