Руководство по именованию переменных

Польза от именования

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

Назначение этого документа, помочь инженерам выбрать хорошие имена переменных.…

Железнодорожно-ориентированное программирование

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

Recipe Function ErrorTrack

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

Проектирование функций представляющих собой шаг

Давайте более детально рассмотрим эти шаги. Например, функцию валидации. Как она должна работать? Некоторые данные поступают в нее, но что должно быть на выходе?…

Как полностью разработать и написать программу

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

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

Сначала несколько комментариев и предупреждений:

  • Я буду фокусироваться на одном варианте использования, нежели на целом приложении.

Моноид без слез

Если вы пришли с мира ООП, то одной наиболее сложной вещью в функциональном программировании для вас может быть отсутствие явных шаблонов программирования. Здесь множество идиом типа частичного применения и техник обработки ошибок, но нет очевидных шаблонов как в "Банде четырёх".…

Цена, о которой забывают менеджеры и инженеры

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

Среди наиболее опасных недооцененных цен — цена сложности.…

Разработка через гамак

Ричард Хикки (создатель языка программирования Clojure) провел очень интересный доклад о решении задач под названием «Разработка через гамак». Ричард говорил больше с личной (эмпирической) точки зрения. Это пока не очень признано академично, но вписывается в некоторые исследования в области мозга. Поэтому доклад не особо научный, но в то же время дает достаточно хорошую пищу для размышлений.

[youtube video=»f84n5oFoZBc»]

Выводы:

  • Не бросайтесь сразу программировать.

Цитаты об ИТ

думающий хоттабыч

Дзен Питона

  • Красивое лучше, чем уродливое.
  • Явное лучше, чем неявное.
  • Простое лучше, чем сложное.
  • Сложное лучше, чем запутанное.
  • Плоское лучше, чем вложенное.
  • Разреженное лучше, чем плотное.
  • Читаемость имеет значение.
  • Особые случаи не настолько особые, чтобы нарушать правила.
  • При этом практичность важнее безупречности.
  • Ошибки никогда не должны замалчиваться.
  • Если не замалчиваются явно.
  • Встретив двусмысленность, отбрось искушение угадать.
  • Должен существовать один — и, желательно, только один — очевидный способ сделать это.

Функциональный JavaScript

функциональный javascript

Draft!!!

Осторожно! Слабонервным, холерикам и беременным не читать - выносит мозг, меняет сознание!

Переменные

function func(fn, arg1, arg2) {
    return function () {
        return fn.call(null, arg1, arg2);
    };
}

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

Безопасное использование .ready() перед подключением jQuery

document ready

Сегодня прочитал [Перестаньте платить дань jQuery](http://samsaffron.com/archive/2012/02/17/stop-paying-your-jquery-tax), хорошую статью от [Sam Saffron](http://samsaffron.com/), которая поясняет идею перемещения всех внешних скриптов в конец HTML документа, и метода который позволит использовать jQuery `.ready()` везде в вашем документе, даже если вы переместили сам jQuery в конец документа. Я метод немного доработал.…