Привет! Представляю вашему вниманию перевод статьи «Learn responsive web design in 5 minutes» автора Per.
В этой статье я научу вас многим приёмам отзывчивого дизайна за 5 минут. Этого, очевидно, недостаточно для правильного изучения, но здесь вы найдёте обзор на следующие наиболее важные методы:
Привет!
Предлагаю вашему вниманию перевод статьи "Too Clean?" автора Robert C. Martin (Uncle Bob).
Я только что посмотрел выступление Сары Мэй: Жизнеспособный код. Это было очень хорошо. Я полностью согласен с основными моментами ее выступления. С другой стороны, темой ее выступления было то, что я раньше должным образом не рассматривал.
Читать полностью »
Начало шаблона для быстрого заземления PHP-разработчиков в Go
15 лет мы делали бэкенд на PHP. И вот однажды было принято стратегическое решение: сначала переписать самые высоконагруженные места на Go, а потом разрабатывать новые сервисы на нём.
Представьте: вы хотите рассказать про новый язык команде из 40 разработчиков, которые настолько хорошо готовят PHP, что собрали на нём многопоточную систему реального времени и высокой доступности. В худшем случае вас сожгут, в лучшем — прислушаются, но продолжат делать как раньше. Это если вводить язык насильно.
Поэтому мы решили сначала устроить хакатон, а потом позвать на тёмную сторону всех желающих. Если бы их набралось хотя бы человек десять, то со временем они показали бы всем остальным личным примером, как это круто.
Расскажу по шагам, как повторить такой опыт у вас. И про результаты нашего внедрения. И про то, что случается в голове у PHP-разработчика при виде нового языка.
Мы начали с подготовки шаблона и CI/CD, который позволяет задеплоиться за 15 секунд. Чтобы его написать самому, нужно где-то недели две. Мы сделали его заранее.Читать полностью »
Иногда бывает так:
— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.
И мы едем. Ночью. На другой край страны.
Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа
Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.Читать полностью »
Перед вами перевод статьи из блога Better Programming на сайте Medium. В ней программист Daan делится простыми правилами, следуя которым вы сможете давать хорошие имена функциям и переменным.
Будучи разработчиком, вы наверняка тратите много времени на создание переменных и придумывание их имен. Имена повсюду: они нужны для файлов, классов, методов и тех самых переменных.
Так как мы проводим столько времени присваивая имена, очень важно делать это качественно. В данной статье я расскажу вам о нескольких простых правилах, следуя которым вы сможете создавать хорошие имена. Ведь это целое искусство!
Читать полностью »
Аксель Ритчин (Axel Rietschin), инженер ядра в Microsoft, обвинил создателей ReactOS, открытой операционной системы, совместимой с Windows, в копировании кода Windows Research Kernel.
Этот продукт содержит исходные коды основной части ядра Windows (NTOS), которое реализует базовые функции ОС для процессов, потоков, реестра, виртуальной памяти и менеджеров кэшей, исполнительных функций, менеджера объекта и т.п.
Читать полностью »
Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.
Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Читать полностью »
На ваш суд скорее статья-вопрос, статья-рассуждение и местами — недоумение. С одной стороны нам презентовали авторитетное мнение Лесли Лэмпорта "Programing Should Be More Than Coding", расставляющее программирование и кодирование в импровизированном табеле о рангах. С оппонирующей стороны — я, не обладающий статусом достаточным для споров с мэтром и легендарным ВУЗом, который он представляет… но отказать себе в таком удовольствии и риске я не могу. Надеюсь, более опытные товарищи поправят мои огрехи в рассуждениях.
Умом я понимаю, что кодирование в современном мире принято воспринимать как низшую ступень инженерной деятельности, которая на эволюционном графике скорее ближе к шимпанзе, чем к программисту. И, возможно, в этом кроется наша большая ошибка, поскольку код — он как ДНК. Всего четыре нуклеотида, а какая пёстрая биомасса в продуктовой линейке.
Как опытные инженеры, мы — мастера абстракций. Поэтому для нас не составит труда представить условного программиста по имени Лесли Лэмпорт (все имена и совпадения не случайны) и его основной инструмент — машину Тьюринга. Он — мастер своего дела, во многом благодаря железному дао:
Предисловие переводчика: Прочитав эту статью, вы, возможно, удивитесь или даже разозлитесь. Да, мы тоже удивились: автор будто бы никогда не слышал про иерархию в команде, про постановку задач со статусом «сделать быстро и без рассуждений». Да, всё так, это немного странный текст. Действительно, автор предлагает программисту взять на себя роль системного архитектора — а зачем тогда нужен архитектор? Но все эти возражения не должны закрывать от вас главного — того, почему мы всё же взяли и перевели этот текст. Он ведь не про роли. Этот текст — про профессиональный подход и осознанность. Правда в том, что, пока вы просто «делаете что скажут», не задумываясь о смысле своих действий, вы никогда не станете большим программистом.
Сказать «нет» лишнему коду. Все, что вы должны сделать, — собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»
Но погодите. Зачем мы это делаем? Ведь основная задача программиста — писать код. Но нужно ли писать любой код, который от вас требуют? Нет! «Понимание того, когда не стоит писать код, вероятно, важнейший скилл для программиста». The Art Of Readable Code.
Читать полностью »
(швед. arkitektur)
Дамы и господа, представляю вашему вниманию arkit — инструмент, который анализирует файлы вашего проекта и генерирует диаграмму зависимостей между ними и внешними модулями. Наверное, проще показать на примере самого arkit:
