Так вот я и пытаюсь понять в чем отличие. Без этого понимания я и статью не понимаю — это же ключевой объект статьи.
Смотрите, что такое "цифровая экономика" я могу понять. Мне, правда, всё равно кажется что это buzzword, но термин понятен. Есть целая программа правительства и там есть определение цифровой экономики "в которой данные в цифровом виде будут являться ключевым фактором производства во всех сферах социально-экономической деятельности" — меня устраивает это определение в том смысле, что я его понимаю и по нему могу отличить цифровую экономику от "доцифровой".
А с инженерами не могу понять. Есть в статье примеры в части "Что надо и что есть" какие-то оторванные от реальности. Инженеры не работающие преимущественно с "данными в цифровом виде" фактически окончательно вымерли, как динозавры, примерно четверть века назад. Я с трудом могу представить себе инженера не обвешанного цифровыми данными. Ну разве что "инженер-агроном", "инженер по охране труда" и "инженерные войска" могу придумать-вспомнить. Так что на мой взгляд почти все существующие инженеры уже "цифровые". Качество подготовки в массе своей, правда, "является зоной потенциального роста", но это уже к уровню образования "вообще", а не конкретно инженеров.
Скажите, а чем в GitExtensions этот squash не нравится?
Комменты сам не собирает.
Вкладка консоли в GE есть, но в ней хоткеи смешаны от GE и bash, а когда запущено приложение, то еще и от приложения, часть приложений работает с глюками (tig в частности). Мне сильно проще отдельно запустить кривоватый git bash, который работает относительно предсказуемо.
На самом деле у каждого клиента еще куча своих "тараканов" и фич. У ST есть суперфича "обратить блок" (прямо в основном окне). Эта фича незаменима, если вам надо вручную пройти по >1K изменений и часть из них вернуть. Зато если надо работать с однобайтными кодировками — он пасует. TG может сделать reverse commit, cherry-pick, squash из окна просмотра истории (контекстное меню), но визуализация основного процесса (fetch-pull-add-commit-push) у него отвратительна (имхо) и неочевидна.
Тут спор "какой клиент лучше" по конструктивности примерно как "какие трусы лучше": кому какие удобны, тот те и использует.
Лично я про «лучше» ничего не утверждал (и не минусовал). По мне — каждому инструменту своя задача и TG я использую. А про эту «омонимику», когда все Tortoise существенно не похожи — не вы первый спотыкаетесь.
Спорить о клиентах git вообще неконструктивно. Они все — обёртка консоли, и если человек не понимает, что делает, то не понимает примерно одинаково, что в GUI, что в консоли.
Как-то сложилось, что под виндой я использую до 4 клиентов. Просто для разных задач.
Консоль.
"+" Максимальная гибкость, удобно работать в zsh.
"-" Неудобна для просмотра, а под виндой та консоль, то что идёт в поставке (mingw) работает слегка "инородно".
SourceTree
"+" Хорошо для просмотра, неплохо для совсем простых действий, фоновый фетч, если нужно. HG из коробки
"-" Функциональность слабая, шаг вправо, шаг влево и "не шмогла". Спорное лицензирование, странное тяжёлое поведение, неспешность развития.
Клиент в IDE.
"+" Рядом.
"-" Недостаточно функциональный (что в VS, что в IDEA), не очень удобно работать, когда репозиторий содержит несколько проектов (особенно разноязычных)
TortoiseGit или (на работе одно, дома другое)
"+" функционал примерно посередине между консолью и SourceTree. Кажется это единственный клиент, который умеет понятно и удобно squash-ить
"-" Дурацкий интерфейс
GitExtensions использую как замену SourceTree под Linux.
Правила, которые сами выработались:
В IDE не делать пушей. Ни в какую ветку. Зато коммитить чуть реже, чем сохранять :)
Push делать в клиенте-обозревателе (GE, ST). Это чтобы осмотреться и оценить перед отправкой.
Консоль использовать для повторяющихся команд, или автоматизации, или как убер-ковырялку, или для сложных команд. Под zsh, впрочем, использую очень активно.
TG только для Revision Graph (там он другой, для реп с ветвистой историей удобный) и для squash.
Любой клиент только обёртка над консолью и всегда надо понимать что выполняет клиент (благо они все, кажется, пишут точную команду)
Ну собственно в GE не хватает revision graph (свернутого) и удобного squash. Плюс я не помню есть ли там удобный cherry pick, кажется нет.
И еще сильно напрягли рекомендации в стиле "делайте всё правильно", например:
"Правильно задавайте уровень изоляции при работе с БД" — ахаха, 80% корпоративных БД на nolock до сих пор сидят, а из разработчиков, хорошо, если 20% могут осмысленно уровни изоляции обсуждать
"используйте разумно хинты к запросам" — тоже прекрасно. Степени разумности, которые я видел — от "нельзя ничего" до "указать индекс для каждой таблицы".
Вот читаю я эту статью и вижу, что написано человеком знающим и опытным — без иронии, действительно знающим и опытным. Но. Но ваши рекомендации опоздали лет на 8-10 — не для какого-то конкретного читателя опоздали, а в принципе опоздали. И по объёмам данных опоздали, и по конкретным приёмам опоздали.
Мне уже надоело переучивать DBA и разработчиков, начитавшихся "советов в энторнетах", подобных данной статье. Проблема не в советах, конечно же а в том, что их применяют не включая мозг. Эти статьи смешиваются, превращаются в опасные мифы и заблуждения.
Вот просто для иллюстрации, совет "сначала выберите удаляемые/изменяемые данные во временную таблицу". Совет для некоторых конкретных случаев весьма дельный. Но на самом деле часто это очень вредный совет:
Не сильно заботясь воткнули stop-and-go.
Потеребили tempdb
Всё сложили в таблицу без индексов (кстати и в вашем примере), а если таких таблиц 10-20, то что потом в соединении?
А если и создали, то воспроизводимость планов с индексами и таблицами в tempdb и их диагностика мягко говоря слабее, чем с продуманными постоянными
И при создании/удалении временных таблиц можно легко нарваться на узкое место в виде перекомпиляции запросов.
Не бывает универсальных (или "вечных") рекомендаций. Рекомендации нужно применять либо как архитектурные принципы ("знаем, что есть исключения, но делаем так пока нет явных причин так не делать"), либо только после диагностики. А вот про диагностику у вас вообще почти ничего нет. Я не про ту диагностику где "индекс давно не используется", а про "что является узким местом данной системы и чем это обусловлено". Ну хоть бы sys.dm_os_wait_stats упомянули. А в идеале, чтобы велосипеды не изобретать, можно и тулзы Брента Озара упомянуть. Кстати, на его основном сайте очень много интересной, полезной и более актуальной информации о производительности MS SQL
Капитан Очевидность тут рядом подсказывает: Мало замечают, потому что больше рулят не байты в секунду, а задержки. Понятно, что если задержки с 10-100 мс (HDD) падают до 0,5-2 (нормальный SSD), то это заметно. А дальше уже только в экстремальных случаях.
На самом деле в энтерпрайзе до "не замечают" еще очень далеко, но "внезапно" узкими местами становится то, что казалось мгновенным.
Из тех обзоров и тестов, что я видел (phoronix, thg, если я не ошибся в ссылках), ключевое преимущество в том, скорости на небольших блоках и глубине очереди 1-2 не зависят от кеширований накопителя и очень-очень достойные, сравнимы со скоростью записи в кеш на SSD. Это на самом деле очень важное достижение для некоторых профилей OLTP-нагрузки. Это тот самый профиль, который СУБД "ненавидит". Сейчас эта проблема на крупных и дорогих СХД более-менее решена огромными (относительно) объёмами кеширования и бесперебойным питанием этой памяти, фактически, чтобы write through(который используется во всяких write ahead log и transaction log) работал как write-back.
Отчасти эту же проблему пытаются решить всевозможные in-memory OLTP (но там, правда, еще парочку жирных коряг убирают).
И современные СХД, и современные enterprise СУБД — всё это вообще никак не дёшево. Если Optane позволит не покупать пару лицух СУБД, или позволит сэкономить на хранилищах, или позволит не переписывать еще пару лет legacy-приложение, то он очень быстро войдёт в датацентры.
И, да, производителю SSD для домашнего пользователя сейчас (и в обозримой перспективе) проще поставить лишний dram-кэш, который сгладит все эти Q1-Q2 доступы.
PS: тоже обратил внимание, что для корпоративного блога очень корректная статья.
Советовать статью на мисте 2005 года про 1С 8.0 с совершенно другой архитектурой (COM+) и давно вылеченными детскими болячками платформы я бы уже не стал. А впрочем и статью ИТС года примерно 2006 тоже бы постеснялся.
Кроме администраторов кластера есть роль "Администратор центрального сервера" или как-то так. Если этот список не задан, то подняв "фальшивый" кластер в локальной сети я легко и непринужденно подниму рабочий процесс на вашем сервере. Причем до 8.2.13 там была "особенность", что любой кластер мог у любого сервера попросить поднять процесс. С версии 8.2.13:
"Для рабочего сервера кластера, не являющегося центральным, в котором имеется не пустой список администраторов центрального сервера, в списке администраторов должен присутствовать администратор, у которого определена аутентификация ОС пользователя, от имени которого запущен "ragent" центрального сервера кластера или должен присутствовать администратор с именем и паролем, совпадающими с именем и паролем одного из администраторов центрального сервера кластера. "
Пароль логина SQL в 1CV8Reg.lst не захеширован. Он обратимо зашифрован (и алгоритм расшифровки пробегал то ли на мисте, то ли в инфостарте, короче есть в паблике). И я даже не буду подбирать и расшифровывать пароль sa. Я просто скопирую эту строчку в свой 1CV8Reg.lst. Раньше по крайней мере работало. Да, в 1С можно использовать и виндовую авторизацию MS SQL — если база одна, то вполне годный вариант, потому что пароль не светится. Если баз несколько, то их разделение надо будет делать (поднимать несколько служб сервера предприятия)
Если у логина SQL, который использует сервер предприятия только public и db_owner, то сервер не сможет видеть и убивать соединения. Как правильно сказали выше — приходится давать processadmin
Для ограничения того, что можно запускать из серверных процедур по идее задумывался "Сервер предприятия КОРП" с профилями безопасности. Взлетело или нет — честно говоря просто не знаю.
"запросто выгрузит базу в .DT", ага, незаметно выгонит пользователей, незаметно остановит работу на несколько часов. Проблема с лишними правами в том, что правильно настроить роли и разбираться с пользователями реально долго и дорого и команду "эй, ты, дай наконец права менеджерам по продажам, чтобы они работали" даёт руководство. Так что имеет смысл сначала идти с разработчиком к руководству и согласовывать бюджет.
Так вот я и пытаюсь понять в чем отличие. Без этого понимания я и статью не понимаю — это же ключевой объект статьи.
Смотрите, что такое "цифровая экономика" я могу понять. Мне, правда, всё равно кажется что это buzzword, но термин понятен. Есть целая программа правительства и там есть определение цифровой экономики "в которой данные в цифровом виде будут являться ключевым фактором производства во всех сферах социально-экономической деятельности" — меня устраивает это определение в том смысле, что я его понимаю и по нему могу отличить цифровую экономику от "доцифровой".
А с инженерами не могу понять. Есть в статье примеры в части "Что надо и что есть" какие-то оторванные от реальности. Инженеры не работающие преимущественно с "данными в цифровом виде" фактически окончательно вымерли, как динозавры, примерно четверть века назад. Я с трудом могу представить себе инженера не обвешанного цифровыми данными. Ну разве что "инженер-агроном", "инженер по охране труда" и "инженерные войска" могу придумать-вспомнить. Так что на мой взгляд почти все существующие инженеры уже "цифровые". Качество подготовки в массе своей, правда, "является зоной потенциального роста", но это уже к уровню образования "вообще", а не конкретно инженеров.
А можно чуть конкретнее?
А чем отличается цифровой инженер от… от… Э… от аналогового, что ли?
Я один, кто не понимает как связаны download.com и download.CNET.com ?
Комменты сам не собирает.
Вкладка консоли в GE есть, но в ней хоткеи смешаны от GE и bash, а когда запущено приложение, то еще и от приложения, часть приложений работает с глюками (tig в частности). Мне сильно проще отдельно запустить кривоватый git bash, который работает относительно предсказуемо.
На самом деле у каждого клиента еще куча своих "тараканов" и фич. У ST есть суперфича "обратить блок" (прямо в основном окне). Эта фича незаменима, если вам надо вручную пройти по >1K изменений и часть из них вернуть. Зато если надо работать с однобайтными кодировками — он пасует. TG может сделать reverse commit, cherry-pick, squash из окна просмотра истории (контекстное меню), но визуализация основного процесса (fetch-pull-add-commit-push) у него отвратительна (имхо) и неочевидна.
Тут спор "какой клиент лучше" по конструктивности примерно как "какие трусы лучше": кому какие удобны, тот те и использует.
Спорить о клиентах git вообще неконструктивно. Они все — обёртка консоли, и если человек не понимает, что делает, то не понимает примерно одинаково, что в GUI, что в консоли.
Как-то сложилось, что под виндой я использую до 4 клиентов. Просто для разных задач.
"+" Максимальная гибкость, удобно работать в zsh.
"-" Неудобна для просмотра, а под виндой та консоль, то что идёт в поставке (mingw) работает слегка "инородно".
"+" Хорошо для просмотра, неплохо для совсем простых действий, фоновый фетч, если нужно. HG из коробки
"-" Функциональность слабая, шаг вправо, шаг влево и "не шмогла". Спорное лицензирование, странное тяжёлое поведение, неспешность развития.
"+" Рядом.
"-" Недостаточно функциональный (что в VS, что в IDEA), не очень удобно работать, когда репозиторий содержит несколько проектов (особенно разноязычных)
"+" функционал примерно посередине между консолью и SourceTree. Кажется это единственный клиент, который умеет понятно и удобно squash-ить
"-" Дурацкий интерфейс
Правила, которые сами выработались:
Ну собственно в GE не хватает revision graph (свернутого) и удобного squash. Плюс я не помню есть ли там удобный cherry pick, кажется нет.
TortoiseSVN, TortoiseGit и TortoiseHg похожи только черепашкой на логотипе.
Сколько не кручу гит, никогда одним клиентом не могу обойтись.
А вообще — обзор очень хороший.
И еще сильно напрягли рекомендации в стиле "делайте всё правильно", например:
Вот читаю я эту статью и вижу, что написано человеком знающим и опытным — без иронии, действительно знающим и опытным. Но. Но ваши рекомендации опоздали лет на 8-10 — не для какого-то конкретного читателя опоздали, а в принципе опоздали. И по объёмам данных опоздали, и по конкретным приёмам опоздали.
Мне уже надоело переучивать DBA и разработчиков, начитавшихся "советов в энторнетах", подобных данной статье. Проблема не в советах, конечно же а в том, что их применяют не включая мозг. Эти статьи смешиваются, превращаются в опасные мифы и заблуждения.
Вот просто для иллюстрации, совет "сначала выберите удаляемые/изменяемые данные во временную таблицу". Совет для некоторых конкретных случаев весьма дельный. Но на самом деле часто это очень вредный совет:
Не бывает универсальных (или "вечных") рекомендаций. Рекомендации нужно применять либо как архитектурные принципы ("знаем, что есть исключения, но делаем так пока нет явных причин так не делать"), либо только после диагностики. А вот про диагностику у вас вообще почти ничего нет. Я не про ту диагностику где "индекс давно не используется", а про "что является узким местом данной системы и чем это обусловлено". Ну хоть бы
sys.dm_os_wait_statsупомянули. А в идеале, чтобы велосипеды не изобретать, можно и тулзы Брента Озара упомянуть. Кстати, на его основном сайте очень много интересной, полезной и более актуальной информации о производительности MS SQLКапитан Очевидность тут рядом подсказывает: Мало замечают, потому что больше рулят не байты в секунду, а задержки. Понятно, что если задержки с 10-100 мс (HDD) падают до 0,5-2 (нормальный SSD), то это заметно. А дальше уже только в экстремальных случаях.
На самом деле в энтерпрайзе до "не замечают" еще очень далеко, но "внезапно" узкими местами становится то, что казалось мгновенным.
Согласен, эти мелкие "оптаны" вышли непоймизачем:
PS: ссылку на phoronix я случайно не ту вставил.
Из тех обзоров и тестов, что я видел (phoronix, thg, если я не ошибся в ссылках), ключевое преимущество в том, скорости на небольших блоках и глубине очереди 1-2 не зависят от кеширований накопителя и очень-очень достойные, сравнимы со скоростью записи в кеш на SSD. Это на самом деле очень важное достижение для некоторых профилей OLTP-нагрузки. Это тот самый профиль, который СУБД "ненавидит". Сейчас эта проблема на крупных и дорогих СХД более-менее решена огромными (относительно) объёмами кеширования и бесперебойным питанием этой памяти, фактически, чтобы write through(который используется во всяких write ahead log и transaction log) работал как write-back.
Отчасти эту же проблему пытаются решить всевозможные in-memory OLTP (но там, правда, еще парочку жирных коряг убирают).
И современные СХД, и современные enterprise СУБД — всё это вообще никак не дёшево. Если Optane позволит не покупать пару лицух СУБД, или позволит сэкономить на хранилищах, или позволит не переписывать еще пару лет legacy-приложение, то он очень быстро войдёт в датацентры.
И, да, производителю SSD для домашнего пользователя сейчас (и в обозримой перспективе) проще поставить лишний dram-кэш, который сгладит все эти Q1-Q2 доступы.
PS: тоже обратил внимание, что для корпоративного блога очень корректная статья.
Вспомнился рассказ по теме Ираклий Андроников. Первый раз на эстраде.
Лет 10 уже
Я не говорю, что невозможно. Просто это слишком "палевно".
publicиdb_owner, то сервер не сможет видеть и убивать соединения. Как правильно сказали выше — приходится даватьprocessadmin