Недавно я написал о «Пять книг, которые изменили мой стиль программирования». В комментариях несколько читателей рекомендовали «Чистый код» Роберта С. Мартина. В результате я прочитал книгу и нашел ее достойной углубленного обзора.

…Даже простейшие инструменты могут давать людям возможность делать великие дела.
Биз Стоун, «Решайся! Заряд на создание великого от основателя Twitter»

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



Многие программисты используют в наши дни Visual Studio Code. Этот редактор кода поддерживает установку расширений. Существует столько подобных расширений, что можно говорить о том, что возможности настройки VS Code практически безграничны.

Но на Visual Studio Marketplace, на площадке, где публикуются расширения для VS Code, опубликовано просто невероятное количество расширений. А это значит, что программистам сложно находить именно то, что им действительно пригодится. Если некое расширение показалось кому-то полезным, то оно, вполне возможно, принесёт пользу и другим людям. Поэтому я расскажу здесь о 7 расширениях для VS Code, которые способны значительно облегчить работу программиста. Всё это — бесплатные расширения. Любой может свободно их загружать и использовать.

Изображение: Designmodo

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

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

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

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

Введение

В последнее время большинство новичков в программировании начинают с высокоуровневых языков, таких, как Java, Python, C#, или любой другой язык, содержащий в себе “джентльменский набор” в виде сборщика мусора, готовых структур данных и так далее. Конечно, такой подход имеет свои плюсы, но, как правило, начинающий разработчик, использующий готовый функционал языка, упускает самое главное – его устройство и механизмы работы и имплементации.

Ruby Digest 2020 с 16 по 31 июля: новинки, новости, медиа, релизы, статьи, обучение.
Смотрим, что интресного было во второй половине июля вокруг Ruby.

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

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

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

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

При любом сотрудничестве важно иметь хорошие инструменты для общения. Безусловно, они индивидуальны и зависят от вашей ситуации, но могут включать в себя рассылки для общения по электронной почте, Git или Subversion для управления версиями, Википедию или Etherpad для совместной работы, расшеренный список задач для организации рабочего процесса или даже полноценный пакет управления проектами.

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

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

Привет, хабр! Продолжаю делиться полезными подборками. Я уже публиковал посты с Github репозиторими (Часть 1 и Часть 2), а также подборку из 10 книг для разработчиков. Решил, не останавливаться:) Кому интересно — добро пожаловать под кат.

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

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



Традиционные решения предусматривают разные варианты «self join», когда выборка соединяется с собой же, либо использование некоторых фактов «за пределами данных» — например, что записи должны иметь строго определенный шаг (N+1, «за каждый день», ...).

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

Но эту задачу нам помогут эффективно решить оконные функции в PostgreSQL.

В течение всей истории разработки ПО мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

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

Здравствуйте, меня зовут Денис, я явлюсь разработчиком информационных систем, пишу статьи и документацию по СУБД Firebird. В этой статье я хочу рассказать о реализации производственного календаря с использованием СУБД Firebird.

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

Для разработки будем использовать Firebird 3.0, в нём был значительно расширены возможности PSQL по сравнению с предыдущими версиями. Все процедуры и функции для работы с календарём будут инкапсулированы в пакете DATE_UTILS.

Содержимое веб-страниц должно быть размещено в некоем элементе, ширина которого, ограничивающая ширину содержимого, позволяет пользователям удобно работать с материалами сайта. Такие элементы называют «обёртками» (wrapper) или «контейнерами» (container). Стилизовать контейнеры средствами CSS можно по-разному. Некоторые способы работы с контейнерами ставят дизайнера перед необходимостью решать достаточно сложные задачи.



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

Кейс компании Appbooster

Полагаю, практически каждый проект, использующий Ruby on Rails и Postgres в качестве основного вооружения на бэкенде находится в перманентной борьбе между скоростью разработки, читаемостью/поддерживаемостью кода и скоростью работы проекта в продакшене. Я расскажу о своем опыте балансирования между этими тремя китами в кейсе, где на входе страдали читаемость и скорость работы, а на выходе получилось сделать то, что до меня безуспешно пытались сделать несколько талантливых инженеров.

Из-за короновируса закрыты границы и непонятно, что с открытием будет, да и с деньгами могут быть сложности, а в отпуск хочется… Местами вещают о внутреннем туризме, а мне есть, что сказать по этому поводу!

Как-то раз я прокатился по России необычным способом, и хоть это было в 2015 году — идея остаётся актуальной.

Даже @Milfgard её одобрил! Собственно идея — в названии статьи, а подробности реализации — под катом.

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

Сегодня разберем пару примеров, как неудачная организация БД и кода могут превратить наше приложение в клубок проблем:

• накрутка serial при ON CONFLICT
• накрутка счетчика транзакций

Посвящается всем любителям анализировать логи.

В логах работающих систем рано или поздно появляются тексты каких-то ошибок. Чем таких систем больше в обозримом пространстве, тем больше вероятность ошибку увидеть. Серверы PostgreSQL, которые находятся под нашим мониторингом ежедневно генерируют от 300K до, в неудачный день, 12M записей об ошибках.

И такие ошибки — это не какой-то там «о, ужас!», а вполне нормальное поведение сложных алгоритмов с высокой степенью конкурентности вроде тех, о которых я рассказывал в статье про расчет себестоимости в СБИС — все эти deadlock, could not obtain lock on row in relation …, canceling statement due to lock timeout как следствие выставленных разработчиком statement/lock timeout.

Но есть ведь и другие виды ошибок — например, you don't own a lock of type ..., которая возникает при неправильном использовании рекомендательных блокировок и может очень быстро «закопать» ваш сервер, или, мало ли, кто-то периодически пытается «подобрать ключик» к нему, вызывая возникновение password authentication failed for user …

^{[источник КДПВ]}

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