Алексей Блышко

Если есть сервер для тестирования - можно начать с логгирования всех запросов на продакшен и скармливания их тест-серверу уже с хдебагом в ручном или автоматическом режиме - в зависимости от умений и предпочтений. Тестовый сервер вполне можно настроить точь-в-точь, как продакшн - благо есть всего три составляющие, которые покрывают 99% повторяемости результатов ошибок. Это окружение, код и данные.

А вообще полный профайлинг поднимает нагрузку всего лишь на порядок. Может быть и продакшена хватит для этой задачи, ежели она разовая и надо срочно. Но да. Некошерно и вообще плохая практика.

Чисто по логике построения интерфейсов, безотносительно к используемым технологиям, это неправильно - сообщать об успехе до того, как успех собственно произошел. На мой взгляд разумнее всего принимать сообщение от пользователя, валидировать его и ставить в отдельную очередь исполнения с тем-же идентификатором. После этого этапа отправлять сообщение пользователю, мол все ок, обрабатывается. Или же сообщение об ошибке. В идеале же стоит еще и прогнозировать время выполнения задачи и сообщать об этом пользователю. Когда же сообщение отправлено, всплывающим ли окошком ли, прямо в этой форме ли, об этом стоит сообщить отдельно... Если оно надо, конечно.

Как насчет того, чтобы сначала заполнить блок, а потом его отобразить?
Или же перед отображением пихать в него какую-нибуть гифку "лоадинг"?

Вариант с sshfs, как показывает практика, самый удобный - править файлы прямо на VPS, подмонтировав её в систему, чтобы весь софт работал с ней как с локальными файлами. Единственный минус - очень долгий поиск перебором по всем файлам.

А дальше уже можно сливать с VPS изменения любыми удобными способами - хоть дропбокс, хоть rsync, хоть dvcs.

50 на 50. На сайте производителя в спецификации ноутбука должна быть указана характеристика "максимальное количество памяти". Эта цифра зависит от материнской платы, так что выше головы не прыгнуть.

У меня есть серьезное подозрение, что все идет по плану - расширение аудитории, классификация и разнесение её по проектам, после чего можно будет делать таргетированную рекламу.

Судя по всему на тостере вполне можно будет рекламировать яндекс-браузер со встроенным маилру поиском. А может быть даже ускорители интернета.

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

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

Работа с почтовыми функциями зачастую нетривиальна из-за различий в настройках хостеров и их борьбе со спамом.

Насколько я помню - самая частая проблема заключается в адресе отправителя. Он должен совпадать с аккаунтом, доменом или чем-то там еще у хостера.

Но есть и другие варианты. Вот небольшой чеклист:
- Не знаю особенности жумлы, но хочу уточнить - переменные $mail и $mailer в хелпере откуда берутся?
- В лог ошибок что-нибудь пишется?
- Включен ли вывод ошибок? E_ALL?

Подписался на участие. Это может быть забавным.

В общем случае только поиск человека и заявление от него на передачу домена.
В частном случае можно попробовать через суд. Но на каком основании — это сложный вопрос. Обычно отсуждают на основании имеющейся торговой марки.

Получить данные по владельцу домена после введения 152ФЗ стало достаточно сложно. Нужно или как-то договриваться с регистратором-хостером или через официальный запрос от правомочных организаций.

Зачастую многие регистраторы предоставляют приватный ящик, по которому можно попробовать связаться с владельцем домена — с него делается пересылка на адрес, указанный при регистрации домена.

Я все присматриваюсь к Аэрону.
www.4geeks.ru/2009/09/aeron_chair/

Но стоимость великовата.

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

А гуглодоксы, насколько я помню, просто отлавливают события нажатий на клавиши клавиатуры, подставляя их жаваскриптом в то место, где установлен курсор. Курсор, кстати там тоже рисуется вручную — он не нативный.

Сомневаюсь что тут что-то может помочь кроме личного опыта.
Если он, как специалист, достаточно грамотный, можно сделать так чтобы с его кодом никто не пересекался.
Обычно это означает, что он будет делать периферию. Делать и переделывать, если понадобится. При этом давать иногда ему делать фиксы ядра, написанным в хорошем стиле. Чтобы чувствовал разницу.
При этом с увольнением я бы не спешил. Зачастую специалист с таким подходом делает работу на совесть. Сложно в поддержке и развитии, но работает. Возможно даже сразу :) Если в команде нужен такой человек — его можно использовать.
Иначе — попробовать отыскать следующего. Для менеджера это будет лишний повод попрактиковаться в подборе команды :)

mercurial как DCVS мне показался проще к понимаю.

Ну или в худшем случае это решается организационными способами.
При разработки для каждой участвующей стороны создается своя копия файла/сайта/проекта. И они работают только с ними.

Специально обученный человек™ ака менеджер проекта ведет основную ветку и принимает решение о выкладываении проекта на продакшн. Также можно вменить ему в обязанность вести эти ветки — создает, удаляет, сливать изменения. Конечно только в том случае, если кто-то из пользователей этого не умеет делать, что обычно актуально в случае сторонних сотрудников.

Если я скажу, что надо заново отформатировать диск до того состояния, в котором он был ранее, наверно это ничем не поможет…