Да, в целом как вариант. Но я сейчас преимущественно пишу на python, поэтому обозначенная проблема отпадает сама собой.

Работал в одной компании, где code conventions предусматривали смешанное использование пробелов и табов. Долго воевал за пробелы, но аргумент от тимлида был — у каждого свои настройки табов, которые ему удобны, и мы должны уважить каждого. Достаточно сложно было контролировать правильную расстановку, но ничего не ехало. Но я все-таки предпочитаю пробелы, так как создавать самому себе лишние сложности в виде контроля расстановки табов и пробелов вместо сосредоточения на написании кода как такового — такое себе занятие.

<tab>int class_with_long_name::method_with_long_name(type1 param1, type2 param2,
<tab>                                                type3 param3, type4 param4)

Удобство разработчика это совершенно 10 дело. Первое, и единственно значимое, удобство пользователя. И когда разработчики перестанут об этом забывать, тогда и будет более качественное и функциональное ПО, а не 100500 слоёв красивых абстракций, которые тормозят на флагманском аппарате, на ровном месте. =)

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

Очень интересно будет посмотреть, как робот с ИИ будет общаться с 3-5 летним ребенком, у которого 100 «почему?» возникают в минуту. Как бы в процессе не исчерпались ресурсы :-)

Создадим тестовую таблицу с полем типа INT и одним миллионом записей:

postgres=# INSERT INTO test SELECT generate_series(1,100000000);

По-моему, там чутка больше миллиона.

Кстати, сейчас minidlna ставится из репозиториев прекрасно через apt-get и замечательно работает! Спасибо большое за статью! Поставил в виртуалбокс нативное приложение LG Smartshare — телевизор его не видит. С minidlna все заработало; линукс рулит :-)

Да понятно, но вопрос мой немного не об этом был.

1. Ну вот не хотят они уделять время для ревью, приходится по 5 раз тыкать палкой :)
2. Код заведомо соответствует PEP8. Под кодстайл, который может не понравится ревьюверу, я имею ввиду, например, названия переменных, внутренние соглашения компании и тд. Но при проверке их ревьюверы, как правило, уходят от сути задачи и упускают возможные ошибки в самом решении.

Пара вопросов по процессу разработки:
1) Как сделать так, чтобы коллеги достаточно быстро отсматривали ревью?
2) Как сделать так, чтобы коллеги сосредотачивались на том, насколько функционально правилен код, а не на code style? Так как, при отвлечении внимания на второе, очень высока вероятность пропустить проблемы в первом кейсе…

Второй READ COMMTITED
В данном случае прочитать данные возможно только после вызова COMMIT. При чем внутри транзакции данные тоже будут еще не доступны.

Пожалуйста, не вводите людей в заблуждение и исправьте текст статьи! Как говорил уважаемый StraNNikk, свои изменения всегда доступны внутри транзакции, до коммита.

Исправил. Прошу review.

Проявите снисходительность к новичку :) Я не думал, что есть смысл переводить этот псевдокод. Если попытаться представить его в другом формате — не будет ли это нарушением правил перевода? Если вы считаете, что перевод этих блоков улучшит статью — я буду только «за» сделать это.

Нет, конечно; это что-то вроде псевдокода. Если речь про то, что я указал язык «cpp» в хайлайтере — просто не удалось подобрать что-либо удобоваримое под эти блоки, а оставлять их совсем не расцвеченными не хотелось.