• Ад своими руками

      Многие говорят – рассказывать надо не только об успехах, но и о неудачах. Полностью с этим согласен — понимание своих неудач, их причин и последствий, иногда ценнее любых успехов.

      Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

      Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

      Обо всем по порядку.
      Читать дальше →
    • Приверженцы статической и динамической типизаций никогда не поймут друг друга. И TypeScript им не поможет



        Когда мы с другом учились в школе и только мечтали стать разрабами, мы думали как сделаем вместе какую-нибудь штуковину — игру или супер-полезную программу.

        Я начал учить плюсы и C#, он — JavaScript. Закончили школу, отучились в универах, отслужили в армии, устроились на работы. Нас потаскало промышленной разработкой там и тут, и когда мы оба от нее подустали, вспомнили с чего начинали.

        Собравшись уже матерыми разрабами, мы решили, наконец, сделать свой проект — двумерную видеоигру. Так как друг был чистый фронт, а я фулстек, очевидной платформой для нас стал браузер. Раньше я разрабатывал фронт только на TypeScript, и мы подумали, никаких проблем, TS — всего-лишь надмножество JavaScript. Возьмем его и все пройдет гладко. Как бы не так. Когда мы начали обсуждать работу, столкнулись с невероятной бездной непонимания друг друга.
        Читать дальше →
      • Опыт использования гибрида клавиатуры и мыши в программировании

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


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



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

        Читать дальше →
      • Шесть парадигм программирования, которые изменят ваш взгляд на код

        • Translation
        Периодически я натыкаюсь на языки программирования, которые настолько самобытны, что меняют моё представление о коде в целом. В этой статье я хотел бы поделиться некоторыми из самых любимых моих находок.

        Здесь вы не найдёте устаревшего посыла «функциональное программирование спасёт мир!»; мой список состоит из куда менее популярных наименований. Готов поспорить, многие из читателей вообще не слышали о большинстве языков и парадигм, о которых пойдёт речь, так что надеюсь, вам будет так же интересно с ними разбираться, как и мне.

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


        Читать дальше →
      • Тёмный путь

        • Translation

        image


        Предлагаю вашему вниманию перевод оригинальной статьи Роберта С. Мартина.


        За последние несколько месяцев я попробовал два новых языка. Swift и Kotlin. У этих двух языков есть ряд общих особенностей. Действительно, сходство настолько сильное, что мне стало интересно, не является ли это новой тенденцией в нашей языкомешалке. Если это действительно так, то это тёмный путь.


        Оба языка включают в себя некоторые функциональные характеристики. Например, в них обоих есть лямбды. В целом, это хорошая штука. Чем больше мы узнаем о функциональном программировании, тем лучше. Эти языки далеки от по-настоящему функционального языка программирования; но каждый шаг в этом направлении — хороший шаг.


        Проблема в том, что оба языка сделали ставку на сильную статическую типизацию. Кажется, оба намерены заткнуть каждую дыру в своём родном языке. В случае со Swift – это странный гибрид C и Smalltalk, который называется Objective-C; поэтому, возможно, упор на типизацию понятен. Что касается Kotlin – его предком является уже довольно строго типизированная Java.


        Я не хочу, чтобы вы думали, что я против статически типизированных языков. Я не против. Есть определенные преимущества как для динамических, так и для статических языков; и я с удовольствием пользуюсь обоими видами. Я предпочитаю динамическую типизацию, и поэтому я иногда использую Clojure. С другой стороны, я, вероятно, пишу больше Java, чем Clojure. Поэтому вы можете считать меня би-типичным. Я иду по обеим сторонам улицы — если так можно выразиться.


        Дело не в том, что меня беспокоит статическая типизация Swift и Kotlin. Скорее меня беспокоит глубина статической типизации.

        Погрузиться в пучину тьмы
      • Разбираемся с SOLID: Инверсия зависимостей

          Давайте глянем на определение принципа инверсии зависимостей из википедии:


          Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

          Формулировка:

          A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
          B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

          Большинство разработчиков, с которыми мне доводилось общаться, понимают только вторую часть определения. Мол "ну а что тут такого, надо завязывать классы не на конкретную реализацию а на интерфейс". И вроде бы верно, но только кому должен принадлежать интерфейс? Да и почему вообще этот принцип так важен? Давайте разбираться.

          Читать дальше →
        • Статическая и динамическая типизация

          • Translation

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



          Тип — это коллекция возможных значений. Целое число может обладать значениями 0, 1, 2, 3 и так далее. Булево может быть истиной или ложью. Можно придумать свой тип, например, тип "ДайПять", в котором возможны значения "дай" и "5", и больше ничего. Это не строка и не число, это новый, отдельный тип.


          Статически типизированные языки ограничивают типы переменных: язык программирования может знать, например, что x — это Integer. В этом случае программисту запрещается делать x = true, это будет некорректный код. Компилятор откажется компилировать его, так что мы не сможем даже запустить такой код. Другой статически типизированный язык может обладать другими выразительными возможностями, и никакая из популярных систем типов не способна выразить наш тип ДайПять (но многие могут выразить другие, более изощренные идеи).


          Динамически типизированные языки помечают значения типами: язык знает, что 1 это integer, 2 это integer, но он не может знать, что переменная x всегда содержит integer.


          Среда выполнения языка проверяет эти метки в разные моменты времени. Если мы попробуем сложить два значения, то она может проверить, являются ли они числами, строками или массивами. Потом она сложит эти значения, склеит их или выдаст ошибку, в зависимости от типа.

          Читать дальше →
        • А нужно ли знать программисту алгоритмы?

            Не встречали еще разработчика, который вместо стандартной в скриптовом языке функции деления строки по регулярке — пишет C-подобный код с конечным автоматом, который вводит неокрепшие умы в трепет?

            И так ужасно ли то, что ты не знаешь в тонкостях работу красно-черных деревьев или путаешь линейный дискриминантный анализ с вторым законом Ньютона?
            Читать дальше →
          • Почему умер Хабр. Что делать и куда бежать

              Disclaimer. Этот пост — развёрнутый ответ на пост Хабр умирает?.

              В исходном посте я дал ссылку на свою дискуссию с deniskin от ноября 2014 года (чуть позднее точки на графике ТС, когда Хабр начал умирать): habrahabr.ru/post/278325/#comment_8789143

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

              Исходный тезис звучит следующим образом: Хабр убило прежде всего непонимание Тематическими Медиа, что такое Хабрахабр и почему он взлетел — в отличие от прочих ТМ проектов, половину из которых уже закопали, а другая половина летит низенько-низенько.

              Дело в том, что Хабр в том его виде, в котором он существовал в 2010 году, был вовсе не «сайтом про IT» типа 3dnews и Ferra. Хабр был, в первую очередь, кружком по интересам. Собралась кучка гиков и обсуждала, в общем, то, что им самим интересно — включая, но не ограничиваясь, космос, настолки, вещества, теорию эволюции, жадность копирастов, гребёнку Чурова и прочая. Периодически ТМ устраивала набеги и банила особо жестокий флейм, но, в целом, ситуация всех устраивала.
              В принципе, основную мысль я изложил, под катом хроника борьбы слона с посудной лавкой
            • Поняв Docker

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


                К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!


                UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.


                Что мы имеем сегодня


                • Зоопарк дубовых VPS-хостингов.
                • Дорогие IaaS и PaaS с гарантированным vendor lock in.
                • Уникальные сервера-снежинки.
                • Ворох устаревших зависимостей на неподдерживаемой операционке.
                • Скрытые связи частей приложения.
                • Незаменимый админ полубог на скейтборде.
                • Радуга окружений: development, testing, integration, staging, production.
                • Генерация конфигов для системы управления конфигами.
                • Feature flagging.
                docker run docker
              • Почему я больше не использую MVC-фреймворки

                • Translation


                Уважаемые хабравчане.

                Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

                Вы можете пообщаться с ним лично в следующих чатах:
                https://gitter.im/jdubray/sam
                https://gitter.im/jdubray/sam-examples
                https://gitter.im/jdubray/sam-architecture

                Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

                По поводу кода он оставил следующий комментарий:
                I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).
                Читать дальше →
              • 40 ключевых концепций информационных технологий доступно и понятно

                • Translation
                Представляю вашему вниманию перевод очень ёмкой, и в то же время достаточно краткой (для такого масштаба проблемы) статьи Карла Чео. Я решил, что очень хочу сделать её перевод практически сразу, как только начал читать, и очень рад, что в итоге сделал это.
                Для того, чтобы сделать обучение более веселым и интересным, представляю вам перечень важных теорий и концепций информатики, объяснённых с помощью аналогий с минимальным количеством технических деталей. Это будет похоже на очень быстрый курс информатики для всех с целью просто дать вам общее представление об основных концепциях.

                Важные замечания:
                • Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
                • Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
                • Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

                Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.
                Читать дальше →
              • Знакомимся с Otto, наследником Vagrant

                  Otto — это новый продукт от Hashicorp, логический наследник Vagrant, призванный упростить процесс разработки и деплоя программ в современном мире облачных технологий. Концептуально новый подход к проблеме, проверенные технологии под капотом и открытый исходный код. Персональный DevOps ассистент разработчика.


                  Читать дальше →
                  • +21
                  • 31.8k
                  • 9
                • Консоль 21 века: mosh, tmux, fish

                    В своей работе мне приходится проводить чуть ли не все свое время в консоли, как в локальной, так и в удаленной. Нет, что вы, я не жалуюсь, даже наоборот — мне нравятся возможности автоматизации, которые предоставляют консольные инструменты, и работа в консоли вполне продуктивна.

                    Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

                    Проблемы ssh


                    При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

                    1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
                    2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval


                    Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

                    Читать дальше →
                  • Введение в функциональное программирование на Python

                    • Translation
                    Рассуждая о функциональном программировании, люди часто начинают выдавать кучу «функциональных» характеристик. Неизменяемые данные, функции первого класса и оптимизация хвостовой рекурсии. Это свойства языка, помогающие писать функциональные программы. Они упоминают мапирование, каррирование и использование функций высшего порядка. Это приёмы программирования, использующиеся для написания функционального кода. Они упоминают распараллеливание, ленивые вычисления и детерменизм. Это преимущества функциональных программ.

                    Забейте. Функциональный код отличается одним свойством: отсутствием побочных эффектов. Он не полагается на данные вне текущей функции, и не меняет данные, находящиеся вне функции. Все остальные «свойства» можно вывести из этого.

                    Нефункциональная функция:

                    a = 0
                    def increment1():
                        global a
                        a += 1
                    


                    Функциональная функция:

                    def increment2(a):
                        return a + 1
                    


                    Вместо проходов по списку используйте map и reduce
                    Читать дальше →
                  • Именованные параметры C++. Не пригодились

                      Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.
                      Читать дальше →
                    • Я — сертифицированный PHP-специалист

                      Да, наверное, возможность применения данного выражения — греет кому-то душу, но я немного о другом.

                      Разрешите поделиться опытом прохождения сертификации по PHP 5.5 от компании Zend Technologies.

                      Моя цель:
                      • показать на примере, что это не так сложно, как кажется;
                      • не так легко, как может показаться;
                      • показать еще один весьма субъективный метод подготовки к тесту;
                      • вдохновить тех из коллег, которые возможно планировали сертификацию, но все не решались это сделать.

                      Путь от «да, я хочу получить статус ZCE» до покупки ваучера


                      4 года — ровно столько времени потребовалось от простого «Да, не плохо было бы получить сертификат» до «Девушка, смотрите, а я сдал»

                      Если у вас появится такая мысль, то открывая в очередной раз Америку, скажу — вам помогут: правильно и ясно поставленная цель; четко разграниченные сроки; план действий.

                      Цель


                      Записывать поставленные цели — старо как мир, однако, о ведении записей и планировании жизни как таковой я раньше не задумывался. «Стать десятым ZCE в Казахстане» — одна из первых записанных на бумаге и достигнутых целей.
                      В этом плане нам технарям не нужно стесняться учиться и перенимать опыт у тимлидов, руководителей проектов и топ-менеджеров. Жизнь — это не только код, фичи и багфиксы.
                      Читать дальше →
                    • Обзор мини-клавиатуры Ducky Mini

                        Здравствуйте все!

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

                        Многие, кто интересуется механическими клавиатурами, слышали про тайваньскую компанию Ducky Channel. Недавно у них появился официальный ресселер в России, что не может не радовать (еще бы курс доллара был пониже, тогда счастья были бы полны мои шорты).

                        У этого ресселера (не буду называть его, поскольку будет рекламой, посмотреть можете на сайте компании в разделе Where to buy) я и приобрел данную клавиатуру по предзаказу.


                        Читать дальше →
                      • За один проход

                          Среди задач по программированию часто попадаются такие: дана последовательность однотипных элементов (обычно это числа), требуется за один проход по ней найти какую-нибудь характеристику (среднее квадратическое отклонение, количество минимальных элементов, непрерывный участок с наибольшей суммой...) Дополнительное ограничение — последовательность может быть очень длинной, и в память не поместится. Других ограничений на элементы последовательности, обычно, не накладывается.
                          С этими задачами всё, более или менее, понятно: нужно найти то, что на мехмате МГУ называют «индуктивным расширением» искомой функции, и реализовать её вычисление. Если найти не удалось (требуемый объём памяти слишком велик), то задача не решается.
                          Но попадаются и другие задачи. В них есть дополнительные ограничения на элементы последовательности в совокупности, и эти ограничения приходится существенно использовать для решения (и проверять их не надо). Простейшая такая задача выглядит так:

                          Задача 1. В последовательности записаны целые числа от 1 до N в произвольном порядке, но одно из чисел пропущено (остальные встречаются ровно по одному разу). N заранее неизвестно. Определить пропущенное число

                          Решение очевидно: просматриваем числа, находим их количество K и сумму S. По условию, N=K+1, значит, сумма чисел от 1 до N будет равна (K+1)*(K+2)/2, и пропущенное число равно (K+1)*(K+2)/2-S. Если вы почему-то боитесь переполнений, то работайте с беззнаковыми числами (там переполнения не страшны — но будьте осторожны при вычислении (K+1)*(K+2)/2 :) ), или вместо суммы ищите XOR всех чисел.
                          Другие задачи
                        • Личные финансы — сохранить и приумножить

                            Современный капитализм обусловил одни простой житейский «закон» — богатые становятся богаче, бедные — еще беднее. Так как больше денег -> больше возможностей заработать -> больше денег. Нам, работникам IT, немного повезло. Благодаря спросу на наш труд, который нам, чего уж скрывать, нравится, мы застряли где-то посередине — средств хватает на удовлетворение большего числа основных потребностей и еще остается небольшой излишек.

                            И вот тут многих начинает волновать вопрос — «что с ним делать?». Многие сделав вывод что «хранить нельзя» в решении вопроса идут дальше и задаются следующим вопросом: «во что инвестировать?». Возникает еще один попутный вопрос: «как обеспечить себе старость?».

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

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

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