я, возможно, глупый, но как можно смотреть видео высокой четкости 720р на экране высотой 600?
Или там еще 120 пикселей выдвигаются откуда-нибудь?
А если его масштабировать, то какой в нем смысл?
ИМХО, пеар для лохов
PS. Ну да, забыл, видео высокой четкости уже можно снимать телефоном.
PPS. Против EEE PC ничего не имею у самого 900.
Вы как-то недооцениваете сложность проблемы.
Я не изучал как ведут сеяб Яндекс.Фотки, но рискну предположить.
Что для отдачи самих фоток используется какой-то супер легкий сервер. И его задача была поставленна — наиболее быстро отдавать весь контент. Также рискну предположить, что такой сервер не один, и контент продублирован не на одной файловой системе.
Так что, когда пользователь пытается просмотреть свою фотографию «по-нормальному» веб-приложение вполне в состоянии проверить различные флаги этой фотографии и показать вам соотвествующий результат. Но!
Когда вы пытаетесь доступиться к фотографии по прямому ее урлу на сервере, тут уж проверки делать очень и очень дорого (вы помните мы предположили, что они используют очень высокопроизводительный сервер для отдачи бинарного контента).
Кроме того, если бы я работал в Яндексе, то я бы отдавал фотографии не просто высокопроизводительным сервером, а еще как-нибудь «извратился» с кешированием: или мощным кешированием внутри самих веб-серверов, либо реверс-прокси (типа кальмар) с кешированием всего, что только возможно, в гигантскую оперативную память (благо 64 бита позволяют), ни или просто в рейд быстрых винтов.
А теперь представьте, вы хотите, чтобы ваша фотография была физически удалена. Для этого нужно всего ничего — сделать purge — всех кешей.
PS. Я понимаю, где слабое место в моем рассуждении — обновления-то подхватываются. Возможно для кеширующего слоя нет команды — удалить из кеша, а по запросу он проверяет оригинал — для обновления, но оригинал-то в случае удаления не меняется. Возможно, перед удалением нужно замещать фотографию — репродукцией Малевича, так как они явно умеют их обновлять.
Мне кажется, вы не понимаете, это идеальная вакансия для определенных кандидатов.
Например, для студента без нормального опыта работы, причем скорее ай-тишного все же, чем маркетолога.
Студент может уметь и страничку сверстать, и на php уже «hello world» написал, и 3Д-макс запустить умеет, и курс экономики+маркетинга недавно прослушал, может умными словами в разговоре реагировать, ну и так далее. Я пытаюсь обобщить всех студентов, но есть и такая «универсальная» часть студентов, которые еще не определились чем они хотели бы занятся. Нужно от студента немного любознательности и адекватность.
Студентам иногда нужно получать где-то первый боевой опыт, а такие компании судя по всему все равно не смогут отличить начинающего специалиста от опытного.
Так что все будут довольны.
Скорее всего вакансия вашего знакомого HR не конкурирует с этой, но вы у него уточните, может им тоже нужен именно такой человек %)
Ну это у вас неправильные поезда были, «они делают неправильных проводниц» (с).
Я говорю о поездах, у которых нормальные розетки есть (с рисунком ноутбука рядом с розеткой).
Позвольте дать совет.
Я как-то в поезде встетил попутчика, который тоже сидел с ноутбуком и уже занимал единственную розетку. Увидев, что я достаю ноутбук, он полез в свою сумку у вытащил небольшой «пилот». И радостно со мной поделился электричеством.
Я, конечно, понимаю, что с маком и айфоном «пилот» не очень сочетается ;)
Но может можно, подобрать что-то компактное, например, «тройник»,
У меня есть личный способ тестирования FS, применимый скорее к девелоперской деятельности, чем к настройке серверов и стореджей.
Скачиваете какой-нибудь достаточно большой опенсорсный проект, и собираете его на нескольких файловых системах. При этом выключив такие трюки, как компиляция в память (как можно сделать например в gentoo подключив /var/tmp/portage через tmpfs).
Результаты нескольких сборок усредняете и выбираете файловую систему своей мечты.
По моим замерам (сборка большого java проекта), reiserfs, стоящая на зашифрованном разделе, обошла ext3 почти в 2 раза. Но тут конечно все зависит от винта, версии и конфигурации ядра и многих других параметров.
Тест должен именно имитировать предполагаемую деятельность возложенную на файловую систему, потому что в обычной жизни я редко запускаю команду cp в таких ситуациях, чтобы время ее выполнения было для меня критично.
Было бы интересно услышать про установку ZFS на flash карты, если вдруг кто-то пробовал.
Вот например Джонатан Шварц в своем блоге пишет, что это должно быть хорошо.
Я имею ввиду, что подключение файловых систем (не включенных в ядр, а иногда и включенных — NTFS, например) через FUSE — является очень рабочим и востребованным в Linux (кстати, и в MacOS тоже). И «костылей» тут никаких нет.
И если автор ветки не совсем разобрался, что есть FUSE, то не нужно о своей необразованности кричать.
Судя по обзору, отличий от поддержки NTFS, я не особо заметил, нужно ставить специальный пакет. Запускать руками разные команды, чтобы все заработало.
А если пользователи убунты привыкли к тому, что NTFS работает из каробки, то это заслуга мейнтейнеров убунты. А по сути все равно внутри трудится ntfs-3g, который в других дистрибутивах нужно доставлять.
За «тыкание» конечно стыдно (немного). Впредь буду сдерживаться.
Мы использовали очень похожую схему, поэтому предлагаю несколько улучшений:
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.
2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)
3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу
4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>
P.S. За Redmine спасибо — не знал о таком продукте.
Я, конечно, отвечаю не на Ваш вопрос. Но, возможно, вам пригодится www.shapeways.com/
Они вроде умеют печатать на 3D-принтере по моделям, причем сделать это можно онлайн. Возможно, Вы сможете как-то улучшить устройство «печатая» его малым тиражом. Заодно будет, что показывать потенциальным дилерам или китайцам. Если у Вас, конечно, еще нет готовой модели.
Сам еще не пробовал что-то там заказывать, если опыт будет удачным отпишите, пожалуйста.
Мне кажется, вы решаете разные задачи: «правильно» хранить файлы(картинки) и быстро отдавать.
Правильно хранить в вашем случае, чтобы не было проблем с целостностью, это в БД.
Быстро отдавать — прокси в режиме кеширования, например, Squid, ну и есть много других вариантов. Это конечно, если у вас большая нагрузка.(Иначе тут вообще нет проблемы)
Научите сквид кешировать на диск, если памяти в серверах мало :)
Да тут, конечно, есть проблема со временем обновления кеша. Но тут можно эксперементировать с заголовками, например отдавать из базы(приложения) не картинку, а только признак менялась она или нет, на основании заголовка прокси либо перезапросит ее, либо отдаст из кеша.
P.S. Могу соврать, но вроде бы фликр большинство популярных картинок держит в кеширующих проксях причем в памяти.
Или там еще 120 пикселей выдвигаются откуда-нибудь?
А если его масштабировать, то какой в нем смысл?
ИМХО, пеар для лохов
PS. Ну да, забыл, видео высокой четкости уже можно снимать телефоном.
PPS. Против EEE PC ничего не имею у самого 900.
Я не изучал как ведут сеяб Яндекс.Фотки, но рискну предположить.
Что для отдачи самих фоток используется какой-то супер легкий сервер. И его задача была поставленна — наиболее быстро отдавать весь контент. Также рискну предположить, что такой сервер не один, и контент продублирован не на одной файловой системе.
Так что, когда пользователь пытается просмотреть свою фотографию «по-нормальному» веб-приложение вполне в состоянии проверить различные флаги этой фотографии и показать вам соотвествующий результат. Но!
Когда вы пытаетесь доступиться к фотографии по прямому ее урлу на сервере, тут уж проверки делать очень и очень дорого (вы помните мы предположили, что они используют очень высокопроизводительный сервер для отдачи бинарного контента).
Кроме того, если бы я работал в Яндексе, то я бы отдавал фотографии не просто высокопроизводительным сервером, а еще как-нибудь «извратился» с кешированием: или мощным кешированием внутри самих веб-серверов, либо реверс-прокси (типа кальмар) с кешированием всего, что только возможно, в гигантскую оперативную память (благо 64 бита позволяют), ни или просто в рейд быстрых винтов.
А теперь представьте, вы хотите, чтобы ваша фотография была физически удалена. Для этого нужно всего ничего — сделать purge — всех кешей.
PS. Я понимаю, где слабое место в моем рассуждении — обновления-то подхватываются. Возможно для кеширующего слоя нет команды — удалить из кеша, а по запросу он проверяет оригинал — для обновления, но оригинал-то в случае удаления не меняется. Возможно, перед удалением нужно замещать фотографию — репродукцией Малевича, так как они явно умеют их обновлять.
Например, для студента без нормального опыта работы, причем скорее ай-тишного все же, чем маркетолога.
Студент может уметь и страничку сверстать, и на php уже «hello world» написал, и 3Д-макс запустить умеет, и курс экономики+маркетинга недавно прослушал, может умными словами в разговоре реагировать, ну и так далее. Я пытаюсь обобщить всех студентов, но есть и такая «универсальная» часть студентов, которые еще не определились чем они хотели бы занятся. Нужно от студента немного любознательности и адекватность.
Студентам иногда нужно получать где-то первый боевой опыт, а такие компании судя по всему все равно не смогут отличить начинающего специалиста от опытного.
Так что все будут довольны.
Скорее всего вакансия вашего знакомого HR не конкурирует с этой, но вы у него уточните, может им тоже нужен именно такой человек %)
Тег: ирония
Я говорю о поездах, у которых нормальные розетки есть (с рисунком ноутбука рядом с розеткой).
Я как-то в поезде встетил попутчика, который тоже сидел с ноутбуком и уже занимал единственную розетку. Увидев, что я достаю ноутбук, он полез в свою сумку у вытащил небольшой «пилот». И радостно со мной поделился электричеством.
Я, конечно, понимаю, что с маком и айфоном «пилот» не очень сочетается ;)
Но может можно, подобрать что-то компактное, например, «тройник»,
У меня одного есть GPRS в телефоне?
Но теперь у Oracle есть операционная система Solaris, в которой ZFS уже есть.
Так что, «пути Ларри неисповедимы».
Скачиваете какой-нибудь достаточно большой опенсорсный проект, и собираете его на нескольких файловых системах. При этом выключив такие трюки, как компиляция в память (как можно сделать например в gentoo подключив /var/tmp/portage через tmpfs).
Результаты нескольких сборок усредняете и выбираете файловую систему своей мечты.
По моим замерам (сборка большого java проекта), reiserfs, стоящая на зашифрованном разделе, обошла ext3 почти в 2 раза. Но тут конечно все зависит от винта, версии и конфигурации ядра и многих других параметров.
Тест должен именно имитировать предполагаемую деятельность возложенную на файловую систему, потому что в обычной жизни я редко запускаю команду cp в таких ситуациях, чтобы время ее выполнения было для меня критично.
Но, конечно, каждому свое.
Вот например Джонатан Шварц в своем блоге пишет, что это должно быть хорошо.
И если автор ветки не совсем разобрался, что есть FUSE, то не нужно о своей необразованности кричать.
Судя по обзору, отличий от поддержки NTFS, я не особо заметил, нужно ставить специальный пакет. Запускать руками разные команды, чтобы все заработало.
А если пользователи убунты привыкли к тому, что NTFS работает из каробки, то это заслуга мейнтейнеров убунты. А по сути все равно внутри трудится ntfs-3g, который в других дистрибутивах нужно доставлять.
За «тыкание» конечно стыдно (немного). Впредь буду сдерживаться.
А потом уж будешь пытаться свое мнение высказывать.
Но ради Бога, скажите, зачем Вашей маме ZFS?
(Может быть моей тоже нужно, а я и не знаю) :D
Или разработчикам LinkedIn, который написан на Java.
И вообще, только вот грязи не надо.
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.
2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)
3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу
4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>
P.S. За Redmine спасибо — не знал о таком продукте.
Они вроде умеют печатать на 3D-принтере по моделям, причем сделать это можно онлайн. Возможно, Вы сможете как-то улучшить устройство «печатая» его малым тиражом. Заодно будет, что показывать потенциальным дилерам или китайцам. Если у Вас, конечно, еще нет готовой модели.
Сам еще не пробовал что-то там заказывать, если опыт будет удачным отпишите, пожалуйста.
Правильно хранить в вашем случае, чтобы не было проблем с целостностью, это в БД.
Быстро отдавать — прокси в режиме кеширования, например, Squid, ну и есть много других вариантов. Это конечно, если у вас большая нагрузка.(Иначе тут вообще нет проблемы)
Научите сквид кешировать на диск, если памяти в серверах мало :)
Да тут, конечно, есть проблема со временем обновления кеша. Но тут можно эксперементировать с заголовками, например отдавать из базы(приложения) не картинку, а только признак менялась она или нет, на основании заголовка прокси либо перезапросит ее, либо отдаст из кеша.
P.S. Могу соврать, но вроде бы фликр большинство популярных картинок держит в кеширующих проксях причем в памяти.
Но имя то же. Загран. :)
А красиво просит платежный пароль после ввода ерунды :)
Только некрасиво кидает назад, могли бы написать: "спасибо, Ваша проблема будет решена"