- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
if(isset($_POST['btnsubmitup']))
{
for ($i = "0"; Arr::get($_POST, 'id'.$i, ''); $i++) {
if (Arr::get($_POST, 'up'.$i, '') == '1') {
$p1=-1;
// $uploaddir = '/img/brands/';
$a = Arr::get($_POST, 'id'.$i, '');
// $p1 = Upload::save($_FILES['photo'.$i], $uploaddir.$a.'.jpg', './', 0777);
$rand=rand(1000000,9999999);
$uploaddir = '/img_carpets/collection/';
$uploaddir2 = 'img_carpets/collection/';
$p1 = Upload::save($_FILES['file1'.$i], $uploaddir.'ID-'.$rand.'-1.jpg', './', 0777);
$p2 = Upload::save($_FILES['file2'.$i], $uploaddir.'ID-'.$rand.'-2.jpg', './', 0777);
$p3 = Upload::save($_FILES['file3'.$i], $uploaddir.'ID-'.$rand.'-3.jpg', './', 0777);
$p4 = Upload::save($_FILES['file4'.$i], $uploaddir.'ID-'.$rand.'-4.jpg', './', 0777);
// if ($p1!="0") { $p1=$rand; }
// if ($p2!="0") { $p2=$rand; }
// if ($p3!="0") { $p3=$rand; }
// if ($p4!="0") { $p4=$rand; }
$im2=Image::factory($uploaddir2.'back.png');
// -> и так далее
Начал разбирать библиотеку (фреймворк скорее - kohanaframework) одного сайта, дабы сделать нормальную админку
Дошел до процедуры сохранения картинок. Я посмотрел, по какому же алгоритму сохраняются картинки (формирование имени файла)
И опупел!
** $rand=rand(1000000,9999999); **
В базе поле для сохранения имени картинки - не уникально.
Т.е., разраб решил поиграть в рулетку, анука генератор чисел выберет еще раз одно и то же число, и перезапишет картинку у товара. ))))
А оператор админки будет чесать репу - тут же работало а тут и нет )
Follow us!
А способ классный.
Ну и для большей эффективности можно рандом от 1 до макс. числа одновременно загружаемых картинок.
9999999-1000000=8999999
т.е. вероятность перезаписи = 1/8999999
или я чего-то не понимаю?
мне тервер преподавали давно и на пальцах, поэтому пускай люди со специальностью "математик" в дипломе меня поправят, может я несу пургу
вероятность, что мы ткнём пальцем в число и попадём уже использующееся = k/M, где k - количество уже использующихся, а M - размер множества
т.е. при 1000 фотографий из 10 млн один тык пальцем - всего то 1/10000 (0.01%, копейки ага?)
но дело принимает другой оборот, когда нам надо удостовериться, что каждое 1001 тыканье не приведет к фейлу (иначе какой в этом смысл)
считаю, что вероятность, что 1001 последовательное тыканье сфейлится будет равна
1 - (1 - p[0])*(1 - p[1])*..*(1 - p[k]), где p[i] = i/M (т.е. начинаем эксперимент с пустой папки)
для 1001 тыканья у меня получилось уже 4.88%
а для 10000 фотографий (из 10 миллионов то, свободных нумеров полно ведь) - 99.327%
1/8999999, 2/8999999, .... k/8999999
Парадокс дней рождений.
Тараса забанили.
а подразумевал я как раз того, кто прорецензировал мой пост
Ну не надо так категорично ;) В git'е тоже должна быть нулевая вероятность коллизии, но все смирились с 1/2^128 (с учетом парадокса ДР)...
P.S. Но 10^7 согласен, мало, да еще и rand() может оказаться хреново реализованным.
надо мигрировать на удобную vcs в конторе, немного разработчиков, никакой удалённой работы - svn или таки git?
всё что нужно (интеграция с ide - работа мышкой, консольный режим) есть в обеих, потому хочется дополнительных критериев
Быстрый, не нужно никакого специального сервера, хотя центральный репозиторий организовать не проблема
Можно редактировать историю (желательно только локальную, разумеется) через git rebase -i
В svn уж больно много раздражающих мелких косяков
Интеграция с MS VC есть у обоих svn плагин для VC мне не понравился, гитовский не видел
Можно ещё mercurial посмотреть, но IMHO git удобнее (хотя у hg интеграция с ОС более нативная)
Удобно делать мелкие коммиты у себя на машине, и отправлять на центральный сервер только готовую более-менее протестированную версию (меньше матов со стороны коллег, у которых после svn update код внезапно начинает работать некорректно).
Удобно работать с ветвями - создал ветвь, потестировал что-нибудь, не понравилось - откатил, никто ничего и не заметил. В svn же работа с ветвями это полная ж...
мы как то привыкшыя лаптями то
есть два подхода
первый - ты собрался редактировать файл(ы), чекаутишь их (обычно автоматом), делаешь что нужно и как только готов возвращать - чекинишь (минусы - никто в один клик не сможет работать с этими файлами, пока ты их не вернешь, если так уж надо параллельно работать над одним файлом, то надо делать больше кликов и больше ручной работы (курить диффы при заливке), плюсы - вообще не надо курить диффы, если ты чекаутил эксклюзивно)
второй - ты сливаешь себе копии, редактируешь их и потом куришь diffы при заливке назад (плюсы - все могут ковырять на своей машине всё что им вздумается, минусы - глаза не казенные при каждом чек-ине сверять диффы)
т.к. разработчиков не много, то разумное разделение ответственности вполне уживалось с первым подходом
но svn и git подразумевают второй
уважаемые знатоки, колхозница Даздраперма Ильинишна из села Глубокие Позывы интересуется, сложно ли при каждом коммите проверять диффы и можно ли как то автоматизировать процесс?
Если "разумное разделение ответственности", и каждый старается пилить свой независимый кусок - то можно даже не курить диффы. Если локальные и удаленные изменения коснулись друг друга - и git и svn предупредят, и заставят решить возникший конфликт.
ну и чтобы два раза не вставать
в рекламных буклетах TFS в красках расписывают о фиче "code review"
типа я могу выделить кусок кода и подсказать молодому сотруднику, куда ему надо сходить что ему надо исправить
в сабже есть что то подобное?
Это значит, что у каждого разработчика на самом деле локально есть полная копия репозитория, которая работает даже без доступа к сети. Когда он наковыряется со своей таской, наплодив кучу коммитов, он может слить изменения в "центральный" репозиторий (центральный только потому, что мы так решили, центром может быть любой репозиторий, они практически не зависимы). Это позволяет делать частые локальные коммиты без опасности кому-нибудь поднасрать.
> в сабже есть что то подобное
Есть, только для этого нужно установить соответсвующий интсрумент.
Для гита есть гугловский gerrit, есть ещё универсальный reviewboard. К сожалению, установка требует некоторых навыков.
репозиторий здесь имеется в виду то, что нужно только тебе для проекта, или всё, что армия говнокодеров успела насрать разработать за 15 лет существования конторы
или под каждый проект надо создавать некий обособленный репозиторий?
svn: ЕМНИП "чистая копия" версии, на которой основана локальная + сама локальная версия. Труды армии говнокодеров за 15 лет хранятся на сервере.
Общепринятый путь - хранить каждый проект в своём git-репозитории (например, каждая подсистема ядра linux лежит в своём репозитории). Это гораздо удобнее, чем хранить всё в одной большой куче. Для иерархических проектов есть фича submodules.
поэтому я как бы могу посмотреть клиентом огромную иерархию от корня $/...., но фактически в солюшене из 10 проектов внутри каждый проект просто привязан к своей конкретной папке в иерархии и при get этого проекта он сливает ровно то, что нужно, начиная с своей папки
весь старый мир никто разрушать до основанья не будет, вот я и пытаюсь уложить в своей голове, надо ли мне будет сливать ненужный код
видать вот эти вот submodules и выручат
У git'а - если последний коммит на сервере не является непосредственным предком коммита на локальной машине. (У него номеров версий как таковых нет).
"code review" - насчет этого не видел, скорее всего нет... Разве что внешние тулзы.
> если код не компиляется
страх какой
это же ведь отключается?
По дефолту все хуки пустые
естесственно эти вещи не интерферируют с основной веткой кода
ну а куда нибудь в .../sandbox проект уже положить охота
всё таки сервер бекапится регулярно, а моя машина - нет
потому и было бы невесело, если бы мне еще vcs лечила мозги, если код не компиляется (кстати, с++ это же джава ведь, чтобы за полсекунды проверить компиляеца или нет, хехе)
EDIT: А, выше уже об этом уже сказали, ну, и пусть говорят!