• Бег — идеальный спорт для удаленщика. Часть 1: путь до первого забега на сотню километров
    0
    Подготовка к марафону или полу-марафону как раз может стать мотивацией. «А зачем бежать марафон?» Ответ как и для большинства бежавших хоть раз в жизни: проверка себя на слабо. Бегал берлинский марафон, впечатления незабываемые.
  • Алкоголизм последней стадии
    0
    Что именно обратимо? Наверное привычка пить? На определенной стадии алкоголизма кажется развивается необратимая энцефалопатия
  • Переезд во Францию по работе: зарплаты, визы и резюме
    +2
    У меня диаметрально противоположный опыт. Фанцузы (особено из провинции) это милейшие люди. Возвращаясь из Франции в Россию, остро обнаруживаешь, что простая бытовая любезность/вежливость отсутствует.

    Учился, работал 17 лет.
  • CG Pods — TWS-наушники, которые смогли
    0

    Не, не, не. После цикла статей о bluedio, к обзорам наушников на хабре у меня иммунитет.

  • Почему люди не используют формальные методы?
    0
    Есть так же метод Б (https://en.wikipedia.org/wiki/B-Method) с практическим применением например для автономной ветки метро или космического корабля Ариан-5.

    Желающие могут самостоятельно попробовать — «Atelier B is an industrial tool that allows for the operational use of the B Method to develop defect-free proven software (formal software)». На выходе автоматически генерируется код на С или Ада.

    Ссылки:
    www.atelierb.eu/en
    www.atelierb.eu/wp-content/uploads/sites/3/dbprotect/formations/slides/formation-atelier-b-formation-niveau-1-en.pdf

    Интервью Jean-Raymond Abrial (создатель метода Б) для журнала 01net о формальных методах в 2002г (извиняюсь за корявый перевод).

    www.01net.com/actualites/jean-raymond-abrial-consultant-le-zero-defaut-nexiste-pas-mais-on-peut-tout-de-meme-sen-approcher-173964.html

    Формальные методы повышают надёжность программного обеспечения, но их использование не распространено. Как вы это объясните?

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

    Формальные методы подразумевают затраты большего времени на спецификацию, чем на тесты. Не ставит ли это под сомнение обычный цикл разработки?

    В других инженерных дисциплинах, таких как авиаконструирование или гражданское строительство существуют аналоги формальных методов — это понятие конструкторского бюро. Сначала рисуют модель будущего объекта, который затем осмысляют в соответствии с теориями. Идея долгого процесса от осмысления до реализации есть часть современной инженерии. Использование формальных методов это конструкторское бюро программного обеспечения: рисунок софта это формальный объект который мы не можем запустить, но над которым мы можем размышлять, моделировать. Большинство программистов считают, что достаточно запустить программу и провести тесты для того, чтобы убедится в правильном функционировании. Как если бы для создания самолета, вы производите что-то похожее на утюг с крыльями и который затем тестируете. Этот способ практиковался в истории технологий, но это примитивный подход. С момента как технология набирает значимости, мы начинаем размышлять над чертежами и моделями.

    В чем сложность использования формальных методов?

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

    В каких случаях формальные методы наиболее применимы?

    Их достаточно много. Например концепция распределенных систем: проблема в том, что в них не существует «главного». В протоколе маршрутизации узел сети не предпринимает решений за другие узлы. Информация меняется и на каждом узле заново определяется дальнейший маршрут, в зависимости от особенностей локальной сети. Таким образом, очень трудно проводить тесты в подобных условиях, так как эти условия исполнения никогда не повторяются. Формальные методы, отчасти, используются для разработки протоколов передачи, маршрутизации и криптографии. Эти методы все больше и больше применяются в задачах, которые неограниченны лишь разработкой софта. В частности, при изучении сложных систем. Необходимо реализовать объект, над которым будет производится дальнейшее размышление, строго соответствующее модели объекта.

    В каких странах более всего используются формальные методы?

    Европа немного впереди планеты всей. В частности Франция, Англия и Германия. Что же касается американцев, то и них много денег и хорошие методы работы. Люди, участвующие в проекте, очень ответственны. Это компенсирует часть проблемы. В профессиональном отношении, они придают огромное значение качеству специалистов. Кстати, в больших компаниях можно часто встретить высокопоставленных работников, которые сами являются специалистами (в тексте техниками). Технические знания высоко ценятся, это позволяет создавать качественные системы.

    Являются ли формальные методы панацеей?

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

    Jean-Raymond Abrial, независимый консультант и «изобретатель» формального метода B.
  • Сколько зарабатывают ИТ-шники в Германии
    0
    Работал в Bombardier Transportation в Берлине — там сплошь гастарбайтеры из Швейцарии, Канады, Аргентины, Франции, Польши и тд — зарплата намного выше 50k в год (sky is the limit)
  • Сколько зарабатывают ИТ-шники в Германии
    +2
    Если перестал платить налог, потому что объявил себя атеистом. а потом вдруг захотел ребенка крестить — пожалуйста снова плати налог, в том числе за пропущенные годы. Случай реальный с коллегой.
  • Злоумышленники научились обходить двухфакторную аутентификацию Yahoo Mail и Gmail
    0
    Вы серьезно? Собирался привезти знакомому Yubikey в подарок на днях.
  • Гибридное хранилище для дома «из коробки» и возможности High Availability от Synology
    0
  • Просто о микросервисах
    0
    Почти в каждой статье о микросерверах можно встретить пассаж о том что ESB это плохо. А что же именно плохо? Быть может автор подразумевает, что сервисы живут в прекрасном мире RESTful и все они друг друга понимают без сложной интерпретации/трансляции? Есть же куча legacy сервисов которые умеют раздавать данные только в своем собственном формате. Получается, что каждому такому сервису необходимо писать обертку типа Anti-corruption layer (https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer). ESB как раз таки и может быть такой универсальной оберткой.

    Хотелось бы развернутого пояснения следующему:
    Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
  • Enterprise Architecture vs алхимия предприятия. Ключевые мифы
    0
    Togaf определяет несколько типов архитектуры (http://pubs.opengroup.org/architecture/togaf9-doc/arch/), в вашем случае будет бизнес архитектура описывающая структуру предприятия, роли, сервисы, продукты, сценарии (купил-продал) и тд.

    На самом деле не стоит применять Togaf на все случаи жизни, эта методология все же специфична для ИТ.
  • Enterprise Architecture vs алхимия предприятия. Ключевые мифы
    0
    Я не опираюсь на конкретные примеры, а применяю рекомендации Togaf основываясь на моем понимании/интерпретации, а так же не малой долей здравого смысла. По началу приходиться по много возвращаться к документации вновь и вновь, искать в гугле подтверждение (или нет) правильности понимания. Только реальное применение позволит (субьективно) правильно разложить все по полкам, получить ответы на возникающие вопросы.

    Architecture repository у меня организован следующим образом:
    • Architecture landscape
      • Strategic architectures — описание предприятия высокого уровня — на примере Амазон это может быть список ключевых сервисов (retail, aws и так далее)
      • Segment architectures — описание определенного бизнес домена предприятия — на пример более подробного описания сервисов aws
      • Capability architectures — описание конкретного aws сервиса, например S3
    • Reference library
      • Reference models — например модель описывающая big data aws, azure или google
      • Reference architecture — более подробное описание с названиями ПО, взаимосвязями опять же на пример для big data
      • Templates — различные шаблоны для ИТ документов

    • Standards information base
      • Список различных стандартов предприятия помогающих архитектору реализовать задачу (все что угодно — SLA, безопасность и тд)
      • Список стандартных и поддерживаемых решений предприятия — модели серверов, СХД, сетевых устройств, ПО для базы данных и тд
    • Architecture building blocks
      • Шаблоны архитектур для различных компонентов (веб сервер) и их конкретная реализация про помощи того или иного решения (Apache)



    В дополнение к этому описание процессов принятия новых стандартов, технологий, рассмотрения и подверждения архитектур новых сервисов предприятия и тд.

    Важно чтоб превалировал здравый смысл, а не слепое и тотальное следование рекоммендациям Togaf.
  • Enterprise Architecture vs алхимия предприятия. Ключевые мифы
    0
    Я рассматриваю Togaf как рекомендации для того чтобы:
    — последовательно, пройдя все необходимые этапы (requirements, uses cases, point of views, application, data, technology architecture и тд) реализовать какую-то цель/стратегию/задачу бизнеса посредством ИТ
    — упорядочить и поддерживать ИТ документацию предприятия состоящую из таких документов как принятые стандарты, описание ПО используемого в организации (это могут быть различные виды описания — просто диаграмма, детальное описание компонентов на уровне данных, инфраструктуры и тд)
    — управление архитектурой как на уровне организации в долгосрочной перспективе (architecture board) или на уровне определенного ПО организации

    В Togaf очень много деталей, но личный выбор каждого выбрать наиболее необходимые/приемлимые моменты. Все это не есть какое-то изобретение Open group, в том или ином виде подобные вещи существуют и практикуются повсеместно. Open group объединила их в документацию и выставила в свободный доступ. Иметь или не иметь сертификат — дело сугубо личное. Обвинять Open group в жадности не вижу смысла.
  • Умер один из «отцов Рунета» Антон Носик
    +3
    Да неужели… https://www.youtube.com/watch?v=FghsHP8E9Ss
  • «SAP HANA в облаке VMware»: Расчет необходимых ресурсов
    +1
    А почему вас нет в список сертифицированных поставщиков (http://www.sap.com/documents/2015/03/74cdb554-5a7c-0010-82c7-eda71af511fa.html#) :)

    По поводу расчета ресурсов, на мой взгляд не все так просто — скриншоты и формулы, что вы привели в статье, описаны на saphanatutorial.com/sap-hana-sizing. А на http://www.sap.com/documents/2015/03/74cdb554-5a7c-0010-82c7-eda71af511fa.html# расчеты другие, в частности «There is no direct correlation between the SAP HANA database size and the required log volume size.»

    [systems ≤ 512GB ] Size redolog = 1/2 x RAM
    [systems > 512GB ] Size redolog (min) = 512GB


    Я не говорю, что вы приводите не правильную информацию, мне кажется по поводу расчета ресурсов есть некоторая путаница в данных доступных в интернете.
  • 12 лучших менеджеров паролей
    0
    Password state от ClickStudion — один из продвинутых менеджеров для Enterprise. Перечислять возможности не буду, они доступны по ссылке https://www.clickstudios.com.au/passwordstate.html

    До 5 пользователей — бесплатно
  • Netapp — реальность против маркетинга
    +1
    Спасибо за статью, часто приходиться работать с поставщиками оборудования — на слайдах все красиво и прекрасно, но когда начинаешь устанавливать вылазят те или иные ограничения, сложности о которых поставщик «забыл» упомянуть. Это в принципе касается всех (и EMC и NetApp). Только реальный опыт подобный описанному вами дает понять где и у кого слабые места.
  • Motorola Moto G — для начинающих и экономных
    0
    Пользуюсь этим телефон уже два месяца. В коробке присутствует и гарнитура и зарядка (куплено в европе).
    Задняя крышка скользкая, неудобно. В остальном очень доволен.
  • HTC: One X, One X+ останутся на текущей версии Android
    0
    Motorola свое обещание для Moto G выполнила — на днях на 4.4 перешел. Зачет.
  • Onda V975 — планшет с 9,7-дюймовым экраном Retina
    +6
    Несколько раз покупал подобные китайские девайсы (но не именно этой марки) — даже низкая стоимость не способна восполнить ущербность железа/прошивки. Наиболее частые слабые места: батарея, чувствительность экрана, gps, etc.
  • На чем хранить бэкапы: Лента VS Дисковые СХД
    0
    Я ведь написал, что у DD890 только 4 порта, которые уже заняты, интерфейс 10 Гб вставить некуда. Я так же писал в каком конкретном случае лента выигрывает у дисковой системы: большие объемы ежедневного трафика (несколько клонов по 15 То), много клиентов резервного копирования. По экономическим соображениям здесь лента будет выгоднее.

    Про дедупликацию сейчас речь не идет. Это тема отдельная, там свои заморочки.
  • На чем хранить бэкапы: Лента VS Дисковые СХД
    0
    Два клиента могут вполне использовать один и тот же драйвер, естественно они при этом пишут или читают попеременно. Так же как и один клиент может писать на несколько драйверов. У datadomain полоса пропускания одна на всех клиентов — 4х8 Гб/с. У ленты — каждый драйвер со своим контроллером FC.
  • На чем хранить бэкапы: Лента VS Дисковые СХД
    0
    У DD890 4 порта FC
  • На чем хранить бэкапы: Лента VS Дисковые СХД
    +1
    Symantec NBU, Backup exec
    EMC Networker
  • На чем хранить бэкапы: Лента VS Дисковые СХД
    +1
    По поводу масштабируемости дисковых систем можно поспорить. Вы привели цифры лишь о емкости, а как же входяший/исходяший трафик? К примеру, у нас в ДЦ стоит EMC Datadomain 890 у которой максимум 3 порта FC 8Gb/s и больше нет слотов. И стоит лента Quantum Scalar i6000 с 24 LTO5 драйверами FC 4Gb/s (96 драйверов максимум). Получается что для того, чтобы достичь уровня ленточной библиотеки в трафике, нужно несколько DD, стоимость которых зашкаливает. То есть там где нужна реальная масштабируемость и большие объемы резервных копий — лента пока имеет свое место исходя из экономических соображений. Но это скорее частный случай.

    А в общем случае, дисковая система выигрывает у ленты так же в силу дополнительного функционала:
    — дедупликация
    — репликация
    — client direct LAN (клиентский сервер может напрямую отправлять данные дисковой системе, без участия медиа-сервера)
  • Неожиданная популярность TinyRSS.ru
    0
    под клиентом я имел ввиду вебморду tinyrss.ru. Перешел на feedly.
  • Неожиданная популярность TinyRSS.ru
    –2
    Ужасно не понравился клиент, фиды не обновляются сами по себе. Установка автоматического обновления ничего не изменила.
  • Тендер по Private Cloud — часть вторая
    0
    Биллинговая система — HP CLoud Cruiser, благодаря ее интеграции с экосистемой HP OO.
  • Облако в кармане
    0
    Самому сделать NAS сервер с Openmediavault с похожим функционалом.
  • Бюджетное решение для бэкапа целого офиса
    0
    На мой взгляд, backuppc делает тоже самое и даже больше.
  • Asterisk распознавание речи через Google + умный IVR
    0
    Спасибо за решение, пара вопросов по этому поводу:
    — почему не записать стандартные, повторяющиеся фразы в формат mp3 или gsm, вместо того чтобы обращаться каждый раз к гуглу (”Здравствуйте! После звукового сигнала произнесите имя абонента”)? Это реально в продакшине или для примера показано?
    — какова задержка обработки в обоих случаях: googletts.agi и speech-recog.agi
  • Практические советы по выбору облачного провайдера
    0
    Да, в сап есть стандартный набор утилит br*tools, который справляется с резервным копированием и достаточен. Но в итоге получается, что кроме сап, в инфраструктуре очень много всего что нужно сохранять — операционки, файлер, exchange какой-нибудь и т.д. И тут встает вопрос о том чтобы иметь единый софт, который бы имел необходимые модули для консистентого резервного копирования различного ПО, мог выдавать понятные отчеты, управлять каталогом копий и при этом имеющий саппорт.

    Получается, что проще управлять всей этим через одно, пусть платное решение, чем несколько разрозненных утилит.

    P.S. Если существует opensource решение отвечающее этим требованиям — тем лучше, правда я не знаю такое. Подскажите, возьму на заметку.
  • Практические советы по выбору облачного провайдера
    0
    предположу, что компания которая инвестирует в сап, не поскупится купить проприетарное решение (emc networker, symantec nbu, etc) чтобы иметь гарантированный саппорт.
  • Практические советы по выбору облачного провайдера
    +3
    По моему все правильно. Только вчера сдали пакет документов в ответ на тендер для облачной инфраструктуры. Клиент в своих запросах идет достаточно далеко (100 стр. тех. задания), к вышеуказанным требованием добавлю:
    — интеграция его собств. датацентра и облака
    — миграция в облако: методы, планировка
    — как дать доступ партнерам к облаку по Интернет + ssl
    — возможность виртуализации AIX
    — можно ли иметь несколько зон в облаке
    — патч-менеджмент опер. систем и ПО: какой процесс и периодичность
    — может ли оператор разместить у себя в ДЦ особую аппаратуру клиента (riverbed, etc.)
    — какие доп. средства может предоставить оператор (scheduler, cmdb, ...)
    — а так же много запросов по поводу управления (все что относится к itilv3): роли, обязанности

    В итоге такой чек-лист актуален, когда переноситься ИТ-инфраструктура в облако, а не просто два-три сервера.
  • NetApp: Матрица совместимости
    0
    Я тоже это имел ввиду — поддержка архитектуры Flexpod.
  • NetApp: Матрица совместимости
    0
    Полная поддержка, без каких-либо ограничений.
  • NetApp: Матрица совместимости
    0
    Нельзя ли собрать FlexPod самому по запчастям? К примеру, часть оборудования уже есть.
    Можно, но такая система не будет называться FlexPod.

    Будет, по крайней мере это нам обещал Cisco и NetApp. Это и логично, ведь Flexpod это не готовый продукт, а blueprint. Если у меня уже есть элементы, которые поддерживаются архитектурой Flexpod, то я могу «сам» (скорее сертифицированный партнер NetApp/Cisco) собрать всю инфраструктуру.
  • ЦОД из коробки: обзор платформы Vblock от VCE
    0
    В VCE, насколько помню, на 60% принадлежит EMC, соответственно схд NetApp там врядли будет.
  • ЦОД из коробки: обзор платформы Vblock от VCE
    0
    То что инфраструктура поставляется пользователю уже собранной и настроенной это большой плюс. Из минусов это стоимость и архитектура vblock, которой управляет не пользователь, а инженеры vce. Думается, что для того чтобы исправить это ограничение EMC предлагает vspex.
  • Восстановление виртуальных машин из «снэпшотов» SAN с помощью Veeam Backup & Replication
    0
    VCB или все же VADP? VCB польностью умер и не поддерживается.