суббота, 7 сентября 2013 г.

[life.photo] О качестве снимков 41-мегапиксельной камеры в телефоне Nokia 1020

Несколько дней назад в своей Google+ ленте я высказал удивление анонсу телефона с 41-мегапиксельной камерой внутри. Вчера на dpreviw увидел полноразмерные примеры фотографий с этого телефона: Nokia sends National Geographic photog into the American West with a Lumia 1020. Скачал эти примеры к себе, посмотрел в масштабе 1:1...

Чуда не случилось. Как по мне, как снимки и шумные, и мыльные. Вот пример кропа с вот этого снимка:

По поводу шума, мне кажется, все понятно -- слишком уж мелкий размер пикселя чтобы выдавать качественное изображение. А вот по поводу мыльность не очень ясно: возможно, это следствие открытой диафрагмы (f=2.2). Хотя на таком расстоянии от камеры, да еще при такой маленькой матрице глубина резкости должна быть достаточной. Так что, полагаю, виновато опять-таки общее качество камеры.

Понятное дело, что фотографии с Nikon D800E (у которого мегапикселей, как бы это не было смешно, чуть поменьше, всего 36), в масштабе 1:1 производят совсем другое впечатление. Примеры таковых можно взять хотя бы на том же dpreview.

Ну и раз чуда не произошло, то остается только в очередной раз задать самому себе вопрос: ну вот нафига в телефоне 41 (вдумайтесь, сорок один!) мегапиксель?

На мой взгляд, большое число мегапикселей нужно для двух вещей:

  • жестокого кропинга, когда из-за неудачной композиции снимка 3/4 его площади нужно выбрасывать. Но для оставшейся 1/4 очень критичным будет качество, поскольку именно этот фрагмент придется "растягивать" для нормальной публикации или печати. В случае с Nokia 1020 качество вряд ли будет иметь место;
  • для печати на большой формат. У меня был опыт печати 12Mpx снимка с Nikon D90 на размер порядка 120x90см. При том, что исходный снимок нуждался в серьезном подавлении шумов, результат получился где-то на 3+ по 5-бальной шкале. Однако, поскольку фотографию такого размера нельзя рассматривать стоя вплотную к ней, то на нормальном для ее обзора расстоянии тех недостатков, про которые знаю я, практически не видно. Хорошие 40-мегапиксельные фотографии, по идее, можно спокойно печатать на формат под 150см с качеством под 150dpi. Такие снимки производят очень сильное впечатление. Например, у меня дома висит отпечаток вот этой панорамы шириной 180см. Но там картинка в масштабе 1:1 имеет вот такое качество:

Кстати говоря, при размерности 9046x1835px моя панорама весит всего лишь 16Mpx, т.е. в два раза меньше, чем один Limuna-вский снимок.

Имхо, разница с Lumina 1020 очевидна. И мне представляется, что 40-мегапиксельные Lumina-вские снимки будут нормально выглядеть при печати до 30x20см. А вот все что больше, уже под вопросом. Но для 30x20см достаточно 4 или 5 мегапикселей, не больше. А уж если до печати дело вообще не дойдет, а фотографии, максимум, будут постится в Фейсбук/ВКонтакт/Одноклассники в размере 800x600, то там даже и о 5Mpx речь не идет. И зачем же тогда 41Mpx?

Похоже Элоп, который на протяжении нескольких последних лет делал все, чтобы обанкротить Nokia и задешево продать ее Microsoft-у, никак не может остановится и продолжает свою разрушительную деятельность.


PS. А вот таким производителям, как PhaseOne, нужно готовится к худшему. Это сейчас они имеют возможность продавать свои 60-мегапиксельные задники по цене под 40K USD. Но год назад для Nikon-а умудрились впихнуть 36Mpx на 35mm матрицу, а в этом для Nokia 41Mpx на 1/1.5" матрицу. Так что 60Mpx с качеством Nikon D800 по гораздо, гораздо меньшей цене остается ждать совсем недолго.

PPS. А поскольку тенденция вбрасывать на массовый рынок все более и более мегапиксельные камеры исчезать не собирается, то для разработчиков ПО для обработки фотографий, похоже, наступают золотые времена. Не Lightroom-ом же единым, в конце-концов. Даже жаль, что я никогда не имел отношения к этой области :(

четверг, 5 сентября 2013 г.

[management] ...и культивировать радостную атмосферу...

В одной занимательной книге по деловому администрированию наткнулся на фрагмент, который, в буквальном смысле made my day :)

