От внедрения зависимостей к отказу от зависимостей

Тема действительно интересная, но по итогу все равно остается много вопросов.

1. Мы выделили весь чистый код tryAccept. И tryAccept сам по себе прекрасен. Но как тестировать tryAcceptComposition? Мы возвращаемся к тому с чего начали.

2. Если добавиться нечистого кода, например по итогу нам надо уведомлять некий третий сервис, тогда нам опять же придется или расширять tryAcceptComposition или делать еще одну обертку, что тоже не упрощает код по сравнению с ООП подходом.

3. Хотелось бы еще посмотреть как работает по итогу связка controller -> tryAcceptComposition -> tryAccept. В случае с DI контрейнером у нас есть только одно место где мы конфигурируем дерево зависимостей обращаясь к ENV ssm:// и т.д. Самый грязный код оставался в точке входа. В случае с композицией каждая *composition должна иметь доступ к конфигурации ( connectionString ) что тоже оставляет вопросы.

Habr vs Medium: сколько можно заработать, опубликовав 9 статей на Medium.com

DmitrySpb79 еще момент что для того чтобы стать партнером Medium необходим Stripe аккаунт который получить жителям СНГ не так просто.

Внедри это полностью. DI-in-JS

Развивая тему — да, ты можешь пихать `container` во все классы и таким образом превратить его в ServiceLocator. Но мы ведь не будем так делать.

class AuthStorage {
  constructor(storage: CookieStorage) {
    this.storage = storage;
  }
}
vs
class AuthStorage {
  constructor(container: IDIContainer) {
    this.storage = container.get<AuthStorage>("AuthStorage");
  }
}

Внедри это полностью. DI-in-JS

container.get — это чистой воды Service Locator,

нет. Это Dependency Injection Container. И разница есть
habr.com/ru/post/465395

Внедри это полностью. DI-in-JS

Затенение — плохая практика.

class Foo {
  constructor(dbConnection: DbConnection = "DbConnection")
}

т.е. ты ожидаешь объект, но инициализируешь его как строку. И делаешь это не потому что Foo это необходимо, но для того чтобы сделать его «Injectable». А Foo не должен знать что Injectable он или нет.

2 Как будет работать этот подход после того по коду пройдет `uglify`?

3. Что если мне надо внедрить не объект, а строку (или объект который является результатом выполенеия некой функции. Например DSN который будет разным для разных окружений?

Я тоже интересовался этой темой и написал свой велосипед
www.npmjs.com/package/rsdi

// your classes 
class CookieStorage {}
class AuthStorage {
  constructor(storage: CookieStorage) {}
}

// configure DI
import DIContainer, { object, get, factory, IDIContainer } from "rsdi";
 
const config = {
    "ENV": "PRODUCTION",               // define raw value
    "AuthStorage": object(AuthStorage).construct(
       get("Storage")                         // refer to another dependency       
    ),
    "Storage": object(CookieStorage),         // constructor without arguments       
    "BrowserHistory": factory(configureHistory), // factory (will be called only once)  
};
const container = new DIContainer();
container.addDefinitions(config);
 
function configureHistory(container: IDIContainer): History {
    const history = createBrowserHistory();
    const env = container.get("ENV");
    if (env === "production") {
        // do what you need
    }
    return history;
}
 
// in your code
 
const env = container.get<string>("ENV"); // PRODUCTION
const authStorage = container.get<AuthStorage>("AuthStorage");  // object of AuthStorage
const history = container.get<History>("BrowserHistory");  // History singleton will be returned

Yii 2.0.6

Опечатался в первом комментарии, имел в виду вот этот github.com/yiisoft/yii2/issues/593

Yii 2.0.6

Cоздавал подобный issue github.com/yiisoft/yii2/issues/7928 с ссылкой все на тот же phinx.org Но тогда он не получил поддержки. Хотя идею эту я реализовал на одном из проектов и остался ей полностьью доволен. Особенно помогает при старте проекта когда 90% миграции добавляют сущность.

Как работают rooms в Socket.io

Как вы думаете несет ли какую-то смысловую нагрузку ваш комментарий? Если вам все понятно — проходите мимо. В начале топика я отметил что стаья для новичков. Возможно вы хотели показать какой вы умный? Хм… боюсь что вышло наоборот.

Автодокументация мобильных веб-сервисов на примере Yii

Swagger генеринует json по которому можно потом сделать свой swagger-ui c блекджеком и бутстрапом.

Создание простого CRUD-приложения с помощью Yii2

$_POST['Post']['title']; всегда задан во вьюшке. С другой стороны что вам мешает использовать кастомный метод Arr::path?

На счет Html::a() мне кажется yii запись гораздо комактнее и во вьюшках будет восприниматься гораздо легче

Планируете ли вы навсегда уехать из России раньше 2017 года?

А что если я гражданин Украины/Белоруссии и планирую уехать(не в Россию — шило на мыло)?

Конвертирование Zend конфига из ini в yaml. Подводные камни

да вы правы, тоже нашел эту встроенную опцию когда разбирался. Не помню когда привязалось ко мне 1002 опция и кочевала из проекта в проект.

Конвертирование Zend конфига из ini в yaml. Подводные камни

>Хотя опыт, видимо, полезный — иногда не знаешь, где стелить соломку :)
И да, когда настураешь на грабли ты ведь этого не ожидаешь)

