Я чёртовы сутки просидел над таской. Нужно было спроектировать самостоятельный модуль, а людям с тяжелой формой перфекционизма нельзя давать задачи на проектирование.

У меня была неделя — целая бесконечность, которой мне не хватило. Снова и снова я перебирал в голове варианты использования того, что должен сделать, но картинка идеального модуля не клеилась. Всегда находился кейс, который хорошо показывал: такой дизайн — говно. Я думал, играл на гитаре, пробовал писать, тупил в монитор, гуглил, играл с детьми, снова думал — голова всегда была занята дурацким модулем.

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

В понедельник утром я отправил пулл реквест. Его приняли с восторгом. Но способ, на который я пошел… вот уж никогда не думал, что отважусь на такое.

Вместо предисловия

В моей недавней статье Lazarus — пишем компонент для анимации спрайтов я описал процесс создания простого компонента TImageFragment, позволяющего отображать заданный фрагмент изображения.

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

При таком подходе отдельные кадры анимации в разных проекциях размещаются на одном изображении, а компонент для отображения спрайта показывает только один выбранный фрагмент этого изображения, используя свойства OffsetX и OffsetY (смещение левого верхнего угла фрагмента изображения по горизонтали и по вертикали).

Множество таких готовых изображений можно найти в Сети — например, вот на этом сайте.

Вместо предисловия

В одесской школе ученики 8-го класса на уроках информатики используют бесплатную кроссплатформенную среду разработки Lazarus (официальный сайт), внешне и внутренне очень напоминающую любимый многими Delphi, использующую версию Object Pascal под названием Free Pascal и в действительности сильно упрощающую процесс вхождения в программирование.

Но детям неинтересно писать программу для вычисления силы тяжести по непонятной им пока формуле F=mg. Практически все дети, которых я пытался учить программированию, с первого занятия хотят написать игру. К счастью, Lazarus прекрасно подходит и для написания несложных игр.

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

Перед вами перевод статьи Adrian Hajdin, которая была опубликована на сайте freeCodeCamp. Под катом автор понятно и лаконично объясняет, в чем преимущество async/await, и на конкретном примере показывает, как использовать этот синтаксис.

Согласитесь, приятно и полезно, когда в проекте исходный код выглядит красиво и единообразно. Это облегчает его понимание и поддержку. Покажем и расскажем, как реализовать форматирование исходного кода при помощи 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.


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

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

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