Ого, да у вас и вправду серьезные проблемы с тем, как забрать человека из одной конторы, и быть уверенным что он тот самый.
Для этого ему нужно писать статьи и публикации, всячески пиариться, и, в общем и целом, ему уже недостаточно просто знать свое дело, ему нужно пытаться выполнять некий перечень действий, без которого он не понравится тем людям, которые в принципе не соображают ничего в том, что он делает.
Господи, что трудного я не понимаю в разработке дизайна потоков/корутин/фиберов?
Что вы вокруг этой темы все скачете, развели тут бардак XD
Неужели так сложно писать код вида:
$base = new ThreadBase();
$thread = new Thread(function () { ...some_code… });
$base->run(thread, thread2,… threadn);
$base->when(thread, thread2,… threadn)->done(function (req, res) {
// some code
});
Ну то есть вот в такой нотации что не ясно то?
То future() какой-то придумают, чтобы повесить событие и только потом сделать обычный синхронный запрос.
То превратят синхронный в асинхронный, а потом наоборот, запутают всех и сидят типа гении, раз никто не понимает. То какие-то корутины, то еще что-то…
В PHP симуляция потоков все ставит на свои места…
Неужто так сложно относится к процессу многопоточности, как к чтению например данных с сервака?
Кинули запрос, получили ответ, считали ответ, перевели из json-а в данные, работаем с полученными данными.
В PHP не хватает разве что возможности подождать конкретный поток или массив потоков, они там пачкой запускаются ровно столько, сколько нужно, в яваскрипте этой проблемы нет — «деферы» есть.
Согласен, всегда писать на деферах — можно уехать крышей, но сообразить для них обертку и не велосипедить — это мужество нужно.
Как по мне — цирк, блин.
Вторична не одежда, друг мой щедрый на дизлайки, вторично то, что те, кто идут за знаниями, считают ее вторичной, тогда те кто «создают» эти знания считают ее первичной.
Мы видим директора в кресле и думаем что он молодца, он что-то задвигает, а мы верим. И потом что получается, все видят вокруг себя каждый день.
Степень важности курсов легко определять по одежде выступающего.
Если там толстовка, скорее всего человек делает то что дешево, быстро и работает, оно важно полезно и нужно.
Если там пиджак, мебель и дорогой офис — скорее всего он просто придумал теорию из ничего.
Как то так случайно получается, что чуваки в майках и толстовках обычно гении, а чуваки в пиджаках — трепачи и бизнесмены.
Наверное самый разумный подход, это когда действительно есть обьект app хранящий экземпляры каждого модуля с возможностью доступа к ним в виде app.module.submodule.submodule.action();
И он же следит за dependency, и он же сжимает код и в общем-то молодец даже
Ну меня больше интересует сайт (или как сейчас модно — приложение), которое доступно в URL в интернете.
Если раскрывать вопрос по демонстрации: ну вот в качестве примера написать на этой позиции обычный такой landing-site с одной стороны на 2 страницы (чтобы была первая и вторая), с другой стороны с отправкой на email письма например, с третьей стороны с поддержкой «тем» и «языков»,
Ну то есть в каждой из сфер по два примера, и самое обидное — связать их так, чтобы была минимальная связность.
Обычно моя проблема в том, что модуль, который я внедряю в чей-то битрикс-говнокод так или иначе требует взаимодействия с самим битриксом. И начинаются связи и невозможность разделить его на маленькие модули — загоны в стиле — а где хранить ссылки на уже созданные объекты? если их хранить в каждом дочернем модуле, то это затраты памяти, делать их через статику — трудности в поддержке потом, когда видишь Class::method() и понимаешь что походу пора идти читать, что там в классе и когда писали.
Даже целиком выписывая программу на интерфейсах и передавая только готовые объекты из функции в функцию все равно вдалбливаешься в необходимость некой шины, которая контроллирует все что было сделано и вся модульная структура снова сыпется по кусочкам или наполняется статическими вызовами.
Где баланс? Показал бы только пример кода.
Рассмотреть контроллер под конкретные случаи типа — контроллер шаблона. Это контроллер вообще? Нет наверное. С другой стороны ему нужно подготовить css/js под конкретный модуль, а родительскому — под себя и еще забрать у всех потомков и так рекурсией хрен знает сколько раз, чтобы была одна точка контроля на каждом уровне. Вот где самый расколбас.
Написать api на контроллерах, который возвращает json и принимает get/post/head быстро и легко — и поддерживать потом тоже легко. А вот когда начинается игра в «продвижение сайта» — начинается веселуха. Вот у тебя скрипты в модуле лежат — ты их слил в один красиво так, родительский модуль подхватил… и тут понимаешь, что jquery был в одном модуле и в другом — оппа уже dependency. А если депы, то значит контроль версий. А если контроль версий — то нужна шина — глобальный модуль, отвечающий за другие модули.
И поди его сделай фасадом, поди пойми, что в нем команда, а что просто объект, учитывая что весь код по сути состоит тоже ведь из команд. И вот эта двойственность слов — под словом команда можно понять это это и вон то — все губит. Вместо красивого кода получается опять связанный клубок ниток.
Опять же — примеры нужны, хоть какие-нибудь. Не картинки, а код — с определением в стиле «давайте представим что вот этот обьект — это команда».
Не холивара ради, но интереса — около года назад видел статью парня, который на английском языке жестоко агрил насчет того, что люди не создают модули, а пишут значит mvc-приложения, а он, значит, видел весь смысл в модулях, а те делил на еще более мелкие модули.
Страница та выпадала в гугле по какому-то жутко умному запросу про MVC и не могла быть найдена просто так — просто была мусором в сети с кучей комментариев в стиле «хватит агрить парень, мир какой он есть!»
А сейчас вот, куча фамилий, сотни диаграм, на выходе вывод — ребята, вы неправильно понимаете MVC. Пора прекратить класть файлики в папки views, а нужно просто писать модули, которые имеют самостоятельный html/js, ну то есть вас пару лет за нос водили, теперь идем в другую сторону.
Радость то! Пришло таки :)
К слову о фасадах — это было очень круто разжевано в о-рейли, паттерны проектирования, они там писали контроллер для «умного дома» в упрощенном варианте. И использовали паттерн Фасад как мега-модуль (который по сути объединяет десяток Комманд), паттерн Контроллер — как навесить на каждую кнопку пульта действие (для независимости к каждой кнопке вешалось действие в виде объекта), а паттерн Команда (это когда конкретное действие описывается как класс, который станет объектом)
Может я конечно пол-статьи не понял, я такой паренек, который значит «увлекается в свободное время», а на работе умничать времени нету. Любопытно взглянуть на простейший пример нотации такого приложения, в котором логика контроллера внешнего модуля отвечающего за layout (имеющего вещи которые нужно сделать при инициализации) — не связана с модулем какой-нибудь драной кнопки или выпадающего меню, и как это сделать вне связей их друг с другом.
exports он разумеется есть, но чтобы добиться полной независимости, очень любопытно увидеть пример. на любом языке.
Зато у меня встречался тот, который пока я составляю ТЗ заказывает у того, кто «больше сотрудников в штате имеет», или просто «у друга»
Сложность не составить ТЗ, а упросить его начать работать с тобой, пока у тебя еще нет ТЗ
Считаю, что ТЗ нужно составлять не из соображений «иди мне и распиши как надо», а из соображений «чувак, над твоим проектом придется работать, долго работать, ОЧЕНЬ ДОЛГО работать, ты хотя бы составь ТЗ, чтобы понять насколько это сложно, а потом будем обсуждать оплату».
Обычно «маленький сайтик с регистрацией, начислением баллов, магазином сувениров и регистрацией» предполагается как штука, которую подобно кролику достали из шляпы (актуально: «возьмите готовое решение, вон их сколько»), попытка объяснить, что это все придется делать, причем заново, заканчивается в лучшем случае обвинением в непрофессионализме, в худшем — «я сюда не поговорить пришел, а найти профессионала, мои деньги стоят для меня очень дорого, не хочешь ты, найдем другого лоха».
А вот когда он сам составит ТЗ — ему наверное больно узнавать, что мне его ТЗ ни в болт не впилось, но это необходимая точка сортировки клиентов — если он «смог» составить ТЗ, значит он понимает, за что и почему он платит.
Это чертовски удобно, когда пишешь яваскрипт код под такую верстку, и в стилях вложенности по минимуму, и редактировать легко.
Молекулы? Что?
Для этого ему нужно писать статьи и публикации, всячески пиариться, и, в общем и целом, ему уже недостаточно просто знать свое дело, ему нужно пытаться выполнять некий перечень действий, без которого он не понравится тем людям, которые в принципе не соображают ничего в том, что он делает.
Что вы вокруг этой темы все скачете, развели тут бардак XD
Неужели так сложно писать код вида:
$base = new ThreadBase();
$thread = new Thread(function () { ...some_code… });
$base->run(thread, thread2,… threadn);
$base->when(thread, thread2,… threadn)->done(function (req, res) {
// some code
});
Ну то есть вот в такой нотации что не ясно то?
То future() какой-то придумают, чтобы повесить событие и только потом сделать обычный синхронный запрос.
То превратят синхронный в асинхронный, а потом наоборот, запутают всех и сидят типа гении, раз никто не понимает. То какие-то корутины, то еще что-то…
В PHP симуляция потоков все ставит на свои места…
Неужто так сложно относится к процессу многопоточности, как к чтению например данных с сервака?
Кинули запрос, получили ответ, считали ответ, перевели из json-а в данные, работаем с полученными данными.
В PHP не хватает разве что возможности подождать конкретный поток или массив потоков, они там пачкой запускаются ровно столько, сколько нужно, в яваскрипте этой проблемы нет — «деферы» есть.
Согласен, всегда писать на деферах — можно уехать крышей, но сообразить для них обертку и не велосипедить — это мужество нужно.
Как по мне — цирк, блин.
Мы видим директора в кресле и думаем что он молодца, он что-то задвигает, а мы верим. И потом что получается, все видят вокруг себя каждый день.
Если там толстовка, скорее всего человек делает то что дешево, быстро и работает, оно важно полезно и нужно.
Если там пиджак, мебель и дорогой офис — скорее всего он просто придумал теорию из ничего.
Как то так случайно получается, что чуваки в майках и толстовках обычно гении, а чуваки в пиджаках — трепачи и бизнесмены.
И он же следит за dependency, и он же сжимает код и в общем-то молодец даже
Если раскрывать вопрос по демонстрации: ну вот в качестве примера написать на этой позиции обычный такой landing-site с одной стороны на 2 страницы (чтобы была первая и вторая), с другой стороны с отправкой на email письма например, с третьей стороны с поддержкой «тем» и «языков»,
Ну то есть в каждой из сфер по два примера, и самое обидное — связать их так, чтобы была минимальная связность.
Обычно моя проблема в том, что модуль, который я внедряю в чей-то битрикс-говнокод так или иначе требует взаимодействия с самим битриксом. И начинаются связи и невозможность разделить его на маленькие модули — загоны в стиле — а где хранить ссылки на уже созданные объекты? если их хранить в каждом дочернем модуле, то это затраты памяти, делать их через статику — трудности в поддержке потом, когда видишь Class::method() и понимаешь что походу пора идти читать, что там в классе и когда писали.
Даже целиком выписывая программу на интерфейсах и передавая только готовые объекты из функции в функцию все равно вдалбливаешься в необходимость некой шины, которая контроллирует все что было сделано и вся модульная структура снова сыпется по кусочкам или наполняется статическими вызовами.
Где баланс? Показал бы только пример кода.
Рассмотреть контроллер под конкретные случаи типа — контроллер шаблона. Это контроллер вообще? Нет наверное. С другой стороны ему нужно подготовить css/js под конкретный модуль, а родительскому — под себя и еще забрать у всех потомков и так рекурсией хрен знает сколько раз, чтобы была одна точка контроля на каждом уровне. Вот где самый расколбас.
Написать api на контроллерах, который возвращает json и принимает get/post/head быстро и легко — и поддерживать потом тоже легко. А вот когда начинается игра в «продвижение сайта» — начинается веселуха. Вот у тебя скрипты в модуле лежат — ты их слил в один красиво так, родительский модуль подхватил… и тут понимаешь, что jquery был в одном модуле и в другом — оппа уже dependency. А если депы, то значит контроль версий. А если контроль версий — то нужна шина — глобальный модуль, отвечающий за другие модули.
И поди его сделай фасадом, поди пойми, что в нем команда, а что просто объект, учитывая что весь код по сути состоит тоже ведь из команд. И вот эта двойственность слов — под словом команда можно понять это это и вон то — все губит. Вместо красивого кода получается опять связанный клубок ниток.
Опять же — примеры нужны, хоть какие-нибудь. Не картинки, а код — с определением в стиле «давайте представим что вот этот обьект — это команда».
Не холивара ради, но интереса — около года назад видел статью парня, который на английском языке жестоко агрил насчет того, что люди не создают модули, а пишут значит mvc-приложения, а он, значит, видел весь смысл в модулях, а те делил на еще более мелкие модули.
Страница та выпадала в гугле по какому-то жутко умному запросу про MVC и не могла быть найдена просто так — просто была мусором в сети с кучей комментариев в стиле «хватит агрить парень, мир какой он есть!»
А сейчас вот, куча фамилий, сотни диаграм, на выходе вывод — ребята, вы неправильно понимаете MVC. Пора прекратить класть файлики в папки views, а нужно просто писать модули, которые имеют самостоятельный html/js, ну то есть вас пару лет за нос водили, теперь идем в другую сторону.
Радость то! Пришло таки :)
К слову о фасадах — это было очень круто разжевано в о-рейли, паттерны проектирования, они там писали контроллер для «умного дома» в упрощенном варианте. И использовали паттерн Фасад как мега-модуль (который по сути объединяет десяток Комманд), паттерн Контроллер — как навесить на каждую кнопку пульта действие (для независимости к каждой кнопке вешалось действие в виде объекта), а паттерн Команда (это когда конкретное действие описывается как класс, который станет объектом)
Может я конечно пол-статьи не понял, я такой паренек, который значит «увлекается в свободное время», а на работе умничать времени нету. Любопытно взглянуть на простейший пример нотации такого приложения, в котором логика контроллера внешнего модуля отвечающего за layout (имеющего вещи которые нужно сделать при инициализации) — не связана с модулем какой-нибудь драной кнопки или выпадающего меню, и как это сделать вне связей их друг с другом.
exports он разумеется есть, но чтобы добиться полной независимости, очень любопытно увидеть пример. на любом языке.
Сложность не составить ТЗ, а упросить его начать работать с тобой, пока у тебя еще нет ТЗ
Обычно «маленький сайтик с регистрацией, начислением баллов, магазином сувениров и регистрацией» предполагается как штука, которую подобно кролику достали из шляпы (актуально: «возьмите готовое решение, вон их сколько»), попытка объяснить, что это все придется делать, причем заново, заканчивается в лучшем случае обвинением в непрофессионализме, в худшем — «я сюда не поговорить пришел, а найти профессионала, мои деньги стоят для меня очень дорого, не хочешь ты, найдем другого лоха».
А вот когда он сам составит ТЗ — ему наверное больно узнавать, что мне его ТЗ ни в болт не впилось, но это необходимая точка сортировки клиентов — если он «смог» составить ТЗ, значит он понимает, за что и почему он платит.