Заметьте, что Гейтс очень осторожно говорит об этих отношениях, нигде нет слов о серьёзной дружбе (разве только в переводах, где «a couple of hours» превращаются в «два часа»), даже в упоминавшемся совместном интервью оба вели себя сдержанно.
«А скажут потом, что Гоголь на дерево голым залез...»
Анекдот с бородой
Нужно не забыть запланировать, куда втиснуть стратегически необходимый пункт «Поделиться радостью с ближними». Чтобы потом запланировать и выполнить «Заставить жену этим пользоваться».
Тьфу, пакость — ведь планировал не комментировать эту статью. Отложу на завтра.
Ну, задачку задали — я, однако же, не иллюстратор.
Поразмыслив решил, что зубцы кремлевской стены более узнаваемы в схематичном виде, чем другие архитектурные сооружения, поэтому получился черновой лого, отдающий банком Москвы.
Хорошее дело задумали, а вот логотип подкачал: у храма Василия Блаженного купола не только другой формы, но и другим числом — на мой вкус, у вас мечеть получилась.
Выбрать, конечно, проще, только никто вас не застрахует от того, что пользователи смогут сказать «у них насыщенная не такая уж и насыщенная, а констрастную можно было бы поконтрастнее сделать» %) Выбор в широких диапазонах с возможностью предустановок, в противоположность, лишен этого недостатка.
Лев Семёнович изумился бы, во что вылились его наработки %)
Если я начну ловить ошибки которых нет, я сразу признаю, что ошибок больше чем я думаю. Логично?)
Логично лишь то, что вы признали бы в этом случае, что ошибки возможны. И это признание ни в коем разе не могло бы быть связано с указанной количественной характеристикой. Ошибки действительно возможны.
Однако же, неоспоримо, что на переключение между контекстами будет затрачено какое-то время, и по возможности его следует минимизировать, и ваш подход вполне имеет право на жизнь. Впрочем, наряду со множеством других.
А есть разница между «держать зачем-то» и «держать понятно зачем» %)
Замечу, в статье речь про готовый проект под конкретное окружение (читай «веб-сервис»), а не о приложении, на которое распространяется требование поддержки разных окружений, экземпляры которого уйдут клиентам. Вот последнее попадёт под описанную вами задачу, а для первого разделение излишне. В таком вот разрезе я об этом думаю.
В этой части задачи ваше решение, конечно же, предпочтительно.
Однако не забывайте, что есть ещё часть определения неактуальности локального торрента, и автор эту часть пощупал, а потому — молодец %)
На заметку: чтобы не опрашивать репозитории, научите демона ловить, к примеру, широковещательные сообщения, разбрасывать которые будет post-commit хук git.
Ну, положим, про одну строку это преувеличение, иначе зачем бы Дима Котеров стал писать JsHttpRequest %)
А вообще, есть мнение, что всему своё время: популяризация указанных выше техник и технологий — есть следствие эволюционного развития ИТ. И, пока я окончательно не ударился в философию, уйду спать.
Если вы про асинхронные запросы — основу ajax, то дело было ещё до IE, и делали его ява-апплеты, MS со своим ActiveX-компонентом сыграла позднее. Наличие примеров и название повлияло на популярность куда меньше, чем «свободная» реализация в js XMLHttpRequest-объекта.
Это я не к тому, что примеры не нужны, а к тому, что пример не гарантирует популярности.
Если, конечно, это не дурной пример — вот он заразителен.
Есть многое на свете… Обернуть можно практически всё, во что будет угодно, если, конечно, забыть на время, что кому-то захочется увидеть расклад прав без помощи нашего приложения %) Вопрос в сомнительной полезности такой затеи.
Верно, что битовые операции поддерживают многие СУБД, только делают они это на разном уровне, иногда даже разными средствами. Выходит, что приложение, заявлющее поддержку разных СУБД, должно будет учитывать возможные нюансы. Присовокупьте к этому, что каркасы для разработки не предлагают выделенных интерфейсов для битовых выборок (поправьте, если я ошибаюсь) и получите довольно живописную прозу, в которой разработчик в погоне за эфимерным быстродействием и в попытке сэкономить пару сотен байт пускается во все тяжкие. Подозреваю, что из zend engine прольётся куда больше, чем удасться сэкономить.
И с последним утверждением на счёт явности быстроты поиска я бы поспорил — быстрота будет зависеть от многих факторов.
«А скажут потом, что Гоголь на дерево голым залез...»
Анекдот с бородой
Тьфу, пакость — ведь планировал не комментировать эту статью. Отложу на завтра.
Поразмыслив решил, что зубцы кремлевской стены более узнаваемы в схематичном виде, чем другие архитектурные сооружения, поэтому получился черновой лого, отдающий банком Москвы.
Логично лишь то, что вы признали бы в этом случае, что ошибки возможны. И это признание ни в коем разе не могло бы быть связано с указанной количественной характеристикой. Ошибки действительно возможны.
Однако же, неоспоримо, что на переключение между контекстами будет затрачено какое-то время, и по возможности его следует минимизировать, и ваш подход вполне имеет право на жизнь. Впрочем, наряду со множеством других.
Замечу, в статье речь про готовый проект под конкретное окружение (читай «веб-сервис»), а не о приложении, на которое распространяется требование поддержки разных окружений, экземпляры которого уйдут клиентам. Вот последнее попадёт под описанную вами задачу, а для первого разделение излишне. В таком вот разрезе я об этом думаю.
Однако не забывайте, что есть ещё часть определения неактуальности локального торрента, и автор эту часть пощупал, а потому — молодец %)
А если вы действительно следите и ждёте, то libnotify не лучший вариант.
Я так понял, что автор упражняется, поэтому предложил ему упражнение №2 %)
А вообще, есть мнение, что всему своё время: популяризация указанных выше техник и технологий — есть следствие эволюционного развития ИТ. И, пока я окончательно не ударился в философию, уйду спать.
Это я не к тому, что примеры не нужны, а к тому, что пример не гарантирует популярности.
Если, конечно, это не дурной пример — вот он заразителен.
Верно, что битовые операции поддерживают многие СУБД, только делают они это на разном уровне, иногда даже разными средствами. Выходит, что приложение, заявлющее поддержку разных СУБД, должно будет учитывать возможные нюансы. Присовокупьте к этому, что каркасы для разработки не предлагают выделенных интерфейсов для битовых выборок (поправьте, если я ошибаюсь) и получите довольно живописную прозу, в которой разработчик в погоне за эфимерным быстродействием и в попытке сэкономить пару сотен байт пускается во все тяжкие. Подозреваю, что из zend engine прольётся куда больше, чем удасться сэкономить.
И с последним утверждением на счёт явности быстроты поиска я бы поспорил — быстрота будет зависеть от многих факторов.
Мой комментарий не о невозможности хранения, он несколько о другом.