Первичный ключ – GUID или автоинкремент?

Насколько я понимаю, последовательные GUID-ы тоже не на единицу отличаются, если рассматривать его как 128-битное число? Как вы сказали, 32 бита брать необязательно, можно те же 128. Если даже раздавать всем клиентам по 1000 каждый раз, то получится примерно 2^118 вариантов. Если база большая, к примеру расположена на 4 машинах, то можно реализовать такую же схему, как с клиентами — генератор последовательности на каждой машине получает свой большой диапазон у мастер-генератора (назовем его так): [1 — 1000000], [1000001 — 2000000],… Как вы считаете, такая схема реальна, или не стоит заморачиваться? В общем-то, основная причина, по которой я спрашиваю — поиск по целочисленному ключу теоретически должен быть быстрее поиска по GUID (что имеет значение при отказе от join-ов).

Первичный ключ – GUID или автоинкремент?

Одна общая последовательность на всю базу. Хотя, как сказали ниже, это будет узким местом.

Первичный ключ – GUID или автоинкремент?

Возможно, вопрос немного глупый, но что если бы можно было генерировать автоинкремент на клиенте? К примеру, при подключении к БД программа резервирует себе некоторый набор id-шников — [1001-1100] — и расходует при создании новых записей. По окончании запрашивает снова — [1601-1700]. Какие недостатки будут у такой системы?

C# — Моделирование «разумной» жизни на базе нейронных сетей

У меня немного другой взгляд на нейросети (и в частности на обучение с учителем), но возможно вы правы) Удачи в исследованиях

C# — Моделирование «разумной» жизни на базе нейронных сетей

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

C# — Моделирование «разумной» жизни на базе нейронных сетей

Как уже сказали, у вас решение принимается не с помощью нейросети, а напрямую в коде. Ради интереса убрал всю работу с нейросетью. Заменил блок принятия решения

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

                //thinking
                //если я тот кто ближе слабее попробовать съесть, если нет драпать
                if (nearlife!=null )
                {
                    if (nearlife.borncount > borncount)
                    {
                        double[][] SenseData = { new double[] { 0, 0, 0, 0 } };
                        trainingSet = new BasicMLDataSet(Input, SenseData);
                    }
                    else
                    {
                        double[][] SenseData = { new double[] { 1, 1, 1, 1 } };
                        trainingSet = new BasicMLDataSet(Input, SenseData);
                    }
                    IMLData output = network.Compute(trainingSet[0].Ideal);
                    if (output[0] > pL) { pL += 0.001; } else { pL -= 0.001; }
                    if (output[1] > pR) { pR += 0.001; } else { pR -= 0.001; }
                    if (output[2] > pB) { pB += 0.001; } else { pB -= 0.001; }
                    if (output[3] > pT) { pT += 0.001; } else { pT -= 0.001; }
                }

на этот

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

                //thinking
                //если я тот кто ближе слабее попробовать съесть, если нет драпать
                if (nearlife != null)
                {
                    double speedXDelta = Math.Abs(sB - sT); if (speedXDelta > 0.001) speedXDelta = 0.001;
                    double speedYDelta = Math.Abs(sB - sT); if (speedYDelta > 0.001) speedYDelta = 0.001;

                    if (nearlife.borncount > this.borncount)
                    {
                        // убегаем
                        // уменьшаем скорость на ближней стороне, увеличиваем на дальней

                        if (sT < sB) { pT -= speedYDelta; pB += speedYDelta; }
                        else if (sB < sT) { pB -= speedYDelta; pT += speedYDelta; }

                        if (sL < sR) { pL -= speedXDelta; pR += speedXDelta; }
                        else if (sR < sL) { pR -= speedXDelta; pL += speedXDelta; }
                    }
                    else
                    {
                        // догоняем
                        // увеличиваем скорость на ближней стороне, уменьшаем на дальней

                        if (sT < sB) { pT += speedYDelta; pB -= speedYDelta; }
                        else if (sB < sT) { pB += speedYDelta; pT -= speedYDelta; }

                        if (sL < sR) { pL += speedXDelta; pR -= speedXDelta; }
                        else if (sR < sL) { pR += speedXDelta; pL -= speedXDelta; }
                    }
                }

Ничего не изменилось.



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

кстати, у вас в коде много ошибок

Навскидку:

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

ret1:
...
foreach (Life life in World) {
...
goto ret1;
}

Неправильно переходит на другую сторону экрана, значение получается больше 1. Оно потом исправляется, но переход в эту сторону не работает.

