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

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

 P.P.S. Очень много текста внутри. 

Главархив Москвы принимает у москвичей фотоплёнки и киноплёнки, чтобы сохранять их на долгие годы. Плюс: сдать исторические материалы можно в центрах госуслуг «Мои документы». Минус: сразу возникает очень неприятная ситуация с авторским правом.

Машина

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

Однако с этим я согласиться никак не могу. Программирование по содержанию ничуть не сложней многих других отраслей знаний, а в чем-то даже и легче, особенно когда касается прикладных задач. Наткнулся на заметку человека, который высказал весьма небанальную мысль: при обучении программированию "с нуля" этот "ноль" для всех сильно разный. И у меня есть стойкое убеждение, что сложность освоения четко зависит от значения этого нуля. А вот почему он разный и что на него влияет- мне и хотелось бы поразмышлять.

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

Недавно мой один знакомый подарил мне старую SD карту памяти фирмы «Canon» на 128 МБ, которую нашёл где-то на улице. Её вполне мог кто-нибудь просто выкинуть, так как обычному пользователю ей очень сложно найти применение в современных технических условиях. Объём 128 МБ по нынешним временам считается очень малым, да и в смартфон её не вставишь ввиду большого размера. В основном распространены карты памяти microSD, которые вставляются в большинство смартфонов, но были также ещё и miniSD. Карты памяти малого объёма (MMC 8 МБ, 16 МБ) я встречал лет 20 назад в miniDV видеокамерах. Они там использовалась в качестве дополнительного носителя для сохранения фотографий.

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

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

Разумеется, язык С имеет много существенных отличий от языка С++, т.е. не составит никакого труда привести примеры несовместимостей, основанные, скажем, на ключевых словах или других очевидных эксклюзивных свойствах С99. Таких примеров вы не найдете в списке ниже. Мой основной критерий для включения примеров в этот список заключался именно в том, что пример кода должен выглядеть на первый взгляд достаточно "невинно" для С++-наблюдателя, т.е. не содержать бросающихся в глаза С-эксклюзивов, но тем не менее являться специфичным именно для языка С.

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

• Простота. Стажёр или студент, приходя к нам, может уже через неделю написать и отправить в продакшен новый микросервис.
• Надёжность. Многие ошибки, в том числе и связанные с многопоточностью, можно поймать на этапе компиляции. Кроме того, фреймворк даёт подсказки по исправлению проблем.
• Полнота. В userver есть всё необходимое для тестирования, работы с разными базами данных, кеширования, логирования, трейсинга, распределённых блокировок, работы с JSON, BSON, YAML, изменения параметров сервиса на лету и так далее.

Однажды я подбирал себе новый монитор и немного увлёкся — получилось чудище во всю стену из трёх телевизоров с ядерной 2318-зональной подсветкой 40 000 люмен на STM32.

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

5 лет назад мы форкнули Manticore из open source версии некогда популярного open source поискового движка Sphinx 2.3.2. У нас было два пакетика травы, семьдесят пять ампул мескалина, три C++ разработчика, один саппорт-инженер, опытный пользователь, менеджер, мать пятерых детей, помогающая нам на полставки и гора багов, крэшей и технических долгов. И вот, по прошествии 5 лет и сотен новых пользователей мы готовы сказать, что Manticore можно использовать как альтернативу Elasticsearch и для полнотекстового поиска и для аналитики данных.

В этой статье хочется: вспомнить как всё начиналось и что было до SOLR и Elasticsearch, максимально объективно обрисовать текущую ситуацию, попытаться понять куда нам двигаться дальше.

За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.

Всякий раз дискуссия выходит к одним и тем же ответам:

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

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

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

В чём проблема GIF?