у меня подобная вещь, при этом чуть менее закрепленная
ношу более года в рюкзаке, иногда в заднем кармане (ширина на 15мм меньше паспорта) и работает великолепно - 95% софта работают с него, плюс клипарты/доки/музыка там же
сейчас уже начинаются легкие сбои, думаю искать замену на всякий; однако считаю стабильный год при очень активном использовании - это более чем хорошо )
О Боги!
больше года пользую винт 2,5" на 80Гб с переходником IDE2USB за 300р.
Толщина 9мм, "отсутствие надобности во внешнем источнике питания";), индикатор, в комплекте красивый и приятный "кожаный" чехол. Узор нанести можно самому и причем какой вздумается.
После готовых решений (сразу коробочка, без переходника), которым уже несколько лет, плюсы Tomato в том, что она подтолкнет компании к выпуску более изысканных девайсов.
ЗЫ: украшать таки лучше самому, а то где же тут гиковость? ))
тьфу, не обратил внимания на дату
однако, почитав ваши посты, считаю комментарий очень уместным
когда вы пишете код, это ваш код и ваше дело, как он выглядит
когда же вы выкладываете код для всеобщего ознакомления, стоит все-таки делать его максимально понятным и разложенным по полочкам
про id да, наврал
а вот for тоже хорошо работает в setAttribute
проблема в том, что если не заключать for в кавычки, его нельзя использовать как ключ хэша, больше этот атрибут мне проблем не доставлял )
я бы, вклиниваясь в диалог, с вами поспорил.
по поводу вашего комментария
а) крошки надо стирать со стола, причины, думаю, объяснять не надо ;)
б) множество людей приемлет любой вариант, а другое множество не четко структурированный код будет изучать дольше; если первому множеству не важно, может стоит потратить минуту ради второго?
мое же мнение - демонстрируя код, надо описывать алгоритм программы, пользуясь каноническими if/for/while/etc в нужных местах, это ведь демонстрация
а конечная реализация все равно будет зависеть от разработчика и будет скорее всего сильно ужата до нечитабельности (убраны лишние пробелы/скобки)
насколько я помню, это только id (не знаю уж причины к сожалению), class (так как используется для других целей, а для указания класса нужен className) и style (некроссбраузерно и по моему удобнее делать через хеш стилей)
Украду:
- переменное кол-во аргументов; я "детей" указывал в массиве третьим параметром
Вам посоветую:
- стили тоже может быть стоит в массив загонять? я так делаю - удобнее и практичнее
- class, for (label for="..."), как уже выше сказали, надо заключать в кавычки/апострофы - это правильнее, к тому же это позволит убрать toLowerCase =)
- насколько помню (сейчас лениво проверять) id надо тоже отдельно обрабатывать - не через setAttribute, а прямым назначением
- у меня ф-ия называется node, имхо более соответствует
что-то в этом есть, но тут требуются еще идейки, например изменение размера ссылки, вывод ее опять на первый план, но, разумеется, с ограничениями
и я бы советовал favicon отрисовать вручную, как минимум точку над i
нет, нет, я понимаю. пожалуй, слишком резко сказал, признаю
однако использование клиентского баланса как полного решения проблемы нагрузок (автор как раз на этом настаивает, как мне кажется) слишком самоуверенно )
и минусы в статье указать действительно стоит.
а как идея - хорошо; может придется использовать, надо смотреть на нагрузки
по-моему это все глупо по одной лишь причине:
клиентское приложение нужно изначально загрузить с сервера, и уж если он лежит, то все труды по клиентской балансировке до этого самого клиента просто не дойдут.
а если серверная балансировка нужна обязательно, то необходимость балансировки клиентской уже ставится под сомнение...
Правила хорошие конечно, про шрифты особенно хочется дизайнерам вдалбливать...
Но нет самого главного по моему мнению правила.
Учитывать то, что окошко браузера не совпадает с таковым в фотошопе.
Ну почему нельзя представить, что элемент с этой красивой рамкой может растягиваться? Как можно делать картинки, обрезанные по нижнему краю, или занимающие ровно n пикселей в ширину для фона? Ну и ошибки в таком духе...
ношу более года в рюкзаке, иногда в заднем кармане (ширина на 15мм меньше паспорта) и работает великолепно - 95% софта работают с него, плюс клипарты/доки/музыка там же
сейчас уже начинаются легкие сбои, думаю искать замену на всякий; однако считаю стабильный год при очень активном использовании - это более чем хорошо )
больше года пользую винт 2,5" на 80Гб с переходником IDE2USB за 300р.
Толщина 9мм, "отсутствие надобности во внешнем источнике питания";), индикатор, в комплекте красивый и приятный "кожаный" чехол. Узор нанести можно самому и причем какой вздумается.
После готовых решений (сразу коробочка, без переходника), которым уже несколько лет, плюсы Tomato в том, что она подтолкнет компании к выпуску более изысканных девайсов.
ЗЫ: украшать таки лучше самому, а то где же тут гиковость? ))
однако, почитав ваши посты, считаю комментарий очень уместным
когда вы пишете код, это ваш код и ваше дело, как он выглядит
когда же вы выкладываете код для всеобщего ознакомления, стоит все-таки делать его максимально понятным и разложенным по полочкам
а вот for тоже хорошо работает в setAttribute
проблема в том, что если не заключать for в кавычки, его нельзя использовать как ключ хэша, больше этот атрибут мне проблем не доставлял )
пока что просто по таймауту проверяю наличие body
по поводу вашего комментария
а) крошки надо стирать со стола, причины, думаю, объяснять не надо ;)
б) множество людей приемлет любой вариант, а другое множество не четко структурированный код будет изучать дольше; если первому множеству не важно, может стоит потратить минуту ради второго?
мое же мнение - демонстрируя код, надо описывать алгоритм программы, пользуясь каноническими if/for/while/etc в нужных местах, это ведь демонстрация
а конечная реализация все равно будет зависеть от разработчика и будет скорее всего сильно ужата до нечитабельности (убраны лишние пробелы/скобки)
Украду:
- переменное кол-во аргументов; я "детей" указывал в массиве третьим параметром
Вам посоветую:
- стили тоже может быть стоит в массив загонять? я так делаю - удобнее и практичнее
- class, for (label for="..."), как уже выше сказали, надо заключать в кавычки/апострофы - это правильнее, к тому же это позволит убрать toLowerCase =)
- насколько помню (сейчас лениво проверять) id надо тоже отдельно обрабатывать - не через setAttribute, а прямым назначением
- у меня ф-ия называется node, имхо более соответствует
10-ю комментариями выше =)
а это как раз и есть весьма удачная вариация на тему, уж точно лучше сотен клонов "миллионов пикселей"
и я бы советовал favicon отрисовать вручную, как минимум точку над i
однако использование клиентского баланса как полного решения проблемы нагрузок (автор как раз на этом настаивает, как мне кажется) слишком самоуверенно )
и минусы в статье указать действительно стоит.
а как идея - хорошо; может придется использовать, надо смотреть на нагрузки
клиентское приложение нужно изначально загрузить с сервера, и уж если он лежит, то все труды по клиентской балансировке до этого самого клиента просто не дойдут.
а если серверная балансировка нужна обязательно, то необходимость балансировки клиентской уже ставится под сомнение...
зы: сорри за поднятие старой темы
Но нет самого главного по моему мнению правила.
Учитывать то, что окошко браузера не совпадает с таковым в фотошопе.
Ну почему нельзя представить, что элемент с этой красивой рамкой может растягиваться? Как можно делать картинки, обрезанные по нижнему краю, или занимающие ровно n пикселей в ширину для фона? Ну и ошибки в таком духе...
Высекать правило в заголовке фотошопа.
провокация
насчет оперы не знаю, не задумывался пока что