https://timezoned.vercel.app/

Регистрация не требуется, вся информация хранится локально в браузере.

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

Заодно наконец попробовал все новомодные веб-технологии. Исходники на GitHub тоже прилагаются: https://github.com/kapxapot/timezoned

Использованные технологии и библиотеки:

• React / Next.js / TypeScript
• Tailwind CSS
• Flowbite React
• Headless UI
• React Joyride

Все продукты производились (грубо говоря) белыми для белых, и везде в иллюстрациях, фото и интерфейсах все было от белых для белых. И это было ок, пока это не стало напрягать всех остальных и эти остальные не получили возможность об этом заявлять.

Как теперь (тренд)

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

Но что же теперь получается на самом деле?

Если раньше везде были изображения белых и белые были довольны, а все остальные недовольны, то теперь чаще всего любой человек видит изображение человека другой культуры (непохожего на него). Скорее всего, мы к этому привыкнем, но пока это вызывает какую-то подсознательную неуютность и отторжение. Наверное, теперь белые могут в полной мере ощутить себя так же неуютно, как раньше было не-белым. Как себя теперь ощущают не-белые, могу только гадать, но думаю, что лучше, чем раньше.

Что мы имеем в итоге?

Если раньше были довольны белые, но недовольны все остальные, то теперь все остальные чуть более довольны, а белые значительно менее довольны. То есть, грубо говоря, теперь недовольны все (в разной степени), ибо наша бессознательная ксенофобия никуда не девается (например, вокруг нас (в России) белых намного больше, чем в интернете, поэтому в реальности в этом плане нам уютнее, чем в глобальном интернете).

Что дальше?

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

Ну а так в целом все это позитивно и прикольно, особенно, когда в каком-нибудь Slack под постом стоят ? всех цветов человеческой кожи. Возможно, нам (мне) просто стоит расслабиться и принять мультикультурализм таким, какой он есть. Но пока это дается с трудом. ?

But actually, XAMPP requires some additional configuring if you want to make things working right. This mini-guide explains it step-by-step.

Installation

• First of all, install XAMPP: https://www.apachefriends.org/download.html.
• Choose Apache, MySQL and phpMyAdmin.
• Open the Control Panel, we’ll need it later.
• Start Apache and MySQL.

Change MySQL root password

By default, MySQL user name is root with an empty password. An empty password is not very secure, and there can be situations when an empty password doesn’t work and some actual password is required. So let’s change it to password, for example.

• Open XAMPP Control Panel.
• Open XAMPP shell (one of the buttons on the right side).
• Execute command mysqladmin.exe -u root password.

Change password in phpMyAdmin

After changing the MySQL password we need to change it in phpMyAdmin config too.

• Open file \xampp\phpMyAdmin\config.inc.php.
• Add password to line: $cfg['Servers'][$i]['password'] = 'password';.

Correct the timezones

In some cases, you may end up with timezones out-of-sync between PHP, Apache and MySQL. Let’s sync them to Europe/Moscow timezone, for example.

Set correct timezone for PHP

• Open \xampp\php\php.ini.
• Add line date.timezone = "Europe/Moscow".

Set correct timezone for Apache

• Open \xampp\apache\conf\httpd.conf.
• Add line SetEnv TZ Europe/Moscow.

Set correct timezone for MySQL

• Open \xampp\mysql\bin\my.ini.
• Add line default-time-zone = "Europe/Moscow".

Ready, steady, go!

We’ve finished configuring XAMPP, grats! Now let’s start the servers.

• Open XAMPP Control Panel.
• Stop Apache and MySQL.
• Start Apache.
• Start MySQL.

If you open http://localhost in your browser, you should be redirected to http://localhost/dashboard and see the XAMPP welcome page.

To open phpMyAdmin, press MySQL‘s Admin button in XAMPP Control Panel or open http://localhost/phpmyadmin directly.

DB connection settings

To connect to DB from your code (PHP in this case), use these settings:

DB_ADAPTER="mysql"
DB_HOST="localhost"
DB_PORT="3306"
DB_DATABASE="test" // change it to your database
DB_USER="root"
DB_PASSWORD="password"

That’s it! Now you are ready to code!

Выводы:

1. Использовать двухфакторную аутентификацию (2FA) через СМС, где это возможно. Потерять доступ к номеру телефона менее вероятно, чем потерять доступ к определенному устройству. Точнее, восстановить симку можно всегда, если вы не забыли ее номер и не потеряли свой паспорт.

