Как создавался Российский тонкий клиент и к чему все привело.



В те времена, когда красный флаг уже перестал развеваться над нашей Родиной, на дворе шел 2012 год. Я работал в одном Российском системном интеграторе, где занимал двойную должность «Руководителя ИТ отдела» и «Руководителя ИТ проектов». Время было веселое, отличная команда профессионалов, которая всегда слаженно работала, хотя и не так все было просто. Можно долго перечислять имена и фамилии людей, которые работали плечом к плечу со мной, но сдавать агентов КГБ, не буду, не имею такой привычки.

Привет, Хаброжители! Совсем недавно мы перевели бестселлер Сэнди Метц.

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

Внимательно изучив это руководство, вы сможете: • Понять, как писать на Ruby качественный код в духе ООП • Решать, что должно входить в состав класса Ruby • Не допускать тесной связи между объектами в тех случаях, когда требуется разграничить функциональность • Определять гибкие интерфейсы между объектами • Освоить утиную типизацию • Эффективно задействовать наследование, композицию и полиморфизм • Разрабатывать экономные тесты • Доводить до совершенства любой legacy-код Ruby.

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

Одним из недешевых процессов с точки зрения производительности является boxing и unboxing. Напоминалку о том, что это такое, можно найти тут. Недавно я решил посмотреть весь IL код наших проектов и поискать инструкции box и unbox. Нашлось достаточно много участков, boxing'а в которых можно избежать легким движением руки. Все случаи, приводящие к ненужному boxing'у, очевидны, и допускаются по невнимательности в моменты концентрации на функциональности, а не на оптимизации. Я решил выписать наиболее часто встречающиеся случаи, чтобы не забывать о них, а затем автоматизировать их исправление. В данной статье и перечислены эти случаи.

Один из методов библиотеки Sidekiq. Объяснение смайла

send в Ruby вызывает методы объектов по имени. Вот очевидный способ применения:

# До: явно используем присваивание. Неудобно, если полей много или они определяются в рантайме.
user.name = "Иван"
user.age = 29

# После: передаём имя атрибута параметром. Решает проблемы первого способа.
def set(field, value)
  send("#{field}=", value)
end
user.set(:name, "Иван")
user.set(:age, 29)

А ещё вы наверняка видели такие строки:

after_create :send_email

Да-да, коллбэки в рельсах внутри реализованы тоже с помощью send.

За свой относительно небольшой опыт работы (порядка 6 лет) я довольно часто слышал фразы опытных и начинающих программистов — «Я чувствую, что это должно работать», «У меня есть ощущение, что этот метод работать не будет», «Давайте сделаем интуитивно-понятный интерфейс» и так далее. Всё это — проявление интуиции в процессе разработки и программировании.
О ней и пойдёт дальше разговор.


Взято с сайта oprah.com

"Возможно, самая красивая система счисления — это сбалансированная троичная" — Дональд Е. Кнут, Искусство программирования, Издание 2.

Многие знают, что компьютеры хранят данные и работают с ними с помощью двоичной системы счисления. Одно из главных объяснений этому можно найти в схеме современных компьютеров, которые состоят из миллиардов простых и массово производимых транзисторов и конденсаторов, которые могут вместе представлять два состояния: высокое напряжение (1) и низкое напряжение (0).

Такая конструкция сегодня настолько распространена, что трудно себе представить, как компьютеры могут работать иначе. Но, в Советской России 50-х годов они работали иначе. Если вы вдруг не слышали про такое, загуглите "Сетунь" — сбалансированный трехкомпонентный компьютер, разработанный в 1958 году небольшой группой во главе с Брусенцовым, в МГУ.

Перед тем, как говорить о Брусенцове и Сетуни, давайте я немного объясню вам троичную сбалансированную систему счисления.

Сбалансированная троичность

Тернарная или троичная — это система счисления, в которой есть три вероятных значения: 0, 1 и 2. В её сбалансированной версии существуют три вероятности -1, 0 и +1, часто упрощённые до -, 0 и + соответственно.

Последние две мои статьи — интервью со спикерами одной прошедшей конференции. Мне показалось интересным поговорить с человеком, который в свое время отказался выступать на этой конференции, “из за одного маленького семейного обстоятельства”. Этот человек — Сергей SergeyT Тепляков, MVP, автор отличной книги про паттерны проектирования, адепт TDD, ныне разработчик Tools for Software Engineers в Microsoft и мейнтейнер библиотеки Code Contracts.

Под катом много текста про конференции, TDD, парное программирование, архитектуру Code Contracts, Хабру.

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

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

Именно поэтому я хотел бы сегодня поднять еще раз эту тему и привести список своих советов, что нужно делать фрилансеру, чтобы он постоянно продвигался вперед, а не топтался на месте и деградировал. Иначе говоря — как не погрязнуть в рутине однообразных и мелких проектов.

UPD: в этом посте отражено субъективное мнение автора в 2016-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ...». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост. Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы, 10+ лет проведенных в этой системе, с короткими перерывами.

