• Мины под производительностью ждут своего часа

      В этой статье я расскажу о минах, заложенных под производительность, а также об их обнаружении (желательно ещё до взрыва) и обезвреживании.


      Картинка для привлечения внимания

      image

      Читать дальше →
    • О статическом анализе начистоту

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


        Читать дальше →
        • +32
        • 8.4k
        • 2
      • «Я бесполезный дурак и хочу уволиться» — 10 вопросов программисту, пилотный выпуск



          Привет, Хабр!

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

          Мы в редакции Хабра намерены это исправлять. Отныне будем регулярно брать интервью у людей, про которых не пишут в СМИ и за которыми не гоняются в соцсетях. Так что если вам есть что о себе рассказать — готовьтесь.

          Чтобы вы поняли, как оно будет выглядеть, начнем со своего примера. Под катом 10 общих вопросов, которые мы будем задавать всем. Для пилота на них ответил fillpackart. (В этом месяце я брал вместе с ним несколько, кажется, неплохих интервью: раз, два, три). Почитайте, и если хотите рассказать о себе таким же образом, пишите сообщения мне или baragol.
          Читать дальше →
        • Проще, чем кажется. Главы 4-5

            «Проще, чем кажется» — бизнес-роман о том, на что еще способны программисты.


            4


            — Ты задачу по бухгалтерии сделал? Отчет. Ты обещал сегодня закончить.

            — Сегодня и закончу, еще весь день впереди. Не надо из-за этого переживать, Галина.

            — О чем ты хотел поговорить?

            — О зарплате.

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

              Привет, Хабр! Говорят, чистосердечное признание смягчает наказание. Каюсь — большая часть статьи будет откровенным копипастом чужого текста. Прошу модераторов не судить строго и считать огромной цитатой. Потому что лучше не скажешь. Потому что я, вы, ты, читатель, — все мы там были или можем быть. В больших межгалактических корпорациях компаниях, которые заманивают офисами, всевозможными плюшками из рога изобилия, самокатами в коридорах и прочими релакс-капсулами, но редко говорят, что будет взамен. А взамен будут бесконечные совещания, легаси, инерция и… мать его, одинокое ощущение себя маленьким винтиком какой-то адовой машины. Начну со своей истории — в одном абзаце. А потом — просто откровенная бомба — текст, каждое слово которого крепко отозвалось во мне, вроде суровом дядьке.


              Читать дальше →
            • Пора убить веб

              • Translation
              Что-то происходит. Люди недовольны. Призрак гражданских беспорядков преследует наши программистские сообщества.

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


              Это ты, хакер фронтенда
              Читать дальше →
            • Странности Generic типов Java

                Я множество раз слышал о том, что дизайн Generic типов в Java является неудачным. По большей части претензии сводятся к отсутствию поддержки примитивных типов (которую планируют добавить) и к стиранию типов, а конкретнее — невозможности получить фактический тип параметра в рантайме. Лично я не считаю стирание типов проблемой, как и дизайн Generic-ов плохим. Но есть моменты, которые меня порядком раздражают, но при этом не так часто упоминаются.


                1


                Например, мы знаем, что метод Class#getAnnotation параметризован и имеет следующую сигнатуру: public <A extends Annotation> A getAnnotation(Class<A> annotationClass). Значит, можно писать вот такой код:


                Deprecated d = Object.class.getAnnotation(Deprecated.class);

                Тут я решаю вынести Object.class в отдельную переменную и код перестаёт компилироваться:


                Class clazz = Object.class;
                // incompatible types:
                // java.lang.annotation.Annotation cannot be converted to java.lang.Deprecated
                Deprecated d = clazz.getAnnotation(Deprecated.class);

                Где я ошибся?

                Читать дальше →
              • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое

                • Translation

                Мы рады представить вам Kotlin 1.1, новую версию языка программирования Kotlin.


                Kotlin 1.1

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


                Читать дальше →
              • Пишем MVP приложение на Kotlin под Android



                  Разработка приложений на Kotlin под Android набирает популярность среди разработчиков, однако статей в русскоязычном сегменте Интернета довольно мало. Я решил немного подправить ситуацию, и написать туториал по разработке приложения на Kotlin. Мы напишем полноценное приложение с использованием всех трендовых библиотек (кроме RxJava) в мире Android-разработки. В конце у нас должно получиться расширяемое и легко тестируемое приложение (сами тесты мы писать не будем).
                  Читать дальше →
                • Kotlin 1.0. Задай вопрос команде

                    На этой неделе случилось важное для нас событие — вышла первая версия языка программирования Kotlin! Так как почти вся разработка Kotlin велась в Питерском офисе компании JetBrains, многие хабровчане уже знают, что такое Kotlin и пробовали его на практике, поэтому этот пост больше для комментариев: задавайте любые вопросы и команда Kotlin ответит. Мы онлайн!

                    image

                    Читать дальше →
                  • Полвека «универсальным машинным языкам» (1966—2016): прошлое, настоящее, будущее

                      КДПВ

                      Прошлое


                      Повествование можно начать с 1962 г., когда в Кембриджском университете началась работа над CPL («Cambridge Programming Language») — «усовершенствованным вариантом» ALGOL-60. К работе над языком подключился аспирант Мартин Ричардс; главной сложностью в реализации нового ЯП ему показалась необходимость ручного портирования компилятора для разных компьютерных платформ. В частности, когда кембриджский EDSAC-2 заменили на Atlas-2, разработчики CPL потратили много времени на портирование своего компилятора для новой платформы.

                      Диссертация Мартина была посвящена «само-компилирующемуся» CPL: разработанный Мартином компилятор был написан на сильно упрощённом варианте CPL, компилятор которого несложно было написать на тогдашнем макроассемблере. Перенос CPL на новую платформу теперь можно было выполнить в два шага:
                      1. Вручную пишем компилятор «упрощённого CPL»;
                      2. Компилируем им компилятор «полного CPL».

                      На этом Мартин не остановился, и разработал BCPL — систему для разработки переносимых компиляторов. Компилятор BCPL генерировал псевдокод, названный Мартином «OCODE».
                      OCODE выглядел примерно так:
                      OCODE «расшифровка» («procode»)
                      94 5 L1 83 73 69 86 69
                      95 4
                      42 0
                      42 0 40 2 14
                      83
                      42 0 42 1 40 2 14 83
                      42 2
                      40 3 42 1 15
                      92
                      85 L5
                      90 L6
                      42 1 40 4 40 2 14 83
                      40 4 42 1 14 80 4 
                      90 5 40 4 40 5 88 L6
                      91 4
                      42 2 40 3 42 1 15 92
                      85 L7
                      90 L8 40 4 40 2 14
                      8 87 L9
                      40 4 42 2 11 92
                      85 L11
                      90 L10
                      42 0 40 6 40 2 14 83
                      40 4 40 6 14 80 6
                      90 L11
                      40 6 40 3 22 86 L10
                      91 6 90 L9
                      40 4 42 1 14 80 4
                      90 L7 40 4 40 5 88 L8
                      91 4 97 103 0
                      
                      ENTRY 5 L1  'S' 'I' 'E' 'V' 'E'
                      SAVE 4
                      LN 0
                      LN 0 LP 2 PLUS
                      STIND
                      LN 0 LN 1 LP 2 PLUS STIND
                      LN 2
                      LP 3 LN 1 MINUS
                      STORE
                      JUMP L5
                      LAB L6
                      LN 1 LP 4 LP 2 PLUS STIND
                      LP 4 LN 1 PLUS SP 4
                      LAB L5 LP 4 LP 5 ENDFOR L6
                      STACK 4
                      LN 2 LP 3 LN 1 MINUS STORE
                      JUMP L7
                      LAB L8 LP 4 LP 2 PLUS
                      RV JF L9
                      LP 4 LN 2 MULT STORE
                      JUMP L11
                      LAB L10
                      LN 0 LP 6 LP 2 PLUS STIND
                      LP 4 LP 6 PLUS SP 6
                      LAB L11
                      LP 6 LP 3 LS JT L10
                      STACK 6 LAB L9
                      LP 4 LN 1 PLUS SP 4
                      LAB L7 LP 4 LP 5 ENDFOR L8
                      STACK 4 RTRN ENDPROC 0
                      
                      ; заголовок процедуры
                      ; стековый кадр (два параметра и две локальные переменные)
                      ; поместить на стек число 0
                      ; поместить ещё один 0, прибавить к нему 2-ой элемент стека
                      ; записать в массив на вершине стека значение под ним
                      ; всё то же самое для 1-ого элемента массива
                      ; поместить на стек число 2
                      ; вычесть единицу из значения 3-его элемента стека
                      ; записать результат в локальную переменную
                      ; перейти к метке L5
                      ; объявление метки L6
                      ; взять 4-ый элемент стека, записать в массив по этому индексу 1
                      ; прибавить к 4-ому элементу стека 1, записать результат обратно
                      ; L5: перейти к метке L6, если 4-ый элемент стека <= 5-ому
                      ; объявление, что на стеке сейчас четыре элемента
                      ; вычесть единицу из значения 3-его элемента стека
                      ; перейти к метке L7
                      ; L8: сложить 4-ый и 2-ой элементы стека
                      ; прочитать значение по этому адресу; если это 0, перейти к L9
                      ; умножить 4-ый элемент на два
                      ; перейти к метке L11
                      ; объявление метки L10
                      ; взять 6-ой элемент стека, записать в массив по этому индексу 0
                      ; прибавить к 6-ому элементу стека 4-ый, записать рез-т обратно
                      ; объявление метки L11
                      ; перейти к метке L10, если 7-ой элемент стека меньше 4-ого
                      ; на стеке сейчас шесть элементов; объявление метки L9
                      ; прибавить к 4-ому элементу стека 1, записать результат обратно
                      ; L10: перейти к L8, если 4-ый элемент стека <= 5-ому
                      ; на стеке четыре элемента; окончание процедуры
                      (Для экономии места, последовательности команд записаны в одну строчку. Мартин в своём руководстве по BCPL поступает точно так же.)

                      Исходный код на BCPL:
                      LET sieve(workvec, vecsize) BE
                      {
                        workvec!0 := 0
                        workvec!1 := 0
                        FOR i = 2 TO vecsize-1 DO workvec!i := 1
                        FOR i = 2 TO vecsize-1 DO
                          IF workvec!i DO
                          { LET j = 2 * i
                            WHILE j < vecsize DO
                            { workvec!j := 0
                              j := j + i
                            }
                          }
                      }
                      
                      В более новых версиях OCODE добавилась поддержка чисел с плавающей точкой (соответственно, набор поддерживаемых опкодов почти удвоился), а также удалили опкод ENDFOR — вместо него генерируется пара LE JT.

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

                      Компилятор BCPL(1) поставлялся в виде OCODE, и чтобы перенести его на новую платформу, нужно было:
                      1. Вручную написать интерпретатор псевдокода(2) (на любом языке, хоть на Бейсике);
                      2. Адаптировать кодогенератор,(3) написанный на BCPL, для своей платформы;
                      3. Запустить под интерпретатором (2) компилятор BCPL (1), скормить ему кодогенератор (3), и получить на выходе исполнимый файл кодогенератора(4);
                        • Интерпретатор (2) нам с этого момента больше не нужен.
                      4. Прогнать через кодогенератор (4) псевдокод компилятора (1), и получить на выходе исполнимый файл компилятора.


                      Такой подход означал, что для переноса компилятора на новую платформу требуется лишь самый минимум низкоуровневого программирования; и действительно, реализация BCPL была завершена к 1967 г. — раньше, чем была завершена реализация CPL, начатая на несколько лет раньше!

                      Достоинства BCPL применительно к системному программированию вдохновили Кена Томпсона на создание языка Би, а тот — коллегу Кена, Денниса Ритчи, на создание Си. Именно из BCPL пошла традиция обозначать {фигурными скобками} блоки программы, и именно на BCPL была написана первая программа «Hello, World!».
                      GET "libhdr"
                      
                      LET start() = VALOF
                      { writef("Hello*n")
                        RESULTIS 0
                      }
                      
                      Более важная нам причина, по которой BCPL вошёл в историю: OCODE — первая универсальная «архитектура набора команд» (ISA), т.е. «виртуальная машина», не привязанная ни к какой конкретной аппаратной платформе с её особенностями. BCPL, таким образом — первый язык программирования, соответствующий парадигме «Write once, run anywhere» (WORA): программу на BCPL можно распространять в скомпилированном виде, и её можно будет запустить на любой платформе, для которой существует OCODE-кодогенератор.
                      Читать дальше →
                    • Про Бурали-Форти, Пуанкаре и то самое определение единицы

                        Если вы, уважаемый мой читатель, имеете обыкновение проводить много времени в интернете, вы наверняка уже видели эту картинку с цитатой:

                        image

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

                        В нижеследующем тексте я раскрою перед вами тайну этого загадочного сочетания символов. Пожалуйте под кат, однако помните поучительную историю о любопытной Варваре, которой на базаре рассказали про парадокс Банаха-Тарского, отчего она сошла с ума, разрезала себе нос на конечное количество частей и склеила из них рогатую сферу Александера.
                        N.B. Я предупреждал.
                      • Про модель, логику, ООП, разработку и остальное

                          Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
                          Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
                          Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
                          Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.
                          Читать дальше →
                        • Постиндустриальное общество: ценности, семья, мораль и право

                            Disclaimer. Написать этот топик меня побудил комментарий nail84 к предыдущему бестселлеру про порнографию.

                            Современное западное общество является, с социологической точки зрения, совершенно уникальным. Перечислю вкратце: эмансипация женщин; либерализация права (легализация наркотиков, проституции, однополых браков, et cetera); либерализация морали, в т.ч. сексуальной; распад традиционной семьи; длинное детство и длительное образование; деградация института брака; снижение рождаемости и повышение фертильного возраста; консюмеризм — все эти явления в совокупности никогда не встречались в человеческой истории.

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

                            P.S. Топик в персональных блогах, не хочешь — не читай. Писать в комменты «это не для Хабра!!! одынодын» не надо.

                            Поехали
                          • Критерий выгодности подстановки и динамическая профилировка

                              image

                              Продолжаю тему межпроцедурных оптимизаций, введение в которую можно найти в предыдущем посте. Сегодня хочется немного порассуждать о подстановке функции (inlining) и о том, как подстановка влияет на производительность приложения.
                              Читать дальше →
                              • +28
                              • 7.6k
                              • 2
                            • О великих велосипедах, или почему иногда нужно писать с нуля

                                Not invented here — источник инноваций и причина успеха?


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


                                Очень часто в компаниях выступают против синдрома «not invented here». Я, как менеджер проектов, прекрасно понимаю соображения такого толка. Велосипеды — это лишние затраты, удлинение сроков разработки, сложность и дороговизна поддержки продукта в будущем, зависимость от разработчиков велосипеда и все такое прочее.

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

                                Не случайно поэтому Гугл выделяет 20% на свободное творчество, и это рождает такие великолепные переосмысления старых вещей, как почтовый клиент Gmail.

                                Но обо все по порядку. В этой статье я хочу коротко рассказать о трех «велосипедах», которые произвели революцию в своей области.
                                Читать дальше →
                              • Table bloat? Не, не слышал…



                                  Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.
                                  что?
                                • Взгляд рядового программиста на вектор изменения оболочек и что делать дальше

                                    imageLinux на моём компьютере уже 5 лет стоит как основная операционная система. Пришлось проходить через всякое: ставить разные дистрибутивы, как для фана, так и для работы. Почти все шесть лет я сидел на Gnome 2, и сейчас бы сидел, если бы не новый ноутбук, нормально работающий только на третьем ядре из-за каких-то драйверов. А с новым ядром пришла новая проблема: новые оболочки. В этом топике я просто опишу свои мысли насчет оболочек, чем они удобны или не удобны лично для меня. Так что, можете сразу ставить после каждого предложения ИМХО.
                                    Подробности
                                  • А как же всё-таки работает многопоточность? Часть I: синхронизация

                                    • Tutorial
                                    картинка для привлечения внимания(пост из серии «я склонировал себе исходники hotspot, давайте посмотрим на них вместе»)
                                    Все, кто сталкивается с многопоточными проблемами (будь то производительность или непонятные гейзенбаги), неизбежно сталкиваются в процессе их решения с терминами вроде «inflation», «contention», «membar», «biased locking», «thread parking» и тому подобным. А вот все ли действительно знают, что за этими терминами скрывается? К сожалению, как показывает практика, не все.

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

                                    Перед прочтением глубокого описания полезно убедиться в том, что вы в достаточной мере разбираетесь в Java Memory Model. Изучить её можно, например, по слайдам Сергея Walrus Куксенко или по моему раннему топику. Также отличным материалом является вот эта презентация, начиная со слайда #38.
                                    Читать дальше. Много.
                                  • О повторном использовании кода

                                      Сегодня существуют разные мнения по поводу успешности объектной технологии. С одной стороны, большинство современных mainstream языков программирования являются объектно-ориентированными, с другой стороны, нередко можно услышать критику ООП, дескать, объектно-ориентированное программирование «провалилось» и не оправдало тех надежд, которые были возложены на нее индустрией разработки ПО. Все, мол, ожидали наступления вселенского счастья в виде увеличения повторного использования, упрощения сопровождения, да и вообще, обещали, что думать придется кому-то другому, а я за это буду деньги получать.
                                      Читать дальше →