Зачем кого-то заставлять? Надо из группы отобрать несколько человек и на них сосредоточить все усилия, а остальным поставить оценки и не тратить время. А вот с избранными работать на полную катушку.
Страдает ясность и читаемость программ. Очень сильно, причём. О замыканиях, по хорошему, знают только те кто прошёл школу Perl, а таких нынче нету. Когда я пишу callback на JS — всё время себя контролирую на предмет использования замыканий, ведь это, по сути, глобальные переменные. И утечки памяти, кстати. Я, например, не знаю, что будет с памятью:
function a1(a){
return function(b){return a+b;}
}
var s='1';
alert('Check memory 1!');
for(i=0; i<20; i++)s=s+s;
alert(s.length);
Ну почему никто просто документацию не хочет читать? Набла, признанная безграмотной после многостраничного обсуждения? А всего-то надо было почитать инструкцию. Апофеоз программирования…
Если бы я встретил как работодатель программиста, который такие функции пишет — этот программист пошёл бы искать другую работу. Почему понятно, надеюсь?
А читать надо нетскейповскую документацию — там всё прозрачно описано.
Отличная статья. Показывает, что PHP'шники часто изучают язык по примерам, и испытывают лёгкий шок, когда обнаруживают неизвестные им конструкции. После этого пишут статьи.
Зато теперь говнокодеры знают про include и break — ведь они всё равно не будут ни мануалов читать, ни книг. Всё польза.
Есть ли в тэгах смысл? Смотрим более-менее любое сообщение на хабре — тэги проставлены, половина тэгов — уникальные. Зачем они нужны, только засоряют. А вот тэги, создаваемые автоматическими классификаторами, были бы более полезны.
На гигабитной сети скорость миграции — 40 секунд на гигабайт (25 мегабайт в секунду). Три гигабайта — это стандартный таймаут, как получается что пакеты не теряются?
«статей у нас 50000, а тэгов 10000» — это как это так? И проблем с построением облака тэгов нет? Естественно нет, если при таком количестве тэгов смысла в облаке просто нет и можно делать его статическим. Надо ввести модерирование и слияние тэгов, тогда их количество сократится на порядок, и проблемы, которые так горячо обсуждаются, исчезнут.
OpenVZ тоже позволяет, есть только одно НО: это в пределах одного адресного пространства.
И есть неожиданная засада — скопировать несколько гигабайтов можно быстро только в пределах одного датацентра, так что живая миграция — это средство для кластеров серверов, не для переездов в другой ДЦ.
Если пользоваться только пакетными менеджерами, то настройка софта сервера быстро делается. Для дебиана, например, достаточно сохранить список используемых репозиториев и список пакетов, возвращаемый dpkg --get-selections. Проблемы начинаются, когда используются машины разных архитектур, например i386 и AMD64, поэтому стоит заранее ориентироваться только на одну архитектуру.
Я бы переезд запланировал ещё при создании системы. А именно все сервисы системы держал бы в контейнерах virtuozzo или openvz. Тогда переезд заключается в копировании контейнера на новое место, тестирование его, остановке старой копии, уточнение копии rsync'ом, замена на старой копии конфигурации nginx, поднятие конрейнера на новом месте, с новыми ip адресами, и запуск старого контейнера, теперь уже только ради одного проксирующего nginx. Перерыв в работе определяется размером модифицированных файлов, например базы данных, и в худшем случае определяется временем сравнения контрольных сумм всех файлов на обоих машинах — то что делает rsync, и что не всегда имеет смысл делать. Плюсы — отсутствие неожиданностей на новом железе, ненужность конфигурирования софта.
Получилось красиво, но вот в чём проблема - понравится ли разработчикам модулей, что интерфейс их настройки придётся проектировать, вместо нынешнего последовательного укладывания блоков один за другим? В конце концов, типы материалов не каждый дено надо редактировать, разве что редактор документов изменить - но и там особых проблем нет, чтобы создавать лишние проблемы. А если деньги есть, то и сейчас можно любой интерфейс сделать.
CakePHP заточен под mysql, и на другую СУБД перейти толково просто не получится. Половина возможностей - для компенсации отсутствия ссылочной целостности и триггеров, этакая надстройка над mysql.
Очень просто. Если я приду в магазин с плохо организованным интерфейсом, я даже на цены смотреть не стану, пойду в другой. Это не теория, это практика - выбор есть.
function a1(a){
return function(b){return a+b;}
}
var s='1';
alert('Check memory 1!');
for(i=0; i<20; i++)s=s+s;
alert(s.length);
for(i=0; i<10; i++){
a1(s)(s);
}
alert('Check memory 2!');
s=''
alert(s.length);
alert('Check memory 3!');
Программа должна быть прозрачной кристально и не быть рассчитанной на очень хорошего специалиста — таких просто нет в достаточном количестве.
return function(b){return a+b;}
}
alert(a1(2)(3));
А читать надо нетскейповскую документацию — там всё прозрачно описано.
Зато теперь говнокодеры знают про include и break — ведь они всё равно не будут ни мануалов читать, ни книг. Всё польза.
200.000 тэгов… Теряется смысл тэга.
И есть неожиданная засада — скопировать несколько гигабайтов можно быстро только в пределах одного датацентра, так что живая миграция — это средство для кластеров серверов, не для переездов в другой ДЦ.