В самом деле, нередко церковь становится чрезвычайно эффективным политическим инструментом. Именно это Вы и демонстрируете, говоря, что В Западной части России могли бы основать свои государства Венгры, Монголы, разные Тюрки, Татары, Германцы, Литовцы… — те народы с которыми Россия неоднократно вела кровопролитные войны и во всех этих войнах в итоге стала победительницей. И все эти войны в основном были оборонительными, и победы в них свидетельствую о величии мировоззрения, и о величии внутренних духовных сил, сформированных именно благодаря Русской Православной Церкви на русский народ. . Но неужели в учении Христа, в самом деле, была отведена роль РПЦ, в кровопролитных международных конфликтах за владение территориями?
Вы опрометчиво пытаетесь превозносить Христианство, путем умаления других религий и выпячивания отдельных, ныне модных, проявлений экстремизма. Экстремизм, в той или иной степени, в различные исторические периоды был свойственен всем культурам. Кто без греха, пусть первым бросит…, и тоже станет экстремистом. :) Подобные явления служат инструментами политики, а не вероисповедания.
Религии провозглашают базовые законы для эффективного сосуществования людей. Укажите хоть одну религию, существующую достаточно длительное время, где в заповедях есть призыв к экстремизму! Нет таких. Экстремизм разрушает общество, а значит прямо противоречит задачам религии.
Борьба с неверными, джихад? Джихад это в первую очередь, призыв к духовной борьбе людей с собственными недостатками, во вторую — к борьбе с неверием в то, что с ними нужно бороться. :) Использование этого термина из уст укуреных афганцев ни сколь не авторитетно. Мнение, что военная агрессивность отдельных ближне-восточных народов, являющаяся следствием исповедания Мусульманства, это такой же политический софизм, как упомянутая Вами роль РПЦ в былых кровопролитных конфликтах за территорию России.
Коли, по Вашим же словам, религия обеспечивает людей связью с Богом, то логично, что религии в своей массе — это альтернативные способы связи. :) Можно задуматься о том, какая связь эффективнее, и с тем-ли Богом в итоге связывает своих последователей. По факту, качество предоставляемой связи, на протяжении многих веков оставляет желать лучшего. И до сих пор весьма далеко от эталонного, которое многократно было описано в древних книгах. Может хватит кататься на X3 и пора уже делом заняться? ;)
Думаю, все проще. Во времена раннего Христианства много людей было неграмотными. Они не могли читать Библию и другие книги, просто потому, что не умели читать. Для них проповедники рисовали картинки — иконы, фрески и т.п., — которые и демонстрировали во время проповедей. Ведь картинки понимают все, даже дети. Кроме того, устная речь лучше воспринимается, когда подкреплена визуальными образами. В настоящее время, подобная техника подачи материала, используется на семинарах, когда лектор параллельно рассказу, демонстрирует слайды. Ну или смайлики. :)
Для прихожан, такие изображения помимо чисто информационной — визуальных образов почитаемых Святых, например, — так же имели весьма высокую художественную и материальную ценность, поскольку кропотливо писались вручную. Не было в те времена дешевых и быстрых способов для тиражирования. Все это вынуждало прихожан относится к иконам с особым вниманием и бережливостью. Ну, а тут до почитания — рукой подать.
Со временем, иконопись превратилась в «насквозь религиозное христианское искусство», а иконопочитание стало догмой. Явление приобрело столь массовый характер, что многие уже перестали понимать, что первично, а что вторично, т.е. фетишизировать иконы и «кланяться на карачках перед раскрашенными досками». Иконоборчество возникло как один из механизмов противодействия этому. Весьма экстремистский надо сказать, т.к. фактически, призывает бороться со следствием, а не причиной.
Ӕто вы правильно сделали.
Люди не будут каждый месяц придумывать новые пароли. Ӕто очевидно. В итоге хабра сможет насобирать классную базу персональных паролей.
что этим методом хотят скрыть? факт установки соединения остается. факт передачи данных тоже. чисто статистически «тайные» данные лучше передавать в обычных пакетах, ведь таких пакетов гораздо больше, чем ретрансмиссионных.
В современном мире, MVC это догма. Такая же как ОтецСынСвятойдух в христианстве. ;)
Техника расщепления приложения на слои описана у Фаулера в Patterns of Enterprise Application Architecture. В двухслойной архитектуре слои называются Client и Server. В трехслойной архитектуре — Presentation, DomainLogic и DataSource. Слоев может быть и больше. Дело не в названиях и их количестве. Суть в том, что на практике бывает полезно, сильно сцепленные куски логики приложения, обосабливать друг от друга (образуя между ними слабые коммуникационные связи). Например, хорошо отделять DomainLogic (логику, ради которой и создается система ⓒ), от прочего, неизбежно сопутствующего барахла, — UI и внешних API приложения с одной стороны, и источников/хранилищ данных с другой.
В большей части интерпретаций, MVC это принцип, который используется для анализа задач, связанных с созданием инструментов пользователя (Tools). С точки зрения MVC, все интересующие программные артефакты рассматриваются в аспекте представлений и их преобразований из одного в другое. View отражает представление некоторой артефакта, в терминах пользовательской ментальной модели, Model — представление в терминах программной модели, а Controller — представление в терминах управления. Например, инструмент для рейтингования этого коммента, с точки зрения MVC может рассматриваться следующим образом. Для юзера это изображение двух изумительных квадратиков: красного и зеленого — которые символизируют критику и одобрение. Для хабрасервера это строка из набора {'minus','plus'}. Для браузера — два мышекликабельных объекта.
И то и другое, в общем-то, являются самостоятельными концепциями, и не зависят от ООП.
② Когда люди обращаются к использованию паттернов проектирования?
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
Когда люди обращаются к использованию паттернов проектирования?
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
Алгебраически, идентификаторы — самостоятельный тип данных, не похожий на [int]. Идентификаторы бессмысленно делить, умножать, возводить в степень, и делать с ними еще много других операций, которые обычно свойственны целым числам [int]. Идентификаторы можно лишь сравнивать между собой. Множество допустимых значений идентификаторов пользователя конечно — оно определяется множеством значений, заданных в соответствующей таблице БД. В итоге, все эти ограничения формируют тип [user_id]. В строго типизированных языках, переменные так же типизированы. Переменная $user_id будет иметь тип [user_id]. А поскольку в таких языках автоматическое преобразование типов не допускается, то попытка присвоить $user_id = (int) … неизбежно приведет к ошибке. В php'шном синтаксисе подражание строгой типизации выглядит так:
использую строгую типизацию в пхп (вида $user_id = (int) $_GET['user_id'])
Это называется приведением типа. Случись, что php станет строго типизированным, это выражение не скомпилируется, поскольку int и user_id — разные типы данных (у них алгебры разные, скажем, выражение [int] + [int] = [int] законно, а [user_id] + [user_id] не имеет смысла). :)
Насчет зарегистрированных слов — если они Вам мешают и Вы им не пользуетесь, милости просим в те самые файлы с исходниками — все эти слова описаны там и еще легче могут быть оттуда убраны
Мир возможного вообще чудесен. ;) Тем не менее, в реальности, по мере роста версии php, словарь зарезервированных слов языка только расширяется.
Нет. Нельзя. Раздутая грамматика в php это следствие динамической типизации и безумного количества правил приведения типов. В таких языках тип результата определяется не типами аргументов, а типом оператора.
Сравни:
Это не недостаток. Просто особенность данного класса языков — для каждого типа оператора нужна своя «закорючкя». Такие языки не позволяют определять пользовательские операторы. Поэтому обилие встроенных операторов никому не мешает. Чем больше операторов встроено в язык, тем он богаче, однозначнее и лаконичнее. В perl, например, их еще больше. :)
Основной недостаток грамматики php это обилие ключевых слов (зарезервированных). Именно поэтому в классах нельзя называть методы именами 'and', 'or', 'use', 'require' и т.п.
Концептуально, «class» сам по себе образует пространство имен. Для классов есть чудная арифметика, позволяющая эти пространства имен комбинировать — слово extends все знают?… И главное — эти чудеса живут в языке еще со времен PHP4. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Для каких целей создавался «Сервис структур Hivext»?
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
структур позволяет разработчикам создавать свои приложения в стиле ООП, позволяет манипулировать и управлять типами и объектами разрабатываемых приложений
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
/* люди, эта хренотень вычислят (2+3)*7 */ var api = new Api; api.call('sum', [2, 3]) .addCallback( function (sum_of_2_and_3) { return api.call('mult', [sum_of_2_and_3, 7]); }) .addCallback( function(result) { alert('(2+3)*7 = ' + result); }) .addErrback( function (error) { alert('Mmm… something wrong happened: ' + error); });сколько нужно программистов для того, чтобы ввернуть лампочку?… ㋡
Вы опрометчиво пытаетесь превозносить Христианство, путем умаления других религий и выпячивания отдельных, ныне модных, проявлений экстремизма. Экстремизм, в той или иной степени, в различные исторические периоды был свойственен всем культурам. Кто без греха, пусть первым бросит…, и тоже станет экстремистом. :) Подобные явления служат инструментами политики, а не вероисповедания.
Религии провозглашают базовые законы для эффективного сосуществования людей. Укажите хоть одну религию, существующую достаточно длительное время, где в заповедях есть призыв к экстремизму! Нет таких. Экстремизм разрушает общество, а значит прямо противоречит задачам религии.
Борьба с неверными, джихад? Джихад это в первую очередь, призыв к духовной борьбе людей с собственными недостатками, во вторую — к борьбе с неверием в то, что с ними нужно бороться. :) Использование этого термина из уст укуреных афганцев ни сколь не авторитетно. Мнение, что военная агрессивность отдельных ближне-восточных народов, являющаяся следствием исповедания Мусульманства, это такой же политический софизм, как упомянутая Вами роль РПЦ в былых кровопролитных конфликтах за территорию России.
Коли, по Вашим же словам, религия обеспечивает людей связью с Богом, то логично, что религии в своей массе — это альтернативные способы связи. :) Можно задуматься о том, какая связь эффективнее, и с тем-ли Богом в итоге связывает своих последователей. По факту, качество предоставляемой связи, на протяжении многих веков оставляет желать лучшего. И до сих пор весьма далеко от эталонного, которое многократно было описано в древних книгах. Может хватит кататься на X3 и пора уже делом заняться? ;)
Для прихожан, такие изображения помимо чисто информационной — визуальных образов почитаемых Святых, например, — так же имели весьма высокую художественную и материальную ценность, поскольку кропотливо писались вручную. Не было в те времена дешевых и быстрых способов для тиражирования. Все это вынуждало прихожан относится к иконам с особым вниманием и бережливостью. Ну, а тут до почитания — рукой подать.
Со временем, иконопись превратилась в «насквозь религиозное христианское искусство», а иконопочитание стало догмой. Явление приобрело столь массовый характер, что многие уже перестали понимать, что первично, а что вторично, т.е. фетишизировать иконы и «кланяться на карачках перед раскрашенными досками». Иконоборчество возникло как один из механизмов противодействия этому. Весьма экстремистский надо сказать, т.к. фактически, призывает бороться со следствием, а не причиной.
Может прав был тот, кто написал: «Не делай себе кумира и никакого изображения того, что на небе вверху, и что на земле внизу, и что в воде ниже земли; не поклоняйся им и не служи им…» (в wiki :) ) — было бы меньше суеты, бессмысленных жизней и бессмысленных смертей © ;)?
тогда смысл сей акции понятен.
Люди не будут каждый месяц придумывать новые пароли. Ӕто очевидно. В итоге хабра сможет насобирать классную базу персональных паролей.
любопытно. почему?
Техника расщепления приложения на слои описана у Фаулера в Patterns of Enterprise Application Architecture. В двухслойной архитектуре слои называются Client и Server. В трехслойной архитектуре — Presentation, DomainLogic и DataSource. Слоев может быть и больше. Дело не в названиях и их количестве. Суть в том, что на практике бывает полезно, сильно сцепленные куски логики приложения, обосабливать друг от друга (образуя между ними слабые коммуникационные связи). Например, хорошо отделять DomainLogic (логику, ради которой и создается система ⓒ), от прочего, неизбежно сопутствующего барахла, — UI и внешних API приложения с одной стороны, и источников/хранилищ данных с другой.
В большей части интерпретаций, MVC это принцип, который используется для анализа задач, связанных с созданием инструментов пользователя (Tools). С точки зрения MVC, все интересующие программные артефакты рассматриваются в аспекте представлений и их преобразований из одного в другое. View отражает представление некоторой артефакта, в терминах пользовательской ментальной модели, Model — представление в терминах программной модели, а Controller — представление в терминах управления. Например, инструмент для рейтингования этого коммента, с точки зрения MVC может рассматриваться следующим образом. Для юзера это изображение двух изумительных квадратиков: красного и зеленого — которые символизируют критику и одобрение. Для хабрасервера это строка из набора {'minus','plus'}. Для браузера — два мышекликабельных объекта.
И то и другое, в общем-то, являются самостоятельными концепциями, и не зависят от ООП.
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
Мир возможного вообще чудесен. ;) Тем не менее, в реальности, по мере роста версии php, словарь зарезервированных слов языка только расширяется.
Нет. Нельзя. Раздутая грамматика в php это следствие динамической типизации и безумного количества правил приведения типов. В таких языках тип результата определяется не типами аргументов, а типом оператора.
Сравни:
Это не недостаток. Просто особенность данного класса языков — для каждого типа оператора нужна своя «закорючкя». Такие языки не позволяют определять пользовательские операторы. Поэтому обилие встроенных операторов никому не мешает. Чем больше операторов встроено в язык, тем он богаче, однозначнее и лаконичнее. В perl, например, их еще больше. :)
Основной недостаток грамматики php это обилие ключевых слов (зарезервированных). Именно поэтому в классах нельзя называть методы именами 'and', 'or', 'use', 'require' и т.п.
с опытом это пройдет. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.