Pull to refresh
4
0
Evgeniy @dj1m

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

Send message

Не поленился зайти, чтобы ответить. Как жителя до недавнего времени средней полосы одного из деградирующих регионов России, меня заинтересовала тема, куда же уходят мои налоги. Так вот для примера: бюджет моего города - около 15 млрд рублей. Из этих денег около 5 млрд обеспечиваются поступлениями НДФЛ. Но оказалось,что только 25% моего НДФЛ идёт в местный бюджет. 75% уходят в федеральный бюджет. То есть у нас мог бы быть бюджет 20 млрд! только за счёт НДФЛ. То есть забирают миллиарды, а потом прибегает Володин, и все паблики рассказывают, какой он молодец - выделил 300 млн на бордюры.

И это только один налог, а их десятки.

Все самые жирные налоги уходят в федеральный бюджет.

Вся фишка в том, что сотрудник сам угорал над этим списком, а потом внезапно понял, что это неправильно и предъявил. Он лицемер и ему стало просто обидно за этот факт.
Всем ностальгирующим рекомендую канал Edvard Wolf на ютубе.
Вот например видос на эту же тему
Я вас уверяю, вы, здоровые 30-летние лбы, будете реветь от ностальгии.
Всё верно. Недавно смотрел про свой город этот вопрос.
У нас в городе хотят сделать «скоростной трамвай». Цена вопроса — 6 млрд рублей.
Всё завязано на некие торги и получение денег из федерального бюджета с бесконечным упоминанием соответвующего чиновника, какой он молодец.
Бюджет города порядка 15 млрд. Если посмотреть доходы, то примерно 5млрд — это доходы от ндфл. Однако, только 25% ндфл остаётся в городе, остальное уходит в федеральный бюджет, даже мимо областного. То есть за счёт только ндфл бюджет города мог быть больше на четверть, чем текущий.
В целом, все самые жирные налоги уходят в федеральный бюджет, менее жирные пилятся между областным и бюджетом муниципальных образований в разных пропорциях, и самые минимальные остаются на местах.
Очень хочется не согласиться с вами.
Как раз таки раньше интерфейсы был побогаче, в те времена старались выделиться. Иконки и интерфейсы, в целом — это больше цветов, тени всякие, закосы под 3д и прочее. А сейчас все эти материал дизайн и тд и тп. Откройте ютуб приложение, у меня в айфоне:
  • хэдер с 5 иконками(просто чёрные линии на белом фоне)
  • 2 превью видео
  • футер с 5 иконками(просто чёрные линии на белом фоне)

Даже обидно, нахрена мне ахрениллион цветов в дисплее, с потрясающей контрастностью и супер пупер разрешение ради десяти чёрно-белых иконок.
проблема в том, что это не показатель. И, как пример, там в соседней статье как раз бывший гуглопрограммист жалуется на жизнь, что они собрали систему и за день просрали 72килобакса. Ну зато все списки и мапы разложены как надо вместе со всеми деревьями.
Ох, боже, я не одинок!
Каждый раз, читая очередной фейл, думаешь да как так то?!
Наверняка, автор зато мастерски раскладывает красно-чёрные деревья, разворачивает листы, разделяет ценности и всё это за bigO(1) и вообще без памяти.
Осталось только софт научиться писать и системы проектировать, ну это мелочи.
Я на проекте с тех времён, когда >5 лет назад его сажали на некий фреймворк + очень сильно кастомизировали под нужды заказчика. Сетап — монолит на фреймворке, джава 1.6, вебложик + много всякого от оракла типо oracle bd, coherence(он уже даже в opensource выложен), а заказчик всё ещё платит за него) и тому подобный кровавый. Причём заказчик в тот момент слезал со своего самописного решения, потому что есть же готовое.
Весь вопрос устаревания кода и проблемы с ним — это сохранять возможность с постоянной скоростью развивать и поддерживать бизнес решение.
Сейчас кольцо замкнулось и есть новые команды, которые находятся на этапе выстраивания нового самописного решения вместо готового на базе всех модных вещей, которые есть: облака, кубер, сервисы, лёгкий фронт, унификация, коучбейз, мемкэш, эластик как поисковик, графана и тд и тп полный фарш. Непонятно куда это всё в итоге приедет, но пока тяжело даётся, потому что новые люди не учитывают предыдущий опыт проекта, но очень надеюсь, что получится.

