• Go lintpack: менеджер компонуемых линтеров


      lintpack — это утилита для сборки линтеров (статических анализаторов), которые написаны с использованием предоставляемого API. На основе него сейчас переписывается знакомый некоторым статический анализатор go-critic.


      Сегодня мы подробнее разберём что такое lintpack с точки зрения пользователя.

      Читать дальше →
    • Безумие и успех кода Oracle Database

        На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

        Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

        За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.
        Читать дальше →
      • Контроль консистентности кода в Go


          Если вы считаете консистентность важной составляющей качественного кода — эта статья для вас.


          Вас ждут:


          • Разные способы сделать одно и то же в Go (эквивалентные операции)
          • Менее очевидные факторы, влияющие на однородность вашего кода
          • Способы увеличения консистентности вашего проекта
          Читать дальше →
        • Данные высокого рода

            Да-да, вам не привиделось и вы не ослышались — именно высокого рода. Род (kind) — это термин теории типов, означающий по сути тип типа [данных].

            Но вначале немного лирики.

            На Хабре вышло несколько статей, где подробно описывался метод валидации данных в функциональных языках.

            Эта статься — мои пять копеек в этот хайп. Мы рассмотрим валидацию данных в Хаскеле.

            Валидация типом


            Ранее было рассмотрен пример методики валидации при помощи валидации типом:

            type EmailContactInfo  = String
            type PostalContactInfo = String
            
            data ContactInfo = EmailOnly EmailContactInfo | 
                               PostOnly PostalContactInfo | 
                               EmailAndPost (EmailContactInfo, PostalContactInfo)
            
            data Person = Person 
              { pName :: String,
              , pContactInfo :: ContactInfo,
              }

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

            Валидация данными высокого рода




            В этой статье мы посмотрим иной метод валидации — при помощи данных высокого рода.

            Пусть у нас есть тип данных:

            data Person = Person
              { pName :: String
              , pAge  :: Int
              }

            И мы будем валидировать данные лишь в том случае, когда валидны все поля записи.
            Поскольку Хаскель по функциональным возможностям на голову превосходит большинство функциональных языков, на нём можно легко избавится от большинства рутины.

            Тут можно и поэтому данный метод широко используется среди авторов библиотек на Хаскеле.
            Читать дальше →
            • +16
            • 2,7k
            • 7
          • Лучший Способ Программирования (Better way To Code)

            • Перевод
            От переводчика:
            Я не являюсь ни профессиональным программистом ни профессиональным переводчиком, но появление описанного в статье инструмента от создателя популярной библиотеки D3.js произвело на меня сильное впечатление.

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

            Знакомьтесь, d3.express, интегрированная исследовательская среда.
            (с 31 января 2018г d3.express зовется Observable и живет на beta.observablehq.com)

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

            Последние лет восемь я разрабатывал инструменты для визуализации информации. Самым удачным результатом моих усилий стала js-библиотека D3. Однако опасность столь долгой разработки инструментария в том, что ты забываешь зачем ты это делаешь: инструмент становится самоцелью, польза от его применения уходит на второй план.

            Предназначение инструмента визуализации — построение визуализаций. Но в чем же цель визуализации? Слово Бену Шнейдерману(Per Ben Shneiderman):
            «Результат визуализации — это
            Читать дальше →
          • Архитектура как бремя

            • Перевод

            За время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.


            Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.


            В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.


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


            Читать дальше →
          • Prettier, ESLint, Husky, Lint-Staged и EditorConfig: инструменты для написания аккуратного кода

            • Перевод
            Вы стремитесь к тому, чтобы писать аккуратный код, но не знаете с чего начать… Вы вчитываетесь в руководства по стилю, вроде этого от Airbnb, стараетесь следовать практическим рекомендациям ведущих специалистов… Вам приходится удалять неиспользуемый код? Приходится искать ненужные переменные? Вы пытаетесь выявлять неудачные паттерны, применённые в ваших программах? Например — хотите понять, читая хитросплетения кода некоей функции, возвратит ли она что-нибудь или нет. Звучит знакомо? Проблема заключается в том, что программисту очень тяжело и многое успевать, и многому учиться.

            Может быть вы — тимлид, под началом которого трудится команда разработчиков разного уровня? В вашей команде есть новые люди? Беспокоит ли вас то, что код, который они напишут, не будет соответствовать вашим стандартам? Проходят ли ваши дни в проверках чужого кода, когда эти проверки, в основном, касаются соблюдения стандартов, а не программной логики?



            Автор этого материала говорит, что он сталкивался со всем тем, чему посвящены только что заданные вопросы. То, с чем он столкнулся, утомляет и изматывает. Здесь он хочет рассказать об инструментах, правильное применение которых позволяет решить вышеописанные проблемы.

            А именно, здесь пойдёт речь о таких средствах как Prettier, ESLint, Husky, Lint-Staged, EditorConfig, об автоматизации форматирования и линтинга кода. Этот материал ориентирован, в основном, на React-разработку, но рассмотренные здесь принципы можно применить в любом веб-проекте. Вот репозиторий, где, кроме прочего, собрано то, о чём тут пойдёт речь.
            Читать дальше →
          • Проблема Windows не в частоте обновлений, а в процессе разработки

            • Перевод
            Глючные обновления указывают на более глубокую проблему


            Windows 10 на презентации в Токио, июль 2015 года

            Очевидно, обновление Windows от 10 октября 2018 года было не самым удачным. Быстро появились сообщения о потере файлов на компьютерах, а Microsoft приостановила распространение обновления. С тех пор баг исправили, сейчас идёт тестирование нового апдейта перед его повторным выпуском.

            Это не первое обновление Windows, в котором возникли проблемы — в предыдущих апдейтах мы видели такие вещи, как значительные аппаратные несовместимости — но оно явно стало худшим. Большинство из нас знает о резервном копировании, но в реальности многие данные, особенно на домашних компьютерах, не имеют бэкапа, и их исчезновение весьма неприятно.
            Читать дальше →
          • Когда программный код вызывает восхищение?



              Тема идеального кода нередко вызывает полемику в среде матерых программистов. Тем интереснее было заполучить мнение директора по разработке Parallels RAS Игоря Марната. Под катом его авторский взгляд по заявленной теме. Enjoy!
              Читать дальше →
            • Книга «App from scratch»

                Я написал книгу, предварительный релиз, о создании веб-приложений с нуля.


                Я прочитал много книг по программированию, но, часто, после прочтения у меня оставался только один вопрос — Как мне применить эти знания на практике?


                Предположим, вы разработчик системы автоматизации, портала или интернет-магазина.
                Добавление новой функциональности осложняется наслоениями кода. Запуск тестов занимает полчаса, а релиз — час. Идея о переходе на новую версию фреймворка вызывает нервные подергивания. Вы узнаёте, что PostgreSQL имеет поддержку массивов, jsonb, полнотекстового поиска и lateral join, но ORM не позволяет использовать их в полную силу. Вы прочитали про TDD, но как писать в таком стиле, когда аналитик описывает сценарии, а фреймворк требует создания модели, контроллера и представления?


                Как применить SOLID, если сущности наследуют от ORM?


                Как избавиться от боли?


                Постепенно, по мере изучения Clojure, и, наконец после прочтения Clean Architecture, я понял, как без боли написать приложение, где на первом месте стоит предметная область, а не фреймворк, где я принимаю решения, а не создатели фреймворков навязывают свои.


                В какой-то степени книгу можно рассматривать как практический самоучитель по Clojure,
                так что знание этого языка не требуется.

                Читать дальше →

              Самое читаемое