Почему нет? Смотря что понимать под потоком. Пришла реализация данных, запустилась какая то функция, по результатам обработки вычислилась какая то переменная, которая используется при следующей инициации. Переменная - состояние актора. Если внутри актора стейт машина - у актора с каждой инициацией обновляется состояние. Поток не вычислительный тред, а сущность, отражающая распространение данных в системе. Акторная модель, описанная тут в контексте ЯП - частный случай потоковой модели организации вычислений.
Интересно, а те, кто программируют на эрланге в курсе, что используют акторную модель?) По моим наблюдениям, точно не все, даже из тех кто этот эрланг и otp преподаёт. Вот Go - в любой вики сразу написано, что это имплементация модели последовательных коммуницирующих процессов, или как там их.
Вы сравниваете акторную модель с ООП - насколько это корректно? Акторная - модель, а ООП - методология. Акторная модель вычислений может быть реализована на любом языке программирования и любой его методологией, и не только программно.
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций. Это способ организации вычислений, или их модель. Ну да, есть языки, предназначенные только для этого, но это не проблема понимания принципов акторной модели, имхо
Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
В конце 90х читал статью про АШП для Боинга или типа того на TMS320
В моей машине есть АШП, гасящая низкочастотные шумы двигателя и шин)
Насчёт задержек - 1мс это 30 см расстояния в воздухе, можно отодвинуть микрофон от динамика. Правда это требует коррекции модели подавления и алгоритма. Ну и да - микрофонов и динамиков должно быть больше, значит процессор дб другой
Я никогда не был сетевиком) W3.11 работала либо с ipx/spx, либр с tcp/ip, если на драйвер карты навешивали и то и другое, при каких то условиях тачка вешалась наглухо. W95 тогда был только на одной машине и тоже вешался при двух стеках. Поэтому перешли только на tcp/ip, а новеловский сервер на 386 с 4 мб оперативки переделали в маршрутизатор под slackware на 2 внутренних локалки и интернет. Ну и плюс ввв, качалка на wget, прокси, самба контроллер. В итого это оказалось перспективней чем возня с нелицерзионным новелом)
Сначала появилась производительность, как количественная метрика, потом динамика производительности.. много я всяких передовых идей в аджайле повидал, но с таким не сталкивался.
Задумайтесь, какой физический смысл имеют абстрактные сторипойнты, делённые на инфляционные рубли при такой кредитной ставке и так ли стоит на подобном шатком фундаменте строить какие то выкладки)
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная
SP для задач проставляет команда. Никакой системы оценивания единой для двух команд быть не может, тем более если стоимость у них настолько различается.
Всё, что даёт SP это велосити, на основании которого старшие "товарищи" могут прикидывать, за сколько спринтов конкретная команда будет разгребать то, что уже наэстимировала в свой беклог.
Вот честно не помню ядер или процессоров. Может это было в предверии P Pro, может для альфы, но этот параметр меня в то время сильно удивил, поэтому и запомнился. Я пытался тогда объединить дисплей класс на W3.11 с сервером Novel Netware под ipx с рабочими машинами и подключить всё к интернету, с Warp это почти удалось, но ipx с tcp/ip под виндус так и не заработал, пришлось выкинуть новел и перевести всё на tcp/ip с маршрутизацией через линукс сервер. И снести Warp)
Ну, код целиком, конечно, не очень правильно оставлять, но у меня был случай, когда от меня с интервалом в два-три года два раза требовали поменять поведение, которым я и не управлял) Первый раз я достаточно быстро нашёл флажок в ui, код, который из нескольких флажков выбирал режим работы и через несколько компонент спускал ко мне. В комменте к и вправду странному коду был указан номер тикета и фамилия коллеги, который это написал. Почитал тикет, посмотрели его с этим коллегой и отписались, что это поведение решение маркетинга. А вот через несколько лет, хотя смутно помнил, что что то такое исследовал уже, этот код искал дольше, нашёл тот коммент - трекер сменили, старый архив закрыли, коллега уволился, перфорс сменили гитом, маркетинг и саппорт весь поменялся, если бы не архив почты, где этот тикет мелькал раз в 3 года, пришлось бы ещё месяц со всеми переписываться. Не, можно конечно было поправить эти флажки чтобы клиент стал счастливым, только тогда прилетела бы сотня запросов от других клиентов почемв стало по другому..
Поэтому я за комменты в странных или критических местах
А если в api к чему нибудь есть несколько методов, которые могут требовать повторов, логику ретрая надо имплементировать в каждом? Или правильней параллельный апи свести к последовательному типа command-parameters и один раз окружить это ретраями, таймаутами и анализом ошибок?
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
Почему нет? Смотря что понимать под потоком. Пришла реализация данных, запустилась какая то функция, по результатам обработки вычислилась какая то переменная, которая используется при следующей инициации. Переменная - состояние актора. Если внутри актора стейт машина - у актора с каждой инициацией обновляется состояние. Поток не вычислительный тред, а сущность, отражающая распространение данных в системе. Акторная модель, описанная тут в контексте ЯП - частный случай потоковой модели организации вычислений.
Интересно, а те, кто программируют на эрланге в курсе, что используют акторную модель?) По моим наблюдениям, точно не все, даже из тех кто этот эрланг и otp преподаёт. Вот Go - в любой вики сразу написано, что это имплементация модели последовательных коммуницирующих процессов, или как там их.
Вы сравниваете акторную модель с ООП - насколько это корректно? Акторная - модель, а ООП - методология. Акторная модель вычислений может быть реализована на любом языке программирования и любой его методологией, и не только программно.
Мне кажется было бы корректней рассматривать акторную модель как разновидность потоковых вычислений, когда не поток инструкций определяет порядок выборки и обработки данных, а потоки данных инициируют выполнение тех или иных инструкций. Это способ организации вычислений, или их модель. Ну да, есть языки, предназначенные только для этого, но это не проблема понимания принципов акторной модели, имхо
Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
Старшие пацаны пошли мелочь трясти из малолеток))
То есть загрузка каждого ядра 80%? Мне просто такая метрика не знакома - загрузка в ядрах
А насколько эти cpu нагружены?)
В конце 90х читал статью про АШП для Боинга или типа того на TMS320
В моей машине есть АШП, гасящая низкочастотные шумы двигателя и шин)
Насчёт задержек - 1мс это 30 см расстояния в воздухе, можно отодвинуть микрофон от динамика. Правда это требует коррекции модели подавления и алгоритма. Ну и да - микрофонов и динамиков должно быть больше, значит процессор дб другой
Я никогда не был сетевиком) W3.11 работала либо с ipx/spx, либр с tcp/ip, если на драйвер карты навешивали и то и другое, при каких то условиях тачка вешалась наглухо. W95 тогда был только на одной машине и тоже вешался при двух стеках. Поэтому перешли только на tcp/ip, а новеловский сервер на 386 с 4 мб оперативки переделали в маршрутизатор под slackware на 2 внутренних локалки и интернет. Ну и плюс ввв, качалка на wget, прокси, самба контроллер. В итого это оказалось перспективней чем возня с нелицерзионным новелом)
Наступает время голубей и ястребов)
Сначала появилась производительность, как количественная метрика, потом динамика производительности.. много я всяких передовых идей в аджайле повидал, но с таким не сталкивался.
Задумайтесь, какой физический смысл имеют абстрактные сторипойнты, делённые на инфляционные рубли при такой кредитной ставке и так ли стоит на подобном шатком фундаменте строить какие то выкладки)
SP для задач проставляет команда. Никакой системы оценивания единой для двух команд быть не может, тем более если стоимость у них настолько различается.
Всё, что даёт SP это велосити, на основании которого старшие "товарищи" могут прикидывать, за сколько спринтов конкретная команда будет разгребать то, что уже наэстимировала в свой беклог.
Вот честно не помню ядер или процессоров. Может это было в предверии P Pro, может для альфы, но этот параметр меня в то время сильно удивил, поэтому и запомнился. Я пытался тогда объединить дисплей класс на W3.11 с сервером Novel Netware под ipx с рабочими машинами и подключить всё к интернету, с Warp это почти удалось, но ipx с tcp/ip под виндус так и не заработал, пришлось выкинуть новел и перевести всё на tcp/ip с маршрутизацией через линукс сервер. И снести Warp)
Как до Мартина программировали и системы строили - загадка)))
Там менюшка с фильтрами была и прочими инструментами, возможно для распараллеливания
Помню в warp 3 был графический редактор типа paint, но помощнее, у него в настройках можно было установить использование до 64 ядер
Зачем ехать в оффис в 8:00, если технологически даже романтизм вполне удовлетворяет виртуально?))))
Ну, код целиком, конечно, не очень правильно оставлять, но у меня был случай, когда от меня с интервалом в два-три года два раза требовали поменять поведение, которым я и не управлял) Первый раз я достаточно быстро нашёл флажок в ui, код, который из нескольких флажков выбирал режим работы и через несколько компонент спускал ко мне. В комменте к и вправду странному коду был указан номер тикета и фамилия коллеги, который это написал. Почитал тикет, посмотрели его с этим коллегой и отписались, что это поведение решение маркетинга. А вот через несколько лет, хотя смутно помнил, что что то такое исследовал уже, этот код искал дольше, нашёл тот коммент - трекер сменили, старый архив закрыли, коллега уволился, перфорс сменили гитом, маркетинг и саппорт весь поменялся, если бы не архив почты, где этот тикет мелькал раз в 3 года, пришлось бы ещё месяц со всеми переписываться. Не, можно конечно было поправить эти флажки чтобы клиент стал счастливым, только тогда прилетела бы сотня запросов от других клиентов почемв стало по другому..
Поэтому я за комменты в странных или критических местах
Это если через 10 лет не поменяют систему контроля версий или репозиторий криво смигрируют) да ещё и трекер не сменят на другой
А если в api к чему нибудь есть несколько методов, которые могут требовать повторов, логику ретрая надо имплементировать в каждом? Или правильней параллельный апи свести к последовательному типа command-parameters и один раз окружить это ретраями, таймаутами и анализом ошибок?
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние