Расширенная регуляризация нейронных сетей в интернет-магазинах — с помощью… напалма

Мощный поток сознания! Зашел прочитать про интернет-магазины и оказался погребен под лавиной ссылок, терминов и имен собственных. Как-то из всего этого извлек, что все эти штучки применимы только для крупных магазинов с кол-вом продаж over 100500 и выдохнул с облегчением — не мой сегмент. Потому как без тяжелых наркотиков такое не вкуривается, а с тяжелыми — здоровье не позволяет. Завидую я вашему здоровью, коллега!

Hype Driven Development

Правильно :) Мне, по-большому счету, все равно, кто расставил эти буквы в слова в таком порядке, меня, по-большому счету, интересует прежде всего информация, которая передается при помощи этих слов. Это https://habrahabr.ru/, а не http://yapishu.net/

Hype Driven Development

Коллега poxu, вы сбиваете фокус внимания со вкуса вина на цвет бутылки, в которую его разлили. Вам есть что сказать за само вино?

Блеск и нищета php. Эволюция языка от 4.x к 7.1

Да, очень похоже на то, что нужно :)

<?php
require 'vendor/autoload.php';

$i = 0;
$app = function ($request, $response) use ($i) {
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World $i\n");
    $i++;
};

$loop = React\EventLoop\Factory::create();
$socket = new React\Socket\Server($loop);
$http = new React\Http\Server($socket, $loop);

$http->on('request', $app);
echo "Server running at http://127.0.0.1:1337\n";

$socket->listen(1337);
$loop->run();

Блеск и нищета php. Эволюция языка от 4.x к 7.1

Слой REST/JSON-сервисов в web-приложениях, если удастся вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python). Ну или в рамках Apache/Nginx запускать PHP-приложения со стадиями инициализации приложения, обработки запросов, завершения приложения (типа servlet'ов). Делать вот это все на каждый GET/POST запрос с web'а — весьма расточительно, не говоря уже о сборке HTML'а на стороне сервера. В web-разработке позиции PHP весьма сильны, но с фронта всех теснит JS — остается back.

Scrum от военного летчика: Искусство делать вдвое больше дел в два раза быстрее

Он поперхнулся, а затем разрыдался: «Я не могу передать вам то счастье, что я испытал. Это изменило всю мою жизнь»

До этого момента читалось с интересом, а после — в памяти всплыло слово "секта".

Как насчёт класть каждую функцию в свой файл?

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

… для проекта, который не будет устанавливаться другим людям

вообще не дискутировал на тему. В своем pet-проекте каждый волен писать код настолько феерично, насколько он чувствует потребность.

Как насчёт класть каждую функцию в свой файл?

В таком случае — берите выше! Коллега saggid заново изобрел декомпозицию, которая является краеугольным камнем в разработке сложных систем. Посыл абсолютно тот же, а глобальность аналогии просто зашкаливающая. Круче может быть только изобрести заново двоичную систему.

Дъявол кроется в деталях, если что.

Как насчёт класть каждую функцию в свой файл?

Если коротко, то архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды.

Микросервисы — современное представление сервис-ориентированной архитектуры (SOA), используемое для создания распределенных программных систем. Как и в SOA, модули в архитектуре микросервисов взаимодействуют по сети друг с другом для выполнения цели.

Что-то я не заметил, чтобы коллега saggid предлагал использовать сетевые протоколы для вызова своих функций, так что сравнение с микросервисами удачно только в части "микро".

Unit-тестирование в сложных приложениях

"Визуальное программирование" в среде builder'а подразумевает автоматическую генерацию кода на выходе (для каждого фрейма и так три файла — h,cpp,dfm). Если продолжать данную традицию, то можно ожидать, что также возможно создание соответствующего unit-теста (*_Test.cpp или что-то подобное) для каждого компонента, в том же автоматическом режиме. Я сам с таким не сталкивался, но допускаю, что если можно сгенерировать по шаблону некий код, то можно сгенерировать и unit-тест для него.

Unit-тестирование в сложных приложениях

и еще такой момент, коллега — судя по вашему описанию, вы широко используете возможности по генерации кода, предоставляемые средой. Тестовый код по отношению к тестируемому идет как 1:2/3/4… (в зависимости от сложности логики тестируемого кода). Если вы до сих пор не столкнулись с удобным инструментом для автоматической генерации unit-тестов в своей среде, то вряд ли он существует. Захотите ли вы вручную создавать тесты для того кода, который нагенерит ваша среда? Посчитайте LOC вашего проекта и умножьте его на 2, для начала.

Unit-тестирование в сложных приложениях

Если я правильно понимаю, то вы используете предопределенные компоненты в качестве базовых, создаете на их основе собственные, которые связываете мышкой и немножко с клавиатуры. Полагаем, что предопределенные компоненты уже оттестированы, и нам их тестировать нет нужды. Значит нужно протестировать заданные свойства вновь созданных компонентов их связи между собой. Вряд ли легковесный CppUnit встроен с C++ Builder настолько, что все можно сделать также мышкой, поэтому придется делать ручками с клавиатуры. Т.к. для строительства приложения вы используете компоненты, то unit-тестирование — самое то. Мокируем окружение, создаем собственную компоненту и проверяем те свойства, которые мы напрограммировали для этой компоненты мышкой и с клавы. Главный вопрос — есть ли подходящая билиотека для создания моков? Сообщество говорит, что есть opmock. Сам я подобных связок не пробовал, но начал бы копать с этого.

всё работает без единой строчки кода.

подозреваю, что если как следует поискать в файлах проекта, то все-таки код можно будет обнаружить :)

