Имея адекватный инструмент, это несложно. Кропотливо, но несложно.
Я свой MBP 2.2 разбирал раза 4 китайскими отвертками ценой в $1 за комплект (-_-), вот это было весело, особенно первый раз выкручивать phillips кухонным ножом, т.к. у китайской отвертки тупо срывало наконечник от тугого крутящего момента и она прокручивалась.
У вас не было случаев повреждения шлейфов острыми краями пинцета? Я бы использовал какие-то силиконовые накладки на кончики, особенно в случае твердых деталей типа модуля Wi-Fi.
Через 30-40-50 лет к власти будут приходить «их» детки (так называемые «мажоры»), которые уже сейчас наркоманы и убийцы, и с детства привыкли к вседозволенности и безнаказанности. «Кормушка» уже давно передается по наследству. ;-(
Ваши рассуждения верны только в контексте нормального правового государства, в котором чиновники соблюдают хотя бы видимость закона. Всё это не имеет никакого отношения к Украине.
Вот вы думаете, что налоговики пришли к «Розетке» из-за неуплаты НДС? Нет, они пришли, потому что «сверху» пришел приказ. И очень скоро у «Розетки» будет новый владелец, как это относительно недавно произошло с сетью строительных супермаркетов «Эпицентр» и с кондитерским заводом «Roshen», и как, скорее всего, у Ex.ua
А на счет судебных исков на возмещение ущерба: судить будут тоже госслужащие (судьи), и вся эта кодла — кумы, сваты, братья.
Зря вы так. Хоститься в Украине очень даже сладко тем, кто не ведет здесь бизнес, т.к. местные чинуши болт клали на запросы полиции из-за бугра. Вспомним хотя бы Демоноид.
> Для измерения ESR применяются простейшие приборы, доступные любому ребенку
Вы забыли упомянуть, что перед измерением конденсатора его нужно выпаять. Когда подозрительных конденсаторов 10+ штук, есть соблазн забить на это дело и заменить только вздувшиеся. Понятно, что если мастеру за это платят деньги, то надо все-таки по-человечески делать, но ведь по-разному бывает.
Я так перепаивал конденсаторы в блоке питания своего Philips 190X7. Симптомы похожие: начал включаться не с первого раза, позже перестал включаться вовсе. Ну что же, взял паяльник, выпаял вздувшиеся, впаял новые качественные, включил. Не работает.
Вывод: не все так просто в жизни. :-)
Разработчик может самостоятельно поддерживать дерево. Понятно, что если генератор парсера это делает за разработчика, то это круто. Но возникает вопрос: а если разработчику нужно чуть другая структура данных, а текущая структура наглухо прописана в годе генератора?
> интеграция семантической логики напрямую в синтаксический анализатор, минуя стадию построения дерева
> Заметно то, что сложную грамматику так не описать
Достаточно спорное утверждение. Простыню кода можно спрятать в вызов функции.
Похоже, я порю горячку. :)
Лично я ни разу не столкнулся с проблемой адаптации модуля к PostgreSQL, знаю о них лишь понаслышке. Мой опыт сильно устарел: я знакомился с Друпал в 2009-м, а тогда нередко сообщали о багах в работе с PostreSQL. В свое оправдание могу лишь предложить загуглить postgresql drupal 6 site:drupal.org. Сейчас, похоже, всё устаканилось. Посыпаю голову пеплом.
> сейчас новые проекты стоит делать уже на семерке
с этим я не спорю, я имел в виду поддержку старых проектов.
На шестерке. Да, признаю, с «недавно» я погорячился, разбирался с этим давно, поэтому с временем промазал. Но суть это не меняет — многие модули по-прежнему заточены по мускул. Да, популярные модули вроде сделали СУБД-независимыми (и то вопрос, по-моему в узких местах все-равно стоят dbms-specific хаки), но таких меньшинство.
На семерку переходить не спешу, т.к. плюшки неочевидны, а работы с переносом — воз. Да и та же фигня с модулями — многие не портированы на семерку.
Его так и позиционируют: CMF(P) (Content Management Framework/Platform) — Вики, Друпал.
Лично я согласен с позицией автора конкретно о веб-приложениях. Друпал силен, и сила его в модулях, почти всегда можно найти модуль, который решает конкретно твою задачу. Но базовый принцип работы Друпала остается прежним, и для внесения изменения в архитектуру надо хакать ядро, а это автоматический отказ от обновлений — привет кракерам.
Вот, к примеру, работа с БД. Долгое время в Друпале поддерживался только MySQL, недавно впилили PostreSQL. А большинство модулей остались совместимы лишь с MySQL. Так и живем…
Короче, не катит Друпал на роль CMF для веб-приложений, имхо.
> как юникод поддерживается сейчас kunststube.net/encoding/ — если кратко, то PHP поддерживает Unicode в том смысле, что не пытается угадывать кодировку текста и просто считает строку последовательностью байт. Хорошая статья, многое подробно разжевано.
> UTF-16 — Достоинства www.unicode.org/notes/tn12/ — еще в 2004-м году написали, почему UTF-16 предпочтительнее во многих аспектах.
Не хочу никого обидеть, но знание ситуации с кодировками в общем и понимание Unicode в частности, имхо, отличает квалифицированного разработчика от code monkey. Ну это же позорище — хрен знает сколько уже языку лет, мировая популярность, а работа с текстом — костыль на костыле.
У меня, например, железный плеер не умеет переключаться по трекам внутри образа. Всю музыку качаю с рутрекера, там чаще выкладывают образы, поэтому я сразу после завершения скачивания разрезаю на треки, конвертирую в vorbis и синхронизирую папку рипов с плеером.
Плюсы:
— в плеере нет помойки: всё аккуратно раскидано по иерархии папок вида «Исполнитель/Год альбома — название альбома»;
— со временем я удаляю треки, которые мне не понравились (в ходе неоднократного прослушивания), и оставляю любимые. С образами всё так легко не получится.
Минусы:
— коллекция занимает больше места. Но я не меломан, музыки у меня немного (меньше 10 Гбайт в lossless), поэтому для меня это не проблема;
— геморрой с проставлением тегов в потрековых рипах образов. Решаю по ситуации, обычно использую самописные скрипты.
По-моему, тут речь идет не о продаже физического носителя или даже его «электронной копии». По ходу, когда покупаешь музыку в онлайн-магазинах, то фактически покупаешь лицензию (т.е. право) (без права лицензирования третьей стороны) на (личное, некоммерческое) прослушивание. А возможность скачать файл, чтобы его таки прослушать, дается как «бонус». Или дела обстоят иначе? Поправьте меня, если я неправ.
Я свой MBP 2.2 разбирал раза 4 китайскими отвертками ценой в $1 за комплект (-_-), вот это было весело, особенно первый раз выкручивать phillips кухонным ножом, т.к. у китайской отвертки тупо срывало наконечник от тугого крутящего момента и она прокручивалась.
Вот вы думаете, что налоговики пришли к «Розетке» из-за неуплаты НДС? Нет, они пришли, потому что «сверху» пришел приказ. И очень скоро у «Розетки» будет новый владелец, как это относительно недавно произошло с сетью строительных супермаркетов «Эпицентр» и с кондитерским заводом «Roshen», и как, скорее всего, у Ex.ua
А на счет судебных исков на возмещение ущерба: судить будут тоже госслужащие (судьи), и вся эта кодла — кумы, сваты, братья.
Welcome to Ukraine.
—
и.о. Кэпа
> Для измерения ESR применяются простейшие приборы, доступные любому ребенку
Вы забыли упомянуть, что перед измерением конденсатора его нужно выпаять. Когда подозрительных конденсаторов 10+ штук, есть соблазн забить на это дело и заменить только вздувшиеся. Понятно, что если мастеру за это платят деньги, то надо все-таки по-человечески делать, но ведь по-разному бывает.
Вывод: не все так просто в жизни. :-)
P.S. а пару материнок я таким макаром оживил.
> Заметно то, что сложную грамматику так не описать
Достаточно спорное утверждение. Простыню кода можно спрятать в вызов функции.
А плагин под Мак так и не обновили. Печалька.
Лично я ни разу не столкнулся с проблемой адаптации модуля к PostgreSQL, знаю о них лишь понаслышке. Мой опыт сильно устарел: я знакомился с Друпал в 2009-м, а тогда нередко сообщали о багах в работе с PostreSQL. В свое оправдание могу лишь предложить загуглить postgresql drupal 6 site:drupal.org. Сейчас, похоже, всё устаканилось. Посыпаю голову пеплом.
> сейчас новые проекты стоит делать уже на семерке
с этим я не спорю, я имел в виду поддержку старых проектов.
На семерку переходить не спешу, т.к. плюшки неочевидны, а работы с переносом — воз. Да и та же фигня с модулями — многие не портированы на семерку.
Лично я согласен с позицией автора конкретно о веб-приложениях. Друпал силен, и сила его в модулях, почти всегда можно найти модуль, который решает конкретно твою задачу. Но базовый принцип работы Друпала остается прежним, и для внесения изменения в архитектуру надо хакать ядро, а это автоматический отказ от обновлений — привет кракерам.
Вот, к примеру, работа с БД. Долгое время в Друпале поддерживался только MySQL, недавно впилили PostreSQL. А большинство модулей остались совместимы лишь с MySQL. Так и живем…
Короче, не катит Друпал на роль CMF для веб-приложений, имхо.
kunststube.net/encoding/ — если кратко, то PHP поддерживает Unicode в том смысле, что не пытается угадывать кодировку текста и просто считает строку последовательностью байт. Хорошая статья, многое подробно разжевано.
> UTF-16 — Достоинства
www.unicode.org/notes/tn12/ — еще в 2004-м году написали, почему UTF-16 предпочтительнее во многих аспектах.
> достаточно мало специалистов, которые понимают тонкости юникода
www.joelonsoftware.com/articles/Unicode.html — вообще классика, всем must read.
Не хочу никого обидеть, но знание ситуации с кодировками в общем и понимание Unicode в частности, имхо, отличает квалифицированного разработчика от code monkey. Ну это же позорище — хрен знает сколько уже языку лет, мировая популярность, а работа с текстом — костыль на костыле.
Плюсы:
— в плеере нет помойки: всё аккуратно раскидано по иерархии папок вида «Исполнитель/Год альбома — название альбома»;
— со временем я удаляю треки, которые мне не понравились (в ходе неоднократного прослушивания), и оставляю любимые. С образами всё так легко не получится.
Минусы:
— коллекция занимает больше места. Но я не меломан, музыки у меня немного (меньше 10 Гбайт в lossless), поэтому для меня это не проблема;
— геморрой с проставлением тегов в потрековых рипах образов. Решаю по ситуации, обычно использую самописные скрипты.