Вам потребуется найти сотрудников, способных на неординарные достижения, а так же создать и культивировать радостную атмосферу, в которой будет процветать успех.

При попытке представить себе коллектив, в котором радостная атмосфера царит хотя бы на протяжении полугода (не говоря уже о годе или нескольких годах) почему-то на ум приходит психбольница, где все пациенты под завязку напичканы вызывающими радостный смех и блаженные улыбки препаратами.

среда, 4 сентября 2013 г.

[business] Слухи об отмене правила 20% времени в Google

Вчера в информационной рассылке dev.by пришло известие о том, что Google отменил свое правило, позволяющее своим сотрудникам тратить 20% рабочего времени на собственные проекты, не связанные со своими прямыми обязанностями в Google. Вот сообщение об этом на dev.by. Сразу же сильно удивился: как я это я прозевал такую оглушительную новость, по сути о превращении корпорации Добра в КОРПОРАЦИЮ Добра ;). Но первая же попытка поиска первоисточников показала, что dev.by в очередной раз оправдал в моих глазах свою репутацию*. А с правилом 20% все довольно интересно.

Как я понимаю, началось все с вот этой заметки в Quartz. На что последовал ответ Google, опубликованный в том же Quartz. Официально это правило живет и здравствует. Но еще одна заметка в Quartz говорит о том, что ситуация несколько сложнее: сотрудники Google могут тратить 20% своего времени на свои проекты, но не все отваживаются на это, т.к. им и основной работы хватает выше крыши. А тут еще и "stack ranking policy", т.е. сортировка сотрудников по результатам работы и пристальное внимание к тем 20% сотрудников, которые оказались в самом низу. Так что многим в Google не до собственных проектов. (Disclaimer: сам я не работаю в Google, а вышеизложенное впечатление у меня сформировалось на основании прочитанных в Интернете статей).

Но самым интересным в поиске информации о правиле 20% в Google оказались две статьи в Wired:

Google Couldn’t Kill 20 Percent Time Even if It Wanted To.

The 15 Percent Solution.

Последняя статья особенно интересна. Мало того, что она написана в 1998, так она еще рассказывает о практике компании 3M, позволявшей сотрудникам компании тратить до 15% своего времени на занятия, не имеющие отношения к их непосредственной работе. Причем практиковалось это в 3M задолго до появления Google. Забавным примером являются липкие листочки Post-It: их появление произошло как раз благодаря этой практике :)

Если кому-то не лень потратить полчаса своего времени на чтение двух интересных статей на английском, то рекомендую заглянуть по двум вышеуказанным ссылкам. Лично мне понравилось и показалось полезным.


* Про репутацию dev.by. Как по мне, так этот сайт напоминает мажора: много понтов, мало толку. Эдакая столичная штучка, только провинциального разлива. Попытка закосить под распальцованных, бодреньких и уверенных в себе москвичей. Проблема, правда, в том, что в Москве под внешней развязностью может скрываться матерый профессионализм (без которого там не выжить). А в Минске только распальцованность и никакого достойного наполнения внутри. В свое время от dev.by был минимальный выхлоп при поиске сотрудников (намного меньший, чем от job.tut.by, при больших затратах). Теперь же постоянно сталкиваюсь с малой полезностью информационных материалов dev.by. Так что фигня полная этот дев точка бай. И да, я злой.

вторник, 3 сентября 2013 г.

[business] Microsoft собирается купить Nokia

Вот, вообщем-то, логический итог внедрения в правление Nokia выходцев из Microsoft:

Microsoft to acquire Nokia’s devices & services business, license Nokia’s patents and mapping services

Хорошо хоть, что Nokia успела бизнес вокруг Qt передать Digia.

[books] Прочел книгу Э.Йордана "ИТ-Аутсорсинг"

Дочитал книгу Э.Йордана "ИТ-Аутсорсинг". За исключением двух небольших светлых моментов общее впечатление плохое: жалко потраченных на нее денег и времени.