2. Google Authenticator — не лучший выбор для 2FA. Собственно, все проблемы из-за отсутствия облачной синхронизации. Понятно, что, скорее всего, так сделано, с одной стороны, чтобы повысить надежность (уж очень надежно вышло, не поспоришь), а, с другой стороны, просто потому, что идите нахуй, вот почему.

   В данный момент планирую попробовать Authy — у него есть облачные бэкапы (но приоритетным способом 2FA выбирать СМС, где возможно).

3. Даже если потерян доступ к 2FA, большинство сервисов позволяют восстановить доступ или через СМС (ВК), или путем обращения в службу поддержки (Okta, Amazon). Пока что у меня не восстановлен доступ только к Discord (и IFTTT), заявка в рассмотрении, но официальная позиция компании «потеряли 2FA — сами дураки, заводите новый аккаунт» не очень воодушевляет.

   Дополнение: Discord так и не восстановил доступ, так что я им больше не пользуюсь.

   Дополнение 2: IFTTT тоже не восстановил доступ. Мой аккаунт деактивировали и выслали мне бэкап всех моих настроек в системе. Т.е. я могу зарегиться под тем же е-мейлом и восстановить все свои настройки. В целом, нормально.

4. Ну и вообще, пожалуй, если нет острой необходимости защитить какой-то аккаунт, то, возможно, лучше к нему вообще не подключать 2FA. Редкий случай, когда перебдеть может быть хуже, чем недобдеть.

Здоровья и долголетия вашим телефонам. ;)

Поэтому я составил список наиболее частых ошибок произношения с моими предложениями по их исправлению. Часть из них просто без вариантов должны произноситься так же, как и на английском языке. А некоторые слова получили в русском языке собственное звучание, но и тут у меня есть свое мнение на их счет (например, апИ).

• ЗАГЛАВНЫМИ буквами обозначено ударение.
• Статья будет обновляться по мере обнаружения мной новых антипаттернов.
• Если вам есть что добавить, или вы со мной не согласны — добро пожаловать в кОмменты!

Заметки

Логин

Тут все несколько сложнее. Если обычно надо ориентироваться как раз на английское произношение (например, prOfit => прОфит), то в случае с логином слово уже вошло в русский язык, и тут ударение ставится по-своему. Мне всегда казалось естественным произносить логИн, я даже не знал долгое время, что по-английски такие слова как login и plugin произносятся с ударением на первый слог.

Был приятно удивлен, что в словарь внесен вариант именно с ударением на второй слог, так что произносите правильно!

Google Translate произносит это слово неверно. Так что ориентироваться на него можно не всегда. А вот в Викисловаре все корректно.

Коммент

Я всегда читал и произносил это слово как коммЕнт, однако в последнее время все чаще встречаю вариант кОммент. Мне понятно, откуда это пошло — в английском языке в слове cOmment ударение падает на первый слог. Однако коммент это еще и сокращение от слова комментАрий (как я его всегда и воспринимал). Мне неизвестны правила переноса ударения при сокращении слов, но я не вижу причин переносить его на первый слог в данном случае.

Аргументы в мою пользу:

• mOment => момЕнт.
• коммЕнтить. Кто-то говорит кОмментить?

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

В общем, в данном случае нет фиксированной нормы, более того, есть словарная фиксация, которую я считаю некорректной.

Допустим, у нас есть класс Money со свойствами Amount (количество) и Currency (валюта), в которое реализовано неявное преобразование к decimal и int. Также перегружен оператор + для сложения Money с Money:

public class Money
{
    public decimal Amount { get; }
    public Currencies Currency { get; }

    ...

    public static implicit operator decimal(Money m) => m.Amount;

    public static implicit operator int(Money m) => (int)m.Amount;

    public static Money operator +(Money m1, Money m2)
    {
        var conv = m2.ConvertTo(m1.Currency);
        return new Money(m1.Amount + conv.Amount, m1.Currency);
    }

    ...
}

Это позволяет безо всяких приведений типов и выковыривания Amount складывать Money не только с Money, но и с decimal и int. Результатом таких операций будет число decimal или int соответственно.

var m = new Money(100, Currencies.RUR);
var x = 200;
var sum = m + x; // (int)300

Кроме арифметических операций можно передавать Money в качестве параметра везде, где требуется decimal или int.

private double TotalSum(double partOne, double partTwo) {
    return partOne + partTwo;
}

private void Test() {
    var m = new Money(100, Currency.USD);
    var total = TotalSum(m, 1000); // (int)1100
}

