Как-то, кстати, на маке вопрос пиратского софта у меня отпал — ни одной пиратской софтины нет, но ничего и не покупал: бесплатные программы + предустановленные + macheist'овые вполне покрывают все необходимости.
Ну просто имейте в виду, что отсутствием хотя бы мааленькой кнопочки Вы как минимум отсекаете всех, кто сидит с мобильных телефонов/устройств (> 7.5% у opera mini). Ну и тех людей, кто не догадается enter нажать, тут статистикой сразить не могу, данных не имею.
Удобства отсутствие кнопочки не добавляет никакого, задача вписать небольшую кнопку в форму, чтоб смотрелось хорошо — ни капли не сложная с точки зрения дизайна (гляньте, как круто это на хабре сделано).
Короче говоря, уверен, что конкретно этот тренд в упрощении дизайна — ошибочный.
Тоже не очень понял, почему применение хранимых процедур и триггеров отнесено к плюсам.
Разве что использование хранимых процедур и триггеров — это самоцель, обусловленная нуждами учебного процесса.
Помню, когда нам БД преподавали, процедуры и триггеры подавались крутыми штуковинами, атрибутами профессиональных СУБД, и их использование очень поощрялось. Пришлось мне как-то потом работать потом с одной legacy-системой, где разработчики, видимо, прониклись данной идеей размазывать часть логики в БД. Брр. Если есть какая-то возможность в СУБД — это еще не значит, что ее нужно обязательно использовать. Определенно, если человек знает только СУБД, он может с помощью хранимых процедур и т.д. сделать больше. И это, видимо, было проблемой у нас в университете, т.к. человек, нам БД преподававший, в программировании особо не разбирался.
Дизайн хреновый, лучше б дизайнера найти, или просто все украшательства выкинуть, перекрасить, например, просто в чб или чб+какой-то цвет, и отступы в порядок привести. А то оранжевый текст на голубом фоне — это не очень круто.
jquery-guys знают толк в маркетинге) полезность для программиста стремится к 0, но эта штука способна сильно увеличить количество jquery-адептов за счет новичков, дизайнеров и т.д.
Смысл в том, что при использовании рефакторинга изменяется роль предварительного проектирования. Если не рассчитывать на рефакторинг, то ощущается необходимость как можно лучше провести предварительное проектирование. Возникает чувство, что любые изменения проекта в будущем, если они потребуются, окажутся слишком дорогостоящими. Поэтому в предварительное проектирование вкладывается больше времени и усилий — во избежание таких изменений впоследствии.
С применением рефакторинга акценты смещаются. Предварительное проектирование сохраняется, но теперь оно не имеет целью найти единственно правильное решение. Все, что от него требуется — это найти приемлемое решение. По мере реализации решения, с углублением понимания задачи становится ясно, что наилучшее решение отличается от того, которое было принято первоначально. Но в этом нет ничего страшного, если в процессе участвует рефакторинг, потому что модификация не обходится слишком дорого.
Indeed with a disciplined team, I would usually prefer to use a DVCS on a CI project than a centralized one. With a less disciplined team I would worry that a DVCS would nudge people towards long lived branches.
Сторонники DVCS могут спокойно продолжать считать проблему надуманной, а сторонники VCS для CI — проблему реальной. Мне кажется, правы обе стороны в том, что проблема на самом деле будет где-то надуманной, а где-то она будет реальной. И не правы в том, что обобщают.
ну и другая выгода, в какой там раз другими словами :)
вот я написал 10 строчек глупого кода, написал еще 10 глупого кода, но все еще не понял, как лучше сделать умный. Я могу сделать ЧТО-ТО, что устранит дублирование кода, но это не устранит причину дублирования, и в 3й раз мне придется опять писать глупый код. Поэтому я не устраняю дублирование и пишу 3й раз 10 строчек глупого кода, которые уже помогают мне понять, как сделать код умным. Если с такой ситуацией не сталкивались, — вы очень умный, вам очень везет, или архитектурные проблемы, встающие перед вами, — несложные.
Удобства отсутствие кнопочки не добавляет никакого, задача вписать небольшую кнопку в форму, чтоб смотрелось хорошо — ни капли не сложная с точки зрения дизайна (гляньте, как круто это на хабре сделано).
Короче говоря, уверен, что конкретно этот тренд в упрощении дизайна — ошибочный.
Разве что использование хранимых процедур и триггеров — это самоцель, обусловленная нуждами учебного процесса.
Помню, когда нам БД преподавали, процедуры и триггеры подавались крутыми штуковинами, атрибутами профессиональных СУБД, и их использование очень поощрялось. Пришлось мне как-то потом работать потом с одной legacy-системой, где разработчики, видимо, прониклись данной идеей размазывать часть логики в БД. Брр. Если есть какая-то возможность в СУБД — это еще не значит, что ее нужно обязательно использовать. Определенно, если человек знает только СУБД, он может с помощью хранимых процедур и т.д. сделать больше. И это, видимо, было проблемой у нас в университете, т.к. человек, нам БД преподававший, в программировании особо не разбирался.
… +голос за mercurial, подошел идеально (разработка в небольшой команде, без сидения в офисе).
Дизайн хреновый, лучше б дизайнера найти, или просто все украшательства выкинуть, перекрасить, например, просто в чб или чб+какой-то цвет, и отступы в порядок привести. А то оранжевый текст на голубом фоне — это не очень круто.
bitbucket.org/akoha/django-lean/wiki/Home — django-приложение для a/b тестирования
Смысл в том, что при использовании рефакторинга изменяется роль предварительного проектирования. Если не рассчитывать на рефакторинг, то ощущается необходимость как можно лучше провести предварительное проектирование. Возникает чувство, что любые изменения проекта в будущем, если они потребуются, окажутся слишком дорогостоящими. Поэтому в предварительное проектирование вкладывается больше времени и усилий — во избежание таких изменений впоследствии.
С применением рефакторинга акценты смещаются. Предварительное проектирование сохраняется, но теперь оно не имеет целью найти единственно правильное решение. Все, что от него требуется — это найти приемлемое решение. По мере реализации решения, с углублением понимания задачи становится ясно, что наилучшее решение отличается от того, которое было принято первоначально. Но в этом нет ничего страшного, если в процессе участвует рефакторинг, потому что модификация не обходится слишком дорого.
Indeed with a disciplined team, I would usually prefer to use a DVCS on a CI project than a centralized one. With a less disciplined team I would worry that a DVCS would nudge people towards long lived branches.
Сторонники DVCS могут спокойно продолжать считать проблему надуманной, а сторонники VCS для CI — проблему реальной. Мне кажется, правы обе стороны в том, что проблема на самом деле будет где-то надуманной, а где-то она будет реальной. И не правы в том, что обобщают.
вот я написал 10 строчек глупого кода, написал еще 10 глупого кода, но все еще не понял, как лучше сделать умный. Я могу сделать ЧТО-ТО, что устранит дублирование кода, но это не устранит причину дублирования, и в 3й раз мне придется опять писать глупый код. Поэтому я не устраняю дублирование и пишу 3й раз 10 строчек глупого кода, которые уже помогают мне понять, как сделать код умным. Если с такой ситуацией не сталкивались, — вы очень умный, вам очень везет, или архитектурные проблемы, встающие перед вами, — несложные.