if (x < 0)
{
    x = 1 - x;
}

Левый двигатель тянет вправо, в сторону увеличения x.
Нижний двигатель либо тянет вверх, либо неправильно определяется нижняя граница. Я считал в экранных координатах, где координата y вниз, у себя исправил границу.

x += pL - pR;
y += pB - pT;
...
sB += Math.Pow(GetDist(x, nearlife.x, y - 0.05, nearlife.y), 2) / 10;

Байес и задача про Морфеуса

Формулировка задачи допускает 2 толкования:
— Морфеус предлагает сначала выбрать руку, затем таблетку из нее
— Морфеус сводит руки вместе, таблетка выбирается из 2 рук сразу, но некоторым образом можно узнать, в какой руке была эта таблетка.
Аналогия автора с фруктами правильная, она относится ко второму варианту. Еще можно по-другому: представим, что в правой руке таблетки более темные. Какая вероятность вытащить темно-красную таблетку из всей кучи?
Теорема Байеса применяется в первом варианте.

Набросал на PHP оба варианта, различие в 3 строчках. Первый выдает 67%, второй 72%.

1 вариант

function test1()
{
    define('LEFT',  0);
    define('RIGHT', 1);
    
    define('BLUE', '0000FF');
    define('RED',  'FF0000');
    
    $hands = [];
    $hands[LEFT] = [];
    $hands[RIGHT] = [];
    
    $config = [
        LEFT  => [BLUE => 7, RED => 3],
        RIGHT => [BLUE => 5, RED => 8],
    ];
    
    foreach ($config as $hand => $handConfig) {
        foreach ($handConfig as $color => $tabletCount) {
            for ($i = 0; $i < $tabletCount; $i++) {
                $hands[$hand][] = ['color' => $color, 'hand' => $hand];
            }
        }
    }
    
    
    $totalCount = 100000;
    $redTabletCount = 0;
    $rightHandCount = 0;
    for ($i = 0; $i < $totalCount; $i++) {
        $hand = mt_rand(LEFT, RIGHT);
        $tablets = $hands[$hand];
        
        $tablet = $tablets[mt_rand(0, count($tablets) - 1)];
        if ($tablet['color'] == RED) {
            $redTabletCount++;
            
            if ($hand == RIGHT) {
                $rightHandCount++;
            }
        }
    }
    
    echo $rightHandCount.' / '.$redTabletCount.' = '.($rightHandCount * 100 / $redTabletCount).'%';
}

2 вариант

function test2()
{
    define('LEFT',  0);
    define('RIGHT', 1);
    
    define('BLUE', '0000FF');
    define('RED',  'FF0000');
    
    $hands = [];
    $hands[LEFT] = [];
    $hands[RIGHT] = [];
    
    $config = [
        LEFT  => [BLUE => 7, RED => 3],
        RIGHT => [BLUE => 5, RED => 8],
    ];
    
    foreach ($config as $hand => $handConfig) {
        foreach ($handConfig as $color => $tabletCount) {
            for ($i = 0; $i < $tabletCount; $i++) {
                $hands[$hand][] = ['color' => $color, 'hand' => $hand];
            }
        }
    }
    
    
    $totalCount = 100000;
    $redTabletCount = 0;
    $rightHandCount = 0;
    for ($i = 0; $i < $totalCount; $i++) {
        //$hand = mt_rand(LEFT, RIGHT);                         // changed
        $tablets = array_merge($hands[LEFT], $hands[RIGHT]);    // changed
        
        $tablet = $tablets[mt_rand(0, count($tablets) - 1)];
        if ($tablet['color'] == RED) {
            $redTabletCount++;
            
            if ($tablet['hand'] == RIGHT) {                     // changed
                $rightHandCount++;
            }
        }
    }
    
    echo $rightHandCount.' / '.$redTabletCount.' = '.($rightHandCount * 100 / $redTabletCount).'%';
}

Форматирование сообщений для Yii::t()

Конечно

10 правил хорошего тона при описании багов

Да, и GUI тоже дураки придумали.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.

Zip-квест про космического админа Василия Романова

А девушка-то в курсе, что она объект применения социнжиниринга?)

Zip-квест про космического админа Василия Романова

слово из мануала по win3.1

Командную

Нашел перебором по словарю словоформ отсюда
Файл надо перевести в кодировку ansi (т.е. windows) и преобразовать первую букву всех слов в прописную

Конец эры айтишников

В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.

