Спасибо за посты! Давно в качестве хобби, при основной работе в IT, увлекаюсь авиацией, так что видеть подобное на хабре очень интересно. Буду рад, если этим постом дело не закончится.
На сколько мне известно, на новых поколениях Boeing'a (777, 787) управление самолетом происходит также через компьютер, и штурвал по факту — джойстик. Однако, по заверению летчиков (не могу сказать это уверенно и определенно, т.к. не читал официальную литературу на эту тему) физическую связь с поверхностями управления кокпит все же сохранил, т.е. в случае полного отказа электроники пилоты могут перейти в режим полностью ручного управления (с помощью гидравлики естественно). На взгляд обывателя это выглядит вполне логично, впрочем как и наличие некой кнопки, которая могла бы выключить компьютер и дать управлять самолетом по старинке. Так вот вопрос, почему же такое резервирование не является стандартом отрасли? Понятно, конечно, что риск весьма ничтожен, но все же…
Эти бандлы исключены просто из стандартной версии, т.е. самим их установить будет возможно или они вообще прекратят поддерживаться в этой версии? Извиняюсь, за, возможно, глупый вопрос.
Далеко не у всех авторов есть возможность самостоятельно продвигать свою продукцию, для этого нужны немалые деньги, связи, опыт. Поэтому они передают свои произведения издательствам. Вполне справедливо, что они хотят за свои услуги также получить вознаграждение. Есть не мало примеров, когда очередная звезда разругавшись с продюссерами пытается продвигаться самостоятельно и сдувается быстрее, чем успевает осознать это.
Вы же, наверное, продукты в магазине покупаете, а не на заводах.
Я не говорю о том, что бы авторы продвигали все сами, хотя в некоторых случаях это вполне реально. И я не говорю о том, что бы эти «посрденики» между автором и потребителем работали за бесплатно. Но, я уже писал вышел, что сейчас создается впечатление, что «посредники» зарабатывают намного больше авторов, это не правильно.
Адекватных для потребителей или издательства?
Для потребителей. Я уже приводил в пример маркеты на современных смартфонах. Заплатить 30-100 рублей за хороший контент не жалко, тем более когда это делается в один клик. Система работает за счет массовости покупок, думаю можно подобное внедрить и в остальные сферы этих отношений.
Т.е. люди, которые занимаются рекламой, оформлением, тиражированием, редакцией, сетью распространения, должны работать бесплатно?
Нет, конечно. Но сейчас складывается такое ощущение, что на произведении том или ином они наживаются намного больше автора. Было уже много примеров, когда сам автор был совершенно не против свободного распространения своего продукта, но ему не позволял делать этого контракт с такого рода посредниками. Но, повторюсь, любой труд должен быть оплачен, если он полезен. Так что если я ошибаюсь в логике функционирования всех этих отношений, то конечно оплата должна быть.
А охрана прав? Это уже отдельная большая статья расходов, которая включена в стоимость каждой книги.
Ну так если эта охрана такая неэффективная, то может и не выгодно в нее вообще деньги вкладывать? Хотя опять же сложный вопрос очень, но у меня складывается впечатление, что порой на суды и адвокатов тратят больше денег, чем якобы недополучили от свободного распространения.
Считаете, что завышенная цена — не платите, ищите альтернативу. Если нет вариантов (вендор лок, монополия), то пишите жалобу в антимонопольные органы.
И опять получаем проблему удобства использования. Я не хочу искать, я не хочу писать, я хочу посмотреть фильм по адекватной цене и с минимальным количеством действий.
Но, ей богу, если бы не было пиратства, копирастам стоило бы самим пиратить.
100%-ное попадание в яблочко!
> ну и конечно же, совершенно забывают о том, что пиратский контент очень не плохая реклама для некоторого вида контента
Когда такая реклама выгодна, контент будет бесплатен и так. Куча веб сервисов с про-аккаунтами тому пример.
Ну тут я имел ввиду по большей части музыку. Ведь давно уже говорилось о том, что тому или иному исполнителю выгодно привлекать своих поклонников на концерты выкладыванием альбомов в свободный доступ, и некоторый даже этим активно пользуются.
1) Безусловно, труд должен вознаграждаться. Но хочется вознаграждать именно автора, а не бесчисленные редакции, студии записи и т.д.
2) Нет нормальных условий, для того, что бы платить за контент. Нет адекватных цен на него. Что бы потреблять лицензионный контент, мало того, что приходится платить, так еще и сделать это не так просто как кажется. Как хороший пример, маркеты на мобильных телефонах (особенно на закрытых iOS и WP), и там конечно есть джейлбрейки и все такое, но доля этого существенно ниже, т.к. заплатить там намного проще и цены весьма приемлемы.
3) Ведь далеко не каждый, кто скачал книжку или фильм нахаляву, заплатил бы за них, если бы нельзя было найти их бесплатно. Я бы даже сказал заплатили бы единицы. Следовательно ущерб от пиратской деятельности подсчитан совершенно не верно, ну и конечно же, совершенно забывают о том, что пиратский контент очень не плохая реклама для некоторого вида контента и косвенные доходы от него вполне могут компенсировать убытки.
Ну если следовать принципу let it fail и нет возможности написать собственный error_handler, то такой подход допустим. Но я в своей практике ситуации где бы это было действительно оправдано встречал крайне редко.
Кстати, а если в Вашем примере без file_exists файл не пропал, а просто у скрипта нет прав на его чтение? В этом случае warning бы очень помог быстро обнаружить ошибку.
И правильно сделает, что не убережет. Но он не покажет сообщение пользователю, а запишет его в логи. Ситуация, когда файл пропадает после вызова file_exists и до вызова fopen явно не нормальна и ее надо отслеживать. Запись в логи в данном случае вполне уместна.
1) Как написали выше, собственный error_handler
2) display_errors в off, и контролировать возвращаемое значение от fopen. В случае ошибки придет false.
И к слову сказать, я считаю, что это более правильные варианты, нежели подавлять ошибку с помощью @.
Думаю, имеет смысл добавить обработку postPersist события в EntityConfigurator. В этом случае в новые присоединенные к EntityManager'у сущности так же будут заинжекчены нужные сервисы, иначе при создании сущности через конструктор придется руками их добавлять.
Ну если для разных картинок размеры могут быть совершенно разными, то да, Вы правы. Но если брать, например, каталог продукции, то в большинстве случаев для всех картинок каталога список нужных размеров будет одинаков. Хотя в этом случае иногда проще сделать ресайз при загрузке, если конечно не планируется частое изменения размеров.
Вообщем, не панацея конечно, но в некоторых ситуациях модуль будет удобен для использования, имхо.
Ведь все равно, каков бы скилл английского не был, все равно лучше материал усваивается на родном языке.
Вот на счет этого не совсем с Вами согласен. Мне намного комфортнее читать документацию подобного рода именно на английском и усваивать ее тоже в этом виде. В переводе бывает много неточностей или переведены те термины, которые не стоило бы переводить или переводить так, перевод далеко не всегда актуален… ну и т.д.
Поэтому лучше, чтобы был вариант выбора.
Здесь несомненно, выбор это всегда хорошо. Как я уже говорил, люди все разные и усваивать информацию все могут по разному.
И вообще, наличие обширной русскоязычной документации чаще всего показывает уровень проникновения данной технологии в данной стране. «Взрослость» технологии.
Достаточно субъективный показатель конечно, но в целом да, Вы правы.
Уточню, я ни в коем случае не против локализированных доков, но сам стараюсь использовать оригинальные варианты.
Йода однозначно оригинальнее второго варианта. Он был первым, что бросилось в глаза, когда я посетил первый раз блог. Так что, думаю, вариант весьма успешен.
Думаю, что те, кто изучал в школе/универе английский язык, смогут без особого труда освоить официальную документацию. Ничего там сложного нет, все достаточно коротко и понятно написано.
Но судя по результатам опроса среди нас много либо людей с другим иностранным за плечами, либо тех, кому читать доки на русском все же привычнее. Каждому свое, как говорится!
У Lumia 800 в начале тоже были проблемы с батареей и тоже по программным причинам. Пофиксили достаточно быстро, сейчас все отлично. Думаю, что с 920 будет та же история.
На сколько мне известно, на новых поколениях Boeing'a (777, 787) управление самолетом происходит также через компьютер, и штурвал по факту — джойстик. Однако, по заверению летчиков (не могу сказать это уверенно и определенно, т.к. не читал официальную литературу на эту тему) физическую связь с поверхностями управления кокпит все же сохранил, т.е. в случае полного отказа электроники пилоты могут перейти в режим полностью ручного управления (с помощью гидравлики естественно). На взгляд обывателя это выглядит вполне логично, впрочем как и наличие некой кнопки, которая могла бы выключить компьютер и дать управлять самолетом по старинке. Так вот вопрос, почему же такое резервирование не является стандартом отрасли? Понятно, конечно, что риск весьма ничтожен, но все же…
Эти бандлы исключены просто из стандартной версии, т.е. самим их установить будет возможно или они вообще прекратят поддерживаться в этой версии? Извиняюсь, за, возможно, глупый вопрос.
Я не говорю о том, что бы авторы продвигали все сами, хотя в некоторых случаях это вполне реально. И я не говорю о том, что бы эти «посрденики» между автором и потребителем работали за бесплатно. Но, я уже писал вышел, что сейчас создается впечатление, что «посредники» зарабатывают намного больше авторов, это не правильно.
Для потребителей. Я уже приводил в пример маркеты на современных смартфонах. Заплатить 30-100 рублей за хороший контент не жалко, тем более когда это делается в один клик. Система работает за счет массовости покупок, думаю можно подобное внедрить и в остальные сферы этих отношений.
Нет, конечно. Но сейчас складывается такое ощущение, что на произведении том или ином они наживаются намного больше автора. Было уже много примеров, когда сам автор был совершенно не против свободного распространения своего продукта, но ему не позволял делать этого контракт с такого рода посредниками. Но, повторюсь, любой труд должен быть оплачен, если он полезен. Так что если я ошибаюсь в логике функционирования всех этих отношений, то конечно оплата должна быть.
Ну так если эта охрана такая неэффективная, то может и не выгодно в нее вообще деньги вкладывать? Хотя опять же сложный вопрос очень, но у меня складывается впечатление, что порой на суды и адвокатов тратят больше денег, чем якобы недополучили от свободного распространения.
И опять получаем проблему удобства использования. Я не хочу искать, я не хочу писать, я хочу посмотреть фильм по адекватной цене и с минимальным количеством действий.
100%-ное попадание в яблочко!
Ну тут я имел ввиду по большей части музыку. Ведь давно уже говорилось о том, что тому или иному исполнителю выгодно привлекать своих поклонников на концерты выкладыванием альбомов в свободный доступ, и некоторый даже этим активно пользуются.
Да, как не прискорбно, но Вы полностью правы.
1) Безусловно, труд должен вознаграждаться. Но хочется вознаграждать именно автора, а не бесчисленные редакции, студии записи и т.д.
2) Нет нормальных условий, для того, что бы платить за контент. Нет адекватных цен на него. Что бы потреблять лицензионный контент, мало того, что приходится платить, так еще и сделать это не так просто как кажется. Как хороший пример, маркеты на мобильных телефонах (особенно на закрытых iOS и WP), и там конечно есть джейлбрейки и все такое, но доля этого существенно ниже, т.к. заплатить там намного проще и цены весьма приемлемы.
3) Ведь далеко не каждый, кто скачал книжку или фильм нахаляву, заплатил бы за них, если бы нельзя было найти их бесплатно. Я бы даже сказал заплатили бы единицы. Следовательно ущерб от пиратской деятельности подсчитан совершенно не верно, ну и конечно же, совершенно забывают о том, что пиратский контент очень не плохая реклама для некоторого вида контента и косвенные доходы от него вполне могут компенсировать убытки.
Кстати, а если в Вашем примере без file_exists файл не пропал, а просто у скрипта нет прав на его чтение? В этом случае warning бы очень помог быстро обнаружить ошибку.
1) Как написали выше, собственный error_handler
2) display_errors в off, и контролировать возвращаемое значение от fopen. В случае ошибки придет false.
И к слову сказать, я считаю, что это более правильные варианты, нежели подавлять ошибку с помощью @.
Вообщем, не панацея конечно, но в некоторых ситуациях модуль будет удобен для использования, имхо.
Здесь несомненно, выбор это всегда хорошо. Как я уже говорил, люди все разные и усваивать информацию все могут по разному.
Достаточно субъективный показатель конечно, но в целом да, Вы правы.
Уточню, я ни в коем случае не против локализированных доков, но сам стараюсь использовать оригинальные варианты.
Но судя по результатам опроса среди нас много либо людей с другим иностранным за плечами, либо тех, кому читать доки на русском все же привычнее. Каждому свое, как говорится!