Я был на испытательном сроке и каждую неделю писал отчёты про то что сделал - i realised functionality to test ..., i realized functionality to test ... Через месяц мой шеф написал мне что то вроде it's look like you are quite marginal in your work schedule, на что я ему ответил, что я конечно новичёк в том что делаю, но тем не менее я стараюсь и у меня уже работают тесты по первому, второму и даже третьему пункту, а если ему не нравится то пусть меня закидают палками и выгонят из этой никому неизвестной в РФ фирмы с нероссийской зарплатой. Получив письмо шеф позвонил и сказал - Саша, в английском realize означает осознать или понять, а то что делали Вы, это называется implement. И у меня с тех пор вопрос к русскому - что у нас означает реализация и почему воплощение в разговорном отсутствует) А тогда исп срок мне прервали и через пару месяцев повысили оклад на 150 баксов))
В основе лежит нелинейное взаимодействие уз поля с неоднородностями. Есть способ формирования низкочастотного направленного сигнала для эхолотов, когда на высокой частоте около излучателя формируется поле как в директорной антенне но уже на низкой частоте. Ещё уже давно известна система трансляции объявлений в аэропортах - там уз пушки узким лучом подсвечивают шары из пенопласта или типа того, которые становятся нч источниками.
Я бы Вам посоветовал заменить шим преобразователь на что то более соответствующее модулятору - к примеру на ЦАП, если он может работать в режиме умножения, это увеличит глубину модуляции и сделает несущую меньше, а составляющие инф сигнала больше.
Печь топят небольшими закладками чтобы её просушить, и в ней улучшилась тяга. Если сразу в продакшен, она развалится)
Так что красиво, конечно, сформулировано, но базовый постулат ошибочный. Это как в 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 и чистой аохитектурой)
Космос и атомка это самая что ни на есть военка, была по крайней мере.
I'm looking for a man... who calls himself Bucho! (C))
Я был на испытательном сроке и каждую неделю писал отчёты про то что сделал - i realised functionality to test ..., i realized functionality to test ... Через месяц мой шеф написал мне что то вроде it's look like you are quite marginal in your work schedule, на что я ему ответил, что я конечно новичёк в том что делаю, но тем не менее я стараюсь и у меня уже работают тесты по первому, второму и даже третьему пункту, а если ему не нравится то пусть меня закидают палками и выгонят из этой никому неизвестной в РФ фирмы с нероссийской зарплатой. Получив письмо шеф позвонил и сказал - Саша, в английском realize означает осознать или понять, а то что делали Вы, это называется implement. И у меня с тех пор вопрос к русскому - что у нас означает реализация и почему воплощение в разговорном отсутствует) А тогда исп срок мне прервали и через пару месяцев повысили оклад на 150 баксов))
Для воздуха на 40 кГц длина волны 7 мм где то. ФАР делается на полуволновых элементах, вот и считайте можно ли её сделать на таких излучателях
В основе лежит нелинейное взаимодействие уз поля с неоднородностями. Есть способ формирования низкочастотного направленного сигнала для эхолотов, когда на высокой частоте около излучателя формируется поле как в директорной антенне но уже на низкой частоте. Ещё уже давно известна система трансляции объявлений в аэропортах - там уз пушки узким лучом подсвечивают шары из пенопласта или типа того, которые становятся нч источниками.
Я бы Вам посоветовал заменить шим преобразователь на что то более соответствующее модулятору - к примеру на ЦАП, если он может работать в режиме умножения, это увеличит глубину модуляции и сделает несущую меньше, а составляющие инф сигнала больше.
То есть автор хочет сказать, что 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 и чистой аохитектурой)