Если суммарный траффик на внешних каналах значительно вырос - это прежде может означать либо большой процент потерь где-то во внутренней сети РФ(пакеты не доходят до потребителя где-то на оконечных участках), либо, что по каким-то причинам внутрироссийский траффик идет через внешние маршруты (поломана внутренняя маршрутизация, либо она заслужила низкие метрики/высокую стоимость).
Кстати о сетях нашей молодости. Сейчас meshtastic набирает популярность, вполне тянет на Fido v2.0, в то время как привычный интернет постепенно превращается в инструмент связи с гос.сектором и торрентокачалку
ИМХО цензор живёт в парадигме, что пользователь либо покупает продукт "из коробки" за подписку, либо выполняет самостоятельную настройку таким образом, чтобы всё работало как раньше. А что если не заворачивать весь забугорный траффик в трубу, а обеспечить себе доступ лишь к тем ресурсам, которые вам действительно нужны (тот же Intel, dell, st например и ряд китайских сайтов которые перестали работать из РФ). Да, таблица маршрутизации будет возможно длинная. Но за то все сервисы иностранной геолокации будут показывать "правильный" IP.
если рассмотреть один и тот же уровень квалификации, то чел без особых технических знаний, со знанием языка и шаблонным мышлением в банке зарплатой скорее будет доволен, а в современную оборонку без технического бэкграунда шансов и без того мало (а на такую же з/п - вообще под сомнением)
Тут до смешного: любые попытки удешевления труда ведут к его удорожанию. Придумали всякие инструменты, фреймворки и т.д. с целью увеличить количество разработчиков, и за счет увеличения конкуренции и снижения трудозатрат/сокращения времени разработки сократить расходы, это отыграло в короткой перспективе, а потом напротив привело к резкому росту оплаты труда тех самых разработчиков
Это всё манипуляции сознанием. Уже запретили использовать образ врача в рекламе для лекарств. Спасибо за дизлайки конечно, но использование старых добрых мульфильмов, картин и т.д. для рекламы (в т.ч. саморекламы ютуберов) - это уже слишком. Я против.
В каком-то смысле и правильно, что блокируют. То что стало общественным достоянием надо и использовать достойно, как элемент культуры прошлого, а не в качестве инструментов рекламы или раскрутки разного сорта ютуберов.
Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.
Если суммарный траффик на внешних каналах значительно вырос - это прежде может означать либо большой процент потерь где-то во внутренней сети РФ(пакеты не доходят до потребителя где-то на оконечных участках), либо, что по каким-то причинам внутрироссийский траффик идет через внешние маршруты (поломана внутренняя маршрутизация, либо она заслужила низкие метрики/высокую стоимость).
Кстати о сетях нашей молодости. Сейчас meshtastic набирает популярность, вполне тянет на Fido v2.0, в то время как привычный интернет постепенно превращается в инструмент связи с гос.сектором и торрентокачалку
ИМХО цензор живёт в парадигме, что пользователь либо покупает продукт "из коробки" за подписку, либо выполняет самостоятельную настройку таким образом, чтобы всё работало как раньше. А что если не заворачивать весь забугорный траффик в трубу, а обеспечить себе доступ лишь к тем ресурсам, которые вам действительно нужны (тот же Intel, dell, st например и ряд китайских сайтов которые перестали работать из РФ). Да, таблица маршрутизации будет возможно длинная. Но за то все сервисы иностранной геолокации будут показывать "правильный" IP.
Вот что значит по настоящему талантливый разработчик. Жизнь пропадает в вебе, а мог бы творить чудеса
если рассмотреть один и тот же уровень квалификации, то чел без особых технических знаний, со знанием языка и шаблонным мышлением в банке зарплатой скорее будет доволен, а в современную оборонку без технического бэкграунда шансов и без того мало (а на такую же з/п - вообще под сомнением)
Нет, я против того, чтобы фирмы и ютуберы разного разлива использовали предметы культуры для саморекламы
Тут до смешного: любые попытки удешевления труда ведут к его удорожанию. Придумали всякие инструменты, фреймворки и т.д. с целью увеличить количество разработчиков, и за счет увеличения конкуренции и снижения трудозатрат/сокращения времени разработки сократить расходы, это отыграло в короткой перспективе, а потом напротив привело к резкому росту оплаты труда тех самых разработчиков
Это всё манипуляции сознанием. Уже запретили использовать образ врача в рекламе для лекарств. Спасибо за дизлайки конечно, но использование старых добрых мульфильмов, картин и т.д. для рекламы (в т.ч. саморекламы ютуберов) - это уже слишком. Я против.
В каком-то смысле и правильно, что блокируют. То что стало общественным достоянием надо и использовать достойно, как элемент культуры прошлого, а не в качестве инструментов рекламы или раскрутки разного сорта ютуберов.
Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
так цена китайской платы с картоприемником и bluetooth 300р
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
эмбеддед в последнее время
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.