Ветропарки повышают температуру почвы под ними, и такое потепление заставляет почвенных микробов выделять больше углекислого газа (двуокиси углерода). То есть, ирония состоит в том, что хотя энергия ветра и снижает частично «углеродные выбросы» человечества, она также увеличивает «углеродные выбросы» от природных источников.
Звучит как полный бред, наброс и манипуляция, если честно.
Какой порядок «углеродного выброса» микробов на 1МВт выработанной энергии ветряками? Где сравнение с углеродным следом тепловых станций? Не приведен? А почему?
Технологии зелёной энергетики требуют десятикратного повышения добычи минеральных ресурсов по сравнению с электричеством, вырабатываемым при сжигании ископаемых видов топлива.
Отличный способ ввести в заблуждение читателя, не осознающего разницу между добычей минеральных ресурсов и ископаемого топлива.
Минеральные ресурсы, в отличии от ископаемого топлива, можно утилизировать по кругу неограниченное количество раз, вопрос лишь экономической выводы по сравнению с добычей.
Количество кобальта, неодима, лития и меди на Земле не изменится в случае полного перехода на зеленую энергетику. А вот нефть назад в скважины не вернешь без расхода количества энергии, превышающее уровень выработки на единицу массы.
Идеология WAL-журналов – это обеспечение атомарности и финальности транзакций, а это 50% букв в ACID. Я ожидаю что об этом рядовой разработчик должен знать, пусть даже не вдаваясь в детали реализации таких журналов.
Но деталях реализации протоколов распределенных систем вы с нуля и за три месяца не разберетесь.
Извините, но вы апеллируете мне моими же аргументами. Я выше писал:
Но сравнивать разработку с проектированиям трубопровода крайне не корректно, поскольку доступность внесения изменений в ПО гораздо ниже, чем в трубопровод, и бизнес ожидаемо пытается выжать из скорости разработки максимум, а это значит что изменение требований будет настолько часто, насколько это позволяет команда разработки.
Не я начал вереницу плохих аналогий. Я просто утверждаю, что любой бизнес пытается выжать ту скорость изменений, которая конструктивно возможна. Для разработки ПО это несравненно более высокая скорость, чем для других бизнесов, и потому проводить аналогии между проектированием ПО и проектированием водопровода или сети ресторанов просто не корректно.
Это просто совершенно разный класс проблем. В проектировании ПО в основном цена ошибки значительно ниже, но и размерность задачи (количество параметров, которые необходимо принимать во внимание) на порядок выше.
Проектируя сайт, вы заранее должны продумать, что будете делать, когда нагрузка увеличится в 1000 раз. От ресторана никто в принципе не ждет тысячекратный прирост наплыва посетителей.
Сколько у вас это займет время на освоение? Час, день?
Посмею утверждать что месяц, если хотим действительно серьезно разобраться, потому что NoSQL – это не только «тоже самое, но проще», но еще сложнее, потому что теперь нам нужно понимать, как работает георепликация, консенсус и синхронизяция между узлами, балансировка ключей, map-reduce и т.д.
Но в целом я согласен – чем более технологий знаешь, тем меньше необходимо времени на изучение следующей.
Я считаю что мозг был включен всегда у всех разработчиков. Я говорю, что как только мы достигаем точки «вообще не ваша проблема как придумать такую архитектуру» тут же добавляется еще один уровень абстракции, из-за которого «думать» – все еще «наша проблема», даже если мы – джун или мидл.
Вы ошибайтесь со скоростью внесения изменений на несколько порядков.
Да, ресторан может успеть стать неликвидным еще до того, как успеет открываться, так редко, но бывает. Но условия разработки – это когда шашлычная за неделю перестраивается в суши-бар, с возможностью по выходным принимать рок-концерт.
Просто приведите мне пожалуйста пример в любой из упоминаемых вами индустрий аналога понятия «пивот», когда за один год ресторан привращают в пивоварню, затем в завод по производсту амиака, а затем в лабораторию по производству вакцин.
Это примерно тот уровень изменений архитектуры, который ожидается бизнесом от команды разработки в ИТ.
То что вы приводите (рост интернет сетей) – это лишь количественное масштабирование, но не качественное. Как наращивать сеть интернет провайдера можно оценить еще в самом начале развития.
То есть по вашему джуны и мидлы тупо пишут код и вообще мозг не включают? Это не так, поскольку как только мы достигаем такого момента с точки зрения развития технологий (а мы его регулярно достигаем), прошлая работа джунов и мидлов становится не нужной, поскольку их работку можно автоматизировать. И в этот момент всем уровням разраработчиков, включая сеньйоров, приходится прыгнуть на один уровень асбтракции выше, где опять нужно включать голову.
В итоге через 10 лет команда, проектировавшая разводку воды по деревне занимается (условно) логистикой в масштабе Земли, с применением всех видов транспорта, учетом погоды, изменения цен и дипломатических отношений, с применением искуственного интеллекта, арендуя транспорт у поставщиков. Это буквально то что происходит с разработкой – то, что еще 10 лет назад делалось вручную сеньйорами, сегодня автоматизировано, а серьйоры отвечают за оркестрацию более высокого уровня.
Я лично не против чтобы сварщик или врач зарабатывал на уровне мидла, или даже сеньйора.
Но сравнивать разработку с проектированиям трубопровода крайне не корректно, поскольку доступность внесения изменений в ПО гораздо ниже, чем в трубопровод, и бизнес ожидаемо пытается выжать из скорости разработки максимум, а это значит что изменение требований будет настолько часто, насколько это позволяет команда разработки.
Где вы видели, чтобы план трубопровода города изменился еще до того, как закончились ремонтные работы согласно предыдущему плану, и в новом плане еще не проложенная труба уже успела стать неактуальной? В разработке ПО подобное происходит регулярно.
Кто-то назовет это «ошибкой планирования», но в действительно это лишь желание бизнеса бежать быстрее конкурентов. Если бизнес готов платить за накладные расходы, или жертвовать качеством, в этом нет проблемы, но в таком случае не нужно удивлятся, что всегда нужно выбрать что-то одно между «криво», «дорого» и «медленно».
Магия начала пропадать поскольку вы упустили самый важный аспект разработки: скорость изменения требований. Представьте теперь, что нужно делать все тоже самое, только в условиях перманентного перестраивания конфигурации в масштабе всего города.
Я бы посмотрел, как бы вы согласовывали изменения на лету между 30 ответственными за каждый кусок, решали вопросы перегрузки и недостатка ресурсов заложенных заранее, планировали запас и проектировали с учетом неопреденного будущего, а потом отчитывались почему перестройка происходит так долго и не эфективно.
А еще помимо воды нужно параллельно пустить лаву (по тем же трубам, но так чтобы они не смешивались), с возможностью разворачивать поток в обратном направлении, регулировать его скорость в зависимости от фазы луны и перераспределять нагрузку в автоматическом режиме, учитывая при этом постоянные ремонтные работы, но так чтобы вода никогда не пропадала у потребителей.
Между прочим, для токенизации кода и подсветки синтаксиса в xi-editor используется пакет syntect, который в свою очередь основан на моем заброшенном проекте sublimate по созданию open source клона Sublime Text 3 и на моем байндинге регулярных выражений oniguruma.
Так что мы по одну сторону баррикад гораздо больше, чем вам кажется.
Мне показалось, что ответ лежит на поверхности: использование IDE не является ни трудным, ни обязательным навыком для эфективной разработки.
Если дальше проводить аналогии, то я сравнил бы IDE с автоматической коробкой передач – кому-то с ней удобнее, а кому-то она будет мешать, если человек хорошо ездит на механике. Но вряд ли вам прийдет в голову утверждать, что те кто ездят на механике – плохие водители. И, как и автоматическая коробка передач для водителей, IDE не расширяет фундаментально ваши возможности как разработчика.
Большинство разработки — это скорее игра в «трубопровод», подключи здесь, дотащи туда, и убедись что не выльется по пути и не прорвёт от напора.
Если бы это было действительно так, то программистам платили бы столько же, сколько и трубопроводчикам, а трубопроводчики стали бы программистами, ведь при той же зарплате руки остаются чистыми.
Но по какой-то причине ни первого, ни второго не происходит.
Да, вот только разработчики в отличии от большинства реально могут работать просто думая за ужином, поскольку продумывание решения – это и есть значительная, если не бóльшая часть работы.
Тоже подумал что операция по сознательному направлению двухсоткилометровой глыбы в сторону Земли требует экстраординарных требований к безопасности, учитывая что падения даже километрового метеорита достаточно для глобальной катастрофы.
Не вполне понятна ситуация с сортировкой элементов перед суммированием, если такая возможность есть. Насколько это ухудшает/улучшает результат? Из вашей статьи кажется, что от этого больше вреда чем пользы, но это как-то противоречит моей интуиции, ведь если идти от меньших экспонет к большим, у нас есть шанс спастись от катастрофических округлений, например в случае с экспоненциальным распределением.
Как обстоят дела с сортировкой, если все значения одинакового знака? Можно ли считать что в таком случае сортировка точно не ухудшает результат? Если складывать отдельно положительные и отрицательные значения, но предварительно отсортировав их, ситуация лучше?
Ну и последний, практический вопрос: я правильно понимаю, что все приведенные алгоритмы не лучше простого перехода к арифметике с более высокой точностью? Скажем, если сравнивать приведенные алгориты на float против использования double в качестве аккамулятора.
Напоминаю, что дыроколы тоже писали самый сложный код своего времени. Без них современного программирования не было бы.
И это тоже написали вы:
Были люди, которые умели программировать на перфокартах. [...] Проблема в том, что они не отличные спецы. Если бы таких было большинство, мы бы никогда не перешли от машинного кода к асемблеру.
Один я вижу здесь прямое противоречие?
Проверочный вопрос: считаете ли вы, что контрибьютор компилятора может быть «неполноценным професионалом» в вашем понимании?
Какой порядок «углеродного выброса» микробов на 1МВт выработанной энергии ветряками? Где сравнение с углеродным следом тепловых станций? Не приведен? А почему?
Минеральные ресурсы, в отличии от ископаемого топлива, можно утилизировать по кругу неограниченное количество раз, вопрос лишь экономической выводы по сравнению с добычей.
Количество кобальта, неодима, лития и меди на Земле не изменится в случае полного перехода на зеленую энергетику. А вот нефть назад в скважины не вернешь без расхода количества энергии, превышающее уровень выработки на единицу массы.
Но деталях реализации протоколов распределенных систем вы с нуля и за три месяца не разберетесь.
Не я начал вереницу плохих аналогий. Я просто утверждаю, что любой бизнес пытается выжать ту скорость изменений, которая конструктивно возможна. Для разработки ПО это несравненно более высокая скорость, чем для других бизнесов, и потому проводить аналогии между проектированием ПО и проектированием водопровода или сети ресторанов просто не корректно.
Это просто совершенно разный класс проблем. В проектировании ПО в основном цена ошибки значительно ниже, но и размерность задачи (количество параметров, которые необходимо принимать во внимание) на порядок выше.
Проектируя сайт, вы заранее должны продумать, что будете делать, когда нагрузка увеличится в 1000 раз. От ресторана никто в принципе не ждет тысячекратный прирост наплыва посетителей.
Но в целом я согласен – чем более технологий знаешь, тем меньше необходимо времени на изучение следующей.
Да, ресторан может успеть стать неликвидным еще до того, как успеет открываться, так редко, но бывает. Но условия разработки – это когда шашлычная за неделю перестраивается в суши-бар, с возможностью по выходным принимать рок-концерт.
Просто приведите мне пожалуйста пример в любой из упоминаемых вами индустрий аналога понятия «пивот», когда за один год ресторан привращают в пивоварню, затем в завод по производсту амиака, а затем в лабораторию по производству вакцин.
Это примерно тот уровень изменений архитектуры, который ожидается бизнесом от команды разработки в ИТ.
То что вы приводите (рост интернет сетей) – это лишь количественное масштабирование, но не качественное. Как наращивать сеть интернет провайдера можно оценить еще в самом начале развития.
В итоге через 10 лет команда, проектировавшая разводку воды по деревне занимается (условно) логистикой в масштабе Земли, с применением всех видов транспорта, учетом погоды, изменения цен и дипломатических отношений, с применением искуственного интеллекта, арендуя транспорт у поставщиков. Это буквально то что происходит с разработкой – то, что еще 10 лет назад делалось вручную сеньйорами, сегодня автоматизировано, а серьйоры отвечают за оркестрацию более высокого уровня.
Но сравнивать разработку с проектированиям трубопровода крайне не корректно, поскольку доступность внесения изменений в ПО гораздо ниже, чем в трубопровод, и бизнес ожидаемо пытается выжать из скорости разработки максимум, а это значит что изменение требований будет настолько часто, насколько это позволяет команда разработки.
Где вы видели, чтобы план трубопровода города изменился еще до того, как закончились ремонтные работы согласно предыдущему плану, и в новом плане еще не проложенная труба уже успела стать неактуальной? В разработке ПО подобное происходит регулярно.
Кто-то назовет это «ошибкой планирования», но в действительно это лишь желание бизнеса бежать быстрее конкурентов. Если бизнес готов платить за накладные расходы, или жертвовать качеством, в этом нет проблемы, но в таком случае не нужно удивлятся, что всегда нужно выбрать что-то одно между «криво», «дорого» и «медленно».
Я бы посмотрел, как бы вы согласовывали изменения на лету между 30 ответственными за каждый кусок, решали вопросы перегрузки и недостатка ресурсов заложенных заранее, планировали запас и проектировали с учетом неопреденного будущего, а потом отчитывались почему перестройка происходит так долго и не эфективно.
А еще помимо воды нужно параллельно пустить лаву (по тем же трубам, но так чтобы они не смешивались), с возможностью разворачивать поток в обратном направлении, регулировать его скорость в зависимости от фазы луны и перераспределять нагрузку в автоматическом режиме, учитывая при этом постоянные ремонтные работы, но так чтобы вода никогда не пропадала у потребителей.
Вот это и есть ад разработки.
Между прочим, для токенизации кода и подсветки синтаксиса в xi-editor используется пакет syntect, который в свою очередь основан на моем заброшенном проекте sublimate по созданию open source клона Sublime Text 3 и на моем байндинге регулярных выражений oniguruma.
Так что мы по одну сторону баррикад гораздо больше, чем вам кажется.
Если дальше проводить аналогии, то я сравнил бы IDE с автоматической коробкой передач – кому-то с ней удобнее, а кому-то она будет мешать, если человек хорошо ездит на механике. Но вряд ли вам прийдет в голову утверждать, что те кто ездят на механике – плохие водители. И, как и автоматическая коробка передач для водителей, IDE не расширяет фундаментально ваши возможности как разработчика.
Но по какой-то причине ни первого, ни второго не происходит.
Не вполне понятна ситуация с сортировкой элементов перед суммированием, если такая возможность есть. Насколько это ухудшает/улучшает результат? Из вашей статьи кажется, что от этого больше вреда чем пользы, но это как-то противоречит моей интуиции, ведь если идти от меньших экспонет к большим, у нас есть шанс спастись от катастрофических округлений, например в случае с экспоненциальным распределением.
Как обстоят дела с сортировкой, если все значения одинакового знака? Можно ли считать что в таком случае сортировка точно не ухудшает результат? Если складывать отдельно положительные и отрицательные значения, но предварительно отсортировав их, ситуация лучше?
Ну и последний, практический вопрос: я правильно понимаю, что все приведенные алгоритмы не лучше простого перехода к арифметике с более высокой точностью? Скажем, если сравнивать приведенные алгориты на float против использования double в качестве аккамулятора.
Проверочный вопрос: считаете ли вы, что контрибьютор компилятора может быть «неполноценным професионалом» в вашем понимании?
Вы два раз спросили, вам два раза ответили.