• Принцип SOLID в языке Go

    Приветствую вас, хабровчане, решил поделиться с сообществом переводом довольно часто (по личным наблюдениям) упоминаемого поста SOLID Go Design из блога Dave Cheney, который выполнял для собственных нужд, но кто-то говорил, что нужно делиться. Возможно для кого-то это окажется полезным.


    SOLID дизайн Go


    Этот пост на основе текста из основного доклада GolangUK прошедшего 18-ого Августа 2016.
    Запись выступления доступна в YouTube.

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

      SOLID критикует тот, кто думает, что действительно понимает ООП
      © Куряшкин Виктор

      Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.

      Читать дальше →
    • Почему ранний возврат из функций так важен?

      Привет, Хабр! Представляю вашему вниманию перевод статьи «Why should you return early?» автора Szymon Krajewski

      image

      В начале моего приключения в роли программиста мой код зачастую напоминал вермишель. В любых условных выражениях я только и делал, что сразу переходил к описанию верного исхода, оставляя на конец остальное. «Это работает, вот и все», — говорил я себе, а код продолжал расти, как на дрожжах. Тысячи написанных методов в итоге заставили меня задуматься, а не стоит ли поменять их внутреннюю логику, возвращая отрицательные результаты как можно раннее. Таким образом, я пришел к тому, что теперь называю правилом «неотложного провала».

      Очевидно, что существует несколько подходов написания одной и той же функции. Например, как можно начать выполнение основной части сразу после положительного исхода условного оператора, так и можно сначала пробежаться по всем отрицательным исходам, возвращая ошибки из функции, а уже только потом перейти к основной логике. Иными словами, я открыл для себя разные стили написания условных конструкций.
      Читать дальше →
    • Абсурдно быстрое кодирование и декодирование base64

      • Перевод
      Об авторе: Дэниель Лемер — профессор компьютерных наук в Университете Квебека (Канада). Его исследования затрагивают производительность программного обеспечения и инженерию данных

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

      Однако мы часто используем текстовые форматы; например, веб-страницы и электронные письма должны быть в текстовом формате. Как же мы отправляем изображения по электронной почте? Как внедряем картинки на веб-страницы? Один из вариантов — поставить ссылку на реальный бинарный файл. Другой типичный подход — встроить бинарный файл непосредственно в тело письма или веб-страницы с помощью base64. Base64 — это просто стандартный текстовый формат, который можно использовать для кодирования любых бинарных данных. Если быть точным, то код base64 — всегда валидный текст ASCII (и поэтому также валидный UTF-8). Каждый байт кода base64 содержит 6 бит данных. То есть мы «теряем» примерно 2 бита на байт. Поэтому эквивалент base64 бинарного файла будет примерно на 33% больше. На практике такое увеличение размера редко становится проблемой. Насколько я знаю, приложения к электронным письмам почти всегда кодируются в base64.

      При написании HTML я нашёл удобным внедрять изображения напрямую в HTML-код с помощью схемы data URI. Например, в недавней статье я таким образом закодировал файл PNG. Крупнейшие веб-сайты вроде Google постоянно используют эту схему. Небольшим недостатком становится то, что веб-страницы чуть увеличиваются в размере (что очевидно) и нельзя воспользоваться преимуществами кэширования изображений. Но зато браузер экономит один сетевой запрос.
      Читать дальше →
      • +18
      • 7,6k
      • 8
    • Как писать чистый и красивый код

      • Перевод
      Каким должен быть качественный код? Роберт Мартин выразил это невероятно точно, когда сказал: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» в минуту».

      image

      Позвольте мне пояснить эту идею.
      Читать дальше →
    • Альтернативная архитектура СУБД и подход к разработке приложений

      Я расскажу о технологической платформе, пригодной для создания информационного ядра системы или приложения. Платформа содержит простой высокоуровневый конструктор модели данных и базовый интерфейс для работы с ней, поддерживает ролевую модель доступа, эмулятор запросов SQL (CRUD), API, а также дает возможность загружать произвольные рабочие места — элементы UI — и наполнять их данными.

      У платформы есть некоторые принципиальные отличия от бесконечного множества «конструкторов», из-за чего она и появилась. Некоторые из отличий достойны качественного холивара, другие просто упрощают жизнь разработчика, кем бы он ни был. Несколько приложений уже работают у живых клиентов, из них будут приведены рабочие примеры выполнения задач.

      Здесь вы можете собрать веб-приложение, не изучая язык программирования: мы оперируем только бизнес-терминами и формулами, не сложнее, чем в MS Excel. Безусловно, понимание принципов работы баз данных поможет вам разработать более живучий, масштабный и богатый функционалом продукт, но этот сервис не требует специфических знаний для простых решений, которые составляют, навскидку, не меньше 80% прикладной разработки (например, кустарной и всего, что сейчас работает в Экселе).
      Ну-ну, продолжай
    • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

      Подробнее
      Реклама
    • [Видео] Доклады с митапа iOS-разработчиков Red Hot Chili Apples


        Прошлый год закончился регулярной встречей iOS-разработчиков Red Hot Chili Apples. Под катом вы найдете записи докладов об альтернативе VIPER, базовых принципах функционального программирования на iOS, а также о том, как делать качественный проект при ограниченных ресурсах.

        Читать дальше →
      • Spectre и Meltdown

        Все как всегда, слышим звон, но не знаем где он


        В сети произошел очередной слив информации об двух уязвимостях в аппаратуре современных процессоров. Собственно уязвимость была открыта для публичного обсуждения одна, но методов ее эксплуатации было раскрыто два, под именами Spectre и Meltdown.
        Для специалистов эта проблема оборудования известна давно, она «втихую» эксплуатировалась и все были довольны…
        Читать дальше →
      • Программирование превращается в помойку

          Программирование превращается в помойку.
          Я в этом твёрдо уверен. Мы стоим на краю пропасти, а возможно — и вовсе, уже спрыгнули. Думаете ли вы также? Чувствуете ли это?.. В любом случае, я должен объясниться. Дело в том, что программирование становиться грязным. Грязным в том смысле, что противоположен смыслу элегантности. Запутанные, и в то же время пустые в сути — вот каковы программы нашего века.

          Попытки радикальной унификации пришли на смену аналогичным попыткам радикальной спецификации, столь популярным в прошлом веке. Видимо, напуганные хакерской изощрённостью, мы теперь не замечаем изощрённой глупости наших собственных программ. И если у хакеров было оправдание — они писали «эфективный» код, то у нас — оправдания нет. Все наши потуги нацелены на избавление от сложности, но, что иронично, они лишь делают всё сложней, добавляя всё новые и новые «универсальные» решения.
          Читать дальше →
        • Путь верстальщика: с нуля до сеньора

            Здравствуйте, меня зовут Александр Зеленин, и я веб-разработчик.
            Многократно я слышал мнение, что верстка — удел начинающих frontend’еров. Хотя фактически это важнейшая часть любого (почти) веб-проекта. Это то, что пользователи видят в первую очередь. На текущий момент качественная вёрстка (особенно проектирование блоков) в крупном проекте требует большого количества различных навыков.


            В данной статье представляю схему развития верстальщика


            image
            [большая по клику]
            Само собой, это не всеобъемлющая и единственно верная схема. Есть ещё целая гора связанных навыков, релевантных технологий и так далее. Градация является субъективной.

            Описание пути код катом
          Самое читаемое