Наверное на страничке config/error.htm рассказывается о том какие браузеры поддерживаются полностью. Возможно на момент написания админки, в опера присутствовали баги, на которые разработчики не хотели отвлекаться.
странно вы рассуждаете :). Следую вашей логике, логичнее было бы сказать «скорее в задании было написано что админка не должна поддерживать оперу и т п и т д....».
очевидно что вам ничего не очевидно.
Очевидно что при аутсорсе верстальщики делают свою работу на отъ… бись, не держутся они за своих клиентов. И еще очевидно что в портфолио у этих говно верстальщиков обычно неплохие работы(копировать они умеют не плохо).
просто развелось дебютантов много, которые увидели в себе спеца после прочтения очередной умной книжки. А копировать и вставлять много ума не надо. Это как наштампованные дизайнеры, посмотрели видео курс по фотошопу, получили озарение о том как воровать шаблоны с templatemonster и ушел.
ответа «на верстальщика» нет почему то, видимо считается что если программист — значит не верстает.
программист видит лучше где и как нужно порезать чтобы софтина работало оптимально с хтмл блоками.
я ругаюсь на горе верстальщиков(наша компания любит оутсорсить верстку), код которых мне приходится прикручивать к приложениям, и при этом переделывать почти 30-40%(а иногда и полностью) их работы(повторяющиеся id, не резиновые формы и т. д.). И еще просто ругаюсь так как многие верстальщики не могут прикрутить свою верстку к тому или иному проекту — нет ничего страшнее прикручивать верстку дебютанта или говно-верстальщика
ну допустим нужно получить список последний 10 продуктов. тогда мне нужно использовать дату как ключ иначе мне придется выдернуть все продукты и проверить дату.
а хранение товаров тоже проблематичным становится?
1. допустим храним все товары в одном масиве под одним ключем, тогда чтобы показать один единственный товар — в память загрузится весь список продуктов а потом уже из этого списка и возьмем нужный нам товар. — это плохо неоптимальное использование памяти
2. допустим наоборот, мы храним все товары под своими ключами — тогда чтобы показать список товаров на придется пробежаться по всей бд и выдернуть все ключи с префиксом product:
хм. ну да, конечно же нереляционная модель удобна там где намного удобнее лишь хранить данные как ключ-значение.
но, мы же не забываем что «Гугл, линкедин, фейсбук, амазон и другие… » используют нереляционную БД как дополнительную к реляционной-основной? Ими нереляционная модель БД в основном используется для кеширования
Интересно что же подразумевается вами под «80% всех проектов» в интернете. В эти 80% «интернет магазин» попадает по-вашему?
По моему нереляционная модель БД может использоваться только для кеширования.
Ну и конечно же можно использовать на сайта-штамповках, все данные для которых можно сохранить даже под одним ключом в нереляциоонной БД. я надеюсь вы не относите сайты-штамповки к определению «проект»
а ваш вопрос о другом.
но тем не менее.
как часто вам приходится работать с датами в виде целого числа?
не думаю что за еденичный запрос вам приходится делать тысячи конвертаций в int.
думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
как было подмечено выше «timestamp выводится так же как и datetime в новых версиях mysql ('YYYY-MM-DD HH:MM:SS', точно в 5.0), в старых без пунктуации.»
т.е. к int-у это не сработает. а в остальном не вижу различий между int и timestamp
но карму то зачем было трогать?
Очевидно что при аутсорсе верстальщики делают свою работу на отъ… бись, не держутся они за своих клиентов. И еще очевидно что в портфолио у этих говно верстальщиков обычно неплохие работы(копировать они умеют не плохо).
просто развелось дебютантов много, которые увидели в себе спеца после прочтения очередной умной книжки. А копировать и вставлять много ума не надо. Это как наштампованные дизайнеры, посмотрели видео курс по фотошопу, получили озарение о том как воровать шаблоны с templatemonster и ушел.
зы: оценивать мою компанию я не просил!
программист видит лучше где и как нужно порезать чтобы софтина работало оптимально с хтмл блоками.
я ругаюсь на горе верстальщиков(наша компания любит оутсорсить верстку), код которых мне приходится прикручивать к приложениям, и при этом переделывать почти 30-40%(а иногда и полностью) их работы(повторяющиеся id, не резиновые формы и т. д.). И еще просто ругаюсь так как многие верстальщики не могут прикрутить свою верстку к тому или иному проекту — нет ничего страшнее прикручивать верстку дебютанта или говно-верстальщика
а хранение товаров тоже проблематичным становится?
1. допустим храним все товары в одном масиве под одним ключем, тогда чтобы показать один единственный товар — в память загрузится весь список продуктов а потом уже из этого списка и возьмем нужный нам товар. — это плохо неоптимальное использование памяти
2. допустим наоборот, мы храним все товары под своими ключами — тогда чтобы показать список товаров на придется пробежаться по всей бд и выдернуть все ключи с префиксом product:
но, мы же не забываем что «Гугл, линкедин, фейсбук, амазон и другие… » используют нереляционную БД как дополнительную к реляционной-основной? Ими нереляционная модель БД в основном используется для кеширования
По моему нереляционная модель БД может использоваться только для кеширования.
Ну и конечно же можно использовать на сайта-штамповках, все данные для которых можно сохранить даже под одним ключом в нереляциоонной БД. я надеюсь вы не относите сайты-штамповки к определению «проект»
вот например jQuery('#'+objectId+'>param[name=flashvars]').val() не будет работать в новой версии, хотя прекрасно работает в v1.2.6
а ваш вопрос о другом.
но тем не менее.
как часто вам приходится работать с датами в виде целого числа?
не думаю что за еденичный запрос вам приходится делать тысячи конвертаций в int.
думаю плюсы datetime в виде функций ADDDATE,YEARWEEK,CONVERT_TZ… все таки перевешивают плюсы timestamp-а
т.е. к int-у это не сработает. а в остальном не вижу различий между int и timestamp