Квантовые компьютеры. С точки зрения традиционного программиста-математика.
Часть 1. Основы. Квантовый регистр.

О чем эта публикация

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

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

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

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

В данной статье разобран алгоритм монотонной кубической интерполяции, предложенный Фритчем и Карлосоном в работе [1].

На рисунке красным обозначен результат обычной кубической интерполяции Эрмита, а синим - монотонной, кругами - опорные точки траектории.

Примеры кода написаны на C++, исходники всей библиотеки лежат здесь. Также написана копия библиотеки на Java, исходники лежат здесь.

Изучение логических ошибок помогает в развитии критического мышления, необходимого во всех сферах жизни. School of Thought проделала отличную работу, описав 24 наиболее распространенные логические ошибки.

За последние 10 лет мне удалось чередовать работу тимлида команды разработки из 3–5 человек (или как сейчас принято называть — техлида, хотя грань между этими понятиями часто размыта) с должностью сениор‑разработчика: после первого 3-летнего опыта тимлидинга я так устал и «выгорел», что на следующие 5 лет вернулся в кодинг, после чего уже более осознанно сделал вторую итерацию и опять стал лидом. Сегодня, оглядываясь на себя 10 лет назад, понимаю, что это совершенно два разных человека. Буду рад, если мой опыт станет полезен новичку, только ступившему на путь тимлида, а также услышать фидбэк от коллег по цеху, обменяться мнениями, мыслями, идеями.

Итак, первый инсайт, разбивший мои начальные представления, я прочёл в книге Т.Демарко и Т.Листера «Человеческий фактор: Успешные проекты и команды».

Привет! Меня зовут Глеб Рыжаков, я научный сотрудник Сколтеха. Я занимаюсь математикой, а точнее, линейной алгеброй, и её приложениями к практическим задачам. Сегодня я расскажу вам о нашем исследовании, которое может помочь справиться с проблемой проклятия размерности, которая возникает во множестве статистических задач, включая машинное обучение.

Понятие «проклятие размерности» появилось в середине прошлого века в пионерской работе Ричарда Беллмана, посвященной методам решения сложных задач путём разбиения их на более простые подзадачи. Сегодня оно понимается в более общем смысле, а именно как экспоненциальный — O(n^d) — рост количества необходимых данных и, как следствие, количества памяти, необходимой для их хранения, с ростом размерности пространства d. Когда задачу можно свести к работе с многомерными массивами в общем случае комплексных чисел, удобно говорить о d-мерных тензорах и использовать достижения мультилинейной алгебры. Хорошая новость заключается в том, что там существует такая процедура, как тензорное разложение, которое в ряде случаев может помочь преодолеть проклятие размерности.

▍ Что мы на самом деле сравниваем, сравнивая языки программирования?

Всем привет.

Давно читаю хабр, давно и регулярно читаю статьи про правильное программирование.

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

TLDR: забейте на читабельность и выразительность. Стремитесь сделать ваш код хорошо работающим..

Вся история МЦСТ – с 90-х годов по настоящее время – является отличным примером того, как не нужно вести бизнес. Когда во главе компании стоят люди, абсолютно не смыслящие ни в архитектурах, ни в управлении, ни в оптимизации процессов, с абсолютным непониманием меняющейся мировой экосистемы, бросающиеся громкими заявлениями, за которыми ничего не стоит. Эти люди превратили возможно потенциально процветающий бизнес в компанию-паразит, пожирающую государственные средства, в ответ выдавая никому не нужный хлам по видом отечественных микропроцессоров. Процессор Эльбрус. Ахиллесова пята отечественной микроэлектроники. Сколько дифирамб было спето православными адептами этих процессоров… Сколько людей было введено в заблуждение самой политикой МЦСТ, через блоггеров выпуская свои байки об уникальной архитектуре Эльбрус, которой аналогов нет. И всё это не смотря на то, что в сети опубликовано достаточно материалов по разбору тупиковости архитектуры Эльбрус.

Принципы SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion) - это общепризнанные рекомендации, разработанные для улучшения сопровождаемости и читаемости исходного кода программного обеспечения. Однако их применение в сфере разработки игр часто оказывается сложным из-за уникальных особенностей этой области. Чтобы полностью оценить контекст, мы погрузимся в эти сложности и изучим альтернативные парадигмы проектирования, которые лучше подходят для динамичной природы разработки игр.

В 2017 году я начал изучать Java. И, чтобы как-то визуализировать результат трудов, я решил сделать десктопное приложение (функционал продублирован в Telegram боте).

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

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

Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.

Итак, четыре проблемы начинающего тимлида.

В левой руке Морфеуса лежит 7 синих и 3 красных таблетки, а в правой 5 синих и 8 красных. Вы закрываете глаза и берете таблетку — она оказывается красной, однако вы не знаете из какой руки ее взяли. Какова вероятность, что вы взяли ее из правой руки?

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Меня зовут Михаил, я юрист в сфере IT/IP и это моя первая статья на Хабре на юридическую тематику. Обычно я их публикую на своём сайте, но в этот раз она сильно затрагивает сообщество программистов, поэтому я решил поделиться ею и на Хабре тоже.

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

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

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

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

Дайджест про то, как и зачем учить математику, 
если ты взрослый

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