Вы сейчас думаете о том как этом можно применить к общему случаю. Я понимаю, что это с одной стороны правильно, но задача стоит другая — нужно оптимизировать конкретный запрос. Поэтому все рассуждения поверх этого оторваны от задачи и к решению не имеют отношения. Главное — идея понятна (надеюсь) и в этом направлении есть возможность экспериментировать.
По 1й ситуации согласен, а вот по 2й и 3й не очень.
2. 99% — это не соответствует действительности, потому как не подкреплено фактами. Договориться между подразделениями можно и часто у адкватных и опытных руководителей это получается практически само собой, потому что они понимают цели компании, задачи каждого подразделения и понимают кому что нужнее в каждый момент времени (или могут это рассказать/осознать за приемлимый промежуток времени, на то они и руководители). Конечно, бывают разные руководители, но если это выростает в конфликт, то оба руководителя делают ошибку, потому что тратят время на препирания вместо поиска второго специалиста, который подойдет второму подразделению. Этот специалист же не один на рынке труда.
3. Служба персонала не может решать такие вопросы, потому что не обладает достаточными знаниями о ситуациях внутри подразделениях. Например, по Вашему примеру, если 2-е из одного подразделения занимаются корпоративным сайтом, а те 10-ть из другого пишут операционную систему нового поколения, что является стратегической задачей компании, которая была поставлена советом директоров, то количественный показатель для распределения ресурсов не подходит.
Думается, что проводить встречу нужно всем вместе, с представителями обоих подразделений, потому как в случае отказа по первой позиции соискатель пойдет на вторую уже не с таким энтузиазмом, как на первую, да и ценить свое и его время тоже нужно.
Если он подходит обоим подразделениям, то, вероятно, возможно найти общего руководителя обоих подразделений и проконсультироваться с ним. Если общего руководителя нет (или он вне досигаемости для решения таких вопросов), то представители заинтересованных сторон могут сравнить свои текущие положения проектов, где ситуация напряженней (горят сроки, стратегический для всего холдинга проект или еще что-то), тому подразделению и следует отдать предпочтение.
Странный был у вас пээм… его имеют за длинные периоды разработки, решение ему снизу пришло, а он потом повышение получил. Надеюсь ему хотя бы стыдно было.
А вообще, каждый должен заниматься своим делом и все должны делать общее дело. И если где-то не так и изменить это не получается — надо просто идти дальше. Имхо.
Конечно, все необходимые классы присутствуют в виде обычных php-классов, и использование модуля в общем-то не обязательно, если у проекта нет проблем с нагрузкой.
А у меня летает просто (дохлый EeePC 1000H, Ubuntu 10.4, Chrome stable). И картинка очень удобная, даже с использованием тачпада. Не уверен насчет айпада, но думаю и там тоже будет хорошо и удобно смотреться.
Большая картинка сделает уродливые скроллы, с помощью которой только и будет возможна горизонтальная навигация. А так можно колесом мышки как гугл.мапс покрутить (или двойной клик = увеличение) и все что нужно увидеть.
Это все взгляд пользователя, поскольку специалистом по юзабилити не являюсь.
В любом случае нужен финансовый институт, который будет аккумулировать средства, списанные с платежных карт держателей. Вряд ли Мастеркард сам этим будет заниматься.
Судя по Ваши постам вы явно отлично знаете Супер Сложные Языки аля PHP и Ruby, которые не в состоянии осилить ни один смертный разработчик… Прошу прощения за сарказм, не сдержался.
Вопрос-то не в том, что те, кто не знает таких подробностей — недочеловеки и им надо закрыть доступ к написанию кода, пока не выучат. А в том, что чем больше нюансов должен держать в голове программист — тем тяжелее ему делать свое дело и, следовательно, больше вероятность чего-то забыть и неправильно сделать. Имхо гораздо лучше, если разработчик будет держать в голове нюансы, связанные с задачей, которую ему надо сделать, а не с премудностями языка, который он использует.
2. 99% — это не соответствует действительности, потому как не подкреплено фактами. Договориться между подразделениями можно и часто у адкватных и опытных руководителей это получается практически само собой, потому что они понимают цели компании, задачи каждого подразделения и понимают кому что нужнее в каждый момент времени (или могут это рассказать/осознать за приемлимый промежуток времени, на то они и руководители). Конечно, бывают разные руководители, но если это выростает в конфликт, то оба руководителя делают ошибку, потому что тратят время на препирания вместо поиска второго специалиста, который подойдет второму подразделению. Этот специалист же не один на рынке труда.
3. Служба персонала не может решать такие вопросы, потому что не обладает достаточными знаниями о ситуациях внутри подразделениях. Например, по Вашему примеру, если 2-е из одного подразделения занимаются корпоративным сайтом, а те 10-ть из другого пишут операционную систему нового поколения, что является стратегической задачей компании, которая была поставлена советом директоров, то количественный показатель для распределения ресурсов не подходит.
Если он подходит обоим подразделениям, то, вероятно, возможно найти общего руководителя обоих подразделений и проконсультироваться с ним. Если общего руководителя нет (или он вне досигаемости для решения таких вопросов), то представители заинтересованных сторон могут сравнить свои текущие положения проектов, где ситуация напряженней (горят сроки, стратегический для всего холдинга проект или еще что-то), тому подразделению и следует отдать предпочтение.
А вообще, каждый должен заниматься своим делом и все должны делать общее дело. И если где-то не так и изменить это не получается — надо просто идти дальше. Имхо.
По бенчмаркам — как будет время, сделаю, очень интересный момент.
Большая картинка сделает уродливые скроллы, с помощью которой только и будет возможна горизонтальная навигация. А так можно колесом мышки как гугл.мапс покрутить (или двойной клик = увеличение) и все что нужно увидеть.
Это все взгляд пользователя, поскольку специалистом по юзабилити не являюсь.
Есть. И у визы и мастера есть на то специальные требования.
Вопрос-то не в том, что те, кто не знает таких подробностей — недочеловеки и им надо закрыть доступ к написанию кода, пока не выучат. А в том, что чем больше нюансов должен держать в голове программист — тем тяжелее ему делать свое дело и, следовательно, больше вероятность чего-то забыть и неправильно сделать. Имхо гораздо лучше, если разработчик будет держать в голове нюансы, связанные с задачей, которую ему надо сделать, а не с премудностями языка, который он использует.