да, я во время чистки мыши тоже как-то случайно потерял эту пружинку и соответственно научился делать колёсико тише.
А с Logitech VX Nano (и другими с аналогичным колёсиком) — даже этого делать не надо.
Ну что же — соблажнившись тем, что у меня такая же мышь как в ролике — решил последовать примеру.
Долго возился со вскрытием датчика — не помешало бы этот момент осветить чуть подробнее. Проще всего — просунуть узкое лезвие в щель около края с длинной стороны и одновременно потянуть крышку вверх. Второй вариант — подсунуть лезвие с узкой стороны вниз и потянуть вверх и к себе. Это несколько опаснее — крышка может треснуть.
Дальше всё делал по инструкции, но видимо сдвинул медную пластинку. И в результате правая кнопка перестала кликаться. Тупо белая кнопочка не доставала до контакта. Провозившись минут 40 и уже почти смирившись с потерей офигенной мыши — я вытащил полностью пластинку и вставил ей обратно. И сработало! Не дыша подрегулировал второй контакт и собрал мышь.
Кстати, устанавливать корпус датчика проще перевернув мышь уверху пузом — иначе белая кнопочка может выпасть и её будет очень сложно найти.
Спасибо за пост — теперь дествительно стало гораздо удобнее.
Ну в принципе автонакатывание альтеров и есть основная фишка, которая сильно раздражает при ежедневной работе. Плюс после автонаката можно делать деплой дев-версии приложения по крону хоть каждый час.
откатить изменение на самом деле не так просто — для этого придётся для каждого альтера писать антиальтер.
Но в принципе — за все годы не возникало такой необходимости ни разу.
Ещё одно важдное правило — альтер должен быть целиком заключён в транзакцию — чтоб при провале одной строки весь альтер не применялся и деплой скрипт должен это учитывать и не применять остальные альтеры при провале одного из них.
Мы уже давно пришли к следующей структуре:
Есть файл database.sql, который создаёт базу с нуля — там всегда самая свежая структура.
Есть каталог alters, в котором лежат файлы поименованные как:
001_2008_05_15.sql
002_2008_06_18.sql
003_2008_06_19.sql
…
Преимущество такого подхода — три позиции под номер дают возможность всегда выстраивать альтреры в хронологическом порядке. Дата позволяет примерно увидеть, насколько обновлялась база. Да и вообще не люблю давать осмысленные названия подобным файлам.
В конце каждого альтера стоит
update zp_maintenance set file='121_2009-04-13.sql', modiftime=now();
Благодаря этому мы всегда знаем какой альтер был применён последним в текущей копии базы данных и можем дотащить новые альтеры, если они появятся.
Ещё один немаловажный аспект — дисциплина разработчиков. При изменении структуры базы данных разработчики должны _сначала_ писать альтер, а потом применять его на свою копию. Никаких добавлений колонок в phpmyadmin и прочих.
джаббер децентрализирован в том смысле, что можно обмениваться сообщениями с пользователями других серверов. При подключении вы всегда присоединяетесь к своему родному серверу и не меняете его никогда. В мобильной сети же вы передвигаетесь между различными сотами. Или можете вообще всплыть в зоне действия другого оператора.
А если гравировать бинарную информацию на гранитных плитах и пересылать их куръерской почтой с экспресс доставкой — то получится ещё дороже.
Не надо сравнивать несравнимое — СМС обеспечивает гарантированное получение сообщения абонентом, даже если он в данный момент отключен или находится чёрт знает где. Никакой другой транспорт не обеспечивает такого.
Почему в смс влазит 160 символов, а не, скажем, 255?
В процессе «придумывания» SMS (а его именно «придумывали», т.к. в отличие от голоса/факса у SMS не было аналога в «проводном» мире) перед авторами спецификации встал вопрос — как передавать SMS-ы между коммутаторами? Было принято решение использовать механизмы, доступные в рамках стека протоколов SS7 (Signalling System #7). Протокол MAP (используемый MSC для передачи «сигнальной» информации о звонке в процессе коммутации — кто звонит, кому звонит, и т.п.) был расширен специальным сообщением «forward_short_message», содержимое которого, собственно, и является телом SMS.
Именно отсюда ростут ноги у известного ограничения. Протокол MAP основан на протоколе TCAP, который по своей природе предусматривал работу в режиме real-time, в стиле «короткий request — короткий responce». Естественно, что ни о какой фрагментации/сессиях в стиле TCP в рамках TCAP речь не шла. MAP унаследовал эту особенность.
Вот и получилось, что 1 SMS должен был обязательно влазить в одно MAP-сообщение. Максимальный размер payload в MAP — 140 байт или (140 * 8 = 1120 бит). В такое кол-во бит можно засунуть либо 160 7-битных символов, либо 140 8-битных, либо 70 16-битных (например, русских или украинских).
Вообще то это ПДД — занимать крайнюю правую полосу только для обгона, поворота направо и если все остальные полосы заняты. То что у нас туда все лезут — только следствие массового отсутствия культуры вождения.
Я разрабатывал аналогичный по назначению компонент и постараюсь дать пару дельных советов:
1) зачем вы намеренно усложняете жизнь пользователя, заставляя его формировать дерево со всеми этими
<li><span><a href="#111">1.1.1. Листик</a></span></li>
Все эти теги нужны только вашему скрипту, так пускай он их и расставляет сам, прозрачно для пользователя.
2) если на странице несколько деревьев — то каждое будет иметь одинаковый ID — парсер будет ругаться.
3) почему «multi-derevo», а не «multi-tree»? Или пишите на русском кириллическим алфавитом либо английский алфавитом на английском
4) если в ноде больше одной строки текста — чёрточки позиционируются по низу ноды — красивее было бы по середине.
5) ну и фич, конечно, совсем мало — как минимум не хватает подгрузки частей дерева по XHR, динамических чекбоксов итд.
записывать информацию в куки, которые передаются при каждом запросе элементов с этого каталога и ниже — это как минимум расточительно. Ограничьте видимость куки только текущей страницей, если это возможно.
У нас минимизация делается при nightly build'e и все ошибки сборки высылаются скриптом на емейл.
А с Logitech VX Nano (и другими с аналогичным колёсиком) — даже этого делать не надо.
Долго возился со вскрытием датчика — не помешало бы этот момент осветить чуть подробнее. Проще всего — просунуть узкое лезвие в щель около края с длинной стороны и одновременно потянуть крышку вверх. Второй вариант — подсунуть лезвие с узкой стороны вниз и потянуть вверх и к себе. Это несколько опаснее — крышка может треснуть.
Дальше всё делал по инструкции, но видимо сдвинул медную пластинку. И в результате правая кнопка перестала кликаться. Тупо белая кнопочка не доставала до контакта. Провозившись минут 40 и уже почти смирившись с потерей офигенной мыши — я вытащил полностью пластинку и вставил ей обратно. И сработало! Не дыша подрегулировал второй контакт и собрал мышь.
Кстати, устанавливать корпус датчика проще перевернув мышь уверху пузом — иначе белая кнопочка может выпасть и её будет очень сложно найти.
Спасибо за пост — теперь дествительно стало гораздо удобнее.
откатить изменение на самом деле не так просто — для этого придётся для каждого альтера писать антиальтер.
Но в принципе — за все годы не возникало такой необходимости ни разу.
Ещё одно важдное правило — альтер должен быть целиком заключён в транзакцию — чтоб при провале одной строки весь альтер не применялся и деплой скрипт должен это учитывать и не применять остальные альтеры при провале одного из них.
Есть файл database.sql, который создаёт базу с нуля — там всегда самая свежая структура.
Есть каталог alters, в котором лежат файлы поименованные как:
001_2008_05_15.sql
002_2008_06_18.sql
003_2008_06_19.sql
…
Преимущество такого подхода — три позиции под номер дают возможность всегда выстраивать альтреры в хронологическом порядке. Дата позволяет примерно увидеть, насколько обновлялась база. Да и вообще не люблю давать осмысленные названия подобным файлам.
В конце каждого альтера стоит
update zp_maintenance set file='121_2009-04-13.sql', modiftime=now();
Благодаря этому мы всегда знаем какой альтер был применён последним в текущей копии базы данных и можем дотащить новые альтеры, если они появятся.
Ещё один немаловажный аспект — дисциплина разработчиков. При изменении структуры базы данных разработчики должны _сначала_ писать альтер, а потом применять его на свою копию. Никаких добавлений колонок в phpmyadmin и прочих.
В общем читайте: Почему 160 символов SMS — это не то же самое, что и 160 байт, переданых по GPRS
Не надо сравнивать несравнимое — СМС обеспечивает гарантированное получение сообщения абонентом, даже если он в данный момент отключен или находится чёрт знает где. Никакой другой транспорт не обеспечивает такого.
В процессе «придумывания» SMS (а его именно «придумывали», т.к. в отличие от голоса/факса у SMS не было аналога в «проводном» мире) перед авторами спецификации встал вопрос — как передавать SMS-ы между коммутаторами? Было принято решение использовать механизмы, доступные в рамках стека протоколов SS7 (Signalling System #7). Протокол MAP (используемый MSC для передачи «сигнальной» информации о звонке в процессе коммутации — кто звонит, кому звонит, и т.п.) был расширен специальным сообщением «forward_short_message», содержимое которого, собственно, и является телом SMS.
Именно отсюда ростут ноги у известного ограничения. Протокол MAP основан на протоколе TCAP, который по своей природе предусматривал работу в режиме real-time, в стиле «короткий request — короткий responce». Естественно, что ни о какой фрагментации/сессиях в стиле TCP в рамках TCAP речь не шла. MAP унаследовал эту особенность.
Вот и получилось, что 1 SMS должен был обязательно влазить в одно MAP-сообщение. Максимальный размер payload в MAP — 140 байт или (140 * 8 = 1120 бит). В такое кол-во бит можно засунуть либо 160 7-битных символов, либо 140 8-битных, либо 70 16-битных (например, русских или украинских).
1) зачем вы намеренно усложняете жизнь пользователя, заставляя его формировать дерево со всеми этими
<li><span><a href="#111">1.1.1. Листик</a></span></li>
Все эти теги нужны только вашему скрипту, так пускай он их и расставляет сам, прозрачно для пользователя.
2) если на странице несколько деревьев — то каждое будет иметь одинаковый ID — парсер будет ругаться.
3) почему «multi-derevo», а не «multi-tree»? Или пишите на русском кириллическим алфавитом либо английский алфавитом на английском
4) если в ноде больше одной строки текста — чёрточки позиционируются по низу ноды — красивее было бы по середине.
5) ну и фич, конечно, совсем мало — как минимум не хватает подгрузки частей дерева по XHR, динамических чекбоксов итд.