Модель T5 – это нейросеть, которая уже обучена хорошо понимать и генерировать текст, и которую можно дообучить на собственную задачу, будь то перевод, суммаризация текстов, или генерация ответа чат-бота.
В этом посте я рассказываю про первую многозадачную модель T5 для русского языка и показываю, как её можно обучить на новой задаче.
Предположим, вы разработали приложение или библиотеку на Python и уже готовитесь передать его / её заказчику. И в этот момент появляются разные вопросы.
Во-первых, к вам прибегает озадаченный проджект-менеджер и говорит: «Мы решили не отдавать исходный код, ведь это наша интеллектуальная собственность. Придумайте что-нибудь, чтобы заказчик был доволен, а мы оставили у себя исходники».
Во-вторых, возникает вопрос окружения - хочется быть уверенным, что заказчик справится с установкой правильной версии Python и всех вспомогательных библиотек, но это не всегда простая задача. Было бы удобно упаковать приложение в автономный исполняемый файл.
И, наконец, хочется, чтобы конечное приложение работало быстрее, чем в среде разработки.
И вот тут настало время скомпилировать Python-код.
Меня зовут Руслан, я старший разработчик компании «Цифровое проектирование». Сегодня я расскажу, как выбрать тот самый компилятор из множества доступных.
Перевод статьи Роберта Мартина
Недавно я получил письмо:
В течение многих лет проверка понимания принципов SOLID было стандартной частью нашей процедуры приема на работу. Предполагалось, что кандидаты хорошо знакомы с этими принципами. Однако в последнее время один из наших менеджеров, который больше не занимается программированием, усомнился в том, что это разумно. Его аргументы заключались в том, что принцип открытости-закрытости (open–closed principle) больше не очень важен, потому что большая часть кода, который мы пишем, не содержится в больших монолитах, а внесение изменений в небольшие микросервисы безопасно и легко. Принцип подстановки Лисков (Liskov substitution principle) давно устарел, потому что мы не уделяем столько внимания наследованию, как 20 лет назад. Я думаю, нам следует рассмотреть позицию Дэна Норта по SOLID: «Просто напишите простой код».
В ответ я написал следующее письмо:
Принципы SOLID остаются актуальными и сегодня, как и в 90-е годы (и даже до этого). Это потому, что программное обеспечение не сильно изменилось за все эти годы. Оно не сильно изменилось даже с 1945 года, когда Тьюринг написал первые строчки кода для электронного компьютера. Программное обеспечение по-прежнему представляет собой операторы if, циклы while и операторы присваивания - последовательность, выбор и итерацию.
Каждое новое поколение любит думать, что их мир сильно отличается от мира предыдущего поколения. Каждое новое поколение ошибается в этом. Это то, что каждое новое поколение узнает, когда приходит следующее новое поколение, чтобы рассказать им, насколько все изменилось. Итак, давайте рассмотрим принципы один за другим.
IT — сфера большая и многогранная. В ней обитают программисты и сетевики, сисадмины и инженеры. Иногда попадаются копирайтеры, дизайнеры и маркетологи. Но это не точно.
Кто-то ушел в «компьютерную» профессию осознанно: сначала радиокружок, потом — технический факультет ВУЗа. Кто-то стал айтишником и вовсе по воле случая.
С точки зрения обывателя каждый «технарь» обязан как минимум чинить компьютеры любого вида и возраста. И уж точно понимать в программировании. Как раз о последнем мы и хотели бы поговорить: насколько важны кодерские навыки ИТ-спецам, не занятым непосредственно разработкой?
Мы поделимся с вами двумя историями двоих наших коллег из отдела DevOps. Оба они в какой-то момент интересовались языками программирования, однако пошли по другому пути. Это тенденция, заговор или несчастный случай? Как и почему это случилось? Ответы под катом!
Очередная статья тут на хабре, которая обсуждала поход в программисты и ИТ вообще и отказ от этого образа профессиональной деятельности, показалась неполной, была в ней некоторая недосказанность. Мой личный опыт прихода и ухода был сильно не похож на то, о чем пишут в подобных статьях.
А так как мне уже 50+ и я в теме со времен средней школы, возможно мой опыт будет полезен.
(Disclaimer!) Данная точка зрения не претендует на роль абсолютной истины и является лишь результатом моего опыта, чтения, наблюдений и размышлений.
Думаю многие знают или слышали о принципах и советах в стиле "Программируйте на уровне интерфейсов, а не реализаций". Хотя в теории, данный принцип кажется полезным и его аргументация звучит логично, но при более глубоком анализе оказывается, что предпосылки лежащие в его основе не реалистичны.
В этой короткой статье я хочу высказать точку зрения, почему данный принцип в большинстве случаев является ошибочным, создает лишние проблемы и приводит к плохой архитектуре.
В данной статье представлен способ максимально быстро получить результат используя Google Colab в качестве платформы для обучения модели HTR.
Первая часть моего повествования заканчивалась поступлением в Военную орденов Ленина, Октябрьской Революции и Суворова академию им. Ф. Э. Дзержинского (сокращённое название ВА им. Ф. Э. Дзержинского, ВАД или просто Дзержинка). Логотип второй части напоминает мне мои первые шаги на пути программиста. Это, прежде всего, годы учёбы в Дзержинке, куда я поступил на второй факультет, на котором готовили специалистов по автоматизированным системам управления ракетными комплексами. На факультете для курсантов было две профилирующие кафедры. Кафедра №23 готовила военных инженеров по эксплуатации вычислительной техники, а кафедра №25 готовила военных инженеров-программистов. Именно с сентября 1971 года в академии начали готовить военных инженеров-программистов из курсантов. Наш курс состоял из пяти отделений, в трёх из которых готовились военные инженеры по эксплуатации вычислительной техники, а в двух отделениях готовились будущие военные инженеры- программисты. Я проходил обучение в отделениях программистов. Почему во множественном числе? Просто обучение я начинал в отделении А, а затем меня перевели в отделение В. Поэтому оба отделения для меня стали родными. Именно эмблема кафедры №25 и находится в центре логотипа статьи. С одной стороны, с эмблемой всё понятно, а с другой стороны, сегодня она требует некоторого пояснения. Символы «к. 25» — ясно, что это кафедра №25. Символы «МО» являются аббревиатурой от словосочетания «Математическое Обеспечение». В те далёкие времена было принято говорить не программное обеспечение ЭВМ, а именно математическое обеспечение ЭВМ. Ну и последнее, символы «МО» располагаются поверх одного из основных носителей (наряду с перфокартами) программ и вообще данных – перфоленты. Сегодня трудно представить, что и программы и исходные данные для них готовились не в файлах на каком-нибудь носителе (диски, флешки и т.д.), а готовились на бумажном носителе, будь то перфолента или перфокарта
Недавно я сел за работу по настройке производительности FlutterFolio, приложения, которое было создано в качестве демонстрации дизайна для Flutter Engage. С помощью одного изменения я сделал FlutterFolio значительно быстрее.
Привет, Хабр!
Меня зовут Игорь Левин. Я разработчик 1С в Sportmaster Lab. Наша команда работает над проектом Shipdocs 2.0 — это продукт, который состоит из двух информационных систем. Он обеспечивает информационную поддержку бизнес-области закупок и цепей поставок. Часто мы автоматизируем кроссфункциональные бизнес-процессы на стыке с международной логистикой и финансовым управлением.
Вот ключевые функции Shipdocs 2.0:
Очередная статья c теорией и практикой на тему домашней автоматизации...
Являюсь давним читателем хабра, но только сейчас созрел написать статью.
В ней будет отображено как текущее состояние дел, так и немного истории. Конкретного финиша нет: совершенствовать можно почти до бесконечности.
Рассчитываю как поделиться идеями и опытом, так и набраться критики и предложений.
operator[](int, int, int)std::optionalstd::move_only_functionstd::basic_string::resize_and_overwritestd::views::zip и zip_transform, adjacent, adjacent_transform
Camunda Modeler позволяет довольно легко набросать BPMN-схему процесса, перетащив элементы в рабочую область и соединив их стрелками. Далее дела обстоят немного сложнее: нужно быть очень внимательным, чтобы с первого раза для каждого элемента заполнить необходимые поля в панели свойств и не допустить ни одной ошибки. С этой точки зрения создание исполняемых BPMN-схем напоминает программирование в Блокноте.
Например, очень легко в Script Task написать скрипт на Groovy и забыть указать Script Format. Тогда по умолчанию движок попробует выполнить переданную ему строку как JUEL-код, и вряд ли мы получим ожидаемый результат.
Было бы неплохо иметь что-то вроде подсказок, на какие поля нужно обратить внимание, какое значение вписать, какие флаги отметить, и так далее в соответствии с принятыми в команде практиками. К счастью, Camunda Modeler позволяет расширять функциональность, не форкая всё приложение, а применив плагины, что мы и решили сделать.
Привет, Хабр. Увидел неплохую англоязычную статью с результатами свежего исследования в секторе IT про выгорание в целом и в период пандемии в частности. Упустив в своем переводе такие подробности оригинала, как "Что такое выгорание", "Что вызывает выгорание" и "Как избежать выгорания" (я уверен, что вы уже видели статьи про это, а если не видели - легко найдете в том числе на хабре), перейду сразу к цифрам.
Статья будет полезна unix-инженерам и владельцам информационных систем, которые сталкиваются в своей работе с нехваткой технических данных о серверной нагрузке за длительный период времени.
Я - unix-инженер и расскажу, как мы разрабатывали скрипт по логированию потребления ресурсов сервера процессами, пошагово, в виде фотографии своего рабочего дня. А точнее, четырёх дней: пройдёмся по этапам, начиная с выявления проблемы и заканчивая развертыванием в проде. Параллельно покажу взаимодействие команды на каждом этапе наглядно. Вас ждет скрипт в конце лонгрида).
Современные языки программирования всё чаще становятся мультипарадигменными, и Kotlin не исключение. С появлением Jetpack Compose наблюдается уход от ООП в функциональное программирование. Изучая новые средства разработки, такие как Jetpack Compose, давайте вспомним и те, которым уже около 60 лет. А главное — разберёмся, как их можно применить к современным подходам для получения большей эффективности.
Ataman – это мой плагин для IDE-шек на базе Intellij. Единственное его предназначение – сделать возможным использование leader key биндингов в моём основном рабочем инструменте – Android Studio.
В этом посте я расскажу, зачем я его сделал и вы удивитесь, как раньше-то без него жили!
Лисп — второй по старшинству из ныне живых высокоуровневых языков программирования (после Fortran) и первый функциональный язык. Он был разработан в 1958 году и сильно изменился с тех пор, породив множество диалектов и оказав значительное влияние на развитие других языков. На данный момент наиболее известные диалекты: Common Lisp, Scheme, Racket и Clojure.
Слева: Лисп-машина в музее MIT.
Справа: Лисп-машина Symbolics 3640, фото Michael L. Umbricht и Carl R. Friend (Retro-Computing Society of RI)
Лисп стал “первооткрывателем” многих идей, нашедших применение в современных языках программирования: древовидные структуры, динамическая типизация, функции высшего порядка и многое другое. В этом посте мы не будем углубляться во вклад Лиспа в теорию, а сосредоточимся на практической пользе.
Изначально Лисп предназначался для работ в области искусственного интеллекта, в частности как представление математической нотации для символьных вычислений. Но насколько широко диалекты Лиспа используются сейчас и в каких областях применяются?
Мы в Typeable любим и применяем функциональное программирование, а влияние Лиспа на функциональные языки всё ещё сильно, поэтому нам стало интересно разобраться в этом вопросе.
Статья по ссылке напомнила мне один недавний проект. Статья отличная, но в ней не хватает какого-нибудь практического примера. От этого остаются неясными границы применимости в принципе неплохих советов автора. В своем проекте я полностью следовал рекомендациям из упомянутой статьи и вот что вышло.