… что такое оптимизация веб-сайтов?
Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта
Мне одному кажется, что под термином «оптимизация сайта», как правило, понимают несколько иное? А то, про что рассказывается в статье — это называют устоявшимся термином «юзабилити-тестирование».
И, возможно, повышение налогов на ИП было сделано не для того, чтобы отжать, а для того, чтобы уменьшить привлекательность этой формы организации, например. В этом случае от нее проще отказаться будет.
Все верно, сотни тысяч ИП от нее отказались. Только я сильно сомневаюсь, что отказавшиеся от ИП отказались и от своих заработков, они просто ушли в тень.
Доказательство, что ИП не сотрудник, переложить на ООО
Есть уже довольно обширная судебная практика, когда ООО переводили сотрудников на ИП и радовались экономии на налогах. А потом приходили налорги и ставили их в такую неудобную позу, что не все потом могли распрямиться.
Общий смысл всей затеи очевиден, как и пару лет назад с повышением отчислений в фонды — увеличить сбор налогов, ибо ООО налогов реально больше ИП платят. Но и результат, на мой взгляд, тоже очевиден — денег, в итоге, получат меньше, а теневой сектор увеличится.
Увы, но самый большой минус ИП как раз в том, что в соцстрах и пенсионный надо платить при любом раскладе, даже если вообще деятельности никакой не ведешь. Есть свидетельство ИП — плати. Правда, насчет 10 лет что-то сомневаюсь, по-моему, срок давности там короче, но точно не помню уже.
Ну вот у меня есть задачи, где использование итераторов значительно сократило бы и объем кода и его читаемость, но я вынужден был отказаться от них именно из-за тормознутости.
… как пример Stream API из Java 8
Так в том-то и дело, что речь о реализации SPL-итераторов в PHP
Очевидная польза от этой штуки в обозримой перспективе только одна — изнашиваться при постоянном ношении будет не так быстро, как обычный паспорт.
Все остальное, связанное со всякими манипуляциями считывания — в весьма туманной перспективе, т.к. для этого банально не готова еще инфраструктура. Да сроки запуска того же СМЭВ переносились сто раз, и до сих пор еще не работает система, как должна. На кой ляд сюда в обязательном порядке за уши притягивают платежные функции — совершенно непонятно. Всякие пенсии и пособия получают те группы населения, которые, очевидно, будут в самых последних рядах на получение этого пластика (если государство в принудительном порядке не заставит).
Поддержу. Особенно при работе на ноуте, где высота экрана (по сравнению с шириной) как правило и так невелика, поэтому есть желание экономить пространство именно по высоте. Напр., первое, что я делаю на ноуте с Виндой — это панель переношу из нижней части экрана в правую.
Согласно официальным отчетам Союз правообладателей под руководством Михалкова за 2010-1013 годы собрал более 5.2 млрд руб. Правообладателям выплачено за этот же период примерно 2.6 млрд руб. Всего с правообладателями по состоянию на конец 2013 года заключено чуть более 3000 договоров (отчетов за 2014 год еще нет).
Очень интересно API. Если не хотите рассказать, что там будет, то было б неплохо форму добавить для ввода мыла, чтоб сообщить всем заинтересованным, когда API станет доступно.
На мой взгляд, это уже детали реализации, и каждый из этих вариантов имеет свои плюсы и минусы, и выбор между ними — это больше вопрос личных предпочтений.
Например, первый вариант в теории должен работать чуть-чуть быстрее, т.к. идет явный вызов существующего метода, в то время как во втором какие-то доли секунды будут тратиться на вызов __callStatic. Насколько это существенно? Не знаю.
Зато во втором случае можно хоть небольшую, но дать подсказку IDE:
/**
* @method ModuleUser ModuleUser()
*/
class E {
// ...
}
Понятно, что это не даст IDE знаний о динамически подключаемых классах, но хотя бы про базовый «коробочный» класс она знать будет.
Так что из этих двух вариантов я предпочту второй. Но, повторюсь, не потому что он объективно лучше, а потому что мне он больше нравится.
Выше в комментах я приводил пример, как может выглядеть метод для создания объекта:
$object = E::ModuleUser();
Где E — это класс (singleton), выполняющий функции ядра, и там есть __callStatic, который получает управление и понимает, что нужно создать объект класса ModuleUser. И вот он уже смотрит стек наследования, определяет, нужно ли непосредственно класс ModuleUser брать (если наследников нет), либо кого-то, кто его переопределяет.
Да собственно, те самые «хуки» — это и есть система «событий и слушателей», которая активно использовалась в PHP-проектах еще до прихода туда нормального ООП, и, наверное, любая более-менее популярная CMS их использует. Но, как Вы верно отметили, нередко это вырождается в жуткую систему костылей и подпорок.
Да и вообще, ни один паттерн не гарантирован от «грязной» реализации, к сожалению.
Хочу акцентировать внимание: речь идет о CMS, и о возможности разрабатывать плагины, расширяющие любую сущность движка, независимыми друг от друга разработчиками.
И вот, исходя из этого, можно придумать любую схему, использовать любые паттерны, на которых могла бы строиться система плагинов. И наверняка найдется способ, как обеспечить баги при одновременном подключении нескольких плагинов. Кстати, не далее, как месяца три назад сталкивался с подобным в проекте на yii, где было использовано несколько сторонних готовых расширений.
Мне одному кажется, что под термином «оптимизация сайта», как правило, понимают несколько иное? А то, про что рассказывается в статье — это называют устоявшимся термином «юзабилити-тестирование».
Все верно, сотни тысяч ИП от нее отказались. Только я сильно сомневаюсь, что отказавшиеся от ИП отказались и от своих заработков, они просто ушли в тень.
Есть уже довольно обширная судебная практика, когда ООО переводили сотрудников на ИП и радовались экономии на налогах. А потом приходили налорги и ставили их в такую неудобную позу, что не все потом могли распрямиться.
Общий смысл всей затеи очевиден, как и пару лет назад с повышением отчислений в фонды — увеличить сбор налогов, ибо ООО налогов реально больше ИП платят. Но и результат, на мой взгляд, тоже очевиден — денег, в итоге, получат меньше, а теневой сектор увеличится.
Так в том-то и дело, что речь о реализации SPL-итераторов в PHP
И в первую очередь — о его производительности. SPL-итераторы — очень интересная вещь, но тормоза в 7 раз по сравнению с обычными циклами — это жуть.
Все остальное, связанное со всякими манипуляциями считывания — в весьма туманной перспективе, т.к. для этого банально не готова еще инфраструктура. Да сроки запуска того же СМЭВ переносились сто раз, и до сих пор еще не работает система, как должна. На кой ляд сюда в обязательном порядке за уши притягивают платежные функции — совершенно непонятно. Всякие пенсии и пособия получают те группы населения, которые, очевидно, будут в самых последних рядах на получение этого пластика (если государство в принудительном порядке не заставит).
Согласно официальным отчетам Союз правообладателей под руководством Михалкова за 2010-1013 годы собрал более 5.2 млрд руб. Правообладателям выплачено за этот же период примерно 2.6 млрд руб. Всего с правообладателями по состоянию на конец 2013 года заключено чуть более 3000 договоров (отчетов за 2014 год еще нет).
Но если Вам действительно интересно, то плагины есть как на гитхабе, так и в каталоге (в каталоге их больше, чем на гитхабе). Но чтоб долго не искать, вот, например, три плагина для Alto CMS с гитхаба:
github.com/altocms/alto-plugin-sitemap
github.com/altocms/alto-plugin-topicintro
github.com/altocms/alto-plugin-similartopics
И они, кроме прочего, расширяют много компонентов, но каждый из них расширяет сущность Topic (или «коробочный» класс ModuleTopic_EntityTopic движка). Чтоб долго не ковыряться в коде, могу привести ссылки конкретно на классы-расширения:
github.com/altocms/alto-plugin-sitemap/blob/master/classes/modules/topic/entity/Topic.entity.class.php
github.com/altocms/alto-plugin-topicintro/blob/master/classes/modules/topic/entity/Topic.entity.class.php
github.com/altocms/alto-plugin-similartopics/blob/master/classes/modules/topic/entity/Topic.entity.class.php
Я правильно понял, Вы это хотели увидеть?
Но это, опять же, кому-то понравится, кому-то нет, дело вкуса
На мой взгляд, это уже детали реализации, и каждый из этих вариантов имеет свои плюсы и минусы, и выбор между ними — это больше вопрос личных предпочтений.
Например, первый вариант в теории должен работать чуть-чуть быстрее, т.к. идет явный вызов существующего метода, в то время как во втором какие-то доли секунды будут тратиться на вызов __callStatic. Насколько это существенно? Не знаю.
Зато во втором случае можно хоть небольшую, но дать подсказку IDE:
Понятно, что это не даст IDE знаний о динамически подключаемых классах, но хотя бы про базовый «коробочный» класс она знать будет.
Так что из этих двух вариантов я предпочту второй. Но, повторюсь, не потому что он объективно лучше, а потому что мне он больше нравится.
Где E — это класс (singleton), выполняющий функции ядра, и там есть __callStatic, который получает управление и понимает, что нужно создать объект класса ModuleUser. И вот он уже смотрит стек наследования, определяет, нужно ли непосредственно класс ModuleUser брать (если наследников нет), либо кого-то, кто его переопределяет.
Да и вообще, ни один паттерн не гарантирован от «грязной» реализации, к сожалению.
И вот, исходя из этого, можно придумать любую схему, использовать любые паттерны, на которых могла бы строиться система плагинов. И наверняка найдется способ, как обеспечить баги при одновременном подключении нескольких плагинов. Кстати, не далее, как месяца три назад сталкивался с подобным в проекте на yii, где было использовано несколько сторонних готовых расширений.