Для полного счастью можно попотеть и написать авторегалку с этими данными =) причем все остальные поля заполняет произвольно, но правдоподобно (большинство таких полей можно ведь и угадать: фамилия там, mail...)
И потом все, кто будут юзать эту программу, будут ходить под одним и тем же юзверем ) может быть, тогда создатели подобных сайтов задумаются?
Для того, чтобы узнать, сколько людей скачало файл, достаточно при отдаче файка цвеличивать счетчик ) думаю, не очень много найдется людей, которые буду закачивать повторно.
Это значит, что на этапе проектирования сознательно не учли, что данные можно вводить неполностью. Подчеркиваю — сознательно. Потому что если несознательно, то проектировщику нужно менять работу вследствие профнепригодности. =)
Любой программист может написать все.
Имея бесконечные деньги и время (с).
А вот написать это быстро, качественно, с минимальными затратами на поддержку и расширяемость — этим и сказывается отличие между отличными, хорошими и средними программистами.
Видимо, есть те, кто заходит туда так, побаловаться )
Ты же не будешь себя сравнивать с кем-то, кто написал Hello World и уже считает себя крутым программером, и, чтобы это подтвердить, проходит тест на brainbench? (есс-но, провально проходит)
… Зато к дневникам Леонардо да-Винчи до сих пор никого не подпускают ) насколько я слышал, он еще в свое время описал строение атома.
Так что спорно все это, спорно… тема для философии, и уж точно выходит за рамки хабра.
Можно навязчиво показывать пользователю при первом входе на сайт надпись «Для регистрации наберите любые логин и пароль, и они будут закреплены за Вами». И создавать куку, что юзер уже заходил на сайт, и при повторном заходе сообщение уже не показывать.
А также для адаптации сделать ссылку «Регистрация», при нажатии на которую отобразится это же сообщение.
Комментарии нужны в следующих случаях:
1) Для участков кода, которые планируется потом переписать (не было времени, решил оставить коммент, а потом отрефакторить).
2) Для внешнего API какой-либо подсистемы или технологии. Это действует только для продуманного API (приведу в пример J2SE API). Если API создается а-ля «тут и так все понятно, зачем минимизировать интерфейс? Даешь гибкость!», то комментарии не работают.
3) Для библиотек классов, ориентированных на наследование другими разработчиками. В этом случае иногда не спасает даже наличие исходников, потому что необходимо четко понимать, из каких соображений разработчик поместил в базовый класс тот или иной метод, а на такой анализ уходит очень много драгоценного времени.
4) Для верхнеуровнего описания алгоритма или бизнес-операции. Хороший пример: вначале пишем верхнеуровневым псевдокодом (практически человеческий язык), потом каждую часть псевдокода кодируем, а сам псевдокод становится комментарием.
5) Для описания сложных участков, возникших в результате оптимизации. Если для целей оптимизации пришлось пренебречь понятностью, необходимо также предложить понятный вариант.
6) Требование заказчика. В этом случае дернуться особо некуда. Единственное — имеет смысл убедить его, что нужно документировать в соответствии с вышеописанными пунктами, и не более того. Иначе получим documentation hell.
Комментарии категорически НЕ нужны, когда:
1) Комментарий описывает КАК сделано, а не ЧТО и ДЛЯ ЧЕГО сделано.
2) Принятая структура документирования (например, JavaDOC) навязывает описание тех частей, которые и так понятны (например, параметры метода).
3) Комментарий описывает непонятную логику. В этом случае имеет смысл все переписать, а не комментировать.
4) Комментарии отражают части длинного алгоритма. В этом случае имеет смысл вынести эти части в отдельные методы. Очень часто при этом необходимость в комментариях отпадает.
P.S. В понимании всего вышенаписанного очень помогает книжка «Совершенный код».
Я лично читаю ) например, первый раз зашел на сайт, и в интересующем меня разделе я этак за недельку комменты прочитаю ) или если интересная статья попалась — тоже.
Остается проблема в логировании ) Доставка-то не гарантируется, а вот логирование того факта, что сообщение Вам доставлено, на стороне почтовика — это уже хуже )
И потом все, кто будут юзать эту программу, будут ходить под одним и тем же юзверем ) может быть, тогда создатели подобных сайтов задумаются?
Имея бесконечные деньги и время (с).
А вот написать это быстро, качественно, с минимальными затратами на поддержку и расширяемость — этим и сказывается отличие между отличными, хорошими и средними программистами.
Можно, например, для самопроверки ничем не пользоваться.
Или у тебя была Windows 98?
Ты же не будешь себя сравнивать с кем-то, кто написал Hello World и уже считает себя крутым программером, и, чтобы это подтвердить, проходит тест на brainbench? (есс-но, провально проходит)
Так что спорно все это, спорно… тема для философии, и уж точно выходит за рамки хабра.
Вот enum в Java позволяет сделать это полиморфизмом, в итоге надобность в switch практически отпадает.
А также для адаптации сделать ссылку «Регистрация», при нажатии на которую отобразится это же сообщение.
Комментарии нужны в следующих случаях:
1) Для участков кода, которые планируется потом переписать (не было времени, решил оставить коммент, а потом отрефакторить).
2) Для внешнего API какой-либо подсистемы или технологии. Это действует только для продуманного API (приведу в пример J2SE API). Если API создается а-ля «тут и так все понятно, зачем минимизировать интерфейс? Даешь гибкость!», то комментарии не работают.
3) Для библиотек классов, ориентированных на наследование другими разработчиками. В этом случае иногда не спасает даже наличие исходников, потому что необходимо четко понимать, из каких соображений разработчик поместил в базовый класс тот или иной метод, а на такой анализ уходит очень много драгоценного времени.
4) Для верхнеуровнего описания алгоритма или бизнес-операции. Хороший пример: вначале пишем верхнеуровневым псевдокодом (практически человеческий язык), потом каждую часть псевдокода кодируем, а сам псевдокод становится комментарием.
5) Для описания сложных участков, возникших в результате оптимизации. Если для целей оптимизации пришлось пренебречь понятностью, необходимо также предложить понятный вариант.
6) Требование заказчика. В этом случае дернуться особо некуда. Единственное — имеет смысл убедить его, что нужно документировать в соответствии с вышеописанными пунктами, и не более того. Иначе получим documentation hell.
Комментарии категорически НЕ нужны, когда:
1) Комментарий описывает КАК сделано, а не ЧТО и ДЛЯ ЧЕГО сделано.
2) Принятая структура документирования (например, JavaDOC) навязывает описание тех частей, которые и так понятны (например, параметры метода).
3) Комментарий описывает непонятную логику. В этом случае имеет смысл все переписать, а не комментировать.
4) Комментарии отражают части длинного алгоритма. В этом случае имеет смысл вынести эти части в отдельные методы. Очень часто при этом необходимость в комментариях отпадает.
P.S. В понимании всего вышенаписанного очень помогает книжка «Совершенный код».
Так можно )