Unit-тестирование в сложных приложениях

А вы пробовали DUnit? Да, он давно не менялся, но и Delphi не вчера родилось. Может вполне юзабельно окажется.

Unit-тестирование в сложных приложениях

Извините, пожалуйста, не хотел никого испугать.

Unit-тестирование в сложных приложениях

Если рассуждать с точки зрения TDD, то вы совершенно правы.

Unit-тестирование в сложных приложениях

Ну как же не сказано? Вот, в самом начале:

Ни один разработчик в здравом уме и трезвой памяти при разработке сложных приложений (> 100K LOC, например) не станет отрицать необходимость использования тестирования вообще и модульного тестирования (unit tests) в частности.

Magento 2: Создание грида в adminhtml

Спасибо, коллега. Внес изменения в код примера.

Magento 2: Создание грида в adminhtml

К сожалению перфекционистам в M2 опасно — она еще очень сырая, неоднородная по реализации система с незавершенными архитектурными решениями (те же репозитории, все еще полностью не заменившие ресурс-модели). Любой владелец магазина на М2 — доброневольный бета-тестер. Работа над выправлением этой ситуации идет, но сможет ли команда разработчиков ее выправить — вопрос открытый. Я бы поставил на них, если бы они отказались от обратной совместимости (которой и так нет) и провели генеральную чистку и реструктуризацию кода и данных, но это стало бы уже М3. Таких маневров community может и не выдержать, а без своих расширений Magento превратится в тот же Shopify, только еще и на своем "железе". Ну а пока разработчики борются со сложностью и, судя по тому, что тесты на Travis'е у них не проходят уже около месяца, борьба идет ожесточенная.

Хотя, она все же чертовски интересная:)

А вот тут полностью согласен :) Весьма любопытный пример распределенной разработки приложений.

Magento 2: Создание грида в adminhtml

Богатая функциональность, получаемая "из-коробки" — это раз. Большое кол-во расширений основного функционала, созданных сторонними разработчиками — это два. Все еще значительное community (best practice & support, как отметил коллега Sergiy) — это три. И плюс куча времени и средств закопанного в нее как разработчиками (основного функционала и расширений), так и владельцами магазинов.

И да, профит в даном случае огромный есть только тогда когда систему заведомо будут поддерживать очень долгое время и большое количество разных людей.

© vpodorozh

Строим свой full-stack на JavaScript: Сервер

В пределе всё всё равно сводится к маш. кодам. Но люди почему-то не любят их использовать.