Ну собственно ради «не моментальной выкупаемости» и делается отдельный файл, который отдельно подгружает наши описания, и кладется _отдельно_.
Если всё проходит с оплатой нормально — файл перекладывается в нормальное местоположение и все счастливы (кроме тех, кто потом будет разгребать код. %) )
А если не проходит нормально — то нужно будет сначала отыскать, откуда растут ноги у «сломанной работы», а потом постараться восстановить оттуда, откуда бэкап и не делали. В этом то и предусмотрительность.
Хотя в моем случае — это теоретические рассуждения.
Я себя однажды обезопасил следующим образом: в БД, в дебри всяких настроек и свойств проекта, была запасена настройка (не отображаемая в панели управления проектом) типа «jugment_day» с забитой датой краха (примерно на месяц после сдачи проекта). Делал заранее, поскольку была информация о работодателе… хм… ну скажем так — не самая приятная для внештатных работников.
И всё получилось как и планировалось по сценарию: денег не оказалось в кассе, игнор звонков и всё в лучших традициях жанра.
А через месяц всё тупо перестало работать. То есть в панели управления всё отлично, а вот сам функционал системы тупо молчал. И для того, чтобы сообразить, что к чему — нужно было копаться в кишках написанного.
Прямой связи со мной — нет. Да и звонить мне, после того как меня же и кинули на оплату — не позволяет самолюбие.
В итоге получилось так, что чинить пришлось моему знакомому, который слупил с них как раз сумму, которая позволила нам компенсировать нервные затраты, и попить пивка.
Ну а починка свелась к ИБТД в течении двух дней, и последующей установке «jugment_day» в NULL.
Хотя признаю — это в какой-то мере результат везения: во-первых, у меня была информация о недобросовестности заказчика, во-вторых — не нашлось под рукой у заказчика никого с должным уровнем квалификации, чтобы разгрести код, ну и в третьих — так уж удачно сложилось, что чинить выпало моему знакомому. :)
поначалу прикольно. Но на второй день начало бесить самого. :)
Единственный вариант, который напрашивается навскидку: защита себя от неуплаты за сдельную работу:
— вешаем библиотеку с define куда-нибудь в доступное место.
— скрипт, сначала грузит наши define(), потом выполняется.
— ежели нам не заплатили за сдельную работу, и перекрыли кислород с доступами, удаляем положенный в заранее доступное место файлик с описаниями и всё.
В остальном же — такое использование имен функций будет, как мне кажется, выбивать из колеи примерно также, как и votTakajaFunkcija() или OtkroemFajl().
С последними примерами пришлось сталкиваться лично :))
Задумка интересная, но как уже сказали выше — слишком цветасто и аляповато получается. На мой взгляд — это лишнее. Просто удобная табличка — этого уже хватает.
Подсветка по типам — ИМХО тоже лишнее. Всё равно отслеживать тип по цвету, скорее всего никто не будет.
Как вариант — оставить различие по цветам, например, для переменных и массивов (обьектов). В остальных случаях, мне кажется текстового указания типа (integer, string и пр.) вполне хватит для ориентации в пространстве дампа. :)
Когда учился в универе — часто готовил шпаргалки к экзаменам. Формат был примерно следующий:
<Вопрос>
<Пара-тройка основных тезисов в виде словосочетаний>
<общее описание — одно-два предложения >
<если требуются формулы — то формула + общее смысловое описание этой формулы.>
общее описание — исключительно для того, чтобы подтолкнуть размышления в нужную сторону — дальше мозг вспоминает сам, как раз то, что нужно.
Запоминать же формулу без понимания смысла — это вообще что-то совсем бессмысленное на мой взгляд :)
В результате на общую площадь формата А4 легко умещались все вообще необходимые подсказки.
Но самое главное — пока их готовишь, запоминаешь. Вплоть до месторасположения на этом А4. Посему необходимости таскать подготовленные шпоры с собой — просто не было.
Это был такой cheatsheet в голове.
Хотя, как помню — на первом-втором курсе у меня были проблемы с предметами: социология и политология. С этими двумя мне не помогали никакие шпоры. В итоге худо-бедно сдал их на троечку и успокоился.
-в каждом году есть один день без даты — после 30 декабря (день нг)
— Когда это произошло?
— В третий «день без даты».
— Хм, а во сколько?
— В безымянный час и в нисколько минут.
— Точнее сказать можете?
— Ну, вроде бы и секунд тоже было нисколько.
:)
Всё-таки теплится надежда, что такого глобального отмытия денежных средств не допустят.
Отлично, отлично! Вот так и надо работать, молодцы!
По поводу виртуальной клавиатуры — присоединяюсь к мнению, что «AБВГД» будет однозначно удобнее.
Те кто печатает вслепую, скорее всего не акцентируют внимание, где какая буква. А те кто не печатает вслепую — всё равно будут искать.
А вот алфавит-то знают все, независимо от уровня навыков печати.
Вот кстати, классическая фраза по стыковке в Elite:
«Добейтесь синхронного вращения корабля со станцией, для успешной стыковки».
Поначалу так и извращался. А потом просто — зашел с нужной стороны станции, выровнял курс на центр шлюзового отверстия, и без всякого вращения прекрасно стыковался. :)
Но Docking Computer конечно экономил в этом плане массу времени.
В любом случае в шаблоне появляется логика отображения при достаточной сложности системы.
Если в простейшем варианте мы имеем сложный шаблон — значит вероятно что-то не так в самой системе.
А при работе с более-менее продвинутым программным продуктом почитать мануал лишним не будет.
Отличное письмо от Мегафона :)
вы им претензию с разбирательствами, а они вам «Спасибо за обращение» и попутно лист А4 рекламного текста об этой самой услуге.
Это видимо намёк: «да вы просто не распробовали! Вот почитайте от чего отказались!».
>На вопрос о лимите по предоплате говорится, что произошел технический сбой и поэтому связь не прервалась после окончания финансов у абонента.
То есть технически оператор признал, что имел место технический сбой?
Таким образом получается что задолженность абонента, пользующегося предоплатным тарифным планом, возникла по причине технического сбоя у оператора.
В том же Photoshop есть такая фишка как batch-операции. Как раз предназначена для пакетной обработки файлов.
Помнится таким образом делал resize примерно 3500 фотографий.
Настроил откуда брать фото, с каким именем и куда сохранять, и какой action использовать (Action для ресайза создал заранее по требуемым параметрам).
Запустил и ушел пить чай. Спустя примерно час-полтора всё было уже готово.
Получается, что толпы народа, работают над задачей в поте лица, под землёй. А случайно упавший, неизвестно откуда, батон хлеба может всё это испортить?
Инженера по безопасности видимо в штате не предусмотрено. Да и собственно, судя по новостям — и самой безопасности тоже. :)
Есть куда потратить еще миллиард: на сетки, защищающие наземную часть от птиц и летающих батонов. :)
ИМХО, более показательным будет передача в конструктор не значения $text, а конфигурации (массив или имя настроек в файле config/tester.php). В таком случае сперва конструктор загрузит дефолтные настройки, затем поверх них скопирует переданные. А сам текст уже передавать через специальный метод или магический __set().
Изначально подобный вариант и намечался.
Но потом сознательно было убрано всё, без чего можно обойтись, и оставлен только самый простой скелет модуля. Главная задача — сразу «въехать» в то, как собственно написать модуль для Ko3. Остально добавить будет не проблемным.
Еще и для того, чтобы избежать случайных накладок — мне кажется и есть смысл называть внутренние файлы модуля так же, как и сам модуль. Если, конечно, не ставиться другой цели.
Если всё проходит с оплатой нормально — файл перекладывается в нормальное местоположение и все счастливы (кроме тех, кто потом будет разгребать код. %) )
А если не проходит нормально — то нужно будет сначала отыскать, откуда растут ноги у «сломанной работы», а потом постараться восстановить оттуда, откуда бэкап и не делали. В этом то и предусмотрительность.
Хотя в моем случае — это теоретические рассуждения.
Я себя однажды обезопасил следующим образом: в БД, в дебри всяких настроек и свойств проекта, была запасена настройка (не отображаемая в панели управления проектом) типа «jugment_day» с забитой датой краха (примерно на месяц после сдачи проекта). Делал заранее, поскольку была информация о работодателе… хм… ну скажем так — не самая приятная для внештатных работников.
И всё получилось как и планировалось по сценарию: денег не оказалось в кассе, игнор звонков и всё в лучших традициях жанра.
А через месяц всё тупо перестало работать. То есть в панели управления всё отлично, а вот сам функционал системы тупо молчал. И для того, чтобы сообразить, что к чему — нужно было копаться в кишках написанного.
Прямой связи со мной — нет. Да и звонить мне, после того как меня же и кинули на оплату — не позволяет самолюбие.
В итоге получилось так, что чинить пришлось моему знакомому, который слупил с них как раз сумму, которая позволила нам компенсировать нервные затраты, и попить пивка.
Ну а починка свелась к ИБТД в течении двух дней, и последующей установке «jugment_day» в NULL.
Хотя признаю — это в какой-то мере результат везения: во-первых, у меня была информация о недобросовестности заказчика, во-вторых — не нашлось под рукой у заказчика никого с должным уровнем квалификации, чтобы разгрести код, ну и в третьих — так уж удачно сложилось, что чинить выпало моему знакомому. :)
Я помню баловался именами типа:
// destructor
function -_-() {}
// exception handler
function O_o() {}
поначалу прикольно. Но на второй день начало бесить самого. :)
Единственный вариант, который напрашивается навскидку: защита себя от неуплаты за сдельную работу:
— вешаем библиотеку с define куда-нибудь в доступное место.
— скрипт, сначала грузит наши define(), потом выполняется.
— ежели нам не заплатили за сдельную работу, и перекрыли кислород с доступами, удаляем положенный в заранее доступное место файлик с описаниями и всё.
В остальном же — такое использование имен функций будет, как мне кажется, выбивать из колеи примерно также, как и votTakajaFunkcija() или OtkroemFajl().
С последними примерами пришлось сталкиваться лично :))
Подсветка по типам — ИМХО тоже лишнее. Всё равно отслеживать тип по цвету, скорее всего никто не будет.
Как вариант — оставить различие по цветам, например, для переменных и массивов (обьектов). В остальных случаях, мне кажется текстового указания типа (integer, string и пр.) вполне хватит для ориентации в пространстве дампа. :)
<Вопрос>
<Пара-тройка основных тезисов в виде словосочетаний>
<общее описание — одно-два предложения >
<если требуются формулы — то формула + общее смысловое описание этой формулы.>
общее описание — исключительно для того, чтобы подтолкнуть размышления в нужную сторону — дальше мозг вспоминает сам, как раз то, что нужно.
Запоминать же формулу без понимания смысла — это вообще что-то совсем бессмысленное на мой взгляд :)
В результате на общую площадь формата А4 легко умещались все вообще необходимые подсказки.
Но самое главное — пока их готовишь, запоминаешь. Вплоть до месторасположения на этом А4. Посему необходимости таскать подготовленные шпоры с собой — просто не было.
Это был такой cheatsheet в голове.
Хотя, как помню — на первом-втором курсе у меня были проблемы с предметами: социология и политология. С этими двумя мне не помогали никакие шпоры. В итоге худо-бедно сдал их на троечку и успокоился.
— Когда это произошло?
— В третий «день без даты».
— Хм, а во сколько?
— В безымянный час и в нисколько минут.
— Точнее сказать можете?
— Ну, вроде бы и секунд тоже было нисколько.
:)
Всё-таки теплится надежда, что такого глобального отмытия денежных средств не допустят.
По поводу виртуальной клавиатуры — присоединяюсь к мнению, что «AБВГД» будет однозначно удобнее.
Те кто печатает вслепую, скорее всего не акцентируют внимание, где какая буква. А те кто не печатает вслепую — всё равно будут искать.
А вот алфавит-то знают все, независимо от уровня навыков печати.
Сколько всего было к нему прикручено и припаяно умелыми руками советских и российских радиолюбителей, не перечесть.
«Добейтесь синхронного вращения корабля со станцией, для успешной стыковки».
Поначалу так и извращался. А потом просто — зашел с нужной стороны станции, выровнял курс на центр шлюзового отверстия, и без всякого вращения прекрасно стыковался. :)
Но Docking Computer конечно экономил в этом плане массу времени.
Если в простейшем варианте мы имеем сложный шаблон — значит вероятно что-то не так в самой системе.
А при работе с более-менее продвинутым программным продуктом почитать мануал лишним не будет.
Отсюда первый вариант будет выглядеть так:
<?php echo $v['head'] ?>
Уже не так компактно, как хотелось бы.
Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
На мой личный взгляд — слишком поперенавороченно получается. =)
В любом упрощении, главное — не усложнить.
вы им претензию с разбирательствами, а они вам «Спасибо за обращение» и попутно лист А4 рекламного текста об этой самой услуге.
Это видимо намёк: «да вы просто не распробовали! Вот почитайте от чего отказались!».
То есть технически оператор признал, что имел место технический сбой?
Таким образом получается что задолженность абонента, пользующегося предоплатным тарифным планом, возникла по причине технического сбоя у оператора.
Это же РАО :)
Помнится таким образом делал resize примерно 3500 фотографий.
Настроил откуда брать фото, с каким именем и куда сохранять, и какой action использовать (Action для ресайза создал заранее по требуемым параметрам).
Запустил и ушел пить чай. Спустя примерно час-полтора всё было уже готово.
Это правильный подход, и очень-очень хочется чтобы все сервисы двигались в этом же направлении.
После прочтения даже появился зуд: сделать что-нибудь эдакое :)
Инженера по безопасности видимо в штате не предусмотрено. Да и собственно, судя по новостям — и самой безопасности тоже. :)
Есть куда потратить еще миллиард: на сетки, защищающие наземную часть от птиц и летающих батонов. :)
Изначально подобный вариант и намечался.
Но потом сознательно было убрано всё, без чего можно обойтись, и оставлен только самый простой скелет модуля. Главная задача — сразу «въехать» в то, как собственно написать модуль для Ko3. Остально добавить будет не проблемным.
Еще и для того, чтобы избежать случайных накладок — мне кажется и есть смысл называть внутренние файлы модуля так же, как и сам модуль. Если, конечно, не ставиться другой цели.