В начале июня один из ведущих «Цинкового прода» разместил на Хабре резонансную статью «Какая ниша у языка и поможет ли PHP8 решить [его] насущные проблемы (спойлер: имхо, нет)». Незадолго до этого мы решили, что пора бы сделать доклад, зачем выбирать PHP, когда вокруг расцветают сто цветов языков. Эти вещи так совпали по времени, что захотелось устроить совместный эфир и обсудить нишу и перспективы языка — с разных точек зрения.


Подключайтесь к трансляции 18 июня в 20 часов по Москве — комментарии на ютубе обязательно попадут в выпуск. А может и с голосовым общением что придумаем.

В эфир придут:

• Постоянные ведущие подкаста «Цинковый прод» — Антон Околелов, Никита Васильченко и Олег Грицак.
• Максим Шамаев — автор докладов об опыте перевода древнего проекта на PHP 7, построении трассировки и логирования между микросервисами и готовящегося доклада «Зачем сегодня писать на PHP».
• Александр Майоров, много пишет про PHP и Python на портале Geekjob.

В предыдущей статье мы обсуждали, почему функциональное программирование это совсем не то, что распиарено, и что оно совершенно не противоречит ООП, так, что даже сам "Дядя Боб" пишет про хороший ФП дизайн порождающий хороший ООП дизайн программы (и наоборот).

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

Недавно мы пригласили в эфир "Цинкового прода" Алексея Лесовского из компании Data Egret. Разговор получился интересный и познавательный, поэтому предлагаю вашему вниманию расшифровку этого выпуска. Из-за внушительного объема пришлось разбить текст на части. Если лень ждать продолжения — можно просто послушать аудиоверсию здесь.

Всем привет, это сороковой выпуск подкаста "Цинковый прод", и с нами в студии постоянные ведущие Антон Околелов, Никита Васильченко и Грицак Олег.

Антон: Итак, у нас сегодня гость, Алексей Лесовский. Лёша, представься пожалуйста, кто ты, чем занимаешься и так далее.

Недавно в подкасте "Цинковый прод" мы обсуждали выгорание. Я решил структурировать некоторые мысли и оформить в виде статьи

История первая

Однажды, когда я еще был простым линейным разработчиком, я решил пофрилансить. Друг попросил доработать одну довольно хитрую систему, платил хорошо (мы договорились об оплате по часам), дедлайны особо не ставил, и я согласился. Ну а почему нет?

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

И вот я начал фрилансить по вечерам.

Сегодня хотел бы довести крайне интересный, но часто покрытый тайнами для обычных смертных программистов раздел базы данных (БД) — уровни изолированности транзакций. Как показывает практика, многие люди, связанные с IT, в частности с работой с БД, слабо понимают зачем нужны эти уровни и как их можно использовать себе во благо.

Немного теории

Сами транзакции особых объяснений не требуют, транзакция — это N (N≥1) запросов к БД, которые выполнятся успешно все вместе или не выполнятся вовсе. Изолированность же транзакции показывает то, насколько сильно влияют друг на друга параллельно выполняющиеся транзакции.
Выбирая уровень транзакции, мы пытаемся прийти к консенсусу в выборе между высокой согласованностью данных между транзакциями и скоростью выполнения этих самых транзакций.
Стоит отметить, что самую высокую скорость выполнения и самую низкую согласованность имеет уровень read uncommitted. Самую низкую скорость выполнения и самую высокую согласованность — serializable.

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

Эта статья является компиляцией коротких выжимок из всех трех с моими субъективными размышлениями под эгидой всеобщего горящего от неэффективности пукана.

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

Возможно вы читали первую часть статьи про код ревью со стороны ревьювера (кстати, мы уже успели ее обсудить в последнем выпуске подкаста "Цинковый прод").

Так как статья набрала много лайков, пишу обещанное продолжение про код ревью с другой стороны — со стороны автора изменений кода

Как обычно, будем говорить MR (Merge Request) вместо CL, потому что термин CL мало кто понимает.

Оригинал инструкции для авторов MR по версии Google можно посмотреть здесь, а я дам краткую выжимку.

Итак, поехали

Работа над любым исследовательским проектом включает в себя поиск и изучение множества источников информации. Организация этого процесса — непростая задача. Сегодня мы расскажем об инструментах, которые призваны оптимизировать различные ее составляющие.

• Toolbox для исследователей #2: подборка из 15 тематических банков данных
• Toolbox для исследователей #1: самоорганизация и визуализация данных

Всем привет.

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

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

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

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

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

После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?

Попробуем разобрать судьбу ещё одного велосипеда, который позволяет реализовать Publish/Subscribe приложение.

Ранее мы познакомились с тем, как ядро управляет виртуальной памятью процесса, однако работу с файлами и ввод/вывод мы опустили. В этой статье рассмотрим важный и часто вызывающий заблуждения вопрос о том, какая существует связь между оперативной памятью и файловыми операциями, и как она влияет на производительность системы.

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

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

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

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Давайте совершим прогулку по цепочке Pointed, Functor, Applicative Functor, Monad, Category, Arrow, в процессе которой я попытаюсь показать что все это придумано не для того что бы взорвать мозг, а для решения вполне реальных проблем, притом существующих не только в haskell. Большая часть кода написана на C#, но думаю и без его знания можно будет понять что к чему.

Статья посвящена лучшим практикам написания кода Go. Она составлен в стиле презентации, но без обычных слайдов. Постараемся кратко и чётко пройтись по каждому пункту.

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

Программная инженерия — то, что происходит с программированием, если добавить фактор времени и других программистов.

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

В нашем блоге мы много пишем о технологиях и полезных инструментах, связанных с биржевой торговлей. Один из них – бесплатная платформа StockSharp, которую можно использовать для профессиональной разработки торговых терминалов и торговых роботов на языке C#. В данной статье мы покажем, как использовать графический фреймворк, входящий в S#.API, с целью создания торгового терминала с возможностью запуска алгоритмических стратегий.

В развертывании медиасерверов для WebRTC есть две сложности: масштабирование, т.е. выход за рамки использования одного сервера и оптимизация задержек для всех пользователей конференции. В то время как простой шардинг в духе «отправить всех юзеров конференции X на сервер Y» легко масштабируется горизонтально, он все же далеко не оптимален в плане задержек. Распределять конференцию по серверам, которые не только близко расположены к пользователям, но и взаимосвязаны – звучит как решение для обеих проблем. Сегодня мы подготовили перевод подробного материала от Бориса Грозева из Jitsi: проблемы каскадных SFU, с описанием подхода и некоторых трудностей, а также подробности внедрения. Стоит сказать, что конференции Voximplant тоже используют SFU; сейчас мы работаем над каскадированием SFU, которое должно появиться в нашей платформе в следующем году.


Мышиные нейроны. Изображение NIHD (CC-BY-2.0)

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

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