Pull to refresh
-1
0.6
Send message

Очевидно при ответе можно было выбрать сразу несколько вариантов. Типа, мешает и разговорчивые коллеги, и офисный шум, или вообще все 3 пункта сразу.

Мне 70 литров соляры в баке не всегда хватает на выезд в места далёкие от цивилизации.

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

Точно! В те времена ороклистам было модно смотреть на mssql сильно свысока, ибо фуу, блокировочник! :)

Не уверен на 100%, но кажется во времена когда трава была зеленее, девки краше, а зарплата у программистов была примерно как у бухгалтеров, в спорах, во время распивания дешевых алкогольных напитков, Оракл называли читером потому что он делал версии не отдельных записей, а блоков, а вот фаерберд версионил отдельные записи.

Ну и где-то в те самые времена, в конторе, где я работал, бизнес-логика вся была в хранимках в оракле, базы большие, так что snapshot too old прям вызвали воспоминания :)

Во времена, когда он еще назывался Interbase, фирма Borland, которая его разработала, хвасталась, что он стоит на абрамсах. Типа, выбрали его туда, потому-что он быстро стартовал.

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

Быть версионником, это вроде-как что-то хорошее, но обратная сторона - он, к сожалению, медленнее остальных СУБД. Хотя опять-же, все это из того-же пула знаний, последний раз с ним дела имел году в 2007, может теперь все-все поменялось.

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

Я прожил первые несколько лет в США, но т.к. общался преимущественно с русскоговорящими, включая на работе в офисе, то разговорный английский был очень плохим. Решил поменять ситуацию и стал слушать аудиокниги, преимущественно в машине по дороге на работу и с работы, туда 40 минут, обратно 40 минут в день, каждый день, ну и кроме этого слушал когда выпадала возможность. Сначала плохо понимал, но прослушивал книги по несколько раз подряд и первые книги были те, которые когда-то читал на русском. Потихоньку уровень рос. А года через два, прослушав раза три Властелина Колец (не читал его на русском раньше, но аудиоверсия очень понравилась, разные голоса, музыка и тд), начал ловить себя на том, что понимаю какие-то фразы и слова, а перевести их на русский не могу. Жена, например, просит фразу перевести - я переведу общий смысл, а слово из фразы спросит - не могу перевести, хотя и понимаю. Чувствовал себя при этом очень странно. Лезу в словарь и сразу мысь "о, точно! вот оно как переводится, какжеж я сразу не догадался". Правда со временем таких слов и фраз становится все меньше и меньше.

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

По последним данным, кстати, половым путём язык тоже не передаётся.

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

так как перекодировки займут добрую половину времени CPU.

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

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

Основная проблема в том, что они охотятся на строго определенных бактерий, с антибиотиками гораздо проще. На хабре почти 10 лет назад была гораздо более интересная и подробная статья на тему: https://habr.com/ru/articles/400097/ еще из тех времен, когда статьи писали люди для людей, а не чатжпт на запрос: "напиши так, чтоб было больше вау-херни и заманухи, ах да, и покороче, чтоб тупые людишки фокус внимания не потеряли".

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

А еще, такое АПИ - мечта мамкиного хакира. Пишешь валидный sql запрос, но гарантированно очень медленный и ставишь сервак в раскоряку с одной лишь машины.

Собственно GraphQL должен помочь решать ту проблему, которую автор пытается решить с помощью SQL

Ну, не совсем так, OpenAI была создана на деньги других людей и Open в названии означал, по аналогии с опенсорсом, что результаты работы будут доступны всем, а уж после нескольких лет исследований, которые принесли вполне себе приличный результат, Микрософт сделала на них ставку и не проиграла. С учетом того, что OpenAI переехали в облако Микрософт, сложно сказать сколько там от Микрософт было реальных инвестиций, а сколько перекладываний из одного своего кармана в другой карман, по сути они выставляют сами себе счета за облако и сами их оплачивают. Вот только от Open, после версии 3, не осталось и следа. Это как еслиб основные инвесторы в Линукс ядро вдруг с какой-то версии закрыли его исходники. Ну а что, инвесторы же, на их деньги пилится продукт. Имеют право, да?

По-моему твиттер-формат не подходит для хабра. Думал, здесь минимум будет перевод какого-то интервью с этим Хуангом, в котором тема будет раскрыта, а одно лишь утверждение, даже без ссылки на источник! И опрос. Грустно. Ну хоть рекламы телеграм-канала нет.

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

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

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

В частности обучение "базовых юнитов" (рабочих) в разные типы, "физический" подход к ресурсам (которые надо откуда-то брать, а не просто из казны появляются)

Эти механики в разных играх 90-х были, обучение юнитов в Settlers, во второй Дюне надо было спайс харвестерами добывать и защищать их от червяков во время добычи, в первом Варкрафте пезанты лес рубили (кажется и камни еще добывали, но точно не помню, могу спутать с другой игрой) и их могли начать вырезать вражеские юниты и тд.

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

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

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

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

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

Принудительный безопасный пуш

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

Угу, увидел заголовок, зашел посмотреть что такое БЖЖ, но так и не нашел. Подозреваю, что это Бразильское дЖиу-дЖитсу. :) А почему автор использовал Ж вместо первых букв, как принято у аббревиатур, ну, видимо перевод с инглиша: Brazilian Jiu-Jitsu - BJJ.

Уважаемый автор, это перевод, или нет? Если не перевод, то зачем буквы неправильные?

У паскаля - вызов функции стандартной библиотеки языка. У ассемблера 6502 была стандартная библиотека, включающая в себя функцию вывода строки на экран? Я честно не знаю, в свое время только tasm использовал и у него никаких стандартных библиотек не было (не считая прерываний ДОСа и БИОСа).

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

А бывает, что просто достаточно пересобрать статистику, чтоб оптимизатор вправил себе мозги и перестроил план запроса на оптимальный.

Information

Rating
1,521-st
Registered
Activity