Кстати заметил еще одно. Эти замечательные не ленивые люди, копастящие свой код по тысячу раз, просто не хотят развиваться. Не изучают ничего нового, а некоторые к новому имеют даже некий протест, который обычно обосновывается фразой «А нафиг его переделывать, если и так работает». Таким человекам глубоко пофиг на то, что возможно через пол года придется вернутся в этому коду и в нем разбираться.
А как правильно написано в Perl Best Practices — плохо написанный и описанный код уже через полгода становиться неузнаваемым, будто вы его сами не писали.
Класс, то что надо! Именно так все и есть. С этими тупизмами сталкиваюсь, да именно этот банальный пример про копирование 5 строчек — это все правда. Весь август я сидел и выносил в процедуры установки свойств, не грешно сказать что с 12 тыс. строк модуль уменьшился до 10 тыс.
Меня поражают эти не ленивые люди! Это же как надо не ценить свое время чтобы вместо одной строки переписывать 5, ошибаться в них, а потом в этих тоннах кода искать эти самые ошибки.
Программист обязан быть ленивым — лень заставляет оптимизировать решение и тратить на проблему меньше времени. Эта лень — не безделье, а стремление избавить себя от работы, которую может делать машина.
Когда у нас есть ксерокс — мне лень печатать копии на печатной машинке!
Да, да! Статейка была на alistapart про 30 способов улучшить свой CSS, это и была одна из рекомендаций.
Очень удобно — сразу видно что/где и внутри чего.
p.s. дело вкуса, а я предпочитаю группировать так:
/* Header
----------------------------*/
#header {} /* даже если нет стилей, все равно указываю для соблюдения "каскадности" */
#header p {
/* стили для p внутри header'а */
}
#header ul {
}
#header ul li {
}
/* Content
----------------------------*/
div#content{
/* стили content'а */
}
div#content p {
/* стили для p внутри header'а */
}
div#content ul {
}
div#content ul li {
}
/* Typographic
----------------------------*/
Даже если определние блока пустое я все равно его пишу для «каскадности».
А для начала было бы неплохо в рамках этого спора установить, что считать админом а что кодером?
Если кодер не знает как винду переставить — это ли чистый кодер?
Потому что объектные базы ориентированы на большие проекты, например обслуживание телекоммуникационной сети, а для сайта — это чрезвычайно много. С этой работой справляются и реляционные БД.
Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.
Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.
Помните, отрицательный результат — тоже результат. Желаю успеха.
Могу признаться честно — боязнь, что не получиться. Я в первый раз так и сделал, но из-за невалидного html местами хабр его обкусочил странно, после чего на меня пошли наезды и минусовки — обидно. (
Вот я подумал было, что введено ограничение на размер статьи, потому решил уж лучше 4 раза по чуть чуть, чем одна несуразица.
Скажи и покажи как и сколько надо/можно, чтобы не травмировать психику пользователей?
Я тут совсем недавно потому не знаю насколько людям можно давать инфы по объему.
Как-то хочется чтобы показываемая часть была логически завершена, а обрывать после первой картинки топик в котором мало текста — это глупо.
К сожалению VisualSVN без Apache не ставится, а в определенных ситуациях это может стать препятствием.
В моем случае сервер уже был, и преставлять не дали.
1. запускаем TortoiseSVN-1.5.3.13783-win32-svn-1.5.2.msi
в процессе установки все значения оставьте как есть
дождитесь конца установки и перезагрузите компьютер.
Их применение важно при работе в команде, это своего рода стандарт кодирования без которого командная работа просто превратится в хаос и все друг друга поубивают в спорах у кого лучше.
Идея это основа, а реализация — её воплощение, которое может и не состоятся, потому что идеи бывают и дурацкие.
А как правильно написано в Perl Best Practices — плохо написанный и описанный код уже через полгода становиться неузнаваемым, будто вы его сами не писали.
Меня поражают эти не ленивые люди! Это же как надо не ценить свое время чтобы вместо одной строки переписывать 5, ошибаться в них, а потом в этих тоннах кода искать эти самые ошибки.
Программист обязан быть ленивым — лень заставляет оптимизировать решение и тратить на проблему меньше времени. Эта лень — не безделье, а стремление избавить себя от работы, которую может делать машина.
Когда у нас есть ксерокс — мне лень печатать копии на печатной машинке!
Очень удобно — сразу видно что/где и внутри чего.
p.s. дело вкуса, а я предпочитаю группировать так:
/* Header ----------------------------*/ #header {} /* даже если нет стилей, все равно указываю для соблюдения "каскадности" */ #header p { /* стили для p внутри header'а */ } #header ul { } #header ul li { } /* Content ----------------------------*/ div#content{ /* стили content'а */ } div#content p { /* стили для p внутри header'а */ } div#content ul { } div#content ul li { } /* Typographic ----------------------------*/Даже если определние блока пустое я все равно его пишу для «каскадности».
Если кодер не знает как винду переставить — это ли чистый кодер?
Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.
Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.
Помните, отрицательный результат — тоже результат. Желаю успеха.
Вот я подумал было, что введено ограничение на размер статьи, потому решил уж лучше 4 раза по чуть чуть, чем одна несуразица.
Я тут совсем недавно потому не знаю насколько людям можно давать инфы по объему.
Как-то хочется чтобы показываемая часть была логически завершена, а обрывать после первой картинки топик в котором мало текста — это глупо.
В моем случае сервер уже был, и преставлять не дали.
У Хабра есть ограничение на размер статьи? В хелпе не видел такого.
Мой журнал — это личное, а хабр сделает это общественным и донесет быстрее кругу специалистов.
Их применение важно при работе в команде, это своего рода стандарт кодирования без которого командная работа просто превратится в хаос и все друг друга поубивают в спорах у кого лучше.