Согласитесь, приятно и полезно, когда в проекте исходный код выглядит красиво и единообразно. Это облегчает его понимание и поддержку. Покажем и расскажем, как реализовать форматирование исходного кода при помощи clang-format, git и sh.

«2048» через несколько недель исполняется 5 лет, а значит, пора написать что-нибудь, посвящённое этой замечательной игре.

Особенно познавательна тема самостоятельной игры искусственного интеллекта в головоломку. Способы реализации есть самые разные и сегодня разберём относительно лёгкий из них. А именно — научим компьютерный разум собирать степени двойки с помощью метода Монте-Карло.

YOLO

Позвольте поведать вам о совершенно новой методологии, которая радикально изменит ваши подходы в программировании. Итак, прервитесь ненадолго от своего стройного и прямолинейного кода и откройте для себя мир альтернативных IT-методологий.

Вообразите наше восхищение, когда манифест этой новаторской новой методологии попал в наши новостные ленты. Пророк YDD, она же YOLO Driven Development Todor Grudev высек в камне (на GitHub) 17 заповедей YDD. YOLO буквально означает — You Only Live Once, или по-русски: ВЖОР — Вы Живете Один Раз.

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

Уколы в адрес технологий разрабы воспринимают на свой счет. Культ инструмента — очень странная штука, которую не объяснить логически. Одни говорят, что культ есть у всех, потому что мышление плотно сплетается с япом. Другие говорят, это джунироская болезнь — ты впервые что-то написал, оно получилось, от восторга ты посчитал свой яп чудом божьим.

Чем бы оно ни было, я эту фигню не понимал никогда.

Сторонники культов кажутся мне непроходимыми тупицами. А я всегда пытаюсь понять, как тупицы стали тупицами, и почему тупицей не стал я. Начал думать и бам! — понял, что все-таки стал. Я тупица-культист, который восхваляет F#. И конечно за этим есть история.

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

Противоположность инкапсуляции — размазывание знаний о функционировании чего-либо по всей программе.

На протяжении нескольких лет я пробовал свои силы в разработке своего языка программирования. Мне хотелось создать на мой взгляд максимально простой, полнофункциональный и удобный язык.

В этой статье я хочу осветить основные этапы своей работы и для начала описать созданный концепт языка и его первую реализацию над которой сейчас работаю.

Во время очередного спора знакомый озвучил мысль, которая меня очень сильно задела. «В большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом. Поэтому их код легко читаем, предсказуем и надежен. И поэтому крупный бизнес выбирает Go». Это достаточно мощный аргумент, над которым нужно как следует поразмыслить, прежде чем опровергать.

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

В последнее время все чаще встречаются упоминания о некоем волшебном средстве — тестировании на основе свойств (property based testing, если надо погуглить англоязычную литературу). Большинство статей на эту тему рассказывают о том, какой это классный подход, затем на элементарном примере показывают как написать такой тест используя какой-то конкретный фреймворк, в лучшем случае подсказывают несколько часто встречающихся свойств, и… на этом все заканчивается. Дальше изумленный и воодушевленный читатель пытается применить все это на практике, и упирается в то, что свойства как-то не придумываются. И к большому сожалению часто на этом сдается. В этой статье я постараюсь расставить приоритеты немного по другому. Начну все-таки с более-менее конкретного примера, чтобы объяснить что это за зверь такой. Но пример, надеюсь, не совсем типичный для подобного рода статей. Затем попробую разобрать некоторые проблемы, связанные с этим подходом, и как их можно решить. А вот дальше — свойства, свойства и только свойства, с примерами куда их можно приткнуть. Интересно?

Представляем вам перевод статьи Nwose Lotannaс, которая была опубликована на blog.bitsrc.io. В ней подборки лучших фреймворков и информация, полезная как новичкам, так и опытным специалистам.

Очередной отчет от State of JS и наш прогноз на новый год уже здесь!

Давайте охватим взглядом удивительный путь развития, совершенный JavaScript в уходящем году и отраженный во мнениях более чем 20 тысяч веб-разработчиков со всего мира. Мы посмотрим, какие javascript-фреймворки для фронтенд-разработки, работы с данными и бэкенд-разработки были самыми востребованными, а также постараемся увидеть возможные будущие фавориты.


State of JS

