На днях появился новый релиз динамического объектно ориентированного языка программирования Ruby 3.3.0. Он вобрал в себя лучшие возможности многих других ЯП, включая Perl, Java, Python, Smalltalk, Eiffel, Ada и Lisp. Что касается кода проекта, то он распространяется под лицензиями BSD (2-clause BSDL) и Ruby, которая ссылается на последний вариант лицензии GPL и полностью совместима с GPLv3. Подробности — под катом.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В этой лекции углубимся в расширенные возможности команды SELECT : как можно "сложить" и "вычесть" выборки (UNION/INTERSECT/EXCEPT), или запомнить и использовать в рекурсивных запросах (CTE), что дают оконные функции (WINDOW) и соединения (JOIN).

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

"Преимущество Scrum-команд — способность к обучению", — часто ли слышали такое? Звучит как суперсила из комиксов Marvel! Только представьте, вместо "человек-паук" у нас "человек-скрам", который вместо паутин метает стики-ноты и вместо борьбы с преступностью учит нерадивых разработчиков, не желающих понимать скрам-магию!

А вот так выглядит обучение в повседневной жизни: вы купили мебель с инструкцией для сборки. Сначала вы думаете: "О, это будет легко", а затем проводите всю ночь, пытаясь понять, куда идет этот чертов шуруп! Но в конце вы учитесь и даже начинаете получать удовольствие от процесса сборки, а следующий шкаф собираете быстрее.

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

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

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

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.

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

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

Очередным ламповым вечером мы встретились в онлайне с Александром Ильиным и решили детально поговорить про общение с работодателями.

Найм профессионального программиста — это слишком дорого, да и программирование — совсем не быстрый процесс. А бизнесу всегда нужно "вчера" и желательно бесплатно. Поэтому всё более популярным становится no-code подход: вы не пишете код, а просто, используя кнопки в интерфейсе и мышку, компонуете своё приложение. Звучит красиво. Так можно создать типовое приложение, накидав туда компоненты. Вот пример рекламной статьи no-code системы Bubble, в которой, по сути, говорят, что для стартапа программисты уже не нужны, по крайней мере — на начальном этапе.

Или если у вас есть условный эксель, где вы можете выделить нужные строки и посчитать их сумму, построить график, и т.д. — вам не надо это всё программировать на каком-либо языке. Всё делается в пару кликов. Это тоже no-code.

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

Вопрос некорректен

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

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

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

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

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

Для решения подобных проблем в PostgreSQL есть так называемые необязательные блокировки (advisory locks), т.е. локи, которые берутся, исходя из логики приложения, а не автоматики хранения/выдачи данных в БД.