Разнос по разным нодам, кажется, называется «шардинг». И шардинг имеет гораздо более широкую применимость в нагруженных проектах, чем партицирование. Мне кажется, что партицирование — оно только для логов и полезно…
Мне кажется, что работодатели (особенно сейчас, когда поток резюме велик в связи с кризисом) обращают больше внимания как раз на резюме, чем на сопроводительное письмо (за исключением случаев, когда резюме идет в самом сопроводительном письме, естественно).
Я сам вообще вначале смотрю присланный код (тут отсеивается 90-95%), потом резюме (еще 75% долой), а уж после этого назначаю собеседование.
> Подавляющее большинство людей не указывают на
> МойКруге контактный телефон
Во-первых, вот как раз повод указать. Он виден только 1-му кругу, так что это безопасно. Во-вторых, никто же не мешает отредактировать в Word полученное резюме и добавить в него те контакты, которые хочется.
> На МойКруге _не принято_ перечислять («палить») на весь
> свет перечень проектов в которых участвовал человек
Почему же «не принято»? Все необходимые поля для этого есть, и очень многие указывают как раз ту информацию, о которой Вы пишете «не принято».
Нам, гикам со стажем, буквы RTF знакомы до боли. Однако для многих не-гиков они — как китайская грамота. (Кстати, при наведении мышкой на ссылку появляется title=«RTF». :-)
Резюме можно редактировать в Word. Люди обычно предпочитают «затачивать» резюме под конкретного работодателя, и наиболее универсально это сделать уже после экспорта.
> Этот ассемблер размером в 14 килобайт становится
> самым быстрым макро-ассемблером существующим на
> рынке с производительностью 1000 строк в минуту
Э-эээ… не ошибка ли тут?
Что такое «производительность ассемблера»? :-)
Если скорость компиляции, то 16 строк в секунду — это как-то совсем мало для 8080 даже.
> InnoDB — самый быстрый из всех известных движков для БД
> основанных на дисках
Можно источник цитатов?
Мои тесты НА ЗАПИСЬ показывают прямо противоположный результат. InnoDB отстает от того же PostgreSQL 8.3 при большом потоке параллельных записей (в том числе — проводимых пачками) в несколько раз. Кроме того, в InnoDB в зачаточном состоянии управление sync-ами, да и просто процессом сброса страниц на диск. Даже Percona Patches тут мало помогает.
Что касается чтения, то, возможно, на чтение по первичному ключу InnoDB и правда несколько быстрее, чем тот же Постгрес (это я не проверял), однако мне кажется, что для подобных целей все же лучше использовать нереляционные СУБД. На сложных запросах (всякая там статистика и т.д.) планировщик MySQL попросту не справляется, тут уже движок таблиц мало влияет.
Точно не те, кто берут взятки. И точно не те, кто дают (т.к. за дачу взятки предусмотрена статья).
Также будет проблема и с контентом: все-таки Интернет — далеко не анонимная среда для подавляющего большинства пользователей, при желании госструктуры могут вычислить каждого (понятно, что есть 0.001% гиков, которые пойдут через китайские прокси и т.д., но писателей в любом ресурсе и так — единицы процентов от читателей, а тут еще и будет дополнительное снижение).
Более того, если посмотреть исходники eAccelerator, то видно, что он, фактически, сериализует опкод в некоторое свое потоковое представление (которое может еще и gzip-ом жать зачем-то, если его попросить), а при запуске скрипта — обратно распаковывает из сериализации во внутренние PHP-структуры. Вот на эту распаковку и тратится куча времени. Так что кэширование там не очень честное (хотя и дает большой прирост, особенно если все файлы склеить в один — почему, пока непонятно).
У меня впечатление, что разговор по телефону (hands-free, естественно) очень слабо мешает вождению автомобиля. Просто водишь обычно полностью «на автомате», тут задействованы какие-то другие участки мозга, больше рефлекторные, — например, те же, что при беге или ходьбе.
У меня бывает, что говоришь с кем-то по телефону и одновременно едешь. А потом, когда кладешь трубку, понимаешь, что уже и приехал, и незаметно время пролетело; при этом даже не можешь дорогу вспомнить, как именно ехал.
А зачем? При таком объеме памяти все часто используемое содержимое диска и так будет в дисковом кэше (т.е. в памяти).
(Кстати, у кого ноутбук, очень удобно его вообще никогда не выключать, а переводить в «спящий режим». В итоге просыпается он за 3-4 секунды, а батарейку тратит очень мало, на неделю обычно хватает в спящем режиме без подзарядки легко. А то я знаю несколько людей, которые честно ноутбук каждый раз выключают и включают по пять раз на дню.)
> и удалил, завтра одумался и восстановил.
Между прочим, по факту — это очень частый случай. ОЧЕНЬ.
Я сам вообще вначале смотрю присланный код (тут отсеивается 90-95%), потом резюме (еще 75% долой), а уж после этого назначаю собеседование.
Впрочем, это все ИМХО.
> МойКруге контактный телефон
Во-первых, вот как раз повод указать. Он виден только 1-му кругу, так что это безопасно. Во-вторых, никто же не мешает отредактировать в Word полученное резюме и добавить в него те контакты, которые хочется.
> На МойКруге _не принято_ перечислять («палить») на весь
> свет перечень проектов в которых участвовал человек
Почему же «не принято»? Все необходимые поля для этого есть, и очень многие указывают как раз ту информацию, о которой Вы пишете «не принято».
> самым быстрым макро-ассемблером существующим на
> рынке с производительностью 1000 строк в минуту
Э-эээ… не ошибка ли тут?
Что такое «производительность ассемблера»? :-)
Если скорость компиляции, то 16 строк в секунду — это как-то совсем мало для 8080 даже.
> основанных на дисках
Можно источник цитатов?
Мои тесты НА ЗАПИСЬ показывают прямо противоположный результат. InnoDB отстает от того же PostgreSQL 8.3 при большом потоке параллельных записей (в том числе — проводимых пачками) в несколько раз. Кроме того, в InnoDB в зачаточном состоянии управление sync-ами, да и просто процессом сброса страниц на диск. Даже Percona Patches тут мало помогает.
Что касается чтения, то, возможно, на чтение по первичному ключу InnoDB и правда несколько быстрее, чем тот же Постгрес (это я не проверял), однако мне кажется, что для подобных целей все же лучше использовать нереляционные СУБД. На сложных запросах (всякая там статистика и т.д.) планировщик MySQL попросту не справляется, тут уже движок таблиц мало влияет.
Точно не те, кто берут взятки. И точно не те, кто дают (т.к. за дачу взятки предусмотрена статья).
Также будет проблема и с контентом: все-таки Интернет — далеко не анонимная среда для подавляющего большинства пользователей, при желании госструктуры могут вычислить каждого (понятно, что есть 0.001% гиков, которые пойдут через китайские прокси и т.д., но писателей в любом ресурсе и так — единицы процентов от читателей, а тут еще и будет дополнительное снижение).
У меня бывает, что говоришь с кем-то по телефону и одновременно едешь. А потом, когда кладешь трубку, понимаешь, что уже и приехал, и незаметно время пролетело; при этом даже не можешь дорогу вспомнить, как именно ехал.
(Кстати, у кого ноутбук, очень удобно его вообще никогда не выключать, а переводить в «спящий режим». В итоге просыпается он за 3-4 секунды, а батарейку тратит очень мало, на неделю обычно хватает в спящем режиме без подзарядки легко. А то я знаю несколько людей, которые честно ноутбук каждый раз выключают и включают по пять раз на дню.)