Как обычно, все проблемы из детства: "папка" - это прообраз папы, отца. Нет папок - не хватало отцовского внимания. Отсюда комплексы и неуверенность...
Моя статья про продукты, где иишка влияет не только на решение задачи, но и на сам способ, которым пользователь до этой задачи добирается.
Судя по статье - еще и на саму задачу, которую пользователь в итоге решил ))
Тогда видимо стоит отделять то что привлекло пользователя в воронку (вау, прикольно!) от того, какую ценность он в итоге получил (профит). Я так понял, у вас это частенько разные вещи.
А можно шаг назад и для тормозов пояснить, что такое "AI-First"?
Складывается впечатление, что все что вы пишите касается не просто AI, а какого-то подкласса продуктов, не закрывающих потребность, а дающих юзерам некие прикольные инструменты, без четкой инструкции по применению. Как базовый AI-chat
Есть вполне рабочие продукты, которые с помощью ИИ закрывают конкретные потребности, там такой маркетинговой экзотики нет - Все вполне линейно и предсказуемо, как и в любых других продуктах.
Нехитрые расчеты с помощью нейронки говорят что можно построить космический лифт от Луны до L1 уже на существующих материалах типа кевлара и зайлона. Может и не нужна будет катапульта. Да и доставка грузов на Луну упростится.
Оказывается идеи такого лифта уже обсуждались, и прототип можно испытать одним запуском Falcon Heavy.
С одной стороны, у тихоходок есть механизмы адаптации к условиям, не встречающимся на Земле. С другой - они очевидно имеют очень много общего с земными организмами - ДНК, клетки, метаболизм, подходящий для земной биосферы. Они не чужие нам.
Гипотеза 1:
Наши общие с тихоходками предки с другой планеты. Просто тихоходки прилетели позже, возможно где-то пожив "по дороге" в очень неблагоприятных условиях.
Гипотеза 2:
Все же с Земли. Что если их предков в результате какого-то древнего катаклизма выкинуло с Земли и они попали в другое место Солнечной системы, где такие "скиллы" нужны, а потом следующим катакликзом через миллионы лет эволюции закинуло обратно?
Такое давление может быть в очень глубоких океанах, например на Титане, Ганимеде или Европе. Высокая радиция есть у Юпитера. А если они там жили - то наверное и чем-то там питались...
Согласен, неожиданностей из-за пыли и других причин будет огромное количество. Наверное, не стоит класть яйца в одну корзину и лучше сразу везти туда и панели и РИТЭГи.
С реактором непонятно, чтобы там его запустить, наладить и протестить как будто нужна уже мало-мальски рабочая база, а не просто экспедиция.
> При существенных концентрациях она может образовать мостики между проводами или проводами и поверхностью Луны (в зависимости от выбранного типа линии). Можно для борьбы с этим заизолировать провода. Но это не только увеличит массу, но и создаст угрозу деградации изоляции из-за пыли, осевшей на изоляцию при строительстве. Пыль абразивна, и на Луне есть микросейсмика. Т.е. нечто с острыми краями будет периодически теребить изоляцию.
Ну, подошвы скафандров за несколько дней активной ходьбы не протерлись, поэтому думаю не очень толстый, но высоковольтный изолированный кабель, кинутый просто на поверхность прослужит довольно долго, пока инженеры не получат нужный опыт и не построят долговременную инфраструктуру.
Строительство ЛЭП такой длины в условиях лунной пыли -- это инженерный подвиг
А как пыль будет мешать строительству ЛЭП?
> А вот как победить лунную пыль -- пока никто не знает.
Да может и хрен с ней. Посчитать экономику удаления пыли, может окажется проще постоянно добавлять чистые панели и смириться с некоторым падением эффективности запыленных, пока не будет изобретен надежный способ обеспыливания.
Напротив, построить такую АЭС довольно просто. Вообще, необслуживаемые реакторы в военной отрасли уже работают.
Да, но из статьи мы узнали, что земные реакторы для Луны не подходят. И достоверно протестировать на земле прототип лунного реактора тоже невозможно - даже из-за разной силы тяжести. А значит это рискованная незрелая технология, которую предлагается использовать как базовый(!) энергетический компонент колонии. Плохая идея.
> без близких аналогов в человеческой истории.
Так-то в принципе освоение Луны - в любом случае инженерный подвиг каких не бывало. Поэтому важно сделать так, чтобы максимально возможное количество используемых технологий были уже зрелыми. Незрелых, снижающих надежность всей лунной колонии, как стабильной системы, там и так с избытком будет.
То что АЭС в космосе (и на Луне) нужны и будут построены - тут спору нет, конечно да. Как параллельная научная программа - может быть. Но как базовая технология для освоения Луны в ближайшие 5-10 лет - точно нет.
Эти да. Но я не про этих. Я про тех, кто реально хотят что-то на Луне построить - а они врят ли заинтересуются реактором на 5 кВт и его "программой развития" на пару десятков лет.
Выглядит так, что проще построить сразу две солнечные электростанции, расположив их в отдалении от базы и так чтобы хоть одна их них всегда была на солнце. Панели можно довозить партиями любого размера, постоянно масштабируя мощность, причем на десятки и сотни киловатт за один рейс. И их уже можно начать отправлять хоть в ближайшие год-два, так чтобы к моменту строительства базы накопить уже мегаватты.
Уж пыль-то проще придумать как победить, чем построить необслуживаемую АЭС на сотни киловатт на Луне.
Да и для серьезного освоения путь маленьких шажков по 5-10-100 киловатт за годы выглядит нелепо. Хотите нормально осваивать - нужны мега- и гига- ватты.
Что ж, здорово. Рад что в Delphi это есть. До сих пор с большим уважением отношусь к этому языку. Скучаю по временам, когда проект на десятки тысяч строк компилироваться за секунды, даже на обычном железе.
Вообще-то ваша задача без классов решается табличкой в excel :)
А ведь все CnB-шники кого я знавал, именно в экселе и работают. Потому как даже в больших ИТ-корпорациях не могут родить действительно рабочую систему подсчета выплат, которая учитывает всё, даже кейсы типа "я формально был в отпуске но вообще-то работал, плотите бонус".
Из собственного опыта, с точки зрения хотелок бизнеса, сложнее и изменчивей систем оплаты труда только системы лояльности. Однажды проектировал систему расчета премий, где одна из формул включала арккосинус. Арккосинус, Карл!
Кроме того, такие системы часто имеют кучу зависимостей типа финансовых показателей отделов, компании, бюджетных правил, ограничений и предохранителей. Какую бы архитектуру вы не заложили, она все равно рано или поздно падёт под хотелками бизнеса.
Посему, в такой задаче лучше закладывать максимально тупую архитектуру, где к сотруднику можно привязать одну из функций расчёта (для ООП-фагов - можно и класс), в которую необходимо также передать расширяемый интерфейс к любым данным компании. Функция расчета выдает список начислений с названиями, суммами, НДФЛами-социалками, возможно какими-то связями с другими бизнес-сущностями. Функции будут лежать в каком-то репозитории функций. Новая хотелка бизнеса добавляет новую функцию, старая версия тоже должна сохраняться. Также будет какой-то модуль с общими функциями, например для расчета НДФЛ. Привязка функций к сотрудникам должна учитывать временные интервалы (в этом месяце так, в следующих 6 - иначе). Привязывать следует именно к сотрудникам, а не к должностям или ролям, потому как на начисления однажды гарантированно повлияют отпуска, больничные, грейды, личные выработки, персональный бонус за заслуги и прочее индивидуальное.
Как обычно, все проблемы из детства: "папка" - это прообраз папы, отца. Нет папок - не хватало отцовского внимания. Отсюда комплексы и неуверенность...
Судя по статье - еще и на саму задачу, которую пользователь в итоге решил ))
Тогда видимо стоит отделять то что привлекло пользователя в воронку (вау, прикольно!) от того, какую ценность он в итоге получил (профит). Я так понял, у вас это частенько разные вещи.
А можно шаг назад и для тормозов пояснить, что такое "AI-First"?
Складывается впечатление, что все что вы пишите касается не просто AI, а какого-то подкласса продуктов, не закрывающих потребность, а дающих юзерам некие прикольные инструменты, без четкой инструкции по применению. Как базовый AI-chat
Есть вполне рабочие продукты, которые с помощью ИИ закрывают конкретные потребности, там такой маркетинговой экзотики нет - Все вполне линейно и предсказуемо, как и в любых других продуктах.
Если все отупеют, то некому будет создавать и поддерживать "отупляющие" технологии, и всё вернется в норму.
Разве что ИИ станут полнностью автономны и смогу и дальше отуплять человечество уже без помощи людей.
Нехитрые расчеты с помощью нейронки говорят что можно построить космический лифт от Луны до L1 уже на существующих материалах типа кевлара и зайлона. Может и не нужна будет катапульта. Да и доставка грузов на Луну упростится.
Оказывается идеи такого лифта уже обсуждались, и прототип можно испытать одним запуском Falcon Heavy.
https://astrostrom.ch/docs/JBIS-6-Lunar-Space-Elevator.pdf
https://www.hou.usra.edu/meetings/newviews2018/pdf/6016.pdf
Посадки будут?
С одной стороны, у тихоходок есть механизмы адаптации к условиям, не встречающимся на Земле. С другой - они очевидно имеют очень много общего с земными организмами - ДНК, клетки, метаболизм, подходящий для земной биосферы. Они не чужие нам.
Гипотеза 1:
Наши общие с тихоходками предки с другой планеты. Просто тихоходки прилетели позже, возможно где-то пожив "по дороге" в очень неблагоприятных условиях.
Гипотеза 2:
Все же с Земли. Что если их предков в результате какого-то древнего катаклизма выкинуло с Земли и они попали в другое место Солнечной системы, где такие "скиллы" нужны, а потом следующим катакликзом через миллионы лет эволюции закинуло обратно?
Такое давление может быть в очень глубоких океанах, например на Титане, Ганимеде или Европе. Высокая радиция есть у Юпитера. А если они там жили - то наверное и чем-то там питались...
Я был истовым крестоносцем ООП еще лет 20 назад, брат ))
С тех пор много воды утекло.
Согласен, неожиданностей из-за пыли и других причин будет огромное количество. Наверное, не стоит класть яйца в одну корзину и лучше сразу везти туда и панели и РИТЭГи.
С реактором непонятно, чтобы там его запустить, наладить и протестить как будто нужна уже мало-мальски рабочая база, а не просто экспедиция.
> При существенных концентрациях она может образовать мостики между проводами или проводами и поверхностью Луны (в зависимости от выбранного типа линии). Можно для борьбы с этим заизолировать провода. Но это не только увеличит массу, но и создаст угрозу деградации изоляции из-за пыли, осевшей на изоляцию при строительстве. Пыль абразивна, и на Луне есть микросейсмика. Т.е. нечто с острыми краями будет периодически теребить изоляцию.
Ну, подошвы скафандров за несколько дней активной ходьбы не протерлись, поэтому думаю не очень толстый, но высоковольтный изолированный кабель, кинутый просто на поверхность прослужит довольно долго, пока инженеры не получат нужный опыт и не построят долговременную инфраструктуру.
...а вертолет еще Леонардо да Винчи изобрел, Сикорский просто взял его чертежи.
А как пыль будет мешать строительству ЛЭП?
> А вот как победить лунную пыль -- пока никто не знает.
Да может и хрен с ней. Посчитать экономику удаления пыли, может окажется проще постоянно добавлять чистые панели и смириться с некоторым падением эффективности запыленных, пока не будет изобретен надежный способ обеспыливания.
Да, но из статьи мы узнали, что земные реакторы для Луны не подходят. И достоверно протестировать на земле прототип лунного реактора тоже невозможно - даже из-за разной силы тяжести. А значит это рискованная незрелая технология, которую предлагается использовать как базовый(!) энергетический компонент колонии. Плохая идея.
> без близких аналогов в человеческой истории.
Так-то в принципе освоение Луны - в любом случае инженерный подвиг каких не бывало. Поэтому важно сделать так, чтобы максимально возможное количество используемых технологий были уже зрелыми. Незрелых, снижающих надежность всей лунной колонии, как стабильной системы, там и так с избытком будет.
То что АЭС в космосе (и на Луне) нужны и будут построены - тут спору нет, конечно да. Как параллельная научная программа - может быть. Но как базовая технология для освоения Луны в ближайшие 5-10 лет - точно нет.
Эти да. Но я не про этих. Я про тех, кто реально хотят что-то на Луне построить - а они врят ли заинтересуются реактором на 5 кВт и его "программой развития" на пару десятков лет.
Теорему Котельникова добавьте
В региональные достижения вполне можно записать
Выглядит так, что проще построить сразу две солнечные электростанции, расположив их в отдалении от базы и так чтобы хоть одна их них всегда была на солнце.
Панели можно довозить партиями любого размера, постоянно масштабируя мощность, причем на десятки и сотни киловатт за один рейс. И их уже можно начать отправлять хоть в ближайшие год-два, так чтобы к моменту строительства базы накопить уже мегаватты.
Уж пыль-то проще придумать как победить, чем построить необслуживаемую АЭС на сотни киловатт на Луне.
Да и для серьезного освоения путь маленьких шажков по 5-10-100 киловатт за годы выглядит нелепо. Хотите нормально осваивать - нужны мега- и гига- ватты.
Что ж, здорово. Рад что в Delphi это есть. До сих пор с большим уважением отношусь к этому языку. Скучаю по временам, когда проект на десятки тысяч строк компилироваться за секунды, даже на обычном железе.
Да, очень похожие механизмы я использовал в C++/Qt лет 15+ назад. Для стилизации под брендбуки - хорошая штука
Но все же под веб UI в мире ИТ на пару порядков больше инфраструктуры, знаний, разнообразных инструментов, на любой вкус, как ни крути.
А ведь все CnB-шники кого я знавал, именно в экселе и работают. Потому как даже в больших ИТ-корпорациях не могут родить действительно рабочую систему подсчета выплат, которая учитывает всё, даже кейсы типа "я формально был в отпуске но вообще-то работал, плотите бонус".
Из собственного опыта, с точки зрения хотелок бизнеса, сложнее и изменчивей систем оплаты труда только системы лояльности. Однажды проектировал систему расчета премий, где одна из формул включала арккосинус. Арккосинус, Карл!
Кроме того, такие системы часто имеют кучу зависимостей типа финансовых показателей отделов, компании, бюджетных правил, ограничений и предохранителей. Какую бы архитектуру вы не заложили, она все равно рано или поздно падёт под хотелками бизнеса.
Посему, в такой задаче лучше закладывать максимально тупую архитектуру, где к сотруднику можно привязать одну из функций расчёта (для ООП-фагов - можно и класс), в которую необходимо также передать расширяемый интерфейс к любым данным компании.
Функция расчета выдает список начислений с названиями, суммами, НДФЛами-социалками, возможно какими-то связями с другими бизнес-сущностями.
Функции будут лежать в каком-то репозитории функций. Новая хотелка бизнеса добавляет новую функцию, старая версия тоже должна сохраняться.
Также будет какой-то модуль с общими функциями, например для расчета НДФЛ.
Привязка функций к сотрудникам должна учитывать временные интервалы (в этом месяце так, в следующих 6 - иначе).
Привязывать следует именно к сотрудникам, а не к должностям или ролям, потому как на начисления однажды гарантированно повлияют отпуска, больничные, грейды, личные выработки, персональный бонус за заслуги и прочее индивидуальное.