Да я не знаю, карго-культ какой-то. Когда нанимают бегуна — его просят пробежать дистанцию, а не перечислить пять способов шнуровки кроссовок. А если программиста — то сразу начинается вот это всё.
То есть плюсы алгоритмического собеседования в том, что кандидат сразу слился? Так можно начинать разговор с фразы "спасибо, вы нам не подходите" — будут сливаться ещё быстрее.
Ну да, передумали в гите. Может майкрософт был убедительнее, потому что у него гитхаб. А может гитовцы просто посмотрели вокруг и решили принять реальность, где у больших фирм есть большие монорепы.
Не похоже. Скорее, они сказали, давайте, мы переделаем гит под гигантские монорепы. А те им сказали, это в архитектуру не вписывается, вы б ещё дум туда встроили. Используйте гит правильно и будет вам счастье. Ну а в фейсбуке подумали, да ну ещё разбираться, правильно использовать, и пошли к меркуриалу, которому деваться было некуда.
а вы нанимаете людей разговаривать за жизнь, решать алгоритмические задачи или писать рабочий код? если первое — то надо проверять, как они разговаривают за жизнь, если второе — то как они решают литкод. ну и так далее.
проверять, в идеале, надо умеют ли они делать ту работу, которую им потом придётся работать.
Вроде всё хорошо, оправдывают, ещё как. Подписку он бы в любом случае не купил. А так вон какой пост про feedly накатал. А теперь его и на хабр перевели. Прекрасно паттерн отработал, я считаю
Статья, сдаётся мне (а я и в оригинал заглянул), не про то, что теория относительности наконец-то опровергнута и информацию можно передавать быстрее скорости света. Так что вовсе не про «первую передачу информации с помощью телепортации» — это даже в переводе прямо сказано:
Транслируя затем другие параметры исходной частицы обычным физическим способом, можно зафиксировать это состояние
то есть, как и у всех, нужен обычный канал и телепортация.
Статья про то, что у фотона считывают несколько параметров, а не только один, таким образом из одного фотона можно вытащить (комбинируя с тем, что передано обычным физическим способом) больше одного бита информации.
Это важно, когда по квантовому каналу передаётся сам ключ. Он случайный, если его перехватят — пофиг, можно новый передать. Но если его перехватят — его нельзя использовать.
Ну аббревиатура же не ОШРО. Моего английского не хватило, чтоб понять, как из "ASP" получаются "шаблоны распределения" (General и Responsibility я догадался). Если в тексте встречается аббревиатура, надо давать расшифровку каждой буквы, а не только вольный перевод её смысла.
Конечно, читал. Я ж с этого комментарий и начал: выводы правильные ☺
И, опять, SQLite — полноценная база данных. В MariaDB, например, если подождать, пока она ничего не будет делать, тоже прекрасно можно файлы копировать, ничего не сломается. От нагрузки зависит, повезёт или нет.
MariaDB/MySQL быстрее, чем SQLite — и да и нет. Вопрос в деталях. Если запустить бенчмарк (тот же sysbench) c тысячами запросов в секунду и сотнями подключений — SQLite будет вообще не конкурент. Для HA же SQLite более чем достаточно почти всегда.
SQLite не очень хорошо работает с параллельными процессами записи? Неа. Вот как раз Да-а. Но где вы в HA видели сотни параллельных процессов записи? То есть это реальный недостаток SQLite, но в данном случае он не играет роли.
Нужно очень сильно постараться, чтобы запороть SQLite базу. Потому что это всего лишь файл с запросами в текстовом виде. Про это уже писали выше, полная чушь. SQLite — полноценная база данных, со страничной оранизацией данных. db разбит на страницы, там всё бинарное. Есть undo log и wal, как положено, для восстановления, если что. Вот как раз текстовый файл запороть — как два пальца.
В то время как MariaDB и PostgreSQL имеют довольно неплохие шансы накрыться при некорректном завершении работы. Плохие-плохие, восстановление данных после краша — это стандартная функциональность и MariaDB и PostgreSQL, она регулярно тестируется и регулярно же используется в проде (к сожалению). Это буква D в "ACID". Накрыться может всё, SQLite тоже, но шансы невелики.
Для бекапа SQLite достаточно на горячую (при запущенном HA) скопировать файлик базы. Как почти с любой базой данных — не-а, это хороший способ запороть базу (если уж выключение питания не помогло).
нужно или останавливать СУБД или пользоваться специальными инструментами экспорта — везде так, SQLite не исключение. Но там ничего сложного, запустил команду — получил бэкап, всё легко заскриптовывается.
Ну почему. Мы когда давали тестовое, срок вообще не ограничивали. Я называл срок в две недели как ориентировочный, типа, мы перестаём ждать, но присылать можно и позже. Это ж просто вежливость, кому сколько времени нужно, у кого сколько времени свободного есть.
Но я все тестовые сам делал вначале, и если в 10 минут не укладывался, то слишком сложное, не годится. Считалось, что кандидат может за пару часов разобраться.
c ИИ тоже есть, OtterTune. И вообще, это не так важно, раз можно подкрутить руками, то я готов поверить, что ИИ тоже может такое посоветовать.
Но вот настройками ядра уменьшить потребление памяти на 30%? Не ну строго говоря можно, задать там где-то, чтоб объём памяти, доступный пользовательским процессам, был меньше на треть — и хоба, MySQL жрёт меньше памяти. Потому что больше ему тупо не дадут. Надеюсь, там не это имелось в виду
Ну так по тексту вроде у браузера нет доступа к смс? Он просто подсказывает OS что в это поле нужен смс-код, и системная клавиатура предлагает подсказку. А браузер видит только то, что юзер вводит
Да я не знаю, карго-культ какой-то. Когда нанимают бегуна — его просят пробежать дистанцию, а не перечислить пять способов шнуровки кроссовок. А если программиста — то сразу начинается вот это всё.
То есть плюсы алгоритмического собеседования в том, что кандидат сразу слился? Так можно начинать разговор с фразы "спасибо, вы нам не подходите" — будут сливаться ещё быстрее.
Если в дампе действительно были числа 377 — это точно к РЕН ТВ, послание от рептилоидов.
Хотя что-то мне подсказывает, что там было 0377, а редактор убрал первый нолик, он не ни на что не влияет, правда?
Ну да, передумали в гите. Может майкрософт был убедительнее, потому что у него гитхаб. А может гитовцы просто посмотрели вокруг и решили принять реальность, где у больших фирм есть большие монорепы.
Не похоже. Скорее, они сказали, давайте, мы переделаем гит под гигантские монорепы. А те им сказали, это в архитектуру не вписывается, вы б ещё дум туда встроили. Используйте гит правильно и будет вам счастье. Ну а в фейсбуке подумали, да ну ещё разбираться, правильно использовать, и пошли к меркуриалу, которому деваться было некуда.
можно я тоже оставлю саркастический комментарий?
а вы нанимаете людей разговаривать за жизнь, решать алгоритмические задачи или писать рабочий код? если первое — то надо проверять, как они разговаривают за жизнь, если второе — то как они решают литкод. ну и так далее.
проверять, в идеале, надо умеют ли они делать ту работу, которую им потом придётся работать.
Вроде всё хорошо, оправдывают, ещё как. Подписку он бы в любом случае не купил. А так вон какой пост про feedly накатал. А теперь его и на хабр перевели. Прекрасно паттерн отработал, я считаю
Что-то кажется тут учёный изнасиловал журналиста.
Статья, сдаётся мне (а я и в оригинал заглянул), не про то, что теория относительности наконец-то опровергнута и информацию можно передавать быстрее скорости света. Так что вовсе не про «первую передачу информации с помощью телепортации» — это даже в переводе прямо сказано:
то есть, как и у всех, нужен обычный канал и телепортация.
Статья про то, что у фотона считывают несколько параметров, а не только один, таким образом из одного фотона можно вытащить (комбинируя с тем, что передано обычным физическим способом) больше одного бита информации.
Это важно, когда по квантовому каналу передаётся сам ключ. Он случайный, если его перехватят — пофиг, можно новый передать. Но если его перехватят — его нельзя использовать.
Ну аббревиатура же не ОШРО. Моего английского не хватило, чтоб понять, как из "ASP" получаются "шаблоны распределения" (General и Responsibility я догадался). Если в тексте встречается аббревиатура, надо давать расшифровку каждой буквы, а не только вольный перевод её смысла.
Ну вот как можно написать статью про какую-то аббревиатуру, постоянно её использовать, воткнуть в название и ни разу — ни разу! — её не расшифровать?
GRASP — General Responsibility Assignment Software Principles
Конечно, читал. Я ж с этого комментарий и начал: выводы правильные ☺
И, опять, SQLite — полноценная база данных. В MariaDB, например, если подождать, пока она ничего не будет делать, тоже прекрасно можно файлы копировать, ничего не сломается. От нагрузки зависит, повезёт или нет.
Выводы правильные, "просто используйте SQLite". Аргументы — неправильные.
MariaDB/MySQL быстрее, чем SQLite — и да и нет. Вопрос в деталях. Если запустить бенчмарк (тот же sysbench) c тысячами запросов в секунду и сотнями подключений — SQLite будет вообще не конкурент. Для HA же SQLite более чем достаточно почти всегда.
SQLite не очень хорошо работает с параллельными процессами записи?
Неа. Вот как раз Да-а. Но где вы в HA видели сотни параллельных процессов записи? То есть это реальный недостаток SQLite, но в данном случае он не играет роли.Нужно очень сильно постараться, чтобы запороть SQLite базу. Потому что это всего лишь файл с запросами в текстовом виде. Про это уже писали выше, полная чушь. SQLite — полноценная база данных, со страничной оранизацией данных. db разбит на страницы, там всё бинарное. Есть undo log и wal, как положено, для восстановления, если что. Вот как раз текстовый файл запороть — как два пальца.
В то время как MariaDB и PostgreSQL имеют довольно неплохие шансы накрыться при некорректном завершении работы. Плохие-плохие, восстановление данных после краша — это стандартная функциональность и MariaDB и PostgreSQL, она регулярно тестируется и регулярно же используется в проде (к сожалению). Это буква D в "ACID". Накрыться может всё, SQLite тоже, но шансы невелики.
Для бекапа SQLite достаточно на горячую (при запущенном HA) скопировать файлик базы. Как почти с любой базой данных — не-а, это хороший способ запороть базу (если уж выключение питания не помогло).
нужно или останавливать СУБД или пользоваться специальными инструментами экспорта — везде так, SQLite не исключение. Но там ничего сложного, запустил команду — получил бэкап, всё легко заскриптовывается.
Break/watch ещё был хороший пункт. При выборе, выскакивала форма с вопросом "Какие часы вы хотите сломать?" и предлагались варианты на выбор
Ну почему. Мы когда давали тестовое, срок вообще не ограничивали. Я называл срок в две недели как ориентировочный, типа, мы перестаём ждать, но присылать можно и позже. Это ж просто вежливость, кому сколько времени нужно, у кого сколько времени свободного есть.
Но я все тестовые сам делал вначале, и если в 10 минут не укладывался, то слишком сложное, не годится. Считалось, что кандидат может за пару часов разобраться.
Free Software Foundation предупреждает:
c ИИ тоже есть, OtterTune. И вообще, это не так важно, раз можно подкрутить руками, то я готов поверить, что ИИ тоже может такое посоветовать.
Но вот настройками ядра уменьшить потребление памяти на 30%? Не ну строго говоря можно, задать там где-то, чтоб объём памяти, доступный пользовательским процессам, был меньше на треть — и хоба, MySQL жрёт меньше памяти. Потому что больше ему тупо не дадут. Надеюсь, там не это имелось в виду
А пруфы хоть какие-то будут? Или мы так просто должны поверить, что можно подкрутить настройки ядра и MySQL будет использовать на треть меньше памяти?
Я знаю, что перевод, и что в оригинале пруфов нет. Стоило бы найти и приложить, если они есть. Или не переводить, если это уж совсем полная лажа.
Ну так по тексту вроде у браузера нет доступа к смс? Он просто подсказывает OS что в это поле нужен смс-код, и системная клавиатура предлагает подсказку. А браузер видит только то, что юзер вводит