Ну, если под любимым языком подразумевается русский, английский и т. д., то это в другой хаб. А если язык программирования или разметки, то конечно писать анализатор самим! На первый взгляд, это очень сложно, но, к счастью, существуют готовые многоязыковые инструменты, в которые относительно легко добавить поддержку нового языка. Сегодня я покажу, как можно с достаточно незначительными затратами времени добавить поддержку языка Modelica в анализатор PMD.

Кстати, знаете, что может ухудшить качество кодовой базы, полученной из последовательности идеальных pull request-ов? Тот факт, что сторонние программисты копировали в свои патчи куски существующего кода проекта вместо грамотного абстрагирования. Согласитесь, в какой-то мере такую банальность отловить ещё сложнее, чем некачественный код — он же качественный и даже уже тщательно отлаженный, поэтому тут недостаточно локальной проверки, нужно держать в голове всю кодовую базу, а человеку это непросто… Так вот: если на добавление полной поддержки Modelica (без создания конкретных правил) до состояния «может запускать примитивные проверки» у меня ушло около недели, то поддержку только copy-paste detector часто можно вообще добавить за день!

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.

Современный backend разнообразен, но всё-таки подчиняется некоторым негласным правилам. Многие из нас, кто разрабатывает серверные приложения, сталкивается с общепринятыми подходами, такими как Clean Architecture, SOLID, Persistence Ignorance, Dependency Injection и прочими. Многие из атрибутов серверной разработки настолько заезжены, что не вызывают никаких вопросов и используются бездумно. О некоторых много говорят, но никогда не используют. Смысл остальных же либо неправильно интерпретирован, либо перевран. Статья рассказывает о том, как построить простую, совершенно типичную, архитектуру backend, которая не только может без какого-либо ущерба следовать заветам известных теоретиков программирования, но и в некоторой степени может их усовершенствовать.

Не так давно на хабре появилось несколько постов противопоставляющих функциональный и объектный подход, породивших в комментариях бурное обсуждение того, что вообще это такое — объектно ориентированное программирование и чем оно отличается от функционального. Я, пусть и с некоторым опозданием, хочу поделиться с окружающими тем, что думает по этому поводу Роберт Мартин, также известный, как Дядюшка Боб.

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

Расскажу, чему я учился у Кличко. Если вам этот рассказ пригодится, в любом виде – отлично. Программисты должны помогать друг другу.

Одним из самых важных уроков, которые я постиг в качестве разработчика 15 лет назад, была эта простая мысль:

Хороший код выразителен, а не впечатляющ.

Я помню, как услышав это спросил «А в чём разница?», и получил ответ.

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

«Впечатляющий» — код, который запоминается. Написание кода, запоминающегося своими сложными структурами и алгоритмами, хотя и почешет ваше эго, станет настоящей болью для того, кто будет поддерживать его в будущем. И если последний окажется маньяком, узнавшим ваш адрес, храни вас Господь от его гнева.

Именно поэтому хороший разработчик мудр, а не гениален. Мудрый разработчик обладает не только умом, но и способностью постоянно думать о последствиях своих действий. Он знает какой конкретно код пишет, для чего он это делает и, главное, как это код поведёт себя в будущем. Или, если проще, мудрый разработчик пытается лечить болезнь, а не симптомы.

«Гениальные» разработчики, так же обладая умом, напротив, думают лишь о настоящем. Они умеют решать текущие проблемы быстро и эффектно. Вот только гора от их хаков и выкрутасов постоянно накапливается и однажды обрушает код, хороня под собой репутации всех причастных. Вот почему Стив Макконнелл однажды верно заметил:

Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.

И мудрые разработчики не делают ничего смекалистого. Они пишут скучный и простой код, который легко понять. Ни больше, ни меньше.

---

Вот ещё несколько принципов мудрых разработчиков.

Первый квартал внутренний критик и синдром самозванца были моими двумя лучшими друзьями. Я с ними общалась каждый день. Систематически. И просто не могла расслабиться. Считала, что недостаточно сделала, недостаточно взяла задач, недостаточно хороша и вообще…

Мне казалось, что я должна быть супертимлидом с первого дня

Несколько месяцев назад я работал в аутстафе. Это не то место, где нужен энтузиазм и вера в великую цель проекта. Меня вместе с командой просто продавали заказчикам, а на митингах было важно, сколько тикетов я закрыл. Приступы перфекционизма — скорее вредная штука для такого места, но я ничего не мог с ними сделать. За один из них я знатно поплатился, попал в адский кранч и провел худшие две недели в моей жизни.

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

Если вы это читаете — можно предположить, что вы заняты поиском фреймворка, который станет основой вашего следующего приложения. Вполне возможно, что вы ориентируетесь на ведущие технологии и размышляете о том, что вам лучше подойдёт — библиотека React или фреймворк Vue. Это — непростая дилемма, но решать её, всё равно, нужно. Вот некоторые распространённые вопросы, которыми задаются те, кто выбирает между React и Vue:

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