Однако будьте внимательны и имейте в виду, что при использовании нескольких Money таким способом их валюты будут игнорироваться, то есть такие операции следует делать только между экземпляром Money и числами (или проводить операции отдельно над Money и отдельно над смешанными объектами).

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

var m1 = new Money(100, Currencies.RUR);
var m2 = new Money(200, Currencies.USD);

var sum1 = m1 + m2 + 1000;
// переведет $200 (m2) в рубли (допустим, по курсу 60 получим 12000 р), сложит их со 100 рублями, после чего прибавит к ним 1000
// результат: 13100

var sum2 = 1000 + m1 + m2;
// сложит все в виде чисел
// результат: 1300

var sum3 = 1000 + (m1 + m2);
// результат: 13100

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

Полный код примера (Github):

using System;
using System.Linq;

namespace Money
{
    public class Program
    {
        public static void Main()
        {
            // test 1
            var m = new Money(100, Currencies.RUR);
            var x = 200;

            Console.WriteLine($"{m} + {x} = {m + x}"); // 300

            //test 2
            m = new Money(100, Currencies.USD);
            x = 1000;

            Console.WriteLine($"{m} + {x} = {Sum(m, x)}"); // 1100

            // test 3
            var m1 = new Money(100, Currencies.RUR);
            var m2 = new Money(200, Currencies.USD);
            x = 1000;

            Console.WriteLine($"{m1} + {m2} + {x} = {m1 + m2 + x}");
            // переведет $200 (m2) в рубли (допустим, по курсу 60 получим 12000 р), сложит их со 100 рублями, после чего прибавит к ним 1000
            // результат: 13100

            Console.WriteLine($"{x} + {m1} + {m2} = {x + m1 + m2}");
            // сложит все в виде чисел
            // результат: 1300

            Console.WriteLine($"{x} + ({m1} + {m2}) = {x + (m1 + m2)}");
            // результат: 13100

            Console.ReadLine();
        }

        private static decimal Sum(params decimal[] x) => x.Sum();
    }

    public enum Currencies
    {
        RUR,
        USD,
        EUR
    }

    public class Money
    {
        public decimal Amount { get; }
        public Currencies Currency { get; }

        public Money(decimal amount, Currencies currency)
        {
            Amount = amount;
            Currency = currency;
        }

        public Money ConvertTo(Currencies newCurrency)
        {
            var newAmount = (Currency == newCurrency)
                ? Amount
                : Amount.Convert(Currency, newCurrency);

            return new Money(newAmount, newCurrency);
        }

        public static implicit operator decimal(Money m) => m.Amount;

        public static implicit operator int(Money m) => (int)m.Amount;

        public static Money operator +(Money m1, Money m2)
        {
            var conv = m2.ConvertTo(m1.Currency);
            return new Money(m1.Amount + conv.Amount, m1.Currency);
        }

        public override string ToString() => $"{Amount} {Currency}";
    }

    public static class Extensions
    {
        public static decimal Convert(this decimal amount, Currencies from, Currencies to) =>
            (decimal)((double)amount * from.GetCourseTo(to));

        public static double GetCourseTo(this Currencies from, Currencies to)
        {
            if (from == to) return 1;

            // placeholder
            if (from == Currencies.USD && to == Currencies.RUR)
            {
                return 60;
            }

            throw new Exception($"No course set for conversion from {from} to {to}.");
        }
    }
}

Результатом выполнения этой программы будет следующий текст:

100 RUR + 200 = 300
100 USD + 1000 = 1100
100 RUR + 200 USD + 1000 = 13100
1000 + 100 RUR + 200 USD = 1300
1000 + (100 RUR + 200 USD) = 13100

Арифметика

Например, null пожирает остальные значения в арифметических операциях и превращает результат в null:

null + null: null
null + 1: null
1 + null: null
1 + 1: 2

Где это может пригодиться

Не знаю, где это может пригодиться, но это довольно забавно. А если серьезно, то просто имейте это в виду.

Сравнение с числами

Если сравнивать null с числами, то он одновременно не меньше и не больше их:

null > 0: false
null < 2: false

Где это может пригодиться

Например, у нас есть строка, но мы не знаем, null она или нет, а нам надо проверить ее длину. В голову может прийти такой неэлегантный вариант:

if (!string.IsNullOrEmpty(str) && str.Length > 10) { ... }

Или даже так:

if (!string.IsNullOrWhiteSpace(str) && str.Length > 10) { ... }

