История сложная и видимо еще не закончена. Желаю вам успехов в вашем проекте, однако стороны кажется рискованная тема влезать в стартап имя без финансов и с проблемами со здоровьем, кажется что на долгом сроке это будет непростым испытанием.
У меня было впечатление что HTTP/2 создан на основе QUIC, однако нет, там был другой протокол SPDY. Однако QUIC согласно википедии появился в chrome под экспериментальным флагом в 2013
Объяснение самих ячеек более менее понятно, но как это штука переходит в режим циклона уже сложновато. Были вот такие торы, а стало что-то непонятное с глазом.
Есть ли связь у торнадо и циклонов, типа "циклоны вызывают торнадо" или это отдельные явления?
Спасибо, пригодилось. Довольно мало информации на эту тему, часть по идее только в исходниках доступна. Например второй аргумент у конструктора BaseInputConnection(). Чтобы передавались сырые события нужно не только TYPE_NULL, но и указать второй параметр как false.
В Rust то как раз очень даже можно, ни одной из вышеперечисленных проблем в Rust нет.
В смысле нет? Куда они делись? Я так понимаю что проблемы с целочисленным переполнением никуда не делись, i + 1 на расте будет работать как работает соответствующая инструкция процессора. В debug они выбрали панику, но в релизе тот же самый wrap around.
В какой-то момент пропадают иллюзии что все можно организовать простыми и логичными решениями. Терминалы и командная строка вроде со стороны такой простой unix-way, а сколько у него под капотом сложностей и концепций чтобы пользователю казалось что все просто.
Почему терминал гавкнул?
Нужное пояснение, гавкающий терминал читается конечно непривычно.
Больше похоже на набор слов, чем на связанную речь.
Такое же впечатление. Попытался понять кто такой Delivery Manager и в чем заключается проблема, и прочитав значительную часть текста не удалось ухватить ни одной полезной мысли.
Возможно это не самое лучшее место для выяснения. Чтобы понять странная она или нет, я бы предложил сначала выяснить как много людей понимает эту метафору в том смысле в каком заложил ее автор статьи. Если для многих она понятна, значит метафора выполняет свою задачу в статье.
По корням: эту метафору не автор придумал, я помню что она ходила в анекдотах во времена "новых русских", т.е. у нее уже есть какой-то культурный след - можно поискать. Было время когда у кого-то появлялись крутейшие машины, а кому-то для выживания надо было вырастить картошку на зиму - по моему история с тех времен.
Что касается практических вопросов: погребов, тыкв, матизов, частоты полива картохи - по моему все не туда.
Когда говорят метафору перевозки картохи в феррари я представляю не то чтобы заехал в ашан и купил 2кг мытой картошки, а приехал на дачу или рынок и взял шесть мешков, закинул в багажник и отвез в погреб. Ну то есть не тонну, но и не пару килограмм. Процесс грязный, дороги неподходящие и сомнительные для спорткара, усвинякаешь машину или повредишь подвеску - можно ожидать что устранение потенциального ущерба будет больше чем было заказать газель с грузчиком. Вот такие чисто мои ассоциации с метафорой.
Вы на каждый тип поездки покупаете отдельный авто?
Есть более менее универсальные автомобили.
Спорткары типа ламбрджини, феррари или макларен покупать имеет смысл отдельно, когда проблема обычных перевозок закрыта - по крайней мере я так себе представляю. Посмотрите например феррари с авито:
За 60 млн бу машинка, не знаю, брать ее для поездок на дачу или на рынок за картошкой выглядит очень сомнительной идеей для меня. Если надо иногда возить картошку или цемент, феррари покупал бы третьей или четвертой машиной.
Не очень понятно зачем вы прикопались к метафоре, по моему она вполне понятная - дорогой инструмент подходящий к решению задачи хуже чем более дешевый инструмент.
сотрудники завалили нас письмами с просьбой выйти в офис
Как это рассказывает сотрудником - это другой вопрос, перед этим высшее руководство или приняло решение само или должно было посовещаться с менеджерами что они думают.
Я думаю что если компания решила что она строит "компанию офиса" и просит всех выйти в офис - это ок. Для тех для кого это не приемлемо много остается много компаний с удалёнкой, думаю намного больше чем раньше.
Я довольно сильно прокачался когда впервые пришел офис: сначала за обсуждением задач с сотрудниками, и вообще наблюдая как они мыслят и далее картерный рост - управление, развитие продукта и прочее. Мне кажется у "старого" офиса была очень мощная синергическая составляющая присутствие людей в одном месте. "Новый" офис - когда команда например распределена по разным офисам, разным городам - во многом лишается такой синергии.
Не каждый офис будет обладать нужной энергией для роста и развития, очень важно кто там сидит и что делает. Интересно было бы послушать доводы больших корпораций зажимающих удалёнку, я так представляю что менеджеры были на совещаниях и делились своими наблюдениями - вот это интересно.
Меня gcc замучил предупреждениями что объекты инициализируются не в порядка объявления в классе. Хоспаде какая тебе разница как я запишу m_count(0), m_ptr(NULL). А тут видимо другой компилятор или версия поновее и когда это действительно нужно предупреждения нет.
Важная вещь, спасибо автору оригинала и за перевод.
Одно время тоже решал проблему скорости компиляции fmt, но не слишком долго и упорно. У меня была какая-то идея (помню смутно) что в отладочной версии использовать форматирование типа printf() которое не проверяет типо-безопасность но ускоряет компиляцию пока работаешь. Когда собираешь релиз (или на CI) - уже можно выполнить полную проверку, когда на этапе компиляции детектируются проблемы с несоответствием фактических типов указанным в строке форматирования.
Почему ваш (судя по профилю) JetBrain перешел на подписочную модель для IDE? Потому что продукт достиг такого уровня что у людей пропала ценность в покупке обновлений. Можно было несколько лет сидеть на старой версии, потому что в новых не было ничего такого ради чего стоило платить. JetBrain починил для себя это подписками, так что внедрять сомнительные фичы в продукт чтобы продать обновления.
Мне не показалось что статья не про то что раньше было лучше. Статья больше про предел развития ПО и то как мы это воспринимаем. Например у продукта нет обновлений, воспринимаем мы это как то что продукт не развивается и заброшен и пользоваться им не нужно. А может быть просто продукт как инструмент работает как нужно.
Другой смысл из статьи что с ростом версии мы не всегда получаем улучшения. Вместе с улучшениями иногда приходит кое-что еще, не всегда желательное. Вот есть два стула: использовать старую версию продукта в которой нет вредных изменений или смирится с ними и перейти на новую версию из-за полезных изменений.
История сложная и видимо еще не закончена. Желаю вам успехов в вашем проекте, однако стороны кажется рискованная тема влезать в стартап имя без финансов и с проблемами со здоровьем, кажется что на долгом сроке это будет непростым испытанием.
У меня было впечатление что HTTP/2 создан на основе QUIC, однако нет, там был другой протокол SPDY. Однако QUIC согласно википедии появился в chrome под экспериментальным флагом в 2013
Очень удобная штука. На Linux работаю эпизодически и недавно поставил far2l на CentOS - очень здорово. Огромное спасибо авторам
Спасибо за интересную статью (осиливал несколько дней) и за ответы!
Торнадо тоже строится на базе ячеек Бенара?
Объяснение самих ячеек более менее понятно, но как это штука переходит в режим циклона уже сложновато. Были вот такие торы, а стало что-то непонятное с глазом.
Есть ли связь у торнадо и циклонов, типа "циклоны вызывают торнадо" или это отдельные явления?
Спасибо, пригодилось. Довольно мало информации на эту тему, часть по идее только в исходниках доступна. Например второй аргумент у конструктора BaseInputConnection(). Чтобы передавались сырые события нужно не только TYPE_NULL, но и указать второй параметр как false.
В смысле нет? Куда они делись? Я так понимаю что проблемы с целочисленным переполнением никуда не делись, i + 1 на расте будет работать как работает соответствующая инструкция процессора. В debug они выбрали панику, но в релизе тот же самый wrap around.
В свое время пропустил игру Фараон, только не давно про нее узнал. Очень интересный проект!
В какой-то момент пропадают иллюзии что все можно организовать простыми и логичными решениями. Терминалы и командная строка вроде со стороны такой простой unix-way, а сколько у него под капотом сложностей и концепций чтобы пользователю казалось что все просто.
Нужное пояснение, гавкающий терминал читается конечно непривычно.
Ого, огромная работа!
Наверное очень помогло ребятам разрабатывающем GC что javascript однопоточный. Алгоритм конечно эвристика на эвристике.
Как вы это сами разбирали по исходным кода или есть такого рода документация у Chrome?
Такое же впечатление. Попытался понять кто такой Delivery Manager и в чем заключается проблема, и прочитав значительную часть текста не удалось ухватить ни одной полезной мысли.
Возможно это не самое лучшее место для выяснения. Чтобы понять странная она или нет, я бы предложил сначала выяснить как много людей понимает эту метафору в том смысле в каком заложил ее автор статьи. Если для многих она понятна, значит метафора выполняет свою задачу в статье.
По корням: эту метафору не автор придумал, я помню что она ходила в анекдотах во времена "новых русских", т.е. у нее уже есть какой-то культурный след - можно поискать. Было время когда у кого-то появлялись крутейшие машины, а кому-то для выживания надо было вырастить картошку на зиму - по моему история с тех времен.
Что касается практических вопросов: погребов, тыкв, матизов, частоты полива картохи - по моему все не туда.
Если в мешках картошки, то очень много :)
Когда говорят метафору перевозки картохи в феррари я представляю не то чтобы заехал в ашан и купил 2кг мытой картошки, а приехал на дачу или рынок и взял шесть мешков, закинул в багажник и отвез в погреб. Ну то есть не тонну, но и не пару килограмм. Процесс грязный, дороги неподходящие и сомнительные для спорткара, усвинякаешь машину или повредишь подвеску - можно ожидать что устранение потенциального ущерба будет больше чем было заказать газель с грузчиком. Вот такие чисто мои ассоциации с метафорой.
Есть более менее универсальные автомобили.
Спорткары типа ламбрджини, феррари или макларен покупать имеет смысл отдельно, когда проблема обычных перевозок закрыта - по крайней мере я так себе представляю. Посмотрите например феррари с авито:
За 60 млн бу машинка, не знаю, брать ее для поездок на дачу или на рынок за картошкой выглядит очень сомнительной идеей для меня. Если надо иногда возить картошку или цемент, феррари покупал бы третьей или четвертой машиной.
Не очень понятно зачем вы прикопались к метафоре, по моему она вполне понятная - дорогой инструмент подходящий к решению задачи хуже чем более дешевый инструмент.
Как это рассказывает сотрудником - это другой вопрос, перед этим высшее руководство или приняло решение само или должно было посовещаться с менеджерами что они думают.
Я думаю что если компания решила что она строит "компанию офиса" и просит всех выйти в офис - это ок. Для тех для кого это не приемлемо много остается много компаний с удалёнкой, думаю намного больше чем раньше.
Я довольно сильно прокачался когда впервые пришел офис: сначала за обсуждением задач с сотрудниками, и вообще наблюдая как они мыслят и далее картерный рост - управление, развитие продукта и прочее. Мне кажется у "старого" офиса была очень мощная синергическая составляющая присутствие людей в одном месте. "Новый" офис - когда команда например распределена по разным офисам, разным городам - во многом лишается такой синергии.
Не каждый офис будет обладать нужной энергией для роста и развития, очень важно кто там сидит и что делает. Интересно было бы послушать доводы больших корпораций зажимающих удалёнку, я так представляю что менеджеры были на совещаниях и делились своими наблюдениями - вот это интересно.
Меня gcc замучил предупреждениями что объекты инициализируются не в порядка объявления в классе. Хоспаде какая тебе разница как я запишу m_count(0), m_ptr(NULL). А тут видимо другой компилятор или версия поновее и когда это действительно нужно предупреждения нет.
Важная вещь, спасибо автору оригинала и за перевод.
Одно время тоже решал проблему скорости компиляции fmt, но не слишком долго и упорно. У меня была какая-то идея (помню смутно) что в отладочной версии использовать форматирование типа printf() которое не проверяет типо-безопасность но ускоряет компиляцию пока работаешь. Когда собираешь релиз (или на CI) - уже можно выполнить полную проверку, когда на этапе компиляции детектируются проблемы с несоответствием фактических типов указанным в строке форматирования.
Почему ваш (судя по профилю) JetBrain перешел на подписочную модель для IDE? Потому что продукт достиг такого уровня что у людей пропала ценность в покупке обновлений. Можно было несколько лет сидеть на старой версии, потому что в новых не было ничего такого ради чего стоило платить. JetBrain починил для себя это подписками, так что внедрять сомнительные фичы в продукт чтобы продать обновления.
Мне не показалось что статья не про то что раньше было лучше. Статья больше про предел развития ПО и то как мы это воспринимаем. Например у продукта нет обновлений, воспринимаем мы это как то что продукт не развивается и заброшен и пользоваться им не нужно. А может быть просто продукт как инструмент работает как нужно.
Другой смысл из статьи что с ростом версии мы не всегда получаем улучшения. Вместе с улучшениями иногда приходит кое-что еще, не всегда желательное. Вот есть два стула: использовать старую версию продукта в которой нет вредных изменений или смирится с ними и перейти на новую версию из-за полезных изменений.