Нам необходимо разработать систему аттестации персонала
Разработаем 3 блока аттестационных заданий, каждый из которых включает 5-7 практических упражнений (проверяющих навык) и 10-13 квалификационных вопросов (проверяющих знание "предмета")
На сайте ведутся работы
сегодня 10924 Подписчиков
Для чего в файле-справочнике записаны строковые имена? Ведь смысл файла-справочника именно в том, чтобы от них избавиться.
Вспомним еще раз, для чего нужны эти строковые имена. Они нужны для понимания ПРОГРАММИСТОМ И ТОЛЬКО ПРОГРАММИСТОМ того, с чем он работает. Ни пользователем, ни программой.
Поэтому давайте все таки уберем их из справочника и оставим так:
$_phone_id = 1;
$_nik_name = 2;
$_name = 3;
$_fname = 4;
$_phone = 5;
$_programm = 10;
$_googl_id = 11;
$_my_catalog = 20;
$_catalog = 30;
$_loc_x = 50;
$_loc_y = 51;
и модифицируем код следующим образом:
Во-первых, переименуем массив:
$properties = array($_phone_id,$_nik_name,$_phone,$_loc_x,$_loc_y)
следующим образом:
$names = array($_phone_id,$_nik_name,$_phone,$_loc_x,$_loc_y)
Ведь в нём, всё-таки, хранятся не свойства как таковые, а только их имена. На первый взгляд, это кажется незначительным и неважным изменением, но через некоторое время Вы увидите, насколько это упрощает понимание того, с чем мы работаем.
Во-вторых, поменяем само получение свойств:
foreach($names as $index => $name) //формируем массив с результатом
{
$r=get($_set_id, $name, null);
while ($res=mysql_fetch_array($r))
{
$set[$name] = $res["Val"];
}
}
OutResult($set);
Замечание: непонятная переменная $array здесь заменена на более понятную $set, опять-таки, из соображений читаемости.
Результатом будет массив с ключами, соответствующими именам свойств вида:
{[1]=>«00001», [2]=> « Ваня», [5]=> «78889995556», [50]=> «30.34953», [51]=> «40.23542»};
Теперь, если мы захотим получить некоторое конкретное свойство из этого массива, мы просто сделаем следующее:
$wanted_value = $set[$_phone];
Согласитесь, что, вопреки не вполне читаемой, на первый взгляд, структуре массива, нам вполне понятно, что мы только что из него достали.
Таким образом, в соответствующих полях можно легко отобразить данные, которые там необходимы с помощью чего-то вроде этого:
<form method="post" name="visualizwer">
<?
$texts = array(”ID телефона”,“Ник” ,”Номер”,”Широта”,”Долгота”);
foreach($names as $index => $name){
echo(
"<span>
<input
id =\"$any_id\"
name =\"$name \"
class =\"element text\"
placeholder = \"$texts[$index] \"
value =\"$set[$name]\"
type =\"text\"
size=\"60\">
</span>"
);
echo ("is selected $any_id.<br /><br />");
}
?>
Обратите внимание, что читаемые для человека названия свойств вводятся ЗА ШАГ ДО ИХ ОТОБРАЖЕНИЯ НА ЭКРАН, не раньше. Более того, здесь они понимаются не как «имена свойств», а как «указания для Пользователей». Они с таким же успехом могли быть следующего вида:
$texts = array(”Ваш уникальный АйДи”,“Ваш невероятный никнейм” ,”Ваш телефон”,”Ваша Широта”,”Ваша долгота”);
Эти читаемые имена свойств можно в принципе хранить и в самой базе. Ведь, если Ваше приложение работает с несколькими языками, эти надписи должны меняться в зависимости от языка.
3. По поводу добавления данных
Не совсем понятно, почему настолько разнятся алгоритмы для добавления и обновления данных. Ведь, когда мы обновляем данные, мы пишем их в указанную строчку, а когда добавляем, то сначала создаем строчку, а затем пишем данные в указанную строчку. Логика для этих двух случаев отличается лишь на одну операцию – генерацию нового ID.
4. По поводу функции GET
Вместо того, чтобы писать отдельный запрос (или отдельную функцию) для каждого случая, лучше написать составитель запросов, который будет автоматически создавать их в зависимости от переданных параметров.
В нашем "ядре" этим составителем является функция get_brick («кирпичик»). Она будет принимать на вход следующие параметры:
get_brick ($selects, $table, $where_keys, $where_values);
$selects - говорит нам: что мы должны выбрать;
$table – говорит нам: откуда выбирать;
$where_keys – говорит нам: какие ключи проверять у наших значений;
$where_values – говорит нам: какие значения должны быть у соответствующих ключей.
Имея такую функцию, мы можем просто менять передаваемые ей параметры, в зависимости от того, что мы хотим найти, а она уже составит нам запрос, к примеру вида:
SELECT VALUE_ID,VAL FROM VALUES_STRING WHERE VAL IN ('Дима');
Возвращаемый такой функцией результат мы уже потом раскладываем в читаемый для человека вид.
С Уважением,
Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.
Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.
Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.
Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).
Эта парадигма создавалась из утилитарного стремления к идеалу, как в управленческом, так и в тризовском смысле. Формулировки идеальности (которые соответствуют по духу и замыслу тем, что сформулировал Генрих Альтшуллер, создавая ТРИЗ, и которые продвигали эту разработку) следующие:
1) Идеально - это когда программу сможет в отсутствие Автора не только сопровождать, но и развивать программист с меньшей квалификацией, чем Автор программы.
2) Идеально - когда добавление новой функциональности в программу не потребует внесения изменений и/или добавлений в программный код (более того, в совершенно идеальной программе увеличение функциональности приводит к сокращению кода); причём всё это без ущерба для любых параметров (например, быстродействия и т.д.).
И чтобы программы писались настолько быстро и сопровождались настолько просто, что их создание и сопровождение можно было бы поручить детям. А взрослые и умные специалисты пусть бы занялись чем-нибудь великим.
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда давали возможность построить модель, которую, тем не менее, нужно было проверять в течение долгого времени. Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу. И в 2006 году автор счёл возможным первую версию закономерности опубликовать открыто.
Летом 2013 года публикуется версия 2.0 - более полная, развернутая и содержащая одно существенное методическое отличие от первой версии.
Автор будет признателен Коллегам, которые найдут "узкие места" данной работы и направят автору критические замечания и/или примеры, как подтверждающие, так и опровергающие положения изложенные в материале.
Сразу начнем с сути дела. Существует некий язык записи сути задачи. Если его применять, то сложные (креативные) задачи решать становится удобнее.
Как и любая модель, эта модель тоже жизнь собой не заменяет, однако авторы статьи попробовали и убедились в том, что действительно удобно. Хотя поначалу кажется непривычным… Впрочем, авторы, уважая время Коллег, постеснялись бы писать о привычном, знакомом, общеизвестном.
Рассмотрим серию примеров. Пока намеренно несложных. (Более сложные мы в дальнейшем тоже рассмотрим).
Для решения некоторых задач программирования в качестве "инструмента", облегчающего разработчику абстрагирование от конкретики, предлагается использовать "абсолютно тупого героя", которому поручается некая деятельность. Поскольку этот герой непроходимо туп (мы даже пишем его с маленькой буквы, чтобы и тени величия в нем не наблюдалось), то задача поручить ему деятельность, которая, тем не менее, должна быть выполнена — нетривиальна.
Тем не менее, надо описать решение так, чтобы тупой (несколько тупых) смогли качественно и незатратно порученную задачу выполнить.
Остальное понятно из контекста разбираемых примеров:
Один раз решили научить тупого молоть уголь и рисовать угольной крошкой по трафаретам на поверхностях и чуть не наломали дров. Сначала научили тупого рисовать углем "бабушку" на "окошке". Для этого, велели ему:
Кто придумал такую тупую инструкцию вспомнить уже невозможно — так, что материться глупо — надо работать. Поэтому с помощью воплей, дубины, «соцпакета» и 10-ти тупых администраторов кое-как упомянутый художественный результат достигался.
Причем 10 тупых администраторов периодически посещали семинары по мотивации тупых, где их учили более правильным "соцпакетам", в результате применения которых тупой должен был бы "раскрыться" и стать Личностью. А уж Личность смогла бы рисовать не только бабушек, но и птичек.
Однако, в связи с развитием рыночных отношений, задание усложнилось.
Фрагмент выступления 08 апреля 2014 года на конференции "Открытые бизнес-методики и технологии", г. Ростов-на-Дону
Рекомендация 2.2 (из 10-ти).
Молодая фирма, стартуя, имеет бизнес-план, как минимум, на первые три года жизни (по крайней мере, иметь его чрезвычайно полезно). Результаты, на которые надо выйти за эти три года, и будем считать "эталонными". Кроме "эталонных", зададим промежуточные результаты — те, на которые надо выйти к заданным срокам. Фактические результаты в стартовый период" будем сравнивать не с эталонными, а с промежуточными результатами.
Важный момент: промежуточные результаты задаются на старте, а не по "факту" (от достигнутого).
Сравните:
а) план вырос потому, что подошел срок, когда пора выйти на показатели, намеченные в бизнес-плане;
б) план вырос потому, что достигли хороших результатов, а всегда хочется больше.
Пункт а), в отличие от пункта б), протеста не вызывает.
Товаров все больше и больше, поэтому непонятно, что рекламировать из имеющегося ассортимента, тем более что макет газетной полосы не резиновый, а кегль шрифта тоже имеет нижнюю границу. Руки опускаются, а в голову приходят уж очень общие идеи типа: "Все для всех всегда". А реклама магазина все больше и больше становится похожа на рекламу банка: там тоже "Для всех и повсеместно". Чтобы упомнить все товары, нужно долго обучаться мнемотехнике.
Создавшаяся ситуация неопределенности усложняет и работу отдела рекламы, и контроль над ним. Товар - с колес, макет - в пожаре... Все заняты текучкой. Некогда планировать, некогда искать идеи, некогда отслеживать эффективность. Надо продавать, изготавливать, размещать: Стоп! Очень уж удобная позиция. Остановимся на несколько часов и посмотрим на десятки тысяч, нет, сотни тысяч товаров и услуг иначе...
В материале приведен список основной литературы по ТРИЗ.
В разные годы издавались и другие книги (как правило, меньшим тиражом) других авторов. Но мы рекомендуем начинать знакомство именно с классики ТРИЗ - книг Г.С. Альтшуллера. Как правило, найти эти книги можно в крупных библиотеках.
24 сентября 1998 г. умер великий человек. Генрих Саулович Альтшуллер, создатель и первый разработчик ТРИЗ - теории решения изобретательских задач, приемов развития творческого воображения, ЖСТЛ - жизненной стратегии творческой личности.
Уже сейчас ясно: это наука следующего тысячелетия. И нам будет трудно объяснить внукам, почему власть и электорат, начальники и ученые, спец. органы и педагоги так боялись новой науки в веке уходящем... Наверное потому, что ТРИЗ и ЖСТЛ меняют мышление, а значит и жизнь. Генрих Саулович считал, что человек должен прожить ее Достойно - на пределе своих возможностей. И он позволил себе так жить. Возможно, наши внуки окажутся сильнее нас...
И.Л. Викентьев
Фрагмент выступления Сергея Сычёва на ежегодном TRIZ-RI ФОРУМе
"Открытые бизнес-методики и технологии",
Москва, 27 сентября 2011 г.
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда позволил построить модель, которую, тем не менее, нужно было проверить… Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу.
Материал публикуется с некоторыми сокращениями и в то же время – с небольшими дополнениями.
Два великих человека радикально высказались об оптимизации: "Единственный способ оптимизировать затратный проект – это его закрыть" (Питер Друкер) и "Идеальная система - та, которой нет, а функции ее выполняются" (Генрих Альтшуллер).
Этот материал посвящен (основанным на ТРИЗ) приемам сокращения работ при сохранении и улучшении их результатов. В этой части работы вслед за классиками сформулируем: "Лучшая работа – та, которую делать не надо, но результат ее получается".
Часто бывает так: людей на работу взяли, а дело не движется. Звонков мало, заявок еще меньше, клиентская база тает… И не только в отделе продаж.
А Вы возьмите к себе "на работу" наших специалистов.
Каждый из нас имеет более чем 20-летний опыт практического внедрения системы управления предприятием, администрирования бизнес-процессов в отделах: активных продаж, закупки (снабжения), продвижения, складском хозяйстве, бухгалтерии, IT и пр.
С нашим приходом на предприятие уже через короткое время процессы управления организацией начинают работать как хорошо отлаженный механизм. А штатные сотрудники привыкают выполнять свои функции.
Если Вы бываете в Европе по делам бизнеса или с частными целями, найдите время заехать к нам в Прагу. На консультацию, на стажировку, на деловой завтрак. За свежими идеями, за новыми методиками, за иной обстановкой и за иными возможностями.
В Праге Вас встретят наши лучшие эксперты. Мы предложим Вам качественные программы бизнес-обучения по-европейски. В том числе, сделанные "под Вас". В том формате, в каком удобно Вам.
"ТРИЗ" - Теория Решения Изобретательских Задач – самая сильная, на сегодняшний день, система создания новых идей и изобретений известна во многих странах: Германии, Великобритании, США, Швеции, Франции, Японии, Корее, Израиле, Вьетнаме, Испании, Финляндии, Канаде и др.
Книги автора ТРИЗ Генриха Альтшуллера [15.10.1926 - 24.09.1998] переведены на десятки иностранных языков. Большинство успешных компаний активно используют её для совершенствования своих товаров и услуг.