ммм… а почему просто не запустить скрипт руби. внутри которого любая магия?
например, «ruby my_script.rb [параметры командной строки]», а уже внутри файла и валидаторы параметров командной строки, и их дефолтные значения на случай незаполненности, и запуск сервера и любой другой код.
Может с простыми API и прокатит автомат, как с примером о погоде. Но на практике как правило все несколько сложнее: интеграция твоего софта(а это сразу куча «особенностей») с несколькими API, которые имеют некоторую вариативность для разных ситуаций и все могут влиять на всех. Тут никакой робот не прокатит. Иначе просто инсталлировали бы ERP-систему, указали где части ERP, где легаси системы, где кластер БД, где брокер очередей, где балансировщик и тд тп — а оно так вжиииик и всё само слилось в единую систему =) *замечтался*
Друзья, вопрос от «неосведомленного»: а зачем вообще делить на подсети? Речь про изоляцию, что бы я не могу работать с устройствами не из моей сети?
Какие плюшки дает деление(в локальных сетях), чем плохо дать маршрутизаторам ip-адреса с маской как у всех? Без обид, если задел делитантностью вопроса ;)
А я даже дождался начала прямого эфира. Посмотрел… лег в час ночи… уснул в два =)
Весь следующий день ходил и думал, как компания такого уровня может делать такие унылые мероприятия: все стенды закрыты, доказательств, что там было железо от АМД кроме их слов — не было. Показателей толком тоже не было — запустили БФ1 и мол вот, работает, в 4К! =) Причем на титане-х от конкурента! В конце мол вот Вегу покажем, запускают сетевую версию игры, ждут… ждут… даже свои же инженеры из зала начали освистывать происходящее. Вот запустилась игра, работает. Без FPS, без какой-либо конкретики.
Выводы по Ryzen можно только из рендера брать, что многопоток есть. Дак он и на FX есть/был.
В итоге да, пока в руки не попадёт железо, можно считать не было никакого мероприятия.
Кстати, я мельком прошелся по комментариям, не увидел замечательного момента (может плохо смотрел): пока пишешь ТЗ, т.е. разжевываешь задачу, в процессе видишь новые критерия, влияющие на решение. Новые комбинации значений этих критериев. Потребности во внесении изменений в заранее вроде бы складную модель решения и тд. Писать ТЗ в таком ключе абсолютно всегда полезно ;)
На всякий случай скажу, что у меня все оке, все схвачено и нет проблем на этом поприще =) Зашел так сказать точку зрения высказать.
Человека из топика разоряется, что «Как так, почему без ТЗ существует разработка». А на самом деле ТЗ ведь не цель, главное результат. Есть результат при минимуме рисков — молодцы. И не важно, было отдельное ТЗ и этап его построения до начала проекта или нет.
Ну я немного не довел суть истории. Можно год писать ТЗ на реализацию, просто к моменту окончания — мир поменялся и пиши снова. А в реальности надо MVP как можно раньше выпустить, в процессе получать обратную связь как можно раньше(ну и иметь серьезных прогеров/архитекторов для требуемой гибкости продукта). Т.е. этот год, ну 10 месяцев, можно иметь некий продукт с выхлопом пользы для заказчика и постепенным наращиванием «мяса».
Пишу ТЗ с 2009 года =) Были проекты, в которых написание ТЗ потопило проект (пока написали, утвердили со всеми, поменялось законодательство и другие правила игры). Были проекты, в которых концепт, полученный «на коленке» в процессе переговоров на первой встрече (не написание ТЗ), в процессе сильно отличался от необходимого решения и сей момент тоже потопил проект.
А вывод один и как везде: важен компромисс в % потраченного времени на разжевывание ТЗ по отношению к его реализацию (этапов больше, два для простоты). Вопрос должен звучать не «Надо ТЗ или нет?», а «В конкретном проекте какую степень детализации мы себе можем позволить для победы». Некоторые задачи понятны с первого взгляда (исправление очевидных багов, например). А некоторые требует проработку ТЗ на всех эшелонах: vision, спецификация функциональных, спецификация нефункциональных, спецификация системных требований, план внедрения и тд тп.
Эмпирически мы на подсознательном уровне понимаем, какую степень проработки ТЗ в своих проектах применять (ТЗ как… опаприкрывательство, как план для клиента, разработчика, тестировщика, внедренца и тд). Но общих правил тут наверное нет.
Было все — и промах с оценкой рынка и ЦА, и с моделью монетизации, и с привлечением и удержанием клиентов. Потом появились проблемы другого уровня — общение с инвесторами, советом директоров, партнерской сетью, грязной конкурентной борьбой, разбирательствами за торговые марки и правами на интеллектуальную собственность. В общем, полный набор прелестей стартапа. Все как в сериале “Силиконовая долина”.
Было бы очень интересно увидеть продолжение по проблемам «другого уровня» и Вашими путями решения.
Перечитал =) Я больше говорил о Вашей архитектуре работы с кэшем из PHP. И комментатор выше я думаю так же подумал.
Почему Вы не стали в PHP-приложении ТОЛЬКО ЧИТАТЬ значения из кэша? Ну и добавили бы минимум логики в приложение, мол получили значение из кэша — радуемся, а не получили — не рисуем компонент, вставляем дефолтное значение(если имеет место быть) и тд. А вот отдельный скрипт по крону запускается(или демон на постоянку с засыпанием), идет в чужой сервис и пишет итоги в кэш. PHP-приложение знать не знает, откуда в кэше данные. Поделили ответственность, создали задел на будущее и тд. В такой архитектуре я не вижу причин появления проблем из поста. С моих глаз у Вас борьба с ветряными мельницами: затолкали конкурентную запись с чтением в логику приложения с кучей клиентов/тредов и давай воевать там =)
Только в статье описано почему это вредно, когда демон на PHP! Как там говорят, «Демон на PHP, Карл!» =)
Конечно он у вас сворует процесс и т.д. А если на Go/C/Crystal и тд демон? Он ни процессов PHP, ни время процессора, ни оперативки, ни сил и времени не будет отнимать.
Человека выше заминусили совсем зазря, ИМХО.
Я сам не частый посетитель этого ресурса. Но время от времени скидывают нечто похожее на историю или серию историй на тему ИТ(там и боль, и юмор, и опыт), размещенных там.
Статья имеет больше литературной пользы, чем практической.
Читать приятно, забавно, но не полезно для разработчика => значит цикл может занять достойное место в литературных пабликах.
Сама по себе панель достаточно простой проект, на мой взгляд. А вот подкапотное взаимодействие с ОС на низком уровне — по мне задача сложная или как минимум серьезная =) Но тут вопрос не к рельсам уже, админки на них пишутся прекрасно. А к коду бизнес-логики.
Я бы сказал, что все три варианта хороши: MVC-фреймворки на «китах»(главных интерпритируемых языках). Какой язык больше нравится(опыт, окружение помощников, личное отношение и тд), в ту сторону и идти. Врятли в ближайшие 2-4года скажите себе: «Какой же я был, надо было Y, а не X выбирать».
Писать бэкенд (не сильно сложного проекта) на рельсах сплошное удовольствие. Да, там немного абстракций не доложили, но на первых парах можно и имеющимися не сильно напрягаясь обходиться.
Ну а случае реальных нагрузок, масштабируемся железом. Зато легко =) Ну или дербаним от монолита «узкие места» и пишем их на чем-нибудь компилируемом.
например, «ruby my_script.rb [параметры командной строки]», а уже внутри файла и валидаторы параметров командной строки, и их дефолтные значения на случай незаполненности, и запуск сервера и любой другой код.
Какие плюшки дает деление(в локальных сетях), чем плохо дать маршрутизаторам ip-адреса с маской как у всех? Без обид, если задел делитантностью вопроса ;)
Весь следующий день ходил и думал, как компания такого уровня может делать такие унылые мероприятия: все стенды закрыты, доказательств, что там было железо от АМД кроме их слов — не было. Показателей толком тоже не было — запустили БФ1 и мол вот, работает, в 4К! =) Причем на титане-х от конкурента! В конце мол вот Вегу покажем, запускают сетевую версию игры, ждут… ждут… даже свои же инженеры из зала начали освистывать происходящее. Вот запустилась игра, работает. Без FPS, без какой-либо конкретики.
Выводы по Ryzen можно только из рендера брать, что многопоток есть. Дак он и на FX есть/был.
В итоге да, пока в руки не попадёт железо, можно считать не было никакого мероприятия.
Человека из топика разоряется, что «Как так, почему без ТЗ существует разработка». А на самом деле ТЗ ведь не цель, главное результат. Есть результат при минимуме рисков — молодцы. И не важно, было отдельное ТЗ и этап его построения до начала проекта или нет.
А вывод один и как везде: важен компромисс в % потраченного времени на разжевывание ТЗ по отношению к его реализацию (этапов больше, два для простоты). Вопрос должен звучать не «Надо ТЗ или нет?», а «В конкретном проекте какую степень детализации мы себе можем позволить для победы». Некоторые задачи понятны с первого взгляда (исправление очевидных багов, например). А некоторые требует проработку ТЗ на всех эшелонах: vision, спецификация функциональных, спецификация нефункциональных, спецификация системных требований, план внедрения и тд тп.
Эмпирически мы на подсознательном уровне понимаем, какую степень проработки ТЗ в своих проектах применять (ТЗ как… опаприкрывательство, как план для клиента, разработчика, тестировщика, внедренца и тд). Но общих правил тут наверное нет.
Было бы очень интересно увидеть продолжение по проблемам «другого уровня» и Вашими путями решения.
Почему Вы не стали в PHP-приложении ТОЛЬКО ЧИТАТЬ значения из кэша? Ну и добавили бы минимум логики в приложение, мол получили значение из кэша — радуемся, а не получили — не рисуем компонент, вставляем дефолтное значение(если имеет место быть) и тд. А вот отдельный скрипт по крону запускается(или демон на постоянку с засыпанием), идет в чужой сервис и пишет итоги в кэш. PHP-приложение знать не знает, откуда в кэше данные. Поделили ответственность, создали задел на будущее и тд. В такой архитектуре я не вижу причин появления проблем из поста. С моих глаз у Вас борьба с ветряными мельницами: затолкали конкурентную запись с чтением в логику приложения с кучей клиентов/тредов и давай воевать там =)
Конечно он у вас сворует процесс и т.д. А если на Go/C/Crystal и тд демон? Он ни процессов PHP, ни время процессора, ни оперативки, ни сил и времени не будет отнимать.
Человека выше заминусили совсем зазря, ИМХО.
Читать приятно, забавно, но не полезно для разработчика => значит цикл может занять достойное место в литературных пабликах.
Ну а случае реальных нагрузок, масштабируемся железом. Зато легко =) Ну или дербаним от монолита «узкие места» и пишем их на чем-нибудь компилируемом.