а я бы побаловался численным моделированием реальной экономики. несколько типов товаров с разной нормой амортизации и сроками хранения и разным влиянием на физические лица при потреблении причём товары не только физические но и ментальные и смешанные. несколько юридических лиц которые производят и продают товары и закупают на рынке труда, много физических лиц которые продают на рынке труда труд различной квалификации и покупают товары. и посмотреть как это всё будет регулироваться как меняться потребление при изменении структуры товаров. можно навесить чтобы физ и юр лица могли умирать и рождаться. можно распределить их территориально. но точно не летом да и сложно это всё одному не потянуть да и вдесятером тоже. да и думаю что околоправительственные конторы в развитых странах этим давно занимаются в полный рост
на самом деле всё что связано с акустооптикой и электрооптикой имеет практически те же скоростные ограничения что и электроника так как там работает коэффициент преломления а это свойство материи и его изменение не будет сильно быстрее переходного процесса на полупроводниковом переходе. а вот японская схема где интерференция интереснее но чтобы делать реальные устройства всё это должно быть исполнено прямо в активной оптической среде то есть по сути это должен быть один лазер очень сложной структуры. настаивать это будет жутко сложно ну или искать способы чтобы это всё само отстраивалось какой нибудь обратной связью. хуже всего то что с модульностью тоже будет морока - просто передать луч света из одного модуля в другой тоже наверное не получится а надо будет по сути объединить две лазерные системы в одну.
без "костыля" никак. даже если на Вашем роутере белый IP, что по моему редкость, то надо будет всё равно дополнительно его настраивать на "проброс портов" и esp32 надо внутри сети постоянный адрес давать. ещё есть вариант использовать сайт iocontrol.ru. на нём вроде можно завести учётку указав почту и используя простенький API гонять пакеты между устройствами находящимися за NATами.
у меня тоже глюки поэтому и спрашиваю) у Вас WiFiserver или Webserver используется? я пробовал на web но сейчас вернулся на wifi. сейчас чтото похоже глючит изза того что формирую слишком большую строку для отдачи на клиента. а до этого глючило потому что формировал js код не добавляя перенос строки. причём до какогото момента всё работало пока, насколько понимаю, не оказалось что функция закончилась и без всяких разделителей пошла следующая. и как консоль браузера смотрите на смартфоне? я пробовал через хром на ПК с включением опции "отладка по usb" и чтото у меня не срастается.
с js кодом всё понятно а что у Вас на esp32? Интересно, потомучто сам сейчас пилю костыль для теплицы esp32/реле с тэном/ds18b20 с конфигурационным и информационным интерфейсами через wifi на html и чё то он у меня обрастает уже всяким разным фишками типа истории температуры с состоянием реле чтобы отследить эффективность работы устройства и уже тянет установить внешний датчик и провести серию экспериментов чтобы понимать какие уровни холода можно "купировать" данным конкретным ТЭНом в данной конкретной теплице да и много ещё чего)
У самого такие мысли были). но имхо надо ориентироваться на мобильные платформы в первую очередь на андроид. И сразу нужно отталкиваться от мультиплеера чтобы это была PvP. ну и js код в принципе очевидный (и не надо экономить на производительности делая неплавную графику ведь код будет работать на клиенте). Интереснее как Вы будете отдавать этот код как он будет храниться что там с памятью будет на esp32 и сколько кода можно туда упихать как организуете REST архитектуру геймплея и как будет использоваться второе ядро esp32
если поднять опыт предыдущих основных изобретений человечества то можно обнаружить что мы так и не смогли научиться передвигаться ни на 4 ногах ни на 6 ни на 8 но научились это делать при помощи колеса и гораздо быстрее чем любое животное, также мы не научились летать ни как птицы ни как насекомые но научились делать это по своему и гораздо лучше. так почему же интересно эти учёные упорно пытаются разгадать способ мышления животных в надежде перенести его на свои изобретения...
ситуация чем то напоминает ситуацию с риэлтерами и перекупами только возведённую в куб. маркетинг засвечивает инфопространство до такой степени что на фоне этого сверкания невозможно разглядеть ничего кроме того что подсвечивается этим самым маркетингом. и маркетинг за свои услуги получает 90% всего бюджета проекта. просто создал инфозавесу между разрабом и юзером и теперь берёт огромные деньги и с тех и с других просто за то чтобы они могли контактировать...
ну так то всё это очевидные вещи. так сказать "список главных добродетелей" любой преуспевающей команды. а в советское время вообще был целый институт(не ВУЗ а форма деятельности) рацпредложений, были специально обученные люди, были отделы при заводах.
работал я в организации где это всё было возведено в ранг идола только называлось не так. главная сложность в системе внедрения была в том что люди не понимали почему то что они всегда собственно и делали вдруг стало какойто особой ценностью да ещё и теперь это считается не их заслугой а заслугой какогото левого массовика-затейника которого начальство поставило проводить идеи производственной системы тойота в массы.
и кстати где тут возможности не экстенсивного а интенсивного развития. у японцев это имхо слабое место. по моему мнению они так фукусиму взорвали - в инструкциях и существующих технологиях у них решения не было как и времени для того чтобы постепенно эту технологию выработать. а шагнуть быстро и решительно за рамки когда это необходимо у них с этим сложности.
для RISK-V по хорошему надо вообще на ассемблере писать. урезанная система команд как раз и даёт возможность человеку легко их выучить да там в принципе и машкоды в бинарном виде несложно читать всё просто. а соответствие стандарту RISK-V это по сути и есть переносимость за которую так ценят С. зато будешь точно знать что и как происходит в твоей программе. а С это всё равно компилятор хоть и считается что он однозначно проектируется в код и очень оптимизирован но он всегда будет отставать от низкоуровневого кода в производительности и обгонять по объёму
сомневаюсь что только блокировка аденозина функции кофе. утром когда организм выспался и отдохнул концентрация аденозина должна быть минимальной так как он весь заряжен до АТФ и готов к использованию в клетках. и именно утренняя чашка кофе как раз таки и самая сильнодействующая. есть там всё таки какоето ещё действие по моему. и настроение меняется от кофе. сам сейчас на одной утренней чашке хотя в выходные могу и пару выпить. от одной сон не меняется а вот от пары пожалуй да, спать ложусь позже и сплю утром дольше. может это просто от того что в выходной меньше устаёшь.
по моему если и есть игра которая учит думать как программист то это факторио. если человек создал там замкнутый процесс имени Коварекса то его смело можно учить программировать даже если он в программирование ноль.
горячий (холодильник от 500 градусов цельсия а турбина под 1000 иначе не получится избавится от лишнего тепла так как сделать это можно только излучением) с рабочим телом в форме газа (потому что жидкостей при такой температуре не бывает вернее бывает но это металлы а с ними проблемы изза их агрессивности и опасность затвердевания в холодильнике при низких режимах) ядерный реактор. что то типа tory-2c из американского проекта "плутон" замкнутый сам на себя через холодильник.
100 кг это ещё и не константа. посчитаем. берём классические формулы так как до скорости света здесь по любому далеко. мощность это энергия в секунду а тяга это импульс в секунду. энергия m*v*v/2 а импульс m*v. значит разделив мощность на тягу получим примерно половину скорости истечения рабочего тела. (будем считать КПД высоким иначе там будет в полный рост проблема нагрева вплоть до 1000 градусов и будет совсем не до полётов) итого около 100 км/с. теперь вернёмся к тяге то есть к импульс в секунду. чтобы развить 6Н при такой скорости истечения нам понадобится 6 на 10 в минус 5ой степени килограмм. за сутки 6 килограмм. за Ваши 30 дней Ваш эмпирический 100 килограммовый аппарат должен израсходовать 180 килограмм рабочего тела)
и ещё - "небезопасный код" и его ошибки от которых все эти "облегчатели программирования" пытаются уберечь своими подпорками, такие как NPE, вылет за границы массива и прочее подобное, как раз и есть индикаторы пригодности кода. если код написан криво то они проявятся и просигналят о том что алгоритмы работают не так как автор задумал. а вот если они будут демпфированы всеми этими "облегчалками" то некорректная работа кода уйдёт дальше попадёт в прод и может вылезти только через годы эксплуатации таким геморром что мало не покажется никому или вообще превратится в неуловимый баг.
а про собеседования тоже согласен - такое чувство что в нынешнее время ценится не умение программировать а знание как можно большего количества синтаксического сахара.
а я пессимист. если что хорошее случается то неожиданная радость а если плохое то закономерная и ожидаемая реальность). получается что эмоции либо 0 либо +.
другой разговор конечно что сам стресс надо снимать а для этого надо деверсифицировать деятельность и развлечения но с показным оптимизмом это врядли коррелирует. вернее коррелирует но не прямо а обратно. по сути это исследование это типичная ошибка выжившего - причина внешнего оптимизма и благополучия умение снять стресс а не внешний оптимизм и благополучие это причина того что стресс не "липнет" к человеку. короче очередные "британские учёные". имхо конечно...
забыли ещё одно важное свойство - логарифм произведения двух чисел это сумма их логарифмов. ну и про деление соответственно. а вообще очевидные вещи из школьного курса...
а я бы побаловался численным моделированием реальной экономики. несколько типов товаров с разной нормой амортизации и сроками хранения и разным влиянием на физические лица при потреблении причём товары не только физические но и ментальные и смешанные. несколько юридических лиц которые производят и продают товары и закупают на рынке труда, много физических лиц которые продают на рынке труда труд различной квалификации и покупают товары. и посмотреть как это всё будет регулироваться как меняться потребление при изменении структуры товаров. можно навесить чтобы физ и юр лица могли умирать и рождаться. можно распределить их территориально. но точно не летом да и сложно это всё одному не потянуть да и вдесятером тоже. да и думаю что околоправительственные конторы в развитых странах этим давно занимаются в полный рост
на самом деле всё что связано с акустооптикой и электрооптикой имеет практически те же скоростные ограничения что и электроника так как там работает коэффициент преломления а это свойство материи и его изменение не будет сильно быстрее переходного процесса на полупроводниковом переходе. а вот японская схема где интерференция интереснее но чтобы делать реальные устройства всё это должно быть исполнено прямо в активной оптической среде то есть по сути это должен быть один лазер очень сложной структуры. настаивать это будет жутко сложно ну или искать способы чтобы это всё само отстраивалось какой нибудь обратной связью. хуже всего то что с модульностью тоже будет морока - просто передать луч света из одного модуля в другой тоже наверное не получится а надо будет по сути объединить две лазерные системы в одну.
без "костыля" никак. даже если на Вашем роутере белый IP, что по моему редкость, то надо будет всё равно дополнительно его настраивать на "проброс портов" и esp32 надо внутри сети постоянный адрес давать. ещё есть вариант использовать сайт iocontrol.ru. на нём вроде можно завести учётку указав почту и используя простенький API гонять пакеты между устройствами находящимися за NATами.
у меня тоже глюки поэтому и спрашиваю) у Вас WiFiserver или Webserver используется? я пробовал на web но сейчас вернулся на wifi. сейчас чтото похоже глючит изза того что формирую слишком большую строку для отдачи на клиента. а до этого глючило потому что формировал js код не добавляя перенос строки. причём до какогото момента всё работало пока, насколько понимаю, не оказалось что функция закончилась и без всяких разделителей пошла следующая. и как консоль браузера смотрите на смартфоне? я пробовал через хром на ПК с включением опции "отладка по usb" и чтото у меня не срастается.
с js кодом всё понятно а что у Вас на esp32? Интересно, потомучто сам сейчас пилю костыль для теплицы esp32/реле с тэном/ds18b20 с конфигурационным и информационным интерфейсами через wifi на html и чё то он у меня обрастает уже всяким разным фишками типа истории температуры с состоянием реле чтобы отследить эффективность работы устройства и уже тянет установить внешний датчик и провести серию экспериментов чтобы понимать какие уровни холода можно "купировать" данным конкретным ТЭНом в данной конкретной теплице да и много ещё чего)
У самого такие мысли были). но имхо надо ориентироваться на мобильные платформы в первую очередь на андроид. И сразу нужно отталкиваться от мультиплеера чтобы это была PvP. ну и js код в принципе очевидный (и не надо экономить на производительности делая неплавную графику ведь код будет работать на клиенте). Интереснее как Вы будете отдавать этот код как он будет храниться что там с памятью будет на esp32 и сколько кода можно туда упихать как организуете REST архитектуру геймплея и как будет использоваться второе ядро esp32
если поднять опыт предыдущих основных изобретений человечества то можно обнаружить что мы так и не смогли научиться передвигаться ни на 4 ногах ни на 6 ни на 8 но научились это делать при помощи колеса и гораздо быстрее чем любое животное, также мы не научились летать ни как птицы ни как насекомые но научились делать это по своему и гораздо лучше. так почему же интересно эти учёные упорно пытаются разгадать способ мышления животных в надежде перенести его на свои изобретения...
ситуация чем то напоминает ситуацию с риэлтерами и перекупами только возведённую в куб. маркетинг засвечивает инфопространство до такой степени что на фоне этого сверкания невозможно разглядеть ничего кроме того что подсвечивается этим самым маркетингом. и маркетинг за свои услуги получает 90% всего бюджета проекта. просто создал инфозавесу между разрабом и юзером и теперь берёт огромные деньги и с тех и с других просто за то чтобы они могли контактировать...
ну так то всё это очевидные вещи. так сказать "список главных добродетелей" любой преуспевающей команды. а в советское время вообще был целый институт(не ВУЗ а форма деятельности) рацпредложений, были специально обученные люди, были отделы при заводах.
работал я в организации где это всё было возведено в ранг идола только называлось не так. главная сложность в системе внедрения была в том что люди не понимали почему то что они всегда собственно и делали вдруг стало какойто особой ценностью да ещё и теперь это считается не их заслугой а заслугой какогото левого массовика-затейника которого начальство поставило проводить идеи производственной системы тойота в массы.
и кстати где тут возможности не экстенсивного а интенсивного развития. у японцев это имхо слабое место. по моему мнению они так фукусиму взорвали - в инструкциях и существующих технологиях у них решения не было как и времени для того чтобы постепенно эту технологию выработать. а шагнуть быстро и решительно за рамки когда это необходимо у них с этим сложности.
для RISK-V по хорошему надо вообще на ассемблере писать. урезанная система команд как раз и даёт возможность человеку легко их выучить да там в принципе и машкоды в бинарном виде несложно читать всё просто. а соответствие стандарту RISK-V это по сути и есть переносимость за которую так ценят С. зато будешь точно знать что и как происходит в твоей программе. а С это всё равно компилятор хоть и считается что он однозначно проектируется в код и очень оптимизирован но он всегда будет отставать от низкоуровневого кода в производительности и обгонять по объёму
вопрос в том сколько он будет стоить извините за меркантильность)
esp32 может и послабее местами но зато wifi на борту и стоит копейки
сомневаюсь что только блокировка аденозина функции кофе. утром когда организм выспался и отдохнул концентрация аденозина должна быть минимальной так как он весь заряжен до АТФ и готов к использованию в клетках. и именно утренняя чашка кофе как раз таки и самая сильнодействующая. есть там всё таки какоето ещё действие по моему. и настроение меняется от кофе. сам сейчас на одной утренней чашке хотя в выходные могу и пару выпить. от одной сон не меняется а вот от пары пожалуй да, спать ложусь позже и сплю утром дольше. может это просто от того что в выходной меньше устаёшь.
по моему если и есть игра которая учит думать как программист то это факторио. если человек создал там замкнутый процесс имени Коварекса то его смело можно учить программировать даже если он в программирование ноль.
горячий (холодильник от 500 градусов цельсия а турбина под 1000 иначе не получится избавится от лишнего тепла так как сделать это можно только излучением) с рабочим телом в форме газа (потому что жидкостей при такой температуре не бывает вернее бывает но это металлы а с ними проблемы изза их агрессивности и опасность затвердевания в холодильнике при низких режимах) ядерный реактор. что то типа tory-2c из американского проекта "плутон" замкнутый сам на себя через холодильник.
100 кг это ещё и не константа. посчитаем. берём классические формулы так как до скорости света здесь по любому далеко. мощность это энергия в секунду а тяга это импульс в секунду. энергия m*v*v/2 а импульс m*v. значит разделив мощность на тягу получим примерно половину скорости истечения рабочего тела. (будем считать КПД высоким иначе там будет в полный рост проблема нагрева вплоть до 1000 градусов и будет совсем не до полётов) итого около 100 км/с. теперь вернёмся к тяге то есть к импульс в секунду. чтобы развить 6Н при такой скорости истечения нам понадобится 6 на 10 в минус 5ой степени килограмм. за сутки 6 килограмм. за Ваши 30 дней Ваш эмпирический 100 килограммовый аппарат должен израсходовать 180 килограмм рабочего тела)
и ещё - "небезопасный код" и его ошибки от которых все эти "облегчатели программирования" пытаются уберечь своими подпорками, такие как NPE, вылет за границы массива и прочее подобное, как раз и есть индикаторы пригодности кода. если код написан криво то они проявятся и просигналят о том что алгоритмы работают не так как автор задумал. а вот если они будут демпфированы всеми этими "облегчалками" то некорректная работа кода уйдёт дальше попадёт в прод и может вылезти только через годы эксплуатации таким геморром что мало не покажется никому или вообще превратится в неуловимый баг.
а про собеседования тоже согласен - такое чувство что в нынешнее время ценится не умение программировать а знание как можно большего количества синтаксического сахара.
а я пессимист. если что хорошее случается то неожиданная радость а если плохое то закономерная и ожидаемая реальность). получается что эмоции либо 0 либо +.
другой разговор конечно что сам стресс надо снимать а для этого надо деверсифицировать деятельность и развлечения но с показным оптимизмом это врядли коррелирует. вернее коррелирует но не прямо а обратно. по сути это исследование это типичная ошибка выжившего - причина внешнего оптимизма и благополучия умение снять стресс а не внешний оптимизм и благополучие это причина того что стресс не "липнет" к человеку. короче очередные "британские учёные". имхо конечно...
забыли ещё одно важное свойство - логарифм произведения двух чисел это сумма их логарифмов. ну и про деление соответственно. а вообще очевидные вещи из школьного курса...