В основе лежит нелинейное взаимодействие уз поля с неоднородностями. Есть способ формирования низкочастотного направленного сигнала для эхолотов, когда на высокой частоте около излучателя формируется поле как в директорной антенне но уже на низкой частоте. Ещё уже давно известна система трансляции объявлений в аэропортах - там уз пушки узким лучом подсвечивают шары из пенопласта или типа того, которые становятся нч источниками.
Я бы Вам посоветовал заменить шим преобразователь на что то более соответствующее модулятору - к примеру на ЦАП, если он может работать в режиме умножения, это увеличит глубину модуляции и сделает несущую меньше, а составляющие инф сигнала больше.
Печь топят небольшими закладками чтобы её просушить, и в ней улучшилась тяга. Если сразу в продакшен, она развалится)
Так что красиво, конечно, сформулировано, но базовый постулат ошибочный. Это как в top down design-е заложить элемент, поведение которого в силу производительности или функционала не обеспечит требований к его работе - придётся возвращаться наверх и повторять проектирование.
С тестами согласен - они и документация всегда шли в конце, главное - демо)
У меня был коллега, который, прожив 10 лет, так и не разговаривал по английски) Он был ээ.. потомственный учёный в возрасте за 50, менеджмент у него был русскоязычный, и Америку он не очень любил)) А уж как разговаривают и пишут не русскоязычные вроде как уже американцы, которых в тамошнем IT почти все, я вообще молчу.
Мне кажется ответственность за корпоративную культуру несёт менеджмент, нет? Нет идеальных людей, и среда развивает в них те навыки, которые необходимы для выживания)
У нас было примерно два сервиса, один из которых управлял записью по nfs от одной железки, потом нотифицировал второй, который читал заголовок файла и логгировал его в базу. Пока не ввели пуллинг на консистентность заголовка на неск. десятков секунд - постоянно были ошибки валидации. И ничего кроме пуллинга было сделать нельзя
На древних tms320c40 длина конвеера команд была 4, и любой if при обработке массива его сшибал. Тем самым скорость вычислений могла быть легко уменьшена в 4 раза) в следующих процессорах TI создали аж оптимизирующий ассемблер для перетасовки команд для VLIW, и количество упоминаний про использование if уменьшилось.
Для современных процессоров общего назначения с их предвыборками инструкций и данных, эта проблема не очень актуальна, имхо. Если какое то dsp на каких то простых архитектурах, то жизнь заставит поразбираться)
Всё так, но я же раньше искрене считал, что кнопки -лучше, а сенсор на лодке вреден. Ну и потом - на румпеле или тряске оказалось легче тыкать большую кнопку на экране, чем одну из кнопок на панели. На авто другие особенности - я к каравто долго привыкал, допустим, теперь норм. На ауди джойстики и менюшки за десяток случайных поездок так и не освоил. И кнопками и крутилками включать режимы мне пока удобнее. Правда и жена легко громкость убавляет - точно косяк производителя))
Вот казалось бы увесистый аргумент, но он для телефона, потому что эхолот при таком волнении уже не очень нужен. Про такой новый ux я и говорю. Я сам всегда так считал, если что
У меня с приятелем гарминовские эхолоты с навигацией, картой и тепе без сенсорных экранов Раньше я был сторонником кнопок, да и сейчас некоторые кнопки в авто меня радуют, а менюшки в машине зятя иногда раздражают. Тем не менее, сейчас я смотрю на эхолоты с сенсорными функциями, потому что оказалось, что самая важная функциональность от сенсоров существенно выигрывает.
По мне, так то что сейчас происходит - это сближение пользовательского опыта и новых технологий - меняются как производители, так и потребители, ну а проблемы неизбежны
Я понимаю, что Вам хочется, чтобы проект был более удобным для вхождения потенциального пользователя, но уж если он его заинтересовал, то уверен, что тот приложит некоторые усилия чтобы его попробовать даже просто в исходниках. Ну, или я сильно отстал от тенденций и переоцениваю потенциальных пользователей и контрибьютеров)
Вот поверите, про великого Боба я узнал три года назад, когда у дочери книжку увидел)) а тогда читал Сухомлина и OSE RM в тексте с псевдографикой. Ну и статьи всякие как строятся гетерогенные многопроцессорные системы
25 лет назад не было инфоцыган) А вот исследования различных моделей организации вычислений, в том числе для построения моделей в различных предметных областях были. Если правильно помню, то самый абстрактная модель организации вычислений называлась token based actor model, или как то так. В зависимости от содержания актора и того, что вкладывалось в ярлык, получались более специализированные модели - синхронные и асинхронные, иерархические, гетерогенные, метрического времени и тепе. В частности, INRIA и Беркли проводили конференции и разные специализированные языки пытались изобретать. Касалось правда это не эээ... "десктопного" программирования, а проектирования цифровых систем контроля и управления. В этом контексте ООП лишь методология. Она не отвечает на вопрос как организовать вычисления в программируемой цифровой системе, даже с SOLID и чистой аохитектурой)
Почему нет? Смотря что понимать под потоком. Пришла реализация данных, запустилась какая то функция, по результатам обработки вычислилась какая то переменная, которая используется при следующей инициации. Переменная - состояние актора. Если внутри актора стейт машина - у актора с каждой инициацией обновляется состояние. Поток не вычислительный тред, а сущность, отражающая распространение данных в системе. Акторная модель, описанная тут в контексте ЯП - частный случай потоковой модели организации вычислений.
Интересно, а те, кто программируют на эрланге в курсе, что используют акторную модель?) По моим наблюдениям, точно не все, даже из тех кто этот эрланг и otp преподаёт. Вот Go - в любой вики сразу написано, что это имплементация модели последовательных коммуницирующих процессов, или как там их.
Вы сравниваете акторную модель с ООП - насколько это корректно? Акторная - модель, а ООП - методология. Акторная модель вычислений может быть реализована на любом языке программирования и любой его методологией, и не только программно.
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций. Это способ организации вычислений, или их модель. Ну да, есть языки, предназначенные только для этого, но это не проблема понимания принципов акторной модели, имхо
Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
В основе лежит нелинейное взаимодействие уз поля с неоднородностями. Есть способ формирования низкочастотного направленного сигнала для эхолотов, когда на высокой частоте около излучателя формируется поле как в директорной антенне но уже на низкой частоте. Ещё уже давно известна система трансляции объявлений в аэропортах - там уз пушки узким лучом подсвечивают шары из пенопласта или типа того, которые становятся нч источниками.
Я бы Вам посоветовал заменить шим преобразователь на что то более соответствующее модулятору - к примеру на ЦАП, если он может работать в режиме умножения, это увеличит глубину модуляции и сделает несущую меньше, а составляющие инф сигнала больше.
То есть автор хочет сказать, что API на Rust нельзя сделать неправильно? А на С++ - нельзя сделать корректным?)
Мне кажется пример с API не очень удачен. Проблема, имхо, не в конкретном языке, а в общем подходе к API как только к интерфейсу без поведения.
Печь топят небольшими закладками чтобы её просушить, и в ней улучшилась тяга. Если сразу в продакшен, она развалится)
Так что красиво, конечно, сформулировано, но базовый постулат ошибочный. Это как в top down design-е заложить элемент, поведение которого в силу производительности или функционала не обеспечит требований к его работе - придётся возвращаться наверх и повторять проектирование.
С тестами согласен - они и документация всегда шли в конце, главное - демо)
У меня был коллега, который, прожив 10 лет, так и не разговаривал по английски) Он был ээ.. потомственный учёный в возрасте за 50, менеджмент у него был русскоязычный, и Америку он не очень любил)) А уж как разговаривают и пишут не русскоязычные вроде как уже американцы, которых в тамошнем IT почти все, я вообще молчу.
Мне кажется ответственность за корпоративную культуру несёт менеджмент, нет? Нет идеальных людей, и среда развивает в них те навыки, которые необходимы для выживания)
А почему 1 это 000000000s а не 0s или не 00000000000000000s? Чтобы за.. устать, но не слишком?)
Не мебелью. 1-м ресурсом. Или 0.5, а то и 0.125. Не встречал, правда, 0.666 - наверно пока ещё есть куда падать)
А если аккаунту лет 8, но он корпоративный? Его, мне кажется, даже не видно
У нас было примерно два сервиса, один из которых управлял записью по nfs от одной железки, потом нотифицировал второй, который читал заголовок файла и логгировал его в базу. Пока не ввели пуллинг на консистентность заголовка на неск. десятков секунд - постоянно были ошибки валидации. И ничего кроме пуллинга было сделать нельзя
На древних tms320c40 длина конвеера команд была 4, и любой if при обработке массива его сшибал. Тем самым скорость вычислений могла быть легко уменьшена в 4 раза) в следующих процессорах TI создали аж оптимизирующий ассемблер для перетасовки команд для VLIW, и количество упоминаний про использование if уменьшилось.
Для современных процессоров общего назначения с их предвыборками инструкций и данных, эта проблема не очень актуальна, имхо. Если какое то dsp на каких то простых архитектурах, то жизнь заставит поразбираться)
Всё так, но я же раньше искрене считал, что кнопки -лучше, а сенсор на лодке вреден. Ну и потом - на румпеле или тряске оказалось легче тыкать большую кнопку на экране, чем одну из кнопок на панели. На авто другие особенности - я к каравто долго привыкал, допустим, теперь норм. На ауди джойстики и менюшки за десяток случайных поездок так и не освоил. И кнопками и крутилками включать режимы мне пока удобнее. Правда и жена легко громкость убавляет - точно косяк производителя))
Вот казалось бы увесистый аргумент, но он для телефона, потому что эхолот при таком волнении уже не очень нужен. Про такой новый ux я и говорю. Я сам всегда так считал, если что
У меня с приятелем гарминовские эхолоты с навигацией, картой и тепе без сенсорных экранов Раньше я был сторонником кнопок, да и сейчас некоторые кнопки в авто меня радуют, а менюшки в машине зятя иногда раздражают. Тем не менее, сейчас я смотрю на эхолоты с сенсорными функциями, потому что оказалось, что самая важная функциональность от сенсоров существенно выигрывает.
По мне, так то что сейчас происходит - это сближение пользовательского опыта и новых технологий - меняются как производители, так и потребители, ну а проблемы неизбежны
Я понимаю, что Вам хочется, чтобы проект был более удобным для вхождения потенциального пользователя, но уж если он его заинтересовал, то уверен, что тот приложит некоторые усилия чтобы его попробовать даже просто в исходниках. Ну, или я сильно отстал от тенденций и переоцениваю потенциальных пользователей и контрибьютеров)
Вот поверите, про великого Боба я узнал три года назад, когда у дочери книжку увидел)) а тогда читал Сухомлина и OSE RM в тексте с псевдографикой. Ну и статьи всякие как строятся гетерогенные многопроцессорные системы
25 лет назад не было инфоцыган) А вот исследования различных моделей организации вычислений, в том числе для построения моделей в различных предметных областях были. Если правильно помню, то самый абстрактная модель организации вычислений называлась token based actor model, или как то так. В зависимости от содержания актора и того, что вкладывалось в ярлык, получались более специализированные модели - синхронные и асинхронные, иерархические, гетерогенные, метрического времени и тепе. В частности, INRIA и Беркли проводили конференции и разные специализированные языки пытались изобретать. Касалось правда это не эээ... "десктопного" программирования, а проектирования цифровых систем контроля и управления. В этом контексте ООП лишь методология. Она не отвечает на вопрос как организовать вычисления в программируемой цифровой системе, даже с SOLID и чистой аохитектурой)
Почему нет? Смотря что понимать под потоком. Пришла реализация данных, запустилась какая то функция, по результатам обработки вычислилась какая то переменная, которая используется при следующей инициации. Переменная - состояние актора. Если внутри актора стейт машина - у актора с каждой инициацией обновляется состояние. Поток не вычислительный тред, а сущность, отражающая распространение данных в системе. Акторная модель, описанная тут в контексте ЯП - частный случай потоковой модели организации вычислений.
Интересно, а те, кто программируют на эрланге в курсе, что используют акторную модель?) По моим наблюдениям, точно не все, даже из тех кто этот эрланг и otp преподаёт. Вот Go - в любой вики сразу написано, что это имплементация модели последовательных коммуницирующих процессов, или как там их.
Вы сравниваете акторную модель с ООП - насколько это корректно? Акторная - модель, а ООП - методология. Акторная модель вычислений может быть реализована на любом языке программирования и любой его методологией, и не только программно.
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций. Это способ организации вычислений, или их модель. Ну да, есть языки, предназначенные только для этого, но это не проблема понимания принципов акторной модели, имхо
Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
Старшие пацаны пошли мелочь трясти из малолеток))