Pull to refresh
55
7
Alexey Evdokimov @PastorGL

Software engineer. Practicioner, not a theorist.

Send message

У молотка должен быть метод .удар(). А булевское свойство .забиваемость() у наследника класса Материал, из которого состоит экземпляр класса Поверхность (заданный оному через соответствующее свойство), в который экземпляр класса Гвоздь забивается методом .забить() экземпляром класса Плотник. Перед этим надо ещё координаты забивания указать, и выбрать конкретный молоток, потому что у плотника их несколько... И количество вызовов метода .удар() зависит как от нужной глубины забивания, так и от сопротивления материала.

А то ведь гвозди не сами себя забивают, и в металлический швеллер их тяжеловато будет вогнать.

Короче, сначала модель надо ещё как следует смоделировать.

Если понимать под «ООП» имплементацию с классами, то некоторые претензии можно принять. И то с натяжечкой, — если злоупотреблять концепциями ряди концепций, как это делают авторы некоторых фреймворков, код может превращаться в переусложнённое маловменяемое нечто. Но ведь и другие имплементации бывают. Прототипная, на локальных контекстах/лямбдах. В конце концов, даже на голом C можно писать во вполне себе объектном стиле.

И вообще, для гоняния туда-сюда сообщений между базой и юаем развитое ООП и в самом деле не особенно нужно (для логики вполне можно обойтись процедурным программированием, а DTO, которые не имеют собственных методов — это же просто структуры), но для написания некоторых классов приложений подход с классами может очень удобным.

Если пишешь интерпретатор или компилятор, например. Или когда твои абстрактные объекты точно моделируют объекты реального мира — причём не собачек или кошечек, а что-то на пару порядков посложнее. Или если есть необходимость в инверсии контроля и инжектах логики, что часто бывает в распределённом энтерпрайзе. Там, где всё действительно строится на интерфейсах, стратегиях, и фабриках, просто потому что код размазан между десятков сервисов, и логика приложения собирается в далёком рантайме.

Просто серебряных пуль и универсалий не существует, каждому классу задач — свой ограниченный набор инструментов. А ещё над методологией разработки нужно думать головой, а не тупо брать какой-то шаблон, потому что он популярный. Обзывать же что-то скамом только из-за того, что для вашей конкретной частной задачи оно плохо подошло — даже не глупость, а свинство.

Ну так развал СССР это ведь «крупнейшая геополитическая катастрофа XX века» по мнению Путина В.В. (см. «Обращение к Федеральному собранию» 2005 года).

Ну а коли президент так думает, значит, надо всеми силами восстанавливать совок. Значит, всё логично и правильно, точно в русле курса партии и правительства...

Не сегодня, так завтра развернут на всю страну.

Ну, останутся разработчики без stackoverflow и docker, ну так и хер с ними... Хабр ведь не про разработку же.

Чтобы заблокировать к чёртовой матери половину интернета, руководствуясь какими-то внутренними распоряжениями, им и так полномочий хватает. Куда больше-то?

Впрочем, даже сокрушаться на эту тему уже надоело. Вот прям щас они Cloudflare зарезали для большей части страны. Видимо, просто потому что могут.

Которые тоже дружно пойдут на рынок труда, как только маленькому проценту программистов станет невозможно заниматься разработкой. Вот только они что-то найдут, а мы вряд ли.

А на чём сам 1С написан? Не на visual C++, часом? А СУБД какая штатно? Не PostgreSQL ли?

В моём 600-тысячном городе суммарный состав всех фирм, занимающихся IT как основной деятельностью (т.е. по первичному коду ОКВЭД — разработка ПО/БД, сопровождение
(1С бухгалтерия), а также интернет-провайдеры, и т.п.), составляет 4100 человек. Это данные из официальных источников за 2023 год. Если добавить хотя бы айтишные подразделения местных заводов (их много, так как город промышленный), не говоря уже о других непрофильных отделах, то айтишников брутто наберётся даже поболее, чем 1% населения.

Сколько среди нас чистых программистов, не берусь экстраполировать. Но не так мало, как вам кажется. А уж тех, кто от нас зависит, и того больше. И вот прикинем, что средства разработки стали недоступными... Потому что они все нынче завязаны на интернет, а вендоры-то где? За бугром, конечно. (Как получаются отечественные «аналоговнеты», вы, надеюсь, понимаете.)

Те, кому зарубежный интернет не нужен для работы, могут и пойти делать какие-то дела. А вот те, кому он таки нужен, смогут пойти только на хрен. Без развлечений ещё как-то можно перекантоваться, а вот без работы что делать?

Но охранителям «суверенитета» на нас, по всей видимости, наплевать. И ещё хорошо, если просто наплевать...

Мде. 3.14дец, но что поделать. Увы, но со спарком такие фокусы это проза жизни. Местами он действительно плохо спроектирован, и проще заманкипатчить, чем пытаться расширить что-то официальным способом. Слишком многое в ядре (написанном на скале), помечено как @DeveloperApi, и даже в жабу не экспозится, и фиг ты что с этим сделаешь, если надо поменять.

А ишьи они по полгода рассматривают, даже если есть пулреквест, — а потом бот их закрывает, так как никто из разработчиков не изъявляет желания ревьюить чужие контрибы.