В этой статье мы будем опираться на данные и выводы State of JS, а также на инсайты, которыми поделилась компания JetBrains в своем ежегодном отчете «Экосистема разработки» (The State of Developer Ecosystem).

Разные помощники в написании классного кода нас просто окружают, линтеры, тайпчекеры, утилиты для поиска уязвимостей, всё с нами. Мы привыкли и используем не вдаваясь в детали, как «черный ящик». Например, мало кто разбирается в принципах работы Pylint — одного из таких незаменимых инструментов для оптимизации и улучшения кода на Python.

А вот Максим Мазаев знает, насколько важно понимать свои инструменты, и нам рассказал на Moscow Python Conf++. На реальных примерах показал, как знание внутреннего устройства Pylint и его плагинов помогло уменьшить время code review, улучшить качество кода и вообще повысить эффективность разработки. Ниже расшифровка-инструкция.

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

Проекты краснодарской студии Plarium значительно отличаются друг от друга по используемому стеку технологий. Нам приходится решать разноплановые задачи и задействовать большое количество профессионалов. Программисты — важная часть команды Plarium Krasnodar. Всего над созданием кода в проектах студии трудятся свыше 50 наших коллег.

Мы проанализировали их опыт и готовы ответить на поступившие вопросы.

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

Предполагается, что читатель немного знаком с паттернами Active Record, Data Maper, Identity Map и Unit of Work.

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

Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.

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

Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта

Однажды в марте 2000 года шесть лучших инженеров Google собрались в импровизированном конференц-зале. Произошло ЧП: с октября 1999 года остановились краулеры. Хотя пользователям ещё выдавали поисковые результаты, но они устарели на пять месяцев. На карту было поставлено больше, чем предполагали инженеры. В данный момент Ларри Пейдж и Сергей Брин вели переговоры о поставке поиска Google на крупнейший в интернете портал Yahoo и обещали увеличить поисковый индекс в десять раз, чтобы идти в ногу со Всемирной паутиной, которая за предыдущий год удвоилась в размере. Если краулеры не починят, google.com застрянет в прошлом, сделка с Yahoo может провалиться, а компания рискует сжечь полученные инвестиции и кануть в небытие.

Привет, Хабр!

Говорить о чистом коде можно бесконечно, но следующая статья Дэйва Николетта очень метафорична и, надеемся, действительно достойна перевода. Пусть и немного «назидательна», о чем автор заранее преуведомляет читателей в оригинале статьи.

Приятного чтения.

Смотрел я тут на днях выступление Kate Gregory на конференции Pacific++ 2018.


Кейт — хороший программист и отличный спикер. Сам доклад поднимает много интересного о программировании на С++ и программировании вообще (стоит посмотреть). Но больше всего меня зацепила одна высказанная ею (буквально вскользь) мысль. Кейт удалось очень кратко и по делу обозначить мотивацию программистов. Звучала она так: «Программист во время работы стремится максимизировать своё счастье». Это звучит банально, но ведь так оно и есть.

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

Сразу хочу вынести за скобки вопросы оплаты труда, условий работы, начальства, коллектива и прочего. Если вы работаете там, где работаете — то всё это вас примерно устраивает. Давайте сфокусируемся на том, что делает нас счастливыми и несчастными при непосредственной работе над кодом.

Хабр, это доклад инженера-программиста Алексея Старкова на конференции Moscow Python Conf++ 2018 в Москве. Видео в конце поста.

Всем привет! Меня зовут Алексей Старков — это я, в свои лучшие годы, работаю на заводе.
Теперь я работаю в Qrator Labs. В основном, всю свою жизнь, я занимался C и C++ — люблю Александреску, «Банду Четырех», принципы SOLID — вот это всё. Что и делает меня архитектурным космонавтом. Последние пару лет пишу на Python, потому что мне это нравится.

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

Я тоже имею тенденции к архитектурной космонавтике, но в этом докладе я расскажу немного о том, как это меня укусило и не позволило построить систему с необходимой производительностью. Главное — как я это поборол.

Краткое содержание моего доклада: было / стало.

lintpack — это утилита для сборки линтеров (статических анализаторов), которые написаны с использованием предоставляемого API. На основе него сейчас переписывается знакомый некоторым статический анализатор go-critic.

Сегодня мы подробнее разберём что такое lintpack с точки зрения пользователя.

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

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