Добре дошъл в клуба

<logout>

Цикъла в показания код е един (този, които прави fetch/assign). Това какво има в темплейт енджина няма общо с прегледността. Изрично отбелязах, че не коментирам производителност, а прегледност.

пример със Smarty:

Чисто и просто, като къпан полицай.

Кога на страницата е прегледен и е ясно кое от къде е. Не да разписваме на сто места цикли върху едни и същи данни, за да ги покажем. Говоря за прегледност на кода, не за производителност.

Моят текущ адрес няма име/номер на улица. Идентифицира се по име на ЖК, номер на блок, номер на вход.
Има градове в България (май Варна и Русе, може и други), в които идентификацията включва име не блок.

Според мен най-правилният подход, когато става въпрос за адрес в България, е да се вземе бланка на държавната администрация и да се препишат полетата от там.

Примерно в данъчната декларация полетата са:

Както се вижда проблемните за раздробяване данни са в едно поле. Всеки си го попълва както знае, че се пише адреса му.

Е за това не ти стига просто програмиране, ако ще и 100 езика да знаеш без необходимата математика няма как да се справиш.

Програмирането на игрите е като програмирането във всяка друга предметна област, трябва да знаеш програмиране + познания в областта. За съжаление (или за радост) предметната област наречена game development обхваща в себе си много други области, затова е по-трудно от всяка от тях взета по отделно.

Сигурен съм, че писане на времеви (weather) симулатор също е много сложно, отново поради нуждата от познаване на много процеси.

Проблема идва от редактори, които не покзват html кода, а го рендват (т.нар. WYSIWYG). Та в такъв редактор, ползвайки стандартен PHP изход, ще ти бъдат "изрязани" всички тагове, защото по спецификация, неразпознат html таг просто се пропуска.
От друга страна, ако ползваш {...} всеки редактор (вкл. WYSUWYG) ще ти покаже placeholder-ите както си трябва.

Не искам да омаловажавам темплейт енджините (ползвам Smarty), но това е последното, "предимство", което бих използвал в тяхна защита.

Предимството на {$title} е, че ако отвориш документа в някякъв fancy редактор, няма да се опитва да ти го интерпретира като таг (заради <>) и дизайнера ще си вижда кое къде трябва да сложи.

<joke>
Или популярната единица:

</joke>

В един от проектите на една от фирмите, в който съм работил имаше някакъв тул за преобразуване на мерни единици (ползваше се за телеметрия във формула 1), та там беше напълно възможно да мериш в "стъпки за две седмици" (дори и google го поддържат: http://www.google.bg/?q=1+km/h+in+feet+per+fortnight).

Когато става въпрос за прости мерки (примерно дължина) може и да се мине с enum, но в момента, в който се стигне до производните нещата загрубяват и enum-а ще ни се стори тесничък.

Моят съвет е, когато се прави такава система да се прави максимално разширяема (предложението с допълнителна таблица). Сигурен съм, че базата няма да падне от един JOIN повече.

CHM има проблеми (т.е. MS имат проблеми) при отварянето му от мрежов ресурс (\\my share\file.chm).
Проблемите идват от настройките за сигурност по подразбиране и е мнооого досадно (особено когато не можеш да ги пипаш, например в корпоративна мрежа) да трябва всеки файл да го копираш локално.

Винаги съм предпочитал добре форматиран PDF (със съдържание и т.н.), който освен същата функционалност като CHM, предоставя и добра версия за печат.

Откакто имам iPad пък предпочитам ePub.

Като цяло на CHM се радвах преди 5-6 години, когато работех изцяло на Windows.

|---------------------------------| <- ей толкова

Нещата, които минават през bindValue/Param/Column/Whatever се почистват и са ок. Ако обаче конструираш сам парчета от заявката (скоро бях писал една тема за динамично задаване на колони), трябва сам да си почистваш каквото добавяш. Ако след динамично конструираната (и почистена) заявка, получиш такава за ползване с PDO (bind*) - оставяш PDO да се грижи за почистването.

Идеята е, че понякога нулирани стойности си изглеждат съвсем наред. Но ако не ги "занулиш" изглеждат различно на различни брайзъри.

Reset/Normalize са два поднода за изравняване на стойностите по подразбиране на различните брайзъри и започваш да градиш разликите от едно и също място.

Аз лично предпочитам Normalize подхода, който с подходящи стойности води до по-малко места за "градене".

Прекрасно заключение, значи нищо не е научено през семестъра. От ситуацията има два изхода:
- сядаш си на Д-то и наваксваш пропуснатото.
- отказваш се и опитваш отново следващия семестър.

Ясно решението в твоя случай е второто, с което темата е приключена.

Цялата памет заделена от програмата се освобождава от ОС при излизане, същото се отнася и за затваряне на файловите манипулатори.

О-о-о-о-о има, има.

Подготвено съдържание, което никога няма да погледна е ненужно доставено при мен. По тази причина хората ползват JS и зареждат парчета от сайта, когато се поискат.