The feedstock (natural gas for example) is desulphurized, mixed with steam and converted to synthesis gas over nickel catalysts at approximately 40 bar and 800°C in the primary reformer. The Uhde steam reformer is a top-fired reformer which has tubes made of centrifugally-cast alloy steel and a proprietary cold outlet manifold system to enhance reliability.
Это вот тот самый паровой реформинг, у которого вход – природный газ, выход – аммиак. Другие варианты требуют водород, который в получении энергетически дороже получить, чем метан нагреть для реформинга. Отсюда и цены на аммиачные удобрения, строго следующие за ценами на метан.
Покажите Ваши минимальные знания, приведя хоть какие-то рассчёты, а не ссылаясь на статьи, которые сами не прочитали.
В качестве источников буду приводить википедию, что б не было ссылок на "мантры из совковых школьных учебников".
Какие из удобрений делаются, по-вашему, из нефти и газа? Фосфаты? Нитраты? Аммиачные соли?
Берём аммиачные соли. Их получают разными способами из, внезапно, аммиака (источник). При этом на получение тонны аммиака требуется порядка 1000 кубов газа (источник).
По ценам, вот тут говорят, что аммиачные соли стоят 380USD за тонну в ЕС. А вот тут говорят, что газ в том же ЕС стоит 33.90EUR/mWh, что равно 357.6EUR/1000m3 (перевод мегаватт в кубометры), то есть по сегодняшнему курсу 386USD за тысячу кубов. Вывод: цена на аммиачные соли примерно полностью состоит из цены на газ. Остальные удобрения предоставлю разбирать вам.
А из вышеупомянутых высоких технологий что из нефти и газа делается? Высокочистый кремний? Фоторезист? Литографы?
Of the 2014 world helium total production of about 32 million kg (180 million standard cubic meters) helium per year, the largest use (about 32% of the total in 2014) is in cryogenic applications, most of which involves cooling the superconducting magnets in medical MRI scanners and NMR spectrometers.[163] Other major uses were pressurizing and purging systems, welding, maintenance of controlled atmospheres, and leak detection. Other uses by category were relatively minor fractions.[162]
При этом основной способ добычи гелия – опять же внезапно – из природного газа:
For large-scale use, helium is extracted by fractional distillation from natural gas, which can contain as much as 7% helium.
То есть как минимум в двух утверждениях – про удобрения (конкретно – про аммиачные соли) и про высокие технологии (высокочистый кремний) Вы сами не удосужились прочитать.
Объём работы QA не сильно меняется. Более того, эти самые QA регулярно встречая пару ошибок оказываются очень полезными сотрудниками, и также получают бонусы за найденные проблемы в виде премий и "достижений" для повышения.
Опять же с позиции "практичного циника" я представляю, что в среднем вокруг средние люди. Возможно есть компании, у которых средний программист – это педантичный senior-маньяк с чувством перфекционизма и большим опытом чтения кода, но что-то мне подсказывает, что такие компании заканчивают как Sun Microsystems.
Уточню: я позицию "практического циника" озвучиваю в применении к позиции за зарплату. Естественно, если это фриланс, своя компания или опенсорс – эта позиция и анализ буду неприменимы.
Зачем? ... Если вы спросите своего лида нужен ли код-ревью, он ответит - конечно, потому что пропущенная на ревью ошибка, это его головная боль, задержанная в будущем задача или новая бага. С другой стороны, если вы подойдете с этим вопросом к продюсеру, особенно перед майлстоуном - да на agile он все эти ваши код-ревью вертел - неделя до сдачи, вагон тасок и два поезда багов - фичи надо пилить, а не в эпистолярном жанре упражняться и письма друг другу писать. Время разработчиков и деньги компании – ключевые вещи, если вы посмотрите на причины проведения код-ревью. ...
А где в этом всём польза (в деньгах) собственно разработчику? Если ревью уменьшает головную боль лида – пусть лид и занимается ревью.
Объясню: допустим, я, один из ревьюверов, заметил, что какой-то код "попахивает", непонятен или неоптимален. У меня два варианта: начать обсуждение и не начинать.
Допустим, я не начал, и просто нажал "одобрить". Через пол года возникла проблема. Если проблему спустили решать кому-то другому, то меня это вообще не касается. А если мне – то я могу героически решить эту проблему и, также героически порешав ещё пяток таких проблем, получить премию.
Теперь предположим обратное, и я начал обсуждение. Дальше опять же два варианта: первый "само программирование может быть связано с эмоциями", и на меня кто-то обиделся, или я добавил кому-то работы. Результат тут строго отрицательный, а я получу ровно такую же дополнительную работу в своём собственном ревью в следующий раз. Второй – коллеги мне сказали "спасибо", и, возможно написали в конце отчётного периода, что "Вася делает классные код-ревью". В этом случае результат околонулевой, потому что я не видел ещё ни одной компании, в которой бы этот показатель был хоть сколько-нибудь важным.
Итого: проделав анализ усилий и результата получаем, что кроме каких-то тривиальных случаев (типа указать товарищу на тривиальную опечатку, из-за которой он огребёт проблемный релиз на следующий день) всегда выгоднее одобрять ревью без особых замечаний.
«Согласны-не согласны» в математике только к корректности применимо. Так-то для размерностей фракталов идея простая: размерность это то, во сколько раз изменяется обьем множества (=площадь для фракталов на плоскости) при изменении линейных размеров.
Собственный опыт из одной западноевропейской страны:)
Жить, действительно, можно, вот только протечки из ванных комнат через потолок, например, видел наверное в каждом третьем доме, пока смотрел как для аренды, так и для покупки. Похожая история с системами водоснабжения и центрального отопления: "всё течёт, все меняется". Дома, естественно, "эконом-класса".
Поработав несколько лет с flask и tornado выбираю теперь только django (+drf) именно для веба. Для микросервисов - grpc. А, и машины с АКПП предпочту;)
Этот ваш "try, запоминающий цепочку вызовов" давно придумали, монады называются.
Вообще вариантов, как сделать
прочитали из базы()
обработали()
записали результат()
придумали примерно два: либо через исключения, либо через монады. Они, конечно, стектрейс сами-по-себе не запоминают, но всегда можно сделать специальный вариант Either, у которого Left будет хранить хоть стектрейс, хоть вообще весь контекст.
Интересно и то, что все эти американско-европейские субурбы начинают разваливаться лет так через 10-15 после постройки. Содержание их в порядке стоит очень дорого.
Сравним с хрущевками/брежневками, простоявшими кое-где вообще без обслуживания все девяностые.
Но да, в отдельном доме сам себе хозяин, никто по потолку не ходит, и клапан в спальне не выводит.
Для одного небольшого проекта использую облачную версию. Разного функционала и удобностей очень не хватает (например, ссылки на создание/открытие merge request в ответе на git push прямо в консоли). Но именно проблем пока не было.
Оно галлюцинировать не начнет? В том смысле что «вот код, вот тесты, все компилируется, тесты проходят, я сделяль», эдакое вольное сочинение на тему входящей задачи.
Как-то на одной из лекций по релятивистской астрофизике преподаватель поздоровался, объявил «тема сегодняшней лекции - что такое свет?», повернулся к доске и следующие полтора часа безостановочно писал интегралы и дифуры. Подскажите: как из этого можно было содержательный комикс сделать?
Как учебное пособие или результат лабы - отлично (только добавьте py.typed!).
Для реальных задач - отказать:( уж очень много недочётов (например: вычитывает все данные в память, полно fullscan-операций, нет покрытия тестами - test_database.py явно не оно:), нет проверки заявленных версий питона через tox)
С 22 года переехал с pycharm на vscode/vscodium. Сколько ни пользуюсь - впечатление, что авторы о пользовательском опыте особо не задумываются:) Всё-таки это не IDE, а редактор с набором рассогласованных плагинов от разных авторов.
На картинке комбайн. Это они так с типами работают?
Вы свою ссылку сами почитайте. Там в начале же:
Это вот тот самый паровой реформинг, у которого вход – природный газ, выход – аммиак. Другие варианты требуют водород, который в получении энергетически дороже получить, чем метан нагреть для реформинга. Отсюда и цены на аммиачные удобрения, строго следующие за ценами на метан.
Покажите Ваши минимальные знания, приведя хоть какие-то рассчёты, а не ссылаясь на статьи, которые сами не прочитали.
В качестве источников буду приводить википедию, что б не было ссылок на "мантры из совковых школьных учебников".
Берём аммиачные соли. Их получают разными способами из, внезапно, аммиака (источник). При этом на получение тонны аммиака требуется порядка 1000 кубов газа (источник).
По ценам, вот тут говорят, что аммиачные соли стоят 380USD за тонну в ЕС. А вот тут говорят, что газ в том же ЕС стоит 33.90EUR/mWh, что равно 357.6EUR/1000m3 (перевод мегаватт в кубометры), то есть по сегодняшнему курсу 386USD за тысячу кубов. Вывод: цена на аммиачные соли примерно полностью состоит из цены на газ. Остальные удобрения предоставлю разбирать вам.
Открываем Википедию (мне лень было переводить):
(выделение моё).
При этом основной способ добычи гелия – опять же внезапно – из природного газа:
То есть как минимум в двух утверждениях – про удобрения (конкретно – про аммиачные соли) и про высокие технологии (высокочистый кремний) Вы сами не удосужились прочитать.
Вообще-то почти всё вокруг из нефти и газа делается, включая еду (удобрения!) и эти добрую часть этих самых высоких технологий.
А вот это – верный подход!
Объём работы QA не сильно меняется. Более того, эти самые QA регулярно встречая пару ошибок оказываются очень полезными сотрудниками, и также получают бонусы за найденные проблемы в виде премий и "достижений" для повышения.
Опять же с позиции "практичного циника" я представляю, что в среднем вокруг средние люди. Возможно есть компании, у которых средний программист – это педантичный senior-маньяк с чувством перфекционизма и большим опытом чтения кода, но что-то мне подсказывает, что такие компании заканчивают как Sun Microsystems.
Уточню: я позицию "практического циника" озвучиваю в применении к позиции за зарплату. Естественно, если это фриланс, своя компания или опенсорс – эта позиция и анализ буду неприменимы.
Давайте я побуду практичным циником.
А где в этом всём польза (в деньгах) собственно разработчику? Если ревью уменьшает головную боль лида – пусть лид и занимается ревью.
Объясню: допустим, я, один из ревьюверов, заметил, что какой-то код "попахивает", непонятен или неоптимален. У меня два варианта: начать обсуждение и не начинать.
Допустим, я не начал, и просто нажал "одобрить". Через пол года возникла проблема. Если проблему спустили решать кому-то другому, то меня это вообще не касается. А если мне – то я могу героически решить эту проблему и, также героически порешав ещё пяток таких проблем, получить премию.
Теперь предположим обратное, и я начал обсуждение. Дальше опять же два варианта: первый "само программирование может быть связано с эмоциями", и на меня кто-то обиделся, или я добавил кому-то работы. Результат тут строго отрицательный, а я получу ровно такую же дополнительную работу в своём собственном ревью в следующий раз. Второй – коллеги мне сказали "спасибо", и, возможно написали в конце отчётного периода, что "Вася делает классные код-ревью". В этом случае результат околонулевой, потому что я не видел ещё ни одной компании, в которой бы этот показатель был хоть сколько-нибудь важным.
Итого: проделав анализ усилий и результата получаем, что кроме каких-то тривиальных случаев (типа указать товарищу на тривиальную опечатку, из-за которой он огребёт проблемный релиз на следующий день) всегда выгоднее одобрять ревью без особых замечаний.
«Согласны-не согласны» в математике только к корректности применимо. Так-то для размерностей фракталов идея простая: размерность это то, во сколько раз изменяется обьем множества (=площадь для фракталов на плоскости) при изменении линейных размеров.
Собственный опыт из одной западноевропейской страны:)
Жить, действительно, можно, вот только протечки из ванных комнат через потолок, например, видел наверное в каждом третьем доме, пока смотрел как для аренды, так и для покупки. Похожая история с системами водоснабжения и центрального отопления: "всё течёт, все меняется". Дома, естественно, "эконом-класса".
Поработав несколько лет с flask и tornado выбираю теперь только django (+drf) именно для веба. Для микросервисов - grpc. А, и машины с АКПП предпочту;)
Этот ваш "try, запоминающий цепочку вызовов" давно придумали, монады называются.
Вообще вариантов, как сделать
придумали примерно два: либо через исключения, либо через монады. Они, конечно, стектрейс сами-по-себе не запоминают, но всегда можно сделать специальный вариант
Either, у которогоLeftбудет хранить хоть стектрейс, хоть вообще весь контекст.Интересно и то, что все эти американско-европейские субурбы начинают разваливаться лет так через 10-15 после постройки. Содержание их в порядке стоит очень дорого.
Сравним с хрущевками/брежневками, простоявшими кое-где вообще без обслуживания все девяностые.
Но да, в отдельном доме сам себе хозяин, никто по потолку не ходит, и клапан в спальне не выводит.
Для одного небольшого проекта использую облачную версию. Разного функционала и удобностей очень не хватает (например, ссылки на создание/открытие merge request в ответе на git push прямо в консоли). Но именно проблем пока не было.
Оно галлюцинировать не начнет? В том смысле что «вот код, вот тесты, все компилируется, тесты проходят, я сделяль», эдакое вольное сочинение на тему входящей задачи.
А в чем проблема с широтностью? У КА Гонец наклонение 82.5 градуса, 12 аппаратов всего. Больше про экваториальные области интересно как-раз.
Как-то на одной из лекций по релятивистской астрофизике преподаватель поздоровался, объявил «тема сегодняшней лекции - что такое свет?», повернулся к доске и следующие полтора часа безостановочно писал интегралы и дифуры. Подскажите: как из этого можно было содержательный комикс сделать?
А, да, пробовали. LISP называется:)
Как учебное пособие или результат лабы - отлично (только добавьте py.typed!).
Для реальных задач - отказать:( уж очень много недочётов (например: вычитывает все данные в память, полно fullscan-операций, нет покрытия тестами - test_database.py явно не оно:), нет проверки заявленных версий питона через tox)
‘du -hs | sort -h’ в помощь.
С 22 года переехал с pycharm на vscode/vscodium. Сколько ни пользуюсь - впечатление, что авторы о пользовательском опыте особо не задумываются:) Всё-таки это не IDE, а редактор с набором рассогласованных плагинов от разных авторов.
С подорожником можно сразу две поездки в автобусе оплачивать. Только там очень интересный интерфейс сделан, спросите у кондуктора:)