Следующие проблемы возникли на нашем проекте на протяжении такой долгой жизни:
— неправильное/недостаточное использование фреймворка на начальном этапе привело к тому, что фичи фреймворка мы пилили сбоку и сами (долго, дорого). Промахнулись с изначальными бизнес требованиями;
— отсюда произошло следующее — крайняя сложность/дороговизна апдейта версии фреймворка, поэтому сделали это один раз и только для минорной версии;
— смена всех людей на стороне заказчика привело к потере договорённостей, смене несколько раз некоего общего курса и необходимости поддержки функционала, который уже никому не нужен. В какой-то момент, мы из-за этого не смогли дожать переезд на джава 8, который потенциально мог бы решить/облегчить даже текущие проблемы с перфом хотя бы за счёт G1, например;
— меняются менеджеры на стороны исполнителя, т.е. тактика «сдать релиз, а потом пусть хоть всё сгорит на проде» приводит к накоплению годами костылей, что в итоге значительно удорожает и разработку, и поддержку. Не нужно спрашивать разрешения делать свою работу хорошо, не нужно вот этого всего: «сегодня надо закрыть все мажоры» «быстрей, быстрей, у нас дедлайн», «быстро закроем, потом переделаем»;
— меняются собственно сами команды — найти разработчика на джава 1.6 становится таки проблемой. Возникает необходимость обязательного входного обучения и формализация кодстайла, процессов разработки и прочего. Я имею ввиду, чтобы это было прям реально хорошо сделано. Иначе даже на обычных PR будут проблемы. Если каждый будет фигачить как он хочет — будут проблемы в поддержке такого решения. Мы сделали такие ошибки(дали волю разработчику, полагаясь на его опыт на проекте) и есть пару мест в проекте, где никто особо не разбирается, кроме него(ну и собственно сам результат работы неоднозначен);
— меняются люди в смежных системах, с которыми есть интеграции — приводит к появлению новых багов в функционале, который давно не трогали, из-за кривизны новых данных или неправильного использования или использования не по назначению;
— в целом, как мне кажется, смена людей приводит к большим проблемам, чем смена технологий, подходов в разработке, тестировании, деплоя и тому подобных технических вещей. Поэтому важны не только процессы прихода новичков, но и уход опытных людей должен быть сопровождён какими-то артефактами. Это актуально не только для разработчиков, но и для qa, ba, менеджеров всяких. А ещё спеки/документация это хорошо, и поддержка всей этой документации тоже отдельная сложная задача.
— бизнес хочет фич и не хочет вкладываться в техдолг. Отсюда несколько последствий. У бизнеса возникает ощущение, что похожий функционал будет разрабатываться быстрее, а по факту медленнее, идёт сильно расхождение между ожиданиями и реальностью, которое вываливается в недоверие/усиленнный контроль/митинги по разбору полётов и прочие довольно неприятные вещи. Чем более запущенней становится какой-то кусок, тем больше вероятность, что следующая фича полностью ломает функционал(такое было дважды) и приводит в полному переписыванию. Работа с техдолгом обязательна, необходимо формализовать и объяснять бизнесу/командам/PO/SM для чего это делается;
— большое количество «временных» решений, которые потом становятся постоянными, а через пару лет вообще превращаются в баг, и найти историю почему было сделано именно так довольно сложно. Обязательно надо комментировать код/писать тестик в случае такого костыля. Как пример, нашли баг, оказалось что проблемы в интеграции не с нашей стороны, другой системе для починки нужно много времени, Делаем хотфикс у нас, и получается что на нашей стороне обработка интеграции в определённом случае идёт по-другому. Коммент с тикетом для другой системы и юнитест на этот кусочек логики очень просто позволил потом снять с нас обвинения в неправильной работе, когда дошли до очередного этапа разбора полётов.
а как же выживают те, кто приезжает из так называемых bodyshop? врядли там на старте можно иметь больше 150к$/year gross?
150к$/year gross — это примерно 9к чистыми в месяц(+- зависит от налогов, который может быть от ~15% до ~35%)
Далее -4к$ на апарты,-2к$ на покушать,-1к$ на связь/интернет, -1к$ на машину
2к$ в плюсе, т.е. просто тупо больше ЗП синьора из провинции
что не так в подсчётах?
Если посмотреть карты коммьюнити, например, в саннивейл/маунтинвью/санта клара, то там средние зп в районе 135к.
Как мы теперь знаем с 29 апреля в России пошёл резкий рост ежедневных случаев (с полки в районе 6к до 10.5к)
Ну и вот видим, что моделирование не сработало. Видимо, забыли добавить коэффициенты(предсказуемости тупости?) на празднование Пасхи и введения пропусков (и сопутствующие толпы в метро) в Москве.
Заодно, было бы интересно посмотреть как майские праздники сыграют.
именно так происходит не только в android разработке. А прям в самом кровавом интерпрайзе. Микросервисы, докер, все дела. Новенькое пишут сразу на котлине, старое переписывают, когда руки дотягиваются.

