1. Не получается зарегистрироваться на сайте вашего фреймворка, чтобы принять участие в разработке, на почту приходит ссылка, но когда по ней перехожу выдает «попытка взлома заблокирована». Пробовал несколько раз.
2. Не нашёл списка контрибьюторов, сколько живых человек принимает участие в проекте?
3. Можете привести несколько сайтов реализованных на этом фреймворке?
4. Есть ли пример исходного кода небольшого типичного проекта реализованного на этом фреймворке? Чтобы можно было быстро оценить как выглядит практика его применения.
Некоторые, живя в современном мире, до сих пор не могут осознать, что амбарный замок — не самое лучшее средство защиты всего на свете и пытаются применить его в любой ситуации.
Защищать от копирования цифровую информацию в эпоху интернета, защищаться от свободного обмена этой информацией… Так же глупо и бесполезно, как было бы защищаться от обмена бумажными книгами.
Продуктивнее направить усилия на упаковку контента в такие форматы, которые не мешают распространению, а делают официальные источники более удобными. Как это сейчас происходит с музыкой и сериалами.
Не можете упаковать свою инфу в такой или похожего принципа формат? Есть краудфандинг.
Продуктивнее не бороться с трекерами, а использовать их массовость и бесплатность в своих целях. Много ли других площадок с миллионной аудиторией, которые позволят вам предложить их пользователям свою информацию бесплатно?
Резать код (что понимают чуть менее чем все под декомпозицией) — это плохо.
Возможно вам не повезло с окружением. Я вообще не встречал подобного, но лучше обратиться к Макконнелуу и Фаулеру, как в их книгах применяется этот термин? И правил «ни одной ф-и длиннее пяти строк!» тоже нигде не припомню, обычно правила звучат так: «обращать внимание на функции длиннее n строк, возможно они нуждаются в рефакторинге». Иногда такие высказывания даже подтверждаются статистикой, кажется тот же Макконнелл приводил данные по корреляции длины строк метода и негативными факторами, но не суть.
У декомпозиции есть цель, если цель «не допускать функции длиннее 5 строк», то проблема именно в цели. Как правило целью декомпозиции ставят что то адекватное, например: упростить понимание кода, избавиться от вредного дублирования и тп. Цель появляется не из неоткуда, разработчик сталкивается с проблемой или руководствуясь своим опытом видит, что она возникнет. Итого, наиболее типичный случай выглядит примерно так: разработчик обнаруживает проблему, для ее решения использует декомпозицию. Создание абстракций, нейминг — вечный спутник этого процесса. Под декомпозицией в программировании (да и не только) собственно и понимают вынос части чего то в какую то отдельную абстракцию.
Проблема неуместности и неверного применения инструмента в конкретных случаях — отдельная тема.
Еще как имеет. Мы говорим «открыть дверь» и не приводим определений для слов «открыть» и «дверь». Сами определения вырезаны из выражения и заменены на абстрактные обозначения.
Декомпозиция — это просто порезать на куски, все. Именования при декомпозиции вообще не предполагается.
Если вы решили употреблять этот термин в таком значении, значит намерено делаете его бесполезным. Осталось понять, вы это делаете только ради пустого спора или действительно, услышав, что кто-то намерен декомпозировать слишком большую функцию ужаснетесь: «о нет, они хотят порезать код на неименованные куски!».
Так код становится легкочитаемым и самодокументированным не из-за того что вы порезали его на куски, декомпозировав, а из-за того, что вы дали читаемое и понятное пояснение этим кускам.
Как раз таки из-за того, что порезали и дали подходящие имена. Вы приводили пример с абзацем текста, так вот, абзац текста можно написать и одним сложным составным предложением. В нем будет куча сложной пунктуации, придется много раз повторять одинаковые длинные конструкции, чтобы избавится от неоднозначности и понять такой текст будет сложно. Сложно будет и что то в него добавить не поломав логики всего высказывания.
Собственно человек только и делает, что запаковывает всё в абстракции для того, чтобы упростить понимание. Мы создаем различные объекты реального мира, конструкции, механизмы и даем этому всему лаконичные названия, даем названия действиям с этими объектами и тд.
Естественно важен, никто не предлагает делать рефакторинг ради рефакторинга. Речь идет о том, что «если стейкхолдер всего один» — это еще не повод всё паковать в одну функцию, есть и достаточное количество других причин.
Затем, что это не единственная причина, по которой стоит декомпозировать функцию. Как раз чтобы облегчить восприятие и упростить сопровождение. Общую логику объемного кода проще понять, если он разбит на именованные абстракции, этими абстракциями проще управлять, повторяющиеся куски сложнее поддерживать и тд.
Да да. Сеньоры видимо читают доки на английском, а потом своими словами объясняют мидлам и джунам чего там понаписано. Заодно открывают им секреты xml.
Разработчики уровня «Senior» знают JavaScript, XML, Ajax, владеют английским языком на уровне, достаточном для чтения технической документации. Востребованы навыки работы в среде Linux / UNIX, опыт настройки и администрирования web-серверов (Apache), систем контроля версий.
Так вот он какой, оказывается, PHP Senior. Умеет всё кроме PHP.
Судя по описанному в этой статье, эксперимент Розенхана может быть успешно повторен в реалиях нынешней отечественной психиатрии, но с прежним результатом.
Почему предложенное решение называют аналогом скоупов? Из скоупов всё таки принято возвращать билдер, что позволяет их сцеплять и активно переиспользовать.
Например, нам нужно выводить популярные статьи в разных контекстах (популярные одного автора/всех авторов/в определенном хабе/за определенное время/...). Популярность определяется несколькими условиями (лайки, просмотры, пороговые значения), мы выносим эти условия в отдельный скоуп, возвращаем билдер и теперь можем использовать его в составе любых запросах.
Как предлагается решать такую задачу без eloquent scopes?
А какая ошибка диагностики на ваш взгляд более распространена: положительная (здорового ложно считают больным) или отрицательная (больного ложно считают здоровым)?
В крупных опросниках, типа СМИЛ просто вводится несколько раз один и тот же вопрос, но по разному сформулированный, даешь разные ответы — значит обманываешь. Это метрика именно лживости, еще есть метрика искренности, там вопросы типа «временами мне в голову приходят такие нехорошие мысли, что о них лучше не рассказывать».
Всё верно, я понимаю как считается вероятность и согласен, что она 1/2. Просто этот пример в статье используется для иллюстрации альтернативной логики и она ну вот такая. Что при выпадении орла у него опять есть 2 вероятности и в обоих из них он имеет брата. Из того же следует, что если в случае орла моряк решает завести не двух, а более детей, то опрашиваемый будет воспринимать вероятность иметь брата еще выше.
В условиях задачи вопрос об оценке вероятности иметь сводного брата (сводную сестру) задавали ребёнку моряка
да и именно его в этой задаче считают наблюдателем. Именно он рассуждает таким образом, что у него было три варианта родится, и решает, что его шансы 1/3.
2. Не нашёл списка контрибьюторов, сколько живых человек принимает участие в проекте?
3. Можете привести несколько сайтов реализованных на этом фреймворке?
4. Есть ли пример исходного кода небольшого типичного проекта реализованного на этом фреймворке? Чтобы можно было быстро оценить как выглядит практика его применения.
Например:
Поля A и B одного цвета.
Защищать от копирования цифровую информацию в эпоху интернета, защищаться от свободного обмена этой информацией… Так же глупо и бесполезно, как было бы защищаться от обмена бумажными книгами.
Продуктивнее направить усилия на упаковку контента в такие форматы, которые не мешают распространению, а делают официальные источники более удобными. Как это сейчас происходит с музыкой и сериалами.
Не можете упаковать свою инфу в такой или похожего принципа формат? Есть краудфандинг.
Продуктивнее не бороться с трекерами, а использовать их массовость и бесплатность в своих целях. Много ли других площадок с миллионной аудиторией, которые позволят вам предложить их пользователям свою информацию бесплатно?
Возможно вам не повезло с окружением. Я вообще не встречал подобного, но лучше обратиться к Макконнелуу и Фаулеру, как в их книгах применяется этот термин? И правил «ни одной ф-и длиннее пяти строк!» тоже нигде не припомню, обычно правила звучат так: «обращать внимание на функции длиннее n строк, возможно они нуждаются в рефакторинге». Иногда такие высказывания даже подтверждаются статистикой, кажется тот же Макконнелл приводил данные по корреляции длины строк метода и негативными факторами, но не суть.
У декомпозиции есть цель, если цель «не допускать функции длиннее 5 строк», то проблема именно в цели. Как правило целью декомпозиции ставят что то адекватное, например: упростить понимание кода, избавиться от вредного дублирования и тп. Цель появляется не из неоткуда, разработчик сталкивается с проблемой или руководствуясь своим опытом видит, что она возникнет. Итого, наиболее типичный случай выглядит примерно так: разработчик обнаруживает проблему, для ее решения использует декомпозицию. Создание абстракций, нейминг — вечный спутник этого процесса. Под декомпозицией в программировании (да и не только) собственно и понимают вынос части чего то в какую то отдельную абстракцию.
Проблема неуместности и неверного применения инструмента в конкретных случаях — отдельная тема.
разве?
Далее
Еще как имеет. Мы говорим «открыть дверь» и не приводим определений для слов «открыть» и «дверь». Сами определения вырезаны из выражения и заменены на абстрактные обозначения.
Если вы решили употреблять этот термин в таком значении, значит намерено делаете его бесполезным. Осталось понять, вы это делаете только ради пустого спора или действительно, услышав, что кто-то намерен декомпозировать слишком большую функцию ужаснетесь: «о нет, они хотят порезать код на неименованные куски!».
Как раз таки из-за того, что порезали и дали подходящие имена. Вы приводили пример с абзацем текста, так вот, абзац текста можно написать и одним сложным составным предложением. В нем будет куча сложной пунктуации, придется много раз повторять одинаковые длинные конструкции, чтобы избавится от неоднозначности и понять такой текст будет сложно. Сложно будет и что то в него добавить не поломав логики всего высказывания.
Собственно человек только и делает, что запаковывает всё в абстракции для того, чтобы упростить понимание. Мы создаем различные объекты реального мира, конструкции, механизмы и даем этому всему лаконичные названия, даем названия действиям с этими объектами и тд.
Наоборот. Пришло время прибраться в салоне? Отправляешь машину на подработку, пускай заработает себе на «салон красоты». И сама же туда съездит :)
Да да. Сеньоры видимо читают доки на английском, а потом своими словами объясняют мидлам и джунам чего там понаписано. Заодно открывают им секреты xml.
Так вот он какой, оказывается, PHP Senior. Умеет всё кроме PHP.
Еще интересно, что насчет жадной загрузки, не используете?
Например, нам нужно выводить популярные статьи в разных контекстах (популярные одного автора/всех авторов/в определенном хабе/за определенное время/...). Популярность определяется несколькими условиями (лайки, просмотры, пороговые значения), мы выносим эти условия в отдельный скоуп, возвращаем билдер и теперь можем использовать его в составе любых запросах.
Как предлагается решать такую задачу без eloquent scopes?
да и именно его в этой задаче считают наблюдателем. Именно он рассуждает таким образом, что у него было три варианта родится, и решает, что его шансы 1/3.