Обновить
-4

Пользователь

Отправить сообщение

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 дизайн с нуля осталось непонятным.

Всё с ними так, но они редко пишут подобного качества статьи)

Именно что с прошлого века, когда пытались цвести всякие гиперкубы и торроидальные топологии, когда появилась аппаратная поддержка кластеров, ОС с динамической балансировкой задач по узлам вычислительной сети и прочее. И это были вполне промышленные решения. Однако примерно через поколение интерес к этим решениям поутих совсем. При этом, по сравнению с тем что описываете Вы, эти решения были на пару- тройку порядков проще - задачи гранулярней, вычисления менее связаны, функциональность и асинхронность как залог параллельности. И поставили на этих направлениях крестик в связи со сложностью и отсутствием универсальности. Почему Вы думаете что вот сейчас взлетит? Причём сразу на несколько порядков сложней?

Вот это "младшие помощники вспомогательного заместителя курьера" у Озона!! Или про млашего инженера была шутка?) Хорошая статья

А это всё у вас действительно с нуля развивается? Может стоит статьи почитать на эту тему? Про Dataflow Architecture, про модели организации вычислений - статьи проекта Ptolemy университета Беркли. Вычисления, управляемые данными не такая уж и простая штука чтобы пользователь мог с ними решать свои разнообразные задачки. В достаточно специальных областях, одной из которых является похеренная Вами GPU, такие подходы работают, но особого прогресса и расширения сферы применения что то не наблюдается.

Ну там про какую то обработку речь шла, я и подумал что уже все - победили)

А когда в плис приходится засовывать контроллер или dsp, потому что вычисления слишком причудливы для реализации на плис, или спецпроцессор, который обрабатывает микропрограмму последовательно для каждого блока данных, так ли высоко преимущество плис в части параллельности?)

Мне показалось что речь шла не о вреде исключений вообще, а именно на уровне архитектуры - взаимодействия компонент. Есть какой то API, есть протокол взаимодействия, и вдруг оттуда прилетает эксепшен. В вводе выводе эксепшены удобны, но их область распространения должна быть ограничена, иначе что за прикол нажать кнопку на плеере и получить окошко что у Васи usb диск отмонтирован.

А мне Watcom нравился . Как я его make в MultiEdit затащил.. но ориентировался конечно на Borland)

Делфи отчасти позиционировался как визуалбейсик, только нормальный, со всей вытекающей отсюда ответственностью) Если серьёзно, не было конечно у него такого плейсмента как у вижуал бейсика, но попытки отвоевать нишу были.

Информация

В рейтинге
5 653-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Инженер встраиваемых систем
Средний
Linux
Java
Английский язык
C++
C
Программирование микроконтроллеров
Linux kernel