Ну… на все болезни лекарств может и не хватить.
Значит ставим кондер на запас питалова и страницу кешируем, когда в оперативке накопятся эти 256 байт, пишем страницу в EEPROM. Либо когда внешнее питалово пропало, тоже сбрасываем кеш «на диск».
Конечно, можно возразить, что нет у нас нигде лишних 256 байт для кеша, и девайс мы не с нуля разрабатываем, а исключительно старье перешиваем, в схему сильно не вмешаешься и т.п.
Но в частных случаях вешаются частные костыли.
В большинстве же случаев, как правило, девайс мы делаем сами. Ну не берите эту микрочиповскую память, возьмите другую.
В случае допиливания готового девайса повесьте сверху свою платку со своей EEPROM. Вплоть до дополнительного контроллера на этой платке, эмулирующего наружу(для остальной схемы) работу старой EEPROM.
Или между процом и EEPROM(не меняя ее) повесить платку с Тинькой и вышеописанным кондером-бесперебойником. При невысоких частотах Тиньке должно хватить мозгов работать как EEPROM-Proxy и держать в себе этот гребаный кеш в 256 байт.
100 тыс записей на ячейку. А значит, от того, сколько у нас емкость EEPROM и какой длины данные нужно писать каждую секунду, будет зависеть, на длину суток какой именно планеты ее хватит.
Иными словами, если нам нужно ежесекундно сохранять туда несколько байт какого-либо состояния, а памяти этой у нас — десятки килобайт, то применив любой простенький алгоритм циклической записи, мы поимеем время жизни EEPROM те самые годы. Да еще и лог в несколько сотен последних записей с девайса можно снять всегда.
Интетесно, можно ли его применить для нестандартных целей, типа создания печатных плат аля ЛУТ или печать на пленке для фоторезиста(по идее гелевые чернила должны быть жирнее, чем тонер с лазерника, который приходится феном пропекать дополнительно при косяках насыщенности печати). А так же для термотрансфера изображений куда-либо.
Когда-то я имел доступ к принетру Xerox Phaser, который для печати использовал твердые чернила в брусках таких. Основа чернил похожа на восковую или парафиновую на ощупь. При печати на глянцевой бумаге потом утюгом на футболки отлично картинки переводились, без всяких спецбумаг.
Просто интереса ради хотелось бы узнать, а что этот принтер умеет с точки зрения «нестандартного» использования?
Тогда в чем по-вашему заключается воровство, когда вы покупаете у кого-то права на какую-то технологию и ее используете? Только в том, что купили ее дешевле, чем она могла бы стоить?
Мы не можем знать точно, почему Эппл грызется по этому поводу. Я имею в виду истинные мотивы вообще всей подобной грызни. Так что я не могу вам ответить на этот вопрос, извините.
Раньше вероятно не грызлись и не нападали на MS потому, что в те времена законодательство было другим, и в частности в отношении цифрового контента можно сказать этого законодательства вообще не было.
>> на основе того что кто то позаимствовал черты их продукта, который они сделали на основе чужих наработок
Про «позаимствовал черты их продукта» мы как раз и узнаем какие-то подробности по мере прохождения судебного процесса. И вроде как в общих чертах уже знаем, к чему предъявляются претензии. Однако, как водится, все-равно узнаем далеко не все. Всего нам не откроют )
Про «на основе чужих наработок» вы что имеете в виду? Рассуждения дизайнера Sony в какой-то газете в текстовом виде? Или что-то другое? Кстати, надо бы накопать эту самую газету, почитать, что он там говорил вообще. Что-то мне подсказывает, что там максимум может хватить на дизайн-концепт в словестной форме, но никак не на «наработки».
>> Ибо получается Аппл подсмотрела у Сони
Пока что этого не получается. Инфы данного поста не достаточно, чтоб делать однозначный вывод. Читайте сам пост внимательнее. Картинка в посте — это рендер дизайнера Эппл, судя по всему, под впечатлением от той статьи. То есть то, как этот дизайнер представил себе описанное в статье устройство от дизайнера Сони. Но никак не то, как этот девайс могла видеть сама Сони или этот ее дизайнер. Так что именно Эппл у них подсмотрела?
Опять же — надо откопать тут статью и почитать, что там вообще есть. А то так и будем пальцем в небо тыкать.
В целом статья хороша, плюсанул. Но замечание у меня все же есть.
ИМХО, не стоит расшаривать между несколькими процессами одно и то же соединение с БД, если вы не знаете, как именно клиентское API данной БД ведет себя в таких случаях. Можно нарваться на рассинхронизированную ситуацию, когда запросы к БД и ответы перемешаются в сокетах.
Вообще гуайды рекомендуют непосредственно перед fork() закрывать все дескрипторы, кроме тех с которыми вы «точно знаете, что делаете», типа слушающих сокетов.
В большинстве случаев будет правильным устанавливать в каждом клиенте свое соединение с БД после fork(). Тогда и закрытие коннекта в каждом клиенте не вызовет описанных в посте проблем.
Похоже на то. Только данная ситуация никак не доказывает, что именно эта идея была взята яблоками для своего девайса. Такие идеи на тот момент уже давно витали в воздухе. Из недавних новостей мы так же знаем, что концепт планшета без лишних кнопок и физических элементов управления рассматривался яблоками еще в девяностых, но был отвергнут и «задвинут на полку». А в феврале 2006 яблотелефон уже явно разрабатывался. Возможно, на тот момент внешний дизайн еще не был определен. Возможно данное описание дизайнера Sony как-то повлияло на конечный дизайн яблофона, а возможно — нет. Может это было просто отдельным случаем из множества подобных: ну озвучил дизайнер Sony свое видение концепта, ну наваял дизайнер Эппла вариант CAD-модели под впечатлением из той статьи. И что?
Просто как пример. Когда-то давно был у нас один проектик: веб-аська 911. Суть была в том, чтобы люди могли сидеть в ICQ из браузера, в то время как у многих на работе админы закрывали порты кроме веба. Тогда еще не было QIP, Meebo и подобных проектов.
Потом появились конкуренты из Питера, потом мы нашли еще несколько более мелких(по нагрузочной способности) конкурентов из Новосиба, Красноярска и еще каких-то городов. Со временем все эти проекты заглохли.
В основном конечно мы бодались с питерцами, при чем появились оба проекта практически одновременно, трудно даже сказать, кто первее. Но не суть. Мы поначалу взаимно друг друга обвиняли в плагиате, а потом нашли остальных и пораскинули мозгами. Пришли к выводу, что никто ни у кого ничего не пер. Просто в одно время появилась в сети инфа о реверс-инжиниринге протокола аськи с описанием базового протокола, и идея создания веб-сервиса просто таки сама витала в воздухе — вот и причина появления стольких на первый взгляд клонов. Дальнейший анализ функционала каждого «клона» это только подтвердил — было взято общедоступное описание реверснутого протокола(основные пакеты) и дальше каждая команда самостоятельно продолжила анализ и распознавание всех остальных сервисных пакетов.
Я это к чему — не всегда появление в прессе каких-то идей, предшествующее выходу другого продукта на рынок, является причиной этого самого выхода.
Сейчас начинается тяжелый судебный процесс — с обоих сторон полетят какие-то факты, документы и их интерпретация сторонами, перерасставление акцентов, умалчивание каких-то нюансов и т.п. Журналюги тоже сделают свое дело, выдавая в прессе желаемое за действительное. Не нужно верить каждому такому факту как истине в последней инстанции. Мы все-равно будем видеть лишь «верхушку айсберга».
Так или иначе, реальную правду мы узнаем уже после того, когда эта самая правда не сможет навредить репутации и финансам этих компаний. Тогда, когда правда будет опубликована уже для истории, и то это еще не гарантия, что это будет вся правда.
А до этого верить что доводам в суде, что домыслам журналистов — занятие неблагодарное.
Если подумать, то есть разница между «купить за бесценок» и «нагло спереть».
Иными словами, в том же фильме «Пираты Силиконовой долины» четко показана разница между тем, как Эппл получила мышь и графический интерфейс у Xerox SPARC и между тем, как Билли, работая на Эппл, впоследствии начал самостоятельно продавать все эти наработки.
Да, Эппл сыграла на некомпетентности «больших начальников» Xerox и перекупила их технологии за копейки. Но это бизнес, воровством тут и не пахнет.
На воровство тут больше похожа ситуация с MS. Хотя впоследствии через годы, как мы знаем, Билли и Стиви закрыли вопрос полюбовно.
Та же ситуация с появлением MS DOS. MS тоже ее не разработала с нуля — выкупила за полтинник у разработчика, после чего со временем допилила. Однако это же тоже не воровство.
То есть то, что и те и другие что-то не сами придумали, еще не делает их ворами.
Да не вопрос, я как бы в курсе про глицерин сам по себе ))
Вы немного контекст не поняли, я не давал рецепт отдельного флюса с уникальными свойствами — по контексту выше просто дал еще один вариант растворения канифоли.
Сами по себе и канифоль и глицерин с точки зрения качества пайки мало чем отличаются. Глицерин проще отмывать, тут вы безусловно правы. Его можно водой, а канифоль — спиртом.
Однако и то и другое — жидкое. А смесь обоих компонентов можно сделать густой и не сохнущей(в отличии от канифоли в спирте), что может быть удобно в определенных ситуациях.
Например при пайке SMD. Удобнее конечно любой флюс плюс паяльная паста — на нее компоненты клеятся перед пайкой, в ней уже есть припой, останется только нагреть. Но если у кого нет этой самой паяльной пасты, то можно сделать почти то же самое проще: нарезаем проволочный припой мелкими кусочками, мажем площадки этой канифольно-глицериновой пастой(ну как мажем… сгусток прям зубочисткой кладем), ставим туда компонент и бросаем рядом по кусочку припоя. За счет густоты флюса все прилипает к площадкам не хуже, чем на паяльную пасту.
Можно приклеить и на спирто-канифоль, но это на порядки неудобнее — спирт быстро испаряется, нужно ловить момент удобного приклеивания. На чистый глицерин особо ничего не приклеишь.
Кроме прочего, при пайке растворенной канифолью(в обоих случаях) ее количество будет достаточно мало, чтобы загадить плату настолько, чтоб затруднить визуальный контроль пайки, как это описывается у автора. Так что если эстетичность платы не нужна, то можно и не мыть потом.
P.S. А так-то конечно да. Глицерином тоже можно паять, более того — он гиппоалергенен, почти не горит — испаряется практически весь. А если в него добавить соответствующий ароматизатор, процесс пайки становится гламурным — вокруг витают запахи, как кальян куришь, жена не злая ходит, говорит «Паяй еще!» )))
Собственно в «мокрых» кальянных табаках тоже варенье на основе глицерина используется. В электронных сигаретах основа жидкости так же либо на пропилен-гликоле, либо на глицерине, либо на их смеси. Ароматизаторы обычно достаточно термостойки и врядли при их мизерном количестве как-либо повлияют на качество пайки.
Но это я уже отвлекся от темы )))
Глицерин жидкий. Канифоль в глицерине — густая бежевая паста(сама по себе никуда не течет практически).
Удобно, например, нанести зубочисткой на пады и на нее же «приклеить» SMD перед пайкой.
В остальном по свойствам оно ничем не отличается от остальных вариантов канифолевых флюсов.
То есть смысл — чисто в консистенции и в том, что глицерин не дает ей высыхать, в отличии от быстросохнущего спиртораствора. А так и то и другое — само по себе флюс, и смешивая их в нужной пропорции, можно получить нужную густоту раствора/пасты.
И то и другое. Можно купить готовый во флакончике с кисточкой, можно сделать самому — тупо спирт и в нем растворить канифоль.
Еще можно ее растворить в глицерине — дольше растворяет, но на выходе будет что-то вроде паяльного жира — густая такая паста. Если добавить немного пропиленгликоля, будет расворять чуть быстрее и на выходе паста будет менее вязкая.
Для EMS, по крайней мере в Москве, индекс не столь важен. Индекс — это номер почтового отделения Почты России. Соответственно для EMS особой ценности не представляет.
Т.к. для почты отправителя в адресе важна только страна, а вся остальная часть адреса — исключительно для наших почтовых работников, можно попробовать нарисовать адрес по-понятнее для них, типа как-то так:
Russia, 109462, Moscow,
UVAO, ul. Marshala Chuykova (!!! a ne prospect Zhukova !!!) 12k1-34,
+79031234567
Конечно не факт, что гарантированно поможет, можно нарваться на непрошибаемого работника, но все же…
А вы не пробовали рисовать актуальные телефоны(обычно одного мобильника достаточно) прямо в адресе доставки при заказе? Не доверяйте на сайтах полю для телефона — это еще не гарантия, что напечатают его на посылке. Просто дублируйте телефон прямо в адресе — в поле Street Line2 или прямо в той же строке, где улица-дом-квартира. Большинство магазинов лейбу на посылку печатают автоматом, так что это гарантия, что телефон на ней будет.
У вас курьер один и тот же(обычно один на район закреплен)? Если да, при очередной доставке возьмите у него номерок и звоните заранее, чтоб не забирал.
Я своего курьера знаю, он меня тоже. Номерами давно обменялись.
Могу позвонить, мол «Завтра не забирай, посылка дорогая, поеду сам забирать с актом вскрытия», или «Я на работу выезжаю, ты где? Где пересечься можем на районе?» — часто мне удобнее подъехать куда-либо, чем ждать полдня пока он по списку до меня доедет.
Или он звонит в 7-8 утра: «Тут тебе посылку забираю, она сильно мятая/порвана. Забирать или сам поедешь с актами вскрывать?».
Ну и тому подобные ситуации. Это удобно.
Конкретному разработчику возможно и будет удобнее ежедневно инклудить файлы по коротким именам. Особенно если разработчик пользуется редактором аналогом «блокнота» без всяких автодополнений и тому подобных фич.
Символ "_" используется в именах файлов всеми и везде. Символ "$", как Вы правильно заметили, может подложить свинью в регулярках. Постоянно об этом помнить и постоянно экранировать… Сомнительное удовольствие. Впрочем, если вы простой кодер, не работающий в команде — это ваше дело, как и где извращаться. Если это поможет разработке — да не вопрос. Все замечательно. В команде об этом должны уже помнить все. Хотя пример безусловно «натянутый» — регулярками парсить список файлов на сервере — это конечно редкость.
Однако все-равно совет укорачивать имена файлов до максимума в виде статьи на Хабре — условно выглядит как призыв всем писать сразу обфусцированный код. Я могу предложить Вам имена функций тоже делать как можно более короткими. Не до a(), b(), c() конечно, но ведь тоже можно str_truncate_spaces() переименовать в sts() или в s_ts(), если первое «s» — префикс текущей либы.
Еще можно инклудить всегда только файл "$.js"(или "_.js"), а в нем с помощью SSI(Server Side Includes) инклудить все остальные библиотеки, или хотя бы часто используемые. Оно и разработчику будет проще, и кешироваться в браузере будет, и все такое.
У меня столько идей на такие темы ))))
Другой вопрос, а нужно ли оно в принципе…
Ну здесь тем более неоднозначно. Ковыряться в неассоциативных именах файлов, пусть и коротких, неудобнее, чем в длинных, но с четким пониманием по названию, что это за файл и что там внутри.
Да и то же использование символа доллара($) в именах файлов хоть и вполне допустимо, но иногда имеет смысл его избегать — просто на всякий случай. А то может вылезти боком в совершенно неожиданной ситуации, которой теоретически быть не должно, но практически почему-то случилась. Удобства в одном месте по возможности не должы порождать неудобства в другом. Как-то так.
Если это у вас является настолько узким местом, что такие переименования могут чему-то существенно помочь, значит вашему проекту пришла жопа и пора его переписывать на Си и заново. Не поможет — переписывать на Asm пока не дойдет.
Другими словами — если проект так спроектирован, что такая мелкая оптимизация может заметно влиять на статистику нагрузки — это плохой проект.
О крайностях, типа веб-сервера на Atmel-контроллере, мы не говорим. Там это может пригодиться.
Значит ставим кондер на запас питалова и страницу кешируем, когда в оперативке накопятся эти 256 байт, пишем страницу в EEPROM. Либо когда внешнее питалово пропало, тоже сбрасываем кеш «на диск».
Конечно, можно возразить, что нет у нас нигде лишних 256 байт для кеша, и девайс мы не с нуля разрабатываем, а исключительно старье перешиваем, в схему сильно не вмешаешься и т.п.
Но в частных случаях вешаются частные костыли.
В большинстве же случаев, как правило, девайс мы делаем сами. Ну не берите эту микрочиповскую память, возьмите другую.
В случае допиливания готового девайса повесьте сверху свою платку со своей EEPROM. Вплоть до дополнительного контроллера на этой платке, эмулирующего наружу(для остальной схемы) работу старой EEPROM.
Или между процом и EEPROM(не меняя ее) повесить платку с Тинькой и вышеописанным кондером-бесперебойником. При невысоких частотах Тиньке должно хватить мозгов работать как EEPROM-Proxy и держать в себе этот гребаный кеш в 256 байт.
Иными словами, если нам нужно ежесекундно сохранять туда несколько байт какого-либо состояния, а памяти этой у нас — десятки килобайт, то применив любой простенький алгоритм циклической записи, мы поимеем время жизни EEPROM те самые годы. Да еще и лог в несколько сотен последних записей с девайса можно снять всегда.
Когда-то я имел доступ к принетру Xerox Phaser, который для печати использовал твердые чернила в брусках таких. Основа чернил похожа на восковую или парафиновую на ощупь. При печати на глянцевой бумаге потом утюгом на футболки отлично картинки переводились, без всяких спецбумаг.
Просто интереса ради хотелось бы узнать, а что этот принтер умеет с точки зрения «нестандартного» использования?
Раньше вероятно не грызлись и не нападали на MS потому, что в те времена законодательство было другим, и в частности в отношении цифрового контента можно сказать этого законодательства вообще не было.
>> на основе того что кто то позаимствовал черты их продукта, который они сделали на основе чужих наработок
Про «позаимствовал черты их продукта» мы как раз и узнаем какие-то подробности по мере прохождения судебного процесса. И вроде как в общих чертах уже знаем, к чему предъявляются претензии. Однако, как водится, все-равно узнаем далеко не все. Всего нам не откроют )
Про «на основе чужих наработок» вы что имеете в виду? Рассуждения дизайнера Sony в какой-то газете в текстовом виде? Или что-то другое? Кстати, надо бы накопать эту самую газету, почитать, что он там говорил вообще. Что-то мне подсказывает, что там максимум может хватить на дизайн-концепт в словестной форме, но никак не на «наработки».
>> Ибо получается Аппл подсмотрела у Сони
Пока что этого не получается. Инфы данного поста не достаточно, чтоб делать однозначный вывод. Читайте сам пост внимательнее. Картинка в посте — это рендер дизайнера Эппл, судя по всему, под впечатлением от той статьи. То есть то, как этот дизайнер представил себе описанное в статье устройство от дизайнера Сони. Но никак не то, как этот девайс могла видеть сама Сони или этот ее дизайнер. Так что именно Эппл у них подсмотрела?
Опять же — надо откопать тут статью и почитать, что там вообще есть. А то так и будем пальцем в небо тыкать.
ИМХО, не стоит расшаривать между несколькими процессами одно и то же соединение с БД, если вы не знаете, как именно клиентское API данной БД ведет себя в таких случаях. Можно нарваться на рассинхронизированную ситуацию, когда запросы к БД и ответы перемешаются в сокетах.
Вообще гуайды рекомендуют непосредственно перед fork() закрывать все дескрипторы, кроме тех с которыми вы «точно знаете, что делаете», типа слушающих сокетов.
В большинстве случаев будет правильным устанавливать в каждом клиенте свое соединение с БД после fork(). Тогда и закрытие коннекта в каждом клиенте не вызовет описанных в посте проблем.
Просто как пример. Когда-то давно был у нас один проектик: веб-аська 911. Суть была в том, чтобы люди могли сидеть в ICQ из браузера, в то время как у многих на работе админы закрывали порты кроме веба. Тогда еще не было QIP, Meebo и подобных проектов.
Потом появились конкуренты из Питера, потом мы нашли еще несколько более мелких(по нагрузочной способности) конкурентов из Новосиба, Красноярска и еще каких-то городов. Со временем все эти проекты заглохли.
В основном конечно мы бодались с питерцами, при чем появились оба проекта практически одновременно, трудно даже сказать, кто первее. Но не суть. Мы поначалу взаимно друг друга обвиняли в плагиате, а потом нашли остальных и пораскинули мозгами. Пришли к выводу, что никто ни у кого ничего не пер. Просто в одно время появилась в сети инфа о реверс-инжиниринге протокола аськи с описанием базового протокола, и идея создания веб-сервиса просто таки сама витала в воздухе — вот и причина появления стольких на первый взгляд клонов. Дальнейший анализ функционала каждого «клона» это только подтвердил — было взято общедоступное описание реверснутого протокола(основные пакеты) и дальше каждая команда самостоятельно продолжила анализ и распознавание всех остальных сервисных пакетов.
Я это к чему — не всегда появление в прессе каких-то идей, предшествующее выходу другого продукта на рынок, является причиной этого самого выхода.
Сейчас начинается тяжелый судебный процесс — с обоих сторон полетят какие-то факты, документы и их интерпретация сторонами, перерасставление акцентов, умалчивание каких-то нюансов и т.п. Журналюги тоже сделают свое дело, выдавая в прессе желаемое за действительное. Не нужно верить каждому такому факту как истине в последней инстанции. Мы все-равно будем видеть лишь «верхушку айсберга».
Так или иначе, реальную правду мы узнаем уже после того, когда эта самая правда не сможет навредить репутации и финансам этих компаний. Тогда, когда правда будет опубликована уже для истории, и то это еще не гарантия, что это будет вся правда.
А до этого верить что доводам в суде, что домыслам журналистов — занятие неблагодарное.
Иными словами, в том же фильме «Пираты Силиконовой долины» четко показана разница между тем, как Эппл получила мышь и графический интерфейс у Xerox SPARC и между тем, как Билли, работая на Эппл, впоследствии начал самостоятельно продавать все эти наработки.
Да, Эппл сыграла на некомпетентности «больших начальников» Xerox и перекупила их технологии за копейки. Но это бизнес, воровством тут и не пахнет.
На воровство тут больше похожа ситуация с MS. Хотя впоследствии через годы, как мы знаем, Билли и Стиви закрыли вопрос полюбовно.
Та же ситуация с появлением MS DOS. MS тоже ее не разработала с нуля — выкупила за полтинник у разработчика, после чего со временем допилила. Однако это же тоже не воровство.
То есть то, что и те и другие что-то не сами придумали, еще не делает их ворами.
Вы немного контекст не поняли, я не давал рецепт отдельного флюса с уникальными свойствами — по контексту выше просто дал еще один вариант растворения канифоли.
Сами по себе и канифоль и глицерин с точки зрения качества пайки мало чем отличаются. Глицерин проще отмывать, тут вы безусловно правы. Его можно водой, а канифоль — спиртом.
Однако и то и другое — жидкое. А смесь обоих компонентов можно сделать густой и не сохнущей(в отличии от канифоли в спирте), что может быть удобно в определенных ситуациях.
Например при пайке SMD. Удобнее конечно любой флюс плюс паяльная паста — на нее компоненты клеятся перед пайкой, в ней уже есть припой, останется только нагреть. Но если у кого нет этой самой паяльной пасты, то можно сделать почти то же самое проще: нарезаем проволочный припой мелкими кусочками, мажем площадки этой канифольно-глицериновой пастой(ну как мажем… сгусток прям зубочисткой кладем), ставим туда компонент и бросаем рядом по кусочку припоя. За счет густоты флюса все прилипает к площадкам не хуже, чем на паяльную пасту.
Можно приклеить и на спирто-канифоль, но это на порядки неудобнее — спирт быстро испаряется, нужно ловить момент удобного приклеивания. На чистый глицерин особо ничего не приклеишь.
Кроме прочего, при пайке растворенной канифолью(в обоих случаях) ее количество будет достаточно мало, чтобы загадить плату настолько, чтоб затруднить визуальный контроль пайки, как это описывается у автора. Так что если эстетичность платы не нужна, то можно и не мыть потом.
P.S. А так-то конечно да. Глицерином тоже можно паять, более того — он гиппоалергенен, почти не горит — испаряется практически весь. А если в него добавить соответствующий ароматизатор, процесс пайки становится гламурным — вокруг витают запахи, как кальян куришь, жена не злая ходит, говорит «Паяй еще!» )))
Собственно в «мокрых» кальянных табаках тоже варенье на основе глицерина используется. В электронных сигаретах основа жидкости так же либо на пропилен-гликоле, либо на глицерине, либо на их смеси. Ароматизаторы обычно достаточно термостойки и врядли при их мизерном количестве как-либо повлияют на качество пайки.
Но это я уже отвлекся от темы )))
Удобно, например, нанести зубочисткой на пады и на нее же «приклеить» SMD перед пайкой.
В остальном по свойствам оно ничем не отличается от остальных вариантов канифолевых флюсов.
То есть смысл — чисто в консистенции и в том, что глицерин не дает ей высыхать, в отличии от быстросохнущего спиртораствора. А так и то и другое — само по себе флюс, и смешивая их в нужной пропорции, можно получить нужную густоту раствора/пасты.
Еще можно ее растворить в глицерине — дольше растворяет, но на выходе будет что-то вроде паяльного жира — густая такая паста. Если добавить немного пропиленгликоля, будет расворять чуть быстрее и на выходе паста будет менее вязкая.
Т.к. для почты отправителя в адресе важна только страна, а вся остальная часть адреса — исключительно для наших почтовых работников, можно попробовать нарисовать адрес по-понятнее для них, типа как-то так:Конечно не факт, что гарантированно поможет, можно нарваться на непрошибаемого работника, но все же…
Я своего курьера знаю, он меня тоже. Номерами давно обменялись.
Могу позвонить, мол «Завтра не забирай, посылка дорогая, поеду сам забирать с актом вскрытия», или «Я на работу выезжаю, ты где? Где пересечься можем на районе?» — часто мне удобнее подъехать куда-либо, чем ждать полдня пока он по списку до меня доедет.
Или он звонит в 7-8 утра: «Тут тебе посылку забираю, она сильно мятая/порвана. Забирать или сам поедешь с актами вскрывать?».
Ну и тому подобные ситуации. Это удобно.
Символ "_" используется в именах файлов всеми и везде. Символ "$", как Вы правильно заметили, может подложить свинью в регулярках. Постоянно об этом помнить и постоянно экранировать… Сомнительное удовольствие. Впрочем, если вы простой кодер, не работающий в команде — это ваше дело, как и где извращаться. Если это поможет разработке — да не вопрос. Все замечательно. В команде об этом должны уже помнить все. Хотя пример безусловно «натянутый» — регулярками парсить список файлов на сервере — это конечно редкость.
Однако все-равно совет укорачивать имена файлов до максимума в виде статьи на Хабре — условно выглядит как призыв всем писать сразу обфусцированный код. Я могу предложить Вам имена функций тоже делать как можно более короткими. Не до a(), b(), c() конечно, но ведь тоже можно str_truncate_spaces() переименовать в sts() или в s_ts(), если первое «s» — префикс текущей либы.
Еще можно инклудить всегда только файл "$.js"(или "_.js"), а в нем с помощью SSI(Server Side Includes) инклудить все остальные библиотеки, или хотя бы часто используемые. Оно и разработчику будет проще, и кешироваться в браузере будет, и все такое.
У меня столько идей на такие темы ))))
Другой вопрос, а нужно ли оно в принципе…
Да и то же использование символа доллара($) в именах файлов хоть и вполне допустимо, но иногда имеет смысл его избегать — просто на всякий случай. А то может вылезти боком в совершенно неожиданной ситуации, которой теоретически быть не должно, но практически почему-то случилась. Удобства в одном месте по возможности не должы порождать неудобства в другом. Как-то так.
Другими словами — если проект так спроектирован, что такая мелкая оптимизация может заметно влиять на статистику нагрузки — это плохой проект.
О крайностях, типа веб-сервера на Atmel-контроллере, мы не говорим. Там это может пригодиться.