Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

Я часто становлюсь участником длительных и жарких дебатов на тему статической типизации против динамической. Сам я определенно отношу себя к сторонникам статической типизации, но эта статья не о достоинствах статической типизации. Цель статьи — устранить распространённое заблуждение насчет статически типизированных языков.

Церемонность

Люди, которые предпочитают динамически типизированные языки статически типизированным, часто подчеркивают тот факт, что отсутствие церемонности делает их продуктивнее. Это звучит логично, однако, это ложная дихотомия.

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

Всем доброго здравия!

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

1. Mall Customers Dataset — данные посетителей магазина: id, пол, возраст, доход, рейтинг трат. (Вариант применения: Customer Segmentation Project with Machine Learning)
2. Iris Dataset — датасет для новичков, содержащий размеры чашелистиков и лепестков для различных цветков.
3. MNIST Dataset — датасет рукописных цифр. 60 000 тренировочных изображений и 10 000 тестовых изображений.
4. The Boston Housing Dataset — популярный датасет для распознавания паттернов. Содержит информацию о домах в Бостоне: количество квартир, стоимость аренды, индекс преступлений.
5. Fake News Detection Dataset — содержит 7796 записей с разметкой новостей: правда или ложь. (Вариант применения с исходником на Python: Fake News Detection Python Project )
6. Wine quality dataset — содержит информацию о вине: 4898 записей с 14 параметрами.

Viewport

1. Первое поколение
   
   • SCCS (Source Code Control System)
   • RCS (Revision Control System)
2. Второе поколение
   • CVS (Concurrent Versions System)
   • SVN (Apache Subversion)
3. Третье поколение
   • Git
   • Mercurial

Небольшая заметка о встраиваемой key-value БД под названием Coffer, написанной на Golang. Если совсем коротко: в остановленном состоянии БД данные лежат на диске, при запуске данные копируются в память. Чтение происходит из памяти. При записи изменяются данные памяти, а изменения записываются в журнал на диск. Максимальный размер хранимых данных ограничен размером оперативной памяти. API позволяет создавать хидеры для записей БД и применять их в транзакциях, сохраняя при этом консистентность данных.

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

Сразу пишу к чему пришёл в ходе изысканий:

1. ИП на ПСН
2. поступление оплаты за услуги по разработке ПО на счёт ИП в долларах США
3. основание для оплаты инвойс, сумма которого не превышает 200 000 руб.
4. инвойсы выставляются по-мере необходимости
5. ККТ не используется

То есть, спокойно работаю, в конце оговоренного периода формирую инвойс, в котором указываю согласованную с работодателем сумму не превышающую указанный порог, получаю деньги прямо на расчётный счёт, оплачиваю раз в год или в течение года патент и взносы в размере 54 000 рублей и больше не переживаю о том, что завтра злобные налоговики придут ко мне с повесткой и ужасными новостями (это была минутка юмора). В следующем году эта сумма подрастёт до 60 000 рублей за год.

Почему так? Какие могут быть ещё варианты? Чем плохи для меня Upwork, PayPal и Payoneer? Попробую ответить под катом. Кому интересны все эти детали, читаем дальше :-)

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

Как только вы переступаете через болевой порог Борроу-Чекера и осознаёте, что Rust позволяет вытворять невообразимые (и порой опасные) в других языках вещи, вас может постигнуть настолько же непреодолимое желание Переписать Всё на Rust. Хоть и в лучшем случае это банально непродуктивно (бессмысленное разбазаривание усилий на несколько проектов), а в худшем — приводит к уменьшению качества кода (ведь с чего вы считаете себя более опытным в области применения библиотеки, чем её изначальный автор?)

Гораздо полезнее будет предоставить безопасный интерфейс для оригинальной библиотеки, повторно используя её код.