Может ли это как-то быть связано с тем, что средняя длина слова в английском языке близка к 5? А то есть подозрение, что в других языках это соотношение может быть другим. Уж не говоря о том, что не в каждом языке легко определить, что есть "слово". Например, если используется письменность без пробелов.
10 лет? А я думал, в каждой CASIO-самоиграйке уже есть паттерны для всякого рока, и звучат они гораздо достойнее. Выходи в переход и лабай на здоровье :)
Кроме того, транспонирование имеет всего два направления: вверх (увеличение частоты каждой ноты) и вниз (уменьшение частоты каждой ноты). Поэтому вместо выражения "в любом направлении" уместнее говорить "в каждом направлении".
Автор, конечно, не имел в виду, что он транспонировал каждое произведение на два полутона (т.е. на целый тон) вверх и на два полутона вниз, как может показаться из (исправленного с учётом сказанного) выражения "транспонирование на пару полутонов в каждом направлении". На самом деле он размножил каждый трек пятикратно:
Со смещением +2 полутона.
Со смещением +1 полутон.
Без смещения.
Со смещением -1 полутон.
Со смещением -2 полутона.
Именно таким образом из 3600 треков он получил 18000 треков.
Поэтому выделенный фрагмет лучше было бы перевести приблизительно так:
Я транспонировал каждый трек на полутон-два вверх и вниз, [получив таким образом…]
Очень интересные добавления! Жаль, что не могу перейти на новую версию, пока сохраняется новое поведение pinned tabs, при котором они все группируются в начале списка табов (см IDEA-258869). А то бы обязательно стал пользоваться и дженериками, и рефакторингами.
Скорее всего, вы не ошибаетесь, просто я успел отвыкнуть от российских реалий и подробностей законодательства. В моём нынешнем трудовом договоре (вполне себе бессрочном и соответствующем требованиям местного закона) написано, что трудовые отношения могут быть прекращены любой из сторон с письменным уведомлением за 4 недели до. Мой предыдущий трудовой договор был расторжен именно по инициативе работодателя с формулировкой "с вещами на выход, з/п за месяц вперёд мы тебе проплатим". Такие дела. Работаешь вполсилы или начинаешь наглеть — дверь оказывается не так уж и далеко.
Предположу, что соискатель подстраивается под бредовые автоматические фильтры рекрутинговых компаний, которые ранжируют резюме в базе по толщине диффа между вакансией и резюме.
По-моему, все эти игры в ожидания и мечты всей жизни только скрывают, что вообще-то есть трудовое законодательство, по которому и работник может встать и выйти в любой момент, и работодатель может указать ему на дверь. Обещать что-то большее — просто игры в манипуляцию "честным пионерским". Всё равно в конце один первым пошлёт это честное пионерское, а второй ему ответит "тыжобещал" и "фунекрасиво", хотя в иной ситуации второй так же радостно был бы на месте первого.
Тот верстальщик, который мечтает стать фотографом, хотя бы честен. А тот работодатель, который не написал в описании вакансии, что полгода его не устраивают, хотя подразумевал это, нечестен. Если вам нужны работники на срок не меньше N, то заключайте срочные контракты и пишите об этом в вакансиях.
код должен быть открыт к расширению, но закрыт к изменению
Я подозреваю, что open-closed principle родился в определённом контексте, а используют его почему-то также и вне этого контекста.
Контекст open-closed principle — это разработка библиотеки для третьих сторон. Третья сторона получает скомпилированный объектный файл (closed), поэтому не может вносить в него изменения и вынуждена пользоваться только тем интерфейсом, который вы (как его разработчик) задокументировали. Если вам для добавления функциональности к библиотеке нужно изменить её код, то вам надо перекомпилировать объектные файлы и доставить их пользователям вашей библиотеки. То есть изменение интерфейса ради новой функциональности создаёт организационную проблему. Именно на решение этой проблемы и направлен open-closed principle: мол, закладывай интерфейс такой, чтобы добавление новой функциональности (open) было возможно без изменения исходного кода.
Однако в статье вы говорите про корпоративную разработку. Да, всё зависит от объёма кодовой базы, от разделения ответственности между командами, от способа доставки кода, от необходимости поддерживать разные версии продукта, поэтому, безусловно, open-closed principle может иметь свой вес и во внутренней разработке.
Но я призываю вас не возводить его в абсолют, потому что каждый отдельно взятый контекст может и не подходить по условия применимости open-closed principle.
Могу привести в пример проект, в котором я работаю прямо сейчас. Его back-end содержит около 800 классов, распределённых по 70 библиотекам. И знаете что? Ни один класс не имеет стороннего (т.е. не управляемого компанией) клиента: весь front-end разрабатывается исключительно внутри компании, а единственный программный интерфейс для партнёров — это экспорт данных в CSV. И если мне нужно поменять интерфейс взаимодействия класса с его зависимыми классами или наследниками, мне ничто не мешает это сделать. Поднял версию библиотеки, поднял версию зависимости в зависимых библиотеках, раскатал код на сервера (язык интерпретируемый), готово. Зачем мне open-closed principle? Какую конкретно мою проблему он решает?
И мне честно было бы интересно узнать, какая часть программистов на хабре действительно разрабатывает библиотеки для сторонних клиентов. Или точнее, какая доля классов / модулей / библиотек, разрабатываемых в компаниях, где работают читатели хабра, предназначена для сторонних клиентов. Потому что ясно, что есть код для внешнего взаимодействия (собственно, интерфейс), а есть код для внутреннего использования (подробности реализации). И их соотношение может быть совсем не в пользу open-closed principle.
PS. А начать, наверное, надо было в того, что рефакторинг и изменения в интерфейсе — это две большие разницы.
А я думал, произносится "Сэнки". По крайней мере, коллеги так произносят. Фирма занимается энергоэффективностью, и Sankey diagram широко применяются. Для справки: локация — Берлин, носителей английского языка нет.
перечислением сложных матримониальных связей, абсолютно бесполезных для сюжета и вкусной еды, которую поглощают персонажи.
Мне кажется, от Вас убежала запятая, которая хотела помочь Вам изложить ту мысль, что вкусная еда входит в перечисление, а не является целью, для которой сложные матримониальные связи абсолютно бесползены. Но я могу ошибаться.
Объясните, пожалуйста, откуда взялись цифры на рёбрах на рисунке "Начальная остаточная сеть"? С виду как будто не имеют никакого отношения к рисунку из "Постановки задачи".
Может ли это как-то быть связано с тем, что средняя длина слова в английском языке близка к 5? А то есть подозрение, что в других языках это соотношение может быть другим. Уж не говоря о том, что не в каждом языке легко определить, что есть "слово". Например, если используется письменность без пробелов.
10 лет? А я думал, в каждой CASIO-самоиграйке уже есть паттерны для всякого рока, и звучат они гораздо достойнее. Выходи в переход и лабай на здоровье :)
Спасибо за перевод!
Боюсь, что эта фраза звучит диковато для тех, кто знаком с музыкальной теорией.
Предлагаю посмотреть в оригинал:
Здесь https://en.wiktionary.org/wiki/half_step — это синоним к https://en.wiktionary.org/wiki/semitone, который означает полутон. Термина "полушаг" в русской музыкальной терминологии не существует.
Кроме того, транспонирование имеет всего два направления: вверх (увеличение частоты каждой ноты) и вниз (уменьшение частоты каждой ноты). Поэтому вместо выражения "в любом направлении" уместнее говорить "в каждом направлении".
Автор, конечно, не имел в виду, что он транспонировал каждое произведение на два полутона (т.е. на целый тон) вверх и на два полутона вниз, как может показаться из (исправленного с учётом сказанного) выражения "транспонирование на пару полутонов в каждом направлении". На самом деле он размножил каждый трек пятикратно:
Со смещением +2 полутона.
Со смещением +1 полутон.
Без смещения.
Со смещением -1 полутон.
Со смещением -2 полутона.
Именно таким образом из 3600 треков он получил 18000 треков.
Поэтому выделенный фрагмет лучше было бы перевести приблизительно так:
Спасибо за внимание.
Очень интересные добавления! Жаль, что не могу перейти на новую версию, пока сохраняется новое поведение pinned tabs, при котором они все группируются в начале списка табов (см IDEA-258869). А то бы обязательно стал пользоваться и дженериками, и рефакторингами.
Скорее всего, вы не ошибаетесь, просто я успел отвыкнуть от российских реалий и подробностей законодательства. В моём нынешнем трудовом договоре (вполне себе бессрочном и соответствующем требованиям местного закона) написано, что трудовые отношения могут быть прекращены любой из сторон с письменным уведомлением за 4 недели до. Мой предыдущий трудовой договор был расторжен именно по инициативе работодателя с формулировкой "с вещами на выход, з/п за месяц вперёд мы тебе проплатим". Такие дела. Работаешь вполсилы или начинаешь наглеть — дверь оказывается не так уж и далеко.
Предположу, что соискатель подстраивается под бредовые автоматические фильтры рекрутинговых компаний, которые ранжируют резюме в базе по толщине диффа между вакансией и резюме.
По-моему, все эти игры в ожидания и мечты всей жизни только скрывают, что вообще-то есть трудовое законодательство, по которому и работник может встать и выйти в любой момент, и работодатель может указать ему на дверь. Обещать что-то большее — просто игры в манипуляцию "честным пионерским". Всё равно в конце один первым пошлёт это честное пионерское, а второй ему ответит "тыжобещал" и "фунекрасиво", хотя в иной ситуации второй так же радостно был бы на месте первого.
Тот верстальщик, который мечтает стать фотографом, хотя бы честен. А тот работодатель, который не написал в описании вакансии, что полгода его не устраивают, хотя подразумевал это, нечестен. Если вам нужны работники на срок не меньше N, то заключайте срочные контракты и пишите об этом в вакансиях.
Я подозреваю, что open-closed principle родился в определённом контексте, а используют его почему-то также и вне этого контекста.
Контекст open-closed principle — это разработка библиотеки для третьих сторон. Третья сторона получает скомпилированный объектный файл (closed), поэтому не может вносить в него изменения и вынуждена пользоваться только тем интерфейсом, который вы (как его разработчик) задокументировали. Если вам для добавления функциональности к библиотеке нужно изменить её код, то вам надо перекомпилировать объектные файлы и доставить их пользователям вашей библиотеки. То есть изменение интерфейса ради новой функциональности создаёт организационную проблему. Именно на решение этой проблемы и направлен open-closed principle: мол, закладывай интерфейс такой, чтобы добавление новой функциональности (open) было возможно без изменения исходного кода.
Однако в статье вы говорите про корпоративную разработку. Да, всё зависит от объёма кодовой базы, от разделения ответственности между командами, от способа доставки кода, от необходимости поддерживать разные версии продукта, поэтому, безусловно, open-closed principle может иметь свой вес и во внутренней разработке.
Но я призываю вас не возводить его в абсолют, потому что каждый отдельно взятый контекст может и не подходить по условия применимости open-closed principle.
Могу привести в пример проект, в котором я работаю прямо сейчас. Его back-end содержит около 800 классов, распределённых по 70 библиотекам. И знаете что? Ни один класс не имеет стороннего (т.е. не управляемого компанией) клиента: весь front-end разрабатывается исключительно внутри компании, а единственный программный интерфейс для партнёров — это экспорт данных в CSV. И если мне нужно поменять интерфейс взаимодействия класса с его зависимыми классами или наследниками, мне ничто не мешает это сделать. Поднял версию библиотеки, поднял версию зависимости в зависимых библиотеках, раскатал код на сервера (язык интерпретируемый), готово. Зачем мне open-closed principle? Какую конкретно мою проблему он решает?
И мне честно было бы интересно узнать, какая часть программистов на хабре действительно разрабатывает библиотеки для сторонних клиентов. Или точнее, какая доля классов / модулей / библиотек, разрабатываемых в компаниях, где работают читатели хабра, предназначена для сторонних клиентов. Потому что ясно, что есть код для внешнего взаимодействия (собственно, интерфейс), а есть код для внутреннего использования (подробности реализации). И их соотношение может быть совсем не в пользу open-closed principle.
PS. А начать, наверное, надо было в того, что рефакторинг и изменения в интерфейсе — это две большие разницы.
Спасибо, будем ждать :)
А зачем вам без рефакторинга? Или вы боитесь рефакторинга? Пробовали, не понравилось?
За тис замолвите словечко... У нас по улице под домами растёт, а мы-то и не знали, что он ядовитый. Ребёнок любит с ним играть.
Раз.
Два.
Три, — сказал муж, достал пистолет и застрелил лошадку.
"Знающий поймёт, а незнающему и знать не надо", примерно так?
А я думал, произносится "Сэнки". По крайней мере, коллеги так произносят. Фирма занимается энергоэффективностью, и Sankey diagram широко применяются. Для справки: локация — Берлин, носителей английского языка нет.
Мне кажется, от Вас убежала запятая, которая хотела помочь Вам изложить ту мысль, что вкусная еда входит в перечисление, а не является целью, для которой сложные матримониальные связи абсолютно бесползены. Но я могу ошибаться.
С удовольствием отметил, что в статье затронута тема "здоровье дочек гика".
Показательно, что автор статьи выбрал себе псевдоним "хомяк00".
Объясните, пожалуйста, откуда взялись цифры на рёбрах на рисунке "Начальная остаточная сеть"? С виду как будто не имеют никакого отношения к рисунку из "Постановки задачи".
За стеклом, которое в данном освещении выглядит для наблюдателя на улице как зеркало.
А откуда взять тех, кто хорошо умеет делать Х?
Я как-то думал, что надо предлагать делать Х также и тем, кто средне умеет делать Х. А дальше практика сделает своё дело.