(Как бы преодолеть мне лень, чтобы написать таки статейку на тему «как я курочил спарк»... Хотя, после миграции на 3.4 большую часть подобного у меня получилось в своей кодовой базе или обойти или убрать. Но в одном месте всё равно до сих пор приходится в кишки залазить, хотя уже и без патчинга.)

Тормозной интерфейс и бесполезные свистелки можно перетерпеть, но падение любого приложения на основе Chromium / Electron через 6–7 дней использования — это уже выше моих сил. А ведь на них сейчас чуть ли не большая часть десктопного софта делается.

Рабочую машину я никогда не выключаю, а домашнюю отправляю в сон. Так вот, на десятке спокойно от одного ежемесячного patch tuesday до другого всё работает, а на 11 процесс рендерера рано или поздно аварийно завершается, и что браузер, что vscode какой-нибудь падает со всеми вкладками.

То есть, DWM в 11 течёт по памяти, и особенно сильно течёт после восстановления из гибернации. Багу эту я репортил несколько раз, но фиксить её, видимо, не собираются. И пока не пофиксят, буду оставаться на десятке...

Оно редко за 2~3к строк вылазит, если только генератора триггеров или ещё какой-нибудь эзотерической фигни не требуется.

А на современной жабе с рекордами писать такое вообще считай читерство. Не нужно, как во времена 6, извращаться с рефлексией.

Хмм... Любой уважающий себя Java-разработчик обязан написать как минимум 1 ORM/JDBC-коннектор, 1 контейнер/DI/AOP, 1 кодогенератор/интерпретатор/компилятор. А лучше 5. Это единственный нормальный путь становления сеньором — и других наверное, нет.

Если вам удалось в одном проекте покрыть сразу несколько перечисленных категорий, значит, вы всё делаете правильно, и станете хорошим Java-сеньором. А если у вас хватает наглости выложить его в паблик, и добавить в название true/ultimate, то вы имеете все шансы стать просто отличным Java-сеньором. Большинство почему-то стесняется :)

Но хватит похвалы. Подобного DO layers написано очень много — я лично штук 6 имплементаций видел, заточенных под конкретный проект, и сам как минимум три писал (ещё более специализированных). У всех один недостаток: если надо сделать шаг влево или вправо от видения автора, то сразу приплыли. Сколько ни думай головой, заранее всех кейсов не продумаешь.

Но за выкладку в паблик зачёт, конечно.

Мне попадалась исследование по дохристианскому Риму — там также ~50% умирали до наступления совершеннолетия, а из оставшихся примерно треть могла дожить до 60 (если повезёт, и не будет эпидемий). Это, получается, общая норма доиндустриальной эпохи — то есть, людей как биологического вида в более-менее естественных условиях.

В Средиземноморье климат помягче, и 2000+ лет назад там вообще был локальный оптимум, так что ни засух, ни наводнений, следовательно, и голод был не то что бы часто. В отличие от малого ледникового периода тыщу лет спустя на севере Европы, где голод после заморозков в июне действительно был самый массовый убийца.

Вообще, мне кажется любопытным, что такой процент дожития до преклонного возраста был очень долго нормой для самых разных человеческих популяций. И поменялся он всего 100 лет назад.

Примерно так, но всё таки даже 10% стариков это уже достаточно, чтобы влиять на социальную структуру общества. Чего вот не было явно сказано, так это сколько из них было женщин. Всё-таки с десяток родов подряд кого угодно убьют — контрацепция в Рима была, но про её доступность ничего толком не известно.

Занятненько. Средневековье таки действительно грязным временем было.

Попадалось мне как-то исследование (давненько уже, сейчас никаких ссылок не найду) про продолжительность жизни в Средиземноморье в дохристианские времена. Вывод был там примерно такой, что если не помер в детстве, и повезло родиться между эпидемиями, то шанс дожить до 60 — 30%. Причём даже неважно, из какого ты сословия. То есть, стариков было немало. А потом Рим пал, и про гигиену почти на две тыщи лет забыли.

В жизни в провинции есть свои плюсы. Например, с местной ИТшной зарплатой можно заработать на квартиру в новостройке в центре города за 3 года. Потому что цены на недвигу тут сильно ниже столичных.

До офиса не надо тратить на метро по 2 часа в день, а можно прогуляться пешком (20 минут в одну сторону, а заодно и кардио). Расстояния вообще не те.

До дачи с мангалом доехать за те же 20 минут.

И в целом темп жизни сильно спокойнее. Лично я в Москву даже только из-за этого переезжать не собираюсь.

Вы видимо не в курсе, сколько платят в регионах.

В моём городе из конца первой 20-ки по населению зарплаты в ИТ отличаются от московских в 2.5 раза. Так что всё правильно, типичный мидл тут получает ~125. Только в нефтянке и банках зарплаты более-менее сравнимы со столичными, но, скажем так, не для всех.

Мда... 4й Спарк уже не за горами, а они всё ещё на 2.3 сидят.

Статью можно даже особенно и не читать, в терминологии телеграмного чатика Data Engineers такое решение это сплошная «глина». (На самом деле даже не удивляет.)

Information

Rating
978-th
Location
Ижевск, Удмуртия, Россия
Registered
Activity

Specialization

Backend Developer, Software Architect
Lead
Big data
Spark
Java
Database
Geoinformation systems
Software development
Algorithms and data structures
Development management
Automation of processes
ETL