Сам знаешь, там торговля будет на спичках :)
Я, честно говоря, совсем никого не знаю, у кого бы первый оффер совсем хорош. Бывают, наверное, target hiring, вроде нанять одного из 10, кто может написать нормальный GC, но такие люди не читают такие рекомендации по повышению ЗП, им главное GC в новом месте написать.
Не в гугле ли недавно уволили кого-то за массовое разглашение ЗП и бонусов? :)
Для меня бы это был red flag о компании. Благо, что мы живем в месте, где выбор большой, если одна компания попалась странная, всегда есть получше за поворотом.
Важный момент. Для программистов, которые ищут первую работу в США — им практически без шанса повысить цифры в оффере, какие бы рекомендации они не имели. Рекрутеры знают лучше, за сколько они могут привезти народ из вашей страны в США, вряд ли вы будете первым у них.
Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.
Одна страница от нескольких отличается не сильно. В любом случае, это совсем не похоже на работу обычного пользователя. Не нужно сажать пользователя, один раз записать тест и использовать его постоянно. Производители часто делают много разного, чтобы пользователям было удобно, а не тестам. Chrome с его автоматической подгрузкой страниц, наверное, вообще убивают батарейку только потому, что кеш отключен, а браузер в пустую постоянно подгружает страницы, которые потом не используются.
Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.
> Как делать это правильно — как раз написано в статье.
Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память?
> И вот это есть рандомная запись на диск и это есть медленно.
Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.
Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)
Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory. Даже в случае чтения, потому что нет overhead на buffer pool, по другому организованы locking & latching, а так же используется другая схема организации данных в памяти, другой concurrency control. Это как раз и дает хороший прирост производительности, даже для чтения.
Есть огромное количество in-memory Db, которые даже и не задумываются о durability, то есть совсем не пишут на диск.
В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.
В общем автор статьи делает упор на то, что БД в памяти просто быстрее работают, потому что пишут только в память, а она быстрее.
Так же делает упор, что в disk oriented DB, в плохом случае, при каждом чтении мы будет лезть на диск. Что подразумевает, что он сравнивает in-memory DB запущенную на PC при достаточным объемом памяти с disk oriented DB, у которой нет достаточно памяти, чтобы держать необходимые страницы в buffer pool.
Это вопрос на 5+. Если кандидат достаточно быстро решает эту задачу, то я спрашиваю два вопроса. Один очень простой — как убедиться, что данные итераторы возвращают числа в возрастающем порядке. Второй — это как можно бы работать с массивом итераторов.
> Вы может не знаете, но 99% сотрудников амазона — это не IT персонал, это низко-оплачиваемые сотрудники выполняющие различную механическую работу. И им выбирать не приходится.
Откуда у вас такая информация? Я живу в городе Редмонд, работаю в городе Сиэтл, где находится компания Amazon. Amazon тут строится как сумашедший, с учетом всех достроенных офисных зданий они будут обладать 7% downtown города по слухам. Не думаю, что там сидят низко-оплачиваемые сотрудники выполняющие механические работы.
Я вам больше скажу — амазон предлагает на время праздников высокооплачиваемым сотрудникам (it специалистам) поработать на складах. Это не шутка.
Откуда у вас такая информация? Про придирчивость, про «либо амазон, либо без работы»?
Мне кажется или вы сами себе противоречите в своем комментарии?
Еще раз, никого не волнуют эти статьи в массовых СМИ. Ты выбираешь работу. В Сиэтле можешь получить оферы из Гугл, Майкрософт и Амазон (и еще куча компаний, но не важно). Скажем МС дает $140,000 и акций $40,000 на 4 года, в Гугле тебе дали $160,000 и акций $100,000 на 4 года, в Амазоне тебе дадут $150,000 и акций $100,000 на 2 года.
То есть пойдешь в МС заработаешь в следующем году 150 тыс, в гугле 185 тыс, в Амазоне 200 тыс. Вот и выбор встанет куда пойдешь. А еще посмотрите на рост акций во всех компаниях, чтобы выбор был бы еще интереснее.
Rand это один из вариантов, имхо для многих систем хочется иметь монотонно возрастающий идентификатор, смотри на docs.mongodb.com/manual/reference/method/ObjectId/#ObjectId
Статья заинтересовала, но как только дошел до «Domain-driven design (DDD)»…
Я, честно говоря, совсем никого не знаю, у кого бы первый оффер совсем хорош. Бывают, наверное, target hiring, вроде нанять одного из 10, кто может написать нормальный GC, но такие люди не читают такие рекомендации по повышению ЗП, им главное GC в новом месте написать.
Для меня бы это был red flag о компании. Благо, что мы живем в месте, где выбор большой, если одна компания попалась странная, всегда есть получше за поворотом.
Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.
Одна страница от нескольких отличается не сильно. В любом случае, это совсем не похоже на работу обычного пользователя. Не нужно сажать пользователя, один раз записать тест и использовать его постоянно. Производители часто делают много разного, чтобы пользователям было удобно, а не тестам. Chrome с его автоматической подгрузкой страниц, наверное, вообще убивают батарейку только потому, что кеш отключен, а браузер в пустую постоянно подгружает страницы, которые потом не используются.
Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.
Да, но они тестируют не так, как это будет делать обычный consumer. Видимо их тест это тупо перезагрузка одной и той же страницы с отключенным cache.
Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память?
> И вот это есть рандомная запись на диск и это есть медленно.
Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.
Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)
Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory. Даже в случае чтения, потому что нет overhead на buffer pool, по другому организованы locking & latching, а так же используется другая схема организации данных в памяти, другой concurrency control. Это как раз и дает хороший прирост производительности, даже для чтения.
Есть огромное количество in-memory Db, которые даже и не задумываются о durability, то есть совсем не пишут на диск.
В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.
В общем автор статьи делает упор на то, что БД в памяти просто быстрее работают, потому что пишут только в память, а она быстрее.
Так же делает упор, что в disk oriented DB, в плохом случае, при каждом чтении мы будет лезть на диск. Что подразумевает, что он сравнивает in-memory DB запущенную на PC при достаточным объемом памяти с disk oriented DB, у которой нет достаточно памяти, чтобы держать необходимые страницы в buffer pool.
Для vim используйте ctrl+[ (default тоже), по мне так намного удобнее.
Русскоязычный блог одного из инженеров SpaceX и заметка о происшествии https://blog.not-a-kernel-guy.com/2016/09/02/before-and-after-amos6/
Откуда у вас такая информация? Я живу в городе Редмонд, работаю в городе Сиэтл, где находится компания Amazon. Amazon тут строится как сумашедший, с учетом всех достроенных офисных зданий они будут обладать 7% downtown города по слухам. Не думаю, что там сидят низко-оплачиваемые сотрудники выполняющие механические работы.
Я вам больше скажу — амазон предлагает на время праздников высокооплачиваемым сотрудникам (it специалистам) поработать на складах. Это не шутка.
Мне кажется или вы сами себе противоречите в своем комментарии?
Еще раз, никого не волнуют эти статьи в массовых СМИ. Ты выбираешь работу. В Сиэтле можешь получить оферы из Гугл, Майкрософт и Амазон (и еще куча компаний, но не важно). Скажем МС дает $140,000 и акций $40,000 на 4 года, в Гугле тебе дали $160,000 и акций $100,000 на 4 года, в Амазоне тебе дадут $150,000 и акций $100,000 на 2 года.
То есть пойдешь в МС заработаешь в следующем году 150 тыс, в гугле 185 тыс, в Амазоне 200 тыс. Вот и выбор встанет куда пойдешь. А еще посмотрите на рост акций во всех компаниях, чтобы выбор был бы еще интереснее.