В статье даны 7 четких точек контроля процесса любой ИТ команды. Бери и делай.
Ну это как из мультика -- "Что нам стоит дом построить? -- Нарисуем будем жить!"
Можно к примеру посмотреть на пункт 6. "Это то место, где заказчик принимает работы и должен сказать ОК. " Здесь не показано как быть в ситуации, когда заказчик по тем или иным причинам не говорит "ОК". Получается так, что мы тут что-то сделали/приготовили -- а ты кушай сам, и не важно что такой результат реальному бизнесу не нужен. И тут начинаются доработки, а это время. Это время накладывается на текущие планы по другим задачам, начинается переприоритезация задач и что-то, что планировали сделать до конца года уже сделать не получается -- и бизнес опять уходит "обманутым". Просто в данном случае остается много артефактов того, что конкретно разработка в этом не виновата -- вот смотрите на задачу, план, списание времени и результат!
По вашему примеру с оценкой, я скажу достаточно категорично, просто потому что у меня опыт разных оценок больше 20 лет: если человек раз за разом не попадает в оценку, он джун и ему надо учиться.
Скажу не менее категорично. Если вы всю свою профессиональную жизнь сталкивались только с типовыми задачами, где сроки типовые (и agile из-за этого и не нужен и даже вреден), так вот если вы не видели/не брали задач исследовательского толка, то и разработкой вы не занимались, то что вы делали называется поддержка
Бывают исключения, где чистая научно-исследовательская работа, но стандартная работа ИТ отдела это: допилить интеграцию, добавить раздел на сайт и тп - не ракетные технологии
Ну собственно говоря о том и речь. Мы смотрим с разных колоколен, но называть один колокол стандартным, а другой нет -- яб не стал
Для примера, я давал оценку на проект за 1 млн usd на год вперед и попал в нее с точностью до 0.5% - проверил спустя год, и сам удивился.
У меня тут одна большая задача в днях посчитана на ближайшие 2 года, и я сам с удивлением смотрю на то, что текущий темп совпадает с моим прогнозом, но я отдаю себе отчет в:
что это безусловно мой накопленный опыт и в большой задаче можно выделить какие-то типовые моменты, сроки который прогнозируются без проблем, но с оговоркой, что ставку исполнителя не отберут, что в отпуск длительный никто не уйдёт и тд
что это может быть просто совпадение (ошибка выжившего)
что исполнители смотрят на оценки и подгоняют/тормозят свои задачи исходя из них. То есть на одной задаче могут чуть отдохнуть и побольше почитать хабра, а на другой -- делают чуть менее качественно, но зато в срок
Agile вообще не является методологией, давайте будем корректны.
Ну это один из основных споров -- споров об определениях. Но соглашусь уступить, так как дело вобщем-то не в этом
Об том и речь. Что Вы не замечаете огромного слона, предлагая при этом подход "для работы любой ИТ команды"
Как только растет команда - придется отделять и формализовывать все, что я описал выше.
Если большой бизнес хочет знать с некоторой погрешностью сколько будет стоить большая фича (неважно в деньгах или во времени), то да, появляются сроки, agile с часами, списание времени и прочие кровавые энтерпрайз штуки. Которые часто есть самообман да и только. И дело тут в оценке погрешности, про которую ничего толком сказать невозможно, да и те кто дают такие оценки -- не всегда те, что за них отвечают через пару лет. Даже с типовыми задачами может быть лажа, у Вас Вася справлялся с задачей за месяц, но он ушел и пришёл Петя. За сколько справится Петя? И нельзя и невозможно сравнить Петю с Васей, сколько линейку грейдов не прикладывай
Начали за здравие, закончили за упокой. У вас тоже не получилось никакой серебряной пули.
"Как мы помним, наша задача - делать все, чтобы его не двигать вправо, а если и двигать, то предсказуемо, прозрачно и заранее" -- никто не знает до момента конечного выполнения задачи сколько эта задача ещё займёт. Бывают крупные задачи, которые решаются в 2-3 раза быстрее запланированного времени. А бывают казалось бы мелкие, но сроки по которым двигаются по 5 раз.
"Разработка может вестись по спринтам, потоком по канбану или по старинке, через waterfall" -- и снова натянули agile-сову на глобус жёстких сроков =)
Agile -- как методология решения нерутинных, исследовательских задач, говорит, что мы всё равно не угадаем по срокам, надо оценивать задачи по сложности. Задача простая и прозрачная -- ставим сложность 3. Сложная и непредсказуемая -- 9. Но это не значит, что мы простую сделаем в 3 раза быстрее чем сложную задачу
По аналогии с SNI, предположу, что ESNI — это расширение TLS и тогда он к DoH напрямую не относиться и это два параллельно развивающихся концепта. Хорошо что вопрос пользовательской криптографии развивается, но пока это лишь концепты. И обрести жизнь может любой из них и ни один из них.
Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
AOID — идентификатор записи как таковой, а вот AOGUID и PARENTGUID используются для создания иерархии. Так, один и тот же адресный объект может иметь несколько записей. В этом случае, каждая запись будет иметь разный AOID и одинаковый AOGUID
Я тогда воспользовался iterparse из lxml.etree — что-то вроде SAX.
А по поводу потоков, разбор XML — не самая трудная задача. Там, в 21 гигабайте, содержится чуть больше 3.2 миллионов записей, если использовать только с атрибутом ACTSTATUS равным 1, то таких записей, на память, что-то около 1.5 миллиона. А вот обработка таких данных — другое дело, для выстраивания иерархии используются строковые UID'ы (атрибут AOGUID). Причем разные объекты могут иметь одинаковые значения AOGUID, тогда «правильная» запись выбирается исходя из других атрибутов.
Список объектов скинул сюда. Впрочем все найденные мною объекты имели CURRSTATUS равный 99. Но тут есть ньюанс, как я понимаю.
К примеру, там есть запись (4-ая по порядку) — ул. Адмирала Горшкова, находившаяся в городе Щербинка. К слову, город Щербика по базе до сих пор город, а вот согласно вики — поселение. Так вот изменилась это запись в сентябре прошлого года. С точки зрения логики, тогда эту запись и могли сделать исторической. И вопрос — как много документов, в которых эта улица все еще существует? Тут видимо надо пологаться из задачи, использовать CURRSTATUS или ACTSTATUS. В самом начале документации (не в описании таблицы) сказано следующее:
ACTSTATUS — определяет, является ли эта запись по адресному объекту актуальной на текущую дату (0 – не актуальный, 1- актуальный).
CURRSTATUS — «Статус актуальности в соответствии » с классификацией адресных элементов и адресных объектов. Содержит значение признака актуальности адресного элемента и объекта адресации
Из «смешного» я еще помню улицы, у которых родительскими объектами были другие улицы — но этого я быстро не найду. Да городской округ в качестве административно территориального деления, согласно закону (еще можно посмотреть здесь), городской округ — это муниципальное деление. В качестве примера — городской округ Егорьевский из Московской области (AOGUID: 96036cfc-7acb-4de8-9004-3ae4c1c232c0).
А вот с домами базы я не смотрел — не было острой необходимости в задаче но напугало наличие _ДВУХ_ баз про дома HOUSE и HOUSEINT. Выдержка из документации:
Таблица HOUSE (House) содержит записи с номерами домов улиц, элементов планировочной структуры, городов и населенных пунктов. При выгрузке сведений по домам в формате DBF именам файлов присваиваются имена HOUSE01 – HOUSE99, где 01-99 коды регионов в соответствии с Приложением 3.
Таблица HOUSEINT (HouseInterval) содержит записи с интервалами домов улиц городов и населенных пунктов.
PS актуальность — от позднелат. actualis — фактически существующий, настоящий, современный =)
Недавно сталкивался с разбором ФИАС, даже думал написать сюда статью, но лени хватает только на комментарии сюда. tl;dr — информация внутри базы разрознена, документация не отражает реальное положение дел. Что бы я выделил из своего опыта:
— Формат dbf — нормально прочитать его в Python у меня не получилось, оптугнуло вот что. Но разбор XML это тоже еще та головная боль. Файл ADDROBJ занимает больше 21 гигабайта, это значит прогонять через DOM — совсем не вариант
— Часть полей объявленных как обязательные, по факту отсутствуют. Другие (необязательные) — присутствуют всегда.
— Опираться на код КЛАДР для записей — плохо. Например ряд улиц из новой Москвы, проходят по AREACODE (входит в код кладр) как Подмосковье. При этом города, которым подчинены эти улицы, могут иметь уже другой AREACODE (то есть принадлежать другому региону).
— Необходимо учитывать ACTSTATUS (не CURRSTATUS) или использовать STARTDATE, ENDDATE, UPDATEDATE. Адресные объекты могут переименовываться, чтобы не копаться в истории — крайне важно искать только актуальные записи.
— Существующая отдельная база для «раскрытия» сокращений (SOCRBASE), т.е перевода из SHORTNAME 'г.' в 'Город', не содержит всех реально используемых сокращений в базе ADDROBJ
К этому необходимо добавить, что контрольная сумма в UDP опциональна настолько, что она может иметь любое значение и это нормально. Да и IP для ответа, может браться из полезной посылки пакета (привет SIP, STUN и пр.)
Не знаю, но я в своем Firefox нашел и Yandex (SHA1: DD:F1:0E:6D:A7:2C:44:7E:CA:D8:74:EB:53:1B:49:66:2D:2C:6E:D2) и RU-CENTER (SHA1: 0D:C4:12:DB:C9:BF:0B:4F:CA:C7:7A:3B:73:AA:07:AA:4F:DE:BD:45)
Безопасность проще переводить в деньги, чтобы было понятно что является эффективным, что — нет. Это как гаечный ключ за 10$. Всегда можно дать админу на лапу или шантажировать его, чтобы получить сертификат. Сертификаты «ломают» и будут «ломать» всегда. В конечном счете, можно взломать вебсервер и вытащить ключ от туда (у мнгоих ли он запаролен?).
Я говорю не об этом. Мне приятней думать, что есть какая-то надежда на децентрализацию в вопросе доверия сертификатов. Что мы доверяем архитектуре/алгоритму/модели, нежели чем вот этим вот 3-5 организациям.
С новыми расширениями сертификатов тоже есть сложности. Есть (и всегда будет) старое ПО. Хотим мы или не хотим, но вопрос внедрения не может не занять множество лет. Я до сих пор в работе сталкиваюсь с Cisco PIX, редко, но сталкиваюсь. Так вот настройка этого «чуда» через браузер требует совсем старую JAVA и IE. Или вот, пример поближе VSphere 5.5 — вышел чуть меньше 4 лет назад, но требует Flash, который как мы знаем «выпиливается» из браузеров. С предлагаемыми расширениями, получится все тоже что и со всеми предыдущими — кто-то реализует, кто-то нет, кто-то реализует по своему. Это как внедрить очередной, 15-ый стандарт, который наконец объеденит все предыдущие (да, снова отсылка к Ренделу =) ). На мой взгляд, тут может сработать только принципиально новая идея (необязательно про блокчейн).
Let's Encrypt лишь следует существующей формальной логике — цепочка до CA и пр. Для клиента нет никаких различий между выпуском сертификата от Let's Encrypt и другого CA или же двумя разлиными выпусками сертификатов от Let's Encrypt для одного и того же домена.
Вобщем все проблемы существующей инфраструктуры CA присутствуют и здесь. Идеально было бы избавиться от CA вообще.
Размер базы — это проблема, особенно для мобильных устройств. Впрочем, как и процедура отзыва сертификата.
Возможно, необязательно хранить всю базу локально. Ведь и сейчас при создания SSL-тунеля, в частности для проверки сертификата на отзыв, требуется обращение ко внешним ресурсам. Что если для проверки сертификатов обращаться к случайным узлам, в стиле p2p, может даже к узлам в сети onion/tor?
А для вопросов непосредственной реализации, достаточно чтобы этим заинтересовались Google и Mozilla =)
Я тут недавно «споткнулся» о следующую мысль. Блокчейн — это технология доверия, когда нет доверия никому конкретно. И тут я понял — этож лучше, чем грядущая проверка сертификатов через CAA-запись. CAA-запись частично решает вопрос доверия CA, но тот же CA может выпустить второй сертификат. А ведь еще есть и DNS-спуфинг.
Хранение всех выданных сертификатов в блокчейне тоже имеет свои минусы, но идея, на мой взгляд, интересная.
Спорный момент, теже мобильные операторы, которые почти одновременно заявили об отсутствии интереса безлимитного интернета со стороны пользователей, стараются все же обойти друг друга, если же не ценой, так тем кто первый запустит новую услугу.
Например, для планшета неважен телефонный номер — легко заменить сим карту. Поэтому тот, кто внедрит «новый -LTE» быстрее чем другие, получит больше «хайпу».
Или же вот, куда «перетекли» абоненты Билайна — к конкурентам.
Для библиотек со стороны, без вариантов, надо расколдовывать mangle, который не стандартизован (по очевидным причинам). Примеры, как может быть: https://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions
А для своих библиотек правильне было бы использовать extern «C».
Ну это как из мультика -- "Что нам стоит дом построить? -- Нарисуем будем жить!"
Можно к примеру посмотреть на пункт 6. "Это то место, где заказчик принимает работы и должен сказать ОК. " Здесь не показано как быть в ситуации, когда заказчик по тем или иным причинам не говорит "ОК". Получается так, что мы тут что-то сделали/приготовили -- а ты кушай сам, и не важно что такой результат реальному бизнесу не нужен. И тут начинаются доработки, а это время. Это время накладывается на текущие планы по другим задачам, начинается переприоритезация задач и что-то, что планировали сделать до конца года уже сделать не получается -- и бизнес опять уходит "обманутым". Просто в данном случае остается много артефактов того, что конкретно разработка в этом не виновата -- вот смотрите на задачу, план, списание времени и результат!
Скажу не менее категорично. Если вы всю свою профессиональную жизнь сталкивались только с типовыми задачами, где сроки типовые (и agile из-за этого и не нужен и даже вреден), так вот если вы не видели/не брали задач исследовательского толка, то и разработкой вы не занимались, то что вы делали называется поддержка
Ну собственно говоря о том и речь. Мы смотрим с разных колоколен, но называть один колокол стандартным, а другой нет -- яб не стал
У меня тут одна большая задача в днях посчитана на ближайшие 2 года, и я сам с удивлением смотрю на то, что текущий темп совпадает с моим прогнозом, но я отдаю себе отчет в:
что это безусловно мой накопленный опыт и в большой задаче можно выделить какие-то типовые моменты, сроки который прогнозируются без проблем, но с оговоркой, что ставку исполнителя не отберут, что в отпуск длительный никто не уйдёт и тд
что это может быть просто совпадение (ошибка выжившего)
что исполнители смотрят на оценки и подгоняют/тормозят свои задачи исходя из них. То есть на одной задаче могут чуть отдохнуть и побольше почитать хабра, а на другой -- делают чуть менее качественно, но зато в срок
Ну это один из основных споров -- споров об определениях. Но соглашусь уступить, так как дело вобщем-то не в этом
Об том и речь. Что Вы не замечаете огромного слона, предлагая при этом подход "для работы любой ИТ команды"
Если большой бизнес хочет знать с некоторой погрешностью сколько будет стоить большая фича (неважно в деньгах или во времени), то да, появляются сроки, agile с часами, списание времени и прочие кровавые энтерпрайз штуки. Которые часто есть самообман да и только. И дело тут в оценке погрешности, про которую ничего толком сказать невозможно, да и те кто дают такие оценки -- не всегда те, что за них отвечают через пару лет. Даже с типовыми задачами может быть лажа, у Вас Вася справлялся с задачей за месяц, но он ушел и пришёл Петя. За сколько справится Петя? И нельзя и невозможно сравнить Петю с Васей, сколько линейку грейдов не прикладывай
Начали за здравие, закончили за упокой. У вас тоже не получилось никакой серебряной пули.
"Как мы помним, наша задача - делать все, чтобы его не двигать вправо, а если и двигать, то предсказуемо, прозрачно и заранее" -- никто не знает до момента конечного выполнения задачи сколько эта задача ещё займёт. Бывают крупные задачи, которые решаются в 2-3 раза быстрее запланированного времени. А бывают казалось бы мелкие, но сроки по которым двигаются по 5 раз.
"Разработка может вестись по спринтам, потоком по канбану или по старинке, через waterfall" -- и снова натянули agile-сову на глобус жёстких сроков =)
Agile -- как методология решения нерутинных, исследовательских задач, говорит, что мы всё равно не угадаем по срокам, надо оценивать задачи по сложности. Задача простая и прозрачная -- ставим сложность 3. Сложная и непредсказуемая -- 9. Но это не значит, что мы простую сделаем в 3 раза быстрее чем сложную задачу
То выпустить сертификат Let's Encrypt не должно составить большого труда — Lets encrypt (Provisioning a DNS record under example.com)
Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
А по поводу потоков, разбор XML — не самая трудная задача. Там, в 21 гигабайте, содержится чуть больше 3.2 миллионов записей, если использовать только с атрибутом ACTSTATUS равным 1, то таких записей, на память, что-то около 1.5 миллиона. А вот обработка таких данных — другое дело, для выстраивания иерархии используются строковые UID'ы (атрибут AOGUID). Причем разные объекты могут иметь одинаковые значения AOGUID, тогда «правильная» запись выбирается исходя из других атрибутов.
К примеру, там есть запись (4-ая по порядку) — ул. Адмирала Горшкова, находившаяся в городе Щербинка. К слову, город Щербика по базе до сих пор город, а вот согласно вики — поселение. Так вот изменилась это запись в сентябре прошлого года. С точки зрения логики, тогда эту запись и могли сделать исторической. И вопрос — как много документов, в которых эта улица все еще существует? Тут видимо надо пологаться из задачи, использовать CURRSTATUS или ACTSTATUS. В самом начале документации (не в описании таблицы) сказано следующее:
ACTSTATUS — определяет, является ли эта запись по адресному объекту актуальной на текущую дату (0 – не актуальный, 1- актуальный).
CURRSTATUS — «Статус актуальности в соответствии » с классификацией адресных элементов и адресных объектов. Содержит значение признака актуальности адресного элемента и объекта адресации
Из «смешного» я еще помню улицы, у которых родительскими объектами были другие улицы — но этого я быстро не найду. Да городской округ в качестве административно территориального деления, согласно закону (еще можно посмотреть здесь), городской округ — это муниципальное деление. В качестве примера — городской округ Егорьевский из Московской области (AOGUID: 96036cfc-7acb-4de8-9004-3ae4c1c232c0).
А вот с домами базы я не смотрел — не было острой необходимости в задаче но напугало наличие _ДВУХ_ баз про дома HOUSE и HOUSEINT. Выдержка из документации:
Таблица HOUSE (House) содержит записи с номерами домов улиц, элементов планировочной структуры, городов и населенных пунктов. При выгрузке сведений по домам в формате DBF именам файлов присваиваются имена HOUSE01 – HOUSE99, где 01-99 коды регионов в соответствии с Приложением 3.
Таблица HOUSEINT (HouseInterval) содержит записи с интервалами домов улиц городов и населенных пунктов.
PS актуальность — от позднелат. actualis — фактически существующий, настоящий, современный =)
— Формат dbf — нормально прочитать его в Python у меня не получилось, оптугнуло вот что. Но разбор XML это тоже еще та головная боль. Файл ADDROBJ занимает больше 21 гигабайта, это значит прогонять через DOM — совсем не вариант
— Часть полей объявленных как обязательные, по факту отсутствуют. Другие (необязательные) — присутствуют всегда.
— Опираться на код КЛАДР для записей — плохо. Например ряд улиц из новой Москвы, проходят по AREACODE (входит в код кладр) как Подмосковье. При этом города, которым подчинены эти улицы, могут иметь уже другой AREACODE (то есть принадлежать другому региону).
— Необходимо учитывать ACTSTATUS (не CURRSTATUS) или использовать STARTDATE, ENDDATE, UPDATEDATE. Адресные объекты могут переименовываться, чтобы не копаться в истории — крайне важно искать только актуальные записи.
— Существующая отдельная база для «раскрытия» сокращений (SOCRBASE), т.е перевода из SHORTNAME 'г.' в 'Город', не содержит всех реально используемых сокращений в базе ADDROBJ
Я говорю не об этом. Мне приятней думать, что есть какая-то надежда на децентрализацию в вопросе доверия сертификатов. Что мы доверяем архитектуре/алгоритму/модели, нежели чем вот этим вот 3-5 организациям.
С новыми расширениями сертификатов тоже есть сложности. Есть (и всегда будет) старое ПО. Хотим мы или не хотим, но вопрос внедрения не может не занять множество лет. Я до сих пор в работе сталкиваюсь с Cisco PIX, редко, но сталкиваюсь. Так вот настройка этого «чуда» через браузер требует совсем старую JAVA и IE. Или вот, пример поближе VSphere 5.5 — вышел чуть меньше 4 лет назад, но требует Flash, который как мы знаем «выпиливается» из браузеров. С предлагаемыми расширениями, получится все тоже что и со всеми предыдущими — кто-то реализует, кто-то нет, кто-то реализует по своему. Это как внедрить очередной, 15-ый стандарт, который наконец объеденит все предыдущие (да, снова отсылка к Ренделу =) ). На мой взгляд, тут может сработать только принципиально новая идея (необязательно про блокчейн).
Вобщем все проблемы существующей инфраструктуры CA присутствуют и здесь. Идеально было бы избавиться от CA вообще.
Возможно, необязательно хранить всю базу локально. Ведь и сейчас при создания SSL-тунеля, в частности для проверки сертификата на отзыв, требуется обращение ко внешним ресурсам. Что если для проверки сертификатов обращаться к случайным узлам, в стиле p2p, может даже к узлам в сети onion/tor?
А для вопросов непосредственной реализации, достаточно чтобы этим заинтересовались Google и Mozilla =)
Хранение всех выданных сертификатов в блокчейне тоже имеет свои минусы, но идея, на мой взгляд, интересная.
Например, для планшета неважен телефонный номер — легко заменить сим карту. Поэтому тот, кто внедрит «новый -LTE» быстрее чем другие, получит больше «хайпу».
Или же вот, куда «перетекли» абоненты Билайна — к конкурентам.
А для своих библиотек правильне было бы использовать extern «C».