Кто ж блокировками заставляет пользователя заниматься? Пользователю снаружи виден метод, а его реализация уже делает все необходимые блокировки. И если она это делает, то делает lock() и defer unlock(). Сразу. Рядом. Без шансов забыть unlock. Об этом речь идёт.
defer unlock даёт те же гарантии, что и lock_guard — при выходе из функции (любом, даже через panic) мьютекс освободится. Я бы сказал, что defer — это оригинальная идея, которая позволяет избежать использования guard'ов и предоставить аналогичную функциональность вообще для любых объектов. Открыли соединение — defer закрыть. Получили блокировку — defer отпустить. Для случаев с более сложной логикой лучше не танцевать с мьютексами, см. статью.
1. Каналы хитрые. Некоторые операции делаются с оптимистичными блокировками, некоторые чисто на мьютексах.
2. Каналы нужно использовать по-другому. Это не слепая замена мьютексам. Надо на каждый разделяемый ресурс запускать отдельную горутину, которой присылать команды на изменение данных и запросы на чтение. Эта горутина просто исполняет все, о чем её просят, гарантированно последовательно.
По сути ваших примеров кода — аналог мьютекса так можно сделать. За исключением всяких крайних случаев типа двойного вызова Unlock.
1. godoc со специальным ключиком сгенерирует документацию по коду, которая по каждому интерфейсу напишет список реализующих его типов. С блекджеком и гиперссылками.
2. Сериализацию можно или делать из коробки, дописывая аннотации к полям структур, как они должны называться на вводе-выводе, а потом используя стандартные пакеты encoding/json, encoding/xml, или использовать protobuf со своими плюсами и минусами. Это что часто используется.
Статья могла бы быть лучше, если была бы дополнена глоссарием — что такое DWH, EBL, BI, SAS и т.д. Гугление даёт слишком много неоднозначных вариантов. В результате, мне например вообще не понятно, какие задачи решаются. Хотя, возможно, статья и рассчитана только на тех, кто знает, что это.
2. И поэтому тоже. И ещё потому что менеджеры могут помочь зарабатывать больше за счёт своих умений организовать работу. Поэтому мы, программисты, согласны делиться с ними деньгами с продажи наших продуктов и услуг. Возомнившие себя царьками директора могут продолжать искать себе сотрудников, которых эти условия устраивают.
PS. Стараюсь писать комментарии без употребления слова «засунуть».
1. Попробуйте мысленно уберите всех программистов и посмотрите, сколько заработает компания. Почему 0, объяснять, наверное не надо. Попробуйте мысленно уберите весь менеджмент и посмотрите, сколько заработает компания теперь. Явно меньше, явно не за всякий проект можно взяться без «внешней» координации усилий, но больше нуля. Это разница в бесконечное число раз. Компании из одних программистов существуют. Компании из одних менеджеров — нет. Я не говорю, что менеджмент не нужен совсем, что он не приносит добавочную стоимость, но это вспомогательная роль, которая может увеличить эффективность программистов, но сама по себе денег не приносит.
2. Потому что интереснее заниматься чисто техникой, а не управлением?
Уважаемому директору я бы предложил хорошо подумать о своём отношении к другим людям. В отличие от программистов, вы не генерируете прибыль организации. Вы — вспомогательный компонент, который помогает программистам и дизайнерам делать продукт, обеспечивает им условия работы, чтобы они могли эффективно решить задачу. Идеальный руководитель должен быть не заметен для сотрудников. Я тоже руководил компанией, и убедился, что большинство образованных людей достаточно порядочны и ответственны, чтобы хорошо делать свою работу без психологического насилия над ними. Я сейчас не говорю про менеджеров и водителей — там может быть другая история. Но то, что вы распоряжаетесь инженерами, как своими собаками, говорит о том, что вы больше заражены властью, чем умением организовать работу компании. Извините, если слишком резко получилось.
Когда не знаешь ещё, в какую сторону будет развиваться технология, придумать правильный стандарт, правильный API очень сложно. Удачная абстракция быстро стала популярной, стала обрастать фичами, не вписывающимися в первоначальный дизайн, и вот результат. Своего рода проклятие первопроходцев.
Позволю не согласиться. Везде, где присутствует ручная работа, возможны ошибки. Это аксиома.
Чем больше граблей разложено в системе, тем больше шанс получить по голове. Вероятность не наступить ни на одни грабли падает в геометрической прогрессии с ростом числа граблей и числа прохожих (сотрудников). Если один человек наступает на одни грабли с вероятностью 0.01% в год, то хотя бы один из 100 человек наступят хотя бы раз на одни из 100 граблей — 1-(0.9999^100)^100 = 63% (упс!)
Проблемы необходимо устранять системно — раз и навсегда, чтобы не оставлять ошибкам ни единого шанса.
Это элементарная задача. Если это Open GL, то перехватывается вызов функций glDraw* (или ещё каких-нибудь, которые вызываются в главном цикле рендера), и подсовывается ещё один вызов «нарисовать линию». Закрывание объектов друг другом делается на уровне буфера глубины (обычно это работа 3D-ускорителя), и просто отдать команду на рисование линии достаточно, чтобы получить эффект, который вы описываете. Если это DirectX, то тоже что-то аналогичное должно быть (я с ним никогда не работал).
Да это понятно. Просто обе проблемы, которые вы описали, можно решить полностью автоматически, без человеческого фактора, без риска чего-нибудь упустить.
А не проще хранить каноническую схему базы данных в репозитарии вместе с кодом, а при выкатке новой версии запускать синхронизатор схемы, который вычислит разницу между канонической схемой и реальной, и выдаст (или автоматически выполнит) нужные SQL-операторы, чтобы привести базу к нужному состоянию?
У меня на военной кафедре случай был. Крысы под фальшполом сожрали все кабели, которые через стену проходили (толстый пучок, весь в ошметки), кроме одного — который вёл к компьютеру начальника кафедры. Знают мерзавки субординацию!
Выпускают, но не для стандарта GSM. Я знаю, что TETRA может работать как в режиме с базовыми станциями, так и в режиме Direct Mode Operation, когда абоненты напрямую друг с другом могут соединяются в зоне прямой досягаемости.
Не претендуя на энциклопедическую точность определения, я бы сказал, что Big data — это данные, которые невозможно эффективно обработать на одном компьютере.
Как только задачу надо распараллеливать, возникает необходимость в целом классе технических приёмов. Никакой магии там нет.
2. Каналы нужно использовать по-другому. Это не слепая замена мьютексам. Надо на каждый разделяемый ресурс запускать отдельную горутину, которой присылать команды на изменение данных и запросы на чтение. Эта горутина просто исполняет все, о чем её просят, гарантированно последовательно.
По сути ваших примеров кода — аналог мьютекса так можно сделать. За исключением всяких крайних случаев типа двойного вызова Unlock.
2. Сериализацию можно или делать из коробки, дописывая аннотации к полям структур, как они должны называться на вводе-выводе, а потом используя стандартные пакеты encoding/json, encoding/xml, или использовать protobuf со своими плюсами и минусами. Это что часто используется.
2. И поэтому тоже. И ещё потому что менеджеры могут помочь зарабатывать больше за счёт своих умений организовать работу. Поэтому мы, программисты, согласны делиться с ними деньгами с продажи наших продуктов и услуг. Возомнившие себя царьками директора могут продолжать искать себе сотрудников, которых эти условия устраивают.
PS. Стараюсь писать комментарии без употребления слова «засунуть».
2. Потому что интереснее заниматься чисто техникой, а не управлением?
Чем больше граблей разложено в системе, тем больше шанс получить по голове. Вероятность не наступить ни на одни грабли падает в геометрической прогрессии с ростом числа граблей и числа прохожих (сотрудников). Если один человек наступает на одни грабли с вероятностью 0.01% в год, то хотя бы один из 100 человек наступят хотя бы раз на одни из 100 граблей — 1-(0.9999^100)^100 = 63% (упс!)
Проблемы необходимо устранять системно — раз и навсегда, чтобы не оставлять ошибкам ни единого шанса.
Как только задачу надо распараллеливать, возникает необходимость в целом классе технических приёмов. Никакой магии там нет.