Коллеги, здарова! Часто бывает что нужно отправить сообщение в мессенджер к разработчикам, в случае возникновения различных проблем.
Представляю небольшое решение, которое позволит отправить сообщение в Telegram с информацией о состоянии DAG`а Apache Airflow
В этой статье я хотел бы совсем чуть-чуть порассуждать о том, с какими намерениями авторы приходят на Хабр, а также рассказать вам чем занимаюсь лично я, чтобы быть одним из авторов Хабра.
«Мы считаем, что сфера опенсорса должна быть жизнеспособной, а труд мейнтейнеров должен оплачиваться!»
Мейнтейнер: *вносит коммерческие возможности*
Мы: «Не таким образом».
Мейнтейнер: *работает на крупную технологическую корпорацию*
Мы: «Не таким образом».
Мейнтейнер: *привлекает инвестирование*
Мы: «Не таким образом».
Мы очень любим Kubernetes и мечтаем чтобы все современные технологии поскорее начали использовать его замечательные паттерны.
А вы когда-нибудь задумывались о том чтобы построить своё собственное облако? Могу поспорить что да. Но можно ли это сделать используя лишь современные технологии и подходы, не покидая уютной экосистемы Kubernetes? Нам по опыту разработки Cozystack пришлось с ним как следует разобраться.
Да, вы могли бы возразить что Kubernetes для этого не предназначен и почему бы не использовать OpenStack для Bare Metal-серверов а внутри него запускать Kubernetes как положено. Но поступив так, вы просто переложите ответственность с ваших рук на руки OpenStack администраторов. Что добавит как-минимум ещё одну сложную и неповоротливую систему в вашу экосистему.
Зачем так всё усложнять? - ведь на данный момент Kubernetes уже имеет всё необходимое для запуска Kubernetes кластеров.
В этой статье задокументированы уроки, полученные мной при проектировании и создании самодельного перьевого плоттера летом 2023 года.
Моей конечной целью было создание собственного станка с программным управлением, и перьевой плоттер показался мне хорошим промежуточным шагом в этом направлении. Это важный контекст в проектировании этого устройства, потому что если бы мне просто нужен был перьевой плоттер, то многое можно было бы упростить.
Эд Кэтмелл — гик, специалист в области анимации, новатор, принесший на рынок технологию Z-buffer. Также он один из основателей Pixar Animation Studios, президент Pixar Animation и Disney Animation. Всё повествование книги идёт от его лица.
Эми Уоллес — журналистка, редактор и репортер, которая помогла Эду рассказать свою историю.
Когда речь заходит о микросервисах, на ум обычно приходят контейнеры. Разумеется, встречаются микросервисные архитектуры, в которых компоненты запускаются без контейнеров. На мой взгляд, сопровождение таких систем получается намного сложнее, так как требует более глубоких знаний в администрировании Linux, скриптинге и различных инструментах автоматизации. В то же время, порог вхождения (дисклеймер: подразумевается именно минимально необходимый набор знаний для начала работы с инструментом) для вещей вроде docker-compose существенно ниже, и работать с ними могут даже начинающие разработчики.
Иногда для оперативной локализации ошибки проще всего воспользоваться отладчиком. Я думаю, каждый разработчик так или иначе применял подход DDD (DDD - шут. Debug Driven Development) при локальной разработке или в поисках бага на удаленном стенде. Но что делать, если удаленное приложение в контейнере? В этой заметке я бы хотел поделиться Dockerfile-ом, к которому пришел в свое время, решая проблему отладки контейнеризированного приложения.
В отличие от императивного подхода, где выражается последовательность операций, функциональное программирование (FP) сосредотачивается на "что" и "как" должно быть вычислено, а не на "когда". Это приводит к более чистому, модульному и легко тестируемому коду.
Juliа поддерживает анонимные функции, замыкания, и имеет систему типов, которая позволяет писать высокооптимизированный код без потери читаемости и удобства.
Привет, странник👋
Сегодня ты встретишься с невероятной историей о том, как одна архитектура смогла убедить программиста в его любви к коду. Ладно, не все так трагично, однако FSD действительно покажет, что можно любить расположение папок в проекте
Пару месяцев назад я со своей командой осознали, что в проекте развернулось небывалых размеров болото, залазить в которое с каждым разом все больнее (наша архитектура до FSD - якорь): писать новый код не хочется, старый код отталкивает своей запутанностью, никто ничего не понимает. Тогда-то мы решили попробовать новую архитектуру - FSD, поскольку сейчас, как мне показалось после изучения этого вопроса, это самая логичная, чистая и понятная архитектура.
Статей о селектах хватает, попробуем про апдейты. "ТОП-100" вопросов не обещаю - тут бы с одним разобраться. Разработчиков OLTP-систем под MS SQL Server и кандидатов на подобные вакансии приглашаю под кат.
Код на T-SQL, и он идеален. Атомарности нет, целостность вернём ручными апдейтами, изоляция с дюрабилити только мешают. Программируем без оглядки на ACID, который жив лишь в статье википедии.
Создание и настройка необходимых компонентов без дублирования кода
Отправка HTTP-запросов в тестируемую систему без дублирования кода
Настройка Spring MVC Test framework, при написании модульных тестов для Spring MVC REST API с помощью JUnit 5.
Когда ты работаешь над продуктом, всегда есть волнующие вопросы: как сделать его лучше? Что нужно изменить, чтобы пользователи были в восторге? Тут на помощь и приходят гипотезы! Это как загадка, которую ты решаешь, чтобы открыть новые возможности и улучшить свой продукт.
Давай разберемся, почему работа с гипотезами — это не просто прикол, а must-have в мире продукт-менеджмента. Это как инструмент, который превращает облачные мечты в ясные дорожные карты к успеху!
Когда ты кидаешься на разработку продукта без грамотно сформулированных гипотез, это как играешь в прятки в темноте — неясно, куда бежать и кого искать. Гипотезы же — это твои фонарики в этой темноте, помогающие увидеть путь к цели.
Так что работа с гипотезами — это не просто игра в догадки. Это искусство умения задавать правильные вопросы о продукте, анализировать данные и выводить новые гипотезы, которые приведут к инновациям и успеху. Поверь, когда ты овладеешь этим искусством, твой продукт станет настоящей звездой на небосклоне бизнеса!
Всем Хабр! В этой статье пойдет речь о переводчиках. Но не в привычном (во всяком случае, в IT-мире) понимании, - а с точки зрения математики. Да-да, это редкий случай, когда нас будут интересовать переводчики вне позиции смыслов.
Сразу оговорюсь, как это стало чаще заводиться в моих статьях:
Вот как 3 месяца занимаюсь созданием контента для продвижения стартапа.
Из-за этого стал пристально следить за новостями из Хабра и другими источниками. И стало как-то грустно. Во многих тг каналах одно и тоже (может быть сетка каналов, здесь хз). На других площадках похожая ситуация.
И здесь я задумался. А может уже живые люди не ведут сайты/блоги/каналы? Может это делают заточенный под это чат боты?
Данная статья касается вопросов «софтостроения» (термин этот я подсмотрел у своего коллеги и друга Сергея Тарасова). Термин мне нравится. Всегда встаю в тупик по порядку изложения. В первую очередь сказать о техническом задании (ТЗ) или о теоретических аспектах или продумывании как и что реализовать в программном коде? Ведь очевидно, что прежде, чем что‑то писать программист должен хотя бы минуту подумать, что он напишет? Есть и другие варианты написания, но мы их касаться не будем и начнем все‑таки с ТЗ.
Вкратце ТЗ звучало так. Написать информационно‑справочную систему поиска и бронирования лекарственных препаратов с использованием телеграмм бота (ТБ) для сети аптек на основе 1С конфигурации.
Задача была написана на 1С и работает (или работала) под телеграмм ботом с именем @lotostatki_bot. Это не предмет статьи, но прототип. Почему 1С? Потому, что 1С это учетная система, а бронирование товара — это документ, который поступает в аптеку и резервирует товар на определенное время. Схема, по которой ведет диалог ТБ @lotostatki_bot следующая...
На просторах сети частенько можно наткнуться на споры про то, что же лучше - стрелочные приборы или цифровые.
Что же лучше? Предлагаю проверить на практике c помощью программы-теста, которая измеряет время, необходимое на считывание значений со стрелочного индикатора и цифрового.
Давно слежу за популярным движением «войти в АйТи». Подписываюсь на различных блогеров, которые с энтузиазмом рассказывают про свой путь переплавки из абстрактных продажников в программисты. Большинство из них сдувается через пару месяцев. Но встречаются иногда упорные люди с высокой мотивацией. Про одни такой интересный кейс я и хочу рассказать.
Вы когда-нибудь задумывались о том, что у человеческого мозга есть ограниченная емкость и вы можете выучить этот чертов английский просто потому что в детстве запомнили слишком много покемонов? Или почему обучение с учителем гораздо эффективнее, чем самостоятельное?
Эти вопросы вполне применимы и в области машинного обучения. Для обучения модели диффузии требуется много данных и вычислительной мощности, а затем для создания изображений требуется значительное количество вычислений и серьезное оборудование. Исследователи (у которых обычно нет денег и на доширкак) задали очень хороший вопрос - можно ли достичь тех же результатов с меньшими усилиями?