IsNullOrWhiteSpace, как и IsNullOrEmpty — хорошая (отличная!) практика, но в данном случае это излишне, поскольку мы сразу же за этим проверяем длину строки (что нам придется делать в любом случае). Поэтому можно написать проще:

if (str != null && str.Length > 10) { ... }

А теперь вспомним наш хак и сократим это еще больше:

if (str?.Length > 10) { ... }

Если str == null, выражение выдаст false, поскольку str?.Length == null. Если же строка не null, будет произведена обычная проверка ее длины.

Пример:

public static class Extensions
{
  public static string Truncate(this string str, int length)
  {
    return (str?.Length > length)
      ? str.Substring(0, length)
      : str;
  }
}

Сравнение с булевскими величинами

С булевскими значениями все без сюрпризов. null не равен как true, так и false:

null == false: false
null == true: false
null != false: true
null != true: true

Где это может пригодиться

null у нас опять сущность из другого измерения, которая ни с чем не совместима. Но эта особенность позволяет немного элегантнее проверять значения переменных типа bool?.

Мы довольно часто встречаемся с булевскими полями в сущностях БД, которые могут быть пустыми. Бывают и такие параметры функций.

Например, у нас есть такой код:

using (var model = new Model())
{
  var project = model.Projects.Where(p => p.Id == 12345);
  ...
}

Нам нужно проверить, особенный это проект или нет, за это отвечает поле project.IsSpecial, тип которого bool?. У него может быть три значения: null, false и true. Первые два соответствуют значению ложь, и только третье означает истина, что типично для булевских полей БД, которые могут быть null.

Таким образом, чтобы узнать, что поле имеет значение истина, нам нужно убедиться, что оно не пустое и имеет значение true. Если бы у нас было простое значение bool, мы бы просто написали:

if (project.IsSpecial) { ... }

Но оно у нас Nullable, поэтому все печально, и нам приходится писать такие монструозные конструкции, как:

if (project.IsSpecial.HasValue && project.IsSpecial.Value) { ... }

Или:

if (project.IsSpecial != null && project.IsSpecial.Value) { ... }

Что немногим лучше.

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

if (campaign.Project.IsSpecial != null
  && campaign.Project.IsSpecial.Value) { ... }

Мало того, что код получается длинным и малочитабельным, так мы еще имеем и повторение кода, которое тоже чревато последствиями. Одним из вариантов будет вынесение campaign.Project во временную переменную (и я рекомендую так делать для увеличения читабельности кода и избавления от его дублирования), но есть вариант и получше.

Нам на помощь приходит вышеописанный волшебный хак.

if (project.IsSpecial == true) { ... }

Вуаля! Элегантно и просто, не правда ли?

Как вариант:

if (project.IsSpecial ?? false) { ... }

Результат абсолютно такой же, но этот вариант мне почему-то нравится меньше (наверное, потому что он пришел в голову не мне, а кому-то другому).

Для вложенной структуры все будет выглядеть примерно так же:

if (campaign?.Project?.IsSpecial == true) { ... }

Что позволяет не проверять на null все части пути к финальному полю.

Что же нам делать, если нам нужно проверить значение bool? на false? Да примерно то же самое:

if (project.IsSpecial != true) { ... }

Обратите внимание, что вот так писать нельзя, потому что значение null мы тоже считаем ложью:

if (project.IsSpecial == false) { ... }

Сортировка

Мы выяснили, что null не равен ни true, ни false. Но что произойдет, если отсортировать массив значений типа bool??

Проверить это очень просто:

var list = new bool?[]
{
  true, true, null, false, false, null, true
};

foreach (var item in list.OrderBy(i => i))
{
  Console.WriteLine(item == null ? "null" : item.ToString());
}

Результат:

null
null
False
False
True
True
True

Получается, что null меньше любого другого значения, причем это не зависит от типа. С числами и строками будет то же самое.

