- 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); **
В базе поле для сохранения имени картинки - не уникально.
Т.е., разраб решил поиграть в рулетку, анука генератор чисел выберет еще раз одно и то же число, и перезапишет картинку у товара. ))))
А оператор админки будет чесать репу - тут же работало а тут и нет )
Tairesh 02.08.2012 11:06 # −4
А способ классный.
guest 03.08.2012 01:08 # 0
Ну и для большей эффективности можно рандом от 1 до макс. числа одновременно загружаемых картинок.
guest 03.08.2012 13:01 # 0
guest 03.08.2012 09:08 # 0
guest 03.08.2012 10:15 # 0
9999999-1000000=8999999
т.е. вероятность перезаписи = 1/8999999
или я чего-то не понимаю?
defecate-plusplus 03.08.2012 10:26 # +8
defecate-plusplus 03.08.2012 11:02 # +2
мне тервер преподавали давно и на пальцах, поэтому пускай люди со специальностью "математик" в дипломе меня поправят, может я несу пургу
вероятность, что мы ткнём пальцем в число и попадём уже использующееся = 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%
guest 03.08.2012 11:09 # −2
defecate-plusplus 03.08.2012 11:31 # +5
1/8999999, 2/8999999, .... k/8999999
roman-kashitsyn 03.08.2012 11:33 # +3
roman-kashitsyn 03.08.2012 11:13 # +4
Парадокс дней рождений.
defecate-plusplus 03.08.2012 11:41 # +1
vistefan 03.08.2012 12:58 # 0
Тараса забанили.
defecate-plusplus 03.08.2012 13:30 # +1
а подразумевал я как раз того, кто прорецензировал мой пост
bormand 03.08.2012 15:37 # +2
Ну не надо так категорично ;) В git'е тоже должна быть нулевая вероятность коллизии, но все смирились с 1/2^128 (с учетом парадокса ДР)...
P.S. Но 10^7 согласен, мало, да еще и rand() может оказаться хреново реализованным.
defecate-plusplus 03.08.2012 15:46 # +1
надо мигрировать на удобную vcs в конторе, немного разработчиков, никакой удалённой работы - svn или таки git?
всё что нужно (интеграция с ide - работа мышкой, консольный режим) есть в обеих, потому хочется дополнительных критериев
roman-kashitsyn 03.08.2012 16:00 # +1
Быстрый, не нужно никакого специального сервера, хотя центральный репозиторий организовать не проблема
Можно редактировать историю (желательно только локальную, разумеется) через git rebase -i
В svn уж больно много раздражающих мелких косяков
Интеграция с MS VC есть у обоих svn плагин для VC мне не понравился, гитовский не видел
Можно ещё mercurial посмотреть, но IMHO git удобнее (хотя у hg интеграция с ОС более нативная)
bormand 03.08.2012 16:08 # 0
Удобно делать мелкие коммиты у себя на машине, и отправлять на центральный сервер только готовую более-менее протестированную версию (меньше матов со стороны коллег, у которых после svn update код внезапно начинает работать некорректно).
Удобно работать с ветвями - создал ветвь, потестировал что-нибудь, не понравилось - откатил, никто ничего и не заметил. В svn же работа с ветвями это полная ж...
defecate-plusplus 03.08.2012 16:11 # 0
defecate-plusplus 03.08.2012 16:22 # +3
мы как то привыкшыя лаптями то
есть два подхода
первый - ты собрался редактировать файл(ы), чекаутишь их (обычно автоматом), делаешь что нужно и как только готов возвращать - чекинишь (минусы - никто в один клик не сможет работать с этими файлами, пока ты их не вернешь, если так уж надо параллельно работать над одним файлом, то надо делать больше кликов и больше ручной работы (курить диффы при заливке), плюсы - вообще не надо курить диффы, если ты чекаутил эксклюзивно)
второй - ты сливаешь себе копии, редактируешь их и потом куришь diffы при заливке назад (плюсы - все могут ковырять на своей машине всё что им вздумается, минусы - глаза не казенные при каждом чек-ине сверять диффы)
т.к. разработчиков не много, то разумное разделение ответственности вполне уживалось с первым подходом
но svn и git подразумевают второй
уважаемые знатоки, колхозница Даздраперма Ильинишна из села Глубокие Позывы интересуется, сложно ли при каждом коммите проверять диффы и можно ли как то автоматизировать процесс?
bormand 03.08.2012 16:27 # 0
Если "разумное разделение ответственности", и каждый старается пилить свой независимый кусок - то можно даже не курить диффы. Если локальные и удаленные изменения коснулись друг друга - и git и svn предупредят, и заставят решить возникший конфликт.
defecate-plusplus 03.08.2012 16:36 # 0
ну и чтобы два раза не вставать
в рекламных буклетах TFS в красках расписывают о фиче "code review"
типа я могу выделить кусок кода и подсказать молодому сотруднику, куда ему надо сходить что ему надо исправить
в сабже есть что то подобное?
roman-kashitsyn 03.08.2012 16:41 # 0
Это значит, что у каждого разработчика на самом деле локально есть полная копия репозитория, которая работает даже без доступа к сети. Когда он наковыряется со своей таской, наплодив кучу коммитов, он может слить изменения в "центральный" репозиторий (центральный только потому, что мы так решили, центром может быть любой репозиторий, они практически не зависимы). Это позволяет делать частые локальные коммиты без опасности кому-нибудь поднасрать.
> в сабже есть что то подобное
Есть, только для этого нужно установить соответсвующий интсрумент.
Для гита есть гугловский gerrit, есть ещё универсальный reviewboard. К сожалению, установка требует некоторых навыков.
defecate-plusplus 03.08.2012 16:45 # 0
репозиторий здесь имеется в виду то, что нужно только тебе для проекта, или всё, что армия говнокодеров успела насрать разработать за 15 лет существования конторы
или под каждый проект надо создавать некий обособленный репозиторий?
bormand 03.08.2012 16:47 # 0
svn: ЕМНИП "чистая копия" версии, на которой основана локальная + сама локальная версия. Труды армии говнокодеров за 15 лет хранятся на сервере.
roman-kashitsyn 03.08.2012 16:50 # 0
Общепринятый путь - хранить каждый проект в своём git-репозитории (например, каждая подсистема ядра linux лежит в своём репозитории). Это гораздо удобнее, чем хранить всё в одной большой куче. Для иерархических проектов есть фича submodules.
defecate-plusplus 03.08.2012 16:56 # 0
поэтому я как бы могу посмотреть клиентом огромную иерархию от корня $/...., но фактически в солюшене из 10 проектов внутри каждый проект просто привязан к своей конкретной папке в иерархии и при get этого проекта он сливает ровно то, что нужно, начиная с своей папки
весь старый мир никто разрушать до основанья не будет, вот я и пытаюсь уложить в своей голове, надо ли мне будет сливать ненужный код
видать вот эти вот submodules и выручат
bormand 03.08.2012 16:42 # 0
У git'а - если последний коммит на сервере не является непосредственным предком коммита на локальной машине. (У него номеров версий как таковых нет).
"code review" - насчет этого не видел, скорее всего нет... Разве что внешние тулзы.
bormand 03.08.2012 16:39 # 0
roman-kashitsyn 03.08.2012 16:29 # 0
defecate-plusplus 03.08.2012 16:40 # 0
> если код не компиляется
страх какой
это же ведь отключается?
roman-kashitsyn 03.08.2012 16:42 # 0
По дефолту все хуки пустые
bormand 03.08.2012 16:44 # +6
defecate-plusplus 03.08.2012 16:51 # 0
естесственно эти вещи не интерферируют с основной веткой кода
ну а куда нибудь в .../sandbox проект уже положить охота
всё таки сервер бекапится регулярно, а моя машина - нет
потому и было бы невесело, если бы мне еще vcs лечила мозги, если код не компиляется (кстати, с++ это же джава ведь, чтобы за полсекунды проверить компиляеца или нет, хехе)
bormand 03.08.2012 16:54 # 0
eth0 03.08.2012 20:43 # +1
bormand 03.08.2012 15:47 # 0
wvxvw 03.08.2012 11:44 # +2
EDIT: А, выше уже об этом уже сказали, ну, и пусть говорят!