Комментарии 28
Нет в гите никакой «криптографии». Хеши это еще не криптография.
НЛО прилетело и опубликовало эту надпись здесь
> Хеши это еще не криптография
И да, что за «криптографический» хеш, и чем отличается от «не криптографического» — возьмётесь прояснить?
И да, что за «криптографический» хеш, и чем отличается от «не криптографического» — возьмётесь прояснить?
Почитайте Википедию :)
en.m.wikipedia.org/wiki/Hash_function
en.m.wikipedia.org/wiki/Cryptographic_hash_function
en.m.wikipedia.org/wiki/Hash_function
en.m.wikipedia.org/wiki/Cryptographic_hash_function
Как видим, криптографически стойкими считаются хеши с некоторыми «невнятными» свойствами вроде:
> it is infeasible to find two different messages with the same hash
Как известно, с помощью радужных таблиц шустро находятся коллизии и для таких хеш функций, которые вроде как считаются криптографически стойкими.
Так что «криптографическая стойкость» — характеристика относительная, и вполне возможно что временная (пока не нашли метод быстрого подбора, например).
> it is infeasible to find two different messages with the same hash
Как известно, с помощью радужных таблиц шустро находятся коллизии и для таких хеш функций, которые вроде как считаются криптографически стойкими.
Так что «криптографическая стойкость» — характеристика относительная, и вполне возможно что временная (пока не нашли метод быстрого подбора, например).
А как это относится к моему ответу на ваш вопрос?
вы путаете холодное с мягким
Продемонстрируйте нам коллизии хотя бы в SHA-1.
Я в курсе, что SHA-1 теоретически уязвим. Тем не менее, коллизий никто пока не нашел.
As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers.Ни о каком «шустром» нахождении коллизий речи не идет. Напрашивается простое определение — криптографическим считать такой хеш, который требует потратить не менее миллиона уе. на подбор одной коллизии.
я возьмусь, в таких структурах данных, как хеш таблицы используются, например, полиномиальные хеши, ничего общего с криптографическими (ну кроме ряда свойств типа постоянной длины) у них нет
а насчет Вашего первого утверждения согласен
а насчет Вашего первого утверждения согласен
Рискну предположить, что «криптографический хэш» исключает возможность расшифровки любой части исходных данных, в то время как обычный хэш может быть даже «сжать входные данные зипом и вернуть»
Спасибо, исправлено.)
Все что вы написали, безусловно полезно и здорово. Я даже положил в закладки, вдруг пригодится.
Но… где же вот это:
Где сам процесс внедрения? Сразу ли пришли к такой конфигурации или пробовали другие? Почему другие не подошли?
Как ко всему этому процессу относились коллеги? А руководство? Какие сложности были во время внедрения, на что обращать особое внимание? Ну т.п. и т.д.
Но… где же вот это:
Этот пост — желание поделиться опытом успешного внедрения непрерывной интеграции
Где сам процесс внедрения? Сразу ли пришли к такой конфигурации или пробовали другие? Почему другие не подошли?
Как ко всему этому процессу относились коллеги? А руководство? Какие сложности были во время внедрения, на что обращать особое внимание? Ну т.п. и т.д.
По-моему, полезность статьи стремится к нулю — если вы хотели рассказать про то, как круто использовать CI, вы опоздали; если вы хотели поделиться конкретным примером внедрения — вы статье нет никаких технических деталей, кроме названия продуктов, инстинктивно появляются такие вопросы, как «почему TeamCity, а не TFS или CruiseControl?», «а какие есть еще?»,…
То что мы внедрили, конкретно описано. Плюс в том, что проекты бесплатны, кроме TeamCity (он ограниченно бесплатен). Цель же, рассказать людям, что такие технологии есть и они отлично работают. Про них некоторые не знают, другие игнорируют. Статья больше направлена на менеджеров и молодые команды. В дальнейшем возможно опишем детали настройки и интеграции. Старались максимально простым языком обобщить и популяризовать.
testflightapp совсем дохлый стал, скорость никакая. Приложения скачиваться долго стали.
— Пользуетесь ли вы системой контроля версий?
— Можете ли вы собрать продукт за один шаг?
— Выполняете ли вы ежедневные билды?
Даже если ответ «да», он еще ничего не значит.
Качество на выходе еще никак не изменилось.
Конечно не изменилось :) Вот только о том что ваша часть приложения не работает вместе с Васиной вы узнаете уже завтра а не через пару недель (в лучшем случае).
Цель CI это отловить проблемы интеграции как можно раньше, а не улучшить общее качество продукта.
Кстати если перед тем как запушить код в центральный репозиторий вы сначала забираете из этого репозитория все изменения, потом полностью билдите программу (с инсталаяторами или deb — пакетами например), програняете все тесты, разворачиваете на на каком-нибудь enviroment, а затем делаете smoke tests — то у вас тоже есть CI как практика.
Цель CI это отловить проблемы интеграции как можно раньше, а не улучшить общее качество продукта.
Кстати если перед тем как запушить код в центральный репозиторий вы сначала забираете из этого репозитория все изменения, потом полностью билдите программу (с инсталаяторами или deb — пакетами например), програняете все тесты, разворачиваете на на каком-нибудь enviroment, а затем делаете smoke tests — то у вас тоже есть CI как практика.
Вот только о том что ваша часть приложения не работает вместе с Васиной вы узнаете уже завтра а не через пару недель (в лучшем случае).
Не-а. Я узнаю о том, что она не собирается, а не о том, что она не работает.
Как бы практика CI подразумевает запуск тестов, развертывание приложения и smoke тесты, так что проблемы интеграции вы как раз поймаете.
Прочитайте внимательно, что я цитирую. Про тесты там ни слова.
Эх ладно :) Специально полез в блог Joel чтобы посмотреть его объяснение чем хорош daly-build. Вот что он пишет:
Иногда при использовании системы контроля версий один разработчик случайно вносит изменения, которые нарушают нормальный ход сборки. Например, добавляет новый файл с исходным кодом, и на его машине всё компилируется просто замечательно, но при этом забывает поместить этот файл в репозиторий. Он гасит свою машину и в хорошем настроении идёт домой. Но после этого уже никто не может работать, и все вынуждены тоже идти по домам, причём в гораздо худшем настроении.
Качество продукта все еще не изменилось. Завтра этот разработчик придет на работу и получит по шее.
Нет, я не говорю, что CI бесполезен, просто надо понимать граничные условия его применимости.
И, кстати, для приведенного примера daily build бесполезен, нужен pre-checkin, чтобы некомпилирующийся код не мог попасть в репозиторий.
Нет, я не говорю, что CI бесполезен, просто надо понимать граничные условия его применимости.
И, кстати, для приведенного примера daily build бесполезен, нужен pre-checkin, чтобы некомпилирующийся код не мог попасть в репозиторий.
правильный CI еще решает задачу чистого environment, а не просто «какого-нибудь», не стоит об этом забывать.
Автор поста говорит: используйте TeamCity, GitHub и TestFlight и будет вам сверхаддитивный эффект. Это все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синергия с Сontinuous Integration