Выравниваю, хоть и без особого фанатизма. Например, нет смысла выравнивать такое:
// some code here
...
$short = 'some value of short variable';
$someLongVariableNameHere = 'value of long variable name';
// and code here
...
Две-три переменные, с настолько разной длиной имён… Ерунда вобщем.
А вот в групповых присвоениях: массивы, группа свойств, блок переменных — тут уже для удобочитаемости выравниваю. Тем самым облегчаю дальнейшее сопровождение кода: читается выровненный блок намного проще.
Очевидно, что это неспроста. Скорее всего, автор чаще говорит на родном языке, чем на русском. ;)
Совершенно не вижу в этом повода минусовать автору карму. А, кстати… А что вы думаете по поводу статьи?
Ситуация с плеерами, это ошибка программистов, которые не стали следовать стандарту до конца, а реализовали только этап воспроизведения нотных данных. Логика, которой они руководствовались, скорее всего проста: обычный пользователь вряд ли будет работать с миди-файлами, содержащими необычные данные. Соответственно — можно сэкономить время.
А вот если использовать для воспроизведения секвенсор (то есть программу, априори предназначенную для работы с миди-протоколом, в числе прочего) то всё нормально. Просто потому, что задача этого ПО несколько другая.
А почему он воспроизводится в QuickTime без ошибок, так на это есть ответ в статье:
Причина тому проста — QuickTime Player использует свой собственный синтезатор (разработанный, однако, Roland)
Всё же Roland — далеко не последнее имя в разработке всяких синтезаторов, работающих в том числе с управлением по миди-протоколу. И было бы просто позорно, если бы у такого производителя, грубо говоря, собственный протокол не работал как следует. :)
Сотрудники Google приводят ещё один интересный факт — растущую популярность двухфакторной аутентификации, когда дополнительно к паролю приходит одноразовый код на телефон.
О, да. Я тоже невольно приложил к этому руку несколько дней назад. Когда просто не смог проверить почту, в обход предложения всё же использовать двухфакторную авторизацию (ну или, возможно, просто не нашёл как проверить в обход этого настойчивого предложения) :)
Хотя, с некоторыми операторами бывает непросто получить код авторизации.
Преподаватель: Так, сейчас вопрос. Ответивший — получает зачёт автоматом. Вопрос несложный. Готовы?
Аудитория: Да-а-а-а!
Преподаватель: Вам нужно проверить наличие тока на этом проводе. Как будете проверять: тыльной стороной ладони или лицевой?
Аудитория: *расслабившись* Ясное дело — ТЫЛЬНОЙ!
Преподаватель: А почему?
Аудитория: *снисходительно* Если под напряжением, то мышцы сократятся. Если лицевой хватать — ладонь сожмётся, и не сможешь выбросить провод. А если тыльной — то рука дёрнется в другую сторону.
Преподаватель: Молодцы, зачёт никто автоматом не получит.
Аудитория: Как так?
Преподаватель: Ребята, вы будущие электрики или кто? Наличие напряжения проверяется вольтметром или индикаторной лампой, а не ладонью.
Гради Буч мне внезапно открыл глаза на ООП. До того я никак не мог понять: что это и зачем?
После прочтения «ООП» Буча мои волосы стали мягкими и шелковистыми, и пришло понимание основ. С этого момента я начал жонглировать объектами. Сначала, как и в цирковом училище, лишь парой-тройкой. Затем больше и больше.
Потом появилась мания, всё перевести в объекты, и я заплутал в трущобах высотных конструкций из этих самых объектов.
Тут пришло время для паттернов, т.е. о том, как организовать (!) свою работу с объектами. Не всё сразу. Один-два примера. Практика. Практика. Ещё парочка. Практика. Практика.
Прочитал ваш коммент про необходимость разделять объекты-контейнеры и функциональные объекты. С этим согласен.
Но на мой взгляд, это все же не проблема ООП, а скорее вопрос архитектурных соглашений в рамках проекта или языка.
Более того, объектно-ориентированные языки сами зачастую нарушают правило инкапсуляции, предоставляя доступ к данным через специальные методы — getters и setters в Java, properties в C# и т.д.
Мне кажется здесь вы перепутали инкапсуляцию с доступом к свойствам. Часто это взаимосвязанные вещи, но не тождественные.
Отключение прямого доступа к свойствам — обычно завязано на некоторое поведение объекта, связанное с этим свойством, или, к примеру, изменение других, сопутствующих свойств.
А инкапсуляция — это уже сокрытие реализации. К чему вам видеть, что у объекта имеется десять вспомогательных методов, которые выполняют «грязную работу»? Объект предоставляет вам красивые публичные методы для работы (меню ресторана), и не пускает вас на кухню, чтобы вы не лезли с советами к шеф-повару. :)
Если при этом на кухне меняется оборудование, технология приготовления блюд — в идеальном варианте вы всё равно получите то, что указано в меню, вам не придётся выяснять подробности приготовления.
Полиморфизм — это тоже весьма сильное средство в умелых руках.
ООП даёт вам возможность, сообразуясь с вашей целью, написать соответствующий «язык» на основе другого «языка». Фреймворки — это, по большому счёту, некоторое специфическое подмножество языка (С, Java, PHP — не суть важно) которое предоставляет определённый формат работы с ним. Если он вам подходит — отлично, меньше лишней работы. Не подходит — пишите своё или ищите подходящий вашим задачам.
Каждая селёдка — рыба, но не каждая рыба — селёдка. Это ещё Врунгель рассказывал. :)
Может вам просто не везёт, но практически все девушки, связанные с IT, которые мне попадались — совершенно нормальные, адекватные и привлекательные. Все проблемы от нервов и отсуствия мозгов, а не от профессии и технического склада ума. :)
Не совсем. Феномен «зловещей долины» отлично подходит для демонстрации созданий, который должны вызывать ужас. Самая отличная и настойчиво эксплуатируемая с древних времён тема — ожившие трупы. Собственно здесь самое ужасное то, что появляется создание которое вроде как «свой», но очевидно, что своим быть не может. Да ещё и отделаться от этих тварей непросто. На этих страхах и живут детские «страшилки», целый пласт фантастики ужасов и Голливуд. :)
А с декорациями немного другой момент, попробую сформулировать.
В театре нам показывают: «вот тут у нас КАК БЫ кухня», «вот тут у нас КАК БЫ тронный зал». Всё. Здесь уже включается воображение, которое достраивает картинку и весь фокус внимания переходит на игру актёров. Больше на декорации мозг не отвлекается, они служат только своеобразным «якорем» для обозначения места действия.
В кино же, нам показывают это так: «А тут кухня», «а тут тронный зал». То есть окружающая кинореальность играет не меньшую роль в подаче всей картинки. Вы когда-нибудь видели трансляции спектаклей по телевизору? Разница кардинальная между спектаклем и кино, опять же — фокус внимания.
Постепенно все привыкли, что кино выглядит так, как оно выглядит на экране (и подсознательно мы сразу отмечаем разницу с реальностью). Все достижения технологии шли на увеличение разрешения, на повышение контраста, яркости, сочности картинки, оставляя при этом чётко очерченную грань «это — кино» (можно сравнить качество картинки фильмов 70-х, 80-х, 90-х и 2000-х годов. Так сказать — наглядное отображение прогресса киноиндустрии).
Сейчас же, когда удаётся посмотреть материал, подготовленный на более качественном уровне, с более плавной картинкой, мозг срывается в «истерику» и сразу отмечает те мелочи, которые ДОЛЖНЫ разделить реальность и экран. И вроде движения более плавные и реальные (не зря многие отмечают это как «театральная постановка» — собственно реализм движений это и даёт), но в тоже самое время нет точки отсчёта, чтобы окончательно провести границу реальность-картинка.
С повышением детализации, с привычкой к более качественной картинке (если она будет, конечно) мне кажется, что это всё отойдёт на задний план, и новые фильмы будут восприниматься также, как и обычное кино.
Две-три переменные, с настолько разной длиной имён… Ерунда вобщем.
А вот в групповых присвоениях: массивы, группа свойств, блок переменных — тут уже для удобочитаемости выравниваю. Тем самым облегчаю дальнейшее сопровождение кода: читается выровненный блок намного проще.
Совершенно не вижу в этом повода минусовать автору карму. А, кстати… А что вы думаете по поводу статьи?
В смысле — вам хотелось бы сменить свою связку на PhpStorm, но надо чтобы вас в этом убедили? О_о
И почему не подходил компонент из Symfony?
Эти мелочи могут стать важным звеном при оценке библиотек.
Как-то так :)
А вот если использовать для воспроизведения секвенсор (то есть программу, априори предназначенную для работы с миди-протоколом, в числе прочего) то всё нормально. Просто потому, что задача этого ПО несколько другая.
А почему он воспроизводится в QuickTime без ошибок, так на это есть ответ в статье:
Всё же Roland — далеко не последнее имя в разработке всяких синтезаторов, работающих в том числе с управлением по миди-протоколу. И было бы просто позорно, если бы у такого производителя, грубо говоря, собственный протокол не работал как следует. :)
При сохранении под другим именем в формате MIDI 1 — файл «похудел» на три килобайта. :)
О, да. Я тоже невольно приложил к этому руку несколько дней назад. Когда просто не смог проверить почту, в обход предложения всё же использовать двухфакторную авторизацию (ну или, возможно, просто не нашёл как проверить в обход этого настойчивого предложения) :)
Хотя, с некоторыми операторами бывает непросто получить код авторизации.
Преподаватель: Так, сейчас вопрос. Ответивший — получает зачёт автоматом. Вопрос несложный. Готовы?
Аудитория: Да-а-а-а!
Преподаватель: Вам нужно проверить наличие тока на этом проводе. Как будете проверять: тыльной стороной ладони или лицевой?
Аудитория: *расслабившись* Ясное дело — ТЫЛЬНОЙ!
Преподаватель: А почему?
Аудитория: *снисходительно* Если под напряжением, то мышцы сократятся. Если лицевой хватать — ладонь сожмётся, и не сможешь выбросить провод. А если тыльной — то рука дёрнется в другую сторону.
Преподаватель: Молодцы, зачёт никто автоматом не получит.
Аудитория: Как так?
Преподаватель: Ребята, вы будущие электрики или кто? Наличие напряжения проверяется вольтметром или индикаторной лампой, а не ладонью.
:)
и
После прочтения «ООП» Буча мои волосы стали мягкими и шелковистыми, и пришло понимание основ. С этого момента я начал жонглировать объектами. Сначала, как и в цирковом училище, лишь парой-тройкой. Затем больше и больше.
Потом появилась мания, всё перевести в объекты, и я заплутал в трущобах высотных конструкций из этих самых объектов.
Тут пришло время для паттернов, т.е. о том, как организовать (!) свою работу с объектами. Не всё сразу. Один-два примера. Практика. Практика. Ещё парочка. Практика. Практика.
И так далее.
Ну и самое главное: не паниковать. :)
Но на мой взгляд, это все же не проблема ООП, а скорее вопрос архитектурных соглашений в рамках проекта или языка.
Мне кажется здесь вы перепутали инкапсуляцию с доступом к свойствам. Часто это взаимосвязанные вещи, но не тождественные.
Отключение прямого доступа к свойствам — обычно завязано на некоторое поведение объекта, связанное с этим свойством, или, к примеру, изменение других, сопутствующих свойств.
А инкапсуляция — это уже сокрытие реализации. К чему вам видеть, что у объекта имеется десять вспомогательных методов, которые выполняют «грязную работу»? Объект предоставляет вам красивые публичные методы для работы (меню ресторана), и не пускает вас на кухню, чтобы вы не лезли с советами к шеф-повару. :)
Если при этом на кухне меняется оборудование, технология приготовления блюд — в идеальном варианте вы всё равно получите то, что указано в меню, вам не придётся выяснять подробности приготовления.
Полиморфизм — это тоже весьма сильное средство в умелых руках.
ООП даёт вам возможность, сообразуясь с вашей целью, написать соответствующий «язык» на основе другого «языка». Фреймворки — это, по большому счёту, некоторое специфическое подмножество языка (С, Java, PHP — не суть важно) которое предоставляет определённый формат работы с ним. Если он вам подходит — отлично, меньше лишней работы. Не подходит — пишите своё или ищите подходящий вашим задачам.
Это не проблема ООП, это проблема выбора. :)
Может вам просто не везёт, но практически все девушки, связанные с IT, которые мне попадались — совершенно нормальные, адекватные и привлекательные. Все проблемы от нервов и отсуствия мозгов, а не от профессии и технического склада ума. :)
А с декорациями немного другой момент, попробую сформулировать.
В театре нам показывают: «вот тут у нас КАК БЫ кухня», «вот тут у нас КАК БЫ тронный зал». Всё. Здесь уже включается воображение, которое достраивает картинку и весь фокус внимания переходит на игру актёров. Больше на декорации мозг не отвлекается, они служат только своеобразным «якорем» для обозначения места действия.
В кино же, нам показывают это так: «А тут кухня», «а тут тронный зал». То есть окружающая кинореальность играет не меньшую роль в подаче всей картинки. Вы когда-нибудь видели трансляции спектаклей по телевизору? Разница кардинальная между спектаклем и кино, опять же — фокус внимания.
Постепенно все привыкли, что кино выглядит так, как оно выглядит на экране (и подсознательно мы сразу отмечаем разницу с реальностью). Все достижения технологии шли на увеличение разрешения, на повышение контраста, яркости, сочности картинки, оставляя при этом чётко очерченную грань «это — кино» (можно сравнить качество картинки фильмов 70-х, 80-х, 90-х и 2000-х годов. Так сказать — наглядное отображение прогресса киноиндустрии).
Сейчас же, когда удаётся посмотреть материал, подготовленный на более качественном уровне, с более плавной картинкой, мозг срывается в «истерику» и сразу отмечает те мелочи, которые ДОЛЖНЫ разделить реальность и экран. И вроде движения более плавные и реальные (не зря многие отмечают это как «театральная постановка» — собственно реализм движений это и даёт), но в тоже самое время нет точки отсчёта, чтобы окончательно провести границу реальность-картинка.
С повышением детализации, с привычкой к более качественной картинке (если она будет, конечно) мне кажется, что это всё отойдёт на задний план, и новые фильмы будут восприниматься также, как и обычное кино.