Но была одна серьезная проблема, баг в моей ментальной системе — это регулярное выгорание от работы, которое я не осознавал. Было плохо, нервозно, тревожно, но причину не удавалось найти. Она сидела где-то глубоко в подсознании, зарывшись поглубже еще в раннем детстве и не позволяла увидеть реальное положение вещей. Как наступило просветление и что делать во избежание выгорания — читайте под катом.

Мы в «Латере» уже много лет занимаемся разработкой биллинга для операторов связи и развиваем сервис для управления выездными сотрудниками «Планадо».

Биллинг — это сложный продукт, работа над которым имеет свои особенности. Во-первых, это узкоспециализированный инструмент enterprise-уровня, который внедряется сотнями экземпляров, а не десятками и сотнями тысяч. Во-вторых, система должна работать в режиме 24x7x365. И самое главное — именно биллинг считает деньги, а значит это критически важный элемент инфраструктуры любой компании.

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

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

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

Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?



Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!

Эту самую картинку наш технический директор подкладывал в каждую презентацию с комментарием: «Я хочу, чтобы вы были как они.»

Приветствую, дорогой читатель.

В атмосфере взаимодействия гибкости и тесного взаимодействия (на буржуйском — Agile и DevOps) присутствует такое понятие, как Continuous Learning. По сути общая идея заключается в том, чтобы признавать простой факт: как бы усердно ты ни работал, каким бы профессионалом бы ты ни был — ты всегда можешь быть и делать лучше.

Дабы не вызывать комплекс неполноценности, я взял за правило, что мой КПД — 95%.
Эта цифры взята из потолка, но она дает мне право осознавать, что я достаточно вовлечен в процесс, я пытаюсь выжать максимум из своих возможностей, но всегда есть 5% которых мне не хватает до идеала. Набравшись новых знаний, я пробую снова — но цифры всегда остаются прежними — 95% и ни процента больше.

Однако, каждый раз я задаюсь одним и тем же вопросом — становлюсь ли я лучше?

Это вторая часть статьи по книге Роберта Мартина «Идеальный программист». В первой части статьи мы начали изучать, чем идеальный программист отличается от не идеального. Рассмотрели ответственность, научились говорить «нет» нереальным задачам и говорить «да» так, чтобы заказчик был, уверен, что всё будет готово вовремя. Мы определились, как писать код, принимать помощь и помогать другим. Продолжим.

Статья-конспект по книге Роберта Мартина «Идеальный программист». После прочтения книги у меня поменялось отношение к программистической жизни. В книге рассматривается процесс написания кода, сам код, отношение к задачам, TDD и много других полезностей. Читать нужно разработчикам и менеджерам проектов. Частично применимо к дизайнерам.

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



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

На одном собеседовании меня спросили: «когда ты пишешь на Ruby, ты пользуешься оператором 'and' или двумя символами амперсанда '&&' для обозначения логического 'И' ?». На самом деле, я по старой привычке всегда ставил два символа амперсанда '&&' и никогда не задумывался об этом. Так и ответил, мне сказали «Хорошо».

А вы не смотря под cut можете внятно объяснить разницу между 'and' и '&&' в Ruby?

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

Подопытный проект

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

# Мама очень заботится о своём сыне, и не разрешает ему гулять,
# если он не надел шарф. А ещё она заботится о его успеваемости, поэтому если
# сын не сделал домашнюю работу, гулять ему она тоже не разрешит.
class Mother
  def permit_walk?(child)
    child.scarf_put_on && child.homework_done
  end
end

Прошло два месяца активной работы над новой версией ядра, и сегодня Линус Торвальдс наконец-то представил ядро Linux 4.9. Наиболее заметными измерениями можно назвать инструменты для диагностики и блокирования переполнений стека ядра, а также включение поддержки SELinux в OverlayFS, плюс реализация шины Gerybus, чего хотелось многим.

Что касается статистики, то она, как всегда, обширна. В новой версии было принято 15 тысяч исправлений от 1400 разработчиков. Общий размер патча составляет 45 Мб. Изменения в патче затронули 11042 файлов, с добавлением 632157 строк кода и удалением 354728 строк. Не является сюрпризом и то, что большая часть (около 42%) представленных в этой версии изменений так либо иначе связаны с драйверами устройств. Еще 19% изменений связаны с обновлением кода для различных аппаратных архитектур, 12% — сетевой стек, 5% — файловые системы, 4% — подсистемы ядра.

Данная статья участвует в конкурсе от Wunsh.ru — русскоязычное сообщество Elixir. Практики и просто сочувствующие — присоединяйтесь!

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

Вступление

"Elixir — динамический, функциональный язык программирования, разработанный для создания масштабируемых и легко поддерживаемых систем." — elixir-lang.org

Используя Elixir для создания ваших приложений вы обязательно столкнётесь с Mix. Он станет вам незаменимым помощником, так как через него вы сможете выполнять такие команды как создание, сборка, тестирование и публикация приложений, а также управление зависимостями и многое другое. Если вы знакомы с Ruby, то этот инструмент очень похож на Bundler, RubyGems и Rake, вместе взятые. В двух словах Mix — это удобный инструмент, который поставляется с Elixir и выполняет не меньше задач, чем швейцарский нож.

Инициализация нового приложения

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

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