Сам работаю за проектором уже больше 6 лет, вот несколько советов от меня:
1. Не покупайте проекторы с лампой накаливания (как у топикстартера), лучше посмотрите в сторону LED-проекторов. Они значительно тише, меньше и должны прослужить вам несколько лет (с лампой накаливания же придется ее менять через год максимум).
2. Не гонитесь за большими разрешениями, так как все, что больше fullhd, значительно дороже. (Я так вообще работаю за 1280х800 — никакого дискомфорта).
3. Самый главный параметр проектора для вас — throw ratio. Чем он ниже, тем большую диагональ картинки вы получите. Но давайте по-порядку.
Если кто не знает, чем дальше проектор от поверхности — тем больше диагональ картинки «падает» на поверхность. Еще раз: дальше проектор — больше картинка, ближе — меньше. Для любого проектора.
Но вот какую именно диагональ вы получите зависит от throw ratio, которая расчитывается так: throw ratio = диагональ картинки / расстояние от проектора до поверхности
Мой первый проектор имел throw ratio 1.1 (то есть если от проектора до поверхности 1м, картинка будет ~0.9м или 35"). Пототом купил проектор с throw ratio 0.9 — стало значительно лучше. Если бы покупал новый — искал бы throw ratio еще меньше.
4. Поверхность, на которую вы планируете проецировать проектор, должна быть белой и не рельефной. Идеально, конечно же, проекционный екран.
5. Качество картинки проекторов очень сильно отличается. Даже разные модели одного производителя. Я работаю за Asus B1M, он для меня идеальный, но таких уже не выпускают. Пробовал Asus P3B — работать с текстом на нем не смог, вернул. Так что нужно идти в магазин и пробовать. Если такой возможности нет — тогда покупайте проектор в тех интернет-магазинах, которые дают возможность возвратить товар назад.
6. Очень важное — на поверхность нужно минимизировать попадание света от сторонних источников. (Иначе картинка будет блеклой, придется выкручивать яркость на максимум и оттого глаза начнуть уставать в разы больше). Замечу, что это не означает, что в комнате должно быть темно. Просто старайтесь сделать так, чтобы источники света были либо далеко, либо светили не на экран проектора.
То же касается окон — идеально ставить экран проектора на ту же стену, где окно. Таким образом, свет от окна не будет прямо попадать на экран. Если такой возможности нет — не беда. Грубые шторы либо полностью непрозрачные жалюзи никто не отменял. В приципе, если работать днем вы (вдруг) не планируете — можно про окна не думать.
Если будут вопросы — задавайте, постараюсь ответить.
А можно я предоставлю самую частую ошибку, которую делают работодатели в моем городе? Не дают информации по зарплатах. Вообще. Никакой. То есть типичный разговор с рекрутером в Скайпе выглядит так:
— Здравствуйте, спасибо что добавили. Ваш опыт нам показался интересным и мы хочем предложить вам взглянуть на нашу вакансию. У нас новый интересный проект с хорошим стеком. Буду благодарна за ответ.
— Добрый день. Стек действительно интересный, но сейчас у меня неплохой проект на текущем месте работы, пока что не вижу преимуществ.
— Может придете на собеседование, узнаете больше про проект? У нас хорошие условия.
— А что можете предложить? Например, на какой уровень зарплаты можно расчитывать на этой позиции?
— Извините, но мы не предоставляем такую информацию.
И так сплошь и рядом. Я понимаю, почему они так делают: хотят урвать высококвалифицированого специалиста подешевле, чтобы, продав его заказчику, получить хорошую маржу. (Ведь много специалистов оглашают ожидания по зарплате в сумме значительно меньшей, чем компания реально может такому специалисту платить).
Но, извините, это вы ко мне стучитесь, а не я к вам. И если вы не согласны предоставить информацию по ключевому параметру сотрудничества (зарплате), то какого черта вы мне пишете?
На первй взгляд, плохого ничего (хоть и идея достаточно революционная, согласитесь).
Но, поскольку Play использует Ebean (имплементация JPA), то для Lazy loading JPA должна иметь геттер. И, поскольку в коде его нет, сам плей в момент компиляции будет его генерировать и вставлять в класс, а все участки кода, где используется этот публичный филд, заменит на геттер.
И вот, дебажите вы свое приложение, в поле у вас значение null (ибо lazy loading), чтобы подтянуть значения из базы вам нужно сделать кол на геттер в дебагерре, но его в сорсах нет.
Да много чего на самом деле.
1. В Спринге есть куча проверенного и рабочего функционала как из коробки, так и в виде модулей. В Play же из коробки даже нет DI, это по-моему провал.
2. Если в спринге пытаются держать хоть какое-то backward-compatibility, то в play оно отсутствует как класс. Я помню как наша команда неделю переводила плейовский проект с одной минорной (подчеркиваю — минорной) версии на другую минорную.
3. Вероятность найти на том же стэковерфлове ответ на вопрос в контексте спринга в разы выше. Есть куча статей с примерами. Не плей кроме официальной документации толком негде больше смотреть (а если и есть, то из-за отсутствия backward-compatibility работать на конкретной версии плея оно вряд-ли будет).
4. Все модули прибиты гвоздями. Хочешь вместо плейовского Ebean использовать Hibernate? А вот фиг тебе. Хочешь вместо sbt заюзать gradle или maven — то же самое.
5. Свои конвеншены написания кода. (Например, модельки должны иметь публичные поля).
Ну и еще много чего, сейчас все и не вспомню. Короче, после 2-х лет работы с плей я не вернусь на него ни за какие деньги. По крайней мере в ближайшем будущем.
Спасибо за ответ, но я все равно не вижу преимуществ DI через конструктор вместо инджекта в поле.
1. Инжект в приватное поле требует поставить field.setAccessible(true), которые не всегда возможен.
Не всегда — это когда? Я таких случаев не знаю.
2. Начиная с Java 9 field.setAccessible(true) — будет не всегда доступен (если не будет выключен полностью).
3. Начиная с Java 10 — его собирались выключить полностью или еще больше ограничить.
И я почти уверен, что до релиза там будет все как было, так как они поломают кучу библиотек, а backward-compatibility это главная фишка Java. Это все-таки не Unsafe, на backward-compatibility которого можно наплевать, так как он формально не часть спецификации.
4. Чтобы выполнить трифиальный тест — нужно подымать контейнер для того, чтобы заинжектить поле!!!
Не нужно, гуглить в сторону @InjectMocks и MockitoAnnotations.initMocks(this)
5. Инжект в поле класса не дает возможности сделать оптимизацию по кешированию конструкторов (см. метод референс) и заставляет всегда выполнять инжект только через рефлексию.
И чем же это плохо? При setAccessible(true) у вас перформенс будет почти тот же, что и при сеттере. Кеш конструктора сделает оптимизацию вам в лучшем случае на несколько миллисекунд.
Не соглашусь, что @Autowired через сеттер или конструктор
облегчает рефакторинг и написание тестов
. Я бы даже сказал наоборот — утруждает.
Мне нужна зависимость? Я пишу одну строку кода поля и ставлю одну аннотацию. Все. Никаких сеттеров, конструкторов, присвоения значений в конструкторе не нужно.
Мне нужно написать тест? Легко — аннотации Mock, @InjectMocks и MockitoAnnotations.initMocks(this) в тестовом классе — и мой объект для юнит-тестирования готов. Никаких лишних телодвижений, меньше кода и усилий. Не понимаю, почему кто-то считает @Autowired над полем плохим тоном, я за несколько лет работы со спрингом так и не нашел объяснения для себя почему так делать плохо, а вот через конструктор — хорошо.
Вы не пробовали посчитать во сколько обойдется двойной набор ВСЕХ приложений на разные ОС
Ну вэб-приложения же как-то делают и чтобы на хроме, и чтобы на фаерфоксе, и даже на ие работали (хотя в 90-е никто и представить не мог, что ие когда-то сметут с трона). И мобильные приложения сразу пишут под Андроид и iOS. Уберите монополию на десктопе — будет то же самое.
В каком проценте делить пользователей и функциональность компании на разные ОС
Это уже от стратегии и менеджмента зависит. Посмотрите на Приватбанк — у них в отделениях работают на линуксе и iOS (да, вы не ослышались, iOS). И ничего — отделения функционируют прекрасно, во время Пети упали терминалы на Windows, но все остальное работало. И как показала практика, стратегия Приватбанка здесь — правильная, а тех, кто завязал всю свою инфраструктуру на одну систему — нет.
Уверены? Я могу ошибаться, но (насколько я осведомлен) в сетевом оборудовании огромный процент прошивок на bsd и прочих юниксах. Я надеюсь, вы понимаете, что linux != bsd/unix, хоть это и одно семейство ОС.
Так что тут как раз-таки монополии нет, есть много продуктов от разных производителей. И если уязвимость будет в одном, упадет только часть сети, а не вся сеть.
Так как мой предыдущий комментарий про монополию Windows заминусовали, решусь-таки на примере пояснить, что я имею в виду, может кто-то не понял моей мысли.
Представьте себе ситуацию, что на рынке легковых автомобилей есть монополист А с 90% долей рынка. Более того, почти все водители учились управлять автомобилями компании А, и плохо себе представляют как управлять автомобилями марок Б и В. Но и это не самое главное — авторегистраторы, gps-трекеры, автомагнитолы и прочие автомобильные принадлежности других фирм тоже делаются исключительно под марку А, и очень редко — под А, Б и В.
И вот вас назначили менеджером по транспортному обеспечению в какой-то организации. Естественно, даже если вы симпатизируете машинам Б и В, вы будете покупать исключительно автомобили А, або при прочих равных затрат будет менше, персонал знает как их водить, а ваши gps-трекеры работают только с ними.
В один прекрасный день группа вымогателей узнает, что в автомобилях марки А есть критическая уязвимость, с помощью которой автомобиль можно заблокировать. И начинают массово блокировать автомобили, паралельно требуя выкупа от собственников за «разблокировку». У вашей организации за час заблокировали 10% автомобилей, и естественно, вы даете распоряжение вернуть все машини назад в парк и перестать использовать. Транспортное обеспечение вашей организации полностью встало до того момента, пока критическая уязвимость не будет устранена.
Если бы у вас использовались не только автомобили А, но еще и Б и В, работа вашей организации не встала бы полностью, потому что автомобили А бы вы вернули в парк, но Б и В продолжали бы работать. Но у вас автомобили только А, ибо А — монополист и вам пришлось покупать их.
Такое с автомобилями сейчас невозможно потому, что нет монополии одного автопроизводителя. Но такая ситуация возможна на ПК потому, что здесь монополия есть.
Я с вами согласен. Ситуация, которую вы описали — это следствие монополии, ни больше ни меньше.
Приведу пример с браузерами. Вспомните эпоху монополии Internet Explorer — тогда тоже все сидели на нем. Ну и сайты верстались исключительно под IE, ибо 90% рынка. В итоге любая критическая уязвимость либо баг в IE (потенциально) мог запросто сломать весь вэб.
Но потом на сцену вышли фаерфокс, хром, другие браузеры, монополия была сломана и сайты уже перестали делаться под один браузер. И сейчас, если в одном из браузеров найдется критическая уязвимость либо баг, упадет только часть вэб-клиентов, но не сломается все.
Простой даже в несколько дней будет гарантированно дешевле.
Вы уверены? Убытки уже оценивают в миллиарды гривен. Я сильно сомневаюсь, что при возможности нормальной взаимозаменяемости Windows другой ОС’ью в рабочей среде, поддержка стоила бы дороже всех этих убытков (и да, Приватбанк — хороший пример). Но нормальной взаимозаменяемости на десктопе нет, потому что тут монополия Windows.
Такая ситуация была бы невозможна в сфере мобильных ОС, ведь тут Android вполне себе конкурентная система для iOS и наоборот. То же самое в сфере браузеров — хром, фаерфокс и т. д.
И хоть меня продолжают минусовать, я все равно уверен, что любая монополия — зло. А если кто-то считает иначе, вспомните, что было с вэбом в эпоху монополии Internet Explorer.
В этом, собственно, и проблема — трудно заменить винду, потому она всюду стоит. А раз всюду стоит, то и случилось что случилось. Была бы возможность нормальной взаимозаменяемости систем для работы — было бы тогда несколько систем и организация бы не была заблокирована.
Если бы вы мне сказали эту мысль вчера, я бы пожалуй с вами согласился. Но сегодня — нет.
Я думаю вы согласитесь, что убытки компаний, подвергшись атаке, будут огромны (и через простой, и через потерю данных). А вот если бы была возможность держать в организации парк машин с разными системами, тогда потери были бы в разы меньше. Конечно, тогда нужно, чтобы каждая система могла на одном уровне покрывать все потребности в работе, чего сейчас на десктопе трудно добиться, к сожалению. В этом и проблема.
1. Не покупайте проекторы с лампой накаливания (как у топикстартера), лучше посмотрите в сторону LED-проекторов. Они значительно тише, меньше и должны прослужить вам несколько лет (с лампой накаливания же придется ее менять через год максимум).
2. Не гонитесь за большими разрешениями, так как все, что больше fullhd, значительно дороже. (Я так вообще работаю за 1280х800 — никакого дискомфорта).
3. Самый главный параметр проектора для вас — throw ratio. Чем он ниже, тем большую диагональ картинки вы получите. Но давайте по-порядку.
Если кто не знает, чем дальше проектор от поверхности — тем больше диагональ картинки «падает» на поверхность. Еще раз: дальше проектор — больше картинка, ближе — меньше. Для любого проектора.
Но вот какую именно диагональ вы получите зависит от throw ratio, которая расчитывается так:
throw ratio = диагональ картинки / расстояние от проектора до поверхностиМой первый проектор имел throw ratio 1.1 (то есть если от проектора до поверхности 1м, картинка будет ~0.9м или 35"). Пототом купил проектор с throw ratio 0.9 — стало значительно лучше. Если бы покупал новый — искал бы throw ratio еще меньше.
4. Поверхность, на которую вы планируете проецировать проектор, должна быть белой и не рельефной. Идеально, конечно же, проекционный екран.
5. Качество картинки проекторов очень сильно отличается. Даже разные модели одного производителя. Я работаю за Asus B1M, он для меня идеальный, но таких уже не выпускают. Пробовал Asus P3B — работать с текстом на нем не смог, вернул. Так что нужно идти в магазин и пробовать. Если такой возможности нет — тогда покупайте проектор в тех интернет-магазинах, которые дают возможность возвратить товар назад.
6. Очень важное — на поверхность нужно минимизировать попадание света от сторонних источников. (Иначе картинка будет блеклой, придется выкручивать яркость на максимум и оттого глаза начнуть уставать в разы больше). Замечу, что это не означает, что в комнате должно быть темно. Просто старайтесь сделать так, чтобы источники света были либо далеко, либо светили не на экран проектора.
То же касается окон — идеально ставить экран проектора на ту же стену, где окно. Таким образом, свет от окна не будет прямо попадать на экран. Если такой возможности нет — не беда. Грубые шторы либо полностью непрозрачные жалюзи никто не отменял. В приципе, если работать днем вы (вдруг) не планируете — можно про окна не думать.
Если будут вопросы — задавайте, постараюсь ответить.
И так сплошь и рядом. Я понимаю, почему они так делают: хотят урвать высококвалифицированого специалиста подешевле, чтобы, продав его заказчику, получить хорошую маржу. (Ведь много специалистов оглашают ожидания по зарплате в сумме значительно меньшей, чем компания реально может такому специалисту платить).
Но, извините, это вы ко мне стучитесь, а не я к вам. И если вы не согласны предоставить информацию по ключевому параметру сотрудничества (зарплате), то какого черта вы мне пишете?
Я работал с Play вплоть до версии 2.3.х, и там DI еще не было.
Guice добавили из коробки начиная с 2.4.x, когда я уже с него ушел.
Но, поскольку Play использует Ebean (имплементация JPA), то для Lazy loading JPA должна иметь геттер. И, поскольку в коде его нет, сам плей в момент компиляции будет его генерировать и вставлять в класс, а все участки кода, где используется этот публичный филд, заменит на геттер.
И вот, дебажите вы свое приложение, в поле у вас значение null (ибо lazy loading), чтобы подтянуть значения из базы вам нужно сделать кол на геттер в дебагерре, но его в сорсах нет.
1. В Спринге есть куча проверенного и рабочего функционала как из коробки, так и в виде модулей. В Play же из коробки даже нет DI, это по-моему провал.
2. Если в спринге пытаются держать хоть какое-то backward-compatibility, то в play оно отсутствует как класс. Я помню как наша команда неделю переводила плейовский проект с одной минорной (подчеркиваю — минорной) версии на другую минорную.
3. Вероятность найти на том же стэковерфлове ответ на вопрос в контексте спринга в разы выше. Есть куча статей с примерами. Не плей кроме официальной документации толком негде больше смотреть (а если и есть, то из-за отсутствия backward-compatibility работать на конкретной версии плея оно вряд-ли будет).
4. Все модули прибиты гвоздями. Хочешь вместо плейовского Ebean использовать Hibernate? А вот фиг тебе. Хочешь вместо sbt заюзать gradle или maven — то же самое.
5. Свои конвеншены написания кода. (Например, модельки должны иметь публичные поля).
Ну и еще много чего, сейчас все и не вспомню. Короче, после 2-х лет работы с плей я не вернусь на него ни за какие деньги. По крайней мере в ближайшем будущем.
Не всегда — это когда? Я таких случаев не знаю.
И я почти уверен, что до релиза там будет все как было, так как они поломают кучу библиотек, а backward-compatibility это главная фишка Java. Это все-таки не Unsafe, на backward-compatibility которого можно наплевать, так как он формально не часть спецификации.
Не нужно, гуглить в сторону @InjectMocks и MockitoAnnotations.initMocks(this)
И чем же это плохо? При setAccessible(true) у вас перформенс будет почти тот же, что и при сеттере. Кеш конструктора сделает оптимизацию вам в лучшем случае на несколько миллисекунд.
Мне нужна зависимость? Я пишу одну строку кода поля и ставлю одну аннотацию. Все. Никаких сеттеров, конструкторов, присвоения значений в конструкторе не нужно.
Мне нужно написать тест? Легко — аннотации Mock, @InjectMocks и MockitoAnnotations.initMocks(this) в тестовом классе — и мой объект для юнит-тестирования готов. Никаких лишних телодвижений, меньше кода и усилий. Не понимаю, почему кто-то считает @Autowired над полем плохим тоном, я за несколько лет работы со спрингом так и не нашел объяснения для себя почему так делать плохо, а вот через конструктор — хорошо.
Ну вэб-приложения же как-то делают и чтобы на хроме, и чтобы на фаерфоксе, и даже на ие работали (хотя в 90-е никто и представить не мог, что ие когда-то сметут с трона). И мобильные приложения сразу пишут под Андроид и iOS. Уберите монополию на десктопе — будет то же самое.
Это уже от стратегии и менеджмента зависит. Посмотрите на Приватбанк — у них в отделениях работают на линуксе и iOS (да, вы не ослышались, iOS). И ничего — отделения функционируют прекрасно, во время Пети упали терминалы на Windows, но все остальное работало. И как показала практика, стратегия Приватбанка здесь — правильная, а тех, кто завязал всю свою инфраструктуру на одну систему — нет.
Уверены? Я могу ошибаться, но (насколько я осведомлен) в сетевом оборудовании огромный процент прошивок на bsd и прочих юниксах. Я надеюсь, вы понимаете, что linux != bsd/unix, хоть это и одно семейство ОС.
Так что тут как раз-таки монополии нет, есть много продуктов от разных производителей. И если уязвимость будет в одном, упадет только часть сети, а не вся сеть.
Представьте себе ситуацию, что на рынке легковых автомобилей есть монополист А с 90% долей рынка. Более того, почти все водители учились управлять автомобилями компании А, и плохо себе представляют как управлять автомобилями марок Б и В. Но и это не самое главное — авторегистраторы, gps-трекеры, автомагнитолы и прочие автомобильные принадлежности других фирм тоже делаются исключительно под марку А, и очень редко — под А, Б и В.
И вот вас назначили менеджером по транспортному обеспечению в какой-то организации. Естественно, даже если вы симпатизируете машинам Б и В, вы будете покупать исключительно автомобили А, або при прочих равных затрат будет менше, персонал знает как их водить, а ваши gps-трекеры работают только с ними.
В один прекрасный день группа вымогателей узнает, что в автомобилях марки А есть критическая уязвимость, с помощью которой автомобиль можно заблокировать. И начинают массово блокировать автомобили, паралельно требуя выкупа от собственников за «разблокировку». У вашей организации за час заблокировали 10% автомобилей, и естественно, вы даете распоряжение вернуть все машини назад в парк и перестать использовать. Транспортное обеспечение вашей организации полностью встало до того момента, пока критическая уязвимость не будет устранена.
Если бы у вас использовались не только автомобили А, но еще и Б и В, работа вашей организации не встала бы полностью, потому что автомобили А бы вы вернули в парк, но Б и В продолжали бы работать. Но у вас автомобили только А, ибо А — монополист и вам пришлось покупать их.
Такое с автомобилями сейчас невозможно потому, что нет монополии одного автопроизводителя. Но такая ситуация возможна на ПК потому, что здесь монополия есть.
Приведу пример с браузерами. Вспомните эпоху монополии Internet Explorer — тогда тоже все сидели на нем. Ну и сайты верстались исключительно под IE, ибо 90% рынка. В итоге любая критическая уязвимость либо баг в IE (потенциально) мог запросто сломать весь вэб.
Но потом на сцену вышли фаерфокс, хром, другие браузеры, монополия была сломана и сайты уже перестали делаться под один браузер. И сейчас, если в одном из браузеров найдется критическая уязвимость либо баг, упадет только часть вэб-клиентов, но не сломается все.
Вы уверены? Убытки уже оценивают в миллиарды гривен. Я сильно сомневаюсь, что при возможности нормальной взаимозаменяемости Windows другой ОС’ью в рабочей среде, поддержка стоила бы дороже всех этих убытков (и да, Приватбанк — хороший пример). Но нормальной взаимозаменяемости на десктопе нет, потому что тут монополия Windows.
Такая ситуация была бы невозможна в сфере мобильных ОС, ведь тут Android вполне себе конкурентная система для iOS и наоборот. То же самое в сфере браузеров — хром, фаерфокс и т. д.
И хоть меня продолжают минусовать, я все равно уверен, что любая монополия — зло. А если кто-то считает иначе, вспомните, что было с вэбом в эпоху монополии Internet Explorer.
Убытки за потерю данных — да. Но вот простой дня работы целой компании обойдется недешево.
В этом, собственно, и проблема — трудно заменить винду, потому она всюду стоит. А раз всюду стоит, то и случилось что случилось. Была бы возможность нормальной взаимозаменяемости систем для работы — было бы тогда несколько систем и организация бы не была заблокирована.
Я думаю вы согласитесь, что убытки компаний, подвергшись атаке, будут огромны (и через простой, и через потерю данных). А вот если бы была возможность держать в организации парк машин с разными системами, тогда потери были бы в разы меньше. Конечно, тогда нужно, чтобы каждая система могла на одном уровне покрывать все потребности в работе, чего сейчас на десктопе трудно добиться, к сожалению. В этом и проблема.