<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
(0) Мария, спасибо за Базовый курс — прояснилось многое…
Я думаю, внутри уже слаженных команд и коллективов нечто agile-овское уже существует. Просто они не называют это так. И не всем разработчикам (и РП) охота систематизировать и анализировать свой опыт. Поэтому мало открытой информации «Agile в ИТ-проектах». А если каждый начнет писать о своем опыте, то у всех получится примерно одинаковый кейс. Один из тех кейсов, которые мне понравились
Гибкие контракты — потому что когда мы формулируем требования в процессе работы, мы не можем на старте знать весь объем работ. (как из этого выкручиваться — я уже писала в статье Контракты Agile: как заключать договора в условиях расползания содержания).
Бэклог в виде «хотелок» бизнес-заказчика, изменяемый на протяжении всего проекта — вместо ТЗ, написанного на старте
Готовность к переделкам — они сразу закладываются в стоимость контракта (хотите без переделок — работайте по водопаду, только тогда не грустите, что получили на выходе совершенно не то, что хотели)
Планирование по кусочкам — вместо планирования всего на старте
Если анализировать кейс Дмитрия Кирилкина, то у него речь идет о команде внутри крупной компании. Ему не пришлось столкнуться с гибкими контрактами — не было такого, чтобы он встречался с Заказчиками, предлагал им отказаться от ТЗ на старте и подписать рамочный договор без определения предстоящих объемов работ.
Если у кого уже имеется текущее сопровождение программного продукта, то внедрить принципы agile будет «само» естественным процессом, знать бы только тонкости…
А если внедрять новое и новому Заказчику, то придется очень постараться «внедрение» (с конечным результатом)
продать какпревратить в «сопровождение» (с бесконечным бэклогом).За статью спасибо! Есть над чем подумать…
Пустопорожняя трата времени, сил и денег, если только вы не занимаетесь впариванием лохам этой хрени.
Заглавный вопрос звучит как «полный бардак» или «обычный хаос». Всё прочее — очередной хайп вокруг модной штучки, пользы хорошо если ноль, а то и вред бывает.
Мария, помнится, в прошлые разы затруднилась привести конкретные истории успеха. Но хайп успешно собирается и пипл хавает.
(2) Эту тему чуть менее чем полностью раскрыл в своей лекции Роберт Мартин, один из авторов упомянутого тут иджайл манифеста. Есть тут , рекомендую.
(1)
А если внедрять новое и новому Заказчику, то придется очень постараться «внедрение» (с конечным результатом) продать как превратить в «сопровождение» (с бесконечным бэклогом).
Согласна, что во внутренних проектах принципы Agile реализовывать куда проще и органичнее, чем во внешних. Это мировой тренд, насколько мне известно, в тех же Штатах — та же фигня. Еще интересная тенденция — знаю несколько историй, когда в ходе проекта по Agile компания заказчик переманивала команду подрядчика к себе в штат, ибо так с ними проще оказывалось взаимодействовать. К удовлетворению своему и новоиспеченных сотрудников, и к огорчению руководства компании подрядчика (не то чтобы я за это агитировала — просто из песни слова не выкинешь).
Про «сопровождение» с «бесконечным бэклогом» — вопрос философский. На практике наоборот, «гибкое» внедрение часто можно остановить раньше, чем «развесистый» проект по водопаду — внедрить только реально нужные функциональные блоки, и забить на рюшечки. Так что рассуждать про то, что Agile способствует бесконечной работе примерно то же самое, что рассуждать о вреде компьютеров, смартфонов или Интернета — это инструмент, его можно повернуть в плюс, можно в минус, и вообще…
(4)
Это и без слова Agile сплошь и рядом. В двух франчах были случаи когда весь проектный отдел уходил к крупному клиенту который купил у них коробки и хотел делать проект. И работа будет выполнятся эффективней и дешевле для заказчика такое выйдет. Ну и специалисты будут работать только в твоей компании и в твоих интересах, а не размазываться на несколько проектов работая в интересах франча.
(3) Спасибо за ссылку, прочитала с большим интересом!
(4) я собственно за agile-технологии…
просто у нас Заказчики думают что покупая внедрение, получат законченное решение. А по факту выходит, что внедрение = сопровождение. И всегда после покупки программы (лицензии), настройки первоначальных данных, минимальной адаптации продукта — возникают новые и новые вопросы и хотелки… Внедрение плавно перетекает в сопровождение.
(7)
Заказчик хочет купить конечный результат, а получает процесс.
(6) На мой взгляд, тут помимо головняка с «дисциплинированными профессионалами» есть еще одни не менее важные грабли. Это ответ на вопрос — каким критериями должен удовлетворять проект, чтобы к нему можно было применить ту или иную методологию. А то внезапно окажется, что «гвоздь не от той стенки».
Если тянуть любимые вами сюда парусные метафоры — то куда мы собираемся идти — устроить на выходных клубные гонки по треугольникам или пройтись из Мурманска в Архангельск через горло Белого моря. Вроде все одно и то же, а на деле некоторые отличия все же есть.
(8) сам по себе программный продукт не может быть конечным результатом. это иллюзия.
он дорабатывается постоянно, добавляются новые пользователи как минимум — все равно сопровождение какое-никакое будет.
У ваших соседей на мисте давеча озвучивали уже
На старте проекта вы обсуждаете, какую стратегию выбрать — быстро спуститься с горы вон к той тёлке (mvp) или медленно спуститься и покрыть все стадо (waterfall). На практике вы будете медленно спускаться вон к той тёлке. Она будет убегать вначале, а потом окажется, что это овца. Вы назовёте это Эджайлом и сделаете доклад на конференции.
(10) А тебе что надо по существу? Рассказ о том, какой бардак начался в ЗАО «1С», когда там среди платформописателей внедрили эту хрень? Или о том, как я эн раз в своей жизни наблюдал сплошной вред за немаленькие деньги? Тебе «анти-суксесс сториз» нужны?
(13) выскажите свое любое мнение по существу вопроса.
эмоции изливать не стоит.
(14) Ну если из предыдущих высказываний моё мнение не ясно, то ещё раз: любая коммерциализированная обобщённая попытка упорядочения процесса, связанного с рабочим взаимодействием людей в ходе работы над различными задачами, требующая формализации и претендующая на роль универсального выигрышного решения, подкреплённая навязчивым пиаром, вредна и разрушительна и для коллектива, и для проекта. Любая, как ни назови. Потому что фломастеры слишком разные и специфика слишком велика в каждом случае. Общий подход — это сферический конь в вакууме, а не прагматика.
(14) Для вас отсутствие конкретики — не показатель? Спросите любого пиарщика от эйджил о конкретных примерах — вам ни-че-го не скажут. Отделаются общими словами, или сошлются на конфиденциальность, или расскажут поверхностно, а начнёшь копать — такие скелеты в шкафах обнаружатся, которые сводят всё к это к пшику за большие деньги.
(15) ок
(16) иду вам навстречу, вот много видео — смотрите их прежде, чем читать по ним статьи — так вернее будет
начните с Дмитрия Кирилкина
Блин. в (12) пост не сразу отобразился почему-то.
(12) Напоминает анекдот про консалтера. «….. И собаку из багажника верните, вы не знаете как выглядят овцы»
(20) Кстати, это один из моих любимых анекдотов!
(15)
Яков, +100500!
Я вообще уверена, что универсальных решений не существует. Мало того, если берут кривую команду, работающую в невнятных условиях над мутными проектами, и объявляют «теперь мы переходим на Agile» — то скорее всего это только добьет и без того не простую ситуацию. Дьявол в деталях, в том, чтобы ориентироваться какие конкретные сильные и слабые стороны в той или иной ситуации, и умение предлагать рабочие решения…
(22) А вот как доходит до конкретики, так внедрение эйджила сдувается, внедряющий сливается, а потом спрашивают уцелевших — а куда столько бабла ввалили и безо всякой пользы? и нет ответа.
Польза например здесь.
(22) Т.е. если все зафейлилось, то это не технология отстойная, а команда кривая и проекты мутные? Ну т.е. нужно сначала выпрямить команду и отфильтровать проекты?
(11)Agile используют для разработки программных продуктов но ни как ни для внедрения, используя эту методику при внедрении вы получите только проблемы и срывы проекта
(16) так общайтесь с практиками, а не пиарщиками
Количество балаболов, продающих эфемерную фигню за большие деньги, действительно зашкаливает. Но это не же значит, что подход плох. Это как с «все мужики — козлы!» — если девушка встречалась только с козлами, значит ли это что ВСЕ мужики козлы?
(27)
Согласна на все сто!!! Практически в любом деле есть балаболы, и есть те, кто делают дело (на самом деле, конечно же, не две крайности, а ось вдоль которой распределяется компетентность). И, очевидно, что нахвататься каких-то поверхностных знаний и про это гордо рассказывать (особенно в теме, которая мало знакома собеседникам) гораздо проще, чем действительно стать профессионалом и делать дело хорошо. Поэтому чисто статистически «балаболов» оказывается куда больше, чем «толковых реализаторов». Ну, и те, кто ведут реальные проекты и у кого все хорошо менее заинтересованы в PR’е, рекламе и пр., чем те, кто занимаются имитацией бурной деятельности. Поэтому вторых не только больше, они еще и заметнее. Так практически в любой деятельности происходит.
(25)
По моему опыту провалы заметно чаще случаются из-за команды или из-за руководства, а не из-за технологии.
Разговаривал недавно со саоим бывшим однокурсником на тему agile, он сейчас живет в Канаде (Торонто). Он сказал, что мы повторяем их зады 5-7 летней давности. Что agile давно не в тренде, поскольку:
1. Стимулирует разработчиков «двигать кнопки по экрану»
2. Разработчики банально разбегаются от этой «потогонной системы» из-за стресса.
(3) Отличная статья. По нему выходит, что agile — это дисциплина + технические практики.
В чем, на мой взгляд, глобальный недостаток Agile — в том, что никто не знает, когда закончится процесс. С точки зрения меня, как руководителя — это зло. Потому что когда я «отдаю» в команду Agile своих сотрудников — я могу ставить на них крест неизвестно на сколько времени, так как на все попытки загрузить их работой начинаются сентеции на тему того, что у нас проект, как долго продлится — никто не знает. В результате сотрудники, занятые на Agile — проектах выпадают напрочь из рабочего процесса. И не известно, на сколько времени.
(29) А зачем мне тогда вся эта технология, если я и так и команду выпрямил, и проектов хороших набрал?
(32) да, это правда. Agile открыто говорит, что в классическом подходе глобальный недостаток — в сложных вещах планировать надолго неверояно сложно, в срок практически никогда не укладываются.
В классическом подходе бывает ведь как: с уверенным лицом говорят, что «будет готово ко дню х». Что случается ко дню х? Не успели. В моей практике так было практически всегда: проект отдавали тому, кто уверенно называл какую-то дату. А почему в эту дату потом не уложились — всегда придумывали ближе к дедлайну.
Получается, в классическом подходе руководителю постоянно дают ложную (!) уверенность в сроках, которая практически никогда не сбывается. И руководителям такая ложная уверенность нравится всегда!
agile рождался в том числе и для этой проблемы классического подхода, для работы в условиях большой неопределенности
Так что лучше — уверенно врать о том что не сбудется или честно сказать, «что мы не знаем, но вот что можем сделать»?
(33)
Да, в-общем, и незачем. Есть хорошая поговорка «Работает — не трогай!».
Если и так всё хорошо — зачем менять технологию?..
А если проекты слишком сложные, требования слишком размытые, методы технической реализации непонятные, и работать с ними привычными методами не получается — тогда можно поискать новые технологии.
(32)
Предполагается, что Agile применяется для проектов такой сложности, когда ответ на вопрос «когда закончится» дать не получится независимо от выбранной технологии.
Как правильно отмечают коллеги, очень часто ответ на этот вопрос при работе «по водопаду» — это иллюзия.
В рамках базового курса по управлению ИТ-проектами я рассказываю историю немножко из другой сферы — как я выбирала, кому поручить выполнение ремонта в квартире — «Agile-команде», или команде, работающей «по водопаду». Выбрала, конечно же, «Водопадную команду», потому что она смогла четко озвучить объем работ, стоимость, сроки и т. п. — в отличие от «Agile», которые на все эти вопросы отвечали крайне сумбурно. Я решила, что так смогу минимизировать свои риски. Кто угадает, что я получила в результате? После нескольких судебных разбирательств и с опозданием примерно на 9(!) месяцев ремонт и правда был успешно завершен. И где по факту оказались их прекрасные обязательства, на которые они бодро подписывались? С «Agile» командой потери были бы по факту куда меньше.
(27) Пока ни одного не встречал. Да и каков критерий отличия одного от другого? Вот автор темы, извиняюсь, кто? Я в своё время интересовался практическими достижениями — уклончивые скользкие фразы были мне ответом.
(36)
Но вот вопрос — был ли бы сделан ремонт?
Вопрос риторический, конечно, но пример показательный. С водопадными командами заключают контракты не потому, что ждут от них выполнения в срок, а потому что надеются, что они работают по определенной технологии и знают, как она работает.
+ Наличие «прекрасных обязательств» по срокам хотя бы говорит об их наличии — в отличие от «Agile»-команды.
(38) это ошибка считать, что в agile не сроков и обязательств! Они есть, просто они разбиты на более мелкие, короткие этапы. И этапы могут поменяться в процессе, если выяснится что дальше работать по изначальному плану невыгодно для заказчика. Всегда и обязательно — с подробным объяснением заказчику что такого обнаружилось в процессе работы, почему план выгоднее поменять, какие есть варианты и т.п.
Если вам кто-то говорит «ничего не известно, обязательств не берем, обещать ничего не будем, мы работаем по agile» — гоните его в шею, это профанация, пыль в глаза, попытка прикрыть модным словом свое неумение.
(38)
Этого мы уже не узнаем. Но если ремонт не делался бы или делался неудовлетворительно — я бы прогнала их в шею уже после первого же спринта, и потери финансовые и нервные были бы куда меньше…
Здесь мне кажется, что ключевой вопрос не в том, «Agile» у нас команда или «Водопадная» — а в том, насколько мы доверяем самой команде, насколько она компетентна, следует технологии и т. п. Здесь косячить/работать качественно могут и те, и другие…