Первыми это обнаружили шумеры. Шумеры — это те самые ребята, которые 6 тысяч лет назад изобрели кучу полезного: колесо, плуг, письменность, классовое общество, цветные ткани, бубенчики. В том числе они изобрели календарь. Это сегодня календарь нужен чтобы не пропустить день рождения коллеги или деловую встречу, а праздники — это очередной повод выпить. А тогда нужно было знать, когда сеять пшеницу, когда собирать урожай, когда готовиться к розливу рек, когда высохнут дороги после наводнения, чтобы пойти резать соседей, ну или пойти торговать с ними. Праздники также были сугубо практического назначения, по ним отмерялось начало или окончание очередного этапа сельхоз работ. И выпить на праздники как же без этого (пивоварение тоже они изобрели). Кстати у шумеров была шестидесятеричная система счета и именно они разделили час на 60 минут, а минуты на 60 секунд. Так что теперь вы знаете кого проклинать, когда мучаетесь, переводя километры в час в метры/секунды.
Пользователь
Какой вклад внесло функциональное программирование в современные языки?
Современные языки программирования обладают большим набором разнообразных средств и удобных фишек, что позволяет писать совершенно разный код на одном и том же языке для одной и той же задачи.
Парадигма программирования — это в первую очередь стиль мышления: то, как программист думает о представлении данных и процессе их обработки. Другими словами, парадигма живёт в голове программиста, а не является свойством языка. Разные языки могут в той или иной степени поддерживать определённую парадигму. Если сейчас зайти на Википедию и начать читать про самые популярные ЯП, мы увидим, что многие из них заявлены как "мультипарадигменные": на них можно писать в разных стилях, но какие-то из них использовать будет удобнее.
В своей недавней статье мы рассказывали о практических применениях Лиспа и упомянули, что он сильно повлиял на развитие других языков программирования, но не стали вдаваться в детали. Пришло время более подробно раскрыть эту тему и разобраться, какой вклад функциональное программирование в целом (не только Лисп!) внесло в развитие других языков. Поскольку мы используем Haskell как основной язык разработки, и наша команда разработчиков состоит из ФП-энтузиастов, мы не смогли пройти мимо такой темы.
В этом посте рассмотрим несколько механизмов, которые либо зародились в ФП-языках, либо нашли в них наибольшее применение и были ими популяризованы, и в итоге появились в языках, изначально не функциональных.
Параллельные вселенные для вашего CI/CD пайплайна в Octopod
Как мы строили параллельные вселенные для нашего (и вашего) CI/CD пайплайна в Octopod
Привет, Хабр! Меня зовут Денис и я вам расскажу как нас надоумило сделать техническое решение для оптимизации процесса разработки и QA у себя в Typeable. Началось с общего ощущения, что вроде делаем все правильно, но все равно можно было бы двигаться быстрее и эффективнее — принимать новые задачки, тестировать, меньше синхронизироваться. Это все нас привело к дискуссиям и экспериментам, результатом которых стало наше open-source решение, которое я опишу ниже и которое теперь доступно и вам.
Сильные стороны функционального программирования
Привет! Меня зовут Катерина, и я испытываю самые тёплые чувства к функциональному программированию, использую функциональный язык на постоянной основе и даже немного преподаю.
Основной язык разработки у нас в Typeable — Haskell, и, пока все спорили о том, готов ли Haskell для продакшена, мы просто его использовали и считали конкурентным преимуществом. Нам хотелось бы поделиться своим мнением, основанным на этом опыте.
Создаем веб-приложение на Haskell с использованием Reflex. Часть 1
Введение
Всем привет! Меня зовут Никита, и мы в Typeable для разработки фронтенда для части проектов используем FRP-подход, а конкретно его реализацию на Haskell – веб-фреймоворк reflex
. На русскоязычных ресурсах отсутствуют какие-либо руководства по данному фреймворку (да и в англоязычном интернете их не так много), и мы решили это немного исправить.
В этой серии статей будет рассмотрено создание веб-приложения на Haskell с использованием платформы reflex-platform
. reflex-platform
предоставляет пакеты reflex
и reflex-dom
. Пакет reflex
является реализацией Functional reactive programming (FRP) на языке Haskell. В библиотеке reflex-dom
содержится большое число функций, классов и типов для работы с DOM
. Эти пакеты разделены, т.к. FRP-подход можно использовать не только в веб-разработке. Разрабатывать мы будем приложение Todo List
, которое позволяет выполнять различные манипуляции со списком задач.
Сравнение Elm и Reflex
Введение
В этой статье мы поговорим о двух принципиально разных подходах к реактивному программированию.
Elm, в отличие от Reflex — это целый язык, а не библиотека, поэтому сравнивать их не очень корректно. Тем не менее, можно показать разницу между подходами, а также рассказать, какие практические трудности могут возникнуть при разработке с использованием каждой из технологий.
Язык моделирования Alloy и приключения с параллельными запросами к базе данных
Данная статья описывает небольшой пример того, как использование языка моделирования Alloy может помочь при разработке программного обеспечения.
О качестве программного обеспечения и инструментарии
В Typeable мы придаем огромное значение качеству программного обеспечения и прикладываем все усилия, чтобы обеспечить это качество. В настоящее время мы искореняем ошибки следующими способами:
- Анализ и создание спецификаций
- Устранение простых ошибок с использованием системы типов Haskell
- Стандартные юнит-тесты и интеграционные тесты
- Непрерывная интеграция
- Обязательные ревью кода
- Тестирование на стендах, проводимое QA инженерами
(мы используем Octopod для оптимизации процесса разработки и QA) - Тестирование в pre-production среде
- Ведение логов и контроль ошибок на этапе эксплуатации
Такое большое число шагов обеспечивает высокое качество кода, но при этом сказывается на затратах. Для выполнения этих шагов нужно и время, и труд.
Зачем мы транспилируем Haskell в JavaScript
Привет, Хабр! Сегодня мы расскажем, почему мы пишем фронтенд на Haskell и компилируем его в JavaScript. Вообще говоря, подобный процесс называется транспиляцией:
Транспиляция — это процесс преобразования программы на языке X в эквивалентную программу на языке Y. В отличие от компиляции, языки X и Y находятся примерно на одном и том же уровне абстракции.
Nix: Что это и с чем это употреблять?
Привет, Хабр!
Мы в Typeable хотели опубликовать небольшой цикл статей о том, как Nix нам помогает (и немного мешает) в разработке. Но, проведя немножко времени в поисках похожего материала здесь, с удивлением обнаружили, что на Хабре нет толкового введения в Nix, на которое можно было бы сослаться.
Статья от @snizovtsev подойдёт как хорошее введение при разработке на C++, но это не совсем то введение, которое мне хотелось бы видеть. Поэтому я решил написать его сам :)
Файлы к этой статье можно найти здесь.
8 «забавных» вещей, которые могут произойти без защиты от CSRF-атак
Введение
В качестве программистов Typeable мы видим свою основную цель в том, чтобы приносить пользу нашим заказчикам. Однако я только что потратил некоторое количество денег заказчика и целый день на то, чтобы добавить защиту от подделки межсайтовых запросов (CSRF) на нашу страницу авторизации и, надеюсь, сделал это без каких-либо видимых следов. Ценность таких действий по обеспечению безопасности бывает трудно увидеть, поэтому я подумал, что полезно было бы описать, что именно может произойти без защиты от CSRF, и почему это небольшое изменение на самом деле является очень ценным.
Как мы выбираем языки программирования в Typeable
Неоднократно меня спрашивали, почему я предпочитаю использовать такие языки программирования как Haskell и Rust, т.к. они не являются самыми широко используемыми и популярными инструментами. Этот пост написан с целью демистифицировать то, что происходит у меня в голове, когда я думаю о выборе технологии.
Nix: воспроизводимая сборка
Привет, Хаброюзеры!
Сегодня мы продолжим наш цикл статей о Nix и как мы в Typeable его используем.
Первый пост из серии, рассказывающий об основах языка Nix, можно прочитать здесь.
Так как мы очень любим и много используем Haskell для разработки, пример приложения будет на этом языке, но знание Haskell здесь никак не требуется. С лёгким допиливанием, код из примеров можно использовать и для сборки проектов на других языках.
Весь код для этой статьи можно найти в репозитарии на Github.
Haskell – хороший выбор с точки зрения безопасности ПО?
Команда Typeable понимает ценность безопасности. Мы любим Haskell, но стоит ли его выбирать, если ваша цель – создание защищенного программного обеспечения? Хотелось бы сказать «да», но как и для большинства эмпирических вопросов о разработке ПО, здесь просто нет объективного доказательства, подтверждающего, что Haskell – или ещё какой-нибудь язык программирования – обеспечивает большую безопасность, чем любой другой. Нельзя сказать, что выбор языка в Typeable не имеет значения для безопасности, но какое именно значение он имеет, еще нужно подумать.
Опираясь на пятилетний опыт преподавания вводного курса по защите ПО, я могу подтвердить, что универсальной теории, на которой может строиться защита ПО, не существует. Вопросы безопасности чаще всего преподаются путем перечисления различных уязвимостей, способов их минимизации и моделей безопасности в надежде на то, что на этой основе студенты смогут получить общее понимание вопроса. Из немногих существующих теоретических работ только некоторые содержат попытки провести связь между языком программирования и аспектами безопасности.
Когда стоит выбирать микросервисы
Всем привет! Меня зовут Виктория, в Typeable я занимаюсь вопросами архитектуры приложений и не могла пройти мимо вечного вопроса: быть или не быть? Точнее переводить нам наши решения на микросервисы или нет. И с целью это понять я провела небольшое исследование возможных причин и анти-причин, выводы по которому и привожу здесь.
Микросервисы начали набирать популярность в 2011-2014 годах, органично заменяя тяжеловесные SOA и монолитные решения, там где архитектура блокировала доступ к быстро развивающемуся рыночному сектору облачных приложений.
Сам подход оформился на стыке технологий из конкурентной необходимости мгновенно вывести бизнес на новый уровень, и поэтому решения развивались лавинообразно и быстро обзаводились надстройками, паттернами и CI/CD обвеской. Для бизнеса причины не теряют актуальности и интерес к микросервисам также не угасает последние десять лет. При этом сделать решение на микросервисах для ИТ команды – задача творческая, интеллектуальная, позволяющая опробовать современные подходы и уложить на лопатки драконов консерватизма предыдущих решений. То есть, вполне благородный вызов.
Но вот стоит ли поддаваться этой магии — большой вопрос.
Как и всякое модное решение микросервисы не всегда идут на пользу. И не являются панацеей от всех проблем.
Впрочем, давайте разбираться.
Property-based тестирование с QuickCheck
Автор статьи: klntsky
Что такое Property-Based Testing?
Property-based testing (PBT) — подход к тестированию ПО, подразумевающий автоматическую проверку свойств функций (предикатов), специфицируемых программистом-тестировщиком. Для проверки, т.е. поиска контрпримеров, используются автоматически сгенерированные входные данные. PBT позвляет разработчикам значительно увеличить тестовое покрытие и эффективно расходовать своё время, не придумывая входные данные для тестов самостоятельно. В общем случае данные, генерируемые во время property-based тестирования, ничем не ограничены, поэтому проверка может быть произведена на тех значениях, про которые разработчик мог забыть или для которых не счёл нужным написать юнит-тесты (действительно, не перебирать же все значения входных параметров вручную).
PBT-подход был популяризован библиотекой QuickCheck, написанной на Haskell, и в этой статье будет показано, как пользоваться этим инструментом эффективно.
В чем польза формальных спецификаций вроде OpenAPI?
В этой статье хочу рассказать, что такое OpenAPI и зачем он может быть нужен.
7 ложных предположений о том, как устроены строки
Как Unicode уничтожает большинство ваших предположений о том, как на самом деле работают строки
Когда речь идет о написании чего-то простого, мы, программисты, обычно действуем интуитивно. В случае с простыми вещами мы полагаемся на четкий набор предположений вместо конкретных знаний о том, как эти вещи работают. Например, мы предполагаем, что если b = a + 1
, то b
больше a
, или что если мы применим функцию malloc
для какого-то буфера, то получим необходимое количество памяти для записи. Мы не заглядываем в документацию всякий раз, когда имеем дело с мелочами.
Мы делаем так, потому что тотальная проверка замедлит работу. Однако если бы мы все-таки провели проверку, мы бы обнаружили, что обычно ошибаемся в своих предположениях. Существует арифметическое переполнение, в результате которого a + 1
может быть значительно меньше, чем a
. Иногда malloc
дает нам null
вместо буфера и мы оказываемся в пролете.
Нам обычно приходится обжечься на таких вещах, чтобы хотя бы немного изменить свои предположения. И даже тогда мы обычно исправляем их весьма условно.
Столкнувшись с досадной ошибкой переполнения, мы можем скорректировать свое предположение о целых числах в виде «a + 1
больше a
, если отсутствует вероятность, при которой a
представляет собой очень большое число». И мы действуем исходя из этого, вместо того, чтобы обдумать четкие правила, по которым работает переполнение.
Уточненные предположения – это опыт. Чаще всего они позволяют нам работать быстрее и правильнее. Однако мы можем вообще переместить некоторые вещи, например, правильную обработку malloc
, из нашей внутренней категории «простые вещи» во внутреннюю категорию «сложные вещи». И тогда мы действительно можем пойти и уточнить, как они работают.
Информация
- В рейтинге
- Не участвует
- Откуда
- Ижевск, Удмуртия, Россия
- Зарегистрирован
- Активность