Во-первых, оригинальное издание книги на английском языке произошло в 2004(!) году. И рассказывается в ней о быстро меняющейся ситуации с передачей рабочих мест из США в другие страны. При этом сама книга является своего рода подведением промежуточного итога еще более старой книги Йордана "Decline and Fall of the American Programmer" 1992 года. В "ИТ-Аутсорсинге" Йордан явно говорит, что со своими пессимистическими прогнозами в 1992 он ошибся, но в целом тенденция по переводу интеллектуальных разработок из США сохраняется и усиливается. Так вот, читая в 2013-м предположения и прогнозы, которые Йордан считал актуальными для 2004-го, я не мог понять: зачем нужно было переводить и издавать на русском языке эту книгу сейчас, в 2013-м? Какой в этом смысл? Гораздо интереснее было бы обновленное издание этой книги, в которой автор бы показал, что произошло за эти 9 лет, в чем он был прав, в чем ошибся, чего не увидел, а что превзошло даже его пессимистические ожидания. Но этого издания еще нет в природе :)

Во-вторых, эта книга, по большей части, посвящена обсуждению того, в какой же хреновой ситуации оказываются работники умственного труда в США в связи с растущим аутсорсингом в более дешевые страны. Йордан на протяжении многих страниц мягко намекает своим американским читателям о том, что жопа пришла всерьез и надолго. Что есть мало способов сохранить свой уровень жизни и привычный доход в 50K долларов в год, если все тоже самое может делать кто-то на другом конце Земли, получая всего 5K долларов за год.

Явно книга писалась для американского читателя. И явно ее основной целью было показать им, что за долгие годы экономического процветания США американцы привыкли жить хорошо и получать больше денег, чем где бы то ни было. Но мир изменяется, технологии развиваются. Теперь их работу могут делать не менее трудолюбивые, образованные и талантливые люди в других странах. Но за гораздо меньшие деньги. Поэтому американцам нужно готовится к тому, что они либо останутся без привычной работы (которая будет передана в Индию, Россию или Китай), либо им придется работать за совсем другие деньги (грубо говоря за зарплату разработчика ПО из Индии или Китая), либо им придется найти себе другое занятие (скорее всего в сфере обслуживания, т.к. производство перекочует из США в более дешевые места).

Так что, если вы, как и я, ждете от книги с названием "ИТ-Аутсорсинг" какой-то полезной информации о том, как оказывать услуги аутсорсинга, или советов о том, как правильно взаимодействовать с аутсорсерами, то в данной книге вы ничего этого не найдете. А найдете то, о чем я только что написал выше. Так что для читателя из СНГ данная книга, за малым исключением, бесполезна.

Из того, что мне понравилось в книге, могу отметить всего два момента. Первый -- это проделанный в самом начале книги обзор того, насколько сильно аутсорсинг проник в различные сферы обслуживания и производства в США. Интересно и полезно для кругозора.

Второй момент -- это небольшая глава номер 8 под названием "Последствия для компаний, покупающих продукты и услуги по обработке данных" (именно из этой главы я недавно приводил у себя в блоге интересную цитату). На мой взгляд, в ней Йордан очень грамотно и логично описывает возможные последствия передачи части интеллектуальной работы компании в аутсорсинг. По сути, чтение книги можно ограничить лишь этой главой.


В завершение хочу поделиться несколькими субъективными впечатлениями.

Оказалось, что я не очень четко провожу границу между разработкой софта под заказ и, собственно, аутсорсингом. Мне кажется, что расплодившиеся на просторах СНГ аутсорсинговые шарашки (включая белорусские ЕПАМ, itransition и пр.) успешно занимаются и тем, и другим. Поэтому я ранее подразумевал под "аутсорсингом" и то, и другое. И это, наверное, не правильно.

Думаю, что аутсорсинг из США и Европы в крупные города СНГ (в первую очередь в Москву, а так же в Питер, Киев и, возможно, Минск) задрал зарплаты разработчиков в этих городах до таких высот, что наши разработчики становятся настолько же уязвимыми перед коллегами из развивающихся стран, как и американские (и, возможно, нашим уже имеет смысл читать "ИТ-Аутсорсинг" заменяя в ней США на Москву). Кроме того, из-за зарплат на зарубежных проектах найм людей для собственных проектов становится практически невозможным. Не важно даже, на какого покупателя будет рассчитан этот проект -- на западного или российского. И все это не есть хорошо, на мой взгляд.

С другой стороны, есть у меня уверенность в том, что если наш аутсорсинг будут давить ценами из какой-нибудь Малайзии, то мы спокойно перейдем к более низким зарплатам. Ну станут хорошие разработчики ПО в Гомеле получать не 2-2.5K USD, а 750-1.5K. Да, неприятно, но и не смертельно. Те, кто хотят большего, уедут, как они это делают и сейчас. Остальные приспособятся. Вот только прогнозов о том, когда именно это произойдет я давать не буду :)

