Блог Хекслета

Подкаст Рахима Давлеткалиева до 2019 года выходил под брендом «Хекслет». Сейчас он переименован в «Мысли и методы». Все старые и новые выпуски доступны тут:

• Блог Рахима
• Soundcloud
• iTunes
• Новые выпуски на YouTube (+ старые на канале Хекслета)
• RSS

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

Вкратце: с обычного офисного админа в небольшом городе, занимающегося всем, от протяжки сети и ползания под столами пользователей до попыток изучения современных средств администрирования, типа Ansible и Docker, я дорос до более-менее уверенного devops-специалиста, работающего с московскими компаниями.

Для настройки окружения проекта можно использовать (а многие так и делают) стандартные средства операционной системы. Такие, как пакетный менеджер (yum, apt), прямое редактирование конфигурационных файлов, bash-скрипты, curl/wget и многое другое.

Этот подход, с одной стороны, самый простой, но он обладает рядом недостатков, некоторые из которых критические.

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

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

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

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

пример рекурсии: художник рисует картину, в которой он рисует картину, в которой он рисует картину...

Теперь на секунду забудем про рекурсию, и просто подумаем про компьютеры. Для выполнения задач компьютерам нужны инструкции. Когда компьютер выполняет набор инструкций — это процесс. Ваш работающий сейчас браузер — это процесс. Простой цикл, выводящий на экран десять раз число "42" — это процесс. Некоторые задачи можно решать рекурсивно, то есть в инструкциях использовать эту концепцию, когда что-то является частью самого себя. В частности, функция может быть частью самой себя, то есть вызывать саму себя.

Нам часто пишут о том, что сложно понять, в каком порядке выполняется код и как, в целом, происходит процесс вычисления. Например:

Здравствуйте! Сначала прошел задание, а затем у меня появился вопрос. Проверка strings.toUpperCase(char) === char сначала переводит символ в верхний регистр, а потом сравнивает с ним же? Или происходит просто проверка без перевода? По логике кода происходит второй вариант, но все же хочу уточнить, т.к. согласно учебника .toUpperCase() именно переводит в верхний регистр.

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

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

1. Производство (разработка)
2. Сборка
3. Контроль и испытания
4. Доставка

function hammingWeight($weight)
{
    $array = str_split(decbin($weight));
    $amount = 0;
    foreach ($array as $value) {
        $amount += $value;
    }
    return $amount;
}

• Понятно ли с первого взгляда что делает функция (основываясь на содержимом)?
• Попробуйте воспроизвести определение понятия "Вес Хемминга" глядя только на код

Говорим с Екатериной Гавриловой из DigitalHR http://digitalhr.ru/

Как проходит день HR'а, какие задачи решают HR'ы и как они это делают. Как происходит поиск и фильтрация кандидатов. Что такое идеальный разработчик в глазах HR'а. Отдельно поговорим про некомпетентность в среде HR'ов и про секреты профессии.

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

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

Первые два года учебы я был сильно заинтересован программированием, математикой и техническими дисциплинами за исключением, разве что, физики. Я был лучший в группе по информатике и всему, что было с ней связано, но не могу сказать, что у меня была сильная мотивация кодить днями и ночами, изобретая что-то грандиозное. То есть я соображал, но в прикладном плане абсолютно не применял ничего. Да и что можно было изобрести, зная паскаль на школьном уровне (а примерно в такой мере нам его и преподавали). А после того, как преподаватель дисциплины "Программирование" отчитал курс лекций, он выдал гениальную фразу - все, что мы сейчас изучили, устарело 15 лет назад.