Одно из его требований, которое меня занимает — держание ножа в правой руке, а вилки — в левой (вариант использования #1). Требование #1 это происходит, по-видимому, от того, что ножом надо резать (и нередко прилагать к этому усилия), что у людей получается лучше основной рукой (для большинства людей — правая). Проблема в том, что орудуя ножом и вилкой, нам далеко не всегда приходится резать что-то твердое, то есть мы бы прекрасно справились с ножом и в левой руке, в то же время, вилкой часто надо делать что-то более сложное, чем просто накалывание еды, левой рукой это делать неудобно, и так и хочется взять вилку в правую руку.

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

Выходит, что это правило этикета (как и большинство других) направлено больше на эстетичность процесса поедания пищи, а не на его удобство. Причем, по-видимому, этикет и не пытается прийти к компромиссу этих направлений, а ставит первое во главу угла.

Если научиться резать мясо левой рукой и не перекладывать вилку туда-сюда (а в таком случае в этом и нет нужды), то теоретически это тоже должно быть приемлемо (вариант использования #2). Но если воспринимать требование #1 формально и считать его основополагающим, а не требование #2, то вариант использования #2 неприемлем. То есть, окружающим не важно, что вы мастерски режете мясо левой рукой, их может возмущать нож в левой руке, ведь это нарушение этикета.

Дополнительные сложности возникают с левшами, потому что для них юзкейсы меняются местами. Если считать основным требование #1, то левши тоже должны держать нож в правой руке. Что им как раз и на руку, потому что им так удобнее и привычнее (не надо переучиваться держать вилку в другой руке). Но если исходить из требования #2, то левшам надо держать нож в левой руке (например, когда надо резать мясо). Но при этом на лбу у левши не написано, что он левша, поэтому для окружающих он будет выглядеть как невежа, не соблюдающий этикет.

Таким образом, налицо конфликт между функциональными и формальными требованиями, что ставит под сомнение целесообразность всего этого этикета в принципе. Как можно придерживаться противоречивого свода правил? Это неприемлемо.

Больше смысла имеет декомпозиция и анализ правил этикета до основополагающих составляющих, от которых и следует отталкиваться. То есть, в этикете 2.0 требование к ножу и вилке будет сформулировано так:

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

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

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

При этом русский язык совсем не такой — у нас существительные обладают родом, род также есть и у глаголов единственного числа прошедшего времени. Тот же «пользователь» — мужского рода, и нечего тут заморачиваться. Говоря о пользователе в мужском роде, мы не подразумеваем, что это именно мужчина. Мы понимаем, что это произвольный человек, который может быть как мужчиной, так и женщиной. Это никого (из адекватных людей) не возмущает и не волнует.

То есть, наш язык изначально обозначает, где у нас мужское, а где — женское, и нечего тут сомневаться и раздумывать. И даже если на самом деле и не идет речь о принадлежности к какому-то полу и роду, то по умолчанию звучит это все равно в мужском роде. Для нас это естественно, мы этого не замечаем. Но для иностранцев это, наверняка, звучит так, как будто мы насквозь патриархальны (на самом деле это так и есть, но мы, опять же, не отдаем себе в этом отчета).

А поскольку язык определяет сознание (и наоборот), то, наверняка, все это отпечатывается и в нашем мировоззрении, что делает русских (в общем смысле этого слова) менее толерантными и политкорректными. И это хорошо, хотя и немного плохо.

Каждый мужчина передает своим детям сразу две части своего имени (фамилию и отчество), в то время как каждая женщина не оставляет в именах своих потомков никаких следов.

Дальнейшее рассмотрение этого вопроса привело меня к размышлениям об одном из ярчайших проявлений патриархальности нашего общества.

Рассмотрим имена мужчин и женщин: фамилию, имя и отчество.

Каждый из нас получает свои фамилию и отчество от отца, тем самым наши отцы как бы отмечают, что 2/3 нашего имени принадлежат им, и только 1/3 — наше имя — наше собственное.

Далее если сравнить мужчину и женщину, то (будем рассматривать только «нормальное» течение жизни человека) женщина выходит замуж и меняет свою фамилию на фамилию мужа, после чего ее «акции» распределяются поровну между ее отцом, мужем и самой ей. То есть, женщине принадлежит только 1/3 собственного имени в любой ситуации.

С мужчиной все немного по-другому. Его «акции» не просто принадлежит его отцу на 2/3, мужчина становится «дистрибьютором» отцовской фамилии, к нему переходят права на нее. Кроме того, он захватывает 1/3 имени своей жены (фамилию) и получает уже свои 2/3 в именах собственных детей. С учетом этих обстоятельств можно считать, что мужчине (если он переходит в свою «полноценную форму» отца и мужа) принадлежит уже 2/3 собственного имени, а 1/3 остается во владении его отца навсегда.

Не думаю, что приведенный выше анализ несет какую-то практическую пользу, но мне показался такой взгляд на наше общество интересным. :)

Написано мной в Google Buzz (R.I.P.) 21.10.2010