• Kubernetes Operator на Python без фреймворков и SDK
    +1

    Хорошая статья, спасибо. Приятно видеть что тема операторов стремительно набирает обороты — скоро будет k8s-оркестрация всего и вся, а не только контейнеров.


    Немного отсутствует момент, где вызывается handle(specs) — чтоб понять как и что туда передаётся, и как он реагирует на изменения этих specs.


    А если вам потребуется писать более сложные операторы, не обрастая при этом инфраструкторной логикой, а только лишь логикой предметной области, то рекомендую взглянуть на Kopf: https://github.com/zalando-incubator/kopf/ (документация: https://kopf.readthedocs.io/)


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


    Код задачи из примера выглядел бы как-то так:


    import kopf
    import kubernetes
    
    rules = {}
    
    @kopf.on.resume('flant.com', 'v1', 'copyrators')
    @kopf.on.create('flant.com', 'v1', 'copyrators')
    @kopf.on.update('flant.com', 'v1', 'copyrators')
    def new_rule(name, spec, **kwargs):
        rules[name] = spec
        for namespace in _get_all_namespaces():
            _ensure(namespace, spec)
    
    @kopf.on.delete('flant.com', 'v1', 'copyrators')
    def no_more_rule(name, spec, **kwargs):
        for namespace in _get_all_namespaces():
            _purge(namespace, spec)
        if name in rules:
            del rules[name]
    
    @kopf.on.resume('', 'v1', 'namespaces')
    @kopf.on.create('', 'v1', 'namespaces')
    def ns_in_sight(name, **kwargs):
        for rule in rules:
            _ensure(name, rule)
    
    def _ensure(namespace, rule_spec):
        pass  # создаём secrets/configmaps
    
    def _purge(namespace, rule_spec):
        pass  # удаляем secrets/configmaps
    
    def _get_all_namespaces():
        api = kubernetes.client.CoreV1Api()
        return [ns.metadata.name for ns in api.list_namespace()]

    Не уверен, что я уловил всю логику, конечно. И не тестировал, конечно. Но примерно так выглядел бы оператор, который и на rules, и на namespaces реагирует.


    Фреймворк, конечно, пока в версии 0.x. Но уже почти устаканился.

  • Так ли легко переехать в Германию? Моя личная статистика поиска работы
    0
    Везде на западе з/п пишется gross per year (брутто в год). Потому что налоги+страховки варьируются очень индивидуально в зависимости от уровня совокупного дохода семьи, возраста, женатости, колва детей, состояния здоровья, региона проживания, вероисповедания, и чёрт знает чего ещё — в итоге могут варьироваться от 20% о 45% (для разработчиков скорее в районе 35-42%).
  • Так ли легко переехать в Германию? Моя личная статистика поиска работы
    +1
    Средняя зарплата в Берлине по состоянию на начало 2017 — 60-65k (seniors), 45-50k (middles) — по данным опроса группы русскоязычных айтишников. Смотрите картинку:

    image



    В Мюнхене — 60-70k и 55-65k соответственно.

    На текущий момент данных нет, но, судя по находимым офферам, в Берлине senior'ы уже получают 70-75k. Возможно, это штучные примеры, а не массовый тренд — ждём опроса в конце года.

    На блюкарту в 2017 минимальный порог 51k вообще, и 39k для «особо востребованных профессий», в т.ч. айтишников всех мастей.
  • Самые востребованные языки программирования 2016
    +1
    Рост вакансий по языкам сам по себе любопытен, но, увы, не отражает изменения баланса между языками.

    Не могли бы вы посчитать не рост вакансий вообще, а либо рост/падение доли вакансий каждого языка в общей массе (например, php = было 5404/sum(2015), стало 9707/sum(2016), прирост = …), либо прирост каждго языка относительно прироста рынка в целом (например, php +79%, но все языки вместе взятые +50%, а, значит, php лишь +29%)?
  • Чем заменить ELK для просмотра логов?
    +1
    А почему не Graylog (который тоже на ElasticSearch, но без Kibana, и специально для логов)? Чем не подошёл?
  • Сброс PHP-кеша через SQL-запрос или из пушки по воробьям
    0
    Готов предположить, что в БД есть логика (триггеры, процедуры), и вот там надо сбрасывать кеш. Была подобная ситуация, только с memcached из Oracle PL/SQL. Вполне себе реальная задача, а не just for fun.

    Косяк, конечно, в том, что создатель кеша (PHP-что-то-там) и инвалидатор кеша (PostgreSQL) находятся в разных слоях архитектуры, и тем размазывают ответственность за кеш (ну или данные — как посмотреть). Но это исправлять дольше и дороже.
  • Как мы писали систему защиты от скликивания
    0
    А можно ли вашу систему прикрутить для защиты трафика на кастомной баннерке? То есть не гуглы/яндексы, а вот собственная/сторонняя баннерокрутилка, но пропускать всё через вас.
  • Опыт выхода на «занятый» рынок региональных порталов о недвижимости
    0
    Монетизация на чём строится? Только реклама? Или сервисы? В каких пропорциях? Основная проблема почти всех сайтов недвижимости — это то, что их трудно монетизировать; поэтому бесплатные альтруисты быстро умирают. Каковы ваши планы?
  • Геймификация в области оплаты труда
    0
    А разве это заслуга разработчика что проект принёс много денег? Вот что вовремя запущен — то да. А деньги — это заслуга продавцов и всех из направления BezDev'а.

    Насчёт накосячил — разработчик может не согласиться что это его вина. И тогда всё скатывается к авторитаризму, где где решения принимаются лично руководителем, и теряется прозрачность и предсказуемость системы.
  • Геймификация в области оплаты труда
    0
    Очень интересная статья. Большое спасибо автору за ее публикацию. Тема численной оценки труда разработчиков меня сейчас интересует особенно сильно, и чужой опыт очень полезен. Есть ряд вопросов, которые хотел бы уточнить:

    Как вы добиваетесь и проверяете достоверность отчетов по времени? Кто и как расставляет баллы сложности на задания/проекты? Насколько справедливой коллектив считает эту оценку? Сколько времени занимает процедура оценки задач? А сколько — подсчета итогов?

    И самое главное: как масштабируется эта система при росте команды до 3-4-5 команд? Все предыдущие вопросы интересуют в большей степени именно в этом ключе.
  • Если бы плотников нанимали так же, как программистов
    0
    Ну, раз на порше кайене, то тем более стартапер — известно ж что все стартаперы мужского пола мечтают о красной спортивной машине, желательно с открытым верхом :-)

    Среди программистов тоже есть стартаперы. Полно стартаперов. Но в собеседованиях такого рода они не участвуют. Это удел рядовых наёмников, то есть «плотников-only» «программистов-only».

    Предлагаю аналогии, коль уж они выстроены, проводить хотя бы в сопоставимых уровнях компетенции и режимах работы.

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

    Во-вторых, это по слухам, и гипотетически. Я вот тоже слышал что некоторые программисты (ну, точнее софтварные инженеры) в некоторых компаниях делают по 400-500тр/мес. Но это уникумы или по ситуации, или по талантам. Рынок уникумов — тоже совсем другой рынок с другой шкалой.
  • Если бы плотников нанимали так же, как программистов
    +1
    Это среднестатистически для хорошего плотняка/столяра, или это какой-то конкретный индивид имеется в виду?
  • Если бы плотников нанимали так же, как программистов
    0
    Трёшку чего, пардон?
  • Если бы плотников нанимали так же, как программистов
    +2
    Junior'ы — особая тема. Обычно в случае джуниора пытаешься нащупать дно, так сказать — оттуда и вопросы. Ну и плюс заложенную в нём потенциальную энергию. А вот со средними и гуру — уже проверяешь соответствие специализации своим требованиям и высоту полёта на примере уже полученного опыта.
  • Если бы плотников нанимали так же, как программистов
    –2
    Разве? Давайте обсудим. То есть хорошие плотники (скажем, 7+ лет стажа) в Москве получают 150-200 тр/мес, при этом не являясь предпринимателями или менеджерами или «родственниками» или кем-то иным кроме плотников? Потому что такого плотника, если он столько получает, будут собеседовать вот ровно как программистов.
  • Если бы плотников нанимали так же, как программистов
    –12
    Если бы плотники получали столько же, сколько и программисты, то и нанимали их бы как программистов. Но плотники не получают столько же, сколько и программисты, поэтому нанимают их таки попроще.
  • Judy-массивы в PHP
    +2
    В смысле, полный перебор логинов по базе не является ошибкой? Он не был упомянут.
  • Judy-массивы в PHP
    +3
    Ну, если что, то и цикл не for-in, а foreach-as.
    Да и не foreach-as, а что-то там про while(mysql_fetch() !== null).
    Ну как вспомнил, так вспомнил. Это всё дурное влияние питона :)

    А если кто-то прочитает мой код и не поймёт шутки, и будет делать так же — ну, ссзб :)

    И вообще, это был намёк, что выборка юзеров не является задачей. Это способ решения какой-то задачи, о которой изначально и было спрошено. Но намёк был слишком тонким, никто не понял. Со мной такое бывает.
  • Judy-массивы в PHP
    +4
    $users = mysql_query('select * from badoo.users');
    for ($user in $users) {
        if ($user['login'] == $login && $user['password'] == md5($password)) {
          //...
        }
    }
    


    так?
  • Leap Motion. Распаковка и небольшой обзор
    +11
    Не понял про жалобы на отсутствующий рынок и приложения. Мне казалось что они сначала планировали рассылать экземпляры для разработчиков, чтобы они начали писать приложения. Надпись «dev board» как бы намекает. А на в массы оно пойдёт позже, когда разработчики напишут приложений. Нет?
  • Почему мы (всё ещё) верим в удалённую работу
    0
    Нормально отношусь. Я не зря указал причину моего отрицательного отношения.

    PS: И сам иногда для отвлечения мозга занимаюсь всякими кодерскими штучками. Такая вот форма релаксации.
  • Почему мы (всё ещё) верим в удалённую работу
    +1
    Диферсификация работодателей — это как раз и есть фриланс. Свои риски, свои способы их преодоления. Работая в офисе люди обычно не задумываются о диверсификации, т.к. это другая поляна, другие правила и модели поведения. Спорить о freelance vs in-office не будем, это очень глубокая нора :)

    А вот удалённая работа на full-time — это, как я и писал где-то тут рядом, нечно совсем новое. Это не фриланс. Это всё-таки ближе к офисной работе. Ну разве что способ доставки себя до рабочего места отличается (метрополитен vs telecommuting). Соответственно, ценности и модели работы тут скорее как у офисной работы, без «диверсификации работодателей».

    Впрочем, свою полянку каждый волен выбирать сам. Главное чтоб по обоюдному согласию. Меня, например, не устраивает «левак» именно по причине выгорания и снижения эффективности по основному месту работы. Наверняка есть работодатели, которых «левак» вполне устроит.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    1. И да, и нет. Обучать придётся в любом случае. Под обучением я не имел в виду основы языка, паттерны или что-то такое. Обучение процессам компании как минимум; плюс обучение нашей системе, наследственным системам, общему вектору развития как компании, так и системы.

    Ну и плюс нанимать средних разработчиков и растить их внутри компании в долгосрочной перспективе выгоднее, чем нанимать готовых гуру. Хотя для ряда задач мы готовы нанимать и гуру, было бы кого.

    На эту тему сломано немало копий, и можно очень долго обсуждать. Но явно не тут в теме про удалённую работу.

    2. Возможно я не понял ваш вопрос. А если понял то ответ таков: потому что задач много, и управляются именно задачи. А управление людьми (вливание в процессы компании (которые ещё довольно активно меняются), стандарты качества, и тп) — это скорее уже про вот то самое обучение из п.1. Это во-первых.

    А во-вторых, почему сложность администрирование задачи не должна зависеть от количества исполнителей? Нелинейно, конечно, но зависит. Либо делегируется, и эта же зависимость работает уже не лично у меня, а где-то там у кого-то, кому оно делегировано. От этого зависимость не исчезает.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    У нас речь идёт о фултайм. На не-фуллтайм будет тратиться неоправданно большое количество сил на обучение и управление (равное фуллтайму) в отношении к приносимой пользе. Поэтому с парт-тайм или почасовой схемой мы не работаем.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    Да, критерии почти такие же как при найме в офис (плюс умение из дома вообще работать, а не халявить — у меня, например, это тяжко получается). Поэтому и говорю где-то тут рядом в комментах, что надомная работа — это и не фриланс, и не офисная работа, это что-то новое, третье.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    У нас целая методика, которую разрабатывают и опробывают проджект-менеджеры. Общий концепт: найти для каждого разработчика свой коэффициент, как его реальность расходится с его оценками, и далее применять для вычисления более реальных сроков.

    Детальную оценку делают разработчики вместе с ведущим, да.

    Касательно «своих» команд — я ещё дополнительно прикидываю и оцениваю сам для себя (без технических деталей, именно на высоком продуктовом уровне). Чай, не зря 10+ лет разрабатывал.
  • Почему мы (всё ещё) верим в удалённую работу
    +1
    Неправильно поняли эту фичу.

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

    Я не представляю себе того менеджера в здравом уме, который будет оплачивать 20% времени сотрудника, чтобы он левачил на сторону.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    Нет. Зачем нам сторонние коммерческие проекты? Мы ведь не аутсорная и не аутстаффная, а продуктовая нишевая компания. У нас своих проектов дофига.
  • Почему мы (всё ещё) верим в удалённую работу
    0
    Неа.

    en.wikipedia.org/wiki/Flow_(psychology) — … fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.
  • Почему мы (всё ещё) верим в удалённую работу
    +1
    Мы платим зарплату. Фиксированную в месяц. Всю «белую» (следовательно, нормальный 2НДФЛ). Оформление в штат по ТК РФ, с заключением трудового договора. «Белее» прямо не придумаешь :) Думаем о мотивационных схемах.

    Про контроль и оценку я чуть выше написал большой коммент.

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

    С социализацией как раз плохо. Ищу способы её повысить. Вот «перманентный hangout», наверное, от автора поста позаимствую экспериментально. Но он может быть и отвлекающим — надо пробовать.

    По сути, потери ≈30-50% общей эффективности из-за распределённости, полученные по оценкам ведущих, на мой взгляд и вызваны в первую очередь двумя вещами: (1) отсутствии социализации надомников, подразумевающейся в офисе, но отсутствующей в надомной работе; (2) сложностями коммуникации офисных и надомных сотрудников.
  • Почему мы (всё ещё) верим в удалённую работу
    +1
    Кстати, отвечая на вторую часть вопроса, про работу на сторону. Как это видеть и оценивать пока не знаю. Я ориентируюсь на общие показатели сотрудника как такового, фактически на его соответствие моим ожиданиям.

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

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

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

    За последние пару месяцев по этой причине потерял 2х, и чуть не потерял 1ого разработчика. Теперь сразу при найме акцентирую внимание что у нас fulltime в штат, а не разовый проект, и не почасовка (кроме тех случаев, когда действительно разовый проект и почасовка). И что работа на сторону очень плохо скажется на наших рабочих отношениях (коль уж запретить на практике нельзя).

    По сути, работа на сторону — это фрилансная привычка, которая не особо уместна в надомной работе. Но и старой доброй офисной работой надомничество тоже не является. В РФ только начинает формироваться культура (именно культура!) надомной работы full-time, отличная от этих двух крайностей. Тут «ГдеЭтотДом» в авангарде :-)
  • Почему мы (всё ещё) верим в удалённую работу
    +6
    Никак. В том смысле, что никак особенно.

    Встречный вопрос: а как вы понимаете что офисный сотрудник эффективно работает? Ведь присутствие на рабочем месте не является показателем эффективной работы, или вообще работы.

    Отвечаю про себя:

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

    Но эта схема работает только в командах порядка 7-10 человек, не больше. Как только начинается рост, появляются типичные проблемы роста. Например, невозможность контролировать всё и всех. Тут на помощь приходят и типичные решения: функциональные иерархии. И тогда оценка сотрудников делается через доверенных лиц на основании уже их мнения; обычно это ведущие команд.

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

    Другой способ, более сложный, но зато более системный — вводить KPI или аналоги. И не говорите мне что программистов нельзя померить. Очень даже можно! В KPI можно вкладывать такие вещи, как выполнение ежемесячных планов, попадание в сроки проектов, количество или длительность инцидентов при эксплуатации проектов/систем, и пр. В конце концов, в KPI можно включать даже экспертную оценку другими сотрудниками, как ведущими, так и мной лично через призму ведущих. Да и измерять можно не только сотрудников, но и сами команды.

    Disclaimer: Вообще 2012ый год я провёл в попытке достичь результата любой ценой, предполагая что процессы как-нибудь сами организуются. Был неправ. Последние 1-2 месяца начинаю делать схему наоборот: процессы нужно выстраивать, результат сам как-нибудь образуется. Формирование упомянутых выше оценок и KPI как раз является частью формирования процессов, так что я пока не могу сказать как было бы идеально правильно. Но мы в компании как раз продумываем и детализируем эти KPI для разработчиков, с некоторыми базовыми прототипами уже наготове.

    Вот как-то так. Заметьте, ни слова про надомность/офисность ;-)
  • Почему мы (всё ещё) верим в удалённую работу
    +3
    О как кстати :)

    Немного самопиара: мы в ГдеЭтомДоме тоже используем удалённую работу. Примерно 2/3 разработчиков и вообще технических специалистов — надомные (термин из ТК), 1/3 — офисные. Так что если вы знаете php/python/js — welcome (jobs@gdeetotdom.ru) ;-)

    С начала 2012, то есть уже второй год, набиваем шишки, набираем опыт. Могу кое-чем поделиться — задавайте вопросы; применимо как к работодателям, так и к сотрудникам, которые хотят работать удалённо. С радостью выслушаю опыт других, потому что кое-чего нам и мне лично сильно не хватает.

    Про цели и методы.

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

    Также, исходная статья написана в расчёте на американскую разработку с её спецификой (у них нет МКАДа). В России многие компании питают иллюзии(!) на тему того, что надомные сотрудники в регионах будут дешевле Москвы и сэкономят бюджеты. Бюджеты они действительно сэкономят, этак 30-50% в зависимости от. Но при этом просядет эффективность на те же самые 30-50%, и главным образом за счёт сложностей общения и интеграции. Ещё неизвестно что хуже.

    Поэтому единственная ценность удалённой работы, как и указано в посте, — только в расширении потенциальной аудитории сотрудников (устранение критерия локации). На ту же цель можно направить и используемую у нас многоязыковую платформу (php+js для FE, python для BE, но возможны любые комбинации и вариации) — но это уже вопрос архитектуры, а не схемы работы.

    Про методы.

    Касательно способов — там всё довольно сложно. Может быть даже чисто-распределённая команда была бы проще управляема и легче реализуема, чем гибридная. А может и нет. В гибридной команде естественным образом формируется ядро из офисных сотрудников, потому что это «классический» способ, к которому все привыкли и знают как делать. Приходится применять управленческие усилия (начиная с ведущих и выше), чтобы преодолеть эти психологические барьеры.

    Хотя вот некоторые приёмы я у автора позаимствую. Про google hangout могу пока сказать неприятную вещь: они публичны; и записи из них в youtube по умолчанию публичны. Но, видимо, это специфика личных hangouts. Надо попробовать которые «for business».

    Пока что используем Skype. Он и чат, он и голос, он и видео и screen-share при необходимости.

    А какие у вас способы удалённой работы?
  • 3 задачи, которые отсеивают 9 из 10 «Senior PHP» кандидатов
    0
    3ю задачу можно и без HAVING решить. На большом объёме библиотеки и популяции авторов и маленьком ожидаемом количестве трёхавторных книг может даже и эффективнее будет ;-)
  • Карта карьеры в ИТ
    0
    Или понимание что в разработке потолок достигнут, КПД больше не растёт, и дальше только сверх-тонкая супер-специализация, которая никому на рынке даром не нужна, не говоря уж про «за деньги». И единственное полезное рынку развитие — в получении навыков управления, опираясь на технологические навыки (разработка, админство) исключительно как на базовую подготовку.

    Это, конечно, если хочется развития. Многие предпочитают выбрать конформистский застой. Личное дело каждого.
  • Что плохого в работе на результат
    0
    Честно говоря, не уловил где тут процесс. Тут есть разного качества результат, разного уровня абстракции или удобства поддержки, если хотите. Но нет процесса.

    Вот если бы вместо того, чтобы делать автоматическую деплой-систему, персонаж написал инструкции и регламенты как устанавливать, кто устанавливает, в каком порядке, как оценивать качество и скорость его работы, какие нормативы — это уже было бы что-то близкое к процессу. А потом уже по ним запустил работать младшего инсталлятора. Или двух. Или дюжину. Главное тут что их почти не пришлось бы обучать основам работы в этой компании, потому что, действуя по инструкции, они результат таки получат, и качественный.
  • Распределенный мониторинг и географическая доступность
    0
    PS: А, я смотрю автор из WEBO :-)

    Тогда могу сразу дать беглый отзыв: интерфейс, конечно, красивый, НО: мало того, что проверочные точки названы какими-то непонятными шифрами типа «NA (KHA)», «AL (EKT)» и «HE (AMS)», так среди них нет ни одной точки в загранице, что делает сервис почти полностью непригодным к боевому использованию. Хотя бы на AWS развернуть пинговалку-то можно было бы, сразу на всех их regions?
  • Распределенный мониторинг и географическая доступность
    +1
    Почему только российские? Есть ещё «канонические» глобальные PingDom, monitor.us и пр.

    Ping Admin, к слову, зачем-то рассчитывается в $$$. Ну и курс у них 34 RUR/USD. Деньги утекают быстрее чем на любом другом сервисе (потому что за каждую проверку каждый раз с каждой точки берётся по чуть-чуть). Точек, конечно, много, но интерфейс неопрятный, наколеночный, не вызывает доверия к сервису. Бесплатного режима, как у других сервисов, нет.

    А host-tracker вообще при тестовой проверке умер в «502 — Web server received an invalid response while acting as a gateway or proxy server» :-)

    А вот за WBO Pulsar спасибо. Его в своё время не нашёл. Выглядит интересным. Изучу.
  • В последнее время слишком много технологических расхождений в сфере программ и железа
    +2
    Технологическая сингулярность грядёт.

    Кстати, Вы неправы насчёт «уникальных» программных обеспечений. Есть некоторый фронт, первичный бульон, так сказать. На нём идёт война решений.

    После этого фронта в тылу остаются уже устоявшиеся кросс-платформенные решения. Много их. Напомнить? Пожалуйста: png, jpeg, mpeg, smtp, pop3/imap, html, http, mime, etc, etc, etc. Это и есть кросс-платформенный остаток первичного фронта — самые сильные решения из тех, что были.

    И то, что сейчас кипит и булькает в этом первичном бульоне, оно через 5-10-15 лет будет стандартом. Ведь никому же сейчас не придёт в [здоровую] голову переизобретать e-почту, например? Или html? Только надстройки, только улучшения.