PS. И да, я так и не понимаю, какой смысл российской компании, которая держит основной центр по разработке ПО в провинции (будь то Гомель, Саратов, Оренбург или Магнитогорск) вместо инвестиций и развития своего центра разработки ПО передавать свои проекты на аутсорсинг другим российским компаниям. Ё-бизнес по-русски, надо полагать.

понедельник, 2 сентября 2013 г.

[prog.c++] Зафиксировал версию 2.1.0 проекта ObjESSty

Сегодня зафиксировал версию 2.1.0 своей библиотеки для сериализации C++ объектов ObjESSty в виде тега.

Версия 2.1.0 является результатом серьезного рефакторинга версии 2.0, которая в свое время создавалась в условиях жуткого цейтнота и, поэтому, содержала внутри много некрасивостей и недоделок. Версия 2.1.0 привела код ObjESSty в приемлемый для дальнейшего развития вид, новых возможностей в ней почти нет.

На данный момент версия 2.1.0 находится только в SVN-репозитории на SourceForge: tags/oess_2/2.1.0.

Выкладывать архив с ее исходниками я не планировал, т.к. не думаю, что сейчас эта библиотека будет кому-нибудь интересна. Но, если будут пожелания, то опубликую на SF и архив с исходниками, и архив с документаций и все, до чего доберусь ;) Вообще, если будут какие-то вопросы, замечания или предложения, то не стесняйтесь. Высказывайте их здесь, на SourceForge, по почте (eao197 на ГМайле). Все, что способно улучшить ObjESSty будет воспринято мной с большим вниманием и благодарностью.

Сейчас ObjESSty является частью проекта SObjectizer. Недавно на SF переехали все исходники этого проекта и дальнейшая его разработка будет вестись там. Есть у нашей команды задумки, которые мы собираемся воплотить в жизнь. Надеюсь, дело пойдет. Т.к. интерес к агентному программированию (или программированию на акторах) сейчас есть, в наличии хорошие фреймворки для JVM, а вот для С++ ситуация выглядит похуже. Мы хотим это исправить ;) Одна из актуальнейших целей для нас -- это перевод исходников и документации по SObjectizer (и всему, что в него входит) на английский язык. Будем признательны, если найдутся желающие помочь в этой непростой работе.

Лицензия у всех компонентов The SObjectizer Project, кстати говоря, одна из самых вменяемых: 3-х секционная BSD-лицензия. Т.е. бесплатно для любых коммерческих или некоммерческих проектов. Даром, если по простому ;)

Если говорить конкретно об ObjESSty, то на данный момент по скорости она проигрывает Google Protobuf-у где-то в 2.5 раза. Отчасти это объясняется заточенностью под более сложные структуры данных, отчасти несколько менее эффективной реализацией внутри. Так что задачей версии 2.2 будет сокращение отставания по скорости от Protobuf-а до минимума. Так же в версии 2.2 хочется реализовать поддержку таких вещей из C++11, как shared_ptr (и, возможно, weak_ptr), а так же unordered_set/multiset и unordered_map/multimap. А так же попробовать минимизировать объем DDL-описаний, которые начинают раздражать своей многословностью.

Кроме того, в процессе работы над ObjESSty 2.2 хотелось бы определиться с главным акцентом: должна ли ObjESSty развиваться именно как система сериализации сложных структур данных, либо же нужно специализироваться на коммуникационных протоколах (подробнее см. здесь).

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

Уважаемые читатели, если не сложно, то поспособствуйте распространению этой заметки. Например, нажимая +1 в Google+. Большое спасибо за понимание!

[prog.tools] Бинарники SlikSvn для Svn-1.8.1

В качестве дистрибутива Subversion для Windows я уже давно использую сборку от SlikSvn. На днях SlikSvn выложил дистрибутив для Svn-1.8.1. Взять можно здесь.

Для информации. В Svn-1.8 появилась долгожданная фича: операция move таки была реализована отдельной операцией. До версии 1.8 она выполнялась как совокупность из copy и remove. Что создавало проблемы при мержинге веток, которые долгое время развивались независимо друг от друга и накопили достаточное количество move в своей истории. Теперь с этим делом в Svn должно стать полегче.

Я пока пользовался Svn-1.7, ожидая появления 1.8.1 от SlikSvn. Вот, дождался :) Правда, Svn успел обновиться до 1.8.3, так что процесс ожидания рестартует ;)