Вот кстати, классическая фраза по стыковке в Elite:
«Добейтесь синхронного вращения корабля со станцией, для успешной стыковки».
Поначалу так и извращался. А потом просто — зашел с нужной стороны станции, выровнял курс на центр шлюзового отверстия, и без всякого вращения прекрасно стыковался. :)
Но Docking Computer конечно экономил в этом плане массу времени.
В любом случае в шаблоне появляется логика отображения при достаточной сложности системы.
Если в простейшем варианте мы имеем сложный шаблон — значит вероятно что-то не так в самой системе.
А при работе с более-менее продвинутым программным продуктом почитать мануал лишним не будет.
Отличное письмо от Мегафона :)
вы им претензию с разбирательствами, а они вам «Спасибо за обращение» и попутно лист А4 рекламного текста об этой самой услуге.
Это видимо намёк: «да вы просто не распробовали! Вот почитайте от чего отказались!».
>На вопрос о лимите по предоплате говорится, что произошел технический сбой и поэтому связь не прервалась после окончания финансов у абонента.
То есть технически оператор признал, что имел место технический сбой?
Таким образом получается что задолженность абонента, пользующегося предоплатным тарифным планом, возникла по причине технического сбоя у оператора.
В том же Photoshop есть такая фишка как batch-операции. Как раз предназначена для пакетной обработки файлов.
Помнится таким образом делал resize примерно 3500 фотографий.
Настроил откуда брать фото, с каким именем и куда сохранять, и какой action использовать (Action для ресайза создал заранее по требуемым параметрам).
Запустил и ушел пить чай. Спустя примерно час-полтора всё было уже готово.
Получается, что толпы народа, работают над задачей в поте лица, под землёй. А случайно упавший, неизвестно откуда, батон хлеба может всё это испортить?
Инженера по безопасности видимо в штате не предусмотрено. Да и собственно, судя по новостям — и самой безопасности тоже. :)
Есть куда потратить еще миллиард: на сетки, защищающие наземную часть от птиц и летающих батонов. :)
ИМХО, более показательным будет передача в конструктор не значения $text, а конфигурации (массив или имя настроек в файле config/tester.php). В таком случае сперва конструктор загрузит дефолтные настройки, затем поверх них скопирует переданные. А сам текст уже передавать через специальный метод или магический __set().
Изначально подобный вариант и намечался.
Но потом сознательно было убрано всё, без чего можно обойтись, и оставлен только самый простой скелет модуля. Главная задача — сразу «въехать» в то, как собственно написать модуль для Ko3. Остально добавить будет не проблемным.
Еще и для того, чтобы избежать случайных накладок — мне кажется и есть смысл называть внутренние файлы модуля так же, как и сам модуль. Если, конечно, не ставиться другой цели.
«Добейтесь синхронного вращения корабля со станцией, для успешной стыковки».
Поначалу так и извращался. А потом просто — зашел с нужной стороны станции, выровнял курс на центр шлюзового отверстия, и без всякого вращения прекрасно стыковался. :)
Но Docking Computer конечно экономил в этом плане массу времени.
Если в простейшем варианте мы имеем сложный шаблон — значит вероятно что-то не так в самой системе.
А при работе с более-менее продвинутым программным продуктом почитать мануал лишним не будет.
Отсюда первый вариант будет выглядеть так:
<?php echo $v['head'] ?>
Уже не так компактно, как хотелось бы.
Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?
На мой личный взгляд — слишком поперенавороченно получается. =)
В любом упрощении, главное — не усложнить.
вы им претензию с разбирательствами, а они вам «Спасибо за обращение» и попутно лист А4 рекламного текста об этой самой услуге.
Это видимо намёк: «да вы просто не распробовали! Вот почитайте от чего отказались!».
То есть технически оператор признал, что имел место технический сбой?
Таким образом получается что задолженность абонента, пользующегося предоплатным тарифным планом, возникла по причине технического сбоя у оператора.
Это же РАО :)
Помнится таким образом делал resize примерно 3500 фотографий.
Настроил откуда брать фото, с каким именем и куда сохранять, и какой action использовать (Action для ресайза создал заранее по требуемым параметрам).
Запустил и ушел пить чай. Спустя примерно час-полтора всё было уже готово.
Это правильный подход, и очень-очень хочется чтобы все сервисы двигались в этом же направлении.
После прочтения даже появился зуд: сделать что-нибудь эдакое :)
Инженера по безопасности видимо в штате не предусмотрено. Да и собственно, судя по новостям — и самой безопасности тоже. :)
Есть куда потратить еще миллиард: на сетки, защищающие наземную часть от птиц и летающих батонов. :)
Изначально подобный вариант и намечался.
Но потом сознательно было убрано всё, без чего можно обойтись, и оставлен только самый простой скелет модуля. Главная задача — сразу «въехать» в то, как собственно написать модуль для Ko3. Остально добавить будет не проблемным.
Еще и для того, чтобы избежать случайных накладок — мне кажется и есть смысл называть внутренние файлы модуля так же, как и сам модуль. Если, конечно, не ставиться другой цели.