Гибридная методология управления на основе ценностей

В этой статье мы расскажем вам об Agilean («Эджайлин») как методе создания гибридных инструментов на базе Lean и Agile и шире об Agilean как о философии управления бизнесом с плацдарма ценностей.

Немного поговорим о нюансах физиологии и психологии человека, исходя из которых была сформулирована логика метода Agilean, и, в заключении, разберем практический пример и принципы применения этого гибридного метода для решения бизнес-задач.

Сравнительно недавно работаю с Symfony (чуть более года) и во всех проектах, что довелось поработать — сущности всегда создавались таким образом, что они содержали только приватные поля и голые сеттеры/геттеры к ним.

В статьи будут рассуждения и примеры, почему такой подход опасный, а именно: нарушает нашу старую добрую инкапсуляцию, провоцирует писать код с багами и повышать сложность системы.
В статье будет опущена тема сеттеров в разного рода билдерах и тема инъекции зависимостей через сеттеры (скажу только, что не одобряем). Не будет ничего про сложные темы вроде DDD, Rich Model, про coupling/cohesion и другие умные слова — просто поговорим про инкапсуляцию. Добро пожаловать под кат.

Все знают Skyeng в первую очередь как инструмент по изучению английского языка: это наш основной продукт, который помогает тысячам людей без серьезных жертв освоить иностранный язык. Но уже три года часть нашей команды занимается разработкой онлайн-олимпиады для школьников всех возрастных групп. С самого начала перед нами встало сразу три глобальных вопроса: технический, то есть вопрос разработки, педагогический и, конечно же, вопрос привлечения детей к участию.

Как оказалось, самым простым вопросом оказался технический, да и перечень предметов за три года заметно расширился: кроме английского в программу нашей олимпиады были включены еще и математика с информатикой. Но обо всем по порядку.

Как сделать участие в олимпиаде привлекательным для ребенка

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

Привет, этим постом мы хотим вызвать тимлидов на разговор. А точнее, запустить проект “ТимлидПозвонит”, в котором раз в две-три недели наши Петр anotherpit, Кирилл flashhhh и Артем arasskosov будут звонить интересному гостю через Google Meet и общаться на наболевшую тему.

В первом выпуске мы поговорили о трудностях найма с Антоном @ap_gubarev Губаревым, который пять лет руководит техническими командами на удаленке и ведет свой телеграм-канал о том, каково это. Ниже вы найдете текстовую выжимку, а также полную аудио и ютуб-версию разговора.

1. Я собеседовал вслепую

Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

• Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  
• Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  
• …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Как я хотела прикинуть, что дешевле – уволить выгоревшего сотрудника, «вылечить» или вовсе стараться не допускать выгорания, и что из этого получилось.

Сейчас небольшое вступление, откуда родилась эта тема.

Я почти что разучилась писать. Сначала нет времени; потом кажется, что все, о чем ты можешь/хочешь написать – это очевидно, а потом ты слышишь историю от коллеги из одной известной компании, который рассказывает, что в пятницу в 10 часов вечера их генеральный на полном серьезе уточняет: «Я тут побывал в департаменте разработки 5 минут назад. Почему еще только 10 вечера, а в офисе уже никого нет?»

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

Привет, я Катя, я не работаю уже год.



Я много работала и выгорела. Уволилась и не стала искать новую работу. Толстая финансовая подушка обеспечила мне бессрочный отпуск. Я отлично провела время, а еще утратила часть знаний и психологически постарела. Какая она, жизнь без работы, и чего не стоит от нее ждать, читайте под катом.

Привет, Хабр! Предлагаю вашему вниманию перевод доклада Александра Кузьменко с прошедшей недавно (14-15 июня) конференции Hong Kong Open Source Conference 2019.

До того, как присоединиться к Haxe Foundation в качестве разработчика компилятора Haxe, Александр около 10 лет профессионально занимался программированием на PHP, так что он знает предмет доклада.

Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят. Например, груша говорит: «Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод». И начинаю дубасить.

Недавно я добавил в грушу запись: «Типы — это сложно и ненужно». В этот момент я бью так сильно, что рука чуть не ломается. Потому что с меня хватит. Пару месяцев назад я пережил один из самых вопиющих кейсов в своей карьере.

Мой друг Антоха попросил меня помочь с решением для одной большой-большой корпорации. Я согласился, и мы влезли в бездонную пучину корпоративного абсурда, кранча, войны с ничего не понимающими коллегами и всеми видами несправедливости. Нам ничего нельзя говорить, поэтому мы будем говорить про типы, чтобы такая фигня никогда ни у кого не повторялась.

Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

Первое серьезное знакомство с этим принципом состоялось для меня в начале первого курса, когда молодых и зеленых нас вывезли в лес, чтобы сделать из личинок студентов — студентов настоящих.

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

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.

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