Хороший пример и постановка проблемы. Я не переводчик, но пока учился в школе, довелось проходить практику в бюро перевода, работая со статьей по нейрохирургии и обсуждая ее с родственником врачом. Некоторые переведённые термины, одобренные переводчиком бюро, вызывали острую реакцию родственника) Потом столкнулся с трудностями перевода руководства по ОС TSX с термином task swapping - тогда не существовало понятия виртуальной памяти, и подобрать что то эквивалентное свопу было крайне затруднительно..Ну и последний сильно проблемный устоявшийся пример - это перевод pointer dereference))
Насколько я слышал, проблема называется проблемой переадресации перевода. Связана с тем, что в рамках двух языков смысл слов и сочетаний может быть разный. И несмотря на то, что architecture deсision по правилам дословного тех перевода следует переводить как решение архитектуры)), такой перевод нуждается в переадресации, которую Вы и проделали. Ну а некоторые вещи вообще невозможно перевести, если в целевом языке нет схожих понятий. Тогда только кофе, файл..))
Раньше были радиолюбители, первым творением которых был, как правило, радиоприёмник в мыльнице. Наверное что то такое подразумевается и в этой статье под "новичком". Иначе о чём вообще идёт речь, если этот "программист" в институтике минимум 4 года что то должен был изучать.
Жизнь и задачи требуют, имхо. Я вот начинал с транзисторов, полевиков, теристоров, ферритовых формирователей импульса на дросселе насыщения, усилителей.. А потом пришлось делать многоканальный тракт передатчика для фар, транзисторы в выходном каскаде остались конечно, а вот формирователь был уже на однобитном ОЗУ с загрузкой через ЛПТ порт. Если бы продолжил, то появился бы плис или fpga. Приёмники в конце 90 уже тоже цифровые - вару, усилитель пч, полосовой фильтр а потом ацп. Я к тому, что один 32 битный контроллер помогает сейчас быстро что то сделать для попробовать. Если он у кого то лежит на столе постоянно, то пара резисторов и новый образец для тестирования задумки уже готов
Мне кажется это в компанейских стандартах должно быть описано. У нас было два филиала, в нашем было требование отвечать в течение суток либо полностью, либо со сроками полного ответа, либо отправлять куда то дальше. Во втором в связи с текучкой этого требования не знали и не хотели вообще признавать, что проблема есть. Так что пришлось и в копии ставить, и ретранслировать начальнику неотвечающего, и таски блокировать запросами, и треды собирать. Небыстро, через hr и топ менеджмент ситуация на некоторое время выправилась.А потом снова текучка на той стороне и снова очень много крайне занятых PO, PM, манагеров и прочих.Бескультурье, вообщем)
Наверно есть отдельные люди или разновидности деятельности, которым самозанятость удобна. Или организации удобно иметь сотрудников как самозанятых, но такими может поинтересоваться налоговая или трудовая инспекция. Но если говорить об индустрии, то самозанятость это замануха или развод от работодателя, в основном. Ну и инженеры в IT должны получать больше, пусть не сразу после вуза, но лет через 3-5. А повысить свою квалификацию самозанятыми по мелким конторкам у них вряд ли получится, нужны и наставники, и задачи посложней и посовременней. Поэтому мне непонятно зачем IT самозанятость да ещё с ограниченной зарплатой.
А почему ссылки на этот сайт и сервис нет на государственном сайте НКЦКИ? То что ори выкладывают бюллетени и руководящие документы не делает их официальными, ну и вообще нет данных о владельце сайта и контактов. Минимум некорректо это, имхо
Любую чужую сеть, имхо. Там где можно прослушать или подменить WiFi роутер, например. По большому счёту, если Вы с работы лезете в свой банк, то тоже нелишним будет попытаться включить VPN, мало ли какие маргиналы у вас сетевики Но это, конечно, паранойя уже))
Вот даже с моими 30 сотками и лесом за забором тезис о "подземной фильтрации" мне не нравится. Кроме того, с одной стороны автор неприемлет аэрацию, а потом пишет о необходимости свободного доступа кислорода для разложения органики.
В общем у меня стоит септик Тверь с аэрацией и колодец за забором для слива чистой воды с переливом. Ой, простите, вода, конечно, нечистая, потому что Тверь не септик))
Тема просто песня)) Я ээ.. 16 лет работал в конторе, в которой несколько раз поменялся менеджмент и лиды. Плюсом был опыт общения с саппортом 2 крупных производителей техники. Все 16 лет нам говорили, что мы работаем в режиме 12 через 12 - те задачи которые у нас есть утром, надо сделать к вечеру, чтобы следующие 12 часов их решали на другой стороне. Ну и плюсом у нас тоже были и команды, и департаменты со своими задачами, но с общим конечным продуктом в продакшене. Так вот, пункты 4 и 6 работают, остальное либо нет, либо усугубляют проблему.
Про контрагентов - один реагировал на все письма, эскалировал когда надо внутри своей конторы, запрашивал эскалирования у нас, если это переходило на бизнес уровень. Второй (с золотым саппортом, причём) как правило тоже отвечал, но держал оборону) Потом я добавлял шефа, тот своего, доходило до наших CEO, мы покупали ещё, они фиксили.
Про отношения между командами локально - несколько групп у нас вводили расписание на общение с другими командами. То есть просто слали всех кто приходил в неурочные часы. Их можно было понять, но карму им это не повышало) В переписке они тоже считали возможным игнорировать вопросы о проблемах в их функциональности. Ну, это их выбор, эскалируйте их и вашему руководству и забудьте о этой теме вообще, пока не ответят. Спросят статус - перешлите тред с комментарием.
Из смешного - к нам в комнату часто ходили с вопросами из соседнего департамента, и часто они касались смежной функциональности. Как то раз функциональность оказалась вообще не наша и даже не рядом, на вопрос зачем и почему вы пришли с вопросом к нам нам ответили - вы с нами разговаииваете))
Я бы, наверное, кроме поддержки 4 и 6, дал ещё совет собирать все кейсы проблемных коммуникаций и когда спросят, а в нормальном процессе спросить должны, выдавать их в HR или кто занимается этими вопросами. Ну и найти кто отвечает)
Кстати, одного, кто любил спрашивать, чтобы облегчить себе жизнь, и не любил отвечать у нас уволили за неэтичность к коллегам.
Именно что с прошлого века, когда пытались цвести всякие гиперкубы и торроидальные топологии, когда появилась аппаратная поддержка кластеров, ОС с динамической балансировкой задач по узлам вычислительной сети и прочее. И это были вполне промышленные решения. Однако примерно через поколение интерес к этим решениям поутих совсем. При этом, по сравнению с тем что описываете Вы, эти решения были на пару- тройку порядков проще - задачи гранулярней, вычисления менее связаны, функциональность и асинхронность как залог параллельности. И поставили на этих направлениях крестик в связи со сложностью и отсутствием универсальности. Почему Вы думаете что вот сейчас взлетит? Причём сразу на несколько порядков сложней?
Хороший пример и постановка проблемы. Я не переводчик, но пока учился в школе, довелось проходить практику в бюро перевода, работая со статьей по нейрохирургии и обсуждая ее с родственником врачом. Некоторые переведённые термины, одобренные переводчиком бюро, вызывали острую реакцию родственника) Потом столкнулся с трудностями перевода руководства по ОС TSX с термином task swapping - тогда не существовало понятия виртуальной памяти, и подобрать что то эквивалентное свопу было крайне затруднительно..Ну и последний сильно проблемный устоявшийся пример - это перевод pointer dereference))
Насколько я слышал, проблема называется проблемой переадресации перевода. Связана с тем, что в рамках двух языков смысл слов и сочетаний может быть разный. И несмотря на то, что architecture deсision по правилам дословного тех перевода следует переводить как решение архитектуры)), такой перевод нуждается в переадресации, которую Вы и проделали. Ну а некоторые вещи вообще невозможно перевести, если в целевом языке нет схожих понятий. Тогда только кофе, файл..))
На контроллерах лучше использовать CORDIC, если вычислять надо постоянно
Раньше были радиолюбители, первым творением которых был, как правило, радиоприёмник в мыльнице. Наверное что то такое подразумевается и в этой статье под "новичком". Иначе о чём вообще идёт речь, если этот "программист" в институтике минимум 4 года что то должен был изучать.
Жизнь и задачи требуют, имхо. Я вот начинал с транзисторов, полевиков, теристоров, ферритовых формирователей импульса на дросселе насыщения, усилителей.. А потом пришлось делать многоканальный тракт передатчика для фар, транзисторы в выходном каскаде остались конечно, а вот формирователь был уже на однобитном ОЗУ с загрузкой через ЛПТ порт. Если бы продолжил, то появился бы плис или fpga. Приёмники в конце 90 уже тоже цифровые - вару, усилитель пч, полосовой фильтр а потом ацп. Я к тому, что один 32 битный контроллер помогает сейчас быстро что то сделать для попробовать. Если он у кого то лежит на столе постоянно, то пара резисторов и новый образец для тестирования задумки уже готов
Мне кажется это в компанейских стандартах должно быть описано. У нас было два филиала, в нашем было требование отвечать в течение суток либо полностью, либо со сроками полного ответа, либо отправлять куда то дальше. Во втором в связи с текучкой этого требования не знали и не хотели вообще признавать, что проблема есть. Так что пришлось и в копии ставить, и ретранслировать начальнику неотвечающего, и таски блокировать запросами, и треды собирать. Небыстро, через hr и топ менеджмент ситуация на некоторое время выправилась.А потом снова текучка на той стороне и снова очень много крайне занятых PO, PM, манагеров и прочих.Бескультурье, вообщем)
Наверно есть отдельные люди или разновидности деятельности, которым самозанятость удобна. Или организации удобно иметь сотрудников как самозанятых, но такими может поинтересоваться налоговая или трудовая инспекция. Но если говорить об индустрии, то самозанятость это замануха или развод от работодателя, в основном. Ну и инженеры в IT должны получать больше, пусть не сразу после вуза, но лет через 3-5. А повысить свою квалификацию самозанятыми по мелким конторкам у них вряд ли получится, нужны и наставники, и задачи посложней и посовременней. Поэтому мне непонятно зачем IT самозанятость да ещё с ограниченной зарплатой.
Беда..
А почему ссылки на этот сайт и сервис нет на государственном сайте НКЦКИ? То что ори выкладывают бюллетени и руководящие документы не делает их официальными, ну и вообще нет данных о владельце сайта и контактов. Минимум некорректо это, имхо
ITшник с доходои менее 2,4 в год. Интересно, конечно))
Любую чужую сеть, имхо. Там где можно прослушать или подменить WiFi роутер, например. По большому счёту, если Вы с работы лезете в свой банк, то тоже нелишним будет попытаться включить VPN, мало ли какие маргиналы у вас сетевики Но это, конечно, паранойя уже))
А сами быстро отвечаете на письма от "технарей"?) Потому что у меня большинство проблем было с очень занятыми на удалёнке PM.
Любой тренинг по безопасности для офисных работников и при доступе к конф информации типа онлайн банкинга содержит пункт:
Включите VPN при доступе к своему аккаунту из публичной сети.
Как у них, в Госдуме, интересно, проводят такие тренинги?)
Да, у нас почти все так и делают. Кольца без дна и скважина метрах в 20-30. Но я оказался скромней
Статья 1 - по ГОСТ с аэрацией не септик, а дальше про кислород для разложения органики.
Вот даже с моими 30 сотками и лесом за забором тезис о "подземной фильтрации" мне не нравится. Кроме того, с одной стороны автор неприемлет аэрацию, а потом пишет о необходимости свободного доступа кислорода для разложения органики.
В общем у меня стоит септик Тверь с аэрацией и колодец за забором для слива чистой воды с переливом. Ой, простите, вода, конечно, нечистая, потому что Тверь не септик))
Тема просто песня)) Я ээ.. 16 лет работал в конторе, в которой несколько раз поменялся менеджмент и лиды. Плюсом был опыт общения с саппортом 2 крупных производителей техники. Все 16 лет нам говорили, что мы работаем в режиме 12 через 12 - те задачи которые у нас есть утром, надо сделать к вечеру, чтобы следующие 12 часов их решали на другой стороне. Ну и плюсом у нас тоже были и команды, и департаменты со своими задачами, но с общим конечным продуктом в продакшене. Так вот, пункты 4 и 6 работают, остальное либо нет, либо усугубляют проблему.
Про контрагентов - один реагировал на все письма, эскалировал когда надо внутри своей конторы, запрашивал эскалирования у нас, если это переходило на бизнес уровень. Второй (с золотым саппортом, причём) как правило тоже отвечал, но держал оборону) Потом я добавлял шефа, тот своего, доходило до наших CEO, мы покупали ещё, они фиксили.
Про отношения между командами локально - несколько групп у нас вводили расписание на общение с другими командами. То есть просто слали всех кто приходил в неурочные часы. Их можно было понять, но карму им это не повышало) В переписке они тоже считали возможным игнорировать вопросы о проблемах в их функциональности. Ну, это их выбор, эскалируйте их и вашему руководству и забудьте о этой теме вообще, пока не ответят. Спросят статус - перешлите тред с комментарием.
Из смешного - к нам в комнату часто ходили с вопросами из соседнего департамента, и часто они касались смежной функциональности. Как то раз функциональность оказалась вообще не наша и даже не рядом, на вопрос зачем и почему вы пришли с вопросом к нам нам ответили - вы с нами разговаииваете))
Я бы, наверное, кроме поддержки 4 и 6, дал ещё совет собирать все кейсы проблемных коммуникаций и когда спросят, а в нормальном процессе спросить должны, выдавать их в HR или кто занимается этими вопросами. Ну и найти кто отвечает)
Кстати, одного, кто любил спрашивать, чтобы облегчить себе жизнь, и не любил отвечать у нас уволили за неэтичность к коллегам.
Было бы полезно упомянуть примеры трафика с виртуальными сетями, вывод дампа в файл и то, что по дефолту дампится только заголовок без пейлоада
Ну, виндусы тут вообще непричём. Средства прототипирования уже были, и даже у нас в РФ. PThreads тоже существовали и кто хотел их использовал.
И что такое коммутация элементов vs дизайн с нуля осталось непонятным.
Всё с ними так, но они редко пишут подобного качества статьи)
Именно что с прошлого века, когда пытались цвести всякие гиперкубы и торроидальные топологии, когда появилась аппаратная поддержка кластеров, ОС с динамической балансировкой задач по узлам вычислительной сети и прочее. И это были вполне промышленные решения. Однако примерно через поколение интерес к этим решениям поутих совсем. При этом, по сравнению с тем что описываете Вы, эти решения были на пару- тройку порядков проще - задачи гранулярней, вычисления менее связаны, функциональность и асинхронность как залог параллельности. И поставили на этих направлениях крестик в связи со сложностью и отсутствием универсальности. Почему Вы думаете что вот сейчас взлетит? Причём сразу на несколько порядков сложней?