Конвертирование Zend конфига из ini в yaml. Подводные камни

«недостаточно протестированные изменения» — подскажите способ как тестировать с гарантией 100% не получить ошибку )?
Тут вопрос немного провакационный ;). Хорошо, а рефакторинг кода — это необходимость? Все работает — а мы начинаем код править, время тратить. Опять же появляется вероятность ошибок после рефакторинга. Зачем его делать )?
Да по сути можно было жить и со старым конфигом, но конфиг уже был достаточно большой. Проект также достаточно большой и развивается, конфиг все равно растет. Крайней необходимости не было. Но я честно не доверяю людям которые панически боятся вносить улучшения, без крайнее необходимости.

Конвертирование Zend конфига из ini в yaml. Подводные камни

Я не могу сказать что есть существенная разница. Тут скорей дело вкуса. Думаю что уместно говорить о лучше/хуже только с точки зрения читаемости/скорости внесения изменений для человека. Потому как разница в скорости обработки незначительна. Так вот если говорить об удобочитаемости я бы разпредалил места в следующем порядке yaml, php array, ini xml.

В Yii появились миграции

«Можно и SQL писать» — но это все равно неудобно :). С остальным согласен.
Сейчас невозможно работать, если есть FK, по крайнее мере, у меня миграции на достаточно большой базе создаются неправильно. Но тем не менее если бы работа была бы доведена до совершенства — это было удобнее. На счет миграции Mysql => SQLite… из моего опыта при миграции Mysql => Postgres на RoR (но как известно yii много идеи оттуда перенял) все равно многое приходилось допиливать, т.е. там еще хватит тоже гемороя.
В целом ничего против миграции не имею, миграции — это правильно и хорошо, а Yii вообще любимый фреймворк :). Но как информация к размышлению. Просто не люблю так работать на ранних стадиях развития проекта, когда база меняется постоянно :).

В Yii появились миграции

Что не нравится в таком подходе к миграциям — необходимость знания языка миграции $this->createTable('tbl_news', array(… каким бы простым он не был. И фактически невозможность изменения схемы при помощи любых других средств EMS и ему подобных.
Оч нравится идея www.antonoff.info/development/mysql-migration-with-php-project Миграция создается ./migrate.php create и все. Т.е. фактически анализируются изменения в схеме бд и создаются необходимые SQL запросы.
Т.е. например я создаю базу в mysql-workbench — это мне гораздо удобнее чем просто командами. Далее делаю ./migrate.php create. Это все что надо знать. Дальше все тоже самое.
К сожаления пока не устраивает работа с FK, но повторюсь идея таких миграции мне кажется намного лучше.

Необъяснимые особенности нашего мозга

это связанно с латентным торможением обычный мозг человека отсекает незначительное
а вот если ты Майкл Скофилд....