Upgrade до Middle PHP-разработчика за 3 месяца

Вот так прочитаешь все это, найдешь хорошую вакансию,
а там используется Yii (потому что не у всех IQ больше 120),
PostgreSQL (по некоторым причинам),
Smarty (или вообще без отдельного шаблонизатора),
nginx-ом управляют сениоры (которые давно там работают и хорошо знают проект).

Вообще, мне кажется, в статье описан middle, который ближе к senior, почему автор и отсеял 90% кандидатов. Вот тут есть хорошее описание.

Исследование защиты игры Charm Solitaire

Здесь уровни после 30-го зашифрованы и расшифровываются ключом, так что просто обойти проверку не поможет)

C++ в современном мире

Мы в универе начинали с одновременного изучения C++ и Pascal. В C++ изучали в основном подмножество C, просто написание учебных программ без использования стандартной библиотеки. Он мне показался более понятным и удобным, чем Pascal. Но сейчас я пишу на более «высокоуровневых» языках.

Скрытый текст

В принципе, это неплохой язык для начального обучения, если не лезть в дебри метапрограммирования и сложных ООП абстракций. Потом уже можно переходить на другие языки, с пояснениями в плане «в C++ надо было делать так, а в этом языке это делается вот так, и это удобнее». Для начинающих будет более понятно, зачем придумали сборщики мусора, динамическую типизацию, и как устроена работа со строками. А то я пару раз сталкивался с вопросами вида «а почему C++ сам int в строку не конвертирует?».

C++ хороший язык, но правильно писать на нем достаточно сложно. Надо знать много технических нюансов.

Экран с бесконечным количеством пикселей

Хм… Да, вы правы. Задумался о целых числах, и упустил из виду, что могут быть строки вида 0000(01), или вообще непериодические. Хотя, если под дробью подразумевать отношение двух целых чисел a / b, то это множество счетно.

Экран с бесконечным количеством пикселей

На самом деле, во множестве бесконечных двоичных строк есть 2 взаимно не пересекающихся множества:

0000(0)
1000(0)
0100(0)
1100(0)
...
...
0111(0)
1111(0)

и

1111(1)
0111(1)
...
...
1100(1)
0100(1)
1000(1)
0000(1)

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

Двойная диспетчеризация

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

Оберон в программировании БПЛА

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

Оберон в программировании БПЛА

Как-то слишком многословно…

c++

class RC
{
    int rc, n;
    
public:

    RC(int x, int n)
    {
        rc = x << n;
        this.n = n;
    }
    
    void set(int x)
    {
        rc = x << n;
    }
    
    int asr1(int x, int n)
    {
        if (x > 0) x += (1 << (n - 1));
        return asr(x, n);
    }
    
    int asr2(int x, int n)
    {
        if (x > 0) x += ((1 << n) - 1);
        return asr(x, n);
    }
    
    int update(int x)
    {
        rc += asr2((x << n) - rc, n);
        return asr1(rc, n);
    }
    
    int get()
    {
        return asr1(rc, n);
    }
}

Фреймворки портят разработку

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

Интенс, индикатор прокрутки (или жизнь после скроллбара)

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

Снова про AUTO_INCREMENT

Да, наверно я был неправ. Спасибо за разъяснение.

Снова про AUTO_INCREMENT

Чем это помешает работе индексов?
Дата-время не всегда имеет достаточную точность.
Про счетчики — если у нас будет один централизованный счетчик на всю базу, то при вставке записи с большим id он будет и меняться соответственно. Как автоинкремент в таблице mysql.
В любом случае, спасибо за информацию.

Снова про AUTO_INCREMENT

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

Снова про AUTO_INCREMENT

Но считать этот адрес идентификатором объекта — нельзя

Да, я знаю. Поэтому у меня и появилась мысль о более абстрактном адресе.

Снова про AUTO_INCREMENT

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

Снова про AUTO_INCREMENT

Да, бизнесу нужны сущности. И мы можем идентифицировать сущность по атрибутам, только если мы специально вводили для нее ключ в качестве атрибута — тот же номер счета. С этой точки зрения нет разницы, использовать для идентификации этот уникальный атрибут, или внутренний дополнительный.
Кроме адресации, из плюсов мне пришли в голову примерно такие:
— Без проблем можно перенести данные между таблицами при рефакторинге
— Отображает последовательность создания объектов
— Меньше ресурсов требуется на создание ID для новой записи (по сравнению с guid)

Как нам теперь понять, на каком шарде лежит объект? По диапазону? Дополнительная сущность.

Насколько я знаю, некоторые варианты реализации шардинга предполагают использование диапазонов, есть варианты с централизованным генератором ключей. Так что тут различий почти нет.

Какого типа объект? По диапазону? Еще одна сущность.

Ну таблицы-то никуда не деваются. Просто немного меняется способ генерации ключа.

А если у вас в системе есть короткоживущие объекты — они все равно будут поедать емкость из общего множества идентификаторов?

Да. Если на них бывают внешние ключи в других таблицах, хоть и ненадолго, то в этот момент они являются частью системы. А если не бывают, и если мы не хотим тратить на них идентификаторы, можно завести для них отдельную последовательность.
Множество значений идентификаторов это небольшая проблема. Кроме того, если использовать GUID, то про них тоже можно сказать, что значения поедаются.

А если у вас есть объекты с естественными идентификаторами — для них все равно заводить искусственный и поддерживать две уникальности?

Да. Это ничем не отличается от составного ключа. Ну и технические причины есть, по числовому идентификатору искать быстрее, чем по 20-символьной строке с номером счета.

А если у вас есть связи, у которых «естественный» ключ — составной, с ними как поступать?

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

Снова про AUTO_INCREMENT

Добиться, пожалуй, ничего. В основном, хочу узнать, правильно я рассуждаю или нет.