Задать вопрос
  • Как решить проблему с ЧПУ, когда url не обновляется?

    reaferon
    @reaferon
    Подозреваю, что у вас ссылки вида
    <a href="catalog/armchairs/0/2">link</a>
    Поставьте слэш:
    <a href="/catalog/armchairs/0/2">link</a>
    Ответ написан
    1 комментарий
  • Эмуляция отказа питания/диска/сети в VMWare ESXI5?

    ntkt
    @ntkt
    Потомственный рыцарь клавиатуры и паяльника
    Тесты на гипервизоре Вам практически ничего не дадут, поскольку реальные нештатные ситуации во всех трех случаях могут породить уникальные и чисто аппаратные глюки.

    Максимум, что вообще можно так отловить, это программные ошибки в юзермодном софте: косяки в скриптах, связанные с незатертыми lock/pid файлами от демонов (при сбое по питанию) и т.д.

    Но если очень хочется, то почему бы и нет:
    1. Отказ питания эмулируется очень просто: если виртуалка без VMWare Tools, то команда выключения для нее эквивалентна отключению машины.
    2. По отказу сети: в консоли ESXi просто заходим в свойства виртуалки и отключаем сетевой адаптер.
    3. Отказ диска эмулировать бессмысленно совсем, т.к. отказ с повреждением данных на диске — это одно, а если диск молча умер, когда его никто не тревожил — это практически эквивалентно ситуации №1.
    Ответ написан
    1 комментарий
  • Эмуляция отказа питания/диска/сети в VMWare ESXI5?

    @0000168
    Как я понимаю надо так:
    1. питание: пускаете хост в рестарт
    2. диск: я делаю unmount диска / тома на стороне схд
    3. сеть: полагаю достаточно «испортить» настройки NICов/SW как на ESX так и на сетевом оборудовании (если оборудование поддерживает)

    P.S. по всем 3 пунктам можно банально «бросить сапоги на пульт управления» вытащить питание, открутить диск или перерезать сетевой провод, но это не спортивно
    Ответ написан
    Комментировать
  • За что разработчик может уважать менеджера?

    80x86
    @80x86
    За то, что это — образ жизни.

    Я попробую изложить тут свой опыт. Думаю, получится ОЧЕНЬ субъективно. Увы.

    Последние три года мне приходится быть этаким Jack Of All Trades (к счастью, без продолжения “master of none“). Я начальник отдела автоматизации учебного процесса довольно большого, но весьма вялого до этой самой автоматизации ВУЗа. Жизнь сложилась так, что кроме этого я занимаюсь веб-разработкой (скорее фрилансом) и координацией нескольких полузакрытых проектов, выросших из аутсорса.

    Соответственно, приходится заниматься административной работой, организационно-координационной и непосредственно разработческой. И рисовать, верстать, копирайтить, тестировать, составлять матмодели, заниматься статистической обработкой и немного паять.

    Это, так сказать, для более глубокого понимания того, почему будет много субъективизма с претензией на объективность.

    До этого, примерно лет пять назад, когда я был чистым разработчиком, на работу менеджеров проекта/команды (да чего уж кривить душой — и на работу любого административного работника) смотрел с презрением, граничащим с этаким public riot. Скорее всего, мне просто не попадалось действительно хороших ПМов, которые бы умели поставить рабочий процесс так, чтобы разработчик понял, что о нём заботятся.

    Зачастую у меня были какие-нибудь вопросы, с которыми я шёл не к менеджеру проекта (к начальнику, директору или ещё кому-нибудь, кто так или иначе вёл проект), а к соседу-разработчику. Потом я сам с собой согласился, что убитое на поиск решения в интернете время многократно убивается пользой от более широкого фронта, открывающегося при обследовании проблемы и перестал ходить к коллегам за советами. Тем болеее, что в результате я и сам всё делал хорошо.

    Ещё мне дико не нравилось решать задачу некрасиво, причём это часто выражалось в затягивании сроков. Если мне начальник говорил:

    — Надо срочно сдать! Хватит тянуть резину, что у тебя там, почему нельзя сделать быстрее?

    , то я ему начинал рассказывать про то, что надо сделать так-то и так-то, соптимизировать выборки, дописать какие-то абстракции для возможного будущего использования и возможности расширения. При этом я откровенно не мог понять, зачем ему нужно кривое и косое решение, которое (вот если его ещё чуть-чуть попилить) скоро станет очень хорошим и крутым.

    Я убивал на это допиливание время, в результате получал аллергию на код и переставал получать удовольствие от жизни и проекта. В итоге делал «уже лишь бы работало», но при этом затягивая сроки и получая очередной приступ язвенной болезни.

    Потом было много разных событий, которые во мне окончательно убили веру в то, что менеджер — это друг, товарищ и практически брат. Эти люди не видели проблем коллектива, не хотели для достижения результата жертвовать своими ресурсами или вообще абстрагировались от проблем за мифическими скрамами, процессами, UML и прочей серебряной атрибутикой современного IT.

    А потом я стал начальником.

    Начальником болота, где не слышали про VCS, например. Вообще. И про проектирование.

    После достаточно серьёзного погружения в проблематику и понимания круга задач я захотел опустить руки, потому что одному тут было не справиться. Потихоньку начал набирать коллектив, при этом в параллель поднимая всю инфраструктуру для разработки и собирая фреймворк для построения приложений. Пока коллектив втягивался в работу, шла куча всяких посторонних дел типа административных войн, в которых приходилось принимать участие; была несовместимость людей в коллективе и было реальное мордобитие; было несогласие по ключевым вопросам проектирования архитектуры. Всё это приходилось разруливать, при этом стараясь попадать в сроки.

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

    С тех пор многое поменялось в голове: я научился жертвовать перфекционизмом в пользу выполнения поставленной задачи; научился делегировать работу; научился избавлять разработчиков от головной боли и смятений в выборе способа решения задач, выполняя роль своеобразной бритвы Оккама; научился… да научился много чему.

    Теперь я понимаю, что основная работа менеджера — это, в первую очередь, аргументированное и действенное избавление разработчика (исполнителя, подрядчика и т.д.) от психологической «головной боли», которая вызывается тем, что тот выполняет несвойственную ему работу. Собственно, за это разработчик и может уважать менеджера, как человека, профессионально выполняющего свою работу.

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

    Слава святому фон Нейману, такие люди, оказывается, есть и их достаточно много. В сравнении себя со многими из них я понимаю, что мне есть, куда стремиться. И это потихоньку топит лёд моего внутреннего разработчика, который потихоньку учится уважать менеджеров.
    Ответ написан
    Комментировать