(Объектно-Ориентированное Помешательство)
Описание
Заразное ментальное расстройство, поражающее программистов, чрезмерно увлекающихся объектно-ориентированным программированием (ООП) и паттернами проектирования. Симптомы включают неспособность писать простой код, чрезмерное усложнение архитектуры и патологическую потребность во внедрении фабрик, стратегий и синглтонов даже там, где они не нужны.
let c=(b,l)=>WebAssembly.instantiate(new Int8Array(
[,97,115,109,1,,,,1,5,1,96,,1,127,3,2,1,,7,4,1,,,,10,
l=(b=b.split` `.flatMap(t=>t>-1?[65,t]:107+'-*/'.indexOf(t)))
.length+4,1,l-2,,...b,11]))(await c('11 11 1 - + 4 * 2 /')).instance.exports['']()
В этой статье я расскажу, что это за стажировки, сколько денег заберут из вашего кармана, почему я не рекомендую туда идти и что могу посоветовать вместо них.
Я ни в коем случае не осуждаю никакие подходы в трудоустройстве. Тут я максимально либерален, но мне крайне не нравится, что кто-то вводит людей в заблуждение, и все карты открывает только тогда, когда подписан договор с большой неустойкой, если вы захотите его разорвать.
Самое главное – не добавляйте превью к статье. Основную мысль тоже не раскрывайте здесь – не стоит сразу выкладывать все карты
const fizzbuzz = (n: number)=>`${n%3 ? '' : 'Fizz'}${n%5 ? '' : 'Buzz'}`;
Как часто сейчас в ИТ сообществе можно услышать про невероятные успехи LLM моделей? ИИ написал диссертацию за 30 минут, ИИ пишет программы на уровне middle разработчика, ИИ диагностирует болезнь с точностью 99.99999% и много много других впечатляющих заголовков пестрят на сотнях сайтов. И это не говоря о том, что создатели таких ИИ моделей заявляют, что через 2-3 года ИИ станет умнее человека чуть ли не в каждой сфере жизни.
А так ли это? Давайте поищем парочку не совсем хитрых, но интересных задач, с которыми может справиться даже ребенок (немного подумав, конечно), но не может справиться современный ИИ.
Программирование — это не только алгоритмы и логика, но и удивительное разнообразие синтаксиса языков. Работая над новым средством подсветки синтаксиса для llamafile, разработчик Justine Tunney* исследовала 42 языка программирования — от классического C и экзотического Tcl до мощного Ruby.
Justine делится своими открытиями о том, насколько причудливым и непредсказуемым может быть лексический синтаксис. Например, триграфы в C — устаревший инструмент для поддержки клавиатур с ограниченными символами, фиксированные длины строк в FORTRAN, вложенные комментарии в Haskell или строки с двойными квадратными скобками в Lua. Ruby вообще оказался чуть ли не самым сложным языком для подсветки из-за его контекстно-зависимого синтаксиса.
Под катом вы найдете описание разработки инструмента подсветки и исследование того, как языки программирования решают одни и те же задачи по-разному. Если вам интересны синтаксис, языковые особенности и сложности лексического анализа – эта статья для вас.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис
Наверное, каждый разработчик рано или поздно задумывается о том, что же происходит в операционной системе на уровне ядра. Для ОС на базе ядра Linux относительно простой точкой входа является написание своих модулей. Модули по своей сути — это драйверы устройств (символьные char device, блочные block device, сетевые network device и другие).
В книге Linux Device Drivers (LDD) подробно описано, как создать свой модуль ядра для интересующего класса устройств. Однако эта книга очень устарела, поскольку в ней рассматриваются случаи, справедливые для ядра версии 2.X.X. А в 2025 году третьему изданию Linux Device Drivers исполняется 20 лет!
На сегодняшний день большинство устройств используют ядра 5.X.X или 6.X.X, в которых многое изменилось. Так и появилась идея этой статьи — адаптировать информацию из LDD под современные ядра.
Под катом рассмотрим следующие классы устройств: char device, block device и network device.
Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.
Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».
Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».
Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».
Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же автор серии видео про его устройство.
Я продолжаю свой цикл статей на хабре про детали реализации питона. Сегодня я хочу рассказать, как tuple устроен внутри.
Под катом будет про: мутабельность кортежей (и планы по отмене такого поведения), дичь с ctypes, переиспользование памяти и другие оптимизации.
Ну и конечно – мое полное видео на полтора часа, где будет множество дополнительной информации о деталях работы VM.
Если вам такое интересно или целиком незнакомо – добро пожаловать!
В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.
Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.
Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).
printf, пока её не реализуем. Здесь вам потребуется освоить различные техники и приёмы отладки, которые в разработке ПО вы никогда не использовали. В частности, начиная «с нуля», вы будете встречать сложные этапы вроде процесса загрузки и страничной организации памяти. Но не пугайтесь, «отлаживать ОС» мы тоже научимся!
Речь пойдет о тайной, сугубо анонимной организации, следы которой начал замечать еще в 2018-ом, работая в Яндексе. О целях и мотивах организации можно только догадываться: некоторые считают это кибер-луддизмом, другие — техно-анархизмом. Ясно одно: организация существует, ее члены уничтожают кодовые базы десятилетиями, и говорить об этом не принято.
Как разработчик я ежедневно сталкиваюсь с большим количеством данных, которые нужны для принятия каких‑либо решений. Логи, конфиги, данные профилирования, аналитические выгрузки из БД и даже сведения о том, когда был написан данный код — это всё данные. Иногда бывает достаточно посмотреть глазами, и картина станет ясной. Но чем больше данных, тем меньше помогает «метод пристального взгляда», и тем нужнее какие‑то инструменты анализа.
Иногда можно собрать нужную информацию, просто скомбинировав несколько линуксовых команд пайпом (cat data.log | grep … | awk … | sort | uniq -c | sort -r | head), иногда пригодятся электронные таблицы, иногда проще написать небольшую программку для анализа данных. Но когда я освоился с языком R и его экосистемой, то всё это стало ненужным.