В какой-то момент стало понятно, что нам не хватает одного окна, в котором собраны все ключевые процессы
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
Есть английский язык как стандарт для айти. Что это вообще за вопрос такой был: переведи медицинский термин туда и обратно? Зачем? Как это связано с темой разговора?
Если у вас есть предметная область и вы пишете исходный код для системы, работающей в ней, у вас УЖЕ ЕСТЬ термины, от которых можно отталкиваться. У вас уже есть медицинское обследование. У вас есть производственная травма. Вам рассказать, как перевести на английский термин "после"?
И, пожалуйста, не надо мне тыкать. Может оказаться, что я старше вас лет на 10.
О. Вспомнил, кто вы такой. Отрицатель ООП. Тогда ладно. Мои аргументы бессильны. Сдаюсь.
Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Я вертел на болту ОРП, вертел реакт, жаваскрипт и весь веб в целом. Десктопщик я. А для своего сайта сделал ssr и мне за глаза хватает.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Спасибо за статью! Это действительно хороший и интересный материал. Напомнило серию "техногенка, котаны?". А, ну да...
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Демократы хотят демократии, а не громить почему-то. Ну могут и погромить, если им обещали, но наврали, как в LA
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
А никто не пробовал твиты Трампа прогнать через него? Вдруг Дональд - программист?
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
Я не понимаю, почему я издеваюсь.
Есть английский язык как стандарт для айти. Что это вообще за вопрос такой был: переведи медицинский термин туда и обратно? Зачем? Как это связано с темой разговора?
Если у вас есть предметная область и вы пишете исходный код для системы, работающей в ней, у вас УЖЕ ЕСТЬ термины, от которых можно отталкиваться. У вас уже есть медицинское обследование. У вас есть производственная травма. Вам рассказать, как перевести на английский термин "после"?
И, пожалуйста, не надо мне тыкать. Может оказаться, что я старше вас лет на 10.
О. Вспомнил, кто вы такой. Отрицатель ООП. Тогда ладно. Мои аргументы бессильны. Сдаюсь.
Для этого нужно, чтобы saving был отглагольным существительным. Нужно указать, что именно оно сейвит. Как существительное само по себе - это экономия.
Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Зачем? Медтермины обычно на латыни, пусть в латыни и остаются. Это общепризнанный общемировой формат