Малварь положил файлы сервера в Белорусии который принадлежал НКО занимающейся расследованием нарушений прав человека и военных преступлений (в том числе и на Украине).
Это не просто нишевая штука, а какая-то очень нишевая) Тоесть реально пригодится, когда переписывание существующего VBA не рентабельно.. ну и не стоит забывать, что в случае чего стоимость поддержки тоже увеличивается.
Скорее всего утекло всё, но выложили отфильтрованное по номерам телефонов российских и белорусских операторов. Через некоторое время гарантированно сольют и остальное.
У меня один аккаунт 6 лет, регистрировался еще на почту, его нет в этой выгрузки, а второй - регистрировался уже на терефонный номер пару лет назад, и в сливе есть.
Где гарантия, что профиль удаляется? а не вешается флаг inactive/hide/deleted, и не копируется в исторические таблицы чтобы вернуть все если обкакаются?
Я вырос, когда Интернет был свободным от политики и цензуры.
Это было время полной анархии, потому что как средство массовой информации он еще не был интересен. Как только стало понятно, что интернет, это средство моментальной доставки информации до заинтерисованного читателя, то он для государств и заинтерисованных групп превратился в еще одно средство отстаивания своих интересов, или как я это называю, средство "искажения реальности" в свою пользу. Знаменитая фраза "кто владеет информацией, тот владеет миром", это уже аксиома. Достоверная или ложная, информация может быть оружием.. а его стараются держать под контролем. Я бы сказал, что это очевидная закономерность.
От себя добавлю привычку, которую я выработал на текущем месте, а именно один-два дополнительных символа в начале названия обьекта.
t_ -- это таблица
v_ -- это вью
m_ -- material view
tv_ -- таблица с результатом выполнения тяжелой вью
-- когда у вас нет технической возможности
-- или прав для создания material view
fn_ -- функция
p_ -- процедура
Преимущества по началу не очевидны, но так как мы как правило читаем слева на право, то начав читать название таблицы или вью, мы уже предполагаем что это за обьект, и в некоторых случаях догадываемся, как он формируется. Но соглашусь, не всем нравится.
В тексте очень много вкусовщины, да так что возникают вопросы почти к каждому из упомянутых пунктов. Поэтому побуду занудой и озвучу их все.
1. Слова должны быть разделены подчеркиванием Плохо wordcount или WordCount
Один из действительно полезных советов. Например ORACLE очень любит создавать регистрозависимые имена столбцов, и вы не сможете к ним обращаться иначе, чем MYTABLE."WordCount".
2. Типы данных не должны быть именами 8. Ищите зарезервированные слова
Классическая тавтология. По факту это одно правило "не использовать зарезервированные ключевые слова и названия функций и таблиц". Например если вы в ORACLE создадите тустую таблицу ALL_OBJECTS, то некоторые клиенты (например ADS) перестанут выдавать вам список обьектов в этой БД.
3. Имена атрибутов должны быть строчными
А может быть надо отталкиваться от предпочтений конкретной БД ? Как заметил @alexxisr ORACLE очень любит приводить названия к верхнему регистру. Более того, из моего опыта, если вы обращаетесь из MSSQL/TSQL через функционал OPENQUERY, то можете получить ошибку, если запрос будет написан нижнем регистре или camelCase форматировании.
4. Напишите полные слова 7. Используйте короткие имена таблиц
Вы либо крестик снимите, либо трусы наденьте. Пишите полные читаемые имена таблиц и столбцов, чтобы следующий забавный перснаж, который будет работать с ней не задавался вопросом "а что это за данные".
6. Избегайте наличия чисел в имени столбца
Неправильно сформулированный совет. Нужно было сформулировать как "Не назначайте имена столбцов которые отличаются только цифровыми постфиксами, если числа не имеют особого значения". К примеру address1 , address2 это действительно плохой пример, но region23, region16, region74 будут более приемлимыми, т.к. цифра явно является автомобильным кодом региона (опустим тут момент, что вообще создавать отдельный столбец для каждого такого примера - плохая идея, привел исключительно для примера).
Что гораздо важнее, оставляйте время для документирования и внесения комментариев к таблицам и столбцам. В случае генерирования DDL они также будут выгружены вместе со всей остальной информацией.
9. Сингулярные имена для таблиц
Множественное число в названии таблиц, это почти стандарт. Пенять на то, что вам придется написать два лишних символа в имери ключа реляции это просто смешно. Нормальным тоном является добавление соли в конец длинных имен, которые будут гарантированно обрезаны, и хранение полного имени в комментарии к ключу или таблице-словаре.
10. Таблицы ссылок должны иметь алфавитный порядок author_book, но не book_author
Я думаю, что это чистая ничем не подкрепленная вкусовщина.. но если вам как-то хочется иметь систему, то гораздо логичнее будет порядок source-target. Минус в том, что если вдруг кто-то перестанет соблюдать порядок, то можно начать путаться.
11. Имена столбцов в единственном числе
Если поле содержит информацию с разделителем, а обработка этих данных не предполагается (только для чтения), то почему бы и нет?
14. Не указывайте в конце имен столбцов типы хранимых в них данных
Как правило да.. но наиболее частое исключение, это добавление сокращенного названия типа к имени столбца содержащего дату. В этом случае массово используют суффикс _dt или _ts.
16. Имена столбцов типа даты Если у вашего имени столбца есть время, то суффикс их с _at или _time.
Такое ощущение, что автор не замарачивался с переводом фразы, или не отредактировал поток сознания. Потому что в целом совет дельный, но не читаемый.
Автор пришёл в разработку на PHP, где из-за низкого входного порога и большого количества "примеров" из сети, качество кода очень низкое.
На самом деле тут может быть любой язык с низким порогом вхождения: dotnet, js, python.. имхо особенно python, из-за большого количества низкокачественных курсов, развратной динамической типизации, отсутствию привычки создавать стабы.. и тд.
Я заметил, что все зависит от рода запрашиваемой информации. Если взять две немного разные задачи, например, поиск даташита на компанент и поиск информации по человеку, и протестировать в разных поисковых системах, то гугл лучше отработает техническую информацию, а тот же яндекс поиск по Васяну.
Тема достойна отдельного исследования) Но из личного (субьективного) опыта, запросы не всегда написаны оптимально, а COALESCE и CASE очень любят пихать всюду, как серебрянную пулю чтобы собрать один запрос который будет повеливать всеми лаконичнен и читаем. Поэтому, например, когда CASE сидит в переусложненных условиях join'ов, зачастую дешевле разобрать сложные условия свичей на запросы соединенные юнионом. Ну и насколько я помню, внутренний оптимизатор запросов очень даже рад видеть UNION ALL.
Краткое содержание
Малварь положил файлы сервера в Белорусии который принадлежал НКО занимающейся расследованием нарушений прав человека и военных преступлений (в том числе и на Украине).
Такой вот "френдлифайр")
ЮФО проводной и мобильный МТС - работает.
Это не просто нишевая штука, а какая-то очень нишевая) Тоесть реально пригодится, когда переписывание существующего VBA не рентабельно.. ну и не стоит забывать, что в случае чего стоимость поддержки тоже увеличивается.
В общем да, но тут ниже был срыв покровов, смысл которого в том, что автор один из типичных инфоцыган от IT.
Там три аккаунта начинающихся с Lexicon, один из них с мейловской почты
Так я этого и не говорил, под
Это качественная характеристика)имеется ввиду, что качество - это свойство реляции.и оператор теле2
Скорее всего утекло всё, но выложили отфильтрованное по номерам телефонов российских и белорусских операторов. Через некоторое время гарантированно сольют и остальное.
У меня один аккаунт 6 лет, регистрировался еще на почту, его нет в этой выгрузки, а второй - регистрировался уже на терефонный номер пару лет назад, и в сливе есть.
Где гарантия, что профиль удаляется? а не вешается флаг inactive/hide/deleted, и не копируется в исторические таблицы чтобы вернуть все если обкакаются?
Это было время полной анархии, потому что как средство массовой информации он еще не был интересен. Как только стало понятно, что интернет, это средство моментальной доставки информации до заинтерисованного читателя, то он для государств и заинтерисованных групп превратился в еще одно средство отстаивания своих интересов, или как я это называю, средство "искажения реальности" в свою пользу. Знаменитая фраза "кто владеет информацией, тот владеет миром", это уже аксиома. Достоверная или ложная, информация может быть оружием.. а его стараются держать под контролем. Я бы сказал, что это очевидная закономерность.
У Вконтактика какой-то публичный Roadmap есть?
Не подвезут, но один из разработчиков MAUI запилил форк в котором "возможно" будет реализована поддержка GtkSharp
Это качественная характеристика)
От себя добавлю привычку, которую я выработал на текущем месте, а именно один-два дополнительных символа в начале названия обьекта.
Преимущества по началу не очевидны, но так как мы как правило читаем слева на право, то начав читать название таблицы или вью, мы уже предполагаем что это за обьект, и в некоторых случаях догадываемся, как он формируется. Но соглашусь, не всем нравится.
Не успел отредактировать
В тексте очень много вкусовщины, да так что возникают вопросы почти к каждому из упомянутых пунктов. Поэтому побуду занудой и озвучу их все.
Один из действительно полезных советов. Например ORACLE очень любит создавать регистрозависимые имена столбцов, и вы не сможете к ним обращаться иначе, чем
MYTABLE."WordCount".Классическая тавтология. По факту это одно правило "не использовать зарезервированные ключевые слова и названия функций и таблиц". Например если вы в ORACLE создадите тустую таблицу
ALL_OBJECTS, то некоторые клиенты (например ADS) перестанут выдавать вам список обьектов в этой БД.А может быть надо отталкиваться от предпочтений конкретной БД ? Как заметил @alexxisr ORACLE очень любит приводить названия к верхнему регистру. Более того, из моего опыта, если вы обращаетесь из MSSQL/TSQL через функционал
OPENQUERY, то можете получить ошибку, если запрос будет написан нижнем регистре или camelCase форматировании.Вы либо крестик снимите, либо трусы наденьте. Пишите полные читаемые имена таблиц и столбцов, чтобы следующий забавный перснаж, который будет работать с ней не задавался вопросом "а что это за данные".
Неправильно сформулированный совет. Нужно было сформулировать как "Не назначайте имена столбцов которые отличаются только цифровыми постфиксами, если числа не имеют особого значения". К примеру
address1 , address2это действительно плохой пример, ноregion23, region16, region74будут более приемлимыми, т.к. цифра явно является автомобильным кодом региона (опустим тут момент, что вообще создавать отдельный столбец для каждого такого примера - плохая идея, привел исключительно для примера).Что гораздо важнее, оставляйте время для документирования и внесения комментариев к таблицам и столбцам. В случае генерирования DDL они также будут выгружены вместе со всей остальной информацией.
Множественное число в названии таблиц, это почти стандарт. Пенять на то, что вам придется написать два лишних символа в имери ключа реляции это просто смешно. Нормальным тоном является добавление соли в конец длинных имен, которые будут гарантированно обрезаны, и хранение полного имени в комментарии к ключу или таблице-словаре.
Я думаю, что это чистая ничем не подкрепленная вкусовщина.. но если вам как-то хочется иметь систему, то гораздо логичнее будет порядок
source-target. Минус в том, что если вдруг кто-то перестанет соблюдать порядок, то можно начать путаться.Если поле содержит информацию с разделителем, а обработка этих данных не предполагается (только для чтения), то почему бы и нет?
Как правило да.. но наиболее частое исключение, это добавление сокращенного названия типа к имени столбца содержащего дату. В этом случае массово используют суффикс
_dtили_ts.Такое ощущение, что автор не замарачивался с переводом фразы, или не отредактировал поток сознания. Потому что в целом совет дельный, но не читаемый.
Какой-то очень плохой машинный перевод
У столбца может быть время?
На самом деле тут может быть любой язык с низким порогом вхождения: dotnet, js, python.. имхо особенно python, из-за большого количества низкокачественных курсов, развратной динамической типизации, отсутствию привычки создавать стабы.. и тд.
Я заметил, что все зависит от рода запрашиваемой информации. Если взять две немного разные задачи, например, поиск даташита на компанент и поиск информации по человеку, и протестировать в разных поисковых системах, то гугл лучше отработает техническую информацию, а тот же яндекс поиск по Васяну.
Тема достойна отдельного исследования) Но из личного (субьективного) опыта, запросы не всегда написаны оптимально, а COALESCE и CASE очень любят пихать всюду, как серебрянную пулю чтобы собрать один запрос который будет
повеливать всемилаконичнен и читаем. Поэтому, например, когда CASE сидит в переусложненных условиях join'ов, зачастую дешевле разобрать сложные условия свичей на запросы соединенные юнионом. Ну и насколько я помню, внутренний оптимизатор запросов очень даже рад видеть UNION ALL.