• А как в действительности ищут программистов кадровые агентства?
    0

    Я про кейс. Сколько вы хотите? 150. Хорошо я предлагаю вам 150 и у нас вилка 100-150. Вы нам очень понравились. Идете?

  • А как в действительности ищут программистов кадровые агентства?
    –1

    Неадекватны могут хорошо работать, если держать их в рамках :) Нельзя же отказываться от продуктивных работников. Адекватов на всех не хватит.

  • А как в действительности ищут программистов кадровые агентства?
    –1

    Ценник — 150. Это деньги. Либо идёшь, либо нет. А мои возможности по оплате вообще это не ваше дело. Нашли 160 у соседа — вперёд к соседу. А мне надо сначала реальной работой доказать, что стоишь больше.

  • А как в действительности ищут программистов кадровые агентства?
    +1

    Это идиотизм просить вилку по зарплате. У вас либо есть цель либо нет. Предположим цель 150. То есть в кампанию где вилка 100-150 вы пойдете, а в 150-200 нет. Они же сволочи меня недооценивают, я точно выше среднего. Среднего чего?? В второй компании у вас по факту лучше перспективы для роста, а в первой потолок. Именно из за неадекватности мышления людей нормальные работадатели НИКОГДА не говорят вилку.

  • Зарплаты в ИТ в первом полугодии 2019 года: по данным калькулятора зарплат «Моего круга»
    +3

    Из анекдота: "ты хоть лотерейный билетик купи". Резюме размести на hh и напиши как мало ты хочешь.

  • Мобильная разработка hh.ru и где она обитает
    +2

    Ты же в две смены пахал, где здесь неправда? Рабочий день 8 часов, а не 24 и твои проблемы.

  • Полный цикл разработки IT продуктов на примере проекта: роли в команде, задачи заказчика, этапы
    0

    Непонятно, чем там занимается бизнес аналитик.

  • Как выбрать СХД, не выстрелив себе в ногу
    +2

    С точки зрения читателя, у меня есть прекрасная статья от Антона и эээ ничего от доктора. Кто из вас мне больше полезен?
    Нет ничего плохого, чтобы спросить у автора о пропусках. Отличный ответ, что это за рамками данного материала. А вот дальнейшее нытье что все плохо, но сам не дам… Это не достойно профессионала.

  • GitHub Sponsors: новый способ внести свой вклад в open source
    +1

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

  • GitHub Sponsors: новый способ внести свой вклад в open source
    +3

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

  • Как начать DevOps трансформацию
    0

    Так и не понял, зачем нужны отдельные люди для этого. Чем там занимаются менеджеры, архитекторы, сами программисты? Они без помощи никак не могут понять, что их задерживает?

  • Собеседование для собеседующих
    0

    Так о чем спор? Я и говорю, что сначала автор потратит 50 дней вместо 50 часов. Если нанимается 7 человек, то 5 окажется так себе. И худшие два из них придут к тебе с предложением переписать фреймворк потому что ты застрял и по другому не умеешь.

  • Собеседование для собеседующих
    0
    Это бизнес и его риски. Надо править — наняли студента за пол батона или подрядчика за много денег. Исправили — отправили всех отдыхать на рынок дальше. Поэтому у понимающих бизнес прибыльный. А мечтатели, минусующие за ответы, которые им не нравятся, получат инфаркт в 35 лет ибо ночь темна и полна ужасов.
    Сейчас рынок кандидатов другой. Падение средней квалификации при росте хотелок. И вопросы у них всегда одинаковые: «Сколько я буду получать? Будете ли вы меня развивать через конференции и командировки? И смогу ли я завтра набрать себе команду из 10 человек?» Там никто не спрашивает про архитектуру, решения и тд.
    Поэтому на рынке и появляется все больше фреймворков и языков упрощающих жизнь, чтобы в любой момент можно было снять обезьяну с дерева, запилить заплатку и не отстрелить себе ногу.
  • Собеседование для собеседующих
    –1

    Это нормально. Разработку могут делать 20 человек, а на поддержку оставят 5. Там нет сил дизайн переделывать. Просто надо догнивать потиху. Жизненный цикл программных продуктов.

  • Собеседование для собеседующих
    –1
    Ожидаемая реакция. Со стороны это часто может казаться правдой. Однако:
    1. Через год молокозавр говорит, что ему надо отредизайнить уже его код. Через 3 приходит новый молокозавр и хаит код предыдущего ничуть не меньше остального легаси.
    2. На самом деле есть вселенские законы и механизмы почему так происходит. Вам никогда не приходило в голову, что еще НИКТО не видел легаси с идеальным дизайном. Неужели все эти годы программировали одни ушлепки? Просто это физика, почему любой код через 3 года превращается в тыкву. И тогда ты осознаешь, что «работает — не трогай» вполне правильный принцип. «Трогаешь — следуй стилю модуля» вторая заповедь достойная каменной скрижали.
  • Собеседование для собеседующих
    +1
    Для большинства компаний это не работает:
    1. Как вы сказали — время. Надо просмотреть много кандидатов. После 2х часов человек обычно уже измотан и все равно не сможет адекватно отвечать.
    2. Вопросы обычно еле помещаются в часовое интервью (идеал по времени). А значит отвечать времени просто нету.
    3. Мы компания которая пишет бинарные деревья. Вот мы и спрашиваем про них. Заодно показываем чем вы будете заниматься. Нам не интересны ваши успехи в искусственном интеллекте(косвенно) и если мы ответим вам, что понятия не имеем как он строится — что это даст нам обоим?
    4. По стандартам в интервью уже есть место для «Может у вас к нам какие-то вопросы?». И возможно экспромт скажет больше, чем подготовка вопросов по гугл.
    5. Интервью обычно оценивается менеджером. Разработчик там только для создания фона из вопросов. Менеджер всегда мечтает о работнике умнее, чем уже есть. Поэтому в игре «мы все знаем лучше вас» нет смысла по определению. Мы вас набираем решить наши проблемы, а не пипками меряться.
    6. Вы в институте пробовали спросить профессора, а он точно знает доказательство теоремы Х? Вы же оба ученые, что же вам не поговорить. Стандартная печаль последних лет — это 23 летний молокозавр, который рассказывает ветеранам, что вчера он прочитал в книжке, что у нас дизайн не по феншую.
    7. Да, здорово, когда люди работают душа в душу. Но так не всегда получается. И вас нанимают делать работу, а не обсуждать интервью Дудя на кухне с коллегами. Вот таск, время и веслы. Может у нас зарплата высокая именно потому, что придется общаться с трудными, глупыми людьми.
    8. В вакансии надо писать список технологий которые требуется. Тогда не придется дополнительно что-то передавать через HR.
  • Роль тимлида в рекрутинге
    +1

    Доклад в целом хороший и правильный. Отражает состояние рынка. Надо подумать о добавлении тепла в вакансию. ))
    Ну и прикольно, как обычные жалобы от HR подаются с заголовком "ты же важный тимлид". Вторая половина больше похожа на "10 ошибок современного тимлида", чем на изучение роли тимлида. Или это роль "Тормоз в найме"? Обидно.))
    Интересно, когда HR агенства додумаются создавать школы тестировщиков и фронтендеров, оформленные как работа в фирме. И на выходе толпа людей с годом опыта в фуллстеке и ТД, вместо пекарей и электриков. У нас в тестировании работает паразитолог. )) Но мы бы его не взяли, если бы кто то не доверил ему мобилки тестировать за год до нас.

  • VR-кухня: чего не видно в шлеме
    0

    Пока одни жалуются, другие уже вовсю продают симулятор кота в Стиме.

  • Резервное копирование на кассеты
    0

    Красиво. А что по деньгам поддержки? За облако надо каждый месяц платить. В DD дисков докупить чтобы основное производство не стало. Порядок интересен. Стало дороже или нет и на сколько.

  • Чертова дюжина для PM: список книг для проджект-менеджеров
    0

    А в книгах что, опыт перестали передавать? Читайте, развивайся. Вот если вы обоснуете почему какую то книгу не стоит читать, вот тогда ваш комментарий засияет смыслом. (Я вот пришел опытные комментарии читать) Без обид, но пост нормальный. Лучше тучи маркетинговых блогов от компаний.

  • Новый вид софта для менеджеров продуктов
    +1

    Plugin portfolio for Jira ?

  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    0
    Статус лишний. «Closed» это и есть продакшн, который вроде ок.
  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    0
    последующие шаги?
    1. Unit test by Developer. (пока не работает — все отдыхают)
    2. Ревью кода предусматривает проверку логики. Если есть продукт-овнер, который это делает быстрее разработчиков — пускайте вперед. Если он один на всех и занят — пускайте разработчиков соседей. Или тим-лида. Чистая логика: если работает не так — какая мне разница красивый ли там код.
    3. Тестировщики максимально в конце. Желательно набор авто-тестов до того как людей дергать. Маленькая команда, тим лид глупый. Сделали мини ревью(формат только) — и пусть тестировщики разбираются работает или нет.

    Нет идеальных процессов. Процесс — либо дает предсказуемый средний результат. Либо закрывает именно ваши проблемы, дырки в скиллах и людях. Документация ниже плинтуса? Раздражает? Введите стадию «Document update» и тд. Делаете код ревью в гите и не бывает такого, что ревью не сделано — можно вообще выкинуть стадию «On review» в Jira.
  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    +1
    Просто попытайтесь проникнуться идеей. Чем больше задач делегированно или автоматизированно — тем больше у руководителя времени вырасти из менеджера- сортировщика в лидера, который думает о развитии продукта и мотивации персонала. Всегда можно найти работника сортировщика, который будет это делать на «достаточно» хорошем уровне и будет рад, что он уже как бы мини-менеджер.
    «У нас принято выставлять задаче due date в момент» — положено-ешь, не положено — не ешь. Не знаешь дату — декомпозируй. Знаешь — пиши, работай.
    Там еще «разработчик присутствует на рабочем месте». Если мержится и работает — зачем вам разработчик? Не работает — выкинули и встретимся по приходу из отпуска.
    Что такое «On Production — Ok» ?? А если не ОК? Где стрелка отката назад? Подозреваю, что востановят прод из бекапа и он всегда будет снова ОК. Значит статус не нужен. Запустился, не упал за 10 мин — Closed. Упадет — новый тикет и root cause. Или ставьте Closed через 2 недели. Вы все равно НЕ ЗНАЕТЕ ок или не ок, пока две недели не пройдет. Зачем лишний статус?
  • Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
    +1
    Слишком много думаете о автоматизации и мало о процессе.
    Сходу:
    — Open это и есть беклог. Не нужен никакой отдельный беклог. Ассайнить тикеты никто не мешает.
    — Лидера уволить и научить разработчиков самим брать тикеты. Когда лидер болеет, работа стоит?
    — декомпозиция есть, а стадии нет? Ничего не создаём сложнее кнопки на экране? Спеки не создаём? Как вообще понять, что разработчик уже декомпозирует, а не тикет просто лежит в беклог? (Я знаю. Важный лидер за спинами ходит.)
    — Сделать Due Date просто обязательным полем и выкинуть скрипт.
  • Как провести неидеальное собеседование тестировщика и почему идеальных не бывает
    0
    С уверенностью скажу за Яндекс.Маркет. И наверняка у вас тоже самое ибо процесс к этому склоняет. Вам кажется, что у вас идет рациональное обсуждение на митинге ПМ-ов, а по факту ресурсы получает тот, кто больше всех ноет. Тихий ПМ — мертвый ПМ.
    Это вопрос уровня… А что делать если надо оттестировать то на что нет спецификации? А что делать если разработчик говорит, что фиксить баг не будет? А что делать, если ПМ говорит, что молодец Вася, хотя ты нашел багов в два раза больше и сделал больше релизов?
    Эти вопросы не должны возникать в нормальных процессах. Смекалка — это как протестировать одним тестом два тест кейса. Или какие выбрать тесты из 2000, так как времени есть только на 400.
    Вы тестируете выживет ли человек в вашей среде. Вместо того, чтобы сесть и один раз подумать, что изменить в процессах, чтобы такого просто не могло быть.
  • Как провести неидеальное собеседование тестировщика и почему идеальных не бывает
    +1

    «Два ПМа приходят к тебе и просят быстро протестировать их проект, который нужно релизить вечером. Что ты будешь делать?»


    Это по моему только в Яндексе толпа ПМ орет друг на друга кому достанется тестеровщик, просит поработать в обед и сделать все быстрее, чем обычно. Вместо того, чтобы выбрать одного ПМ решающего приоритет работ, планировать когда и что и наконец просто нанять тестеровщик сколько положено.
    Ну и обязательно задать вопрос на интервью как выбраться из #опы, которую сами и придумали.

  • Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12
    0
    Именно! Несмотря на то, что у нас 2 копии базы, мы не хотим чтобы записи менялись одновременно на 2х сайтах. И один сайт думал что у Васи 100 руб, а другой 200. Это не особенность приложения. Это бизнес задача (требование). Будь хоть 100 узлов, работать будет как бы один, минус блокировки других узлов. В вашей табличке указано среднее время с учетом удвоения мощности и наличия фаз не требующих блокировок. И так как фазы не требующие блокировок в 6 раз более ресурсоёмкие, то и снижения среднего времени вы получаете за счет них. При этом я уверен что среднее время в пределах одного узла растет.

    Если бы вы тестировали скажем снятие денег в банкомате, то это была бы чистая фаза 2 без примесей, сплошные блокировки. И время только бы росло. У вас слишком удачный тест пример. Если ваш аналитик анализировал характеристики нагрузки и понял, что кластер ускорит (или не сильно замедлит) — это хорошо, молодцы. Если вы просто строили систему disaster recovery и вдруг обнаружили, что времена хорошие — это совсем другое.

    Следует писать не о времени обработки, а о поведении системы в случае выхода из строя одного узла. Zero down time? Как изменится среднее время? Растут ли очереди? Кстати, тогда вы поймете, что нельзя нагружать 2 узла как равные. Иначе при выходе из строя одного узла, второй упадет очень скоро так как ресурсы очереди не бесконечны.
  • Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12
    0
    Слово «критическая» не совсем подходит, ок. Просто скажите мне, почему в второй фазе при соединении кластера время растет в 2 раза, в отличии от других фаз?
  • Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12
    0
    Так, то есть мы имеем 3 фазы. 1я и 3я не требуют кластера и могут выполняться асинхронно. Синхронная 2я фаза увеличивает время в 2 раза даже на расстоянии 0. И весь выигрыш мы получаем только из за того, что время обработки 1й и 3й фазы в пять раз выше критической 2й. И их(1 и 3) можно накопить для обработки позже. Если бы рассматривали «карточный процессинг» то результаты были бы гораздо плачевнее, так как там нет отложенных и асинхронных транзакций.
  • Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12
    0
    >> Обмен данными между CF и подключенными системами организуется по принципу «память-память» (похоже на DMA), при этом процессоры, на которых работают приложения, не задействуются.

    Угу, потому что самих процессоров доступных для приложения стало меньше, так часть занята обслуживанием CF.
  • Производительный отказоустойчивый географически разнесенный кластер, работающий по схеме Active-Active на мейнфрейме IBM zEnterprise EC 12
    0
    Как вы тестировали разные расстояния? У вас что 4 центра с мейнфреймами?
  • IBM представила новый мейнфрейм z13
  • IBM представила новый мейнфрейм z13
    0
    сопроцессор — это железно тот же самый процессор, просто залит другой микрокод.
  • Подборка настолок про космос и обзор их механик
    +1
    Если играть без поля и брать карты событий — это и будет бесконечный космос. Наверно правильнее спросить:
    1. Хочу ли я видеть сколько уже исследовал?
    2. Хочу ли я возвращаться в старые места? И знать точно где они и за сколько доберусь?
    3. Хочу ли встречаться с другими игроками по желанию а не случайно.?

    Окей. Можно делать галактику кругами. На втором кольце отдельные гексы и плюшки. На 3 жесть. На 4 непролазные астероиды а то стол закончится.
  • Подборка настолок про космос и обзор их механик
    0
    Посмотрел. Дальнобойщики вообще не о том. Касательно мира — давайте честно. Все миры были на один лад. Значит можно летать меж двух систем и карты событий будут строить якобы новый мир. Поле из гексов условно позволяет лететь куда угодно пока в колоде гексы не закончатся. На гексе можно десяток планет бахнуть и на каждой событие брать. В элите никто не обещал что если залететь далеко будут плюшки. Это был самообман. Мол там я точно квест найду. А по сути это рандом. И бесконечным мир не был. Скажем 50 гексов по 10 планет — 500 мест. Хоть в линию хоть по спирали. Должно хватить.
  • Подборка настолок про космос и обзор их механик
    0
    А в старкрафте больше 3х зданий. Это же настолка. Надо чем то жертвовать. Напечатать сотню гексов не проблема. Но все же хотят доиграть до конца хотя бы часа за 4. Какие конкретно чувства хочется воскресить?
  • Подборка настолок про космос и обзор их механик
    0
    Не понимаю в чем проблема создания Элиты? Открывай карту гексами. При входе в гекс карта события — полиция, пираты, торговцы. Хочешь воюй на кубиках, хочешь беги. Выиграл — открыл карту с ценами на планете. Вот и вся Элита ))
  • 50 лет мэйнфреймам
    0
    Современные мейнфреймы в Питере: тыц
  • 50 лет мэйнфреймам
    0
    Спасибо.