А какие механизмы?

В этом и проблема! Вы не можете избавиться от них и переселить их.
Все эти антипрививочные движения приводят только к одному результату — деградации. Видео на тему, почему резко вернулась корь в Штата. Корь, КАРЛ!
www.youtube.com/watch?v=Z2swde6Z97w

Каким бы скайп не был говнищем(особенно после последних апдейтов), реальной альтернативы так-то и нет. Все-таки, чаще всего, винда — стандарт для корпораций, поэтому аргумент про линукс мимо. В скайпе я легко могу шарить экран, собрать чат на 100500 человек, позвонить в чат на 25 человек, через пень колоду могу сообщения из одного чатика процитировать в другом. И да, по поводу ci/cd, у нас скайп бот, который в соответствующий чатик с тестовой средой пишет ее состояние о пересборке, состоянии сервака и тому подобное. А ещё он настолько убогий на мобилке, что работу вы будете оставлять на работе. Хотя, пока я ехал в маршрутке, разраб шарил экран с кодом и мы таки пофиксали его баг.
В итоге, за многие годы работы выявилась следующая закономерность. Если у заказчика есть скайп, то в принципе связаться с ним проблем нет. А вот когда нет, то начинается вся эта дичь с телеграммами и прочее и хрен ты решишь вопрос быстро. Хотя как альтернативный канал, почему бы и нет.

Такие собеседования, такие вопросы, сложности алгоритмов, как быстрее, как меньше памяти, 100500 этапов интервью…
а по факту:
1) выпиливал некоторые моменты использования гуавы, потому что жрёт памяти как не в себя
2) заканчивался пул коннектов, потому что их использование из какой-то другой гугловой библиотеки было настолько НЕ ОЧЕНЬ очевидным(да, потом нашли пример в доках, да, разработчик не посмотрел)
3) вы видели gmail?), больной ублюдок вообще интерфейс придумывал

Но тем не менее, осадочек остался, ожидаешь-то большего.
Неистово плюсую. Не надо быть семи пядей во лбу, рокстар, аджайлгуру, разработчиком собственного фреймворка(велосипеда), чтобы просто ответственно делать свою работу, просто решить задачку. Причём неважно какая задача. Если человек делает на от**ись, то он всё так делает.
Ну кто в России не удивить высокими налогами)
Вот табличка интересная:
a.radikal.ru/a04/1804/c5/28ed0cc8b0ee.png
Если взять сумму налогов от «денег на руки» как проценты, то получается около 48-50%.
А in-memory data grid Oracle Coherence не рассматривали? Там и индексы, и кластеризация, и быстрая PoF сериализация и много чего собственно.
Каждый раз, читая такую историю, думаю: ну вот, наконец-то есть люди, умные люди, которым надо и которым хочется что-то менять и, может быть, у них получится. И каждый раз вижу этот облом. И каждый раз я их понимаю и подерживаю в решении сменить страну, чтобы просто иметь возможность созидать и двигаться дальше.
ну вот АКИТ вместо проработок вопросов такого уровня, снижения налоговой нагрузки, упрощения ведения бухгалтерии, упрощения процедур работы с госорганами, занимается тем, чтобы поприкрыть зарубежные интернет-магазины и решает вопросы уровня «а чо они не платят, как мы». В итоге, за всё расплатится конечный пользователь.
1

Information

Rating
Does not participate
Location
Россия
Registered
Activity