Ну разве что javascript, python и .net вытеснятся одним универсальным супер-языком. Разделение на фронтенд и бэкенд разработку применительно к веб появилось не так давно, и пока они только отдаляются друг от друга. По крайней мере, лет 8-10 назад вакансию «фронтенд-разработчик» мало где можно было встретить. Даже если писать бэкенд на node.js, все равно там другие задачи, и поэтому другая специализация.

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

Зачем останавливаться на 4 уровне OSI, и почему именно на нем? Давайте будем напрямую из браузера с сетевой картой работать. Уровни абстракции для того и нужны, чтобы не вдаваться в детали реализации. Все знать невозможно, и даже общее представление обо всем иметь невозможно.

Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков

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

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

Несмотря на наличие кучи генераторов сайтов или wordpress/joomla, программирование пока никуда не делось. И не денется. Потому что, чем сложнее система, тем больше потребуется таких ползунков и кнопочек для ее представления. Настолько много, что это будет аналог языка программирования.

Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики.

Как может помочь в изучении SPDY знание умножения матриц? А знание процессов, происходящих в атоме? Такие общие фразы в целом правильные, но они не дают ответ на основной вопрос — как найти границу, стоит ли изучать дальше, или уже можно начать изучать что-то другое.

Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.

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

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

Техническое собеседование: пять способов отпугнуть соискателя / пять способов взбесить интервьюера

По поводу протоколов TCP/IP и других подобных вопросов. Года 3-4 назад я мог в сетевом дампе разобрать начало IP-кадра, узнать значения флагов, и предположить, какие данные придут дальше. Сейчас я практически ничего из этого не помню, просто потому что этим не занимаюсь. Основы основами, но если человек хороший фронтенд/бэкенд разработчик, то совсем необязательно, что он знает тонкости смежных областей.

Путь аналитика. Работа над ошибками

А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)

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

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

Условие как компромисс

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

Как нейронные сети рисуют картины

Насколько я понимаю, рисование основано на механизме обратного распространения. То есть, некоторое изображение на входе дает сигнал на выходе: нейрон1 = 0.8, нейрон2 = 0.3,… Задаем сигнал на выходе, по коэффициентам нейронов рассчитываем, какой должна быть входная картинка.

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

Lines и теория вероятностей

Да, перепутал немного, 100 вызовов это было на моей машине, это ограничение XDebug. А на сервере падала по превышению лимита памяти либо по таймауту выполнения.

Lines и теория вероятностей

Ведь если останется всего одна последняя клетка, кто знает, сколько раз придётся повторяться? Сколько времени понадобится 16-битному процессору, чтобы выполнить столько циклов?

Не совсем по теме статьи, но реально встречался с подобной ошибкой в продакшене. В системе использовалась довольно старая и сильно допиленная версия osTicket. Там есть возможность генерировать дополнительный случайный номер для заявки.
Выглядит это так (class.ticket.php):

function genExtRandID() {
	global $cfg;

	// We can allow collissions...extId and email must be unique ...so same id with diff emails is ok..
	// But for clarity...we are going to make sure it is unique.
	$id=Misc::randNumber(EXT_TICKET_ID_LEN);
	if(db_num_rows(db_query('SELECT ticket_id FROM '.TICKET_TABLE.' WHERE ticketID='.db_input($id))))
		return Ticket::genExtRandID();

	return $id;
}

EXT_TICKET_ID_LEN по умолчанию равно 6.

В итоге, когда количество заявок превысило примерно полмиллиона, система начала случайным образом падать при создании заявки. Потому что предел рекурсии 100 вызовов. Долго не могли понять, в чем дело, ошибка-то не воспроизводится.

Насколько важно видеть URL сайта?

Ну а как это противоречит моему комменту?) Он не «не видит куда его перекинуло», а видит, что он перешел по ссылке, и URL исчез. Лично я вообще ни разу не сталкивался с такой ситуацией, и подумал бы, что у меня браузер глючит. Поэтому закрыл бы вкладку или вообще перезапустил браузер. В данной ситуации для меня нет разницы, написано в адресной строке «vk.som» или там пусто. Это выглядит странно, и лучше не продолжать.

Насколько важно видеть URL сайта?

Фишинг подразумевает, что человек думает, что находится на одном сайте с пустой строкой вместо URL, а на самом деле на другом сайте с пустой строкой вместо URL. Но тот человек, который смотрит на URL, скорее всего вообще не будет пользоваться сайтом, где URL не видно, вне зависимости от того, настоящий он или фишинговый. Даже если это и не баг вашего кода, я бы посоветовал поменять ваш код, чтобы он работал по-другому и не очищал URL.

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