> Библиотеки — это уже готовые решения, часто проверенные временем и имеют известные заранее условия использования и ограничения. Т.е. такие решения более надежны чем копи-паст т.к. можно заранее узнать подойдет оно или нет.
Библиотеки — это комплексные решения. Они состоят из мелких, которые и решаются на stackoverflow. После того, как решение найдено, можно вполне погуглить по его использованию и найти его сторонников и противников, а также оценить его «проверенность временем».
> Не всегда чьё-то решение подойдет в конкретной ситуации, один фиг надо будет углублятся и до конца раскрутить скопированный алгоритм — экономия по времени лишь скорость набивки текста, и это в лучшем случае если решение на 100% подошло сразу без правок.
Если вы пытаетесь найти в инете целиком проект под ваше ТЗ, чтобы вообще ничего не писать, то да скорее всего что-то да не подойдет по вашу ситуацию :)
Я постоянно ищу и заимствую мелкие решения, абсолютно решающие мои проблемы.
По XSLT, например, просто десятки решений было найдено.
> SODD (StackOverflow Driven Development) в своей массе характеризует, что разработчик не способен к исследованию проблемы/задачи в глубину.
У вас какая конечная цель? Самоутвердится тем, что вы смогли найти решение своими умозаключениями или решить задачу правильно и в короткие сроки? Возможно, некоторые эти цели пытаются совместить, но я скорее больше ко второй. Я не говорю о том, что нужно применить абсолютный копипаст со stackoverflow, но ознакомиться с имеющимися там решениями и возможно позаимствовать наиболее подходящие — по-моему это логично. Очевидно, что если решение уже есть, выдумывание его с нуля никак не может быть эффективнее, чем просто позаимствовать.
> Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Я использую PHP и Perl. Отладка одной ситуации занимает секунды. У вас похоже JAVA, сожалею :)
> Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Вещь может и полезная, но как я уже сказал, это выпадение из рабочего времени. Действительно ли время, потраченное на codereview эффективнее, чем плановая работа? В моем опыте таких codereview не было. А уж исправление опечаток — лично у меня этим занимается IDE и тесты. Это абсолютно автоматизированная часть, глупо тратить на нее человеческий ресурс.
> вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
Знание алгоритмов нужно. А в чем принципиальное отличие библиотек от решений на stackoverflow? Библиотеки — это те же самые решения сторонних разработчиков. Вы почему-то их четко разделяете, прямо кодовый рассизм какой-то :)
> Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение.
Среди таковых причин вижу:
— программирование без компьютера и электричества, в условиях апокалипсиса, либо прочий форс-мажор (в виду низкой вероятности и неработоспособности всех систем в такой ситуации, навык не очень пригодится скорее всего)
— программирование для устаревших платформ (вместо читабельного кода видим набор нулей и единиц) — также сочту малополезным навыком в маловероятной ситуации
В целом я согласен с вами, что хоть какой-то навык чтения кода у программиста быть должен. Судя по моему опыту, достаточный навык внимательности имеется у любого умственно здорового программиста. Возможно, мой опыт излишне оптимистичен…
Почему я так негодую при виде слишком большого внимания по мелочам, т.к. это нерациональная трата времени. Большое внимание к мелким деталям при беседе с кандидатом можно сравнить со странным процессом чтения книги — вместо того, чтобы понять смысл, мы читаем отдельные слова из середины книги и пытаемся найти в них опечатки. Вы отлично ознакомитесь с «буквенным» составом книги, но не вынесите никакого реального опыта.
На мой взгляд правильнее не грузить людей деталями, а начать с общего — какие проекты делали и каким образом. Далее, если потребуется можно уточнить детали реализации и копнуть по мелочам — так хотя бы собеседование будет выглядеть относительно адекватным (говорю, как кандидат с большим опытом :)).
> — собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Забавно. Один и тот же пункт мы с вами совершенно по-разному оцениваем. В виду того, что copy+paste позволяет решить задачу в разы быстрее, а мозг оставить более свежим, я считаю copy+paste очевидным плюсом при работе. Конечно же при условии, что программа оттестирована и работает правильно.
> code review: практика вообще целиком про это
Имхо, более бессмысленная трата времени кроме codereview — совещания на общие темы.
Причем эмоционально codereview даже хуже пустых совещаний, т.к. codereview это заведомо эмоционально негативная процедура, при которой код некого автора подвергается глубокому досмотру с целью выявлений того, что наблюдатели могут счесть «проблемами» и скорее всего хотя бы одна «проблема» будет найдена. За время, потраченное на codereview время нескольких человек будет заморожено, кроме того сам исследуемый код не получит серьезных продвижений, будет лишь дан ответ на вопрос, устраивает ли он наблюдателей или нет :)
Наличие самой процедуры говорит о проблемах в организации работы, т.к. любые возникающие проблемы или спорные вопросы логично решить до написания кода, на не после. Если перенести сodereview в область самого программирование, то оно выглядит как строительство костылей вместо масштабного рефакторинга.
> Попытки давать кандидатам олимпиадные задачки по программированию, или задачки из книжки «Математические головоломки», у меня, как правило, ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы затем снизить предложение по зарплате.
Наконец-то кто-то выразил мою давно выработанную мысль. Я бы даже ещё снизил планку и всевозможные технические детали вида «а как называется функция, которой можно сделать то-то» записал в ту же сторону маразма.
Зачем вообще по жизни может пригодиться решение головоломок в коде? Вставил код по частям в отладчик — и всё очевидно.
Открыл мануал по языку и нашёл любую ф-цию за секунды.
Прозрачно намекаю, что если человеку и удасться успешно отвечать на подобного рода вопросы, то для практической работы эти навыки не несут никакого смысла.
Подключал как-то систему Альфа-клик, работал с девел-инсталляцией, но ситуация была такая же — все платежи всех магазинов были видны в одной таблице. Повторюсь, девел. Да продакшна кстати так и не дошло.
Не стоит кидаться в меня камнями. Я не говорю, что выбор решения неправильный, статья неинтересная или что-то в этом духе.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.
Похоже, имело место быть сканирование и того и другого:
Радужная оболочка глаза
Технология распознавания радужной оболочки глаза была разработана для того, чтобы свести на нет навязчивость сканирования сетчатки глаза, при котором используются инфракрасные лучи или яркий свет. Ученые также провели ряд исследований, которые показали, что сетчатка глаза человека может меняться со временем, в то время как радужная оболочка глаза остается неизменной. И самое главное, что невозможно найти два абсолютно идентичных рисунка радужной оболочки глаза, даже у близнецов.
Для получения индивидуальной записи о радужной оболочке глаза черно-белая камера делает 30 записей в секунду. Еле различимый свет освещает радужную оболочку, и это позволяет видеокамере сфокусироваться на радужке. Одна из записей затем оцифровывается и сохраняется в базе данных зарегистрированных пользователей. Вся процедура занимает несколько секунд, и она может быть полностью компьютеризирована при помощи голосовых указаний и автофокусировки.
В аэропортах, например, имя пассажира и номер рейса сопоставляются с изображением радужной оболочки, никакие другие данные не требуются. Размер созданного файла, 512 байт с разрешением 640 х 480, позволяет сохранить большое количество таких файлов на жестком диске компьютера.
Очки и контактные линзы, даже цветные, никак не повлияют на процесс получения изображения. Также нужно отметить, что произведенные операции на глазах, удаление катаракты или вживление имплантатов роговицы не изменяют характеристики радужной оболочки, её невозможно изменить или модифицировать. Слепой человек также может быть идентифицирован при помощи радужной оболочки глаза. Пока у глаза есть радужная оболочка, её хозяина можно идентифицировать.
Камера может быть установлена на расстоянии от 10 см до 1 метра, в зависимости от сканирующего оборудования. Термин «сканирование» может быть обманчивым, так как в процессе получения изображения проходит не сканирование, а простое фотографирование.
Радужная оболочка по текстуре напоминает сеть с большим количеством окружающих кругов и рисунков, которые могут быть измерены компьютером. Программа сканирования радужной оболочки глаза использует около 260 точек привязки для создания образца. Для сравнения, лучшие системы идентификации по отпечаткам пальцев используют 60-70 точек.
Стоимость всегда была самым большим сдерживающим моментом перед внедрением технологии, но сейчас системы идентификации по радужной оболочке становятся более доступными для различных компаний. Сторонники технологии заявляют о том, что распознавание радужной оболочки глаза очень скоро станет общепринятой технологией идентификации в различных областях.
Методы
Ранее в биометрии имел применение рисунок кровеносных сосудов на сетчатке глаза. В последнее время этот метод распознавания не применяется, так как кроме биометрического признака несет в себе информацию о здоровье человека.
Также, данный проект создает в вебе скрипты с произвольным, заданным в POST контентом. Вряд ли данный скрипт кто-то захочет размещать у себя, тем более что его исходники вы сами выложили в свободный доступ. И теперь достаточно только знать сайты, где это могло быть размещено и послав к этим сайтам парочку запросов курлом, разместить там любой свой код. Советую вам скорее это исправить.
<?php
$from = array("`","~","!","@","#","$","%","^","&","*","(",")","-","=","+","\\","|","?","/",",",";",":","№","'","\"",".");
$_POST['args']['script'] = str_replace($from, '_', $_POST['args']['script']);
$_POST['args']['script'] = preg_replace('/\_+/','_', $_POST['args']['script']);
if($_POST['args']['script']!='_'&&$_POST['args']['script']){
$src = fopen(PDT_WORKING_DIR.'/scripts/'.$_POST['args']['script'].'.php','w');
fwrite($src, '<?php
// Содержимое скрипта
?>');
echo json_encode(array('script'=>$_POST['args']['script']));
}else{
echo json_encode(array('error'=>'В названии скрипта не должно быть спецсимволов, имя не может быть пустой строкой'));
}
?>
Недавно я задавал в q/a именно такой вопрос, который вы пытались решить. Почитайте, там местная публика предложила целую россыпь замечательных решений — habrahabr.ru/qa/34957/
Нет, а что тут странного? Чтобы написать код, нужно сначала подумать. И вовсе необязательно это время убивать глаза перед монитором.
Кроме того, когда работа происходит не на конвеере, а над некоторым постоянным кол-вом проектов, то постоянное написание кода вовсе выглядит довольно глупо. В этом случае скорее выполняется аналитика и примерка новых решений и технологий на проекты, что тоже мало связано с написанием кода.
> И, знаете что? Я не понимаю, как такой компании, с такими ресурсами и таким опытом проектирования интерфейсов, хватает совести брать за это деньги.
Если честно, не одобряю гугло-дизайн и в его веб-интерфейсах, примерно с времен гугло-плюса. Тогда же они примерно и дизайн почты переделали — убрали многие функции во всплывающее меню; при каждом втором входе (а вхожу я не так чтобы очень часто), тыкают носом в какую-то фичу. Гугл-плюс не удался и черт с ним, но весь его дурацкий подход к проектировке интерфейса перетянули в почту :(
Вы описали проблему, с которой столкнулись при использовании CI. А какие преимущества он дал? Может быть его использование не оправдано и проще написать полностью «свой» код, и не тратить время на борьбу с ПО сторонних разработчиков?
Вы ответили настолько общей фразой, что не понятно — одобрили или возразили :)
Просто странно, что вы сами пишете «забыл where» из чего делаете выводы о том, что нужно проверять запрос, добавлять limit и использовать phpMyAdmin. Вот и удивляет, почему из ошибки «забыл where» не сделать вывод «писать where первично». :)
А вообще в описанной вами ситуации плохо абсолютно всё, что вы упомянали.
Более похожая на суровые промышленные реалии ситуация обновления данных должна выглядеть вот так:
1. У вас должна быть копия продакшновских данных где-то в стороне. Для вас это вполне реализуемая ситуация, ведь вы предлагаете делать дамп перед запросом. Почему именно перед запросом? Настройте постоянно работающую репликацию на пару других серверов. Эти сервера кроме возможности проводить на одном из них эксперименты с данными, будут вам и источником свежайшего бекапа и подпоркой в случае падения основного сервера.
2. Вы сначала пишете запрос с SELECT тех данных, которые хотите обновить. Запускаете его с EXPLAIN, чтобы оценить насколько данная выборка будет тяжелой для сервера, каковы вероятности залочить таблицы надолго. Исходя из результатов, оптимизируете.
После оптимизации, запускаете запрос на селект на реплике (чтобы не мучать продакшн). И внимательно изучаете то, действительно ли это те данные, которые вам нужны. Если данных много, можно не каждую строку конечно сверять, а прикинуть кол-во записей, отдельные их признаки и пару тройку строк-таки проверить.
3. По результатам пункта 2 вы пишете не запрос, а скрипт на любом удобном ЯП, желательно на том же, на котором работает проект. Почему именно скрипт?
Потому что операция обновления данных слишком рискованная, вы это сами поняли, она должна быть выполнена аккуратно и с предварительными проверками. От апдейта строк одним запросом лучше отказаться. Лучше выполнить селект из пункта 2, потом пройтись по всем строкам в цикле и для каждой строки выполнить проверку на то, что она действительно должна быть обновлена. И если строка подходит — обновить. И, разумеется вся работа скрипта должна внутри транзакции. с BEGIN первым запросом и COMMIT последним. Перед последним COMMIT желательно также поместить проверку на адекватность данных. Для оптимальной работы транзакций без блокировки всей таблицы, у таблиц должен быть engine=InnoDb. MyISAM (стандартный движок) позволяет только лочить таблицу целиком.
4. Полученный скрипт запустить на одной из реплик, проверить результат на адекватность.
5. Если пункт 4 успешен, перейти к обновлению продакшна. При чем заметьте, подготовленный выше скрипт написан так, что чтобы его выполнить не нужно разбираться в структуре БД и выполнять какие-то дополнительные проверки. Этот скрипт может быть передан как часть нового релиза системы различным клиентам, которые используют ваш софт, или вашим коллегам, которые накатывают обновления.
Зависит от уровня культуры ваших соседей. Поверьте, это всё равно лучше, чем Москва. Моя мама, оставшаяся жить там, снимает гараж за 15 тр в месяц и это не из роскоши.
Мне как-то повезло с очень большим, грамотно расширенным двором и нахождением поблизости объектов инфраструктуры вместо жилых домов и пустырей (будущих жилых домов :) ) — приток автолюбителей наблюдается только из жителей моего же дома, который построен в 70х годах и контенгент давно устоявшийся. Хотя не спорю — во многих, даже соседних дворах бывает совсем наоборот.
Видимо, каждый кулик своё болото хвалит. Чтож и я позвалюсь. 7 лет назад мигрировал из Мск в Спб. Крайне доволен — работы для IT завались, жизнь раз в 500 комфортнее и раза в 2 дешевше. Оформился в местный военкомат, решил проблемы за копеечные цены по сравнению с Мск. Купил авто, имею возможность бесплатно и безболезненно парковать его возле дома (с чем в Мск огромные проблемы были), и маршрут до работы составляет ~ 40 минут (при том, что другой конец города). Климат, правда не рекомендую, но зато от дома до Финского города Иматра 4 часа автомобильного пути. Шенген выдают сроком действия на 1 год, 180 дней пребывания. А по Шенгену можно в любую страну ЕС. Т.е. ровно половину времени можно проводить в ЕС. На сдачу квартиры в спальном районе Мск можно снять 2 квартиры в Спб — 1 в центре и одну на окраине. Правда, сюда тоже огромная миграция и с некоторым трудом удалось ребенка отправить в детский сад, хотя район у нас не самый застраиваемый.
Библиотеки — это комплексные решения. Они состоят из мелких, которые и решаются на stackoverflow. После того, как решение найдено, можно вполне погуглить по его использованию и найти его сторонников и противников, а также оценить его «проверенность временем».
Если вы пытаетесь найти в инете целиком проект под ваше ТЗ, чтобы вообще ничего не писать, то да скорее всего что-то да не подойдет по вашу ситуацию :)
Я постоянно ищу и заимствую мелкие решения, абсолютно решающие мои проблемы.
По XSLT, например, просто десятки решений было найдено.
У вас какая конечная цель? Самоутвердится тем, что вы смогли найти решение своими умозаключениями или решить задачу правильно и в короткие сроки? Возможно, некоторые эти цели пытаются совместить, но я скорее больше ко второй. Я не говорю о том, что нужно применить абсолютный копипаст со stackoverflow, но ознакомиться с имеющимися там решениями и возможно позаимствовать наиболее подходящие — по-моему это логично. Очевидно, что если решение уже есть, выдумывание его с нуля никак не может быть эффективнее, чем просто позаимствовать.
> Про использование дебаггера и проверка корректности кода — каждый раз в дебаггере прогонять? Сколько же разработка длится? Годы? Не говоря уже про многопоточность.
Я использую PHP и Perl. Отладка одной ситуации занимает секунды. У вас похоже JAVA, сожалею :)
> Codereview это настолько полезная вещь, начиная от устранения мелких ачипяток до каких-то более концептуальных проблем, как, например, не полное понимание работы какого-то отдельного механизма взаимодействия системы, задачи и т.п.
Вещь может и полезная, но как я уже сказал, это выпадение из рабочего времени. Действительно ли время, потраченное на codereview эффективнее, чем плановая работа? В моем опыте таких codereview не было. А уж исправление опечаток — лично у меня этим занимается IDE и тесты. Это абсолютно автоматизированная часть, глупо тратить на нее человеческий ресурс.
> вам не нужно ни знание алгоритмов, библиотек, принципов работы и code review вам не поможет.
Знание алгоритмов нужно. А в чем принципиальное отличие библиотек от решений на stackoverflow? Библиотеки — это те же самые решения сторонних разработчиков. Вы почему-то их четко разделяете, прямо кодовый рассизм какой-то :)
> Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение.
Среди таковых причин вижу:
— программирование без компьютера и электричества, в условиях апокалипсиса, либо прочий форс-мажор (в виду низкой вероятности и неработоспособности всех систем в такой ситуации, навык не очень пригодится скорее всего)
— программирование для устаревших платформ (вместо читабельного кода видим набор нулей и единиц) — также сочту малополезным навыком в маловероятной ситуации
В целом я согласен с вами, что хоть какой-то навык чтения кода у программиста быть должен. Судя по моему опыту, достаточный навык внимательности имеется у любого умственно здорового программиста. Возможно, мой опыт излишне оптимистичен…
Почему я так негодую при виде слишком большого внимания по мелочам, т.к. это нерациональная трата времени. Большое внимание к мелким деталям при беседе с кандидатом можно сравнить со странным процессом чтения книги — вместо того, чтобы понять смысл, мы читаем отдельные слова из середины книги и пытаемся найти в них опечатки. Вы отлично ознакомитесь с «буквенным» составом книги, но не вынесите никакого реального опыта.
На мой взгляд правильнее не грузить людей деталями, а начать с общего — какие проекты делали и каким образом. Далее, если потребуется можно уточнить детали реализации и копнуть по мелочам — так хотя бы собеседование будет выглядеть относительно адекватным (говорю, как кандидат с большим опытом :)).
> — собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Забавно. Один и тот же пункт мы с вами совершенно по-разному оцениваем. В виду того, что copy+paste позволяет решить задачу в разы быстрее, а мозг оставить более свежим, я считаю copy+paste очевидным плюсом при работе. Конечно же при условии, что программа оттестирована и работает правильно.
> code review: практика вообще целиком про это
Имхо, более бессмысленная трата времени кроме codereview — совещания на общие темы.
Причем эмоционально codereview даже хуже пустых совещаний, т.к. codereview это заведомо эмоционально негативная процедура, при которой код некого автора подвергается глубокому досмотру с целью выявлений того, что наблюдатели могут счесть «проблемами» и скорее всего хотя бы одна «проблема» будет найдена. За время, потраченное на codereview время нескольких человек будет заморожено, кроме того сам исследуемый код не получит серьезных продвижений, будет лишь дан ответ на вопрос, устраивает ли он наблюдателей или нет :)
Наличие самой процедуры говорит о проблемах в организации работы, т.к. любые возникающие проблемы или спорные вопросы логично решить до написания кода, на не после. Если перенести сodereview в область самого программирование, то оно выглядит как строительство костылей вместо масштабного рефакторинга.
Наконец-то кто-то выразил мою давно выработанную мысль. Я бы даже ещё снизил планку и всевозможные технические детали вида «а как называется функция, которой можно сделать то-то» записал в ту же сторону маразма.
Зачем вообще по жизни может пригодиться решение головоломок в коде? Вставил код по частям в отладчик — и всё очевидно.
Открыл мануал по языку и нашёл любую ф-цию за секунды.
Прозрачно намекаю, что если человеку и удасться успешно отвечать на подобного рода вопросы, то для практической работы эти навыки не несут никакого смысла.
Мой вопрос был не совсем точен. Я хотел спросить, почему вы используете SOAP, а не любое другое решение, какие преимущества?
Работал с SOAP долгое время, трудозатраты достаточно большие на рутину.
Та же поддержка WSDL в актуальном состоянии.
А если WSDL генерить автоматом и оно будет меняться при любом изменении в коде, как сделал коллега из первого комментария, то какой в нем смысл? В этом случае проще упразднить WSDL и весь SOAP и перейти к чему-то более лёгкому.
Из-за высказанных проблем по трудозатратам в поддержке, решил отказаться в пользу более простого и легкого самодельного JSON-based протокола. SOAP использую только если есть необходимость в нём самом. Если же задача стоит в обеспечении взаимодействия, а выбор протокола на усмотрение, то я бы SOAP реализовывать не стал.
Стало интересно, каковы ньюансы протокола, из-за которых вы его выбрали и которые вы считаете достоинствами, о чем и был изначальный вопрос.
Радужная оболочка глаза
Технология распознавания радужной оболочки глаза была разработана для того, чтобы свести на нет навязчивость сканирования сетчатки глаза, при котором используются инфракрасные лучи или яркий свет. Ученые также провели ряд исследований, которые показали, что сетчатка глаза человека может меняться со временем, в то время как радужная оболочка глаза остается неизменной. И самое главное, что невозможно найти два абсолютно идентичных рисунка радужной оболочки глаза, даже у близнецов.
Для получения индивидуальной записи о радужной оболочке глаза черно-белая камера делает 30 записей в секунду. Еле различимый свет освещает радужную оболочку, и это позволяет видеокамере сфокусироваться на радужке. Одна из записей затем оцифровывается и сохраняется в базе данных зарегистрированных пользователей. Вся процедура занимает несколько секунд, и она может быть полностью компьютеризирована при помощи голосовых указаний и автофокусировки.
В аэропортах, например, имя пассажира и номер рейса сопоставляются с изображением радужной оболочки, никакие другие данные не требуются. Размер созданного файла, 512 байт с разрешением 640 х 480, позволяет сохранить большое количество таких файлов на жестком диске компьютера.
Очки и контактные линзы, даже цветные, никак не повлияют на процесс получения изображения. Также нужно отметить, что произведенные операции на глазах, удаление катаракты или вживление имплантатов роговицы не изменяют характеристики радужной оболочки, её невозможно изменить или модифицировать. Слепой человек также может быть идентифицирован при помощи радужной оболочки глаза. Пока у глаза есть радужная оболочка, её хозяина можно идентифицировать.
Камера может быть установлена на расстоянии от 10 см до 1 метра, в зависимости от сканирующего оборудования. Термин «сканирование» может быть обманчивым, так как в процессе получения изображения проходит не сканирование, а простое фотографирование.
Радужная оболочка по текстуре напоминает сеть с большим количеством окружающих кругов и рисунков, которые могут быть измерены компьютером. Программа сканирования радужной оболочки глаза использует около 260 точек привязки для создания образца. Для сравнения, лучшие системы идентификации по отпечаткам пальцев используют 60-70 точек.
Стоимость всегда была самым большим сдерживающим моментом перед внедрением технологии, но сейчас системы идентификации по радужной оболочке становятся более доступными для различных компаний. Сторонники технологии заявляют о том, что распознавание радужной оболочки глаза очень скоро станет общепринятой технологией идентификации в различных областях.
Методы
Ранее в биометрии имел применение рисунок кровеносных сосудов на сетчатке глаза. В последнее время этот метод распознавания не применяется, так как кроме биометрического признака несет в себе информацию о здоровье человека.
ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BE%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8#.D0.A0.D0.B0.D0.B4.D1.83.D0.B6.D0.BD.D0.B0.D1.8F_.D0.BE.D0.B1.D0.BE.D0.BB.D0.BE.D1.87.D0.BA.D0.B0_.D0.B3.D0.BB.D0.B0.D0.B7.D0.B0
Вот здесь возможна уязвимость с инклюдом произвольного php-файла.
Также, данный проект создает в вебе скрипты с произвольным, заданным в POST контентом. Вряд ли данный скрипт кто-то захочет размещать у себя, тем более что его исходники вы сами выложили в свободный доступ. И теперь достаточно только знать сайты, где это могло быть размещено и послав к этим сайтам парочку запросов курлом, разместить там любой свой код. Советую вам скорее это исправить.
Недавно я задавал в q/a именно такой вопрос, который вы пытались решить. Почитайте, там местная публика предложила целую россыпь замечательных решений — habrahabr.ru/qa/34957/
Не сетчатки, а роговицы. Сетчатку если можно просканировать, то всего один раз.
Кроме того, когда работа происходит не на конвеере, а над некоторым постоянным кол-вом проектов, то постоянное написание кода вовсе выглядит довольно глупо. В этом случае скорее выполняется аналитика и примерка новых решений и технологий на проекты, что тоже мало связано с написанием кода.
Если честно, не одобряю гугло-дизайн и в его веб-интерфейсах, примерно с времен гугло-плюса. Тогда же они примерно и дизайн почты переделали — убрали многие функции во всплывающее меню; при каждом втором входе (а вхожу я не так чтобы очень часто), тыкают носом в какую-то фичу. Гугл-плюс не удался и черт с ним, но весь его дурацкий подход к проектировке интерфейса перетянули в почту :(
Просто странно, что вы сами пишете «забыл where» из чего делаете выводы о том, что нужно проверять запрос, добавлять limit и использовать phpMyAdmin. Вот и удивляет, почему из ошибки «забыл where» не сделать вывод «писать where первично». :)
А вообще в описанной вами ситуации плохо абсолютно всё, что вы упомянали.
Более похожая на суровые промышленные реалии ситуация обновления данных должна выглядеть вот так:
1. У вас должна быть копия продакшновских данных где-то в стороне. Для вас это вполне реализуемая ситуация, ведь вы предлагаете делать дамп перед запросом. Почему именно перед запросом? Настройте постоянно работающую репликацию на пару других серверов. Эти сервера кроме возможности проводить на одном из них эксперименты с данными, будут вам и источником свежайшего бекапа и подпоркой в случае падения основного сервера.
2. Вы сначала пишете запрос с SELECT тех данных, которые хотите обновить. Запускаете его с EXPLAIN, чтобы оценить насколько данная выборка будет тяжелой для сервера, каковы вероятности залочить таблицы надолго. Исходя из результатов, оптимизируете.
После оптимизации, запускаете запрос на селект на реплике (чтобы не мучать продакшн). И внимательно изучаете то, действительно ли это те данные, которые вам нужны. Если данных много, можно не каждую строку конечно сверять, а прикинуть кол-во записей, отдельные их признаки и пару тройку строк-таки проверить.
3. По результатам пункта 2 вы пишете не запрос, а скрипт на любом удобном ЯП, желательно на том же, на котором работает проект. Почему именно скрипт?
Потому что операция обновления данных слишком рискованная, вы это сами поняли, она должна быть выполнена аккуратно и с предварительными проверками. От апдейта строк одним запросом лучше отказаться. Лучше выполнить селект из пункта 2, потом пройтись по всем строкам в цикле и для каждой строки выполнить проверку на то, что она действительно должна быть обновлена. И если строка подходит — обновить. И, разумеется вся работа скрипта должна внутри транзакции. с BEGIN первым запросом и COMMIT последним. Перед последним COMMIT желательно также поместить проверку на адекватность данных. Для оптимальной работы транзакций без блокировки всей таблицы, у таблиц должен быть engine=InnoDb. MyISAM (стандартный движок) позволяет только лочить таблицу целиком.
4. Полученный скрипт запустить на одной из реплик, проверить результат на адекватность.
5. Если пункт 4 успешен, перейти к обновлению продакшна. При чем заметьте, подготовленный выше скрипт написан так, что чтобы его выполнить не нужно разбираться в структуре БД и выполнять какие-то дополнительные проверки. Этот скрипт может быть передан как часть нового релиза системы различным клиентам, которые используют ваш софт, или вашим коллегам, которые накатывают обновления.
По-моему решение проблемы раскрывается в ее постановке — сначала внимательно напишите where, а потом допишите первую часть запроса.